Thursday morning it occurred to me that today would mark the 4 year anniversary of the start of my work on The Imperial Realm :: Miranda which made me think, "it's about time I put up some real, unretouched in-game screenshots."







I love the sand storm effect! Sometimes I park the camera under a ridge and watch the sand blow over my head. Getting all those particles interacting with the terrain at a decent frame rate was tough.

These screenshots show The Wasteland, one of several biomes in the game. It is hot, white sand, and rock and nothing lives there except some curious flowers. Anything you can see in the screenshots you can go to with no immersion-breaking load screens.

You may have noticed the second shot borrows a note from Oblivion. I loved the shots of Jack motorcycling between buried ships in a post-apocalyptic wasteland. If the final game reminds you a bit of Iceland, Oblivion and Prometheus are why.

Here is a good example of why multithreading is hard.

I can't remember the last time I had to spend any time finding a memory stomp. This was not always the case -- I have spent many an hour with data breakpoints. Man was I happy when those finally started working on the Wii. Today I thought I'd share a couple little things I use to eliminate overflows in my code.

I always hated working on games that didn't have a working debug build. On some the framerate was too low. Some didn't even build. There was always one real reason for it: somebody in charge didn't think it was worth having a running debug build. But the cost of a broken debug build is a huge increase in bugfixing time. Debugging a non-debug build results in misleading values in your debugging windows, bad callstacks, and heavy reliance on static analysis of trace output to figure out what has gone wrong. In short: it has a huge cost in developer time.

I've been stuck on this for a week, so I'm putting it out as a Friday puzzle challenge. Can you tell me what I'm doing wrong?

I added the normal mapping code from Followup: Normal Mapping Without Precomputed Tangents. I have other normal mapping code which uses the usual method of passing the tangent vector with the vertex data and that works great. There's no vertex shader code on The Tenth Planet, so I had to figure that out myself.

The problem I have is that if I use the normal from perturb_normal, the lighting rotates with the model so it is always the same side of the model that is lit (beautifully) no matter how the model is oriented relative to the light source. If I light the model with the interpolated vertex normal I get smooth n dot l lighting which works as expected.

In my quest to increase draw distance, I needed to find a way to reduce the number of triangles in my terrain block meshes from 7938 to something much smaller but that still retained the overall shape of the original block. I found lots of algorithms for decimating (reducing the number of triangles in) meshes but nothing specific to terrain meshes.

I read this post on AltDevBlogADay which made me decide to finally post this:

I was approached by a fresh-faced rep from Hansoft at Game Developers Conference a couple years ago. She asked me if I used project management tools, and after replying that I used their software, she was really excited and asked me what I thought of it. I told her I had never seen a product so thoroughly designed to make people feel bad about their work. She stared at me blank faced, then handed over one of every tchotchke they had in their booth.

The toys didn't make me feel any better about Hansoft. Do you have a happy team? Hansoft may well drive it into the ground.

I spent a couple hours reading pages of Google results trying to figure this out last night. There are a lot of people who seem to have problems with this. The pictures are all reasonably clear, but the implementations are quite variable for a non-math guy. Here's the resulting vector code which seems to be good. Maybe this'll help someone. Note that you can replace Vector3 with Vector2 and this will work for 2D lines.

p1 and p2 are points on a line. DistancePointLine returns the perpendicular distance p3 is from that line. It returns true if p3 is perpendicular to the line segment from p1 to p2, false if not. It also returns the distance from the infinite line going through p1 and p2 (because I found that more helpful.)



IntersectionPointLine returns the point on the infinite line that runs through p1 and p2 that is perpendicular to p3. Some variations of IntersectionPointLine return either p1 or p2 as the intersection point if p3 is not within p1 to p2 (u is out of range 0.0-1.0) which would give the distance to a point which is on the line segment, but in this case it is no longer the perpendicular distance. If this is what you want, in IntersectionPointLine return p1 if i < 0.0 and p2 if u > 1.0. That wasn't helpful in my case (I'm using this to decimate meshes) hence the code below finds the perpendicular distance from the infinite line.

Here is the C++ code:

    bool Geometry::DistancePointLine( const Vector3& p3, const Vector3& p1, const Vector3& p2, float32 *distance )
    {
        Vector3 intersection;
        bool withinLine = IntersectionPointLine( p3, p1, p2, &intersection );
        if ( distance != NULL )
        {
            *distance = ( p3 - intersection ).Magnitude();
        }
        return withinLine;
    }

    bool Geometry::IntersectionPointLine( const Vector3& p3, const Vector3& p1, const Vector3& p2, Vector3 *intersection )
    {
        Vector3 diff = p3 - p1;
        Vector3 dir = p2 - p1;
        float u = Vector3::DotProduct( diff, dir ) / Vector3::DotProduct( dir, dir );
        if ( intersection != NULL )
        {
            *intersection = p1 + dir * u;
        }
        if ( ( u < 0.0f ) || ( u > 1.0f ) )
        {
            // closest point does not fall within the line segment
            return false;
        } 
        return true;
    }

I was talking to an artist buddy on the weekend about post effects. I wanted to add a heat refraction effect for my hottest biome, and we got to talking about what other post effects I might want to consider. There are a ton of possible post effects, but as a non-artist, I'm often unsure as to whether they're really worth the effort of implementing. Color Correction came up as very worthwhile, and as it turns out, it is super easy to use (even for the artistically challenged.)

I needed to accurately determine the distance of particles from other scene geometry in order to fade out particles that are too close to things (which gets rid of nasty seams in the particles.) I'd used a method copied from somewhere but I noticed that particles got faded the further you got from them. This felt like a math error.

This week I did some digging around and found not one, but two methods to get the distance (in world coordinates) of a pixel from the camera.