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

2009-04-28 Thread David Spilling
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 transparent objects so probably wouldn't have
noticed if something was awry - I'll have to check).

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.

Thanks for the caveat!

David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-28 Thread Jean-Sébastien Guay

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. I'll try that out.

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-28 Thread Jean-Sébastien Guay

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 clouds that are just quads with semitransparent cloud textures on 
them, so it was very apparent :-)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-28 Thread Jean-Sébastien Guay

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 need to add an extra 
camera. It's a classic two-pronged attack:


1. Use a CullCallback that sets the compute near/far mode to off, 
traverses the skydome and resets it to the previous value.
2. Use a drawable DrawCallback on all the skydome's drawables that will 
calculate the maximum possible value the far plane would need to be at 
for the skydome to be visible from the current camera position, draws 
the drawable, and resets the old far plane after drawing.


One thing I found I needed to do is keep the same near plane value as 
was set before, otherwise the skydome seemed to move when the camera moved.


Here's the code I'm using:

struct DoNotIncludeInNearFarComputationCallback
: public osg::NodeCallback
{
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor *cv =
dynamic_cast osgUtil::CullVisitor*( nv );

// Default value
osg::CullSettings::ComputeNearFarMode oldMode =
osg::CullSettings::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES;

if( cv )
{
oldMode = cv-getComputeNearFarMode();
cv-setComputeNearFarMode(
osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
}

traverse(node, nv);

if( cv )
{
cv-setComputeNearFarMode(oldMode);
}
}
};

struct OverrideNearFarValuesCallback
: public osg::Drawable::DrawCallback
{
OverrideNearFarValuesCallback(SkyDome* skyDome)
: m_skyDome(skyDome) {}

virtual void drawImplementation(osg::RenderInfo renderInfo,
const osg::Drawable* drawable) const
{
osg::Camera* currentCamera = renderInfo.getCurrentCamera();
if (currentCamera)
{
// Get the current camera position.
osg::Vec3 eye, center, up;
renderInfo.getCurrentCamera()-getViewMatrixAsLookAt(
eye, center, up);

// Get the max distance we need the far plane to be at,
// which is the distance between the eye and the skydome's
// center, plus the skydome's radius.
double distance = (m_skyDome-getCenter() - eye).length() +
   m_skyDome-getRadius();

// Save old values.
osg::ref_ptrosg::RefMatrixd oldProjectionMatrix =
new osg::RefMatrix;
oldProjectionMatrix-set(
renderInfo.getState()-getProjectionMatrix());

// Get the individual values
double left, right, bottom, top, zNear, zFar;
oldProjectionMatrix-getFrustum(
left, right, bottom, top, zNear, zFar);

// Build a new projection matrix with a modified far plane
osg::ref_ptrosg::RefMatrixd projectionMatrix =
new osg::RefMatrix;
projectionMatrix-makeFrustum(
left, right, bottom, top, zNear, distance);
renderInfo.getState()-applyProjectionMatrix(
projectionMatrix.get());

// Draw the drawable
drawable-drawImplementation(renderInfo);

// Reset the far plane to the old value.
renderInfo.getState()-applyProjectionMatrix(
oldProjectionMatrix.get());
}
else
{
drawable-drawImplementation(renderInfo);
}
}

SkyDome* m_skyDome;
};

struct AddCallbackToDrawablesVisitor : public osg::NodeVisitor
{
AddCallbackToDrawablesVisitor(SkyDome* skyDome)
: osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN),
  m_skyDome(skyDome) {}

virtual void apply(osg::Geode node)
{
for (unsigned int i = 0; i  node.getNumDrawables(); i++)
{
node.getDrawable(i)-setDrawCallback(
new OverrideNearFarValuesCallback(m_skyDome));
// Do not use display lists otherwise the callback will only
// be called once on initial compile.
node.getDrawable(i)-setUseDisplayList(false);
}
}

SkyDome* m_skyDome;
};


Then when adding the dome to the scene I do these extra steps:

// Setup rendering so that the skydome does not affect the automatic
// near/far plane calculation.
m_node-setCullCallback(
new DoNotIncludeInNearFarComputationCallback);
AddCallbackToDrawablesVisitor visitor(this);
m_node-accept(visitor);

// Transparent bin is #10 by default so render just before
// transparent objects.
ss-setRenderBinDetails(9, RenderBin);
ss-setAttributeAndModes(
new osg::Depth(osg::Depth::LEQUAL, 1.0, 1.0),
osg::StateAttribute::ON);



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

2009-04-28 Thread Cole, Charles E. (LARC-B702)[RAYTHEON TECHNICAL SERVICES COMPANY]
Hi J-S,

Thanks for keeping this post going with what you've done.  I've been keeping an 
eye on it with keen interest.  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 viewed as being far field.

Thanks.

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: 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, 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 need to add an
 extra
 camera. It's a classic two-pronged attack:
 
 1. Use a CullCallback that sets the compute near/far mode to off,
 traverses the skydome and resets it to the previous value.
 2. Use a drawable DrawCallback on all the skydome's drawables that will
 calculate the maximum possible value the far plane would need to be at
 for the skydome to be visible from the current camera position, draws
 the drawable, and resets the old far plane after drawing.
 
 One thing I found I needed to do is keep the same near plane value as
 was set before, otherwise the skydome seemed to move when the camera
 moved.
 
 Here's the code I'm using:
 
 struct DoNotIncludeInNearFarComputationCallback
  : public osg::NodeCallback
 {
  virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
  {
  osgUtil::CullVisitor *cv =
  dynamic_cast osgUtil::CullVisitor*( nv );
 
  // Default value
  osg::CullSettings::ComputeNearFarMode oldMode =
 
 osg::CullSettings::COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES;
 
  if( cv )
  {
  oldMode = cv-getComputeNearFarMode();
  cv-setComputeNearFarMode(
  osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
  }
 
  traverse(node, nv);
 
  if( cv )
  {
  cv-setComputeNearFarMode(oldMode);
  }
  }
 };
 
 struct OverrideNearFarValuesCallback
  : public osg::Drawable::DrawCallback
 {
  OverrideNearFarValuesCallback(SkyDome* skyDome)
  : m_skyDome(skyDome) {}
 
  virtual void drawImplementation(osg::RenderInfo renderInfo,
  const osg::Drawable* drawable)
 const
  {
  osg::Camera* currentCamera = renderInfo.getCurrentCamera();
  if (currentCamera)
  {
  // Get the current camera position.
  osg::Vec3 eye, center, up;
  renderInfo.getCurrentCamera()-getViewMatrixAsLookAt(
  eye, center, up);
 
  // Get the max distance we need the far plane to be at,
  // which is the distance between the eye and the skydome's
  // center, plus the skydome's radius.
  double distance = (m_skyDome-getCenter() - eye).length()
 +
 m_skyDome-getRadius();
 
  // Save old values.
  osg::ref_ptrosg::RefMatrixd oldProjectionMatrix =
  new osg::RefMatrix;
  oldProjectionMatrix-set(
  renderInfo.getState()-getProjectionMatrix());
 
  // Get the individual values
  double left, right, bottom, top, zNear, zFar;
  oldProjectionMatrix-getFrustum(
  left, right, bottom, top, zNear, zFar);
 
  // Build a new projection matrix with a modified far plane
  osg::ref_ptrosg::RefMatrixd projectionMatrix =
  new osg::RefMatrix;
  projectionMatrix-makeFrustum(
  left, right, bottom, top, zNear, distance);
  renderInfo.getState()-applyProjectionMatrix(
  projectionMatrix.get());
 
  // Draw the drawable
  drawable-drawImplementation(renderInfo);
 
  // Reset the far plane to the old value.
  renderInfo.getState()-applyProjectionMatrix(
  oldProjectionMatrix.get());
  }
  else
  {
  drawable-drawImplementation(renderInfo);
  }
  }
 
  SkyDome* m_skyDome;
 };
 
 struct AddCallbackToDrawablesVisitor : public osg::NodeVisitor
 {
  AddCallbackToDrawablesVisitor(SkyDome* skyDome)
  : osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN),
m_skyDome(skyDome) {}
 
  virtual void apply(osg::Geode node)
  {
  for (unsigned int i = 0; i  node.getNumDrawables

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

2009-04-28 Thread Jean-Sébastien Guay

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. 
 I'm assuming that it has to be great enough to still be viewed as being far 
field.


As I said in another thread, I generally place my skydome at the (x,y) 
of the complete scene's bounding sphere, with z = 0, and with a radius 
that encompasses the whole scene (so the scene's bounding sphere's 
radius). That's in our simulators, so we need values that work for all 
scenes, and that works for us.


In another application we give control over the values (it's kind of 
like a content creation app, so users might want to tweak them).


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-28 Thread Jean-Sébastien Guay

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 viewed as being far field.


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 
were to make a flight sim where the user can travel large distances this 
wouldn't work and we'd need to do it differently.


Hope this helps,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-28 Thread Cole, Charles E. (LARC-B702)[RAYTHEON TECHNICAL SERVICES COMPANY]
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
 were to make a flight sim where the user can travel large distances
 this
 wouldn't work and we'd need to do it differently.

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.

chuck
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-28 Thread Jean-Sébastien Guay

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, thinking about it, it should work there too. Since the skydome 
is setting fragments at the far plane after all other opaque objects 
have been rendered, and the really large far plane value will only 
affect the skydome itself, no z-fighting between the skydome and 
anything else should occur.


Try it if you want, and let us (me :-) ) know how it goes.

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-26 Thread David Spilling
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 wierder, the skydome vertices would
clip, but the inter-vertex points wouldn't due to interpolation, so the dome
looked patchy.

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.

In my app, I don't see a Camera with NESTED_RENDER as much of a per-frame
overhead - it's pretty much negligible with all the rest of the CPU activity
I'm engaging in, but I can appreciate that this might not be the case for
everyone.

Plus it had the advantage of being scenegraph agnostic - i.e. injection of
this as a (for example) .osg worked without having to appeal to a particular
application scenegraph structure in terms of PRE_RENDER, depth clears, etc.

David
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-26 Thread Jean-Sébastien Guay

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 using the code you quoted. As I said, it has too many 
implications on the scene graph and viewer but it ended up being the 
only solution I could find that worked and gave the results I wanted.


I'm still open to suggestions though. :-)

Glad I could help,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-26 Thread Jean-Sébastien Guay

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 well.


  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.


I wonder where the near/far for final rendering are set. I'll 
investigate this. I agree with your intuition, if we can find an 
appropriate place where we could set a large value for the far plane, 
then reset it to the previous value when the skydome is rendered then 
that would work.


Perhaps in a Drawable DrawCallback? Something like:

struct MyDrawCallback : public osg::Drawable::DrawCallback
{
virtual void drawImplementation(osg::RenderInfo renderInfo,
const osg::Drawable* drawable) const
{
// Save old values.
double left, right, bottom, top, zNear, zFar;
renderInfo-getCurrentCamera()-getProjectionMatrixAsFrustum(
left, right, bottom, top, zNear, zFar;

// Set the far plane to a large value.
renderInfo-getCurrentCamera()-setProjectionMatrixAsFrustum(
left, right, bottom, top, 1000, 1);

drawable-draw(renderInfo);

// Reset the far plane to the old value.
renderInfo-getCurrentCamera()-setProjectionMatrixAsFrustum(
left, right, bottom, top, zNear, zFar);
}
};

I'll test something like that out, in combination with the cull callback 
for ignoring the skydome in the automatic near/far computation, tomorrow 
when I get in the office.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-26 Thread Jean-Sébastien Guay

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 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).


Since the skydome is furthest from the camera, but if actually wraps 
around the camera, the only way to guarantee that it will be drawn in 
the correct order for transparent objects in the foreground to blend 
correctly with it is to render it first.


I know this sounds bad, I previously advocated rendering 
skydomes/skyboxes last too (to take advantage of the fact that we can 
just set any fragments that have not been set yet by other objects) but 
I don't see how to reconcile that with the rendering of transparent 
objects in the foreground.


So, given that I need the skydome to render first, it means I need to 
muck around with the clear settings and things like that, which I don't 
like.


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-25 Thread Doug McCorkle

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 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 really  
close to small models without them being clipped by the near plane.  
Barring any breakthrough on the other front, this will still be a  
very good solution.


If anyone's curious, the code looks like:

// Callback that checks other cameras

namespace {

int s_skyDomePreRenderCameraNum = -100;

class CheckCamerasCallback : public osg::NodeCallback
{
public:
   virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
   {
   osgUtil::CullVisitor *cv =
   dynamic_cast osgUtil::CullVisitor *( nv );
   if (cv)
   {
   // Do not use cv-getCurrentCamera() because it did not
   // exist in 2.2 which we still support
   osg::Camera* camera =
   cv-getCurrentRenderBin()-getStage()-getCamera();
   // If the camera is either a pre-render camera with num 
   // our pre-render order, or not a pre-render camera
   if (camera-getRenderOrder() != osg::Camera::PRE_RENDER ||
   camera-getRenderOrderNum() 
  s_skyDomePreRenderCameraNum)
   {
   // I should also check if the camera is set to render  
to

   // the framebuffer and is not an RTT camera, just to be
   // sure I'm only affecting the cameras I want to  
affect.


   // Set the camera to not clear the color buffer.
   if (camera-getClearMask()  GL_COLOR_BUFFER_BIT)
   camera-setClearMask(
   camera-getClearMask()  ~GL_COLOR_BUFFER_BIT);
   }
   }

   traverse(node,nv);
   }
};

}

SkyDome::SkyDome(...)
{
   // Skydome initialization (the code is a modified version of the
   // osgEphemeris skydome)
   // ...
   // ...

   // Render the skydome through another camera so that the cloud  
plane

   // won't influence the main camera's near/far plane computations.
   // I'd prefer to find some other way to have the sky dome not
   // influence the main camera near/far values, because this has
   // repercussions on the viewer setup (see how CheckCamerasCallback
   // affects all other cameras). But it works well.
#define USE_EXTRA_CAMERA
#ifdef USE_EXTRA_CAMERA
   osg::Camera* camera = new osg::Camera;
   camera-setRenderOrder(osg::Camera::PRE_RENDER,
   s_skyDomePreRenderCameraNum);   // set to -100 by default
   // Hopefully this will be the first pre-render camera, so it should
   // clear the color and depth buffers (this skydome is not  
guaranteed

   // to fill the whole view at all times).
   camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
   // The dome hangs under m_skyTransform.
   camera-addChild(m_skyTransform.get());
   // m_node is the node that's exposed to be added to the graph by
   // client code.
   m_node-addChild(camera);

   // Make sure the main viewer camera only clears the depth buffer
   // otherwise it will clear our skydome...
   m_node-setCullCallback(new CheckCamerasCallback);
#else
   // The dome hangs under m_skyTransform.
   // m_node is the node that's exposed to be added to the graph by
   // client code.
   m_node-addChild(m_skyTransform.get()); // The dome hangs under  
this

#endif

}

Thanks a lot.

J-S

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-25 Thread Chris 'Xenon' Hanson
  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 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.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
There is no Truth. There is only Perception. To Perceive is to Exist. - Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-21 Thread Paul Martz
I can see that this might have long fingers in your app. Bummer.

Anyhow, you might be able to also avoid clearing depth in your other
cameras. Here's something to try: In the camera that renders the skydome,
use Depth in the StateSet to set the depth range to something like
0.999-1.0. This puts your skydome all the way in the back of the depth
buffer, and then it should be far enough back that subsequent scene cameras
shouldn't need to clear either the color or depth buffers.

It might be kind of a pain in your app, but hopefully avoiding those clears
buys you some small performance gain that makes the change as a whole
beneficial.

Paul Martz
Skew Matrix Software 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 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, 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 previous post in this thread) but it didn't
work for some reason - the subgraph was never rendered.

I've done what Paul suggested: the skydome is under a PRE_RENDER camera and
so has its own projection matrix and thus, doesn't affect the computed
near/far values for the main camera. It works, but it has more implications
on the rest of my scene graph/viewer setup than I'd like. 
All other cameras need to be set to only clear the depth buffer otherwise
they'll clear my skydome (of course) and since in my app, views may be added
at any time, this introduces an extra required step when creating a view...

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.

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-21 Thread Jean-Sébastien Guay

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_RENDER, 
it's the first camera. I therefore need to disable clear of the color 
buffer for all other cameras.


Anyways, I'll try to go forward with the other route (disabling auto 
computation of near/far) since I think this will have less implications.


Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-21 Thread Paul Martz
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 convoluted.
:-)

Paul Martz
Skew Matrix Software 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 4:02 PM
To: OpenSceneGraph 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 camera needs to clear
the color buffer, and since my skydome is rendered in PRE_RENDER, it's the
first camera. I therefore need to disable clear of the color buffer for all
other cameras.

Anyways, I'll try to go forward with the other route (disabling auto
computation of near/far) since I think this will have less implications.

Thanks,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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

2009-04-21 Thread Jean-Sébastien Guay

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 really 
close to small models without them being clipped by the near plane. 
Barring any breakthrough on the other front, this will still be a very 
good solution.


If anyone's curious, the code looks like:

// Callback that checks other cameras

namespace {

int s_skyDomePreRenderCameraNum = -100;

class CheckCamerasCallback : public osg::NodeCallback
{
public:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor *cv =
dynamic_cast osgUtil::CullVisitor *( nv );
if (cv)
{
// Do not use cv-getCurrentCamera() because it did not
// exist in 2.2 which we still support
osg::Camera* camera =
cv-getCurrentRenderBin()-getStage()-getCamera();
// If the camera is either a pre-render camera with num 
// our pre-render order, or not a pre-render camera
if (camera-getRenderOrder() != osg::Camera::PRE_RENDER ||
camera-getRenderOrderNum() 
   s_skyDomePreRenderCameraNum)
{
// I should also check if the camera is set to render to
// the framebuffer and is not an RTT camera, just to be
// sure I'm only affecting the cameras I want to affect.

// Set the camera to not clear the color buffer.
if (camera-getClearMask()  GL_COLOR_BUFFER_BIT)
camera-setClearMask(
camera-getClearMask()  ~GL_COLOR_BUFFER_BIT);
}
}

traverse(node,nv);
}
};

}

SkyDome::SkyDome(...)
{
// Skydome initialization (the code is a modified version of the
// osgEphemeris skydome)
// ...
// ...

// Render the skydome through another camera so that the cloud plane
// won't influence the main camera's near/far plane computations.
// I'd prefer to find some other way to have the sky dome not
// influence the main camera near/far values, because this has
// repercussions on the viewer setup (see how CheckCamerasCallback
// affects all other cameras). But it works well.
#define USE_EXTRA_CAMERA
#ifdef USE_EXTRA_CAMERA
osg::Camera* camera = new osg::Camera;
camera-setRenderOrder(osg::Camera::PRE_RENDER,
s_skyDomePreRenderCameraNum);   // set to -100 by default
// Hopefully this will be the first pre-render camera, so it should
// clear the color and depth buffers (this skydome is not guaranteed
// to fill the whole view at all times).
camera-setClearMask(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
// The dome hangs under m_skyTransform.
camera-addChild(m_skyTransform.get());
// m_node is the node that's exposed to be added to the graph by
// client code.
m_node-addChild(camera);

// Make sure the main viewer camera only clears the depth buffer
// otherwise it will clear our skydome...
m_node-setCullCallback(new CheckCamerasCallback);
#else
// The dome hangs under m_skyTransform.
// m_node is the node that's exposed to be added to the graph by
// client code.
m_node-addChild(m_skyTransform.get()); // The dome hangs under this
#endif

}

Thanks a lot.

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org