Re: Vertices not moving on Onyx

New Message Reply Date view Thread view Subject view Author view

Don Hatch (hatch++at++hell.engr.sgi.com)
Mon, 24 May 1999 18:16:45 -0700


Note that on IR, perfly (and your perfly-derived program)
will use display lists for geosets by default, see the following in perfly.c:
    ViewState->drawMode = (iR ? DLIST_GEOSET : DLIST_OFF);
You can force this off using the -T option in perfly,
or hit the 'i' key at runtime (not sure how robust this is).

You can change the default in your program,
or, if you want your loader to work with perfly,
you can do this:
        geoset->setDrawMode(PFGS_COMPILE_GL, PF_OFF);
However, note that if you just do this in the loader,
perfly will undo it in its pfuTravSetDListMode() traversal
based on ViewState->drawMode :-(
I've worked around this by explicitly making the call every frame
in an APP callback attached to the scene or the geode in question.
(I'm not sure whether it would work if you only do that on the first frame,
since it looks like there is some latency inherent
in perfly's handling of this stuff).

Don

On May 24, 11:05am, Angus Dorbie wrote:
> Subject: Re: Vertices not moving on Onyx
> OK, what about display lists?
>
> There's very little else can go wrong here. Performer does not copy your
> data. If you 'compile' a display list the gl makes a copy, otherwise
> your data is drawn in immediate mode, what you have in memory is what
> you get drawn.
>
> One problem already suggested is multiprocessing creating copies of your
> data because you create the array before the call to pfConfig.
>
> You'll have to figure out which of the above is going wrong.
>
> A useful test would be to run in single threaded mode to see if this
> fixes the problem. There is a simple command line option for this in
> perfly.
>
> Cheers,Angus.
>
>
> c.mottram wrote:
> >
> > Checking it out, the scene loader is basically perfly.C with some bits added
> > to add my own data to each object, the call
> > if(PackedAttrFormat)
> > {
> > pfuTravCreatePackedAttrs(scene, PackedAttrFormat, 0x0);
> > }
> > is pretty definately not made, assuming that is, that this is the bit which
> > would pack the arrays.
> > The object files are Inventor files,
> > the only other thing I do is add a node above each object to move them around.
> > Copies I make of the objects while they're moving, show the distortion I
> > would have expected, but are again static.
> >
> > cheers & tanks Chiron
> >
> > At 09:56 AM 5/24/99 -0700, you wrote:
> > >Did you compile your geometry to display lists, or perhaps traverse it
> > >to packed arrays so that your original data representation is not the
> > >one being drawn?
> > >
> > >Cheers,ANgus.
> > >
> > >
> > >c.mottram wrote:
> > >>
> > >> 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
> > >>
> > >> -----------------------------------------------------------------------
> > >> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > >> Submissions: info-performer++at++sgi.com
> > >> Admin. requests: info-performer-request++at++sgi.com
> > >
> > >--
> > >"Microsoft's system was like a forest that hadn't had a controlled
> > > burn in decades, just waiting for one person with a match to turn
> > > it into a disaster. Melissa was Microsoft's fault. They left their
> > > system wide open to this sort of abuse, they knew it could happen
> > > and did nothing." -- Bruce Perens
> > >
> > >For advanced 3D graphics Performer + OpenGL based examples and tutors:
> > >http://www.dorbie.com/
> > >
> > >
> >
> > -----------------------------------------------------------------------
> > List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> > Submissions: info-performer++at++sgi.com
> > Admin. requests: info-performer-request++at++sgi.com
>
> --
> "Microsoft's system was like a forest that hadn't had a controlled
> burn in decades, just waiting for one person with a match to turn
> it into a disaster. Melissa was Microsoft's fault. They left their
> system wide open to this sort of abuse, they knew it could happen
> and did nothing." -- Bruce Perens
>
> For advanced 3D graphics Performer + OpenGL based examples and tutors:
> http://www.dorbie.com/
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Angus Dorbie

-- 
Don Hatch  hatch++at++sgi.com  (650) 933-5150  Silicon Graphics, Inc.

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon May 24 1999 - 18:16:49 PDT

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