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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
_
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
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
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
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
23 matches
Mail list logo