From: Alexandre Naaman (naaman++at++laplace.engr.sgi.com)
Date: 09/08/2004 11:43:22
Hi Alexander,
> We've already implemented a Cg binding in our VR framework Avango (which
> also features a Performer renderer). A crucial think I observed is a
> tight integration of Geometry AND Shaders. For performance reasons it is
> obvious to use pfGeoArrays, but I think they have a rather clumsy
> interface in Performer. There should be more helper functions to cope
> with them. Say for example when you want to generate binormals and
> tangets for a geometry in a pfGeoArray or when trying to rearrange the
> vertices in a cache friendly way, things get really complicated if you
> want to do this in a general manner. When a pfGeoArray is being shaded
> by a GLSL shader (or Cg), the attributes must be bound to the location
> the shader expects them. Maybe there could be some clever way to match
> them.
I agree, the interface for pfGeoArrays _was_ clumsy.
But that was before, and things will be different in 3.2.
You see ... we completely re-wrote the interface for geo arrays in 3.2 and
now it will be possible (in many cases) to write code that thinks it's
using geosets but in reality is using geo arrays. Let me give you an
example...
if in the past you did something like:
pfGeoSet *gSet = new pfGeoSet();
gSet->setAttr(PFGS_COORD3, PFGS_PER_VERTEX, vertices, inds);
gSet->setAttr(PFGS_TEXCOORD2, PFGS_PER_VERTEX, texCoords, inds);
then with 3.2 you'll be able to do:
pfGeoArray *gArray = new pfGeoArray();
gArray->setAttr(PFGS_COORD3, PFGS_PER_VERTEX, vertices, inds);
gArray->setAttr(PFGS_TEXCOORD2, PFGS_PER_VERTEX, texCoords, inds);
pfGeoSet::setMultiAttr(), most of the ::get(Multi)AttrXXX(), et al will
also work transparently with pfGeoArrays in 3.2.
That being said, you'll no longer be required to do the ::queryAttrType()
stuff. Instead you can just do ::setAttr(), or if you want call
addAttrType(). When you do a setAttr() of a new type (PFGS_COORD3,
PFGS_TEXCOORD2, etc ...) a pfVertexAttr will automagically get created for
you and then you can (at a later time) query home many attrs exist, what
their names are, etc ... The newer interface should be *A LOT* easier to
use.
Note that the biggest issue with going from GeoSets to GeoArrays remains
that if you have more than one set of indices for your data then we have
to unroll everything, and that piece of code is still to be written. Also,
for geo arrays indices are stored as unsigned ints, not unsigned shorts
(as they are for geosets).
In terms of arranging vertices in a cache friendly way, we realize that
this is an issue and have a new pseudo-loader (and some pfd functions) for
doing exactly this kind of thing and it will be avaialble in 3.2. In
addition we're also working on some other caching schemes which (and that
won't be as exposed to the users as pfd functions) which we hope will
bring us additional performance gains when using geo arrays.
> Regarding parameters there should be some possibility to access the
> current PF viewmatrix (without having to invert and post-rotate it!),
> current model matrix and alike in the shaders. Maybe there could be some
> special functions in pfGProgramParams to bind the current model matrix
> (normal, transposed, inverted, inverted transposed) and so on to named
> parameters.
There's little doubt that with the following version of Performer (3.3) we
will be spending quite a bit of time on these kinds of issues. For now
we're pleased with providing the hooks to use this stuff but we need (and
will) spend much more time dealing with usability issues in the future.
Spending some time trying to see how RenderMonkey uses shaders has been
very useful in that respect ...
> I really appreciate the hard effort you put into the integration of
> these techonlogies as it's often more difficult to bring them into an
> exisiting system than designing a system (using these technologies) from
> scratch like NVSG.
No doubt about it! :)
A+,
Alex.
This archive was generated by hypermail 2b29 : Wed Sep 08 2004 - 11:44:47 PDT