Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-22 Thread Robert Osfield
On Wed, Apr 22, 2009 at 4:36 PM, Chris 'Xenon' Hanson wrote: > Jean-Sébastien Guay wrote: >> I just had a thought, could the object on which this callback is set >> have any influence on the results? Should I set the cull callback on the >> Geode, or will any parent node do? >> I was setting it on

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-22 Thread Jean-Sébastien Guay
Hi Chris, I assume the call to traverse() is what actually adds the skydome to the render graph, so I'd need to trace down into that right? I traced down into that, and the drawables are added to the graph... It goes down to inline void CullVisitor::addDrawableAndDepth( osg::Drawable* d

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-22 Thread Chris 'Xenon' Hanson
Jean-Sébastien Guay wrote: > I just had a thought, could the object on which this callback is set > have any influence on the results? Should I set the cull callback on the > Geode, or will any parent node do? > I was setting it on the parent node of my skydome, which is a > MatrixTransform. Perhap

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi again, I dug back into my e-mail archives and found a message from Robert on 10/7/2003 that I used as my inspiration: Thanks for digging that up. Indeed, after the corrections you mention, it looks almost exactly like what I have. I just had a thought, could the object on which this ca

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi Chris, I dug back into my e-mail archives and found a message from Robert on 10/7/2003 that I used as my inspiration: Thanks for digging that up. Indeed, after the corrections you mention, it looks almost exactly like what I have. But, I think this demonstrates you're on the right tr

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Chris 'Xenon' Hanson
Jean-Sébastien Guay wrote: > From scratch, I couldn't find another cull callback that did things > before and after the traverse() in the examples... Any suggestions? I dug back into my e-mail archives and found a message from Robert on 10/7/2003 that I used as my inspiration: There isn't at

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Chris 'Xenon' Hanson
Jean-Sébastien Guay wrote: > Otherwise, I guess I could cache and reset the ComputeNearFarMode like > this: > > Does that look like something that could work? (it doesn't seem to at > first glance, but maybe I'm doing something wrong) It looks exactly like I'd expect it to be. I think you can o

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi Chris, I think I'd prefer being able to disable the auto compute near/far for the node itself, and be done with it. If you can tell me why my code posted before doesn't render anything, I'm all ears. Yeah, that should be the way to do it. Did you copy a working recipe or wing it from scr

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Chris 'Xenon' Hanson
Jean-Sébastien Guay wrote: > That's what I've done (see a previous post in this thread) but it didn't > work for some reason - the subgraph was never rendered. Ok. I stepped into the conversation late. > I think I'd prefer being able to disable the auto compute near/far for > the node itself, a

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread David Spilling
J-S (and others), You could look at doing this is the same way the depth partition node does it, which is what I do: I use a class based on an OSG camera with an overriden traverse method, that forces the projection matrix to a particular z near and z far. Oh, and the camera has setComputeNearFar

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi Chris, From memory, can't you create a NodeCallback that checks to see if it's being traversed by a CullVisitor (dynamic-cast the NodeVisitor) and if so, temporarily switch off the near/far computation, traverse the node/subgraph, and then turn it back on? That's what I've done (see a p

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Chris 'Xenon' Hanson
Chris 'Xenon' Hanson wrote: > Yeah, but I had a way to avoid this. Let me look at my code again... From memory, can't you create a NodeCallback that checks to see if it's being traversed by a CullVisitor (dynamic-cast the NodeVisitor) and if so, temporarily switch off the near/far computatio

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Chris 'Xenon' Hanson
Jean-Sébastien Guay wrote: > Nope, that's exactly what I'm doing, the problem is that OSG still uses > the skydome when auto-computing the near+far planes for the other > objects in the scene. And I need the dome to be really big, otherwise I > get the problem I mentioned earlier (when moving away

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi Chris, Maybe I'm missing something, but usually a skydome doesn't need z-buffering at all. Backface culling is sufficient for when you're inside a tessellated sphere, so you can just clear the z-buffer, turn off Z writes/compares, render the skydome, turn on z-write/compare and render the

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi Paul, I currently disable autocompute and set a large far plane value and a small near plane value, but this results in z fighting. That's exactly what I'm hoping to avoid. The equivalent to this in OpenGL would be to use two Camera nodes. [...] Seems like you could do something similar w

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Chris 'Xenon' Hanson
Paul Martz wrote: > Seems like you could do something similar with your skydome. Use a camera to > render the skydome, then a second camera to render everything else in your > scene. Maybe I'm missing something, but usually a skydome doesn't need z-buffering at all. Backface culling is sufficie

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Paul Martz
e LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 21, 2009 10:13 AM To: OpenSceneGraph Users Subject: [osg-users] Ge

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi Robert, Hows about using a cull callback that caches the compute near/far values before traversing the subgaph then restores the value afterwards, it'd only take a couple of lines of code. Unless I'm reading the headers wrong, there is no setter for the computed near and far values? Only g

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi Robert, Hows about using a cull callback that caches the compute near/far values before traversing the subgaph then restores the value afterwards, it'd only take a couple of lines of code. Hmm, another interesting approach. I'll try it. Thanks, J-S -- _

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Robert Osfield
ll try that and report how it goes. > > J-S > >> >> chuck >> >>> -Original Message- >>> From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- >>> boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay >>> Sent: Tu

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
sage- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users- boun...@lists.openscenegraph.org] On Behalf Of Jean-Sébastien Guay Sent: Tuesday, April 21, 2009 12:13 PM To: OpenSceneGraph Users Subject: [osg-users] Geometry considered in near+far plane auto computation Hi all, I need some nodes

Re: [osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Cole, Charles E. (LARC-B702)[RAYTHEON TECHNICAL SERVICES COMPANY]
egraph.org] On Behalf Of Jean-Sébastien Guay > Sent: Tuesday, April 21, 2009 12:13 PM > To: OpenSceneGraph Users > Subject: [osg-users] Geometry considered in near+far plane auto > computation > > Hi all, > > I need some nodes to be ignored by the near+far plane auto computa

[osg-users] Geometry considered in near+far plane auto computation

2009-04-21 Thread Jean-Sébastien Guay
Hi all, I need some nodes to be ignored by the near+far plane auto computation. I was wondering, is there some other way than setReferenceFrame(ABSOLUTE_RF) to do this? My specific use case is a skydome. It needs to be very large, but still be "in the world" - if I use the same trick as for