Re: [osg-users] osgdepthpeeling or osgoit
I've just posted an overhauled version of osgoit to osg-submissions. You may want to have a look. Compositing with solid geometry is now possible, and mix-and-match with GLSL shaders in transparent objects works fine. Tested on nVidia so far. Hopefully that HeatMap GLSL thing also renders on Intel. Christian 2013/2/17 Mathias Fröhlich mathias.froehl...@gmx.net Hi List, On Sunday, February 17, 2013 08:20:55 Sajjadul Islam wrote: are both the same is theory ? What are the differences between them implementation-wise ? osgoit concentrates on the order independent transparency and does this with a minimal requirement on the state of the displayed model. Also it uses a minimal set of OpenGL features/extensions to make this run on as much hardware/drivers as possible. Greetings Mathias ___ 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] osgdepthpeeling or osgoit
I am currently stuck with OSG 3.0.1 (latest stable release) not being able to provide an osg::Uniform corresponding to the GLSL sampler2DRectShadow. The enum does not yet contain the *SAMPLER_2D_RECT_SHADOW type. ;-(* I would have to switch to a later development release, which is a major undertaking. Alternatively I might have to switch from Texture Rectangles to regular Texture2D objects, fortunately there is a #define for that. Christian 2013/2/20 Mathias Fröhlich mathias.froehl...@gmx.net Hi, On Tuesday, February 19, 2013 19:07:59 Christian Buchner wrote: After some futile attempts to make the nVidia dual depth peeling compatible with non-Vidia cards by dropping the vendor specific extensions I've decided to go forward with the DepthPeeling code from osgoit. I noticed that as soon as there are GLSL shaders attached to the object being rendered, the shadow depth testing seems to fail (is this fixed function stuff?). Or in other words, these statements don't have an effect anymore. _depthTextures[i]-setShadowComparison(true); _depthTextures[i]-setShadowAmbient(0); // The r value if the test fails _depthTextures[i]-setShadowCompareFunc(osg::Texture::GREATER); _depthTextures[i]-setShadowTextureMode(osg::Texture::INTENSITY); It seems that I will have to roll my own shadow comparison in GLSL. This would be in the fragment shader, I presume? Without looking in depth into this and just out of my head. Yes, in the Fragment shader have a shadow sampler unifom bound on that texture and compare for the .r component. Then discard the pixel if that test fails. You need to rescale the projection space fragement position apropriately to the input of the shadow sampler. If I remember right there was also some problem with the demo with models not being close to the origin. I believe something with the near far computation in interaction with osgoit is not entirely correct. Greetings Mathias ___ 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] osgdepthpeeling or osgoit
Hi iirc you can use just integer uniform for any sampler, specific sampler type matters only inside glsl shader Cheers. 20.02.2013, 13:25, "Christian Buchner" christian.buch...@gmail.com: I am currently stuck with OSG 3.0.1 (latest stable release) not being able to provide an osg::Uniform corresponding to the GLSL sampler2DRectShadow. The enum does not yet contain the SAMPLER_2D_RECT_SHADOW type. ;-( I would have to switch to a later development release, which is a major undertaking.Alternatively I might have to switch from Texture Rectangles to regular Texture2D objects, fortunately there is a #define for that. Christian2013/2/20 Mathias Fröhlich mathias.froehl...@gmx.net Hi, On Tuesday, February 19, 2013 19:07:59 Christian Buchner wrote: After some futile attempts to make the nVidia dual depth peeling compatible with non-Vidia cards by dropping the vendor specific extensions I've decided to go forward with the DepthPeeling code from osgoit. I noticed that as soon as there are GLSL shaders attached to the object being rendered, the shadow depth testing seems to fail (is this fixed function stuff?). Or in other words, these statements don't have an effect anymore. _depthTextures[i]-setShadowComparison(true); _depthTextures[i]-setShadowAmbient(0); // The r value if the test fails _depthTextures[i]-setShadowCompareFunc(osg::Texture::GREATER); _depthTextures[i]-setShadowTextureMode(osg::Texture::INTENSITY); It seems that I will have to roll my own shadow comparison in GLSL. This would be in the fragment shader, I presume? Without looking in depth into this and just out of my head. Yes, in the Fragment shader have a shadow sampler unifom bound on that texture and compare for the .r component. Then discard the pixel if that test fails. You need to rescale the projection space fragement position apropriately to the input of the shadow sampler. If I remember right there was also some problem with the demo with models not being close to the origin. I believe something with the near far computation in interaction with osgoit is not entirely correct. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] osgdepthpeeling or osgoit
I am currently finding a problem with the osgoit demo (as found in OSG 3.0.1). The osgviewer by default starts in full screen mode, and never generates an initial RESIZE event. I am testing this on Windows, if that matters. The _texWidth and _texHeight members of the DepthPeeling object remain at their default values of 0. While this seems to generate reasonably sized shadowing maps (why?), this has the unfortunate side effect that the CullCallback never receives an update with the correct texture width and height. When not using texture rectangles and when USE_NON_POWER_OF_TWO_TEXTURE #define is not set, it will execute this line: m.postMultScale(osg::Vec3d(viewport-width()/double(_texWidth), viewport-height()/double(_texHeight), 1)); producing an invalid scaling matrix. So the screen stays blank (no model is rendered at all) when using square Texture2D objects. Feeding an appropriate default value to the DepthPeeling constructor with the screen resolution fixes it. Christian 2013/2/17 Mathias Fröhlich mathias.froehl...@gmx.net Hi List, On Sunday, February 17, 2013 08:20:55 Sajjadul Islam wrote: are both the same is theory ? What are the differences between them implementation-wise ? osgoit concentrates on the order independent transparency and does this with a minimal requirement on the state of the displayed model. Also it uses a minimal set of OpenGL features/extensions to make this run on as much hardware/drivers as possible. Greetings Mathias ___ 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] osgdepthpeeling or osgoit
Hi i think this can be fixed with just sending resize even manually after viewer have been realized and event handlers set up: osgGA::GUIEventAdapter * event = viewer.getEventQueue()-createEvent(); event-setEventType(osgGA::GUIEventAdapter::RESIZE); viewer.getEventQueue()-addEvent(event); or int x, y, width, height; osgViewer::ViewerBase::Windows windows; viewer.getWindows(windows); windows.front()-getWindowRectangle(x,y,width,height); viewer.getEventQueue()-windowResize(x,y,width,height); I believe both pieces should work same way Cheers. 20.02.2013, 15:31, "Christian Buchner" christian.buch...@gmail.com: I am currently finding a problem with the osgoit demo (as found in OSG 3.0.1). The osgviewer by default starts in full screen mode, and never generates an initial RESIZE event. I am testing this on Windows, if that matters.The _texWidth and _texHeight members of the DepthPeeling object remain at their default values of 0. While this seems to generate reasonably sized shadowing maps (why?), this has the unfortunate side effect that the CullCallback never receives an update with the correct texture width and height. When not using texture rectangles and when USE_NON_POWER_OF_TWO_TEXTURE #define is not set, it will execute this line: m.postMultScale(osg::Vec3d(viewport-width()/double(_texWidth), viewport-height()/double(_texHeight), 1));producing an invalid scaling matrix. So the screen stays blank (no model is rendered at all) when using square Texture2D objects. Feeding an appropriate default value to the DepthPeeling constructor with the screen resolution fixes it. Christian2013/2/17 Mathias Fröhlich mathias.froehl...@gmx.net Hi List, On Sunday, February 17, 2013 08:20:55 Sajjadul Islam wrote: are both the same is theory ? What are the differences between them implementation-wise ? osgoit concentrates on the order independent transparency and does this with a minimal requirement on the state of the displayed model. Also it uses a minimal set of OpenGL features/extensions to make this run on as much hardware/drivers as possible. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org,___osg-users mailing listosg-users@lists.openscenegraph.orghttp://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] osgdepthpeeling or osgoit
For the record, with a little editing one can make any OSG object
transparent
Here's a modified state set that makes the dump truck work with the osgoit
demo. I added blending, moved everything to TRANSPARENT_BIN and changed the
alpha settings in the material. And then it works as expected in the osgoit
viewer.
StateSet {
UniqueID StateSet_1
DataVariance STATIC
rendering_hint TRANSPARENT_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_LIGHTING ON
GL_BLEND ON
BlendFunc {
DataVariance STATIC
source SRC_ALPHA
destination ONE
}
Material {
DataVariance STATIC
ColorMode OFF
ambientColor 0.2 0.2 0.2 0.4
diffuseColor 0.8 0.8 0.8 0.4
specularColor 0 0 0 0.4
emissionColor 0 0 0 0.4
shininess 0
}
}
I would find the osgoit demo more useful if it had a command line switch to
override the material settings and blend function of the loaded model, so
one can run this with the vast majority of existing OSG models from the
default data directory.
I will now try to understand the osgoit code and then try to roll my own
implementation of either the dual depth peeling code, or the weighted
average method from the nVidia paper.
The reason is that I will have to show some transparent buildings in our
radio simulator and once we start adding some interior walls to the
geometry, things become too complicated for the simpler algorithms. Depth
peeling seems to be the way to go for us.
Thank you for providing the osgoit demo!
2013/2/19 Mathias Fröhlich mathias.froehl...@gmx.net
Hi,
On Monday, February 18, 2013 15:56:02 Christian Buchner wrote:
does osgoit require the loaded 3D model to be transparent already?
What do you mean?
If parts of your model are not transparent they should not render
transparent?
Right?
I remember that I was able to run osgdepthpeeling with the dumptruck
model
successfully, but with the osgoit sample I can't get this to render any
transparency at all.
It did for me the other way round. I never saw something sensible with
osgdepthpeeling. But loading a model with transparent triangles renders
fine
with osgoit. At least the ones that I usually tried.
Only if your model contains protected state attributes that need to be
overwritten this can hurt. Especially the blend mode need to be overruled
by
the viewer code.
For the zurich paper, I also read that. IIRC the loaded model needs to have
all the state replaced by the viewer codes for multiple render targets
which
makes all the colors and textures and whatnot just disappear or requires a
lot
work to translate that.
That simpler algorithm does not need any cooperation from the model except
the
blend state must not be protected.
So it's about to view a model just like it would look like with osgviewer
but
with correct(er) transparency.
Greetings
Mathias
___
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] osgdepthpeeling or osgoit
After some futile attempts to make the nVidia dual depth peeling compatible
with non-Vidia cards by dropping the vendor specific extensions I've
decided to go forward with the DepthPeeling code from osgoit.
I noticed that as soon as there are GLSL shaders attached to the object
being rendered, the shadow depth testing seems to fail (is this fixed
function stuff?). Or in other words, these statements don't have an effect
anymore.
_depthTextures[i]-setShadowComparison(true);
_depthTextures[i]-setShadowAmbient(0); // The r value if the test
fails
_depthTextures[i]-setShadowCompareFunc(osg::Texture::GREATER);
_depthTextures[i]-setShadowTextureMode(osg::Texture::INTENSITY);
It seems that I will have to roll my own shadow comparison in GLSL. This
would be in the fragment shader, I presume?
2013/2/19 Christian Buchner christian.buch...@gmail.com
For the record, with a little editing one can make any OSG object
transparent
Here's a modified state set that makes the dump truck work with the osgoit
demo. I added blending, moved everything to TRANSPARENT_BIN and changed the
alpha settings in the material. And then it works as expected in the osgoit
viewer.
StateSet {
UniqueID StateSet_1
DataVariance STATIC
rendering_hint TRANSPARENT_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_LIGHTING ON
GL_BLEND ON
BlendFunc {
DataVariance STATIC
source SRC_ALPHA
destination ONE
}
Material {
DataVariance STATIC
ColorMode OFF
ambientColor 0.2 0.2 0.2 0.4
diffuseColor 0.8 0.8 0.8 0.4
specularColor 0 0 0 0.4
emissionColor 0 0 0 0.4
shininess 0
}
}
I would find the osgoit demo more useful if it had a command line switch
to override the material settings and blend function of the loaded model,
so one can run this with the vast majority of existing OSG models from the
default data directory.
I will now try to understand the osgoit code and then try to roll my own
implementation of either the dual depth peeling code, or the weighted
average method from the nVidia paper.
The reason is that I will have to show some transparent buildings in our
radio simulator and once we start adding some interior walls to the
geometry, things become too complicated for the simpler algorithms. Depth
peeling seems to be the way to go for us.
Thank you for providing the osgoit demo!
2013/2/19 Mathias Fröhlich mathias.froehl...@gmx.net
Hi,
On Monday, February 18, 2013 15:56:02 Christian Buchner wrote:
does osgoit require the loaded 3D model to be transparent already?
What do you mean?
If parts of your model are not transparent they should not render
transparent?
Right?
I remember that I was able to run osgdepthpeeling with the dumptruck
model
successfully, but with the osgoit sample I can't get this to render any
transparency at all.
It did for me the other way round. I never saw something sensible with
osgdepthpeeling. But loading a model with transparent triangles renders
fine
with osgoit. At least the ones that I usually tried.
Only if your model contains protected state attributes that need to be
overwritten this can hurt. Especially the blend mode need to be overruled
by
the viewer code.
For the zurich paper, I also read that. IIRC the loaded model needs to
have
all the state replaced by the viewer codes for multiple render targets
which
makes all the colors and textures and whatnot just disappear or requires
a lot
work to translate that.
That simpler algorithm does not need any cooperation from the model
except the
blend state must not be protected.
So it's about to view a model just like it would look like with osgviewer
but
with correct(er) transparency.
Greetings
Mathias
___
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] osgdepthpeeling or osgoit
Hi, On Tuesday, February 19, 2013 19:07:59 Christian Buchner wrote: After some futile attempts to make the nVidia dual depth peeling compatible with non-Vidia cards by dropping the vendor specific extensions I've decided to go forward with the DepthPeeling code from osgoit. I noticed that as soon as there are GLSL shaders attached to the object being rendered, the shadow depth testing seems to fail (is this fixed function stuff?). Or in other words, these statements don't have an effect anymore. _depthTextures[i]-setShadowComparison(true); _depthTextures[i]-setShadowAmbient(0); // The r value if the test fails _depthTextures[i]-setShadowCompareFunc(osg::Texture::GREATER); _depthTextures[i]-setShadowTextureMode(osg::Texture::INTENSITY); It seems that I will have to roll my own shadow comparison in GLSL. This would be in the fragment shader, I presume? Without looking in depth into this and just out of my head. Yes, in the Fragment shader have a shadow sampler unifom bound on that texture and compare for the .r component. Then discard the pixel if that test fails. You need to rescale the projection space fragement position apropriately to the input of the shadow sampler. If I remember right there was also some problem with the demo with models not being close to the origin. I believe something with the near far computation in interaction with osgoit is not entirely correct. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdepthpeeling or osgoit
does osgoit require the loaded 3D model to be transparent already? I remember that I was able to run osgdepthpeeling with the dumptruck model successfully, but with the osgoit sample I can't get this to render any transparency at all. 2013/2/17 Mathias Fröhlich mathias.froehl...@gmx.net Hi List, On Sunday, February 17, 2013 08:20:55 Sajjadul Islam wrote: are both the same is theory ? What are the differences between them implementation-wise ? osgoit concentrates on the order independent transparency and does this with a minimal requirement on the state of the displayed model. Also it uses a minimal set of OpenGL features/extensions to make this run on as much hardware/drivers as possible. Greetings Mathias ___ 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] osgdepthpeeling or osgoit
Hi, On Monday, February 18, 2013 15:56:02 Christian Buchner wrote: does osgoit require the loaded 3D model to be transparent already? What do you mean? If parts of your model are not transparent they should not render transparent? Right? I remember that I was able to run osgdepthpeeling with the dumptruck model successfully, but with the osgoit sample I can't get this to render any transparency at all. It did for me the other way round. I never saw something sensible with osgdepthpeeling. But loading a model with transparent triangles renders fine with osgoit. At least the ones that I usually tried. Only if your model contains protected state attributes that need to be overwritten this can hurt. Especially the blend mode need to be overruled by the viewer code. For the zurich paper, I also read that. IIRC the loaded model needs to have all the state replaced by the viewer codes for multiple render targets which makes all the colors and textures and whatnot just disappear or requires a lot work to translate that. That simpler algorithm does not need any cooperation from the model except the blend state must not be protected. So it's about to view a model just like it would look like with osgviewer but with correct(er) transparency. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgdepthpeeling or osgoit
Hi List, On Sunday, February 17, 2013 08:20:55 Sajjadul Islam wrote: are both the same is theory ? What are the differences between them implementation-wise ? osgoit concentrates on the order independent transparency and does this with a minimal requirement on the state of the displayed model. Also it uses a minimal set of OpenGL features/extensions to make this run on as much hardware/drivers as possible. Greetings Mathias ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
