Not logged in, Join Here! or Log In Below:  
News Articles Search    

Submitted by Daniel Sanchez-Crespo, posted on July 21, 2001

Image Description, by Daniel Sanchez-Crespo

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!

Image of the Day Gallery


Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
Rectilinear Cat

July 21, 2001, 02:06 PM

That is INSANE!!! Very nice work! Are those trees bump mapped?

Warren Marshall

July 21, 2001, 02:08 PM

The shots look great! I notice that the terrain is very flat though ... is that by design or a limitation of the engine?

Kurt Miller

July 21, 2001, 02:10 PM

I was just admiring these shots the other day on Avault ;] Great stuff...

Phil Carlisle

July 21, 2001, 02:14 PM

Hey Daniel,

Is this the same game thats got a column on gamasutra?? about the startup studio??

Anyway, looks really good so far, keep up the good work!


Isaack Rasmussen

July 21, 2001, 02:31 PM

Wow! Nice graphics!
The tree texture looks particular amazing.


July 21, 2001, 03:26 PM

If you read, he says that when drawing object like in the tree scene, the landscape detail has to be lower.


July 21, 2001, 03:50 PM


GeForce2 GTS is an old system, though?


July 21, 2001, 04:16 PM


David Olsson

July 21, 2001, 05:08 PM

He probably meant the cpu, don't you think ?


July 21, 2001, 05:15 PM

This is absolutely gorgeous. It looks like about the quality of Riven, which is pre-rendered by a server farm!


Warren Marshall

July 21, 2001, 05:25 PM

Thanks, but I already read that. However, all 4 shots are flat terrain and I don't see tons of trees in each one. I was just curious.


July 21, 2001, 06:24 PM

Morgan > Cant agree with you hey Riven has awesome great artwork !!! Anyway as u said it was not real time and cant compare both engine !

Nice work anyway guys ! any tech demo available soon ?

zed zeek

July 21, 2001, 07:14 PM

excellant looking stuff, u wouldnt mind sending me a few models of those trees would you ;) just joking.
i notice (topleft screen) the sky isn't fogged. personally i fog the whole sceen (sky included) IMHO it looks better but this is a matter of taste. also the lighting doesnt look right, still looks good mind. i luv the use of curves to describe the terrain.


July 21, 2001, 08:39 PM

Obviously, but I can't see a P2-266 being put under that much stress with a GeForce2 GTS in it's arsenal. Do you see?

David Olsson

July 21, 2001, 09:33 PM



July 21, 2001, 10:47 PM

*cries* =). That is amazing. I should probably kick myself in gear working on my own project =). Wish I had a GeForce2 to work with...

Is that a rope bridge in the upper left of the bottom left pic?



July 22, 2001, 12:16 AM

Great work Dani(and rest of the team , of course)!

I´ve been following Novarama´s work since the first article at Gamasutra. I reached to your employment page too, the slogan nearly makes me drop out of University:"Leave everything and follow us" 8).

Hope to find another article at Gamasutra soon, talking about how great and sucessful the game became...

zed zeek

July 22, 2001, 12:59 AM

have a look at this screenshot
youve prolly already noticed it but somethings not quite right with the fogged out tree in the middle

Jukka Liimatta

July 22, 2001, 02:39 AM

>Obviously, but I can't see a P2-266 being put under that much stress >with a GeForce2 GTS in it's arsenal. Do you see?

No. nVidia hardware always requires a fast CPU, even GF3.

Give the GF3 code which consists only of DrawIndexedPrimitive() calls, where VB's are in videomemory, and you still get 2-3x better FPS with P4/1.7Ghz than P2/400Mhz machine. This is surprising since the DrawIndexedPrimitive() *should* by theory put all workload onto the GPU. It doesn't in practise based on the results we get in real world.

Sorry, but I don't see it your way.

Joe Ante

July 22, 2001, 06:50 AM

Your visibility culling sounds interesting. Would you mind giving more details on the outdoor occlusion culling?


July 22, 2001, 07:59 AM

if u use var, the gpu does everything except processing the indecees, everything else is then yet put onto the gpu and done there, but if you not use VAR, the cpu has to put the whole data every frame over to the gpu, and if you have a slow cpu, this takes much time.. ( its not only the cpu, but if you have an old system, wich is nearly logical fact here with a p2 something, then it means that transfering the data takes much time in affort, if u use an athlon 1.9gig with ddr-ram and all normaly this datatransfer does work much faster, too )


July 22, 2001, 08:54 AM

Ok, thi is Dani speaking. First of all, thank you very much for the comments, impressing you guys is really an honor for us. Let's see if I can make any sense:

All pics were taken on a P2 with a GeFORCE2. Most of the coding was done with a TNT2, and yes, moving to the GeFORCE gave us a speed kick (almost doubled). The reason for this I guess is better handling from the driver of VA's. All the stuff about a P2 not being able to deliver data to a G2 blah blah is false: moving from a TNT2 to a G2 on a P2 makes the demo QUITE faster. Still, the game is designed for P3 600 or so. The Geforces allow us to have high-res textures and register combiners, which is one of the key factors to deliver photo-realism on a PC.

About the terrain, we can do more or less everything as long as it's 2D and a half (no vertical walls, no flyovers). We do all that with additional layers on top of the terrain engine. The demos are flat, yes, we agree. Keep in mind our goal is to concentrate on the visual experience, not the tech side. So, terrain often yields triangles to other rendering stages to ensure the whole thing makes sense. I hope to be able to send some pics with rougher maps though. The result is somehow like Tribes II terrain-wise, only that we have better texturing and put more funny stuff on top of the land ;-)

Phil: yes, we are the Gamasutra guys. Expect 3rd installment of my column by mid-August, covering the "from demo to engine" process and some random thoughts on making great games. I have also applied to talk about game studio creation at GDC'2002... we'll see if the Gods favor me.

About the Riven/modeling side, I have the great pleasure to have 3 of the best modelers I have ever met in my team (cheers to them all from here!!!! We did it guys!!!!). Their work simply leaves our tech behind. Besides, we share a common vision and, yes, Riven is part of it. Still, those images are only a tiny part of the vision. If I were you, I'd have some kleenex ready: we are gonna do it even better ;-)

Zed Zeek: yes, The pic you point to is not quite right. Z-ordering is WRONG there, showing our BSPs, quadtrees, portals and other gimmicks need some more working. Keep in mind we are still testing, so there's many problems arising (although we are happy with the results so far)

Joe Ante: Ok, the answer is NO, i cannot give you all the funny details, but here's some ideas:
- terrain (and distance) is a good culler for large areas, which can be precalc'ed: hills blocking the view, etc.
- smaller, close to the viewer areas can somehow be processed with a finer algorithm which works on a object-level.
Another issue is memory footprints: we have about 1M trees maybe, so all this culling algo has to work with references and not objects themselves.

That's it. I will post another answer if there's more questions. Just thank you very much for your comments (especially criticisms). It is a pleasure to discuss stuff with you guys.

Sebastian Sylvan

July 22, 2001, 09:24 AM

Damnit! I thought I was the first one to give serious thought to precalculating terrain culling.

Phil Carlisle

July 22, 2001, 11:42 AM

I think I saw a paper by Rottger about terrain culling using precalculation (kind of like using higher parts of the terrain as occluders.

Daniel: I hope you keep on and get to the point where you have enough tech to make your game. I'm not a fan of engines as is (other than seeing nice things), but I think you guys will actually get to produce a game :))



July 22, 2001, 02:16 PM

Nope, just a branch.
But it sure is sweet looking!
Can't type more... changed keyboard to dvorak... bye... take care... tell mom I love her.


July 22, 2001, 03:04 PM

Hrm, well ok, that's interesting to know anyway :)

Joakim Hĺrsman

July 22, 2001, 04:59 PM

Are you sure those buffers are in videomem? If they aren't the fact that the P4 has _much_ higher memory bandwith than the P2 will make a big difference. Then the GPU is basically sucking vertices from memory, so the bandwith would make a large difference. CPU is still important though. Then maybe the driver does some kind of index processing.

zed zeek

July 22, 2001, 05:52 PM

i also have occlusion culling in my game which uses everything as occluders includeing the landscape,trees etc :)
trouble is it takes nearly an hour to calculate it.
the final version will take 2396x as long to calculate.
1hour x 2396 = (waiting until i upgrade my cpu/graphics card)

This thread contains 28 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.