RE: [Algorithms] dynamic scene graphs with non-object information

[Tom F. <to...@mu...>]

Indeed. In real-world systems, "just slapping an env map on something" is a
pretty complex operation. You need to try about five different possible
blend modes, each of which works on different bits of hardware. On some
hardware you need to fall back to a multipass version. It requires extra
computation and vertex info, as you say.

If you apply an env map, you frequently need to be able to determine how
bright that map is. Ideally, you would use a gloss map and hold that in the
alpha channel of the base texture, but if the texture is alpha-blended, you
can't use the alpha channel that way. And of course if you don't have
multitexture hardware then you just can't do this - you have to go with a
uniform brightness. And if the base texture is alpha-blended, then a
multipass env map is not going to work without mucking around with Z-compare
values (EQUAL works most of the time). So that Z-compare change has to be
factored into your laziness graph.

If your underlying material is a detail map, then on most hardware you've
just run out of textures. The Radeon can apply all three at once, but other
cards need two or three passes, again with many variations of the allowable
blend modes in those individual passes, and again changing vertex types
accordingly.

So being able to propogate the "apply env map" instruction down a tree seems
to have zero real use in reducing state changes - in practice you need to
have figured out all the possible combinations of material at start of day
according to what the hardware can do, and the actual degree of laziness you
can apply between two given states relies so much on the underlying hardware
that unless you are going to use some really cunning heuristics to
reorganise the tree according to the hardware, any graph of material types
(aside from the simplest "same"/"not same" links) is just not going to be
useful.

Well, that's my experience, anyway. I would _love_ a tree to be useful - it
would help cut down state changes a lot - but in practice it just isn't.

The most laziness I do is same/different laziness, and also some laziness
when setting up chunks of state such as alpha-blend mode, Z-compare mode and
discrete things like that. And all this is runtime same/different laziness
as and when the states come in - it's not any sort of graph-directed
laziness.


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.



> -----Original Message-----
> From: Shane Stevens [mailto:sh...@bl...]
> Sent: 17 January 2001 23:04
> To: gda...@li...
> Subject: RE: [Algorithms] dynamic scene graphs with non-object
> information
> 
> 
> Not to mention the fact that inserting renderstates and 
> multiple textures
> ultimately has to affect your vertex data in the object nodes.  Not to
> mention there night be specific code needed per vertex.  Imagine just
> whacking an environment map state above everything in your 
> world.  You then
> have to add extra UV's and code to handle the environment 
> mapping.  Doing it
> generally is going to slow you down baaaaaad...  I personally think an
> object based scene graph is pretty good but generalising it 
> too much more is
> ultimately going to hurt you when it comes to raw poly throughput.
> 
> Just my opinion of course...
> 
> Shane
> 
> 
> Shane Stevens
> Lead Programmer
> bluetongue
> www.bluetongue.com