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

[Alex Taylor]

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<osg::Image> intensityImage =
createTexture3D(data);*

*            osg::ref_ptr<osg::Image> image_3d =
(volumeProperties.volumeTechnique == VolumeTechnique::FixedFunction) ?*

*
osgVolume::applyTransferFunction(intensityImage.get(),volumeProperties.transferFunction.get())
:*

*
intensityImage.release();*



*            osg::ref_ptr<osgVolume::ImageLayer> 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<osg::Image> image_3d = new osg::Image;*

*        image_3d->setImage(num_s, num_t, num_r,*

*                GL_LUMINANCE, GL_LUMINANCE, GL_UNSIGNED_BYTE,*

*                static_cast<uint8_T *>(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 <robert.osfield at gmail.com>
wrote:

> Hi Alex,
>
> On 11 February 2016 at 20:47, Alex Taylor <alextaylor at gmail.com> 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
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160216/fdf9953c/attachment-0003.htm>