Hi J-S,
The problem when the skydome renders last is that it won't be blended
correctly with transparent objects (they need to be rendered after all
opaque objects, and sorted back to front).
Ah. I hadn't considered that in detail. (I wonder what my app's behaviour is
then? I don't have many
Hi David,
For me, I will probably control the renderbins (if I'm not already doing
it), and render opaque objects skydome transparent objects; i.e.
putting the skydome in the regular opaque bin. Most of my objects are
opaque so I get some benefit here.
Yeah, that sounds like a happy medium.
Hi David,
Ah. I hadn't considered that in detail. (I wonder what my app's
behaviour is then? I don't have many transparent objects so probably
wouldn't have noticed if something was awry - I'll have to check).
Forgot to mention, that's the reason I noticed it right away, because we
have
Hello Chris,
I wonder if there were somehow a callback you could apply somewhere
that would hork with
the near/far clip, or if it's just easier to use multiple cameras at
that point.
Perhaps in a Drawable DrawCallback? Something like:
OK, I've finally got this to work well, without the
Of Jean-Sébastien Guay
Sent: Tuesday, April 28, 2009 10:14 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Geometryconsidered in near+far plane auto
computation
Hello Chris,
I wonder if there were somehow a callback you could apply
somewhere
that would hork with
the near/far clip
Hi Chuck,
Glad I can give useful and interesting information :-)
I do have one question though out of curiosity ... what dimensions
(particularly the radius) did you use to generate the skydome? I see that you
use the radius to determine the far plane value, but didn't know what you used.
Hi Chuck,
I do have one question though out of curiosity ... what dimensions
(particularly the radius) did you use to generate the skydome? I see
that you use the radius to determine the far plane value, but didn't
know what you used. I'm assuming that it has to be great enough to
still be
Hi J-S,
I just realized I didn't give you actual information, just how we get
the values... The radius turns out to be around 5000m most of the time.
In our simulators, most of the time the user will stay in an area about
100mx100m in the center of the scene, so this works well. I think if we
Hi again Chuck,
Thanks again. All of my apps have been flight sim-like apps, so a large
radius is required. But I do things differently. I may try your approach and see if I
can get better performance while still keeping relevant and viewable information from
being culled.
Actually,
Chris,
After some brain-twisting, I did realize that even with z comparison off,
OGL is
probably rejecting the skydome because it's beyond the far clip plane. I've
been trying to
think of a way to fool this, but it seems like it is unavoidable.
That's exactly what I found (or even
Hello Doug,
Is the solution you posted below the final solution you settled on? I
had trouble determining what you finally ended up deciding was the best
path forward. Thanks for posting this information on the list.
Yeah, as Robert said it was a convoluted thread... :-)
Yes, I ended up
Hi Chris,
After some brain-twisting, I did realize that even with z comparison off, OGL
is
probably rejecting the skydome because it's beyond the far clip plane. I've
been trying to
think of a way to fool this, but it seems like it is unavoidable.
Yeah, that's the conclusion I got to as
Hi David,
I had to use the approach I posted to simultaneously:
1) Make sure the skydome didn't participate in near/far autocalculation
2) Make sure OSG didn't cull the skydome
3) Make sure that OGL would actually draw something
4) Allow the skydome to draw last.
The problem when the skydome
Hello J-S,
Is the solution you posted below the final solution you settled on? I
had trouble determining what you finally ended up deciding was the
best path forward. Thanks for posting this information on the list.
Doug
On Apr 22, 2009, at 12:40 AM, Jean-Sébastien Guay wrote:
Hi again
Followup:
After some brain-twisting, I did realize that even with z comparison off, OGL
is
probably rejecting the skydome because it's beyond the far clip plane. I've
been trying to
think of a way to fool this, but it seems like it is unavoidable.
I wonder if there were somehow a
, April 21, 2009 2:29 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Geometryconsidered in near+far plane auto
computation
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
Hi Paul,
Anyhow, you might be able to also avoid clearing depth in your other
cameras.
Actually, the problem is not disabling clear of the depth buffer, it's
disabling clear of the color buffer. Only the first camera needs to
clear the color buffer, and since my skydome is rendered in
Users
Subject: Re: [osg-users]Geometryconsidered in near+far plane auto
computation
Hi Paul,
Anyhow, you might be able to also avoid clearing depth in your other
cameras.
Actually, the problem is not disabling clear of the depth buffer, it's
disabling clear of the color buffer. Only the first
Hi again Paul,
Anyways, that's a design concern, not implementation. Thanks for your
suggestions.
And I do want to emphasize that your solution (using a separate
osg::Camera) does work. I've implemented it for both the skydome and
cloud plane (which can get really big too) and I can now get
19 matches
Mail list logo
