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, th
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
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 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.
openscenegraph.org] On Behalf 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 cal
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 ne
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 clou
Hi David,
For me, I will probably control the renderbins (if I'm not already doing
it), and render ; 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. I'll try that out.
Thanks,
J-S
--
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 man
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
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 we
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 usin
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 w
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 callback
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 P
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
Hi Paul,
Yes, I understand this. And because you _have_ to disable color buffer
clears in the other cameras, it'd be nice if you could also disable depth
buffer clears. That way, the other cameras wouldn't have to invoke glClear
at all. (That was the point I was trying to make, sorry it got conv
SceneGraph 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 c
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 PRE_R
n Guay
Sent: Tuesday, 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 (dynami
20 matches
Mail list logo