Eric, I believe that you have hit the nail on the head. My misuse of OSG::MatrixFrustum() caused me some headaches a couple of weeks ago, but I thought I had it fixed. After doing more careful tracing through the code path for OSG::RenderTraversalAction(Base), I think that my use of OSG::MatrixCameraDecorator (and consequently OSG::MatrixFrustum()) appears to be biting me. I may have to go back to the design drawing board to get this sorted out. Thanks for the tip.
-Patrick Eric Maslowski wrote: > 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/ -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
