c.mottram (ucftchr++at++ucl.ac.uk)
Tue, 25 May 1999 13:53:10 +0100
geoset->setDrawMode(PFGS_COMPILE_GL, PF_ON); effectively stopped it and
didn't seem too slow, though the documentation says it is ( how slow is
slow, these were objects with only 2000 odd polygons).
So this is all very satisfactory, with a few more options to play with, many
thanks again.
I think, the real problem was my upgrade to Performer 2.2, where I tacked in
my code to a newer version of perfly.C without really looking at or
understanding the differences, "act in haste, repent in leisure" or some
similar aphorism!
Chiron
At 06:16 PM 5/24/99 -0700, you wrote:
>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.
>-----------------------------------------------------------------------
>List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
>
This archive was generated by hypermail 2.0b2 on Tue May 25 1999 - 05:53:32 PDT