Re: [osg-users] StateAttribute comment clarification

On 2/9/07, Paul Martz [EMAIL PROTECTED] wrote: In in here it masks out all but StateAttribute::OVERRIDE StateAttribute::PROTECTED so only these have meaning in the case of attributes. Yes, but setAttributeAndModes() handles the case where the override value is INHERIT (by removing the

Re: [osg-users] osgviewer threading model control and stats report

Hi André, On 2/9/07, André Garneau [EMAIL PROTECTED] wrote: FYI: I have double-checked this today and this is not an issue. The new NVIDIA worker threads will only appear on the first wglMakeCurrent() of newly created OSG graphic threads. It would complicate code, but perhaps one way to

[osg-users] Meshes being loaded facing the wrong way?

Hi all, I'm new to OSG and have a question. In a modelling program my mesh has its fore-aft axis long the Z axis, with +Z being forward. When I load it into an OSG scene with the camera at 0,0,500, looking towards the origin where the mesh is, rather than seeing the front of my mesh I'm

[osg-users] Problem with computeIntersections and DO_NOT_COMPUTE_NEAR_FAR

I have a problem with computeIntersections, which I am using to see if I pick an object or not. The problem is that it is not working when I set the setComputeNearFarMode to DO_NOT_COMPUTE_NEAR_FAR using the following code and at the same time use anaglyphic stereo.

Re: [osg-users] Problem with computeIntersections and DO_NOT_COMPUTE_NEAR_FAR

Hi, I know why there is a difference in behavior between the two different ways of settings DO_NOT_COMPUTE_NEAR_FAR. In principle the results should be the same. Try putting some debugging messages in the computerIntersections method to see what projection matrix it is used in each case, this

RE: [osg-users] StateAttribute comment clarification

I don't think we need to change the API. I just want to make sure the comment in the code is right, because it didn't match my understanding of how these values are used. What confused me in the comment was the statement that OFF applied to attributes, because I don't think OFF applies to modes,

RE: [osg-users] osgviewer threading model control and stats report

Hi Robert, That seems like a sensible approach as it would avoid the issue altogether, at the expense of a little bit more code to properly handle the threading model transitions. André -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield

Re: [osg-users] StateAttribute comment clarification

Hi Paul, On 2/10/07, Paul Martz [EMAIL PROTECTED] wrote: I think what we have is as follows: * OVERRIDE causes a parent node's attribute/mode to override child settings of the same attribute/mode, unless the child's attribute mode is PROTECTED. * PROTECTED applies to attributes and modes as

Re: [osg-users] osgviewer threading model control and stats report

Hi André, On 2/10/07, André Garneau [EMAIL PROTECTED] wrote: That seems like a sensible approach as it would avoid the issue altogether, at the expense of a little bit more code to properly handle the threading model transitions. I was afraid you'd say that :-) Right now I'm juggling way too

Re: [osg-users] changing the node in viewer.setDataScene

On 2/8/07, Paul Speed [EMAIL PROTECTED] wrote: elekis wrote: hi all I have a little probleme, I have two node who represent two differents things, and I would like to render one, and afer pushing a touch, changing on other something like that //init osg::Group* root = new

RE: [osg-users] osgviewer threading model control and stats report

Hi Robert, That seems like a sensible approach as it would avoid the issue altogether, at the expense of a little bit more code to properly handle the threading model transitions. I was afraid you'd say that :-) :-) Right now I'm juggling way too many balls to tackle this, or to help out