Change line of sight occlusion to be calculated by the audio system rather than the client - #14
Draft
ccp-zoetrope wants to merge 3 commits into
Draft
Change line of sight occlusion to be calculated by the audio system rather than the client#14ccp-zoetrope wants to merge 3 commits into
ccp-zoetrope wants to merge 3 commits into
Conversation
Register occluder spheres with the audio system and let Update() compute each positioned emitter's occlusion by testing the listener-to-emitter segment against them, instead of the game pushing per-emitter blockage. While spheres are registered, per-emitter blockage calls are rejected so the two drivers cannot fight; both stay disabled while acoustics is on. - Occluder centres stay in game world space (double) and are translated into audio space via SetOccluderOrigin, which the game reports as the player moves, so occluders never need re-sending. - Tunables: blocked occlusion level, radius scale (bounding spheres are larger than what they bound), and LoS recompute interval. - DescribeEmitterOcclusion() reports the listener/emitter positions and the responsible occluder, to tell real blockage from mismatched spaces. - Track whether a game object ever received a real position so origin-bound emitters (UI, music) are skipped, and add IsUsableWorldPosition() so the finite spawn sentinel can't poison geometry math. - Slower default fade rate (0.5) so sounds fade rather than switch. - Add test_occluder_sphere_exposure.py.
…ject * Occlusion had two drivers: the game pushing a blockage value per emitter, and the engine computing blockage itself from occluder spheres the game registers. * The API also moves off AudManager into its own Blue concept - audio2.GetOcclusion(), wrapped by python/audio2/occlusion.py - which is a view onto the manager's subsystem, not a second instance. * Gone from the manager: SetEmitterLineOfSightBlockage, SetObstructionOcclusion, ClearObstructionOcclusion, GetEmitterOcclusion, and the obstructionOcclusion* properties. * Added diagnostic api's for tests and QA tools.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The game used to compute line-of-sight blockage and push values per emitter from the client code itself. The game now registers the bounding spheres of balls that can block sound with carbon audio and this then tests each positioned emitter's sightline against them. In essence, the client is now responsible for pushing a smaller scale version of the Carbon Destiny ballpark into carbon audio.
Why
There are a few benefits we get from moving occlusion detection into carbon audio, rather than having the client doing all the calculations for occlusion:
How it functionally works
Testing