Marcus (giraffe.asd.sgi.com!sgi.sgi.com!uunet.uu.net!multigen!Marcus)
Fri, 11 Aug 1995 13:54:27 PST
Creating a new material here is unneccesary. This code snippet
is actually a memory leak.
> mtl = pfGetGStateAttr(pfGetGSetGState(
> pfGetGSet(pgeode, 0)), PFSTATE_FRONTMTL);
>
>4) Modify mtl, and then place it back into the *pfGeode:
>
> pfMtlColor(mtl, PFMTL_EMISSION, 1.0f, 0.0f, 0.0f);
> pfGStateAttr(pfGetGSetGState(pfGetGSet(pgeode, 0)),
> PFSTATE_FRONTMTL, mtl);
Rebinding the material to the geostate here is also not needed.
The one you previously got and modified is still bound.
>This method has worked well when working with Inventor
>objects loaded into Performer. However, I found that this
>does not work with OpenFlight format objects. The problem
>is that every object loaded with LoadFlt acquires the changed
>material properties.
This is because the .flt file you are loading has zero or one
materials referenced by polgygons. In the case of zero material
references, the loader creates a default material that is used
throughout.
>In the above case, all .flt objects start to glow red, when I
>only wanted one of them to.
Naturally, since there is only one material in the scenegraph.
The loader's statistics output will so as much ...
>When I looked at the LoadFlt documentation, I found the
>following statement:
>
>"-the converter assumes that all .flt files use the same material table"
>
>Aside from the obvious question of why the loader makes
>this assumption, can anyone give me a hint on how to work
>around this problem?
>
Sorry ... this is actually a old and obsolete statement from
README.SS.<blah> that has _not_ been true since Performer 1.0
... I think (before my time). I've cleaned up the README.FLT.R14_2
file for Performer 2.0.
Each OpenFlight file has an internal palette of 64 material
definitions that are (possibly) referenced by polygons. The
materials are used properly on a per file basis. In order for
you to do what you want, you'll need to create and reference
unique materials for each polygon in the database. As a
run-time hack you must traverse each geoset of interest
and create a copy of its geostate, bind a new material to the
copy, and then bind the new (copied) geostate to the geoset.
Having done all this ... you will gain control of materials on
a per geoset level at the expense of draw performance.
Regards,
Marcus Barnes, Member Technical Staff
MultiGen Inc., 550 S. Winchester Blvd. Suite 500, San Jose CA, 95128
PH: 1-408-556-2654 FX: 1-408-261-4102
EMAIL: multigen!marcus++at++uunet.UU.NET
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:46 PDT