Paul Sherman (psherman++at++pobox.alaska.net)
Thu, 20 May 1999 12:31:37 -0800
Brian,
Yes, this is doable. I (and co-workers) have done this in a few
different instances. There are a couple of different ways to do
this and a couple of different problems to watch out for.
If you want to do openGL calls to simply draw things (the most
common example of this being in the HUD code), we found it easiest
to do this in a post-draw. I have never really experimented with
trying to do more advanced geometry in this manner. Perhaps someone
else would comment.
If you want to do a different type of render of the geometry, then
a draw-callback is the way to go. I think there was an example of
this sort for IR rendering a few years back. A method which I have
used successfully in the past is to write my own draw traversal which
calls individual pfGeoSet::draw() commands on the geometry. Custom
rendering can then be done with OpenGL and Performer calls to set
state and such. Note that you need to be pretty careful with this.
You can easily bypass Performer's CULL and DRAW optimizations, which
can drastically reduce performance. Angus already pointed out some
of the issues that you have to deal with on CULL, whereby you need
to manage your bounding spheres carefully. This method can have the
opposite problem, namely that you can completely bypass CULL, so
that all nodes get drawn. If you have a scene which would benefit
from culling, you will need to be extra careful with your bounds.
On one application that we wrote, we created our own CULL to
bitmask nodes and then the custom draw traversal used this. The
other issues which can cause you serious problems are in state and
depth sorting. These are pretty intelligent optimizations that
Performer provides for you. State sorting is crucial to performance,
and depth sorting to appearance. Again, you will need to manage all
of this pretty carefully. Trying to do a custom render this way is
not for the faint of heart. Implementation and optimization can
take many months.
The final way to do this sort of thing (and what I think that you
may need) is to construct a sub-scenegraph on the fly. At first pass,
you may make some mistakes on this, but it gets pretty easy quickly.
Find an appropriate place in your scenegraph (perfly can show you
your scenegraph tree) to add your new node or nodes and start
constructing. The nodes that you will need are pfGroup, pfSwitch,
pfDCS, pfSCS, pfGeoSet, pfGeoState and pfGeode. You may want some
flux and engine nodes too. If your new geometry is static, just
do this once. If you need to adjust it, do so in the app process. If
you need to completely alter it every frame, again, do so in the app
process. Putting your geometry into the scene has the advantage of
allowing Performer optimizations (which are very helpful). Be sure to
share materials when possible for state sorting. The best way to do
this sort of thing really depends on your openGL application and the
associated geometry. Constants in geometry go into the scenegraph,
alterations to that geometry go to the app process. Alterations to
appearance go into app or draw.
One final thing to watch is memory management. It is pretty easy to
make mistakes when creating stuff on the fly. This will be especially
apparent if you do this is a multiprocess application.
Okay, sorry for the long reply. Assuming that all of this is just as
clear as mud, feel free to contact me if there are any specifics that
I can clarify.
Paul Sherman
Periphery Consulting
psherman++at++pobox.alaska.net
Dotson, Brian W. wrote:
>
> Hi,
>
> I am trying to take an application that uses OpenGL to draw 3D geometry and
> run it within Performer.
>
> I was thinking that I could place the OpenGL drawing code within a draw
> callback, but this didn't work. The only examples I have seen are using 2D
> OpenGL commands, such as putting text on the screen or a hud.
>
> Is it possible to use 3D OpenGL commands to create a geometry within
> performer and visualize the object along with other objects that may have
> been loaded from a .flt file?
>
> Thanks in advance,
>
> Brian Dotson
> National Institute for Occupational Safety and Health
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Thu May 20 1999 - 13:35:48 PDT