Kathy Loynes (kathyl++at++wormald.COM.AU)
Thu, 2 Nov 1995 18:27:29 +1100 (EST)
> When you work with pfColorTable, you getosets have to be configured as indexed
> geosets. This way, when the geoset is drawn, its colors array is not used.
> Rather, its color indices array is used to index into the colortable.
> Note that if the color component of a geoset is indexed, than all the other
> components have to be indexed either, i.e. texture coords, vertex coords and
> normals.
> Those can be indexed directly into their respective tables.
Umm, I might be totally confused but is that really the case ?? The 1.2
pfColortable man page states :
pfApplyCtab selects ctab as the current, global pfColortable. If
colorindex mode is enabled (pfEnable(PFEN_COLORTABLE)), then all
subsequent pfGeoSets will use the pfVec4 array supplied by ctab rather
than their own local color array. Colorindex mode works for both indexed
and non-indexed pfGeoSets.
This seems to be directly opposite to what you're saying. I must admit
that I have not tried using pfColortables yet but I am about to and had
come across this in the doco. My understanding was that if non-indexed
geosets were used then the values in the colortable are simply accessed
in sequential order, starting at 0.
I'm quite happy to be corrected though......
Actually, while on the subject of pfColortable usage I was wondering if
anyone could comment on the best approach for large scale geometry color
changes in a scene. I am trying to set up an application with 2 channels
showing simultaneous color & greyscale views of the same scene.
The best way seemed to be to set up 2 alternative geostate
tables (obviously using Performer 2.0 here). The color channel would
simply use the geometry colors as modelled. For the greyscale channel, I
would need to use pfColortable(s) to specify the alternative colors.
There seemed to be 2 possibilities here.
1 :
For each geoset in the scene have a specific, unique associated geostate.
Globally enable colorindex mode and then in each local geostate specify a
local colortable with exactly the same number of rgba pfVec4s as in the
geoset. The geoset would then simply use these rather than its own
modelled set of colors. I think that in this case the geosets would *not*
need to be indexed. The indexing into the colortable would be sequential
starting at 0 each time. However, I think this may be a bad approach
because of performance considerations. The number of local states would
be large (separate colortable per geoset) and the switching in real-time
would be time-consuming.
2: (I hope someone is still reading.....)
Have a single global pfColortable containing all the possible shades of grey
that may be required. Then "somehow" get the geosets to index into it.
This is where I'm getting confused. If, for example, the geoset has 3
primitives and the color binding is PFGS_PER_PRIM and I want to use the
colors in the colortable at indices 0, 1 & 2 in that order, then all is
fine. In fact I don't see why indexed geosets would be needed.
However, if I want to use the colors at indices 9, 10 & 11, it seems a bit
more complex. The geoset *would* need to be indexed. What should the indices
be though ? As I understand it the same indices are used to color the
geoset both when the colortable is enabled & disabled. If I use 0, 1, 2 then
it won't find the correct color in the colortable. If I use 9, 10, 11 then
either it will not find the correct colors when the colortable is disabled, or,
I have to use a 12 element local array as a parameter to pfGSetAttr so it
can use 9, 10 & 11 to index it.
Have I missed something very fundamental ?? Many thanks to anyone who can
shed a little light.
rgds,
Kathy
-----------------------------------------------------------------------
Kathy Loynes | Wormald Technology
kathyl++at++wormald.com.au | Advanced Systems Engineering
Ph: +61 2 9981 0611 | Sydney, Australia
-----------------------------------------------------------------------
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:00 PDT