TTLG|Thief|Bioshock|System Shock|Deus Ex|Mobile
Results 1 to 19 of 19

Thread: Room Bushes - How do they actually work? (from a technical standpoint)

  1. #1
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany

    Room Bushes - How do they actually work? (from a technical standpoint)

    Hi there Taffer's!

    Since I got into coding and blueprint scripting in ue4 I wondered how I could achieve a sound propagation system in a way that Thief has it.
    Room brushes seem to me a very solid solution but I can't find deep design information on how they really work.

    What I know to this point is that sound is propagated to the center of each brush, than to the next and so forth.

    If you guys know just a little more about that topic or where I can find even a document it would mean a lot to me
    Also, if you already experimented with these design's in ue4 let me know your aproach.

    Thanks in advance!

  2. #2
    Member
    Registered: Jan 2001
    Location: Constantly losing tug o'war
    The source code was released a while ago so you could have a look. It doesn't get much deeper than that. It's so deep you'll get the bends if you stop reading the code too quickly.
    This thread has a couple of links to try:
    https://www.ttlg.com/forums/showthread.php?t=134091

    Post #17 is an FTP link which might work (not working for me but I'm not used to ftp myself so I'm not sure if it's a bad link or my settings not being correct).
    Last edited by R Soul; 23rd Apr 2021 at 17:03.

  3. #3
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    Oh yeah, right!
    Having a look into that would be great.
    Sadly the FTP links are seem to be down

  4. #4
    New Member
    Registered: Feb 2003
    Try the South Quarter link in the wayback machine https://web.archive.org/ - one of the earlier captures should have what you're after.

  5. #5
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    https://web.archive.org/web/*/http:/...hquarter.com/* show's what has been captured but I'm only able to find NewDark zip's which are not I'm looking for (because NewDark is just a patch right?).
    But maybe I'm just overlooking what I'm after^^
    Also searching the Internet for the code seems not as easy as I thought...

  6. #6
    New Member
    Registered: Feb 2003
    Sorry, should have been a bit clearer. In the linked thread above, the post immediately before the one with the failed ftp site link contains a direct link to the South Quarter archive - so use this http://www.southquarter.com/thief_2_service_release.7z on the web archive search and it should have the file in one of the earlier captures.

  7. #7
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    Now this looks about right!
    Thank you very much

  8. #8
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    What I know to this point is that sound is propagated to the center of each brush, than to the next and so forth.
    During Room DB processing, Dromed calculates so called Room Portals - planes that lie on the border of overlapping rooms. For every room portal, it stores its center point (which also shouldn't lie inside the solid, like the room brush center itself) and it also stores distances from the rooms center to the planes center.
    So the actual sound propagation is calculated between the room centers and the room portals centers and then from portals to centers of the adjecent rooms.

    Kinda like:

    Room --> Portal --> Room --> Portal --> Room

    You can visualize the links in Dromed:

  9. #9
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    Thanks for the visualization!

    Okay, so these Portal's are created when a brush overlap's another brush on this specific location? But isn't this most of the time within a solid? (At least that's what I remember from my foolish Dromed mapping attempt's^^)

    I guess the PC (player character) or the AI raycast's to these centerpoint's to send and get information about the sound distance, loudness etc.

    What I didn't get yet is how these brushes work with a doorway.
    If a door is closed the doorway-roombrush has it's centerpoint inside the solid entity, which is the door. So it can't communicate the sound information from the adjecent room's(?)

  10. #10
    Member
    Registered: Oct 2004
    Location: Ireland/Poland
    Okay, so these Portal's are created when a brush overlap's another brush on this specific location? But isn't this most of the time within a solid?
    No, typically room brushes should overlap each other in open spaces, so the portal would lie within it. Exceptions may be, when room brushes are touching by corners (think L shaped room made of 3 room brushes).

    You can open up Dromed and check it for yourself - select any room brush and press Show All or Show Sel buttons at the bottom panel with brush properties.

    If a door is closed the doorway-roombrush has it's centerpoint inside the solid entity, which is the door.
    The correct way to handle doorways is to have two roombrushes on each side of the door, touching each other within the bounds of the door model.
    By their nature, doorways are always filled with air, or you'd never be able to go through them. If you're thinking of the black polygons that are generated within the door model geometry to block vision - they're only black polygons, but inside is still an air as a medium.
    It's the door's physical model, that you collide with - not a temporary solid wall.

    I'm not exactly sure how the engine handles door and sound attenuation. But it just must store an information on which links go through the door objects and check for the door closed status. Check 'Door > Rotating' or 'Door > Translating' Property. There are settings 'Blocks Sound %' and 'Lean Blocks Sound %'. Also each property holds IDs of two roombrushes associated with the door. These are probably calculated when you build Room DB.

  11. #11
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    Alright. I'll try to figure something out about how to achieve this

  12. #12
    Member
    Registered: Apr 2011
    The code is pretty straightforward to follow. You should start looking in sound/psndinst.cpp, at cPropSndInst::FindSoundPath()

    But the dark engine's manually-placed room brushes is not a great setup to emulate these days. A much better appraoch these days would be to voxelise the empty space in your levels, and trace sound paths through that.

  13. #13
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    Quote Originally Posted by vfig View Post
    A much better appraoch these days would be to voxelise the empty space in your levels, and trace sound paths through that.
    That's an interesting approach! I have to see how this would be possible with ue4. There is a Free Voxel Plugin now.
    Do you have experience with setting up sound propagation in games?

  14. #14
    Member
    Registered: Apr 2011
    I don't, but the basic principles for Thief-style single-path propagation are pretty straightforward (although not actually physically correct, it works pretty well in practice).

    You make a volumetric representation of the space. On any given frame, for each sound emitter, you find the shortest path from the emitter to the receiver (the player). The length of this path governs the apparent volume of the sound, and the direction of the last segment of the path (that is, the direction from which the path reaches the receiver) governs the apparent direction of the sound.

    Assuming the engine you're using already does basic positional audio (stereo separation and volume falloff by straight-line direction/distance) you could get Thief-like results by, at the start of the frame, moving the sound entity to the location of the second-last point of the path, and adjusting its volume based on the length of the path up to that point, like this:



    The hard part of this (i.e. expensive) is the pathfinding. But it is a simple pathfinding problem, so you want to choose a volumetric representation and a pathfinding algorithm that is easy to create and maintain (unlike room brushes!) and gives you suitable performance. And all the usual pathfinding optimisations apply: for example, you ideally don't want to recalculate the entire path every frame, but only when the guard or the player has moved such that the path would have changed (in Thief, this is when either of them moves into a different room brush).

    Once you have a system like this in place, supporting doors the way Thief does is straightforward: if the shortest path passes through a closed door, you simply multiply the sound entity's volume by an additional factor (according to how much the door should block the sound). To handle cases such as when a sound's path through a closed door is the shortest, but there is a slightly longer path through an open window beside the door—then you need to take the closed door's blocking factor into account in your pathfinding algorithm's cost function so that it prefers the window path. This is because what you really want is not the shortest path overall, but the path with least volume reduction.

    Addendum: You might wonder why Thief bothers with the room brush representation, when it already has a complete, precise, accurate, volumetric representation of the entire level, in the form of its bsp tree. Like, when deciding which polygons need to be rendered on any given frame, the game is essentially pathfinding through the bsp nodes and portals to find all the nodes that are visible from the camera position. So couldn't the sound propagation do the same? So, it could, but the level geo is a lot more complex than room brush geo, so there are way more nodes and portals to trace through, making pathfinding much more expensive. For rendering, the game only needs to consider portals directly in view of the camera, so it doesn't have to search very far or very deep; but the sound pathfinding needs to go in all directions and around corners to an arbitrary distance (limited only by the maximum radius of the sound emitter). So the simpler geometry of room brushes makes the sound pathfinding a whole lot cheaper. But i speculate that even back in 1998 it might have been possible to use the bsp tree. In the quake engine and its descendants, the straight-line paths between all bsp nodes that can see each other are precalculated when compiling the map (the 'vis' step), and stored in the pvs, the "potentially viewable set". This makes the renderer faster, because it doesn't have to walk from the node with the camera in through portal after portal after portal to build a list of all the nodes that might need to be drawn; it just looks up the pvs and immediately gets the entire list. If the sound pathfinding algorithm could use the pvs, it would be able to 'jump' much longer distances when searching, and find paths much more quickly. But the dark engine's renderer doesn't use a pvs, and without that using the bsp tree for sound pathfinding is definitely too expensive for real time on 1998 era cpus that are already very busy doing lots of rendering.
    Last edited by vfig; 4th May 2021 at 10:03.

  15. #15
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    This is absolutely gorgeous!
    Thanks a lot for this really gold, in-depth explanation.

    Especially this one is very interesting:
    Quote Originally Posted by vfig View Post
    you ideally don't want to recalculate the entire path every frame, but only when the guard or the player has moved such that the path would have changed
    and:
    Quote Originally Posted by vfig View Post
    This is because what you really want is not the shortest path overall, but the path with least volume reduction.
    I actually already experimented with sound propagation in ue4 by using function's like GetPathLength or GetPathCost. But this is (like you mentioned) a really cpu heavy calculation.
    Using a custom hard coded function would be the right solution. But this is for later^^
    ...at the moment I'm stuck with the challenge of creating a pathfinding function which is not based on floor pathfinding. To picture an example:
    If a space would be divided by a wall there would be no way to propagate the sound entity to the other half of the space if there would be no connection on the floor. But realistically the sound would of course be propagated over the wall. The same situation applies for your window example.

    So this is all related to more engine research. Again, I'm very grateful for your effort.

  16. #16
    Member
    Registered: Apr 2011
    Well, that specific situation you describe might be resolvable if you set up a NavAgent with a very big step height (so that it can essentially step over any wall). But of course you still will likely have problems with propagation through floor/ceiling holes.

    So using a floor-based navmesh is less than ideal, as you say. But still probably good enough for putting together a rough working prototype. Then if the prototype seems viable, you can swap in or build a different pathfinding system. Or you might find that even the floor nav is good enough if augmented with author-placed links for floor/ceiling holes, who knows?

    Remember, it doesnt have to be right, it only has to work and sound convincing.

  17. #17
    Member
    Registered: Apr 2016
    Location: Hamburg, Germany
    Quote Originally Posted by vfig View Post
    Remember, it doesnt have to be right, it only has to work and sound convincing.
    So true! I'll keep that in mind!

  18. #18
    Member
    Registered: Sep 2008
    Location: Deutschland/Germany
    BTW ... the property Add>Room>Ambient seems to have no effect?
    My FM campaigns Garrett's Young Years XTra, Reunion With Basso
    Want your upcoming FM translated in foreign languages?

  19. #19
    Member
    Registered: Apr 2011
    Quote Originally Posted by zappenduster View Post
    BTW ... the property Add>Room>Ambient seems to have no effect?
    yes, the property exists in thief, but neither the game code nor the stock scripts use it. (so in making a profit i made use of it to drive my custom ambience scripts on a room by room basis)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •