Re: Rendering OpenGL in draw call back

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Wed, 17 Feb 1999 18:11:46 -0800


Brian Corrie wrote:
>
> I have a pfProblem. We have some code, written in OpenGL, that does some
> fairly sophisticated rendering (mulit-pass reflections etc). Rather than
> re-writing the code in Performer, I want to integrate it (as OpenGL) into the
> Performer scene graph. Although I haven't found any documentation on this type
> of thing, things like the Performer Volumizer node do this. Some of Angus's
> stuff at dorbie.com do similar things but not in the scene graph environment...

My examples on www.dorbie.com are in the scene graph environment. The
OpenGL is primarily used in draw callbacks on scene graph nodes to
modify state not directly supported in pfState. The examples ues other
tricks and a favourable wind for resolving ordering issues.

>
> My idea was that I would subclass a pfGeode (with no geometry) and insert the
> OpenGL rendering code in the draw call back. Thus my OpenGL would get called
> with the appropriate transformations etc. from the scene graph applied. Seemed
> to make sense to me... I have gone one step further and implemented it as a
> database loader so I can use the node in any Performer app. Brilliant I
> thought! (like most of my brilliant ideas, things are looking a bit dim at the
> moment 8-)

Sounds good to me except that any pfState on the geoset node may clobber
whatever you set in the pre draw callback. Also make sure you use pf
calls to modify performer state or at least restore state after you've
had your wicked way with the pipeline. Otherwise you may confuse
performer state management. It's deliberately lazy about state changing
to save time so performer does it's own state tracking. There are also
some things which you can't currently do like turning lights off using
performer methods.

>
> My question/problem is twofold:
>
> 1) The above doesn't work... yet. I have a simple geometry that I am using as
> a test (a simple room environment). My shading doesn't work. I have tried
> everything that I can think of (although I am not a pfExpert), but in three
> different Performer apps (perfly, my own code, and Avocado (a VE environment
> from GMD in Germany)) I get three different results. I can't seem to turn off
> the Performer geostate/lightmodel/whatever so that whatever app I use seems to
> have some sort of an effect on my OpenGL. I have tried creating a GeoState in
> my subclassed node and doing a gstate->setInherit(0) and then set up the
> GeoState that I want. I have tried setting up the state in the draw callback
> with OpenGL. Nothing seems to work. I can't seem to get rid of the Performer
> state in its entirety. I would like to say something like:
>
> draw() {
> pfGoAway()
> do_opengl()
> pfComeBack()
> }
>
> I have tried using pfPushState, glPushAttrib, and the appropriate
> glEnable/glDisable calls in the Draw callback. I am confused 8-( So am I doing
> something fundamentally wrong? Or am I missing something simple (the most
> likely case 8-)? Has anyone done such a thing before? I think it is pretty
> clear that I don't have a firm grasp of the entire Performer state machine and
> how shading info is inherited. What am I missing???
>
> 2) Even if I do get the above going, will I ever be able to do multipass
> things in the draw callback with OpenGL (sounds dangerous!!!)? Am I asking too
> much? I didn't think so and it seem like such an elegant solution to my
> problem.
>
> Any comments or suggestions would be greatly appreciated!!!
>
> Thanks in advance,
>
> Brian
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com

-- 
"Only the mediocre are always at their best." -- Jean Giraudoux

For advanced 3D graphics Performer + OpenGL based examples and tutors: http://www.dorbie.com/


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Wed Feb 17 1999 - 18:11:55 PST

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.