Re: [osg-users] Changes in osgVolume from 3.0 to 3.4

[Alex Taylor]

Robert,

Thanks. This was helpful. I resolved my issue by just setting the alpha to
1.0 for all input values in my transfer function. This together with
specifying an IsosurfaceProperty gave me the effect I wanted.

Thanks again,

Alex
On Tue, Feb 16, 2016 at 10:16 AM Robert Osfield 
wrote:

> Hi Alex,
>
> I'm a bit too busy to go rummaging through code to answer your
> questions so will do my best by providing some general questions.  I
> vaguely recall OSG-3.0 alpha, transparency and isosurface all
> overlapped a bit, so there was a bit of cross over.  In OSG-3.4
> transparency and isosurface value is now separate and can be applied
> together within the same shader.   There is also AlphaFunc which clips
> out fragments below a specific alpha value.  I hope this makes sense.
>
> Robert.
>
> On 16 February 2016 at 14:59, Alex Taylor  wrote:
> > Robert,
> >
> > Thanks again. I do have one quick follow up question related to something
> > you said.
> >
> > "Check the alpha values settings that you have set up for the
> VolumeTile."
> >
> > I'm trying to figure out exactly what you mean by the "alpha values
> > settings" on the VolumeTile. I define my VolumeTile as shown below. As
> you
> > can see, I'm not setting Alpha anywhere in the setup of my tile. The one
> > place where alpha comes in is when I set the TransferFunctionProperty on
> my
> > tile. This brings me to my question.
> >
> > It looks to me like the intention of Isosurface property is to specify
> the
> > isovalue for the isosurface rendering. What happens if you specify an
> > Isosurface property but your transfer function contains alpha values
> between
> > the ranges of (0,1)? Meaning, if you are defining an isosurface at
> isovalue
> > = X, do you also have to specify the alpha in your transfer function as a
> > unit step function U(I-X) with transition at X?
> >
> > I'm trying to understand the motivation for blending being on for the
> > Isosurface codepath in RayTracedTechnique and how the alpha in the
> transfer
> > function interacts with the specification of an IsosurfaceProperty. I had
> > originally thought/guessed that the alpha in your transfer function would
> > just be ignored if you specify an IsosurfaceProperty.
> >
> > - Alex
> >
> > osg::ref_ptr intensityImage =
> createTexture3D(data);
> >
> > osg::ref_ptr image_3d =
> > (volumeProperties.volumeTechnique == VolumeTechnique::FixedFunction) ?
> >
> >
> >
> osgVolume::applyTransferFunction(intensityImage.get(),volumeProperties.transferFunction.get())
> > :
> >
> >
> > intensityImage.release();
> >
> >
> >
> > osg::ref_ptr layer = new
> > osgVolume::ImageLayer(image_3d);
> >
> > tile->setLayer(layer.get());
> >
> > Where createTexture3D is defined as:
> >
> > osg::Image* createTexture3D(const mxArray* src) {
> >
> > if (src == NULL || mxGetNumberOfDimensions(src) != 3 ||
> > mxGetClassID(src) != mxUINT8_CLASS) {
> >
> > return NULL;
> >
> > }
> >
> > size_t num_s = mxGetDimensions(src)[0];
> >
> > size_t num_t = mxGetDimensions(src)[1];
> >
> > size_t num_r = mxGetDimensions(src)[2];
> >
> > // now allocate the 3d texture;
> >
> > osg::ref_ptr image_3d = new osg::Image;
> >
> > image_3d->setImage(num_s, num_t, num_r,
> >
> > GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE,
> >
> > static_cast(mxGetData(src)),
> >
> > osg::Image::NO_DELETE);
> >
> >
> >
> > return image_3d.release();
> >
> > }
> >
> > Other than that, the only other specification Alpha comes from setting
> the
> > TransferFunctionProperty on the tile with my TransferFunction. This
> brings
> > me to my question.
> >
> > When
> >
> >
> >
> > On Fri, Feb 12, 2016 at 5:42 AM Robert Osfield  >
> > wrote:
> >>
> >> Hi Alex,
> >>
> >> On 11 February 2016 at 20:47, Alex Taylor  wrote:
> >> > Also, if it matters, I found that I can get the rendering I'd expect
> if
> >> > I
> >> > explicitly set the BlendFunc in the special case of Isosurface:
> >> >
> >> >   if (volumeProperties.useIsosurface){
> >> > stateset->setAttribute(new osg::BlendFunc(GL_ONE,
> GL_ZERO),
> >> > osg::StateAttribute::ON);
> >> >}
> >> >
> >> > I'm not sure why I need to do this in OSG 3.4 when I didn't in OSG
> 3.0,
> >> > probably another issue with the viewer or something on my end.
> >>
> >> From the details above and the picture it looks to me that OSG-3.4 is
> >> probably doing the right thing w.r.t the settings, such as alpha
> >> settings, you are using and OSG-3.0 implementation was incorrect and
> >> ignored these settings so you never saw this.
> >>
> >> Check the alpha values settings that you have set up for the VolumeTile.
> >>
> >> Robert.
> >> ___
> >> osg-users mailing list
> >> 

Re: [osg-users] ArUco (AR) with OSG

[Jan Ciger]

On Wed, Feb 17, 2016 at 10:48 AM, Robert Osfield 
wrote:

> Hi Igor,
>
> The description is useful. In general the OSG just passes along projection
> and view matrices directly to OpenGL.  However, by default the OSG computes
> the near and far in the cull traversal on each frame and uses this to clamp
> the projection matrices so that depth precision is maximized.  The problem
> can arise if you are trying to match two render passes, if they have a
> different depth range then z buffer test will be erroneous so you'll get
> fragment clipped or not clipped.  Could this be the issue?
>
> To disable the compute near far simple do:
>
>
> viewer.getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
>
> You can find all the settings in the include/osg/CullSettings.
>
>

I have found it useful to force the projection matrix using the
osg::Projection node.  That avoids any issues with OSG modifying the
projection matrices.

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

Re: [osg-users] ArUco (AR) with OSG

[Robert Osfield]

Hi Igor,

The description is useful. In general the OSG just passes along projection
and view matrices directly to OpenGL.  However, by default the OSG computes
the near and far in the cull traversal on each frame and uses this to clamp
the projection matrices so that depth precision is maximized.  The problem
can arise if you are trying to match two render passes, if they have a
different depth range then z buffer test will be erroneous so you'll get
fragment clipped or not clipped.  Could this be the issue?

To disable the compute near far simple do:


viewer.getCamera()->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);

You can find all the settings in the include/osg/CullSettings.

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