Re: [osg-users] Removing objects with shared GL state from scene graph

2019-07-02 Thread Chris Djali
Hi,

This surprises me, but apparently clearing the object cache is enough to stop 
anything from leaking (otherwise, in the case where the second text node was 
removed, too, without releasing its GL objects, CodeXL was reporting two leaked 
shaders and three leaked program pipelines). I was expecting some things not to 
be released by their destructors, but apparently everything is.

I'm now in a situation where I think I can solve the issue that's bothering me 
sufficiently tidily that it won't be a maintanance nightmare, so the OpenMW 
Construction Set might be about to get its first non-nasty piece of code, which 
is nice.

I've seen that the object cache also has a releaseGLObjects function, which I 
imagine should have roughly the same effect except with the option to do it for 
just one context instead of all of them. I'm planning on calling that as part 
of a viewer cleanup operation. Might it be an idea to make this happen 
automatically in OSG without applications having to set it up themselves?

Cheers,
Chris

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





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


[osg-users] OpenSceneGraph-3.6.4 release candidate 4 tagged

2019-07-02 Thread Robert Osfield
Hi All,

I have just tagged the 3.6.4-rc4:


https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.4-rc4

Please test and report success/failures here on this thread.

I'm now heading off for a family holiday, I'll be back at the compute on
Friday 12th so won't be able to address issues right away.

Thanks in advance for all the testing :-)
Robert.

-- Changes since 3.6.3 are:

diff --git a/ChangeLog b/ChangeLog
index 0f658af68..c5d222026 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,673 @@
+Tue, 2 Jul 2019 20:21:05 +0100
+Author : Robert Osfield
+Updated SO number to refect change to the Drawable header inline method
status
+
+Tue, 2 Jul 2019 20:19:05 +0100
+Author : Robert Osfield
+Updated in prep for 3.6.4-rc4
+
+Mon, 1 Jul 2019 16:15:21 +0100
+Author : Colin McDonald
+Trivial change to src/osgSim/LineOfSight.cpp to quieten down an info
message in DatabaseCacheReadCallback::readNodeFile.
+
+Mon, 1 Jul 2019 16:12:53 +0100
+Author : Robert Osfield
+Updated release candidate number to 4 in prep for 3.6.4-rc4 release.
+
+Mon, 1 Jul 2019 15:48:29 +0100
+Author : Robert Osfield
+Removed stray tab
+
+Tue, 25 Jun 2019 17:09:46 +1200
+Author : jimcamel
+Fixed bug where FFmpeg Image Stream would stop if paused for more than 10
secondsThe FFmpeg image stream class uses a 10 second timeout between
frames to determine if the stream is dead and if so closes it. However, the
timeout is determined using the variable lastUpdateTS which stores the last
time the publishNewFrame function was called, and if the video has been
playing and then is paused for longer than 10 seconds, when it is unpaused
this timeout will fire and the stream will be closed, stopping the video
playing beyond what has been buffered.
+
+To stop this timeout from happening before the video starts playing, the
timeout checks to see if the lastUpdateTS > 0 (at initialization it is set
to 0). In this fix, we simply set the value of lastUpdateTS to 0 when the
video is unpaused, this will force the check to skip on unpause, and from
then on lastUpdateTS will have the correct value again.
+
+The lastUpdateTS variable is private and only used for this one function,
so there should be no side effects from the change.
+
+Fri, 7 Jun 2019 12:45:45 +0200
+Author : Riccardo Corsi
+Bugfix due to copy-paste typo which prevented multi uv channel mesh to be
imported correctly.
+
+Mon, 1 Jul 2019 13:43:29 +0100
+Author : Robert Osfield
+Fixed layout
+
+Mon, 1 Jul 2019 13:42:33 +0100
+Author : Robert Osfield
+Merge branch 'patch-27' of https://github.com/mp3butcher/OpenSceneGraph
into patch-27
+
+Thu, 30 May 2019 23:10:27 +0300
+Author : Alexey Galitsyn
+Fix not checking num lock state when remapping keypad keys on Windows.Num
lock state was never checked during remapping keypad keys on Windows.
+Now when num lock is active, keypad numeric keys and keypad delimeter key
+should work as expected (return KEY_KP_0 to KEY_KP_9 and KEY_KP_Decimal
+respectivly).
+
+
+Mon, 1 Jul 2019 12:56:36 +0100
+Author : Robert Osfield
+Restructed the setting of the default osgDB::Options so it doesn't
override the ObjectCacheHint setting when a user specified osgDB::Options
object is passed in.
+
+Mon, 1 Jul 2019 12:33:21 +0100
+Author : Robert Osfield
+Merge branch 'OpenSceneGraph-3.6_vas' of
https://github.com/eligovision/OpenSceneGraph into OpenSceneGraph-3.6_vas
+
+Mon, 1 Jul 2019 12:18:21 +0100
+Author : Robert Osfield
+Couldn't resolve warnings coming from the FBX headers so had to suppress
warnings.
+
+Tue, 21 May 2019 13:28:41 +0200
+Author : Laurens Voerman
+replaced "if (apm || !apm->valid())"
+
+Tue, 21 May 2019 13:29:47 +0200
+Author : Laurens Voerman
+fix typo in header guard.
+
+Wed, 15 May 2019 11:49:17 +0200
+Author : Laurens Voerman
+fix typo in ReaderWriterFBX: writObject -> writeObject
+
+Fri, 14 Jun 2019 15:28:46 +0100
+Author : OpenSceneGraph git repository
+Merge pull request #760 from LaurensVoerman/readObjectimplement readObject
for all relevant readerWriters
+
+Fri, 14 Jun 2019 15:01:15 +0100
+Author : OpenSceneGraph git repository
+Merge pull request #759 from AnyOldName3/more-tgaVarious TGA improvements
+
+Fri, 14 Jun 2019 14:32:31 +0100
+Author : OpenSceneGraph git repository
+Merge pull request #758 from LaurensVoerman/osgt_indentationfix
indentation for osgt files for windows dynamic library build.
+
+Fri, 14 Jun 2019 14:29:32 +0100
+Author : OpenSceneGraph git repository
+Merge pull request #757 from LaurensVoerman/rendererNoRefCountfix compile
error if OSGUTIL_RENDERBACKEND_USE_REF_PTR not defined in
include/osgUtil/RenderLeaf
+
+Sat, 8 Jun 2019 01:17:21 +0200
+Author : Julien Valentin
+update traversedebug preventing traversal to disable OQN
+
+Fri, 31 May 2019 15:27:18 +0200
+Author : Julien Valentin
+add enable check in traverseQuery
+
+Wed, 15 May 2019 14:35:39 +0300
+Author : Konstantin S. Matveyev
+typo fix
+
+Wed, 15 May 2019 14:27:10 +0300
+Author : valid-ptr
+VertexArrayState's lazy disabling of vertex attributes mechanism 

Re: [osg-users] Removing objects with shared GL state from scene graph

2019-07-02 Thread Robert Osfield
Hi Chris,

On Tue, 2 Jul 2019 at 15:43, Chris Djali  wrote:

> If that's the case, though, it seems like relying on it for correctness
> isn't a good strategy - surely all these release calls exist because
> there's some chance an implementation detail might change at some point and
> make them necessary.
>

I don't yet get the leak part.  The Font class manages all of it's objects
via ref_ptr<>, they all will be deleted automatically once the Font get
deleted.

Is it simply that the Font's that are cached within the osgDB::ObjectCache
that is keeping Font's around independent of the scene graph objects that
are coming and going.

You can explicitly flush the ObjectCache.

Again, what makes you think there is a leak, are you using some debug tool
to determine this? If so, which one?

I am still at the point of not knowing whether it's a usage issue at your
end, a mis-understanding of how things work, or a bug in the OSG.  From the
info I have so far I don't have way of knowing, which is why I'm asking
specifically about the leak.

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


[osg-users] Frame Drop

2019-07-02 Thread 515415812
Hi all,I??m just rendering a simple Cylinder. It??s code as following. I 
repeated load it 10 times.
osg::ref_ptr hints = new osg::TessellationHints;  
hints->setDetailRatio(100.0f);
geode->addDrawable(new osg::ShapeDrawable(new osg::Cylinder(osg::Vec3(6.0f, 
0.0f, 0.0f), _radius, _height), hints)); 
when I first push ??s?? ,the frame of the scene is about 60Hz and then I 
countinue push ??s??, the frame would drop to 40Hz, finally I push ??s??, the 
frame just is 20Hz. 
The sum cost time of event update cull draw and gpu is about 14.5ms(62Hz),not 
the same as above 20Hz, I don??t know why? Could anyone give me some advice?
Best wishes!
Judy___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Removing objects with shared GL state from scene graph

2019-07-02 Thread Chris Djali
Hi,

When the text node's releaseGLObjects is called, it calls the same method of:
The 
GlyphQuads
The 
Font (which is potentially problematic when it doesn't get skipped).
The vertex attributes (
_coords, _normals, _colorCoords, _texcoords)
The primitives in 
_decorationPrimitives
The base 
Drawable.

The Text destructor releases none of these, neither does the TextBase 
destructor, and the Drawable destructor doesn't release everything that its 
releaseGLObjects does, but that might be inconsequential.

The GlyphQuads should be fine as it's just its primitives that get released, 
and all the primitive sets seem to release their own stuff in their 
destructors. It should be similar for _decorationPrimitives.

The vertex attributes might be fine with the handling in their destructors, too.

As I've been saying, the font might be shared with other text nodes, so may or 
may not be released later depending on what happens with other text nodes.


That means that it's possible that within all the nested releasing of GL 
objects for a text node, only the font actually owns anything that needs 
releasing, so in the case where only one text node is removed, we get away 
without calling releaseGLObjects.

If that's the case, though, it seems like relying on it for correctness isn't a 
good strategy - surely all these release calls exist because there's some 
chance an implementation detail might change at some point and make them 
necessary.

It also isn't a great strategy to apply generally - if we removed all the text 
nodes, and didn't release the last one, the texture and program(s) the font 
owns would definitely leak. In the case of an application where for whatever 
reason it's difficult to keep track of which text node is the last, and so a 
consistent strategy is required, you're back with the release-or-leak choice.

Surely the best solution is an osgText::Text::releaseGLObjects implementation 
that's always safe to call for text nodes that won't get used again?

Cheers,
Chris

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





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


[osg-users] silhouette bitmap into vector

2019-07-02 Thread Trajce Nikolov NICK
Hi Community,

This is a bit more CG question rather then OSG related, but I think there
are lots of CG folks in this community so I dare to ask

I am after processing of a rendering outline of a scene (which is a bitmap
as a result of RTT in OSG) and then having this outline as an array of 2D
coordinates. And preferable close to real time. Anyone with some
suggestions?

Thanks a bunch as always! Meanwhile I am googling this one

Cheers,
Nick

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


Re: [osg-users] two pass rendering without enhancing osg::Drawable

2019-07-02 Thread Trajce Nikolov NICK
Thanks Robert :). Sometimes I struggle :-))) ... Thanks again !

On Tue, Jul 2, 2019 at 12:22 PM Robert Osfield 
wrote:

> Hi Nick,
>
> On Tue, 2 Jul 2019 at 10:58, Trajce Nikolov NICK <
> trajce.nikolov.n...@gmail.com> wrote:
>
>> is there any elegant way to have multipass rendering then inheriting and
>> enhancing osg::Drawable? Thanks a bunch for any hint
>>
>
> Have you forgotten how the OSG works?
>
> There are dozens of examples in the OpenSceneGraph/example that use
> mulit-pass and multi-stage rendering without ever subclassing Drawable or
> using callbacks. One simple uses osg::Camera to manage mulit-stage
> rendering, like render to texture. and using StateSet's::RenderBin details
> when you want to have multiple bins, or you can just put the same subgraph
> into the scene graph multiple times and decorate each branch with different
> state to select what you want.
>
> Robert.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


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


Re: [osg-users] two pass rendering without enhancing osg::Drawable

2019-07-02 Thread Robert Osfield
Hi Nick,

On Tue, 2 Jul 2019 at 10:58, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:

> is there any elegant way to have multipass rendering then inheriting and
> enhancing osg::Drawable? Thanks a bunch for any hint
>

Have you forgotten how the OSG works?

There are dozens of examples in the OpenSceneGraph/example that use
mulit-pass and multi-stage rendering without ever subclassing Drawable or
using callbacks. One simple uses osg::Camera to manage mulit-stage
rendering, like render to texture. and using StateSet's::RenderBin details
when you want to have multiple bins, or you can just put the same subgraph
into the scene graph multiple times and decorate each branch with different
state to select what you want.

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


Re: [osg-users] Removing objects with shared GL state from scene graph

2019-07-02 Thread Robert Osfield
Hi Chris,

I have begun reviewing the test program.  In the comments you suggest if
relaseGLObects() isn't call text1 objects leak.  This confuses me, what
"objects" do you think leak? At this point I need something concrete to
investigate.

FYI, delete texture and other GL objects are cached in set of GL objects
that are queued for deletion (for textures it's the TextureObjectManager
that does this), the deletion of GL obejcts has to happen in a thread that
has the context current that owns those GL objects, so there is a call to
osg::flushDeletedGLObjects(..) in the draw traversal by sceneView.  The
containers that manage the list of GL objects to be deleted can also cache
them for reuse - this is done for textures, so when you create a new
texture and there is a texture object that has be queued for deletion then
rather than delete and create the OSG is able to simple reuse the texture
object avoiding the expensive delete and create texture object calls.

This reuse feature is crucial for paged databases and defaults of how many
texture objects to keep around are chosen for typically hardware and data
so there shouldn't normally be any need to worry about, the OSG should
mostly just do the right thing.  If you are concerned that texture objects
etc. are getting cleaned up as soon as you'd expect then you can setting
the TextureObjectManager properties (see the include/osg/Texture header for
details), there is one TextureObjectManager per graphics context.

--

In your test program you have scene graph objects that you explicitly
retain ref_ptr<>'s to, which will mean these objects won't get deleted
until the exit of the main.  This makes me wonder if perhaps the perception
of leak could be down to just the ordering of things are done.  For this
particular usage case it seems to me like everything should just work out
of the box without any need to explicitly call releaseGLobjects().

I currently don't know what to investigate, there isn't anything too
unusual in this example that makes me think there is some usage case where
the usual OSG mechanisms might fail, it looks pretty straight forward to
me.  I've already done a heap load of bug hunting and fixing in this area
prior to 3.6, with much more challenging usage.  Since I don't know what
specially you think is leaking and I don't have any hunches myself I'll
just have to wait till you give more guidance.

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


[osg-users] two pass rendering without enhancing osg::Drawable

2019-07-02 Thread Trajce Nikolov NICK
Hi Community,

is there any elegant way to have multipass rendering then inheriting and
enhancing osg::Drawable? Thanks a bunch for any hint

Cheers,
Nick

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