Keeping the GPU on its toes

Engines, Libraries and Tools Java 3D
#1

From everything i’ve read on 3d programming, the main problems seem to be sending the info in the best way to the GPU to keep it constantly working, as opposed to waiting for texture uploads, state changes, readbacks (ack!) etc. Note i’m thinking from an openGL viewpoint here…

As I currently see things, theres several important factors, namely:
[] Minimising texture switching, seems to be a major point from what i’ve heard, switching vertex/pixel shaders being the only operation thats more expensive it seems (but shaders are out of my hardware range so i’m ignoring these for now). I assume the high cost is that the texture has to be transfered accross the AGP bus.
[] Static/compiled geometry. I’ve been seriously surprised how much this can speed things up, however good it may be it contradicts many other points (and i can’t do my own lighting calculations, boo, hiss).
[*] View culling. Important technique, but again seems to contradict with using compiled geometry.

I’ve probably missed somethings that others will rank as important, but for the time being these are what i’m trying to concentrate on. I’m going to keep things simple and have a top-down tile/iso/hex type engine, but i can’t seem to come up with a design that manages to neatly deal will all of the above without excessive amounts of processing before the actual rendering. I’ve got a few half ideas at the moment, but i’d like to hear some other opinions first.

Cheers

#2

Well, you’re basically dead on target. Designing the bit that gets the best out of it all is indeed the difficult part.

It used to be that texture uploads were potentially the most expensive but these days you really want to make sure your geometry is culled to the minimum necessary to avoid overdraw. The thing is, they’re all expensive operations but the expense varies greatly between cards, so you really have to do you best to minimise everything.

Cas :slight_smile:

#3

After much metaphorical beard scratching, I think i’ll be able to get some pretty good view clipping with a portal-eque system of interconnected cells (which would probably be good for ai as well if i got that far). Still plenty of grey areas though…

Does filling up a vertex array for each texture per frame sound like too much overhead? Basically find all visible tris, bung all of texture 1 in a vertex array and render, repeat for all of the rest of the textures…

#4

So Java3D has a fair bit of wizardry in it in just these areas.

It does efficient view-frsutrum culling, compiles and optimizes the scene graph tree, and does state-sorting in order to minimize those nasty GPU context switches.

For details of how this is all done though you have to ask our Wizard-of-3D, Doug Twilleager.

JK

#5

On a side note, yesterday my copy of ‘3D engine design’ ( http://www.gamedev.net/columns/books/featuredbook.asp?productid=101 ) and frankly i’m not impressed >:(

A much more accurate title would be ‘3d collision detection’, since practically all of the book is testing collision of X against Y. Now while i may at some point need to calculate the intersection of a lozenge against a capsule, its really not what was promised. And theres but a single page on portal visibility, and a measly 3 on bsp’s. And the only info i can find on this thread topic is but a single sentance: ‘Then the Renderer can sort the objects to minimise state switching’.

/rant.

Maybe a section on the site for book recommendations etc. similar to the one over at flipcode would be a good idea?

#6

Designing a 3D engine always is to find a good tradeoff for various optimums. Some optimizations are mutually exclusive - which always leads to different engines for different purposes.

More geometry? More lighting? More textures? Bigger scenes? More effects?

Take any two of these…

If the GPU has to change textures, it not only has to be loaded from main memory (in the worst case), but it also stalls the pipeline (at least in earlier days when I dealt with these things). So better sort for textures. But also sort for transparency (which break texture sort). And also sort geometry (which breaks texture and transparency sorts).

So it’s no wonder that there are indoor engines, outdoor engines, flightsim engines, …

I love the idea that there is an engine that cares about these things for me. And I hope that Java3D does (and I feel it does better than I could do!).

I hope I never need to go down to OpenGL again…