Re: [osg-users] ShaderComposer::releaseGLObjects warning

[Andy Skinner]

So, to be clear, we'll leave it as is?

thanks
andy


Needing to put a using in lots of places across the OSG to just quieten 
inappropriate warnings is pretty crappy.  The more superfluous code you have in 
your code base the less easy it is to read, the easier it to break.  This makes 
me very wary of jumping through hoops to quieten dodgy warnings from the 
compilers.

Robert.



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

Re: [osg-users] ShaderComposer::releaseGLObjects warning

[Robert Osfield]

Hi Andy,

On 27 April 2016 at 19:09, Andy Skinner  wrote:

> Yes, the "using" statement does quiet the warning.
>

Good to hear.


>
>
> Does that mean this is the solution, or that this just shows that there
> isn't a problem?  The reason I ask is that we've discussed the "using"
> statement for things like this before, and I don't believe you were in
> favor of it.  But using it would let us remove a bunch of warning handling
> in our use of OSG.
>
>
Needing to put a using in lots of places across the OSG to just quieten
inappropriate warnings is pretty crappy.  The more superfluous code you
have in your code base the less easy it is to read, the easier it to
break.  This makes me very wary of jumping through hoops to quieten dodgy
warnings from the compilers.

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

Re: [osg-users] Use cases of MultipassTechnique?

[Robert Osfield]

HI Alex,

MultiPassTechnique will be able to handle rendering of 3D elements that
intersect the volume, this includes arbitrary slice geometry like in the
example.  Simply create the slice geometries yourself with the appropriate
texture mapping and then place them in the scene.  When the
MiltiPassTechnique renders it will render the 3d scene to a colour buffer
and depth buffer then use this when rendering the volume.

I don't recall off the top of my head how you pass on the 3d subgraph, it's
probably just added as a child.  Sorry I can't be more specific, it's been
a few years since I wrote it and am away from my dev machine right now.

Robert.

On 27 April 2016 at 18:52, Alex Taylor  wrote:

> All,
>
> I've posted recently with a debugging question related to my exploration
> of MultipassTechnique. Robert has provided guidance on how to proceed with
> my debugging problem, but I have a conceptual question about what the
> practical use cases are when a person would choose to use
> MultipassTechnique because its still not totally clear to me.
>
> There are two effects I'm trying to achieve, both are already implemented
> in the Medical Image application Slicer that uses VTK as the rendering
> backend. I'm wondering if either of these effects are possible using
> MultipassTechnique, or really any of the volume rendering methods exposed
> in the osgVolume nodekit. I was hoping that if someone knows that either of
> both of the things that I want to do are not possible off hand that they
> could tell me so that I can save myself some time.
>
> 1) If you refer to the two images below, the white bounding box represents
> a "region of interest" that can be used to define clipping on the volume.
> In the first image, the ROI box includes the entire volume. In the second
> image, the upper face of the ROI bounding box has been lowered along the Z
> dimension to apply clipping to the volume axially. Everything above the
> upper face of the clipping ROI is not rendered. You can see this in the
> images below because I've moved the ROI below the 2-D axial slice, where as
> the volume structure above the slice is visible in the first image.
>
> *My first question*, is this effect possible by defining a "hull" with
> MultipassTechnique where one would specify an osg::Geode and some quads to
> define the bounding ROI?
>
> 2) In both images, a grayscale 2-D axial "slice" is displayed in the 3-D
> rendering demonstrating where a given 2-D slice plane is in the context of
> the 3-D structure. *My second question: *Would MultipassTechnique allow
> me to accurately render the "slices" as as part of the geometry passed in
> as children of the tile and allow me to get the depth right of where the
> slice intersects the volume structure?
>
> If no one knows offhand, forgive this rather lengthy post. I've just
> trying to get calibrated on the uses of MultipassTechnique and I thought
> these concrete examples would help clarify my questions.
>
> [image: volumeROIExample.jpg][image: volumeROIExampleNarrowedROI.jpg]
>
> ___
> 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] ShaderComposer::releaseGLObjects warning

[Andy Skinner]

Yes, the "using" statement does quiet the warning.

Does that mean this is the solution, or that this just shows that there isn't a 
problem?  The reason I ask is that we've discussed the "using" statement for 
things like this before, and I don't believe you were in favor of it.  But 
using it would let us remove a bunch of warning handling in our use of OSG.

thanks
andy

From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: Wednesday, April 27, 2016 5:55 AM
To: OpenSceneGraph Users 
Subject: Re: [osg-users] ShaderComposer::releaseGLObjects warning

Hi Andy,

On 26 April 2016 at 20:31, Andy Skinner 
> wrote:
Thanks for that fix.  There is a remaining issue, and I'm not sure if you would 
see it as a bug or a dodgy compiler warning.  :)

We get a similar message about osgUtil::CullVisitor::clone().

NodeVisitor uses META_Object, which brings in:
virtual osg::Object* clone(const osg::CopyOp& copyop) const { return new name 
(*this,copyop); }

But CullVisitor defines clone as:
virtual CullVisitor* clone() const { return new CullVisitor(*this); }

They differ in whether they take an argument.  I believe we've discussed this 
kind of thing before when considering using "using", and it was, if I remember 
correctly, a dodgy compiler warning then.


The osg::ShaderComposer warning did highlight a bug, but this warning isn't 
highlighting an actual error.  If one calls clone(osg::CopyOp) then you'll 
still git the correct clone() method.  It does highlight what is not ideal 
coding style, and in this case it's a historical reason why there is this 
clone() convenience method.  These days a osg::clone(object) would do just as 
well without requiring the extra method, but this is a relatively modern 
addition.
Could you try doing adding:
   using NodeVisitor::clone;
To the include/osgUtil/CullVisitor and see if that quietens the warning.
Robert.


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

[osg-users] Use cases of MultipassTechnique?

[Alex Taylor]

All,

I've posted recently with a debugging question related to my exploration of
MultipassTechnique. Robert has provided guidance on how to proceed with my
debugging problem, but I have a conceptual question about what the
practical use cases are when a person would choose to use
MultipassTechnique because its still not totally clear to me.

There are two effects I'm trying to achieve, both are already implemented
in the Medical Image application Slicer that uses VTK as the rendering
backend. I'm wondering if either of these effects are possible using
MultipassTechnique, or really any of the volume rendering methods exposed
in the osgVolume nodekit. I was hoping that if someone knows that either of
both of the things that I want to do are not possible off hand that they
could tell me so that I can save myself some time.

1) If you refer to the two images below, the white bounding box represents
a "region of interest" that can be used to define clipping on the volume.
In the first image, the ROI box includes the entire volume. In the second
image, the upper face of the ROI bounding box has been lowered along the Z
dimension to apply clipping to the volume axially. Everything above the
upper face of the clipping ROI is not rendered. You can see this in the
images below because I've moved the ROI below the 2-D axial slice, where as
the volume structure above the slice is visible in the first image.

*My first question*, is this effect possible by defining a "hull" with
MultipassTechnique where one would specify an osg::Geode and some quads to
define the bounding ROI?

2) In both images, a grayscale 2-D axial "slice" is displayed in the 3-D
rendering demonstrating where a given 2-D slice plane is in the context of
the 3-D structure. *My second question: *Would MultipassTechnique allow me
to accurately render the "slices" as as part of the geometry passed in as
children of the tile and allow me to get the depth right of where the slice
intersects the volume structure?

If no one knows offhand, forgive this rather lengthy post. I've just trying
to get calibrated on the uses of MultipassTechnique and I thought these
concrete examples would help clarify my questions.

[image: volumeROIExample.jpg][image: volumeROIExampleNarrowedROI.jpg]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ShaderComposer::releaseGLObjects warning

[Robert Osfield]

Hi Andy,

On 26 April 2016 at 20:31, Andy Skinner  wrote:

> Thanks for that fix.  There is a remaining issue, and I'm not sure if you
> would see it as a bug or a dodgy compiler warning.  :)
>
>
>
> We get a similar message about osgUtil::CullVisitor::clone().
>
>
>
> NodeVisitor uses META_Object, which brings in:
>
> virtual osg::Object* clone(const osg::CopyOp& copyop) const { return new
> name (*this,copyop); }
>
>
>
> But CullVisitor defines clone as:
>
> virtual CullVisitor* clone() const { return new
> CullVisitor(*this); }
>
>
>
> They differ in whether they take an argument.  I believe we've discussed
> this kind of thing before when considering using "using", and it was, if I
> remember correctly, a dodgy compiler warning then.
>
>
The osg::ShaderComposer warning did highlight a bug, but this warning isn't
highlighting an actual error.  If one calls clone(osg::CopyOp) then you'll
still git the correct clone() method.  It does highlight what is not ideal
coding style, and in this case it's a historical reason why there is this
clone() convenience method.  These days a osg::clone(object) would do just
as well without requiring the extra method, but this is a relatively modern
addition.

Could you try doing adding:

   using NodeVisitor::clone;

To the include/osgUtil/CullVisitor and see if that quietens the warning.

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

Re: [osg-users] OpenSceneGraph 3.4.0, latest git master: build of ffmpeg plugin fails after upgrade to ffmpeg 3.0+

[Robert Osfield]

Hi Ben,

On 27 April 2016 at 10:22, Ben Woods  wrote:

> I have created a pull request to commit this ffmpeg3 patch against the
> master OpenSceneGraph repository on GitHub:
> https://github.com/openscenegraph/OpenSceneGraph/pull/70
>

For now the official route for submissions to send whole modified files to
the osg-submissions mailing list.  I've found the git pull mechanism
problematic, until I find efficient ways around it's diffidences I'll be
sticking to the route outlined on the OSG website's submission page.

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

Re: [osg-users] OpenSceneGraph 3.4.0, latest git master: build of ffmpeg plugin fails after upgrade to ffmpeg 3.0+

[Ben Woods]

I have created a pull request to commit this ffmpeg3 patch against the master 
OpenSceneGraph repository on GitHub:
https://github.com/openscenegraph/OpenSceneGraph/pull/70

Regards,
Ben

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66984#66984





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

Re: [osg-users] osgVolume::MultipassTechnique use

[Robert Osfield]

Hi Alex,

A stack trace with debugging info would be far more useful and should be
able to pinpoint the cause of the crash, or at least give some clues of
where to look.

Also, does the osgvolume example crash when you use the MultiPassTechnique?

Robert.

On 26 April 2016 at 21:35, Alex Taylor  wrote:

> Hey all,
>
> I'm running into a segmentation violation when I attempt to use
> osgVolume::MultipassTechnique more or less as a drop in replacement for
> RayTracedTechnique using OSG 3.4. My use of RayTracedTechnique works and
> renders fine.
>
> Here is an partial code listing demonstrating my use of MultipassTechnique:
>
> *void setVolumeProperties(osg::ref_ptr
> volume,osg::ref_ptr tile,*
> *osg::ref_ptr layer,
> VolumePropertyManager ,
> osg::ref_ptr volumeScene)*
> *{*
>
> *// FixedFunctionTechnique turns on GL_LIGHTING, which breaks the
> color rendering.*
> *osg::StateSet* stateset = volume->getOrCreateStateSet();*
>
> *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);*
> *layer->addProperty(new
> osgVolume::SampleDensityWhenMovingProperty(volumeProperties.sampleDensityWhenMoving));*
> *layer->addProperty(new
> osgVolume::SampleDensityProperty(volumeProperties.sampleDensity));*
> *} else if (volumeProperties.volumeTechnique ==
> VolumeTechnique::Multipass) {*
> *osg::ref_ptr multipass = new
> osgVolume::MultipassTechnique();*
> *tile->setVolumeTechnique(multipass.get());*
> *volumeScene->addChild(volume.get());*
> *volume->getOrCreateStateSet();*
> *layer->addProperty(new osgVolume::SampleRatioProperty(1.0f));*
> *layer->addProperty(new
> osgVolume::SampleRatioWhenMovingProperty(0.5f));*
>
> *} 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));*
> *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());*
> *}*
>
> The following function returns the Node * that will be passed to the
> viewer. I either return a osgVolume::Volume * or osgVolume::VolumeScene *
> object depending on whether I'm using multipass rendering as my Node *.
>
> *osg::Node* BP_createPeerHelper(Volume& v,*
> *hg::SceneClient& client,*
> *const gui_objects::Cookie& owner,*
> *hg::UpdateState& us) {*
>
> *osg::ref_ptr volume = new osgVolume::Volume;*
> *osg::ref_ptr volumeScene = new
> osgVolume::VolumeScene;*
>
> *const mxArray* data = v.getData();*
> *VolumePropertyManager volumeProperties(v,us);*
>
> *if (data != NULL && mxGetNumberOfDimensions(data) == 3 &&
> mxGetClassID(data) == mxUINT8_CLASS) {*
>
>
> *osg::ref_ptr tile = new
> osgVolume::VolumeTile;*
> *volume->addChild(tile.get());*
>
> *// If we are using FixedFunctionTechnique, we need to apply
> the transfer function to get a new allocated RGBA memory on the CPU to pass
> to OSG.*
> *// Otherwise, we can pass the intensity data directly to the
> card. GPU shaders does the RGBA directly.*
> *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());*
>
> *
> setVolumeProperties(volume,tile,layer,volumeProperties,volumeScene);*
>
> *// Our original implementation positioned the bbox [-0.5,0.5]
> in each dimension.*
> *// FixedFunctionTechnique applies the locator matrix to the a
> unit cube [0 1] in 

[osg-users] compositeviewer with mutliple windowmanager

[Sebastian Schmidt]

What is the normal approach to create multiple windows, each filled with 
widgets and/or 3d models?

In my opinion i only need to merge the code in osg examples for osgwidgetwindow 
and osgcompositeviewer.

So i created two windowmanager and stuff for each view and added them to the 
compositeviewer.

It works for now, but i'm not sure if its the right approach.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=66981#66981





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

Re: [osg-users] Qt OpenGL Warning opengl

[Robert Osfield]

HI Auke-Dirke,

On 25 April 2016 at 14:07, Auke-Dirk Pietersma  wrote:

> I have the following issue. Whenever i choose to render a scene with
> opengl greater than 2.1 i get the following messages.
>
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode
> 0xb50
> Warning: detected OpenGL error 'invalid enumerant' after applying GLMode
> 0x4000
> Warning: detected OpenGL error 'invalid operation' after applying
> attribute LightModel
>
> Not only do i obtain these messages, the scene also does not get rendered.
>
> Nothing fancy has been done, see this init snippet:
>
>  graphicsWindow_ = new osgViewer::GraphicsWindowEmbedded( this->x(),
> this->y(),this->width(),this->height() );
> viewer_ = new osgViewer::Viewer;
>
> osg::Camera* camera = new osg::Camera;
> camera->setViewport( 0, 0, this->width(), this->height() );
> float aspectRatio = static_cast( this->width()) /
> static_cast( this->height() );
> camera->setClearColor( osg::Vec4( 0.f, 0.f, 1.f, 1.f ) );
> camera->setProjectionMatrixAsPerspective( 30.f, aspectRatio, 1.f,
> 1000.f );
> camera->setGraphicsContext( graphicsWindow_ );
> viewer_->setCamera(camera);
>
> _earthManip = new osgEarth::Util::EarthManipulator;
>
> viewer_->setCameraManipulator(_earthManip, false);
> viewer_->addEventHandler(new osgViewer::StatsHandler);
>
>
> osg::ref_ptr group = new osg::Group();
> _mapNode = createMapNode();
> group->addChild(_mapNode);
> _earthManip->setNode( _mapNode->getTerrainEngine() );
>
> viewer_->setSceneData(group.release());
>
> I'm Working on Linux with Qt5.6 on an ATI HAWAII , Radeon R9 Series.
>
> Can someone provide me with some hints/tips?
>

I presume you are using Qt to create the graphics context.  Is that you are
creating a context with a core profile with the compatibility profile
disabled?  The later is required for using the old fixed function pipeline
attributes and modes.

The OSG is able to use all GL3+GL4 features by testing for them at run-time
even if you just create a GL2.x graphics context so there little need for
explictly asking for GL3 core profile context.

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