Re: [osg-users] (no subject)

[Robert Osfield]

Hi Anders,

There is a new mechanism for managing clean up of GL objects, which in
theory should help improve management of lifetimes of GL objects.

The warning suggests that something is try to do GL call after the
context is cleaned up, I don't know yet if this is a bug in the new
code or whether the new code is just revealling an old bug elsewhere.

Could you be more specific of how to reproduce the problem as there
isn't an --ssm option supported by the osgviewer example.

Robert.


On 4 February 2016 at 09:05, Anders Backman  wrote:
> Hi all.
>
> Trying OSG 3.5.1 and I have started to get some problems with objects
> (osg::Program/osg::Shaders etc.) being de-allocated after context is
> destroyed:
>
> Error: OpenGL version test failed, requires valid graphics context.
>
>
> Sometime it crasches sometimes it just print the warning.
>
> I can reproduce it with osgViewer --ssm
>
> The only solution so far has been to keep a static reference to the camera
> in the scene, which feels a lot like a hack.
> The same code worked in 3.4.0. So as you wrote in an earlier post, this
> probably reveals something that was not deallocated before.
>
> As soon as the viewer is destroyed, it takes the camera with it. Hence the
> Context is also destroyed.
>
> Not sure how to handle this in an general way.
>
> /Anders
>
>
> --
> __
> Anders Backman, HPC2N
> 90187 Umeå University, Sweden
> and...@cs.umu.se http://www.hpc2n.umu.se
> Cell: +46-70-392 64 67
>
> ___
> 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,

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

Re: [osg-users] (no subject)

[Anders Backman]

Yep sorry. I was having some (other) issue where text was not rendered when
I had enabled shadows, so I was messing with osgViewer.cpp copying sample
code from osgShadow there.

The example that reveals the issue at shutdown is plainly osgShadow.cpp


Output:

osgshadow.exe --window 0 0 1024 768
FOV is 29.1484
Error: OpenGL version test failed, requires valid graphics context.

And a crasch. Interestingly only if you first move the camera (left mouse
move) in the graphics window.
If you do not interact with the scene, it only show the error message.

/Anders



On Thu, Feb 4, 2016 at 11:57 AM, Robert Osfield 
wrote:

> Hi Anders,
>
> There is a new mechanism for managing clean up of GL objects, which in
> theory should help improve management of lifetimes of GL objects.
>
> The warning suggests that something is try to do GL call after the
> context is cleaned up, I don't know yet if this is a bug in the new
> code or whether the new code is just revealling an old bug elsewhere.
>
> Could you be more specific of how to reproduce the problem as there
> isn't an --ssm option supported by the osgviewer example.
>
> Robert.
>
>
> On 4 February 2016 at 09:05, Anders Backman  wrote:
> > Hi all.
> >
> > Trying OSG 3.5.1 and I have started to get some problems with objects
> > (osg::Program/osg::Shaders etc.) being de-allocated after context is
> > destroyed:
> >
> > Error: OpenGL version test failed, requires valid graphics context.
> >
> >
> > Sometime it crasches sometimes it just print the warning.
> >
> > I can reproduce it with osgViewer --ssm
> >
> > The only solution so far has been to keep a static reference to the
> camera
> > in the scene, which feels a lot like a hack.
> > The same code worked in 3.4.0. So as you wrote in an earlier post, this
> > probably reveals something that was not deallocated before.
> >
> > As soon as the viewer is destroyed, it takes the camera with it. Hence
> the
> > Context is also destroyed.
> >
> > Not sure how to handle this in an general way.
> >
> > /Anders
> >
> >
> > --
> > __
> > Anders Backman, HPC2N
> > 90187 Umeå University, Sweden
> > and...@cs.umu.se http://www.hpc2n.umu.se
> > Cell: +46-70-392 64 67
> >
> > ___
> > 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
>



-- 
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Viewing Stacked Semi-Transparent Geodes

[Christian Buchner]

There are techniques to perform order independent transparent rendering,
one of these is demonstrated in the osgoit example
of OpenSceneGraph. However osgoit uses a multipass technique and can be
rather slow.

Christian


2016-02-04 9:31 GMT+01:00 Voerman, L. :

> Hi Erik,
> the effect you see is caused by your blend function being order dependent,
> for a good result transparent triangles need to be drawn back to front.
> Did you set the rendering_hint to TRANSPARENT_BIN (binNumber 10 / binName
> DepthSortedBin)?
> like in stateSet->setRenderingHint(StateSet::TRANSPARENT_BIN);
> Regards, Laurens.
>
> On Wed, Feb 3, 2016 at 9:48 PM, Erik Hensens  wrote:
>
>> Hi everybody!
>>
>> I have two geodes, each is a flat circular disk with some circular holes
>> removed. Each geode is flat in the YZ plane, and they are stacked against
>> each other with a small amount of spacing, centered at (x1, 0, 0) and (x2,
>> 0, 0). There is a single parent matrix transform node that is the parent of
>> both of these geodes, and I use the matrix transform to set different
>> rotations. Each of these disk geodes is semi-transparent by means of
>> calling setAlpha on their materials for the FRONT_AND_BACK faces.
>>
>> The problem is that at certain parent matrix transform rotations certain
>> parts of the first disk are more visually prevalent and at other rotations
>> certain parts of the second disk are more visually prevalent, i.e. how
>> these two semi-transparent geodes are viewed against each other changes
>> based on the rotation of the parent matrix transform. I've attached two
>> images to show you the difference.
>>
>> What is causing this effect and how can I eliminate it? I want it to look
>> the same no matter what the rotation of the parent matrix transform is.
>>
>> Thanks in advance for any help!
>>
>> Cheers,
>> Erik
>>
>> --
>> Read this topic online here:
>> http://forum.openscenegraph.org/viewtopic.php?p=66186#66186
>>
>>
>>
>>
>> ___
>> 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] Changing indexing at runtime

[Roberto Vicini]

Hi,

at runtime, i need to switch the DrawElementsUInt array attached to geometry 
with another one . How can i that?

Thank you!

Cheers,
Roberto

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





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

Re: [osg-users] [forum] "Request received" emails

[Sebastian Messerschmidt]

Okay, just checked this and I'm too getting those emails.
So this maybe is related to the mailing list.
@Robert, any ideas?

Cheers
Sebastian
I am not a forum user, but I got one too, at 9:31 when I send a 
message to osg-users

Regards, Laurens.

On 04/02/2016 20:46, Jannik Heller wrote:

Hi,

Today I've been getting emails like this:


Code:

donotre...@secureserver.net

We received your inquiry
We received your inquiry
Your inquiry has been received. You should expect a response within 
72 hours.


This is your Incident ID: 28748198

Thanks,
Customer Service

Please do not reply to this email. Emails sent to this address will 
not be answered.

© 2016. All rights reserved.




At first I dismissed it as a spam email but soon noticed that the 
timing of the emails correlates exactly with postings that I made on 
this forum.


I don't suppose that the forum moderators intended this.

Any idea what is going on?

Thank you!

Cheers,
Jannik

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





___
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] [forum] "Request received" emails

[l.voerman]

I am not a forum user, but I got one too, at 9:31 when I send a message 
to osg-users

Regards, Laurens.

On 04/02/2016 20:46, Jannik Heller wrote:

Hi,

Today I've been getting emails like this:


Code:

donotre...@secureserver.net

We received your inquiry
We received your inquiry
Your inquiry has been received. You should expect a response within 72 hours.

This is your Incident ID: 28748198

Thanks,
Customer Service

Please do not reply to this email. Emails sent to this address will not be 
answered.
© 2016. All rights reserved.




At first I dismissed it as a spam email but soon noticed that the timing of the 
emails correlates exactly with postings that I made on this forum.

I don't suppose that the forum moderators intended this.

Any idea what is going on?

Thank you!

Cheers,
Jannik

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





___
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] Changing indexing at runtime

[Sebastian Messerschmidt]

Hi Roberto,

if you have the Geometry pointer somewhere you can change the attached 
primitive sets as long as you are doing this during update only and set 
its state to dirty.


Cheers
Sebastian

Hi,

at runtime, i need to switch the DrawElementsUInt array attached to geometry 
with another one . How can i that?

Thank you!

Cheers,
Roberto

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





___
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] Mesh reduction with indexes modification

[Roberto Vicini]

Hi,

I'm using osg for reproduce SRTM data into a scene and all works fine.
Now i want to reduce triangle in the scene by maintaining same vertex array and 
modify index buffer in order to skip some of the vertices in vertex array.
I use indexed GL_TRIANGLES.
This is the code i use for indexing traingles


Code:

int factor = 8;
m_indexArray->resize(m_indexArray->size()/factor);
  for (int i = 0; i<(m_rows - 1)/factor; i++){
for (int j = 0; j<(m_columns - 1)/factor; j++){
  int vertexIndex = (i* m_columns) + j;

  (*m_indexArray)[index++] = factor*(vertexIndex);
  (*m_indexArray)[index++] = factor*(vertexIndex + m_columns);  
 
  (*m_indexArray)[index++] = factor*(vertexIndex  + 1);

  (*m_indexArray)[index++] = factor*(vertexIndex + 1);
  (*m_indexArray)[index++] = factor*(vertexIndex + m_columns ); 
 
  (*m_indexArray)[index++] = factor*(vertexIndex + m_columns  +1);
}
}




Where:
m_rows is row count of mesh.
m_columns is col count of mesh
factor is a variable i use to reduce triangles.
m_indexArray is of type osg::ref_ptr.

As i said i use a "factor" variable in order to reduce indexed vertices. if 
factor == 1 then i have full resolution mesh (original mesh)
because indexing cover all vertices. if i choose (and it must be a power of 
two) factor == 2 or 4 or 8 and so on i obtain 
reduced mesh. In particular if i choose factor = 2 then i got a mesh with 1/4 
of triangles and so on.

The mesh in the scene is rapresented as expect but i have a problem. With 
values of factor > 1 when i move into the scene
may occur some "interruption". The camera movement seems to break some tenths 
of second and after resume.
This strange behavior seems to verify randomly when scene is on, but surely 
when i set values of factor > 1.
May be the indexing does not cover all vertices?

Thank you!

Cheers,
roberto[/code]

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





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

Re: [osg-users] (no subject)

[Anders Backman]

Seems that this actually caused a lot more problem than I first thought...

The fact that you need to have a valid reference while tearing down nodes,
means that our system with plugins (dll:s loaded etc) now causes problems.
The Camera it self, has references to a scene, states, (Renderer) etc, and
if I keep a reference of the Camera to last, I get crashes when the camera
destructor is called, due to the fact that most of the nodes, shaders,
programs where created (allocated) in dll:s that has already been unloaded.


So to recap:

I need a context when a node is removed (if the node contains for example a
shader/program).
If I keep a reference to the Camera (hence the context), the camera also
keep references to just about everything I put into the scenegraph, meaning
that I delay the destruction of objects very late.

Right now I do not really see a solution for this. It was working in 3.4.0.

/A

On Thu, Feb 4, 2016 at 12:25 PM, Anders Backman  wrote:

> Yep sorry. I was having some (other) issue where text was not rendered
> when I had enabled shadows, so I was messing with osgViewer.cpp copying
> sample code from osgShadow there.
>
> The example that reveals the issue at shutdown is plainly osgShadow.cpp
>
>
> Output:
>
> osgshadow.exe --window 0 0 1024 768
> FOV is 29.1484
> Error: OpenGL version test failed, requires valid graphics context.
>
> And a crasch. Interestingly only if you first move the camera (left mouse
> move) in the graphics window.
> If you do not interact with the scene, it only show the error message.
>
> /Anders
>
>
>
> On Thu, Feb 4, 2016 at 11:57 AM, Robert Osfield 
> wrote:
>
>> Hi Anders,
>>
>> There is a new mechanism for managing clean up of GL objects, which in
>> theory should help improve management of lifetimes of GL objects.
>>
>> The warning suggests that something is try to do GL call after the
>> context is cleaned up, I don't know yet if this is a bug in the new
>> code or whether the new code is just revealling an old bug elsewhere.
>>
>> Could you be more specific of how to reproduce the problem as there
>> isn't an --ssm option supported by the osgviewer example.
>>
>> Robert.
>>
>>
>> On 4 February 2016 at 09:05, Anders Backman  wrote:
>> > Hi all.
>> >
>> > Trying OSG 3.5.1 and I have started to get some problems with objects
>> > (osg::Program/osg::Shaders etc.) being de-allocated after context is
>> > destroyed:
>> >
>> > Error: OpenGL version test failed, requires valid graphics context.
>> >
>> >
>> > Sometime it crasches sometimes it just print the warning.
>> >
>> > I can reproduce it with osgViewer --ssm
>> >
>> > The only solution so far has been to keep a static reference to the
>> camera
>> > in the scene, which feels a lot like a hack.
>> > The same code worked in 3.4.0. So as you wrote in an earlier post, this
>> > probably reveals something that was not deallocated before.
>> >
>> > As soon as the viewer is destroyed, it takes the camera with it. Hence
>> the
>> > Context is also destroyed.
>> >
>> > Not sure how to handle this in an general way.
>> >
>> > /Anders
>> >
>> >
>> > --
>> > __
>> > Anders Backman, HPC2N
>> > 90187 Umeå University, Sweden
>> > and...@cs.umu.se http://www.hpc2n.umu.se
>> > Cell: +46-70-392 64 67
>> >
>> > ___
>> > 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
>>
>
>
>
> --
> __
> Anders Backman, HPC2N
> 90187 Umeå University, Sweden
> and...@cs.umu.se http://www.hpc2n.umu.se
> Cell: +46-70-392 64 67
>



-- 
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] (no subject)

[Robert Osfield]

Hi Anders,

On 4 February 2016 at 13:19, Robert Osfield  wrote:
> However, let me investigate the bug at my end. This should clarify
> things.  I haven't had a chance to investigate yet as I've been
> testing and checking a block of work this morning.

I have tracked the problem down to the various
osgShadow::ShadowTechnique not implementing the resizeGLObjects() and
releaseGLObjects() methods that they should have been implementing all
along, this is a bug in these classes, which have been revealed by the
changes to the core OSG w.r.t release GL objects.  Fixes for these
ommissions is something I'm currently working on.  These changes would
be appropriate to older versions of the OSG as well as.

I will complete these fixes and get them checked in, once I do I'll
update this thread.

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

Re: [osg-users] (no subject)

[Robert Osfield]

Hi Anders,

On 4 February 2016 at 13:03, Anders Backman  wrote:
> Seems that this actually caused a lot more problem than I first thought...
>
> The fact that you need to have a valid reference while tearing down nodes,
> means that our system with plugins (dll:s loaded etc) now causes problems.
> The Camera it self, has references to a scene, states, (Renderer) etc, and
> if I keep a reference of the Camera to last, I get crashes when the camera
> destructor is called, due to the fact that most of the nodes, shaders,
> programs where created (allocated) in dll:s that has already been unloaded.
>
>
> So to recap:
>
> I need a context when a node is removed (if the node contains for example a
> shader/program).
> If I keep a reference to the Camera (hence the context), the camera also
> keep references to just about everything I put into the scenegraph, meaning
> that I delay the destruction of objects very late.

I wouldn't worry to much right now as I haven't yet worked out what is
going wrong in your case.  The changes to the core OSG aren't meant to
cause new restrictions on usage.  The only case where we might not be
able to retain support for is if there was originally buggy code that
was doing things wrong and somehow by luck didn't cause problems now
causes problems.  For the later case we need to find the problem in
client code.

However, let me investigate the bug at my end. This should clarify
things.  I haven't had a chance to investigate yet as I've been
testing and checking a block of work this morning.

> Right now I do not really see a solution for this. It was working in 3.4.0.

Right now just go back to OSG-3.4.0,

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

[osg-users] (no subject)

[Anders Backman]

Hi all.

Trying OSG 3.5.1 and I have started to get some problems with objects
(osg::Program/osg::Shaders etc.) being de-allocated after context is
destroyed:

Error: OpenGL version test failed, requires valid graphics context.


Sometime it crasches sometimes it just print the warning.

I can reproduce it with osgViewer --ssm

The only solution so far has been to keep a static reference to the camera
in the scene, which feels a lot like a hack.
The same code worked in 3.4.0. So as you wrote in an earlier post, this
probably reveals something that was not deallocated before.

As soon as the viewer is destroyed, it takes the camera with it. Hence the
Context is also destroyed.

Not sure how to handle this in an general way.

/Anders


-- 
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FBO and Renderbuffer leak in OSG 3.5

[Jannik Heller]

Hi Robert,

The leak is only noticable when you frequently remove and re-create cameras, 
something that osgprerender does not do.

I've added an osg::Observer to test that the Camera is being deleted properly, 
and it is. It looks like CPU side everything is being deleted correctly, only 
on GPU side there is an issue because glDeleteFramebuffers is being called 
without a current context.

Please check out the following minimal changes to osgprerender.cpp - recreating 
the Camera every frame. This leaks for me in OSG 3.5 but does not leak in 3.4. 
An easy way to see the increase in VRAM usage is with nvidia-smi if you are 
using an Nvidia card, not sure about tools for other graphics cards 
manifacturers.

When I run this modified example, the VRAM usage instantly baloons to 4 GB, and 
the system memory usage starts growing very fast (presumably since the graphics 
card has to swap back and forth from system memory when it's full). 

Hope that helps in solving the issue.

Thanks,
Jannik

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



/* OpenSceneGraph example, osgprerender.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the "Software"), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

#include 

#include 
#include 
#include 

#include 
#include 

#include 

// call back which creates a deformation field to oscillate the model.
class MyGeometryCallback :
public osg::DrawableUpdateCallback,
public osg::Drawable::AttributeFunctor
{
public:

MyGeometryCallback(const osg::Vec3& o,
   const osg::Vec3& x,const osg::Vec3& y,const osg::Vec3& z,
   double period,double xphase,double amplitude):
_firstCall(true),
_startTime(0.0),
_time(0.0),
_period(period),
_xphase(xphase),
_amplitude(amplitude),
_origin(o),
_xAxis(x),
_yAxis(y),
_zAxis(z) {}

virtual void update(osg::NodeVisitor* nv,osg::Drawable* drawable)
{
// OpenThreads::Thread::microSleep( 1000 );

const osg::FrameStamp* fs = nv->getFrameStamp();
double simulationTime = fs->getSimulationTime();
if (_firstCall)
{
_firstCall = false;
_startTime = simulationTime;
}

_time = simulationTime-_startTime;

drawable->accept(*this);
drawable->dirtyBound();

osg::Geometry* geometry = dynamic_cast(drawable);
if (geometry)
{
osgUtil::SmoothingVisitor::smooth(*geometry);
}

}

virtual void apply(osg::Drawable::AttributeType type,unsigned int count,osg::Vec3* begin)
{
if (type == osg::Drawable::VERTICES)
{
const float TwoPI=2.0f*osg::PI;
const float phase = -_time/_period;

osg::Vec3* end = begin+count;
for (osg::Vec3* itr=begin;itr

Re: [osg-users] FBO and Renderbuffer leak in OSG 3.5

[Jannik Heller]

One more thing, it does look like an FBO specific issue, because if I run with

./osgprerender --window

there is no leak whatsoever.

Thanks,
Jannik

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





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

[osg-users] [forum] "Request received" emails

[Jannik Heller]

Hi,

Today I've been getting emails like this:


Code:

donotre...@secureserver.net

We received your inquiry
We received your inquiry
Your inquiry has been received. You should expect a response within 72 hours.

This is your Incident ID: 28748198

Thanks,
Customer Service

Please do not reply to this email. Emails sent to this address will not be 
answered.
© 2016. All rights reserved.




At first I dismissed it as a spam email but soon noticed that the timing of the 
emails correlates exactly with postings that I made on this forum.

I don't suppose that the forum moderators intended this.

Any idea what is going on?

Thank you!

Cheers,
Jannik

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





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

Re: [osg-users] Viewing Stacked Semi-Transparent Geodes

[Erik Hensens]

Thank you very much for your response. I actually was calling 
setRenderingHint(StateSet::TRANSPARENT_BIN), but I commented that line out and 
it actually started working properly. Thanks for the direction!


Voerman, L. wrote:
> Hi Erik,the effect you see is caused by your blend function being order 
> dependent, for a good result transparent triangles need to be drawn back to 
> front. 
> Did you set the rendering_hint to TRANSPARENT_BIN (binNumber 10 / binName 
> DepthSortedBin)?
> like in stateSet->setRenderingHint(StateSet::TRANSPARENT_BIN);
> Regards, Laurens.
> 
> 
> On Wed, Feb 3, 2016 at 9:48 PM, Erik Hensens < ()> wrote:
> 
> > Hi everybody!
> > 
> > I have two geodes, each is a flat circular disk with some circular holes 
> > removed. Each geode is flat in the YZ plane, and they are stacked against 
> > each other with a small amount of spacing, centered at (x1, 0, 0) and (x2, 
> > 0, 0). There is a single parent matrix transform node that is the parent of 
> > both of these geodes, and I use the matrix transform to set different 
> > rotations. Each of these disk geodes is semi-transparent by means of 
> > calling setAlpha on their materials for the FRONT_AND_BACK faces.
> > 
> > The problem is that at certain parent matrix transform rotations certain 
> > parts of the first disk are more visually prevalent and at other rotations 
> > certain parts of the second disk are more visually prevalent, i.e. how 
> > these two semi-transparent geodes are viewed against each other changes 
> > based on the rotation of the parent matrix transform. I've attached two 
> > images to show you the difference.
> > 
> > What is causing this effect and how can I eliminate it? I want it to look 
> > the same no matter what the rotation of the parent matrix transform is.
> > 
> > Thanks in advance for any help!
> > 
> > Cheers,
> > Erik
> > 
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=66186#66186 
> > (http://forum.openscenegraph.org/viewtopic.php?p=66186#66186)
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> >  ()
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > 
> > 
> 
> 
>  --
> Post generated by Mail2Forum


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





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

Re: [osg-users] Viewing Stacked Semi-Transparent Geodes

[Erik Hensens]

Thank you for your response. In the interest of full documentation, I thought I 
should note that I tried setting the blend function as osgoit does, but it 
didn't make a difference in my example. Thanks anyway!


cbuchner1 wrote:
> There are techniques to perform order independent transparent rendering, one 
> of these is demonstrated in the osgoit example
> 
> of OpenSceneGraph. However osgoit uses a multipass technique and can be 
> rather slow.
> 
> 
> Christian
> 
> 
> 
> 
> 
> 2016-02-04 9:31 GMT+01:00 Voerman, L. < ()>:
> 
> > Hi Erik,the effect you see is caused by your blend function being order 
> > dependent, for a good result transparent triangles need to be drawn back to 
> > front. 
> > Did you set the rendering_hint to TRANSPARENT_BIN (binNumber 10 / binName 
> > DepthSortedBin)?
> > like in stateSet->setRenderingHint(StateSet::TRANSPARENT_BIN);
> > Regards, Laurens.
> > 
> > 
> > On Wed, Feb 3, 2016 at 9:48 PM, Erik Hensens < ()> wrote:
> > 
> > 
> > 
> > > Hi everybody!
> > > 
> > > I have two geodes, each is a flat circular disk with some circular holes 
> > > removed. Each geode is flat in the YZ plane, and they are stacked against 
> > > each other with a small amount of spacing, centered at (x1, 0, 0) and 
> > > (x2, 0, 0). There is a single parent matrix transform node that is the 
> > > parent of both of these geodes, and I use the matrix transform to set 
> > > different rotations. Each of these disk geodes is semi-transparent by 
> > > means of calling setAlpha on their materials for the FRONT_AND_BACK faces.
> > > 
> > > The problem is that at certain parent matrix transform rotations certain 
> > > parts of the first disk are more visually prevalent and at other 
> > > rotations certain parts of the second disk are more visually prevalent, 
> > > i.e. how these two semi-transparent geodes are viewed against each other 
> > > changes based on the rotation of the parent matrix transform. I've 
> > > attached two images to show you the difference.
> > > 
> > > What is causing this effect and how can I eliminate it? I want it to look 
> > > the same no matter what the rotation of the parent matrix transform is.
> > > 
> > > Thanks in advance for any help!
> > > 
> > > Cheers,
> > > Erik
> > > 
> > > --
> > > Read this topic online here:
> > > http://forum.openscenegraph.org/viewtopic.php?p=66186#66186 
> > > (http://forum.openscenegraph.org/viewtopic.php?p=66186#66186)
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > osg-users mailing list
> > >  ()
> > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > 
> > > 
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> >  ()
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > 
> > 
> 
> 
>  --
> Post generated by Mail2Forum


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





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

[osg-users] FBO and Renderbuffer leak in OSG 3.5

[Jannik Heller]

Hi,

I have just tracked down a memory leak regarding FBO's to what appears to be an 
OSG bug. Please check out the attached screenshot of gDebugger, OSG attempts to 
glDeleteFramebuffers / glDeleteRenderbuffers from the main thread with no 
context current. That can't work properly and I'm actually surprised that the 
driver doesn't crash or complain about this.

When I change the threading mode to SINGLE_THREADED the leak disappears, this 
makes sense since now all graphics work is done from the main thread, so 
deleting from the main thread will actually work.

I'm getting this issue with OSG 3.5 git master commit 40bd79c499a37a9. When I 
revert back to OSG 3.4 the leak disappears. I presume this is a regression from 
when the new GL buffer object management was introduced in OSG 3.5. 

I haven't written a reproduction sample yet but it should be fairly simple - 
all I'm doing is add an FBO camera to the scene graph, have it render for one 
frame, and then remove it from the scene graph to be deleted.

Any ideas on how to fix this? If needed I can try to provide a reproduction 
sample.

Thank you!

Cheers,
Jannik

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





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

Re: [osg-users] FBO and Renderbuffer leak in OSG 3.5

[Robert Osfield]

Hi Jannik,

Does the issue appear with any of the RTT example i.e. osgprerender?

>From your description it could be removing the FBO Camera from the
scene graph but keeping a reference around for it beyond the lifetime
of the graphics window that could be an issue.  However, I suspect it
isn't actually a leak, but an attempt to fix a potential leak that is
causing the reported problem as the old code would likely be not even
attempting to delete the GL objects.

It would be useful to have an example as I could easily create an
example that doesn't cause any problems and not know what to amend to
recreate the issue.

Robert.

On 4 February 2016 at 17:52, Jannik Heller  wrote:
> Hi,
>
> I have just tracked down a memory leak regarding FBO's to what appears to be 
> an OSG bug. Please check out the attached screenshot of gDebugger, OSG 
> attempts to glDeleteFramebuffers / glDeleteRenderbuffers from the main thread 
> with no context current. That can't work properly and I'm actually surprised 
> that the driver doesn't crash or complain about this.
>
> When I change the threading mode to SINGLE_THREADED the leak disappears, this 
> makes sense since now all graphics work is done from the main thread, so 
> deleting from the main thread will actually work.
>
> I'm getting this issue with OSG 3.5 git master commit 40bd79c499a37a9. When I 
> revert back to OSG 3.4 the leak disappears. I presume this is a regression 
> from when the new GL buffer object management was introduced in OSG 3.5.
>
> I haven't written a reproduction sample yet but it should be fairly simple - 
> all I'm doing is add an FBO camera to the scene graph, have it render for one 
> frame, and then remove it from the scene graph to be deleted.
>
> Any ideas on how to fix this? If needed I can try to provide a reproduction 
> sample.
>
> Thank you!
>
> Cheers,
> Jannik
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=66205#66205
>
>
>
>
>
> ___
> 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] (no subject)

[Robert Osfield]

Hi Anders et.al,

On 4 February 2016 at 14:34, Robert Osfield  wrote:
> I will complete these fixes and get them checked in, once I do I'll
> update this thread.

I have fixed the problems in osgShadow and checked in fixes to git master.

Gotta be said that some elements of the osgShadow code is right mess,
far more complicated and difficult to follow than it should be.  There
are quite a few classes in there that I should never have merged as
they really make a mockery of clean and clear class design and
implementation.  I'm wondering whether I should just remove such parts
of the OSG as we go forward.

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

Re: [osg-users] [forum] "Request received" emails

[Sebastian Messerschmidt]

Hi Jannik,

I didn't change anything in the forum's configuration, but I've seen the 
same type of emails.

They stopped some days ago however.

Can you please try to watch if it is/stays related to your postings?

Cheers
Sebastian

Hi,

Today I've been getting emails like this:


Code:

donotre...@secureserver.net

We received your inquiry
We received your inquiry
Your inquiry has been received. You should expect a response within 72 hours.

This is your Incident ID: 28748198

Thanks,
Customer Service

Please do not reply to this email. Emails sent to this address will not be 
answered.
© 2016. All rights reserved.




At first I dismissed it as a spam email but soon noticed that the timing of the 
emails correlates exactly with postings that I made on this forum.

I don't suppose that the forum moderators intended this.

Any idea what is going on?

Thank you!

Cheers,
Jannik

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





___
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] LineOfSight intersection returning geometry

[Robert Osfield]

Hi Tony,

You only need to set the mask on node at the top of the subgraph for
the whole subgraph to be culled from a traversal.

Robert.

On 4 February 2016 at 00:43, Tony Vasile  wrote:
> So if you have a large piece of geometry like terrain or ocean is simply a 
> case of setting the right mask on the root node of this large geometry to 
> avoid or allow intersections? Or do you have set the mask on all the pieces 
> of said large geometry?
>
> 
> Tony V
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=66187#66187
>
>
>
>
>
> ___
> 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] Viewing Stacked Semi-Transparent Geodes

[Voerman, L.]

Hi Erik,
the effect you see is caused by your blend function being order dependent,
for a good result transparent triangles need to be drawn back to front.
Did you set the rendering_hint to TRANSPARENT_BIN (binNumber 10 / binName
DepthSortedBin)?
like in stateSet->setRenderingHint(StateSet::TRANSPARENT_BIN);
Regards, Laurens.

On Wed, Feb 3, 2016 at 9:48 PM, Erik Hensens  wrote:

> Hi everybody!
>
> I have two geodes, each is a flat circular disk with some circular holes
> removed. Each geode is flat in the YZ plane, and they are stacked against
> each other with a small amount of spacing, centered at (x1, 0, 0) and (x2,
> 0, 0). There is a single parent matrix transform node that is the parent of
> both of these geodes, and I use the matrix transform to set different
> rotations. Each of these disk geodes is semi-transparent by means of
> calling setAlpha on their materials for the FRONT_AND_BACK faces.
>
> The problem is that at certain parent matrix transform rotations certain
> parts of the first disk are more visually prevalent and at other rotations
> certain parts of the second disk are more visually prevalent, i.e. how
> these two semi-transparent geodes are viewed against each other changes
> based on the rotation of the parent matrix transform. I've attached two
> images to show you the difference.
>
> What is causing this effect and how can I eliminate it? I want it to look
> the same no matter what the rotation of the parent matrix transform is.
>
> Thanks in advance for any help!
>
> Cheers,
> Erik
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=66186#66186
>
>
>
>
> ___
> 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