From: Paolo Farinelli (paolo++at++sgi.com)
Date: 05/22/2003 18:57:07
Hi Adam,
I am assuming that if you remove the partially transparent faces from
your model, then everything looks correctly from all angles. right?
If so, my guess is that you have a problem with z-fighting and incorrect
rendering order of your base polygon and your light-map polygon.
What I think is happening is that:
1. the light-map polygon is rendered first
2. the panel geometry is rendered second; the displacement offset you
mentioned is probably too small in some situations (depends on the
viewing angle, depth buffer precision, absolute distance from eye and
near and far settings) and the console geometry is not drawn because
of z-fighting.
If your console geometry is completely opaque, this shouldn't happen,
as Performer will render all opaque geometry before any transparent
geometry is drawn.. so I am guessing that your console geometry is
being treated as transparent..
If your console geometry is really not transparent, then your problem
may be something you are doing within creator that is making the
Performer flt-loader believe that it is transparent, like for example:
setting 4-valued vertex or material colors, or mapping a 4-component
texture.
If your console geometry actually is (and needs to be) transparent, you
will have to ensure that the light-map is rendered after the console
geometry. Performer sorts all geometry in the transparent bin and
renders back to front, so it will get it right most of the time, but
sometimes it will get it wrong depending on your view position (this
seems to be what is currently happening)..
I can suggest a couple of ways to fix this:
1. In creator, you can make the light-map geometry be a child of the
console geometry (I think creator calls them subfaces, but I'm not sure).
This should translate to a pfLayer node when loaded, and should
render correctly.
2. A software solution could be that of traversing the loaded model
and placing all lightmap geometry into a user created pfDrawBin.
You can then ensure that this geometry is rendered after the other
transparent geometry is rendered (take a look at the man page for
pfChannel::setBinOrder, etc ).
3. A more hacky approach (that I've successfully used in the past) is based
on the knowledge of the way in which Performer sorts its transparent
geometry.
Basically, sorting takes place at the pfGeoSet level, and all that is
relevant
is the distance from the eyepoint to the center of each geoset.
So by adding a 'dummy' triangle to your console geoset you can force its
bounding box center to be wherever you want..
For example, within creator, you could add a triangle of very small size
(and completely transparent) positioned it at some distance behind the
console.
Depending on exactly how your scene is set up, and the range of different
angles from which the console needs to be visible, you may or may not be
able to get this to work..
Hope this helps!
Let me know if you need further assistance.
Regards,
Paolo
Adam Grossman wrote:
> Hi,
> I'm working on a visual model using Multigen Creator, followed by
> conversin to .pfb using pfConv. There is one section of a display
> console that is givingn us some trouble. We've used single
> (rectangular) polygons with partially transparent face materials to
> simulate lights on the panel, and these are controlled by Switch
> nodes. The faces simulating the lights are also offset from the plane
> of the console by 0.001 db units (should be 1 mm). The problem comes
> when we try to look at the geometry inside the simulation from
> different angles. It seems that at some angles, these partially
> transparent faces (alpha is about 0.5) also provide a window through
> the geometry directly behind it, and you can see the rest of the scene
> instead of the face with its texture underneath the light. We're using
> pfConv from Performer 2.2.11 (for compatibility reasons for other
> software), and Performer 2.5.2 for Linux. The Linux box contains 2
> Xeon 3.06 GHz chips, nVidia Ti4800 graphics chip and the latest nVidia
> driver (downloaded yesterday).
> I'd appreciate any suggestions you may have.
> Many thanks,
> Adam
>
> ---------------
> Adam Grossman
> Research Assistant & Simulations Developer
> Simulation & Modelling for Acquisition, Rehearsal and Training
> Defence R&D Canada Toronto
-- Paolo Farinelli paolo++at++sgi.com Member of Technical Staff, OpenGL Performer 1-650-933-1808 Silicon Graphics 1600 Amphitheatre Pkwy, Mountain View, CA 94043
This archive was generated by hypermail 2b29 : Thu May 22 2003 - 18:57:17 PDT