OpenGL Geometry Instancing...

[nbohr1more]

I thought I would pop in with another of my lame-brained speculations about engine-tech that I only have a peripheral grasp of...

 

I have seen discussion of Geometry Instancing since the cat was let out of the bag about it for ATI's X800 series (the secret was that the hardware already existed in Radeon 9xxx DX9 cards).

 

ATI, at the time, was only exposing Geometry Instancing as an API hack in D3D. If I'm not mistaken, it took until Geforce 8800 for the OpenGL extension to appear.

 

As you can see, I've been obsessing about GC and MD's CPU pulverizing Forest in NHAT 3/3 and I remembered that this technique was postulated as a solution for that problem (way back in X800 olden-times).

 

So:

 

1) Would it be possible to create a Particle Shader that invokes Geometry Instancing to create Trees?

2) Would this have any performance benefit or would Doom 3 still need to pass interaction calcs to the CPU (perhaps making things worse due to the lack of Visportals)?

3) If this is possible, does anyone know if older cards like nvidia's 6xxx or ATI's 9xxx series now have Instancing in their OpenGL ICD or is this feature tied to OpenGL 3.2 (and therefore DX10 class hardware)?

 

Example:

 

Instancing Demo

Edited June 6, 2010 by nbohr1more

[nbohr1more]

Hrmm... looks like this is still a WIP for OpenGL ... both ATI and Nvidia STILL have driver compliance issues... I guess Instancing will have to wait for TDM v2 on Id Tech 7 ...

[OrbWeaver]

Nothing like this is possible until/unless the Doom 3 code is open-sourced by id.

[nbohr1more]

Is this the same limitation that was referred to in the Parallax Mapping discussion, eg. the engine is limited to 2 shaders so any added shaders have to be chained-into the existing ones?

 

(excuse my ignorance and lack of precision).

 

So this means that any one-off whiz-bang shader effect for, say, making torch flames, water, or candles look better (not that those examples really need any improvement ) will have to wait for GPL as well?

 

(I thought that the limitation was only for things that affect the entire light model???)

 

 

 

(for the future?)

 

...Anyway, it looks like there are a at least a couple of ways to skin a cat.

 

See Humus's method at the top:

 

Instancing Discussion

 

Nvidia's "Pseudo Instancing":

 

Pseudo Instancing

[OrbWeaver]

The shaders in Doom 3 can be modified, but the inputs to those shaders cannot, because they are part of the renderer code. The inputs to the shaders are values that are relevant to the light interaction shading, such as surface texture, light colour, light position, vertex colour etc.

 

Implementing advanced shaders which perform substantial rendering operations (rather than the simple dot-3 bump-mapping they do at the moment) is therefore not possible, because the advanced shaders would require access to more information about the level geometry that they currently have. The reason parallax mapping was possible is that this technique uses the same bumpmap information which is already available to the shader for use in the dot-3 lighting code.

[Serpentine]

GI pops up quite often in various discussions, at the end of which it boils down to this:

Do you have control of the hardware? do you have absolute control of the situation? if you can answer yes for both there is a chance that it will be useful.

 

Since ATI were the first people to talk up GI, nvidia could not adopt it, because they will never accept such things as they believe in locking things into using them, their approach is in opengl (and deprecated now iirc?) and broken in d3d, which means that people do things manually. On the AMD site, it works pretty well under d3d but is rather limited in use. Under opengl I have no idea. They speak of it from time to time but its pretty much accepted as being so narrow in use that its not important for sales etc.

It also has limitations, you need to design other parts of the engine to deal with GI if you're using it on a more ad hoc basis, as such its only used in VERY VERY specific situations, i.e demos and no one really uses it in commercial/game type stuff as for most cases the loss in flexibility does not make up for the saving in geometry data unless you are using incredibly complex models and using multiple copies of the same one (try think of a valid situation that isnt high poly characters in a game). Most modeling/rendering software uses GI, however not hardware based.

Geometry shader use has taken a lot of the promise that GI had and made it more accessible and due to wider applications and better understanding it's growing in use, however only to newer cards.

 

So yeah, at the end of the day its mostly seen as a useless "nice idea"

[nbohr1more]

I see the problem.

 

There would be no way to point the shader at the source model that needs to be instanced.

 

I guess you could encode the model into a texture then use VTF or R2VB to extrude it...

 

So the process would be

 

1) Apply a texture to the entire terrain with normals to encode the first tree and other normals to encode the instance locations

2) Perform a conditional shader on the initial normals and pass them to R2VB

3) Now that we've got our Tree, perform a conditional shader on the rest of the texture

4) Process each found Normal as an Instance

 

But this shader would probably be way too long (performance wise) and the texture would be HUGE...

[OrbWeaver]

But this shader would probably be way too long (performance wise) and the texture would be HUGE...

 

Right. Which, combined with the points Serpentine made about the limited utility of GI, would make the entire exercise rather a waste of time (except for the technical curiosity).

 

If you want to produce an area with a large amount of simple trees, my suggestion would be to model the entire set of trees in a 3D application, texture them with the same material (but different UVs if required), and place them as a single object. This would allow them to be rendered using a single draw call.

[nbohr1more]

So potentially, the entire NHAT Forest could be exported and converted to on large mesh then re-imported (rather than being made of invokes for the trees in the TDM base)?

[nbohr1more]

(BTW I didn't mean to bypass Serpentine... I was composing my reply concurrent to his post apparently... )

[OrbWeaver]

So potentially, the entire NHAT Forest could be exported and converted to on large mesh then re-imported (rather than being made of invokes for the trees in the TDM base)?

 

You certainly could do this, the issues you'd have to consider are (1) whether the actual gain in performance (if any) justified that amount of time you would spend actually doing this, and (2) whether any increased performance for rendering would make up for the less efficient culling: objects are culled as a whole, so your entire forest would either be rendered or not rendered, rather than individual trees being culled.

[nbohr1more]

Maybe, when I have lots of free time... I will try this experiment.

 

Perhaps there is an optimal draw-call to culling ratio (for example, break the entire map into 8 meshes?)...

 

I should first try the simpler experiment of putting a wall at the top of the path as that is where the FPS drops like a rock... (kinda like Hadrian's Wall )...

 

Thanks for humoring my wild tangents once again.

[Mortem Desino]

NHAT's forest terrain is seperated into several models so they can be culled and visportals can close them off properly. If I replace the 8 terrain models with one large combined ASE, I kill off 5-10 more fps (the same as if it was all worldspawn).

[nbohr1more]

I thought you would chime in...

 

I also figured you would've tried all the conventional or advised options...

 

The forest idea has always been of interest to me (from a real-time 3d POV) because it's such a challenge.

 

The problem is actually well suited to things like Tessellation, GS, and other advanced geometry tricks. Too bad that these cant currently be used...

 

Out of curiosity:

 

1) Was this map created this way to be a Balls-to-the-Walls extreme test of the engine and modern hardware?

2) What was the slowest CPU that this was tested on?

3) Was this map tested on any AGP systems (I have a terrible feeling that a lot of CPU communication to the GPU is happening here)?

 

Thanks.

 

(actually I'm not sure if the first question should be directed at you or GC )

Edited June 8, 2010 by nbohr1more

[Bikerdude]

NHAT's forest terrain is seperated into several models so they can be culled and visportals can close them off properly. If I replace the 8 terrain models with one large combined ASE, I kill off 5-10 more fps (the same as if it was all worldspawn).

Hmm, this might be usefull in my cathedral map - whats culling then exactly..?

[OrbWeaver]

Hmm, this might be usefull in my cathedral map - whats culling then exactly..?

 

Model culling works by not rendering models whose bounding boxes cannot be seen through an open visportal. Turn on r_showPortals and r_showTris and look at some models through a door portal to see this in action.

[nbohr1more]

I believe this is your choice:

 

1) Make one big func_static to reduce draw calls but hope that it doesn't have too much geometry

 

or

 

2) Have lots of sub-components, like the columns, which either will or wont be rendered depending on the visportal but hope that the number of draw calls to invoke these elements doesn't choke the engine

 

The decision comes down to the size and complexity of the map or map portion. I imagine that someone with more time than myself has actually worked out the best ratio of func_static complexity to draw-calls for a select range of CPU models.

 

(as I've often said, I mostly post before thinking so take all this as a bunch of lazy guesswork)

[nbohr1more]

One last silly conjecture... (please feel free to let the crickets chirp on this one...)

 

Since we cannot acquire position data from the engine to tell the Instances where to go, we could encode vertexes with markers (like bump patterns... braille?) that would make finding them in the Vertex Buffer easier. Now this craziness depends on how reliable the Vertex Buffer Object is (which has been an area of frustration for game developer for awhile AFAIK...).

 

So the algorithm would be:

 

1) Create a terrain mesh

2) Encode vertex bumps that can be decoded for relative positional data into the mesh

3) Create a "texture" that is really just a lookup table for the codes

4) Create a texture that is encoded with a tree mesh (or extreme normal map... but the math would be, uh... complex..?)

5) Create a "Particle Effect" shader that covers a certain radius around each "bump marker"

6) When the Particle Effect is invoked it will snoop the Vertex Buffer for these bump markers

7) Once 3 markers are found, the remaining relative positions in the mesh data can be decoded from the "lookup table texture"

8) Use the mesh texture with VTF or R2VB to modify one (or all) of the marked areas in the Vertex Buffer

(even without instancing we have succeeded in creating new geometry on the GPU without pulling out a credit card and calling up John Carmack)

 

 

(optional steps, presuming we only created one tree above...)

 

9) Either generate position data codes from the original snoop data via mathematical offsets or snoop all the encoded items for positional data nearby.

10) Use step 9 for the position stream for Geometry Instancing

 

Each cluster of trees would radiate from a group of 3 markers found in the Vertex Buffer.

 

Caveats:

 

1) You would need to somehow ensure that the dmap process would not modify the geometry in the encoded areas

 

2) If the data in the Vertex Buffer is as unreliable as has been mentioned in the past, we would probably see artifacts like trees flickering in and out of existence...

 

I'm sure if someone tried this we'd get zilch but it's my compulsion to have my suspicions confirmed by outside eyes (again, let the crickets chirp on this... it's just my OCD)...

[nbohr1more]

More of my OCD nonsense:

 

It looks like someone at Doom3world went further and and implemented a shader pass that captures depth values for an entire frame into a texture:

 

http://www.doom3world.org/phpbb2/viewtopic.php?f=56&t=21576&start=0&st=0&sk=t&sd=a

 

...but I guess either method is a hack and would only be used as a last resort if Doom 3 doesn't go GPL...