RE: [Algorithms] Effective usage of multitexturing

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Sorry, some confusion over terminology. The wayI'm using it:

"Material" = the whole state of the chip when rendering any particular type
of effect. Not closely related to the "material" used for lighting equations
(though obviously one includes the other).

"render state"/"render sub state" = one of the things you change with calls
like SetRenderState, SetTextureStageState, etc.

So yes, definately sort by material, and then by texture, but there's not
much point in reordering things to try to change _fewer_ individual render
states - in general video drivers either re-think through the whole
rendering pipeline (doing the translation from API state to hardware state),
or they don't do any changes. There's not much to be saved by only updating
a few renderstates - it's almost as expensive as updating them all.

I think the use of "render substate" is to emphasise that we're talking
about individual states, not the state of the renderer as a whole.

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: Dan Thompson [mailto:da...@cs...]
> Sent: 14 August 2002 04:19
> To: Gdalgorithms-List@Lists. Sourceforge. Net
> Subject: Re: [Algorithms] Effective usage of multitexturing
> 
> 
> I think i missed some messages along the way, but from what 
> I've heard, you
> *should* sort by renderstate, then material. So what exactly 
> is this render
> (sub)state you people are talking about? Is the (sub) 
> something signifigant?
> Or am I reading you right in that you should set the 
> renderstate whenever
> you need it and just avoid calls to SetMaterial(for D3D, and 
> I've forgotten
> the GL equivilant) and SetTexture?
> 
> If I remember there were some NVidia slides at one of the big 
> conferences
> (forgot which one) that was suggesting avoidance to SetRenderState.
> 
> -Dan
> 
> 
> ----- Original Message -----
> From: "Tom Forsyth" <to...@mu...>
> To: "Chris Kline" <ck...@ir...>; 
> "Gdalgorithms-List@Lists.
> Sourceforge. Net" <gda...@li...>
> Sent: Tuesday, August 13, 2002 11:27 AM
> Subject: RE: [Algorithms] Effective usage of multitexturing
> 
> 
> > > Are most people sorting based on render (sub)state, or just
> > > grouping by
> > > material object?
> >
> > Just material object. All finer states (apart from texture) 
> are ignored.
> > What I mean is that we sort by material object, then within that by
> texture.
> > Our material object includes the concept of texture type (cube map,
> > dimensionality, etc) and number (single, dual texture, 
> etc), but not the
> > actual textures themselves. So multiple objects can share the same
> material,
> > without actually sharing the same texture.
> >
> > > I think there's a point (in terms of unique
> > > material and
> > > object count) at which the benefit of fine-grained sorting is
> > > swamped by the
> > > overhead of doing it, but I'm not sure what that cost-benefit
> > > graph looks
> > > like.
> >
> > It's pretty sharp! Something that I know from my 
> driver-writing days that
> > has since been confirmed by many current driver writers is 
> that changing
> one
> > renderstate is frequently the same cost as changing many 
> (call overhead
> > aside). So sorting my sub-render-state is fairly pointless. 
> It's just a
> lot
> > more work, and you're not actually saving driver-thinking 
> or hardware
> setup
> > cycles. Obvious exceptions for changing things like 
> alpha-test reference
> > values and other continuous parameters.
> >
> > > Anyone have any anecdotal (or empirical) evidence on this?
> > > Has fine-grained
> > > sorting met a similar fate to BSP-based rendering in 
> light of modern
> > > hardware?
> >
> > Yes. In D3D we have the concept of state block macros, 
> which encapsulate
> > arbitrarily large amounts of graphics state. Many people 
> are now using
> them
> > to "store" the whole of a Material Object state, and they just call
> Apply()
> > on that. In OpenGL you have the similar (but even more 
> flexible) idea of
> > display lists. There's a good case for capturing the whole 
> renderstate
> > malarky in a single display list, one for each material 
> object. There's
> > potentially a lot of driver optimisation that can be done 
> on one of those.
> >
> > > > No inter-dependence (or if there is some, it is handled
> > > internally).
> > >
> > > So would you use a push/pop system and reset back to the
> > > default state prior
> > > to Apply() the next state object, or use
> > > test-and-optionally-set checks
> > > inside Apply()?
> >
> > Neither. As said above, just dump the entire (appropriate) 
> state into a
> > state block / display list. The driver can convert this to 
> native DMA
> > commands, and suddenly at no stage are you doing the 
> renderstate->hardware
> > conversion process, which is typically what takes most of 
> the time. The
> > driver just throws DMA command streams at the hardware.
> >
> > > > That way, when the graphics coder changes any implementation,
> > > > they know it's not going to break anything else in the game.
> > >
> > > Except perhaps performance :)
> >
> > Au contraire!
> >
> >
> > 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: Chris Kline [mailto:ck...@ir...]
> > > Sent: 13 August 2002 19:14
> > > To: Gdalgorithms-List@Lists. Sourceforge. Net
> > > Cc: Tom Forsyth
> > > Subject: RE: [Algorithms] Effective usage of multitexturing
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tom Forsyth [mailto:to...@mu...]
> > > >
> > > > The "ideal" solution would be to use a mixture. Use and 
> allow type 2
> > > general
> > > > shaders, but then near the end of the project, start
> > > hand-optimising the
> > > > particular cases that are used most often, and
> > > hand-optimise them (and the
> > > > fallback paths) for each platform.
> > >
> > > Agreed. I wish there was off-the-shelf type-2 solution
> > > available right nowI
> > > just don't have the time (or the compiler experience) to roll
> > > my own. Maybe
> > > Stanford will release their implementation sometime.
> > >
> > > > This requires a "cost-o-meter" so that artists know roughly
> > > how expensive
> > > > each shader will be on the target platform, and may in fact
> > > need multiple
> > > > cost-o-meters, one for each platform. For example, 
> something that
> > > > is trivial on the XBox (e.g. a "convert texture to
> > > monochrome" shader) may
> > > > be extremely expensive on the PS2, and vice versa.
> > >
> > > Good point; I hadn't thought of that. If your material 
> setup tool was
> > > running in-engine, you might be able to gather this info 
> as an on-line
> > > process. By disabling certain capabilities you could
> > > approximate target
> > > platform hardware, and you could automate this for the
> > > artists by providing
> > > them with target profiles that would automate the 
> enabling/disabling.
> > >
> > > > But more complex things like anisotropic lighting, cell 
> shading, etc
> > > require
> > > > actual coding, and there are few artists that want to hit
> > > the metal like
> > > that.
> > > > So either way, you need a coder getting in there and coding
> > > stuff up.
> > >
> > > Right. I imagine that the "layer" library available to the
> > > artists would
> > > include pre-written FX shaders.
> > >
> > > > For the next game we're probably going to have a simple
> > > layers system, but
> > > > no more than two or three layers, and usually only one. <...>
> > > > Each material type will be custom-coded by a coder to 
> work on the
> > > > various platforms and the various fallback paths (on the PC).
> > >
> > > This is similar to what I had been thinking I would do,
> > > basing the material
> > > system around "effects" instead of layers. E.g., the artist
> > > chooses the "Env
> > > Map with Bump mapping" effect, or the "dual-texture" effect,
> > > then sets the
> > > input parameters.
> > >
> > > This is the way that Renderware and (IIRC) NetImmerse have
> > > structured their
> > > material systems, probably (as you said) because it's
> > > controllable in a
> > > cross-platform product.
> > >
> > > > The most important thing is to encapsulate all your
> > > rendering  pipeline
> > > state
> > > > into a single thing (e.g. a class) that you can call
> > > Apply() on, and the
> > > > entire pipeline is now set up. <...>
> > >
> > > Are most people sorting based on render (sub)state, or just
> > > grouping by
> > > material object? I think there's a point (in terms of unique
> > > material and
> > > object count) at which the benefit of fine-grained sorting is
> > > swamped by the
> > > overhead of doing it, but I'm not sure what that cost-benefit
> > > graph looks
> > > like.
> > >
> > > Anyone have any anecdotal (or empirical) evidence on this?
> > > Has fine-grained
> > > sorting met a similar fate to BSP-based rendering in 
> light of modern
> > > hardware?
> > >
> > > > No inter-dependence (or if there is some, it is handled
> > > internally).
> > >
> > > So would you use a push/pop system and reset back to the
> > > default state prior
> > > to Apply() the next state object, or use
> > > test-and-optionally-set checks
> > > inside Apply()?
> > >
> > > > That way, when the graphics coder changes any implementation,
> > > > they know it's not going to break anything else in the game.
> > >
> > > Except perhaps performance :)
> > >
> > > -chris
> > >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: Dice - The leading 
> online job board
> > for high-tech professionals. Search and apply for tech jobs today!
> > http://seeker.dice.com/seeker.epl?rel_code=31
> > _______________________________________________
> > GDAlgorithms-list mailing list
> > GDA...@li...
> > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=6188
> 