Well I'll be... That guy gone done copied yah!

t0tAl_mElTd0wN

07-02-2007 02:55:46

Yes, so today I had this Brilliant idea! Ill write an Ogre-specific wrapper for OpenAL, which uses Ogre's objects to manage OpenAL's objects' positions. Hell, I even came up with the best name ever: OgreAL! It's brilliant! I can't believe nobody has thought it up!

Yeah, so, after getting about as far as automatically calculating velocity, I posted on the Ogre forums and was pointed here. Doh! (http://www.ogre3d.org/phpBB2/viewtopic.php?p=201610#201610)

Anyway, figured I'd move the conversation on over here. As I said in my post, I'd certainly be interested in contributing, if I can get it to compile. I suppose I'll give it another shot, see how it goes.

CaseyB

07-02-2007 03:07:56

From the Ogre Forum:
I also had the object maintain it's own pointer to the Ogre node, so all one had to do was "piggyback" the OpenAL object on a nodeYup, I implemented mine as a subclass of Ogre::MoveableObject, so you can attach them directly to an Ogre::SceneNode and there is an inherent pointer to the node they are attached to through the MoveableObject.

Here's the code, if you're interested:I am VERY interested! This is one of the things that I thought about but never implemented because I wasn't sure whether it would behave appropriately across scene scales. I mean if the user says that 1 Unit = 1 Meter or 1 Unit = 1 Kilometer, will the sound behave appropriately? Would they just need to set the speed of sound in the units they are using? I never got around to playing with that!

I would indeed be interested in helping with the project though, provided I can get it to compile (I use MinGW and Codeblocks)WONDERFUL! I have struggled with support for Code::Block + MinGW!! It would be great to have you on board! I can help you get built and set you up with write access to the Sourceforge Repo!

t0tAl_mElTd0wN

07-02-2007 03:29:32

Alright. That sounds good.

The only catch to that auto-calculation is that the user has to specify the speed of sound.

Basically, pick a unit. In my game, our unit is meters. Now, the doppler effect works because the speed of sound is set correctly for the default, but we're not using the default. We're using our own measure of speed. This will be <user's units> per millisecond. Do a google search for "Speed of Light in Meters per Millisecond" - that's what my speed of light has to be. Once that's set, everything will just magically fall into place.

Working on getting the compiler working correctly right now. If I get it all set up, I'll fix up the directory structure again to mimick that of the Visual Studio project (I have both - no worries), and simply work out of my own project file, so I can keep my own directory structure, which has become a standard across my project.

I had thought of implementing the MovableObject, but I elected to go for a piggyback method (as opposed to a container method) where the sound object maintained a pointer to the node in question. That way I didn't have all those unused mesh variables and such, and I could focus just on the information I needed. As far as I could tell, it worked just as well.

CaseyB

07-02-2007 04:46:34

Now, the doppler effect works because the speed of sound is set correctly for the default, but we're not using the default. We're using our own measure of speed. This will be <user's units> per millisecond.That's what I thought, except that the default is in meters per second, so as long as the user sets the speed of sound to be X units/second, then it should work out! Very cool!

Working on getting the compiler working correctly right now. If I get it all set up, I'll fix up the directory structure again to mimick that of the Visual Studio projectIt's actually a slightly modified version of a Visual Studio project, I modeled it after the Ogre structure, there are some differences, but that's just because I didn't want to spend the time tweaking the settings to make it exactly the same!

I had thought of implementing the MovableObject, but I elected to go for a piggyback method ... That way I didn't have all those unused mesh variables and such, and I could focus just on the information I needed.There is no mention of any kind of mesh or anything else in a MovableObject, it's actually a (relatively) light weight class that acts as a super-class for any thing in the Ogre world that can be attached to a SceneNode (i.e. Cameras, Lights, Entities, Terrain, etc.) and has a lot of useful functionality that would need to be duplicated with the piggyback method. They are both viable ways to go, I just wanted the my Sounds and Listener to behave in exactly the same way as everything else that Ogre knows about. Even so much so that I registered a factory with Ogre::Root to create the Sounds and Listener so that they follow the Ogre paradigm exactly.

t0tAl_mElTd0wN

07-02-2007 05:04:16

Yeah, I saw that. Not bad at all.

I'll spend some time going through the code and familiarizing myself with it. I have a few ideas of features I'd like to add:

- The ability for an OggStream to accept data from an arbitrary data source (specifically UDP packets for voice chat)
- A class for accepting samples (OGG Encoded) from a capture device and sending to an arbitrary source (again, my goal being voice chat via UDP)

What I've seen so far I like, but it'd be nice if it was commented a bit more. You can expect I'll probably be adding comments and such. No Doxygen stuff, just code clarification.

CaseyB

07-02-2007 05:22:58

The ability for an OggStream to accept data from an arbitrary data source (specifically UDP packets for voice chat)
- A class for accepting samples (OGG Encoded) from a capture device and sending to an arbitrary source (again, my goal being voice chat via UDP)
I told you we are on the same wavelength!!! This is actually something that I am going to add for my job! How sweet is that, I'll get paid to work on OgreAL! We are not doing raw UDP, we are actually going to do VOIP, and instead of putting it in the OggStream, we are going to create another SoundStream subclass. Maybe even a NetworkSoundStream, and then use that to derive the VOIPSoundStream and you could do a pure UDP one if you like, the more the merrier! Our first goal is going to be playing sounds streamed over the network, so once you feel solid with the code you could look into setting up a capture device in OpenAL. I've looked at the API for that and it seems pretty straight forward, but I was interested in PLAYING sounds at the time! ;)

What I've seen so far I like, but it'd be nice if it was commented a bit more. You can expect I'll probably be adding comments and such. No Doxygen stuff, just code clarification.Yeah, I usually come back and add in comments, but after doing the Doxygen stuff I didn't make it to adding more comments to the code! By the way, are you playing with the OgreAL, or OgreAL-Eihort branch?

t0tAl_mElTd0wN

07-02-2007 05:31:55

At the moment I'm using OgreAL, not Eihort, as that's the library I'm currently using for development (and it was hard enough to set up the pre-compiled SDK on Windows... I'm afraid of compiling it myself :? )

I'll do a checkout of the Eihort branch, though, and take a gander through that. I suppose I'll have to up my ogre at some point, better sooner than later I suppose.

CaseyB

07-02-2007 05:37:07

They should both be exactly the same as far as the library code is concerned, the only differences are the input in the examples and the Ogre directory structure! So it's no biggie! I can just diff over any changes you make to the OgreAL branch. They are going to be merged after Eihort is released anyway!

Vectrex

07-02-2007 11:52:40

nice to see this project still going. Btw speex is the voip codec you should check out. If you download Raknet at www.rakkarsoft.com their voip demo uses speex (made by the ogg people)