Jump to content

  • Log In with Google      Sign In   
  • Create Account






Audio engine and various updates

Posted by Ysaneya, 08 July 2009 · 713 views

In this journal, no nice pictures, sorry :) But a lot to say about various "small" tasks ( depending on your definition of small. Most of them are on the weekly scale ). Including new developments on the audio engine and particle systems.

Audio engine


As Nutritious released a new sound pack ( of an excellent quality! ) and made some sample tests, I used the real-time audio engine to perform those same tests and check if the results were comparable. They were, with a small difference: when a looping sound was starting or stopping, you heard a small crack. It seems like this artifact is generated when the sound volume goes from 100% to 0% ( or vice versa ) in a short amount of time. It isn't related to I-Novae's audio engine in particular, as I could easily replicate the problem in any audio editor ( I use Goldwave ). It also doesn't seem to be hardware specific, since I tested both on a simple AC'97 integrated board and on a dedicated Sound Blaster Audigy, and I had the crack in both cases.

A solution to that problem is to use transition phases during which the sound volume smoothly goes from 100% to 0%. It required to add new states to the state machine used in the audio engine, and caused many headaches. But it is now fixed. I've found that with a transition of 0.25s the crack has almost completely disappeared.

One problem quickly became apparant: if the framerate was too low, the sound update ( adjusting the volume during transition phases ) wasn't called often enough and the crack became noticeable again. So I moved the sound update into a separate thread ( which will be good for performance too, especially on multi-core machines ) which updates at a constant rate independently of the framerate.

Since I was working on the audio engine, I also took some time to fix various bugs and to add support for adjusting the sound pitch dynamically. I'm not sure yet where it will be used, but it's always good to have more options to choose from.

Particle systems


In parallel I've been working on a massive update ( more technically a complete rewrite ) of the particle system. So far I was still using the one from the combat prototype ( ICP ), dating from 2006. It wasn't flexible enough: for example, it didn't support multi-texturing or normal mapping / per pixel lighting. Normal mapping particles is a very important feature, especially later to reimplement volumetric nebulae or volumetric clouds.

Particles are updated in system memory in a huge array and "compacted" at render time into a video-memory vertex buffer. I don't use geometry shaders yet, so I generate 4 vertices per particle quad, each vertex being a copy of the particle data with a displacement parameter ( -1,-1 for the bottom-left corner to +1,+1 for the top-right corner ). The vertices are displaced and rotated like a billboard in a vertex shader.

Performance is decent: around 65K particles at 60-70 fps on a GF 8800 GTS, but I'm a bit baffled that my new Radeon HD 4890 is getting similar framerates, as it's supposed to be much faster than a 8800 GTS. I ran a profiler and most of the time seems to be spent into uploading the vertex buffer rather than updating or rendering. I don't know whether I should blame Vista or ATI/AMD...

I still have a few ideas to experiment to better manage the vertex buffer and avoid re-filling it completely every frame, especially when some particles are static ( example: all particles in a nebulae ).

Visual Studio 2008


I migrated all my projects to Visual Studio 2008. While doing so I switched the C-runtime library from dynamic to static, hopefully avoiding future problems with missing dependencies. Unfortunately, most of the external libraries I was using were compiled with the dynamic CRT, so I had to update and recompile every single of those libraries, which took a lot of time. I also used that occasion to move the automatic linking of INovae's IKernel from the header files to the cpps.

Normal mapping


SpAce reported normal mapping problems in ASEToBin. He generated a cube in 3ds max, duplicated it, applied a UV map to one of them and used it as the "low poly" mesh, while the other version is the "high poly". Then he baked the normal maps from the hi-poly to the low-poly into a texture and loaded it in ASEToBin. The results were wrong: in 3ds max the cube render was as expected, but in ASEToBin, there was some strange smoothing/darkening artifacts.

I played with that code for days and was able to improve it, but arrived to the conclusion that they were caused by vertex interpolation of the tangent space. 3ds max doesn't interpolate the tangent space per vertex, but actually re-calculates the tangent space per pixel. The only way I could do that in ASEToBin ( or more generally in the game ) is to shift this calculationto the pixel shader, but for various reasons it's a bad idea: it'd hurt performance quite a bit; it'd raise the hardware requirements, etc..

So far I haven't seen any real-time engine/tool that took 3ds max's normal map and rendered the cube with good lighting, which comforts my in my conclusion that it can only be fixed if you perform the calculations per pixel.

Gathering Texture packs


In the past years, many people have made tiling texture packs. Those texture packs have variable quality; some of the textures inside the packs are excellent; others are "good enough"; others aren't so nice. Almost none of them were made with a specific faction in mind - which is partially due to us not providing clear guidelines on the visual style of faction textures -. In any case, I think it's time to collect all those textures, filter them by quality, sort them by faction and re-publish them in a single massive pack everybody can use.

It will take a while to sort everything. A few devs are currently working on new textures ( especially SFC textures ), but I think it would be nice if in the coming weeks some contributors could help. We are primarily looking for generic textures, like plating for hulls, greeble, hangar/garages elements, etc.. Also, if you have work-in-progress textures sitting on your hard drive in a decent ( usable ) state, now would be a good time to submit them.




How do you like VS 2008 so far?
That's very interesting about the ATI card, I had a somewhat similar issue with NVidia VS ATI a while back relating to redundant state changes.

The unnecessary state changes were all but free on the NVidia card, but were considerably slower on the ATI card.

Chalk it up to ATI mucking up their drivers :/
What (low-level) API do you use for audio?
I have only used OpenAL so far and found that it does the "interpolation" of gain, pitch, etc. automatically.


Also, have you thought about which sounds will be heared? After all it's vacuum out there so it should be pretty silent except for your own craft. ^^
Will you just ignore the fact and add the full audioeffect pallette (doppler-effect, distance attenuation, ...) or will you kind of muffle the distant sounds to low frequencies?

I'm asking cause you are aiming for a lot of realism and I always wonder how it will work out in terms of gameplay.
Quote:
Original post by Ohforf sake
What (low-level) API do you use for audio?
I have only used OpenAL so far and found that it does the "interpolation" of gain, pitch, etc. automatically.


I use OpenAL. However you have no way to let it automatically fade in or out sounds, so to do that you need to set the gain yourself. I haven't noticed any interpolation of gain, in fact I'm not really sure what you mean by interpolation, because it is my understanding that as soon as you call alSourcef with AL_GAIN, the gain is changing instantaneously.

Quote:
Original post by Ohforf sake
Also, have you thought about which sounds will be heared? After all it's vacuum out there so it should be pretty silent except for your own craft. ^^


It's a game, so there will be full sound effects. However I'm planning to add a "semi-realistic" mode where you can only hear sounds coming from your own ships, while external sounds get muted.

Quote:
Original post by Ohforf sake
will you kind of muffle the distant sounds to low frequencies?


I need to check again whether a low-pass filter is supported in generic mode in OpenAL (software mode). I've had a lot of trouble with the hardware accelerated driver in the past.
It took me some time, due to other stuff on my hands, but I did look into this interpolation problem.

Quote:
Original post by Ysaneya
I haven't noticed any interpolation of gain, in fact I'm not really sure what you mean by interpolation, because it is my understanding that as soon as you call alSourcef with AL_GAIN, the gain is changing instantaneously.

By interpolation I meant gradual changes of gain to avoid those artifacts you described.
I did some testing on my (crappy) notebook and found that it does no interpolation whatsoever, just jumping from old to new gain.
So I looked it up in the specification and found this:
OpenAL 1.1 Specification
In section 4.1 it says: "The implementation is in charge of ensuring artifact-free (click-free) changes of gain values and is free to defer actual modification of the sound samples, within the limits of acceptable latencies."

So I guess it should do the the interpolation on it's own, but it boils down to whether or not the current OpenAL implementation chooses to break with the specification.
Which is kind of good to know, as it forces you to do the interpolation on your own, just like you did...

Quote:
Original post by Ysaneya
I need to check again whether a low-pass filter is supported in generic mode in OpenAL (software mode). I've had a lot of trouble with the hardware accelerated driver in the past.


Using two samples for each noise, one with emphasis on low frequencies and one with high frequencies, might already do the trick. With two sources per noise you could mix them together with different gains (or different distance attenuation models) and hope that they don't run out of phase.

Again, I look forward to another journal describing whatever solution you found :-)
PARTNERS