Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Thu, 19 Sep 1996 19:23:30 +0100
On Sep 19, 6:13pm, Richard Gallery wrote:
> Subject: GL problem
> 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
>-- End of excerpt from Richard Gallery
=======================================================================
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:34 PDT