Problems with the osgaudioocclude example
Doug McCorkle
I noticed that with the osgaudioocclude example that if the object is either behind the viewer or very, very, very far in front of the viewer that there is not level change in the a.wav being played. I am assuming this has something to do with culling the object from view. Do you know what the problem may be?
Doug
Chris 'Xenon' Hanson
> Hey Chris,
> I noticed that with the osgaudioocclude example that if the object is either behind the viewer or very, very, very far in front of the viewer that there is not level change in the a.wav being played. I am assuming this has something to do with culling the object from view. Do you know what the problem may be?
The early SVN history seems to have been lost when migrating from the Skew matrix repo
to Google code. I can't tell for sure, but I think Paul (re)wrote this class extensively
to run on the update traversal instead of the way osgAL did it, which I think might have
been on cull, which would have been bad.
One would think that running on the update traversal, it should run fine despite and
near/far clipping. I don't see anything that would tell me otherwise.
I also don't have a test case that I've been able to reproduce what you're seeing here.
I diabled the auto rotation in osgaudioocclude, moved the sound node 20 units on the X
axis and loaded the dumptruck model. Occlusion seemed to work fine even when I zoomed so
far back I could no longer see the dump truck. It also seemed to work when the truck was
behind the camera.
Maybe you could try this test case? Attached is my slightly tweaked osgaudioocclude source.
> Doug
--
Chris 'Xenon' Hanson, omo sanza lettere. Xe...@AlphaPixel.com http://www.alphapixel.com/
Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting.
"There is no Truth. There is only Perception. To Perceive is to Exist." - Xen
Doug McCorkle
On Mar 16, 2011, at 1:01 PM, Chris 'Xenon' Hanson wrote:
> On 3/14/2011 7:57 PM, Doug McCorkle wrote:
>> Hey Chris,
>> I noticed that with the osgaudioocclude example that if the object is either behind the viewer or very, very, very far in front of the viewer that there is not level change in the a.wav being played. I am assuming this has something to do with culling the object from view. Do you know what the problem may be?
>
>
> The early SVN history seems to have been lost when migrating from the Skew matrix repo
> to Google code. I can't tell for sure, but I think Paul (re)wrote this class extensively
> to run on the update traversal instead of the way osgAL did it, which I think might have
> been on cull, which would have been bad.
>
The OpenAL and FMOD code now use the same update procedure which works fine so I think Paul's code is in the clear.
> One would think that running on the update traversal, it should run fine despite and
> near/far clipping. I don't see anything that would tell me otherwise.
>
THe issue with the sound turning on loud at far distances 1.0 x 10^9 can only be reproduced with FMOD. I could not get this to happen with OpenAL so I think this is an FMOD specific issue.
> I also don't have a test case that I've been able to reproduce what you're seeing here.
> I diabled the auto rotation in osgaudioocclude, moved the sound node 20 units on the X
> axis and loaded the dumptruck model. Occlusion seemed to work fine even when I zoomed so
> far back I could no longer see the dump truck. It also seemed to work when the truck was
> behind the camera.
>
Occlusion works fine as long as you are inside of 1.0 x 10^9 and as long as the reference distances are setup "correctly" with FMOD. If there are not then things sound bad just like with the osgaudio example.
Doug
Chris 'Xenon' Hanson
>> The early SVN history seems to have been lost when migrating from the Skew matrix repo
>> to Google code. I can't tell for sure, but I think Paul (re)wrote this class extensively
>> to run on the update traversal instead of the way osgAL did it, which I think might have
>> been on cull, which would have been bad.
> The OpenAL and FMOD code now use the same update procedure which works fine so I think Paul's code is in the clear.
I agree. I'm saying, as far as I can tell, it run on Update and not Cull, so it should
be immune to Call-related limitations.
>> One would think that running on the update traversal, it should run fine despite and
>> near/far clipping. I don't see anything that would tell me otherwise.
> THe issue with the sound turning on loud at far distances 1.0 x 10^9 can only be reproduced with FMOD. I could not get this to happen with OpenAL so I think this is an FMOD specific issue.
I am testing with the latest FMOD 43209.
>> I also don't have a test case that I've been able to reproduce what you're seeing here.
>> I diabled the auto rotation in osgaudioocclude, moved the sound node 20 units on the X
>> axis and loaded the dumptruck model. Occlusion seemed to work fine even when I zoomed so
>> far back I could no longer see the dump truck. It also seemed to work when the truck was
>> behind the camera.
> Occlusion works fine as long as you are inside of 1.0 x 10^9 and as long as the reference distances are setup "correctly" with FMOD. If there are not then things sound bad just like with the osgaudio example.
I'm a little confused about what you're reporting. Part of the original report said:
"if the object is either behind the viewer"
And I can't reproduce this particular failure. Is this case still failing for you or not?
I'll try to find a way to setup a failure with distances of 1.0 x 10^9 and see if I can
replicate it.
Doug McCorkle
On Mar 16, 2011, at 2:28 PM, Chris 'Xenon' Hanson wrote:
> On 3/16/2011 1:18 PM, Doug McCorkle wrote:
>>> The early SVN history seems to have been lost when migrating from the Skew matrix repo
>>> to Google code. I can't tell for sure, but I think Paul (re)wrote this class extensively
>>> to run on the update traversal instead of the way osgAL did it, which I think might have
>>> been on cull, which would have been bad.
>> The OpenAL and FMOD code now use the same update procedure which works fine so I think Paul's code is in the clear.
>
> I agree. I'm saying, as far as I can tell, it run on Update and not Cull, so it should
> be immune to Call-related limitations.
>
>>> One would think that running on the update traversal, it should run fine despite and
>>> near/far clipping. I don't see anything that would tell me otherwise.
>> THe issue with the sound turning on loud at far distances 1.0 x 10^9 can only be reproduced with FMOD. I could not get this to happen with OpenAL so I think this is an FMOD specific issue.
>
> I am testing with the latest FMOD 43209.
>
>>> I also don't have a test case that I've been able to reproduce what you're seeing here.
>>> I diabled the auto rotation in osgaudioocclude, moved the sound node 20 units on the X
>>> axis and loaded the dumptruck model. Occlusion seemed to work fine even when I zoomed so
>>> far back I could no longer see the dump truck. It also seemed to work when the truck was
>>> behind the camera.
>> Occlusion works fine as long as you are inside of 1.0 x 10^9 and as long as the reference distances are setup "correctly" with FMOD. If there are not then things sound bad just like with the osgaudio example.
>
> I'm a little confused about what you're reporting. Part of the original report said:
>
> "if the object is either behind the viewer"
>
> And I can't reproduce this particular failure. Is this case still failing for you or not?
>
It fails if the levels and distances are set to similar values as in the osgaudio example.
> I'll try to find a way to setup a failure with distances of 1.0 x 10^9 and see if I can
> replicate it.
I can replicate it with your code. I just "push" the object with my mouse with the "fly" feature in osgviewer and eventually the audio levels will jump.
Doug
Chris 'Xenon' Hanson
> I can replicate it with your code. I just "push" the object with my mouse with the "fly" feature in osgviewer and eventually the audio levels will jump.
Ok, will push it further and see if I can make it fail for me. I'm wondering if FMOD is
precision limited or something, because I'm pretty sure osgAudio doesn't treat far-off
stuff any differently. :(