Technical Question - why did the devs create roombrushes?

JarlFrank on 15/2/2016 at 23:10

So, having just completed my first FM, it has been a very interesting experience and I learned a lot about the inner workings of Dromed and the Dark Engine, but one thing I don't entirely get is:

What is the point of room brushes?

Basically, you construct a level in Dromed by carving out air brushes, then maybe filling in some solid brushes. Then you place objects. Those are the very basic elements of Dromed: solid walls, open spaces, and objects. In the open spaces - the air brushes, or also water brushes - you can walk, while the solid places block both movement and visibility. Nobody can see you through a wall, and light is blocked by a wall too. Very easy stuff.

And then, there are the room brushes. Into every walkable air brush you make, you put a room brush of the same size or slightly larger so it borders to or overlaps the next roombrush... exactly like airbrushes, but with sound instead of visibility/space. So basically, room brushes are usually molded exactly to the air and solid brushes so sound propagation works correctly: sound should travel through openings - windows, doors, etc - and be blocked by solid walls. Some objects like doors can even block sound travelling through a roombrush, so the engine can definitely handle objects blocking sound propagation.

Then why do roombrushes exist at all? Wouldn't it have been easier to just make sound propagation based on air brushes? Wherever there is an open space, sound travels. Solid brushes, just like some objects (the doors), block sound. Easy as that. It would save everyone the trouble of placing room brushes into every air brush, especially since room brushes can only have rectangular shapes.

Does anyone know why the devs programmed the engine like this, instead of having sound just propagate through air and water without the need for roombrushes?

LarryG on 15/2/2016 at 23:43

Room brushes give you sound propagation. In order to have sound propagate in real time on those old PCs back in the day, LGS imposed a simplified geometric structure called the room database. Each physical non-solid space is represented by one or more cuboid room brushes for the sound vectors to bounce off of. Each intersection of room brush to room brush creates a sound portal which allows for such things as doorways to block sounds when doors are closed. They also provide for sound attenuation as you get further from the sound's source or pass from air to water (or vica versa).

I forget who wrote this, but here are some room brushing tips:

Quote:

Room Brushing Tips-n-Tricks

I've had a number of people come to me with room brush problems/question, so I thought I'd write up the most common ones, and my strategies on resolving them.

How do I get sound blocking to work?
Sound blocking is done at portal boundaries. If you want to block sound with a door, it needs to be placed on a room portal (the area where rooms intersect), within a tolerance - it doesn't have to be exact. If a room portal doesn't exist where you want to block sound, you will need to create one, by splitting an existing room brush.

You can check if your door understands which rooms it blocks sound between by looking at the door property: it has two fields, Room ID #1 and #2, which indicate which room are on either side of the door. A value of -1 means that it can't find a room there.

This means that if you have a single room brush in a doorway that contains a sound-blocking door, it will need to be split into the portion of the doorway in front of the door and the portion behind.

How do I know if my room database covers my whole level?
There is currently no automatic way to check this, but places in a map that are outside the room database can be detected by playtesting. As of 1.118, whenever an object leaves the room database, it will spew to the mono. If you ever see this spew unexpectedly, note where you are in the level and examine it in the editor.

In addition, if you would like to know what room a given object thinks it's in, you can run the “spew_room_obj X” command, where X is the objID of the object you are interested in. This will spew its incrementally updated room, as well as its brute-force-computed room, indicated by an asterisk.

These two values should always be the same; if they aren't, you have a problem with the validity of your room database or its connectivity info. The best course of action is to inspect connectivity around the last room that the object thought it was in (which will be the non-asterisked value).

How do I know if my room connectivity is correct?
There are a number of ways to check connectivity of your room database. The easiest method is to select the room brush in question and click on the “Show Sel” button in the PNP. This will draw lines from the center of the selected room, through each of its portals, to the centers of the brushes on the other side of each of the portals.

“Show All” does the same thing, but with all the room brushes in the level rather than just the selected one.

Also, you can set the “RoomSpew” config variable (it must be done in a cfg file!), which will spew whenever a room transition occurs in game mode.

How do I know if my room database is valid?
There are a couple simple validity checking tools available when compiling your room database. You can activate these by setting the “check_rooms” config variable.

The first thing it will check for and highlight is rooms whose centers are within other room brushes. This causes problems with determining which way the room portals are “facing”, which can in turn cause problems with objects incrementally tracking which room they are in. The typical solution is simply shrinking/repositioning the offending room brushes.

If the first test is “passed”, it will then check that all room portal centers are within the world. Having room portal centers outside the world is not a problem for sound propagation (though you should be sure that you want sound to be able to propagate through whatever piece of world the room portal center is in), it is a problem for pathfinding using the room database. Pathfinding pre-calculates paths between room portal centers, and having a room portal center outside the world interferes with that.

also:

Quote:

Room Brushing Config Variables

Below are some user.cfg variables and other tools that are very useful when doing room brushing.

The first, Check_Rooms, applies to the operation of building the room database in the editor. It hilights room brushes that it considers bad or suspicious. First it hilights all room brushes whose center is inside another room brush. Those are bad room brushes. You need to fix those. If it finds no bad room brushes, it hilights all room brushes that intersect with other room brushes inside solid space. Those are suspicious, because you might not have intended those room brushes to intersect. Those are not technical problems the same way bad room brushes are, so you don't need to fix them but you should check them out and fix them if they aren't what you wanted. One thing to keep in mind with respect to room brushes with centers inside other room brushes: in some cases, it may be that you cannot figure out which other brush a certain room brush's center is supposed to be in. If you come across that case, by far the most likely explanation is that you've accidentally cloned that room brush without moving the clone anywhere, and you have two room brushes exactly on top of each other.

The other 2, RoomSpew and OutOfRoomSpew, spew to the mono during game mode. RoomSpew spews whenever any object (including the player) goes from one room to another, and it says which rooms the object has moved between. OutOfRoomSpew spews warnings whenever any object (including the player) gets into a space which isn't covered by the room database. Currently, this is somewhat redundant with an automatic warning that gets generated whenever an object doesn't know what room it is in. Ideally, no objects will ever get outside the room database, so you should address those warnings before your level ships.

The engine also spews automatic warning messages whenever it generates sounds that are outside the room database. You've probably seen them; they look like:
"ftroc_p1" on Player (12) (vec -1.0938154 -25.068552 -7.9059227) not in room!
If you go to the (vec x,y,z) coordinates using the command vm_teleport x, y, z you will find some reachable air space which isn't covered by any room brush. In the example above, this is probably a room brush that doesn't extend all the way to the floor that the player is walking on.

There is also an in-game display toggle you can use called show_player_room. This draws a thin black cube overlay which corresponds to the room the player is currently in. This one is really handy to visualize your room brushing, especially in complicated 3D spaces. The higher the game resolution you are using, the harder this cube is to see.

Lastly, when you select a room brush in the editor, the gadget has the buttons "Compile" which re-builds the room database (just a handy shortcut), and "Show Sel" which draws lines from the current room brush to all other room brushes it connects to (useful to see which rooms are connected for sound propagation), and "Show All" which draws all such lines for all room brushes in the level (not generally recommended for big levels).

Check_Rooms ; diagnoses the room database as it is being built
RoomSpew ; spews to the mono whenever objects make room transitions
OutOfRoomSpew ; spews to the mono whenever an object gets outside the room database

Telliamed on 16/2/2016 at 00:55

Room brushes aren't just for sound, they also determine how to build the AI pathfinding database. Pathfinding and sound propagation aren't line-of-sight so determining "Can I hear that sound?" or "Can I get from here to there?" are difficult problems. Much more difficult than just "Can I see that point?" which can be done with raycasting or binary partition search.

Like many difficult problems, it can be done if you accept a trade-off. Usually, that's either doing it precisely, quickly, or cost (memory usage) efficiently. Thief's greatest asset is its use of sound, so giving up any precision in sound propagation couldn't be compromised. And of course in a game you have to make everything run as quickly as possible. So the one resource LGS didn't have was memory usage. Trying to map every single part of the physical world for pathfinding would have taken more memory than they could afford. Thus room brushes were devised as a way to limit the size of the databases for sound and AI.

So no matter how complex or how many brushes are used to make a terrain that will be composed of any number of polygons and cells, the Dark Engine only sees it as one concave room. And however large your map is, the room brushes limit the AI to only consider the actual in-play areas that they can actually walk in.

Newer games are able to handle large pathfinding databases and do realtime sound propagation directly because we're running them on hardware that is faster and has more memory.

(completely unrelated, but I FINALLY figured out why the forum styles had been screwed up for over a year. Apparently there's some blank properties ("color:;") that Firefox instead of ignoring treats as an error. Copying a fixed copy of the stylesheet into userContent.css makes the site look normal again.... well, except now the editor buttons are all wrong. )

john9818a on 16/2/2016 at 02:42

I think Tellliamed made the point I was thinking about. The room brushes are never broken down into cells like most air brushes. There are also times when you have a mix of solid and air brushes within an air brush carved out as a room (i.e. bathroom) but you wouldn't want each air brush within that larger air brush affecting the sound propagation.

FireMage on 18/2/2016 at 02:34

You have although forgotten a very important task of the Roombrushes: Triggers and map localisations!

These things are used a lot by LGS team, to make something working like a BoundsTrigger but larger and more accurate, to detect who is entering in the room (The scripts named TrigRoomPlayer | TrigRoomCreature | TrigRoomObject etc.)
The final room goal too!

And these one are even more interesting in T2 with their ability to choose if such place must have fog or not, rain or something else.
With Newdark you can even change the whole ambience! :D

Rooms are surely one of the greatest tools in the Dark Engine! :)

Yandros on 18/2/2016 at 12:55

Inline Image:

http://www.wearytaffer.com/images/smilies/whathesaid_big.gif

Nameless Voice on 20/2/2016 at 03:10

Quote Posted by Telliamed

Newer games are able to handle large pathfinding databases and do realtime sound propagation directly because we're running them on hardware that is faster and has more memory.

Are they, though? I can't think of any games other than Thief that actually handle sound propagation really well. Nearly every game just lets sounds leak through walls without a care.
I just normally don't notice it because sound usually isn't as important in other games as it is in Thief. On the flip side, I might also not notice games that do it right because, again, sound isn't that important there.

TheDuriel on 20/2/2016 at 15:01

Quote Posted by Nameless Voice

exactly. generally sound propagation simply doesent matter. a recent game that does it quite well is rainbow six siege.