| Submitted by , posted on 21 July 2001 |

Image Description, by I'm Dani Sánchez-Crespo, engine programmer at Novarama Studios, a new game studio in Barcelona, Spain. We have just announced our first project (code-named nova.1). It is powered by a custom engine built in-house by 2 people (me and my tech programmer Marc) and, as avid flipcode readers, we want to share some impressions with the community.
nova.1 is a 3D adventure with seamless outdoors/indoors levels. This puts lots of stress on the rendering pipeline (we use OpenGL for that, and reserve DirectX only for inputs, sound, etc.), as there's less occlusion than in something like an FPS shooter. Some decisions had to be taken to ensure decent frame rates.
For terrain rendering, we decided to use a scalable algorithm that can eat up a large or a small portion of our triangle budget depending on the level and the user's configuration. We can offer levels with very detailed land masses (if there's not many objects on top), or large levels (such as the forest in the pic) with low terrain detail. In terms of the algorithm, we explored the usual options like quadtrees, ROAM, self-similar fractal methods, etc. but in the end we came up with a technique somehow based in parametric surfaces instead of triangles, which works fine for us.
In terms of object representation, the first thing to note is that making a forest like the one you see in the top-right picture (4x4 Kms) is hard. Thus, to keep a "decent" memory footprint, we only store each object once (in the most compact form we came up with), and then instantiate it (hopefully using hardware transforms) along the game levels. We use a two-level visibility solver: one for gross processing of large areas, another for object-level visibility. Once we determine that part of an object is visible, we pump it to the card, regardless of the % of the object really visible. Triangle-level tests are not really worth it anymore according to our tests.
Data is pumped from the engine to the graphics card thru Vertex Arrays (currently trying to port to VAR/Fence, I know!). With this configuration we can send out an average of 780.000 triangles per second on a PII, 266 Mhz, 64 Mb, with a GeFORCE2 GTS (yes, old system, great for optimization!). We are achieving 16-24 fps as an average. Some early tests on VARs seem to raise the bar to about 2.1Mtris/sec, so we are optimistic.
Sadly, we do not have any fancy pics of the indoors renderer. We use a lazy version of portals which also helps controlling game logic (AI's, collisions, shadows maybe in the future). As you can see, our outdoors implementation is quite well suited for object-dense zones. This applies to indoors rendering as well.
Still, there's a lot of work still to be done: our terrain renderer is not particularly well suited for shadows, and memory footprint is still an issue if you want to build compelling levels. We hope to keep on working on them, and learning cool new tricks on flipcode!

[prev] | Image of the Day Gallery www.flipcode.com | [next]

Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.