Emitters and Distance Question
Hi again everyone!
Quick question regarding the implementation of the volume curve in XACT, and regarding emitters.
1) Is it wise to use one emitter and set it based on the current cue and shared by all the soud sources in the game? or create an individual emitter for each sound source? It seems to work alright with one emitter, a handful of critical sections and the like, but there isn't a lot of documentation in regards to its usage with multiple emitters. Advice willingly accepted on this one.
2) As for distance volume curves, I've played with a couple of things, but none of them seem to have any real effect on the volume based off distance. I started in the XACT Creation Tool, and played with the distance settings, making them smaller and smaller, and additionally with setting up a X3DAUDIO_DISTANCE_CURVE, consiting of an array of 10 X3DAUDIO_DISTANCE_CURVE_POINT's, ranging from 0.0f - 1.0f. This was then assigned to the X3DAUDIO_EMITTER pVolumeCruve parameter.
Am I approaching something wrong here? Or did I fail to pick up a nuance somewhere in the documentation?
Thanks again everyone
Hi Strakian,
For #1, I'm not entirely sure I'm following -- you can use as many emitters and listeners as you wish. Where/why are you using critical sections with the emitters? You might have one emitter per playing cue instance, or if many cue instances are coming from a single 3D location, you can reuse the same emitter (and returned calculations) for all of them. For instance, for a non-player-character, I might use their location as a single emitter, and all dialog, foley, and weapon sounds that they make come from that single emitter location.
For #2, X3DAudio's interaction with XACT can be a bit confusing. The basic rule is that if the sound designer has the ability to control an element of 3D, the X3DAudio functionality defers to the content. So for the specific case of distance rolloff, that can be managed by the content creator -- they create an RPC curve where the sound (or any of its track's) volume responds to the distance variable. XACT3DApply then automatically updates that distance variable when it's called, based on the XACT3DCalculate calculations. Any sounds using that RPC curve will now get quieter (or however you wanted the sound to behave) as the variable gets further out.
Hope this helps! Yes, the documentation should be clearer about how these interact. I'll file a bug.
-Scott
I believe what Strakian is doing is creating only a single emitter, and changing its position when he starts each cue, hoping that the cue will "remember" the position it was started with when he then changes the values to start another cue.
I would recommend using an emitter per object -- sharing a single emitter across all objects is not the way it's supposed to be done, AFAICT.
Yes, that's correct - you generally want to use an emitter per object (perhaps not per cue instance, but at least per actor/object in the game that makes sounds). I suppose if you never called XACT3DApply again on a cue instance (so you're just positioning it once and then are done with it), you could potentially reuse the emitter - assuming that everything you play on to that emitter has the same set up (same number of channels, same use as either a point source or a multi-point emitter), but as we're generally talking about objects that you're repositioning each frame, it's better to keep it to an emitter per object.
Thanks!
-Scott
Thanks for the info guys. This might be one of those things that should be mentioned in the documentation, because in all honesty, the game example is pretty useless for nuances like this. It just defined everything in a struct and used it, which doesn't help much if you're trying to create a generic approach to the problem, perhaps some useful comments? Mention in the emitters/listeners section of the documentation.
As for some of the previous comments, I was indeed using one emitter, applying once per cue play, and then using a critical section to update the emitter position on a cue every 20th frame or so in the update. This isn't code I entirely wrote myself, and some of it was pulled from the example game app. It seems to work ok for our game project thus far, so I can see no reason to overhaul the code at the moment. Just proves my point that certain things are still unclear in the documentation on things like this.
Thanks for the great responses!
