Re: [osg-users] Shadow frustum culling

[Gedalia Pasternak]

Thanks Terry, yes that’s my exact problem, I have a cascaded shadow map
system for a directional light, where objects just outside the shadow map
frustra don’t alway cast into the shadow map. I’ll take a look at the view
class.
Gedalia

On Mon, Oct 29, 2018 at 5:06 PM Terry Welsh  wrote:

> Gedalia,
> If I understand the original question correctly, you're not seeing
> shadows that are cast by off-screen objects. I had that exact problem
> back around 2006 and Robert solved it with the introduction of the
> View class. Sorry, I don't remember the details beyond that and can't
> find our old discussion archived anywhere.
> - Terry
>
> > Hi Gadalia,
> >
> > The OSG doesn't culling per Camera with each camera's own view frustum
> used
> > for culling, this means the shadow camera should only cull things that
> are
> > in it's frustum.  If it's culling objects that you think should be in the
> > frustum then perhaps it's just set up with the wrong projection matrix
> > settings.
> >
> > Robert
> >
> > On Mon, 29 Oct 2018 at 18:44, Gedalia Pasternak 
> wrote:
> >
> > >
> > > Hi List,
> > > I've noticed that when using a camera for shadow casting it can often
> cull
> > > out objects that are just outside of the frustum but cast shadows into
> the
> > > scene. Is there any way to decouple the camera frustum culling
> calculation
> > > from the rendering one, even just increasing the culling frustum size
> by
> > > 10-15% might help.
> > > Thanks
> > > -Gedalia
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Shadow frustum culling

[Gedalia Pasternak]

Hi List,
I've noticed that when using a camera for shadow casting it can often cull
out objects that are just outside of the frustum but cast shadows into the
scene. Is there any way to decouple the camera frustum culling calculation
from the rendering one, even just increasing the culling frustum size by
10-15% might help.
Thanks
-Gedalia
-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Minor change proposal : Blacklist usage of all unsized texture internat format

[Gedalia Pasternak]

glTexStorage is much faster then glTexImage because it allocates the whole
memory buffer in one shot, glTeximage take quite a bit longer to allocate
the memory, not sure if it's 1.x or even longer than that due to
reallocing and moving the memory if needed. I'm running off 3.4 and made a
number of fixes to try and make sure glTexStorage was used all of the time.
-gedalia

On Thu, Aug 16, 2018 at 3:41 AM, Robert Osfield 
wrote:

> Hi Julien,
>
> On Thu, 16 Aug 2018 at 02:30, Julien Valentin
>  wrote:
> > Immutable Storage  mandatory for lot of GL4 features:
> > TextureImage synchronization,TextureView, persistance mapping, virtual
> texture and surely other stuff I didn't used yet
>
> Thanks, this is what I was missing.  I had been searching online for
> discussion about glTexStorage vs glTexImage but didn't come across
> compelling reasons.
>
> If these modern features don't work without glTexStorage usage then do
> we have to have a flag in osg::Texture saying it's being actively
> used?  Or is good enough to just make sure glTexStorage is used widely
> enough and all GL4 usage that depends upon it all check the
> GLExtensions.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in Cull Visitor

[Gedalia Pasternak]

Does that mean it’s used incorrectly in
OcclusionQueryNode::getPassed()? That was what I was basing my
understanding on.
Gedalia


On Sun, May 13, 2018 at 10:57 AM Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Gedalia,
>
> On 13 May 2018 at 15:27, Gedalia Pasternak <gpaster...@mak.com> wrote:
> >But won’t just simply removing it mean that adding a render leaf will
> be
> > changing what the current frame is?
>
> TraversalNumber is local value to a visitor it isn't a the frame
> number, this is retrieved with the osg::FrameStamp::getFrameStamp().
>
> >  For occlusion nodes I’ve realized that it’s not currently possible to
> use
> > them within instanced hierarchy without tracking which traversal
> generated a
> > given query, the cull visitor traversal index (along with other changes)
> can
> > help disambiguate which draw query it was.
>
> The FrameStamp is probably what you should be using, it's attached the
> CullVisitor and the osg::State as well as the viewer.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in Cull Visitor

[Gedalia Pasternak]

Thanks Robert,
   But won’t just simply removing it mean that adding a render leaf will be
changing what the current frame is?
 For occlusion nodes I’ve realized that it’s not currently possible to use
them within instanced hierarchy without tracking which traversal generated
a given query, the cull visitor traversal index (along with other changes)
can help disambiguate which draw query it was.
Gedalia

On Sun, May 13, 2018 at 6:55 AM Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Gedalia,
>
> Well spotted, this issue has been in the code for almost two decades
> without anyone noticing.  I've removed the duplicate from CullVisitor
> and checked this into OSG master and the 3.6 branch.
>
> Robert.
>
> On 12 May 2018 at 21:34, Gedalia Pasternak <gpaster...@mak.com> wrote:
> > Both CullVisitor and it's base class NodeVisitor have members named
> > _traversalNumber. Yielding duplicate member variables with the same name,
> > and inconsistent behavior depending on how you access the class.
> > Cull visitor's should be renamed, maybe to _cullTraversalNumber or
> something
> > that wouldn't conflict with the base class. An accessor would be nice as
> > well. In the case of NodeVisitor it's what frame it's up to, for cull
> > visitor it's what accepted object it's up to (
> >// Otherwise need to create new renderleaf.
> > RenderLeaf* renderleaf = new
> > RenderLeaf(drawable,projection,matrix,depth,_traversalNumber++);
> > )
> >
> > -Gedalia
> >
> > ___
> > 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
>
-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Bug in Cull Visitor

[Gedalia Pasternak]

Both CullVisitor and it's base class NodeVisitor have members named
_traversalNumber. Yielding duplicate member variables with the same name,
and inconsistent behavior depending on how you access the class.
Cull visitor's should be renamed, maybe to _cullTraversalNumber or
something that wouldn't conflict with the base class. An accessor would be
nice as well. In the case of NodeVisitor it's what frame it's up to, for
cull visitor it's what accepted object it's up to (
   // Otherwise need to create new renderleaf.
RenderLeaf* renderleaf = new
RenderLeaf(drawable,projection,matrix,depth,_traversalNumber++);
)

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

Re: [osg-users] Limit in size of VBOs?

[Gedalia Pasternak]

I've seen a perf hit from using VBO's over display lists, but it's been
worth it to be able to debug rendering with NSight, The modern OSG opengl
clean path has a few other perf hits. The various model/view/projection
matrix should probably be a uniform buffer object, instead of independent
uniforms. That speeds up rendering a bit as well.
-gedalia

On Fri, Sep 8, 2017 at 12:17 PM, Robert Osfield 
wrote:

> On 8 September 2017 at 17:13, Antoine Rennuit 
> wrote:
>
>> Robert,
>>
>> Thanks a lot for you answer.
>>
>> Your positions makes sense. As for the overheads in relation to
>> optimizations and default behaviors, my position is that OSG should be as
>> standard as possible (i.e. look like default GL), so as to ease the
>> learning curve - but leave the possibility to optimize. Now, it is only my
>> opinion and you and your 15 years of experience are final judges ;)
>>
>
> 15 years of experience I wish I was so young!
>
> I've actually being using IrisGL then OpenGL since 1992, so 25 years!! :-)
>
> As to default GL, well it's a bit of open book.  Which version of default
> GL? GL1.x, GL2.x, 3.x, 4.x?  GLES 1.x. 2.x, 3.x?  What hardware? What OS?
>
> With middleware like the OSG we're stuck trying to weave out a way through
> all this variations as they evolve over time, it's not a static or unified
> platform we are trying to track.   The OSG can try to hide some of the
> complexities but in the end it's something application developers need to
> be aware of as well.
>
> Robert.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [forum] passing material properties to shader uniforms

[Gedalia Pasternak]

For OpenGL 3.2, I've taken the approach of using an uniform block to
replace the materials, (if you think about this materials are currently
treated as something that is shared between all shaders, which is how they
are implemented in the fixed function pipeline) each material has a buffer
on the GPU, and I just switch the uniform block pointer as part of the
material apply. I found using callbacks really slowed down the scene graph
update as the scene got larger. And there were also a number of bugs I hit
by using material uniforms where scene graph optimizations seemed to lose
them.

-Gedalia

On Thu, Jun 1, 2017 at 10:12 AM, Robert Osfield 
wrote:

> Hi Goran,
>
> In standard OSG (3.2.x, 3.4.0 or the 3.5.x dev series) there isn't any
> way to automatically remap osg::Material to uniforms so you'll have to
> run a traverser through the scene graph and replace the osg::Material
> to osg::Uniform's.
>
> If you are willing to experiment with bleeding edge experimental code
> then have a look at the shader_pipeline branch of the OSG, in this
> branch I'm working on a new scheme for automatically mapping old fixed
> function state like osg::Material to uniforms and #define settings
> that can then be used by #pragma(tic) shader composition to provide a
> fully integrated shader+fixed function state solution.
>
> Robert.
>
> On 15 May 2017 at 14:18, Goran Pantar  wrote:
> > Hi,
> >
> > I'm using OpenGL ES 2.0 and having dificulties to pass the old style
> material properties (ambient, difusse, specular, shininess) to the uniforms
> used in my fragment shader.
> >
> > For the 3d model I use models in 3ds format with multiple materials and
> multiple drawables.
> >
> >
> > As a dirty hack I changed the Material.cpp Material::apply(State&)
> function. This worked properly and I was able to modify this several global
> uniforms used by my shader.
> >
> > Now I'm trying to do this the OSG way using updateCallbacks and visitors
> but the uniform are not updated during the rendering. Probably only the
> last drawable material properties are set to the uniform and than this is
> used when rendering.
> >
> >
> > I expect that there is some perfectly elegant way to do this, so please
> point me in the right direction.
> >
> > Thank you!
> >
> > Cheers,
> > Goran
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=70931#70931
> >
> >
> >
> >
> >
> > ___
> > 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
>



-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] uniform buffers for transform stack and other constants

[Gedalia Pasternak]

Hello,
   I've seen that OSG has some basic primitives for uniform buffers, but
they seem designed for homogeneous data. Most modern engines use uniform
buffers to represent various levels of shader constants based on frequency
of state changing, so you might have a per frame UBO/per pass UBO, a
material UBO, and a per draw call UBO. (one-off object changes might be the
done with the simpler uniform system.)

Typically that data is not homogeneous, but represented by a C structure
that has to be somewhat carefully laid out.
For example I've switched to a UBO for OSG's transform stack:
struct osg_TransformStack
{
   osg::Matrixf ModelViewMatrixInverse;
   osg::Matrixf ModelViewMatrix;
   osg::Matrixf ModelViewProjectionMatrix;
   osg::Matrixf ProjectionMatrix;
   osg::Matrix3 NormalMatrix;
};

That can get mapped to a UBO via
   _extensions->glBufferData(GL_UNIFORM_BUFFER, sizeof(osg_TransformStack),
_transformstack, GL_DYNAMIC_DRAW);

And the UBO in glsl would look like:

struct osg_TransformStack
{
mat4 ModelViewMatrixInverse;
mat4 ModelViewMatrix;
mat4 ModelViewProjectionMatrix;
mat4 ProjectionMatrix;
mat3 NormalMatrix; // Mat3's don't actually map great to std140 layouts
};

layout(std140) uniform osg_transform_stack_block
{
   osg_TransformStack osg;
};

Replacing the individual uniforms that OSG adds to replace the legacy
gl_*Matrix calls in State::convertVertexShaderSourceToOsgBuiltIns() with a
UBO saves me a few ms a frame, but I'm doing all the uniform buffer
management by hand and I've had to significantly modify the state class. (I
think some of the performance gain is from avoiding OSG's uniform
management abstractions as well.)  I've had to do something similar with
materials, otherwise I have significant performance degradation when
switching off the fixed function pipeline.
  Has anyone else experimented with UBO's in this manor? Is there a cleaner
OSG way to do that's still high performance?

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

Re: [osg-users] Tearing hair out over simple GLSL instancing

[Gedalia Pasternak]

you might want to look into glVertexAttribDivisor
https://www.opengl.org/sdk/docs/man4/html/glVertexAttribDivisor.xhtml
That would let you make a vbo with 100 offsets in it and then each
instanced draw call would get a different offset.
you can even send down a 4x3 transform matrix by using more attributes.

On Thu, Dec 22, 2016 at 12:35 PM, Andrew Cunningham  wrote:

> On thinking about this issue, I see the problem. I really only have 4
> vertices, so the value d in my vertex shader just is always pulled from
> locations 0-3 in my array. What I really need to do is access an array of
> offsets in my shader indexed by glInstanceID
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=69744#69744
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern OpenGL and VBO performance

[Gedalia Pasternak]

Just as a follow up, I tried the vao support in the top of master and was
unable to get it to work with a simple openflight terrain.
I've opened an issue with the info here:
https://github.com/openscenegraph/OpenSceneGraph/issues/165
long story short when I hooked up glDebugOutput it crashed in a glDraw
function after the driver sent the following warning
message = GL_INVALID_OPERATION error generated. Invalid VAO/VBO/pointer
usage.
Anyone else have it working?
-gedalia


On Wed, Nov 9, 2016 at 12:53 PM, Gedalia Pasternak <gpaster...@mak.com>
wrote:

> Hello list,
>
> I'm wondering if anyone has done performance testing on the new VAO
> support in 3.6? I'm using 3.4 and see a significant performance hit when
> turning on the GL3 flags and using VBO's, As a test I restored call list
> support and saw a significant performance improvement vs the VBO path. But
> still slower then the non gl3 pipeline. ( Some of these settings are
> embedded in the saved ive file which makes it a bit harder to test
> different code paths.) But OSG seems to be enabling and disabling lots of
> VBO attributes and doesn't particularly draw stuff in a way that's
> optimized to have the minimal number of attribute changes.
>
> I've also added a Material UBO which seems a reasonable replacement for
> the existing attribute which uses deprecated functionality. But it's not
> clear how to do this cleanly. And would need that UBO to be added to all
> shaders.
> It's still unclear to me how enabling gl3 should work. Shader generation
> doesn't automatically happen and there's really very little rendering out
> of the box.
> Gedalia
>
> --
> DI-Guy Engineering Lead, VT MÄK
> 150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
>
>


-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Modern OpenGL and VBO performance

[Gedalia Pasternak]

Hello list,

I'm wondering if anyone has done performance testing on the new VAO
support in 3.6? I'm using 3.4 and see a significant performance hit when
turning on the GL3 flags and using VBO's, As a test I restored call list
support and saw a significant performance improvement vs the VBO path. But
still slower then the non gl3 pipeline. ( Some of these settings are
embedded in the saved ive file which makes it a bit harder to test
different code paths.) But OSG seems to be enabling and disabling lots of
VBO attributes and doesn't particularly draw stuff in a way that's
optimized to have the minimal number of attribute changes.

I've also added a Material UBO which seems a reasonable replacement for the
existing attribute which uses deprecated functionality. But it's not clear
how to do this cleanly. And would need that UBO to be added to all shaders.
It's still unclear to me how enabling gl3 should work. Shader generation
doesn't automatically happen and there's really very little rendering out
of the box.
Gedalia

-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG Running with modern OpenGL

[Gedalia Pasternak]

Thanks Chris,
   OSG earth does have some fixes for materials and lighting, but it would
be cleaner if it was part of OSG core. I'm pursing those as well, just
seems like the core libraries should function out of the box, without
spending a week applying patches or workarounds. We've been pursing using
nsight and renderdoc, which really won't function with the deprecated
stuff.
yup, I'll be at IITSEC.
-gedalia

On Mon, Sep 26, 2016 at 12:28 PM, Chris Hanson  wrote:

> Well, probably a good facsimile would be the situation for OpenGL ES,
> which lacks all of those same features.
>
> We did a bunch of work involving this, writing custom FFP to shader
> generators, as well as doing the grunt work of making osgEarth work on
> mobile devices (Android and iOS) through OpenGL ES.
>
> I don't think there's specifically a roadmap, but if you have questions
> about something in particular, shoot me an email. Are you going to IITSEC?
> ​
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>


-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG Running with modern OpenGL

[Gedalia Pasternak]

Hello,
   I'm working on a OSG based rendering engine and we're trying to switch
OSG to run without OSG_GL_FIXED_FUNCTION_AVAILABLE and all the other
deprecated pipeline functions disabled. I'm wondering if there's a road map
for getting OSG to support all the various bits of functionality that
currently printf endlessly.
I managed to fix the osgText and stat drawing, which a number of people
have pointed out just need reasonable shaders associated with the draw
nodes. But Materials/lights/Alpha discard all seem a bit trickier requiring
either a ton of additional uniforms and more elaborate state tracking when
shaders switch or using uniform buffers, I'd rather not reinvent the wheel
or wind up patching osg endlessly with kludgy workarounds.
Thanks,
-Gedalia

-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org