Re: Vertices not moving on Onyx

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++sgi.com)
Mon, 24 May 1999 10:07:00 -0700


Joaquín Casillas wrote:
>
> "c.mottram" escribió:
> >
> > Hi, just wondering whether anyone else has had this problem, I have some
> > code to squidge objects depending on some function and the position of each
> > of the vertices, now I never had any problems with this until my latest
> > upgrade to IRIX 6.5.3.
> > Now I have anomolous situation where the code works perfectly on an O2, it
> > works fine too when I am remotely logged on to the Onyx but am displaying on
> > an O2, but if I am on the Onyx and using the Onyx's own graphics, the
> > objects stay the same shape.
> > Is there a function I have to call to tell the Onyx's graphics that the
> > geometry has changed?
> >
> > thanks in advance Chiron
> > VRCentre
> > UCL
> > London
>
> Are you using multiprocessing? If so, try setting the multiprocess mode
> to PF_APPCULLDRAW, and if it works right then you may have a problem
> with the processes not seeing the vertex list of geoset. If this is the
> problem, try using pfCyclebuffers or pfFlux node to fix the problem. I
> had similar problems in the past, when porting some code from O2 to Onyx
> platform.
>

This was my first reaction, however the symptoms seem a little different
than expected, to get this problem you'd need to use multibuffering and
NOT push changes downstream. There are situations which could cause this
like allocation your vertex data off the heap before a fork or off the
stack before sproc or fork. This could create multiple copies of the
data without the user being aware but the email suggested that this was
display oriented, so running on an ONYX2 and displaying on an O2 should
not affect the problem.

The creation of display lists on a remote display may affect the
symptoms but more likely this is a packed vertex array traversal which
relies on the display server support on ONYX2 and creates another memory
copy of the data in order to accomodate the requested packed vertex
format. It is worth exploring all possibilities.

Cheers,Angus.


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon May 24 1999 - 10:07:05 PDT

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