Thread: [Plib-users] bump maps

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

Has anyone try do bump map with plib

Larry Hess wrote:

> Has anyone try do bump map with plib

Not that I know of.

It's hard to do portably - but for some specific cards, it's not
all that hard...you could probably do it without a change to PLIB
if you have GeForce because it's just a matter of setting some state
in the pre-draw callback and undoing those changes in the post-draw.

The biggest issue is that you rarely want *just* a bump map - typically
you need a colour map also.  That gets us into the whole business of
supporting multiple texture maps - which *is* a big deal.

This is clearly something we have to address though - graphics cards
are increasingly supporting more and more sophisticated multi-pass
renderers.

In order to do this portably, I think we'll need to implement a 'shader
language'...something along the lines of SGI's new shader-compiler - which
I believe was just added to Performer.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Steve Baker wrote:
> 
> That gets us into the whole business of
> supporting multiple texture maps - which *is* a big deal.
> 

 The multitexture interfaces appear, on the surface, to be
pretty straightforward. I've played around with multitexture,
but haven't gone beyond a few very simple hacks, so I've
likely missed the messier cases. Which areas do you see as
especially problematic? 

-cks

"Christopher K. St. John" wrote:
> 
> Steve Baker wrote:
> >
> > That gets us into the whole business of
> > supporting multiple texture maps - which *is* a big deal.
> >
> 
>  The multitexture interfaces appear, on the surface, to be
> pretty straightforward. I've played around with multitexture,
> but haven't gone beyond a few very simple hacks, so I've
> likely missed the messier cases. Which areas do you see as
> especially problematic?

Things like going through *ALL* the ssgLeaf routines and
adding support for a variable number of texture coordinate
sets.

Having the lazy-evaluation ssgState mechanisms support
an arbitary number of ssgTextures per state.

Then it's basically true to say that there are exactly
zero common 3D file formats that support multiple texture
coordinates - so we'd probably have to support glTexGen
for some textures and not on others (so the number of texture
maps wouldn't necessarily equal the number of texture coordinate
sets)...

Then you get into all the complications of how maps can
affect each other.

All of this without impacting single-map performance for
existing applications any more than we absolutely have to.

So, although it's not hard to understand at the OpenGL
level, it seems to be *far* from simple at the SSG level.

However, this is DEFINITELY something we need for the
future.

-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Thread: [Plib-users] bump maps

plib-users