 |
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!
|
|