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] Changes in osgVolume from 3.0 to 3.4

[Robert Osfield]

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
>> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [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 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
> 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] Changes in osgVolume from 3.0 to 3.4

[Robert Osfield]

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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Alex Taylor]

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.

- Alex



On Thu, Feb 11, 2016 at 2:49 PM Alex Taylor <alextay...@gmail.com> wrote:

> Hi Robert,
>
> Thanks so much, the thread you referenced, "osgViewer/Renderer ctor
> set wrong defaults for SceneView" has mostly resolved the blending issues
> I was having. I now call:
>
> osg::ref_ptr stateSet =
> osgCamera->getOrCreateStateSet();
> stateSet->setGlobalDefaults();
>
> When setting up my Camera. Things *mostly* look good now. I am still
> having one lingering problem with the way my isosurfaces are rendering with
> RayTracedTechnique as a result of the OSG 3.4 upgrade from OSG 3.0. I'm
> using RayTracedTechnique with the default shaders used by
> RayTracedTechnique, no hardcoded shaders paths or anything like that.
>
> if (volumeProperties.volumeTechnique ==
> VolumeTechnique::RayTraced){
> osg::ref_ptr rayTraced = new
> osgVolume::RayTracedTechnique();
> tile->setVolumeTechnique(rayTraced.get());
> osg::ref_ptr frontFace(new
> osg::FrontFace(osg::FrontFace::CLOCKWISE));
> stateset->setAttribute(frontFace.get(),
> osg::StateAttribute::PROTECTED);
>
> } else if (volumeProperties.volumeTechnique ==
> VolumeTechnique::FixedFunction) {
> tile->setVolumeTechnique(new
> osgVolume::FixedFunctionTechnique());
> stateset->setMode(GL_LIGHTING,osg::StateAttribute::OFF |
> osg::StateAttribute::OVERRIDE);
> } else {
> throw hg::PropertyException("VolumeTechnique");
> }
>
> layer->addProperty(new
> osgVolume::TransferFunctionProperty(volumeProperties.transferFunction.get()));
> layer->addProperty(new
> osgVolume::AlphaFuncProperty(volumeProperties.alphaFunc));
> layer->addProperty(new
> osgVolume::SampleDensityProperty(volumeProperties.sampleDensity));
> layer->addProperty(new
> osgVolume::SampleDensityWhenMovingProperty(volumeProperties.sampleDensityWhenMoving));
> if (volumeProperties.useLighting) layer->addProperty(new
> osgVolume::LightingProperty);
> if (volumeProperties.useIsosurface) layer->addProperty(new
> osgVolume::IsoSurfaceProperty(volumeProperties.alphaFunc));
> if (volumeProperties.useMaximumIntensityProjection)
> layer->addProperty(new osgVolume::MaximumIntensityProjectionProperty());
>
> Attached is what I see for isosurfaces in OSG 3.4 vs. OSG 3.0. The OSG 3.4
> isosurfaces are rendering very "washed out" looking. I suspect I'm still
> having some sort of Blending issue with the Isosurface specifically. Any
> thoughts on what that might be happening?
>
> Either way, I have really appreciated your help.
>
> - Alex
> ​
> ____________
> From: osg-users <osg-users-boun...@lists.openscenegraph.org> on behalf of
> Robert Osfield <robert.osfi...@gmail.com>
> Sent: Thursday, February 4, 2016 6:43 AM
> To: OpenSceneGraph Users
>
> Subject: Re: [osg-users] Changes in osgVolume from 3.0 to 3.4
>
> Hi Alex,
>
> The blending difference might be down to a bug fix elsewhere in the
> OSG.  Have a look at yesterdays discussion "osgViewer/Renderer ctor
> set wrong defaults for SceneView", in particular my replies that
> explain how a bug fix (in OSG-3.2 onwards) to the way that global
> State is managed reveals a deficiency in the viewer set up.
>
> As the light direction issue, the new way is more general purpose, the
> old behaviour isn't required, the old shaders aren't maintained.  If
> you want the old shaders and uniform set up you'll need to write these
> yourself, or just adopt the new approach and have your viewer
> manipulate the main light source using the viewer's Light or an
> osg::LightSource placed in the scene.
>
> Robert.
>
> osg-users
> x
>
> On 3 February 2016 at 21:11, Alex Taylor <alextay...@gmail.com> wrote:
> > Robert,
> >
> > Thanks. There are two main culprits the behavior change I was seeing. The
> > first is that for some reason, between OSG 3.0 and 3.4, I now need to
> > explicitly set a BlendFunc. With the exception of MIP, it looks like the
> > rest of osgVolume just renders with a default BlendFunc and doesn't
> > explictly s

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

[Robert Osfield]

Hi Alex,

The blending difference might be down to a bug fix elsewhere in the
OSG.  Have a look at yesterdays discussion "osgViewer/Renderer ctor
set wrong defaults for SceneView", in particular my replies that
explain how a bug fix (in OSG-3.2 onwards) to the way that global
State is managed reveals a deficiency in the viewer set up.

As the light direction issue, the new way is more general purpose, the
old behaviour isn't required, the old shaders aren't maintained.  If
you want the old shaders and uniform set up you'll need to write these
yourself, or just adopt the new approach and have your viewer
manipulate the main light source using the viewer's Light or an
osg::LightSource placed in the scene.

Robert.

osg-users
x

On 3 February 2016 at 21:11, Alex Taylor  wrote:
> Robert,
>
> Thanks. There are two main culprits the behavior change I was seeing. The
> first is that for some reason, between OSG 3.0 and 3.4, I now need to
> explicitly set a BlendFunc. With the exception of MIP, it looks like the
> rest of osgVolume just renders with a default BlendFunc and doesn't
> explictly set anything.
>
> I found that by setting
>
>  stateset->setAttribute(new osg::BlendFunc(GL_SRC_ALPHA,
> GL_ONE_MINUS_SRC_ALPHA), osg::StateAttribute::ON);
>
> There is a second issue I want to ask about:
>
> It looks to me there was a change to the shaders I'm using regarding the
> position of the light source between OSG 3.0 and OSG 3.4:
>
> https://github.com/openscenegraph/osg/commit/4525ec49a386b48608fdb3107033a1c915d928e6
>
> The change is to honor the lightDirection from GL_LIGHT0 rather than use the
> eye direction as the direction of the light source.
>
> If I wanted to get the old behavior of using the eyeDirection, is there an
> easy way to go about that?
>
> Thanks,
>
> Alex
>
>
> On Thu, Jan 28, 2016 at 3:16 PM Robert Osfield 
> wrote:
>>
>> Hi Alex,
>>
>> There were quite a few improvements to osgVolume between OSG-3.0 and
>> OSG-3.4, both in shaders and the introduction of the new MultiPassTechnique.
>> One thing to look at with your own setup is that you aren't picking up on
>> old
>>  shaders such as by having your own path to old shaders.
>>
>> It's quite a while since I did the work on osgVolume, around two years, so
>> won't be able to be specific without viewing code and being able to
>> reproduce the problems you are seeing first hand.
>>
>> Robert.
>>
>> On 28 January 2016 at 15:25, Alex Taylor  wrote:
>>>
>>> Hi,
>>>
>>> I'm working on upgrading the OSG version used in the product I work on.
>>> When OSG is upgraded with the same client code, I'm noticing differences is
>>> the way my volumes are rendered with all of the rendering algorithms that I
>>> can't explain. I've fixed the parameters I'm using to define the osgVolume
>>> in both versions, so it can't be a matter of picking up a different default
>>> option for a parameter.
>>>
>>> OSG 3.4 Fixed Function
>>>
>>> OSG 3.0 Fixed Function
>>>
>>>
>>> OSG 3.4 Ray Traced Lit
>>>
>>>
>>> OSG 3.0 Ray Traced Lit
>>>
>>>
>>>
>>> OSG 3.4 Isosurface
>>>
>>> OSG 3.0 Isosurface
>>>
>>>
>>> In the Ray Traced cases, I'm using the properties:
>>>
>>> AlphaFunc = 0.02;
>>> SampleDensity = 0.005;
>>>
>>> I'm using setting the TransferFunctionProperty, so I'm using the shaders
>>> to do the alpha/color mapping.
>>>
>>> For the FixedFunctionTechnique, I'm using AlphaFunc = 0.02, and using the
>>> applyTransferFunction function to obtain an RGBA mapped osg::Image buffer.
>>>
>>> It's very possible that the upgrade to 3.4 has changed something else in
>>> my overall use of OSG elsewhere in the pipeline, unrelated to osgVolume,
>>> that is causing this issue. That said, I thought i'd ask if visually anyone
>>> has a guess it what might have changed between osg 3.0 and osg 3.4 that
>>> might explain these visual differences.
>>>
>>> Thanks for your help,
>>>
>>> Alex
>>>
>>>
>>>
>>> ___
>>> 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
>
>
> ___
> 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