Being a sound guy, I always hate those games where you hear the NPC scream just as loud as before even when you close the door. So I was thinking if something more advanced could be implemented in jme3, at least some switch to disable sounds when the EarNode and the SoundNode have no "visual" contact? Maybe even something more advanced involving diffraction etc? I looked into OpenAL, but it does not seem like they're even thinking about something like that.
Could this be something for jme3 or do you think it is more of a high level thing to be implemented per game engine?
Interesting idea. Casting a ray from the source of the sound to the camera would get not only obstructions, but a direction for the sound, making it useful for a surround implementation.
jME3 was actually implemented with this in mind. OpenAL does support this with EFX (Effects Extension).
What you're talking about is referred to as obstruction, occlusion and exclusion of sound sources.
You would have to detect if the listener and source are in the same room or not, if there's a direct path between them, or there's an indirect path between them, and then apply the necessary low-pass filtering.
jME3 allows you to set a low pass filter with AudioSource.setFilter() call. The rest is left for the user although I could create a demo that would demonstrate this.
Also, you need JOAL in order to support EFX, LWJGL's OpenAL implementation doesn't have it.
Momoko_Fan said:
jME3 was actually implemented with this in mind. OpenAL does support this with EFX (Effects Extension).
What you're talking about is referred to as obstruction, occlusion and exclusion of sound sources.
You would have to detect if the listener and source are in the same room or not, if there's a direct path between them, or there's an indirect path between them, and then apply the necessary low-pass filtering.
jME3 allows you to set a low pass filter with AudioSource.setFilter() call. The rest is left for the user although I could create a demo that would demonstrate this.
Also, you need JOAL in order to support EFX, LWJGL's OpenAL implementation doesn't have it.
I looked a bit at EFX / EAX and it seems that what you are talking about is only filters, so the most simple implementation of something like this, working more like visual occlusion..
I was thinking about something more advanced where you maybe also compute the sound diffracting around corners, being reflected by walls etc. This would of course involve some kind of simple pathfinding and raycasting methods. Maybe the reverb-tool from OpenAL/EFX can be bent in such a way that the reverb can be computed from these values..
As I said, I am an audio engineer so maybe I can put some thoughts in this. I don't have very much experience with OpenGL and scenegraphs so I would maybe have to ask here and there about what info one can get painlessly from the scengraph etc.
Anyway, from the comments about CoD:WW one can tell that if you do it wrong, people dont like it :) And I am still not quite sure if this should go into the base engine..
Well why not?, just allow it to be deactivated and everyone is happy.
Having this stuff in the main release and have jme3 more like a omplete game engine would probably make sure that people
- know there is already something what the are searching for
- give them this forum as a place to discuss about
- reduce the initial problems newbies has with jme2,
I was thinking about something more advanced where you maybe also compute the sound diffracting around corners, being reflected by walls etc. This would of course involve some kind of simple pathfinding and raycasting methods.
It really isn't that difficult. EFX also has reverb which is essentially an approximation of sounds reflecting from walls. You can set the low pass individually for main wave & it's reflections. This can be used to simulate occlusion, if there's no direct path between the sound and you, the source's main sound will be muffled but the reflections will not, otherwise if you're in different rooms but there is a direct sound path, then the reflections will be muffled but the main sound will not, if you're in different rooms and there's no direct path both the main and reflections are muffled.
The muffling part I suppose depends on material characteristics but I don't think it matters much, this is only supposed to be an approximation.
Yup, thats the simple solution. But your brain is pretty good at decoding reverb information since it does every day. So if you just have the reverb with static settings your brain will always say "you're in the middle of the room". Based on where you, the geometry and the sound source are, more parameters than just hicut need to be changed (early reflections, late reflection density and panorama etc.). Also, walls normally dont just damp or hicut sound waves but they completely block them. Listen to GTA4 when you drive close to a wall. You hear the sound reflections from your own car, just as you do in real life. To me this is a massive reality boost.
Momoko_Fan said:
The muffling part I suppose depends on material characteristics but I don't think it matters much, this is only supposed to be an approximation.
Well normen, you're probably the best person at the moment to have brought up this topic as this was something I was thinking about when I first read the question. You might be able to build this into the physics library even... different attenuation levels for different frequencies depending on material hardness. :)
The “muffling” of the reverb is dependent on the material of the walls that reflect the sound source, the muffling of the direct sound also in some way, but it is more complicated than just telling which objects are in a direct line between source and ear and saying they dampen the high frequencies. That is what happens when you have cloth or something as a barrier where the air can actually go through. To clarify, a picture of the “simple” solution (yes, I am an artist!)
(blue=direct sound | purple=“muffled”/changed sound | arrow=percieved sound direction)
In reality it is a bit different than that, in a real room what happens is this:
Almost nothing is going directly through the wall (except for very low ferquencies that actually move the wall or traverse it if theres enough air exchange through doors etc.)
What you hear is the sound that is diffracting around the corner and maybe some relatively direct reflections from the walls. That is why I was mentioning path finding stuff etc.
Probably something as extended as this should really go into some external library since I suppose that it would involve too many parameters on Spatials for the sound engine that are not very “general”… So putting it in a physics engine may be a good idea…
Well I think either or…
Either:
JME3 is designed as a more or less monolithic GameEngine, with many features, and then please all in one projekt, so none gets forgetten over updates ect (like many jme2 project dies)
Or:
JME3 as simple high speed renderer , but nto capable of doing anything else.
But not:
Physics + Sound? I mean i understand the reasons but it is completly illogical to combine different parts, but not combine them with the engine then. Also integration within the engine kinda helps that everything gets bug fiexes ect, while seperate projects are kind of a problem in that case.
(If you had a bugfix for jme-physics would you know where to contribute/submit it with a few clicks?) I think we should have this forum as the central place where everything gets handled, also this makes sure that the librarys are not dieing due to missing active developers.
Just a few threads away was said something like this:
"I can't say JOGL looks like it's standing strong though. Its resources are all over the place, linking to javagaming forum, their own integrated forum, old Java.net repos, kirai repos… On that note though, I do need to get this mission statement, roadmap etc. set up on the wiki"
Please don't let that happen to JME
Empire Phoenix said:
Physics + Sound? I mean i understand the reasons but it is completly illogical to combine different parts, but not combine them with the engine then. Also integration within the engine kinda helps that everything gets bug fiexes ect, while seperate projects are kind of a problem in that case.
Yes, I think its mainly a thing of keeping the right information in/about Spatials here. For example, for the diffusion and reflection part one would need infos that are quite similar to those the renderer needs (occlusion, rays etc.) but on the other hand the physics properties of the geometry are needed as well. Even for the simple solution, so... don't know.. JME3 is supposed to be a game engine so one can say that most of the time you want to do something with virtual spaces, not just fast opengl effects for screensavers.. So tight integration of such features might really be something... hmhmhmhm :|
Integrating the physics engine with sound isn't possible… There simply isn't any API within the physics engine that simulates sound propagation and such. The physics engine should (mostly) just do rigid body collision detection and response.
That's not to say it isn't possible (without a physics engine), but I don't think that we should spend too many resources trying to achieve a sound simulation that is actually considered accurate. I think in most cases the sound being muffled should give the player the hint that the sound is beyond a wall and that he shouldn't worry about it.
JME3 is designed as a more or less monolithic GameEngine, with many features, and then please all in one projekt, so none gets forgetten over updates ect (like many jme2 project dies)
That's the intended result. jME3 is a game engine and is intended to have all the necessary tools and features need to create a high quality 3D game.
Momoko_Fan said:
That's not to say it isn't possible, but I don't think that we should spend too many resources trying to achieve a sound simulation that is actually considered accurate.
Its about "feeling accurate" to me, not "considered being accurate". I know many people can play a game even without sound but me, I am getting crazy.. But you are right, this affords some dedicated work.
To address the physics+sound bit I started, I should've better explained myself (and better thought this out).
Something along the lines of a pluggable "material library" could be interesting. Whether it's a ball bouncing or soundwaves reflecting, it's all based on physical material in the end. It could be something as simple as:
Material
- Hard/Soft values
- Density
[li]Reflective Properties/li]
In the end, I agree that super accuracy isn't the most important thing in the world but I think that people often undervalue the importance of sound in what makes a good AAA title
To the OpenAl, why not just check if it is installed
And if everything fails use the java sound api as a fallback (with only the basic stuff, no effects here)
Kinda like http://www.jmonkeyengine.com/forum/index.php?topic=10948.0, however more concentrated on the effects OpanAl can do, and just not using them when the JavaSound api is used.
Empire Phoenix said:
To the OpenAl, why not us (at least under windows a JNA check if it si isntalled , ect)
what?? :)
Well lets jsut checck if windowspathsystem32OpenAL32 or the respective 64 one is isntalled, and done
@Empire Phoenix did you mean to post that in reply to this message? http://www.jmonkeyengine.com/forum/index.php?topic=13057.msg95748#msg95748
Empire Phoenix said:
Kinda like http://www.jmonkeyengine.com/forum/index.php?topic=10948.0, however more concentrated on the effects OpanAl can do, and just not using them when the JavaSound api is used.
I think the 3D SoundSystem project is a great place to start with that.. Paul's done a really nice job of making that a pretty uncomplicated process while still remaining quite versatile and light
normen said:
what?? :)
I think Phoenix might have been dabbling with a brew or two considering his post after yours :p
Empire Phoenix said:
Well lets jsut checck if windowspathsystem32OpenAL32 or the respective 64 one is isntalled, and done
cough