 |
Submitted by , posted on 04 November 2001
|
 |
Image Description, by
Just another terrain-renderer-image-of-the-day, right?
Well, sort of... I put together this terrain engine a year ago to be used in
a real-time simulations course at university. Since we were getting our
grade based on the simulation (we did a SUV simulator, however these shots
are taken before the car was put in), not looks, our criteria were: Don't
waste too much time building the environment; it has to look good, but
doesn't need to be general enough to work for anybody's project.
So this is basically a lot of "cheating". I don't do my own shading, it
won't do timelapses, but then again, I coded it in no-time and it does what
it has to.
Lightmaps: Nope, everything baked into one nice little texture rendered
out in Bryce. Free proper shadows. Detail texture is separate, though.
Sun & Skybox: The skybox is also Bryce. Since we wanted a lens flare
effect for the sun (this is quite subtle and dare I say pretty tastefully
done) I just matched it's position to that of the sun's in the bryce
rendering.
Multitexturing: Just the larger bryce rendered texture and a detail one,
made to look like dirt. -Really- important in order to provide a sense of
scale to the viewer.
Technical notes:
Frame rate: 50-70 fps on a Rage128 on a 350 Mhz G4, using about 25k polys.
And this is while using GLUT in a window under Mac OS 9.
Static binary triangle-tree structure: I reduce my 257x257 (typically)
heightfield image into something like 25.000 polys using an algorithm
similar to ROAM, except it's not dynamic, stuff them into indexed arrays and
then render everything every frame. Even though the binary triangle tree
allows for easy and efficient frustum culling, keeping a static indexed
array can be lots faster. Only major drawbacks is the overdraws when looking
down the entire terrain.
Z-buffer lookups for the lens flare: For doing flares that are independent
of scene complexity and allows easy area light sources, this was way quicker
than ray casting.
|
|