0
0

My sound designer requested a feature where we put a lowpass filter on distant sounds. We’re using the Event API, so he could do it himself using the distance param, but he’d have to do that for each event, which would be a pain. So, I was thinking that an easier solution would be to use the Geometry API to create a box or simple sphere with an appropriate size and move it around with the listener. Seems like that would work pretty well. Anyone tried something similar? Are there better ways or hidden drawbacks with my approach?

  • You must to post comments
0
0

setOcclusion would be a better api to use. And its not a pain to use if you use template events, then you only have to create the rolloff curve once.

  • You must to post comments
0
0

So, you’re suggesting that each frame I iterate over all of the active events, compute the distance from the listener, and then call Event::set3dOcclusion()? I (yet) don’t keep a centralized internal list of active Events. Is there a way to get that from FMOD?

Also, the docs say that calling set3dOcclusion will override the Reverb Wet/Dry Level params set in the Event. Is that the case if I use the geometry API as well?

  • You must to post comments
0
0

How would your geometry idea work? It would be pretty binary. Either not occluded or occluded. You’d probably hear the sudden jump when it passed your sphere / box.

The audibility is determined with event::getinfo, but that doesnt mean distance. You’d have to compute distance.

I think i’d recommend just setting up a rolloff curve and a lowpass filter for events, and using a template.

The method with the least overhead would be to use the FMOD_INIT_SOFTWARE_OCCLUSION and Channel::setOcclusion on the low level, looping through all low level channels and calling get3DAttibutes to calculate the distance that way.

That way you wouldnt be allocating memory for lowpass filters for events, and you wouldnt be processing heaps of events, just a fixed number of channels every frame.

  • You must to post comments
0
0

The Event + template approach was the one I thought of first, but I was looking for a solution that wouldn’t require any sound designer work. I didn’t know about the setOcclusion API; the geometry idea was the first thing that came to mind, but I agree that it would probably be pretty binary.

I think I’ll give the Channel::setOcclusion approach a whack and if that fails horribly then we’ll go the Event/Template route.

Thanks for the feedback/ideas. I’ll post something once I’ve settled on an implementation strategy.

  • You must to post comments
0
0

Using the software occlussion path and looping through the channels worked great. Here’s the code, should anyone else be interested in it. There are a handful of calls to our vector library, but they are easily replaced.

[code:1k3t7ufu]
FMOD_RESULT result = FMOD_OK;
FMOD::System* pSystem = NULL;
result = s_pFMODEventSystem->getSystemObject( &pSystem );
if( result == FMOD_OK )
{
for( int i = 0; i < MAX_CHANNELS; ++i )
{
FMOD::Channel* pChannel = NULL;
result = pSystem->getChannel( i, &pChannel );
if( result == FMOD_OK )
{
FMOD_VECTOR vFMPos;
result = pChannel->get3DAttributes( &vFMPos, NULL );
if( result == FMOD_OK )
{
float distance = m_vListenerPosition.Distance( vec3( vFMPos.x, vFMPos.y, vFMPos.z ) );
float occlussion = 0.f;
if( distance > m_distantLowpassRange.max )
{
occlussion = m_maxDistantOcclussion;
}
else if( distance > m_distantLowpassRange.min )
{
occlussion = ( ( distance – m_distantLowpassRange.min ) / m_distantLowpassRange.Delta() ) * m_maxDistantOcclussion;
}
result = pChannel->set3DOcclusion( occlussion, 0.f );
}
}
}
}[/code:1k3t7ufu]

  • You must to post comments
0
0

If anyone needed this to only be applied to certain types of sounds, and is using the Event system, it should be possible to use EventCategory::getChannelGroup (for each event category you need affected) and then loop through its channels with ChannelGroup::getChannel.

Just in case anyone needs more control over which sounds you want affected by this.

Nice catch though audiodev, this is something I’d looked into briefly too.

  • You must to post comments
0
0

Interesting.

Was there any difference in performance/memory-usage when using the occlusion and/or EventCategory::getChannelGroup path vs applying to individual events (or using templates to apply to multiple events at once)?

  • You must to post comments
0
0

Glad you guys like it. The big different for me between the channel/occlussion approach vs the Designer/template approach is that the former doesn’t require any work from the sound designer. It’s also avoids some of the sticky issues with templates and is less bug prone. My impression from Brett’s post is that it’s also more efficient to go the occlussion route, presumably because you’re working off of a more specialized, internal FMOD structure rather than the more generic Event/parameter system.

I think the only wrinkle with doing it based on EventCategory is that there’s really a tree of ChannelGroups when you use the Event system, so you’d need to walk the entire tree, but other than that, it should be just fine. We may go that way eventually, depending on the amount of control we need in the end.

  • You must to post comments
0
0

this should probably be a wiki entry in http://www.fmod.org/wiki !

  • You must to post comments
0
0

It is now!

[url:3ke3l6n7]http://www.fmod.org/wiki/index.php5?title=Simulating_Distance_With_set3DOcclusion[/url:3ke3l6n7]

cheers,
Templar

  • You must to post comments
Showing 10 results
Your Answer

Please first to submit.