John Granieri (granieri++at++graphics.cis.upenn.edu)
Fri, 20 Sep 1996 10:52:23 -0400
I actually had a similar problem (a human animation library I wrote for
use in Performer, although I ultimately fixed it by removing the offending GL
calls and replacing them with appropriate Performer calls).
For a quick fix, to get it working in a Performer/OpenGL environment)
I used a simple Iris GL-stub library (stubs out all drawing, rendering
state, window, and event queue calls, and implements a software matrix stack
for all the transform-related calls), and linked it in the main executable.
That worked fine to support some old GL-based code till I could fix it
properly.
If you'd like the library, I can make it available via ftp.
-John
John Granieri
Center for Human Modeling and Simulation 200 South 33rd Street
University of Pennsylvania Philadelphia, PA 19104-6389
Voice: 215-573-3013, Fax: 215-898-0587, Mail: granieri++at++graphics.cis.upenn.edu
> Hi
>
> Perhaps some-one can suggest a fix to a problem I have.
> As I understand Performer, only the draw process is allowed
> to have a GL context, and it is not possible to make GL calls from
> another process. This appears to have been tightened up uner 2.0,
> which I have just upgraded to.
>
> I have some human animation libraries, which I have been using to
> drive human characters in our Performer app, and up till our upgrade
> recently all worked fine. Indeed, when we got our application going
> again
> under 2.0, in single process mode for de-bugging, it all works too,
> although
> quite a bit more slowly than we would like. So, then we turn on
> multi-processing, and the problem appears.
>
> What appears to happen is, that the animation libraries I use make some
> gl calls. Now, all I do with these animation libraries is tell them
> to play animation sequences, not to draw anything, i.e. they basically
> interpolate keyframes,, without displaying the result,
> and I then input the data straight into Performer DCS's in models
> in order to actually animate the geometry.
>
> Unfortunately, there appears to be some un-used but still called gl
> functionality embedded in these animation libraries, as when I
> even try to load the keyframe to interpolate I get system crashses, and
> a stack trace shows me some calls to gl stuff going on.
>
> So, I have several options to proceed, including moving all the calls
> to
> these libraries into the draw process, and using shared memory and
> semaphores to communicate back to the application (messy and time
> consuming), asking for re-compilations and re-writing of the libraries
> that give the problem (maybe not even possible, definitely on a time
> delay),
> or, finding some way to allow gl calls in my application process.
>
> The last one seems most attractive, tonight at least.
> So, anyone know if it can be done
> and how (allowing gl calls in the application process).
>
> thanks for reading all this.
>
> bye
>
> --
> Richard Gallery
> Philips Research Labs
> Cross oak Lane
> Redhill
> Surrey
> RH1 5HA
>
> 01293-815167
> fax 01293-815500
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:53:35 PDT