More teasers ;)

[EvilCheese]

Here are a couple more screens from my forthcoming game engine... these demonstrating my new custom pixel shader, and newly implemented anisotropic texture filtering.

This time the shots are taken from my new "desert waste" map.




Opinions/Criticism welcome (And desired).

Edit: Excuse the low res skybox I'm using... I need to get a better modelling package to produce them at finer detail.

[Shadowrage]

Get rid of the skybox lol! i want to be able to go to those far off hills and find them looking like that close up! not never reach em! n find an "edge"

Apart from that looking very nice, am/was a regullar tribes2 player and this terrain kicks its ass.

[Spht]

Looks neat. What happens when you fly to the sky? Are the clouds floating objects or generated colors on the environment map?

Also, are the mountains in the background actual object which faded itself like that when you're certain distance from them?

Is your whole world a square block which, when you met the end you stop at a blank wall? Or is the terrain infinitely generated as you move forward? Or is it a globe world all randomly mapped out when you start where you can keep going forward until you end up where you started?

[iago]

I notice that the stuff that's far away is a little blocky, but overall it still looks good (besides the sky, of course ;-))

[Camel]

I don't know much about 3d programming -- I've used OpenGL before, but as a 2d speed hack -- but would it not be possible to have the areas further away render once for every five frames or so (or, more efficiently, when user's view of the background changes significantly) in order to increase the depth that can be rendered? If so, it might be possible to have a *real* background without the uuber graphics card, no?

[EvilCheese]

Terrain is stored on disk as a heightmap, and optional shadowmap. A single heightmap file can be up to 1024x1024 heixels in size.

Heightmaps are read into a Terrain class, which subdivides and allocates the terrain in arbitrary sized blocks to a set of Patch classes which manage their preprocessing  tesselating and drawing.

The terrain class is organised such that multiple heightmaps can be loaded and tiled into the terrain on the fly, with only the relevant parts being present in memory at any time. This means that the world is potentially infinite, with bounds limited only by local storage space.

The number of triangles used to render each patch is varied depending on a variety of factors, including its screen-space size, variation, and distance from the viewer, such that flat areas and areas very distant from the viewer are rendered with very few polygons, whereas nearer terrain is meshed much more tightly.... this allows massive viewing distances without the need for occlusion fogging to hide clipping planes.

I originally implemented ROAM to achieve this, but found it too limiting for my requirements, so I've devised a custom mesh-adaptation algorithm (which seems to work quite well, as you can see).

Additionally, frustrum-culling and hierarchical occlusion culling at patch-level allow most out-of-view patches to be discarded before ever hitting the render pipeline, keeping framerate good, and processor-load fairly low (<=30% with the current implementation on my 1.3 ghz celeron machine).

The sky is presently drawn using a 90-degree-FOV-per-face projection box, giving the impression of sky and distant hills which are "immersive"... at a future time I hope to replace this with a more dynamic solution (volumetric clouds with projected shadows would be nice... and not too hard to implement).

In answer to your question, you can never possibly reach the sky, since the sky-projection volume is always centered on the currently active camera.

[EvilCheese]

I don't know much about 3d programming -- I've used OpenGL before, but as a 2d speed hack -- but would it not be possible to have the areas further away render once for every five frames or so (or, more efficiently, when user's view of the background changes significantly) in order to increase the depth that can be rendered? If so, it might be possible to have a *real* background without the uuber graphics card, no?

With the dynamic-tesselation I'm using, this kind of thing is possible now, the only reason you dont see it is that I'm not using heightmaps that large for testing.

(There's no way to avoid rendering everything per-frame, but you can adapt the mesh so that the background is trivial to draw)

[Raven]

The compression is pretty good on it. Only 147k for that size/quality.

[UrbalT]

It looks like shit in 8-bit.

Fix, please.  

[Eagle of BH]

Actually it looks really good, I'm sure none of you could do any better =p