Am I doing it right?

I've been inside of one of the usual guantlets of optimization. Somehow I always end up there, even if it's not needed. I guys I'm a tools/engine guy at heart. So, I recently added more threading. God, I love threading. I got a 10% performance gain on systems with 4 cores. On two cores it was more or less the same. On some really low end systems with integrated graphics, I actually lost a few percent, but I am not sure why as of yet.

The biggest improvement was scaling. Throwing in more triangels affects the performance much less now. And this is really nice. My system is filled with overhead and calculations. Frustrum culling, repositioning of vertices, etc, etc. It's something I have to live with due to the nature of my engine. It's main focus it that I can keep my code the same, even if I use Unity, SharpDX or Unreal Engine as my view engine.

The solution I came up with is to "compile" my current models to each view engine. So, for unity, I create lists of vertices and uv and for SharpDX I create list of ColorPositionTextureVertex, etc. So these needs to be compiled from time to time, but the major computation is when I commit the current frame. After culling all loaded meshes, I take the visible ones and combine them. All to make less draw calls. The resulting vertices and indices are sent to the graphics card and drawn. So, there is no vertices on the cards memory that gets reused from one frame to another. And that's probably not very smart. Most of my generated meshes are static, so I guess I could just update the indices for every buffer, every frame, instead of sending all the vertices and indices. That would result in more draw calls, but less sent.

Read the full post

Infinite terrain with BEPU Physics

I've recently swapped out my own physics engine for BEPU Physics. I have an "infinate" procedurally generated world. That really means VERY VERY large, not infinate. I believe infinate is impossible.

I decided to use a Terrain from BEPU which maps to a heightmap of floats. That was exactly what I needed. However, there was a snag. When I updated the heightmap, the Terrain thought it was in the same place.

Read the full post

Reworking my old generators

So, why do I always spend so much time on these things? I've previously made a dungeongenerators that work by using a path and branching off it. In retrospect, there's a few weaknesses with it. For starters, it doesn't really use up the area it's has allocated. It has huge gaps in it. That might also be a strenght, I guess. I want to streamline my map generators so they fit the same model.  I want to be able to transform my generation passes without having to change any code. Come up with new outputs by just fiddling with my viewer.

I chose that picture first, because the title of the post was to be "Generators, generators, generators!!!". It's so epic, so I will keep it with this footnote :)

Read the full post

Oh height map, my little friend

I'm still rolling my own "infinite" world. I havn't calced how long it would take to reach the edges, but I think would take considerable time. As always, development is slow and I don't have much time to spend on it. I generally code on the bus, some during lunch and sometimes before going to bed.

So, I tried writing my own midpoint displacement algorithm on a map that has the side in the power of two (256, 512, 1024, etc). It didn't work that well. It produced pretty images, but it was completly useless as a hightmap.

Read the full post