Brute force chunk NO-LOD terrain

I’m still not sure whether this is a good idea but here is the idea. I managed to get texture splatting working on the brute force terrain. I’m testing it using a laptop that defaults to nebula’s fixed function render path. Using the fixed function, I have to do a pass for each detail texture. I’ve set the shader to use 4 details textures so 4 passes. I’m still getting a decent frame rate of about 60 but as always a new problem rears its ugly head.

Distant primitives look very obviously tiled. So I had a bright idea (I think). I want to split the terrain mesh into chunks. I believe the beauty of brute terrains is that the entire terrain is uploaded once into the graphics hardware, now I want to split the beauty of it?

With Splatting

Without Splatting

The whole point of chunking it is so that distant chunks will be rendered using the large diffuse texture and a single pass. Chunks closer to the current view will be rendered using a splatting shader and a number of detail textures. I’m not trying to gain any speed improvements but rather to get rid of the tiling in distant geometry. I’m thinking I should get a trade of by gaining some speed for reducing the number of passes in distant geometry and loosing some speed for sending more batches of geometry so I’m hoping for pretty much the same frame rate as I’m getting now with splatting.

Wish me luck.

Brute … not so bad

I started working on my terrain implementation for nebula over the weekend. I chose to do a brute force implementation first just to get the hang of concepts like generating vertices from height map values and generating texture coordinates.

When I initially developed an interest in making games, I never thought I would have to do a terrain, I remember skipping the terrain chapter in a DirectX book I was reading back then. Needless to say I went back to said chapter over the weekend.

I now have a brute force terrain renderer which uses nebula’s default standard shader with a diffuse texture stretched over the terrain. You can imagine that the texture up close is anything but pretty.

Here is how it works. The terrain object requires an input heightmap with 8 bits per pixel. You may also provide a tile size parameter which is used to determine the number of vertices required plus to control the resolution of the terrain. A higher tile size means less vertices and a less smooth terrain.

Say we provide a heightmap of 1024 x 1024 pixels, a terrain of 1024 x 1024 units will be generated. If we had set the tile size to 32, we will end up with a vertex every 32 pixels/units. Therefore we will end up with 33 x 33 vertices for a 1024 x 1024 unit terrain which is pretty decent but what I’m most impressed about is the frame rate. I’m getting a frame rate of about 120 on a laptop with an intel chip though its still needs work on the texturing.

My plan was to get a basic brute force implementation rendering then immediately move on to a chunk lod implementation. Right now, I’m actually thinking I can get away with brute force so I’m looking at whether I can add texture splatting to it and see how far I can get with it.

A question for anyone who can provide some insight on using triangle strip primitives. According to the direct sdk docs, every 2^nd triangles should be oriented reversed for it to work properly. I can’t get the terrain to render properly using triangle strips. Looking at the bottom of the terrain, I see holes on every 2^nd triangles and from the top it seems fine but I can see hanging meshes on some parts of the terrain.

Choosing an engine … again

As far as game engines go, I’ve been around the block and back a couple of times. I have tried my hand at every engine I could get my hands on. I don’t know if it’s just me but every once in a while I question my choice of a particular engine and retry engines that I had already decided against. We’ll, it’s that time again. If you’ve read my previous posts you might have figured that I’m totally sold on the nebula device.

Lately while laying out the ground work for project samurai, I have had doubts about using nebula for it. Almost the entire game is set out doors with vast landscapes, a lot of vegetation (grasslands and sparse trees). In its current state, nebula has no functioning terrain renderer. There is a multilayer scene node that I think is basically a brute force terrain implementation and in my view doesn’t look very pretty.

Some time last year while on one of my engine quests, I came across S2 Engine. Back then it was in version 1.4 and had no terrain implementation. Something else that put me off is that they didn’t/don’t provide a demo. Its videos and screenshots looked very impressive but I decide against it mostly since I couldn’t try it myself. Now version 1.5 has just come out with a lot of improvements including terrain rendering, vegetation painting and mesh instancing. Again the videos and screenshots look impressive. Being part of a really small team it looks like an ideal solution for project samurai.

The only disadvantage of using S2 is that for a 135 euro version, I can only use the engines script interface and I’ve always been one who likes to look under the hood. There is an option to upgrade to a license that provides a C++ SDK and another pricier option that provides full source access.

I’ve been looking at the available terrain renderers with the aim of picking one to fix. The two available ones are both based on Thatcher Ulrich’s work on chunk LOD terrain. The first one, nclodterrain has some pretty nice tools for generating terrain meshes and textures but on running it, my terrain seems to be tilted 90 degrees around the X axis. The other one, ncterrain2 just displays a box; I’m still trying to figure that one out.

I have no intention of abandoning nebula but I think using S2 will speed up our development. In the mean time, I’m planning on working on a terrain implementation for nebula but I don’t want project samurai’s development to be tied to this.