Jump to content
  • Advertisement

Ohforf sake

Member
  • Content Count

    380
  • Joined

  • Last visited

Community Reputation

2052 Excellent

About Ohforf sake

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ohforf sake

    Random forum images

  2. Ohforf sake

    Matrix Inversion using LU Decomposition

    I was under the impression that the primary numerical benefit of a factorization over computing the inverse directly was the problem of storing the inverted matrix in the sense that storing the inverse of a matrix as a grid of floating point numbers is inferior to storing the factors of the factorization. If that is correct, wouldn't computing the inverse from the LU factorization diminish the numerical gains? I think I even read this in the Matlab documentation, that you should never explicitly compute the inverse of a matrix, but rather stick with the factors of the factorization.
  3. Ohforf sake

    Audio engine and various updates

    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 :-)
  4. Ohforf sake

    Audio engine and various updates

    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.
  5. Ohforf sake

    Horizon culling

    I didn't work myself through all those formulas but when it comes to culling terrain patches, why don't you use some sort of "backface culling". This is just a thought but lets assume you build your planets through reccursive subdivision of a tetrahedron (which would lead to an icosphere with easy LODing because of the hierarchy) and a terrain patch would be a bunch of triangles you get from the subdivision of a single triangle way up in your hierarchy. Now as mountains are relativly small compared to the size of a planet, this trianglesoup closely resembles the single parent triangle and if this parent triangle is backfacing (add a few degrees to be sure) then the whole terrainpatch is likely to be occluded. The backfacing test would boil down to a single dotproduct of view-direction and parent-normal. If its positive (or greater then some error-threshold) then its backfacing. In addition you could speed things up by making use of the hierarchy and checking the top levels first. If they are "extremely" backfacing (eg. the backside of the planet) discard all following levels and if they are "slightly" backfacing (eg. parrallel to the view direction) go down a few levels and check those again. However for other geometry like ships, moons, ... the above equations are still necessery, so as I said, just a thought...
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!