2 problems: view culling and shared memory

New Message Reply Date view Thread view Subject view Author view

Kenneth B Russell (kbrussel++at++media.mit.edu)
Wed, 28 Jan 1998 01:21:37 GMT


Hello Performer gurus,

I've run into a problem in both Performer 2.1 and 2.2 with tall
GeoSets getting culled inappropriately; usually when the bottom
of the geometry is being viewed and the top extends off the top
of the screen. Turn off culling entirely fixes the problem but
slows down our application considerably. I just tested the VRML
files in question in perfly using the OpenWorlds VRML 2.0 loader
(instead of our custom one), and I don't see the problem. Has
anyone encountered this before? In our app, we're just using the
default (dynamic) bounding volumes, and don't have any node
callbacks for the cull process. We move the camera by calling
pfChannel::setViewMat, and I'm pretty sure our camera matrix is
okay.

The second issue is with modification of a data structure which
was used as an argument to pfNode::setTravData. The data
structure was allocated in shared memory using pfMalloc and I
have verified the arena is not NULL, pointer is okay in both APP
and DRAW processes, etc. However, if I modify the data structure
in the APP process after calling setTravData, the modifications
are not visible in the DRAW process's node callbacks. Since
setTravData doesn't take as argument the size of the user data
structure, I assumed it was storing a reference rather than a
copy (and in fact, the pointer has the same value in the APP
process and DRAW node callback). Where did I go wrong?

Thanks very much,

-Ken

__________________________________________________________________________
Kenneth B. Russell Synthetic Characters Group, MIT Media Lab
kbrussel++at++media.mit.edu http://www.media.mit.edu/~kbrussel
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:56:37 PDT

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