Hi Patrick, I may be missing the overall question, but we've run into some frustum problems (see below) and have tracked down it's assignment to the camera decorators. More specifically, MatrixFrustum(). I can't say whether this is the same place the frustum is set for intersection tests, but hope it helps with your search.
Previous frustum problems: http://www.mail-archive.com/[email protected]/msg08487.html Cheers E. --- Eric Maslowski Research Computer Specialist University of Michigan 3D Lab Autodesk 3D Studio Max Certified Trainer email: [EMAIL PROTECTED] office: 734-615-9699 mobile: 734-730-9904 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Hartling Sent: Thursday, October 18, 2007 19:03 To: users Subject: [Opensg-users] Frustum disparity between OSG::RenderTraversalAction instances in cluster scenario I have been digging more into the problem that I described in a message that I posted last week (subject "OSG::Group core and clustering oddity"), and I have ruled out OSG::Group and its subclasses being a factor. I don't think there is anything about PyOpenSG that is causing the problems, either. My current suspicion is that I need to do some more work in the C++ render server application, and the lead I am following now has to do with OSG::RenderTraversalAction and how its frustum is set up. In my client GUI, I have a valid frustum in the OSG::RenderTraversalAction instance, and everything renders well. In the render servers, however, the OSG::RenderTraversalAction frustum has near and far planes that seem totally unrelated to what is being set up on the client side. In particular, the far plane appears to be invalid with a normal of the form [nan, nan, nan] and a distance from the origin of -inf. I understand that OSG::RenderTraversalAction is not a field container, and I am creating the instances manually on both ends of the communication channel. However, I am not doing anything directly that sets the frustum for an instance of OSG::RenderTraversalAction, and I don't know how it gets set. Not knowing this is making it hard for me to figure out why the render servers have what seems to be a completely bogus frustum. How is the frustum supposed to get set? I have been tracing through the code when the traversal action is applied to the scene graph, and I see where the frustum is used for intersection testing. What I have not yet seen is where, how, or when that frustum is set. Is this something that I should be doing in my render server code based on information that is received from the client GUI via the scene graph sharing? -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
