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*
On Wed, Apr 22, 2009 at 4:36 PM, Chris 'Xenon' Hanson
xe...@alphapixel.com 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
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 a
...@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 to be ignored by the near+far
...@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 to be ignored by the near+far
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
--
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
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] Geometry considered in near+far plane auto
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 sufficient
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
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
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
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
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
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
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, and
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
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 omit
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
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
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
21 matches
Mail list logo
