Re: [osg-users] How to access the view parameters from which the Cull Visitor came?

[Jannik Heller]

Hi Miguel,

Overriding traverse() is possible, it's also possible to add a callback via 
node->addCullCallback(myCallback) which is essentially the same just via a 
callback object that can be reused for multiple nodes (of possibly different 
types). I would usually go with callbacks as they are a little more flexible 
but both methods are fine. From there if it's a cull visitor you can just cast 
it: 


Code:

osgUtil::CullVisitor* cv = static_cast(nv)



and get all the info you need from the CullVisitor, its Camera, etc.

It should be noted that OSG can (but does not by default) run culling for 
multiple cameras simultaneously, with the CullThreadPerCamera threading mode. 
If this is the case, making modifications to a subgraph like setNodeMask(), 
changing uniform's etc. is going to create race conditions. This can be worked 
around by not modifying the scene graph with your changes, but instead push 
them onto the active CullVisitor only (e.g. by pushing a StateSet with new 
state, or push a new ModelViewMatrix - have  a look at the CullVisitor's  
push/popStateSet and push/PopModelViewMatrix). I would argue this is the 
cleaner way in any case, as the act of viewing a scene should not fundamentally 
change it (unless we're talking about quantum mechanics ;) ).


> 
> 1) to access view width and height in pixels (Viewport in pixels) and pass 
> them to a specific node shader as uniforms,
> 

This part is easy - the CullVisitor has the Camera and the Camera has a 
Viewport.


> 
> 2) Check some View attributes depending on which I show or hide the child 
> nodes. I set the View attributes when I create the osgViewer::View, for 
> example, there is an attribute determining if the View is Primary (Main) or 
> Secondary (Zoom).
> 

As far as I remember, the osgViewer::View isn't directly exposed from the 
CullVisitor or the Camera because the core OSG is not dependent on the 
osgViewer component. You might be able to use dynamic_cast's to get at the View 
regardless, but I'd suggest try using masks instead to differentiate views 
(e.g. the Camera's CullMask). 

Hope this helps,

Cheers,
Jannik

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





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

Re: [osg-users] Running a per-frame task on the graphics thread

[Jannik Heller]

Hi James,

You should be able to use a Drawable with DataVariance set to DYNAMIC for the 
'sync phase', and a second Drawable (with no special dataVariance) for the 
drawing, with your logic implemented in the Drawable's drawImplementation(). 
RenderBins can be used to control when they are drawn. This should achieve what 
you want. Note the dynamic Drawable won't really 'block' the main thread (the 
main thread may still be doing culling, passing other Drawables onto the draw 
queue, etc.), but it will prevent the next frame from commencing until the 
dynamic Drawable is done drawing. This should all work regardless of which 
threading mode's in use. Placing the first drawable in the earliest RenderBin 
should ensure there is as little waiting as necessary.

Cheers,
Jannik

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





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

Re: [osg-users] osgParticle (particle life time)`

[Jannik Heller]

Hi Nick,

I think what you're looking for would be Particle::kill():


Code:

/** Kill the particle on next update
NOTE: after calling this function, the isAlive() method will still
return true until the particle is updated again.
*/
inline void kill();




Does this not work?

Cheers,
Jannik[/code]

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





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

Re: [osg-users] Forum problems

[Jannik Heller]

Hi,

I've seen this quite often in the past; so far deleting the site cookies and 
logging back in always solved it (for a while anyway).

Cheers,
Jannik

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





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

Re: [osg-users] Equivalent of glTexSubImage2D ?

[Jannik Heller]

Hi Johny,

By default, OSG will run graphics operations in a separate thread so trying to 
do OpenGL calls from the main thread will not have an effect. Update callbacks 
are always invoked from the main thread. Try using a DrawCallback on a Drawable 
or Camera instead which will be invoked from the OpenGL thread, and it will 
pass along the GraphicsContext for convenience as well.

If, however, you're set on not using threading at all, you can turn it off with 
the environment variable OSG_THREADING=SingleThreaded.

Cheers,
Jannik

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





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

Re: [osg-users] Vertex Buffer Object used inside display list

[Jannik Heller]

On Nvidia, replaying the trace prints the following debug output for each 
'glDrawElements' line:


Code:
usnknown (sic) severity API unknown issue 131185, Buffer detailed info: Buffer 
object 1 (bound to GL_VERTEX_ARRAY_BUFFER_BINDING_ARB, 
GL_TEXCOORD_ARRAY_BUFFER_BINDING_ARB (0), and GL_ARRAY_BUFFER_ARB, usage hint 
is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object 
operations.




Not sure what this means exactly but I'd guess the VBO is first uploaded to the 
graphics card, then downloaded again to later re-upload into the display list? 
That sounds like while Nvidia accepts this behavior, it isn't recommending it 
from a performance standpoint.

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





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

[osg-users] Buffer object pool and setUnrefImageDataAfterApply()

[Jannik Heller]

Hi,

I was considering to use the buffer/texture object pool for my program (see 
http://forum.openscenegraph.org/viewtopic.php?t=3844=previous )

What strikes me as odd, though, is how enabling texture buffer pools 
automatically disables the use of unrefImageDataAfterApply() for textures:

/** Returns true if the associated Image should be released and it's 
safe to do so. */
bool isSafeToUnrefImageData(const State& state) const {
return (_unrefImageDataAfterApply && 
state.getMaxTexturePoolSize()==0 && areAllTextureObjectsLoaded());
}

Why is that the case? Would there be a way to use texture buffer pools while 
keeping the memory usage benefits of unref-ing the image data after its applied?

Cheers,
Jannik

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





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

Re: [osg-users] Running OSG with Emscripten

[Jannik Heller]

Hi kornerr,

Try using Geometry::setUseVertexBufferObjects(true) - this should make OSG use 
VBO's and EBO's (element buffer objects) instead of the standard display lists.

Cheers,
Jannik

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





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

Re: [osg-users] FrameStamp in osg::State

[Jannik Heller]

Found it: 
https://github.com/openscenegraph/OpenSceneGraph/commit/7aae7206369528bcc3a2d6a5ed50e16b97f44a97

I was looking at the wrong branch (duh)

That should solve all my problems, thanks Robert!

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





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

Re: [osg-users] FrameStamp in osg::State

[Jannik Heller]

Hi,

@Riccardo: Haha, that's my own post ;) The FrameSwitch node is what I currently 
do but I'm looking to clean this up a little. Since the double buffering is an 
implementation detail ideally it would be handled by the node itself rather 
than a decorator node that has to be part of scene graph. Also, having two copy 
of the same node presents a few gotchas that you need to be aware of at all 
times.


> 
> Otherwise if you need the frame number only as a reference, I think you might 
> "pile up" frame numbers during the cull visit, and then "consume" them from 
> your drawImplementation. 

Interesting idea. My first thought that wouldn't work since drawImplementation 
could be called more than once in the same frame, but, there's nothing that 
prevents the CullVisitor from "piling up" the same frame number twice either ;)

@Robert: I am using 3.4. I vaguely recall that change you talk of but couldn't 
find it in the code nor in the git log, did this get lost somehow? If not could 
you point me to it? Thanks!

Cheers,
Jannik

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





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

[osg-users] FrameStamp in osg::State

[Jannik Heller]

Hi,

I'm trying to use the frame number of the FrameStamp in osg::State for a double 
buffering implementation in my custom drawImplementation() method.

However, the frameStamp in osg::State is just a pointer so when the frame 
advances, it will be increased. The problem is that in DrawThreadPerContext 
mode, osg can advance the frame before the draw has completed, so the frame 
number seen in drawImplementation() could be one frame ahead in some cases.

Any idea what to do? Do you think OSG should be changed to produce an accurate 
frame number for osg::State?

Thank you!

Cheers,
Jannik

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





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

Re: [osg-users] Replies with "Incident ID"'s returned for every post I sent to this list... Is that normal?

[Jannik Heller]

Hey guys,

Digging deeper into this issue, I found in the mail header:

X-Report-Abuse: You can also report abuse here:
 
https://sable.madmimi.com/abuse/new?id=64170.233867.1.89772119f10a5f14edc461729ba36bd9

So I went to that URL and filled out the abuse form, this is what I filled in:

"Unsolicited email is being sent to every mailing list subscriber of the 
osg-users mailing list  whenever they make a post.

It appears as if a certain user has subscribed to the mailing list with a 
customer service mail address that creates new incident IDs for every mail 
received. Please block this user from your service."

There's another form when you google for "secureserver.net abuse", here: 
https://supportcenter.secureserver.net/AbuseReport/Index , so I filled that one 
out as well.

Please everyone who receive this mail fill out the form as well. Hopefully 
that'll make it stop.

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





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

Re: [osg-users] System requirements for OpenSceneGraph

[Jannik Heller]

Hi Nikita,

If you want to help finding the cause for the bug in master you can run a git 
bisect.

git bisect will use a binary search pattern and give you commits to test on 
your PC, usually this takes about 10 steps and you'll arrive at the problem 
commit.

http://webchick.net/node/99

Once we've identified the commit that introduced the bug it should be easy to 
find a solution.

Cheers,
Jannik

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





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

Re: [osg-users] StateSet::compileGLObjects miss typing

[Jannik Heller]

Hi LiChi,

You are correct, this is a mistake that needs to be fixed, the following 
for-loop is not even executed unless checkForGLErrors is true.

In fact, I've just spent an hour or so debugging a weird "Invalid operation" 
GL-error and it turned out to be caused by exactly this bug - the StateSet not 
compiling its state was causing the useProgram() in the GLObjectVisitor to fail 
as the program had not been compiled as expected.

I've submitted a fix for this here: 
https://github.com/openscenegraph/OpenSceneGraph/pull/169

Cheers,
Jannik

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





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

Re: [osg-users] More lights in scene!

[Jannik Heller]

Hi,

Check out my solution - no shaders needed: 
http://forum.openscenegraph.org/viewtopic.php?t=15339

Cheers,
Jannik

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





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

Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight

[Jannik Heller]

Hi Robert,

I can confirm that using dirtyGLObjects() does update the geometry.

I found a new bug, there seems to be a state leak somewhere in the interaction 
of osgUtil::IncrementalCompileOperation, VAO and dynamic geometry. It's a weird 
issue that comes and goes, some static meshes either flickering in/out of 
existance or having their vertices garbled. I am still trying to nail down the 
conditions for this elusive bug, and trying to create a reproducible example. 
Will update you with new findings.

Cheers,
Jannik

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





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

Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight

[Jannik Heller]

Hi,


> 
> I have 
> done this to avoid the extra checks required against the individual 
> arrays to see if they are dirty or not - I have done it for 
> performance reasons as I want to keep the CPU overhead for draw 
> dispatch as low as possible. 
> 

Have you done benchmarking to see if avoiding these if checks makes a 
difference? Have you considered checking the individual arrays could be 
advantageous if not all arrays have changed? For example, with a skeletally 
animated model, you would update only the vertices (and possibly normals) every 
frame while the texture coordinates, indices and colors will remain static. 
Here we could save a whole bunch of GL calls (possibly even buffer uploads?) by 
testing the arrays individually.

Perhaps we could have one "dirty" flag for the whole VAO, and if it's dirty, we 
start testing the arrays individually to see which ones changed. If VAO isn't 
dirty, no need to test the arrays.

Cheers,
Jannik

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





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

Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight

[Jannik Heller]

Hi,

I have tested out the VAO branch on my Nvidia graphics card. As you said, 
VAO+VBO is slightly faster than VBO but not as fast as display lists. Would be 
curious on the performance results with AMD cards.

Unfortunately, I am unable to use VAO for animated meshes because you've 
introduced a new meaning of the dataVariance flag. 
https://github.com/openscenegraph/OpenSceneGraph/blob/vertex_array_object/include/osg/Drawable#L523

I do *not* set the dataVariance to DYNAMIC for all my animated meshes because 
the performance overhead of DYNAMIC is not acceptable for me. If Drawables are 
set to DYNAMIC, OSG would not break frame until all the draws are submitted. I 
manage the updates using a double buffering scheme that prevents the buffer 
from being modified while the draw thread is using it. So essentially I don't 
need the DYNAMIC flag, but now I'm forced to use it (and incur the performance 
overhead associated with it) because OSG won't update the arrays if I don't. :( 
Previously it was sufficient to dirty() the vertex arrays to get OSG to update 
things. Hopefully that can be fixed.

Cheers,
Jannik

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





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

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Jannik Heller]

Hi,


> You need to think about whether you need to delete Camera's 
> dynamically during the applications life, you haven't explained why 
> you are doing this and why not keeping the Camera around is not 
> appropriate so I can't comment on the validity of what you are doing.
> 

I don't need to remove it during runtime, I remove it on exit. Obviously it's a 
good idea to remove stuff on exit to avoid memory leaks. You *could* just leave 
your scene as it is and let OSG clean it up when the viewer exits - but I like 
to follow the principle of: whoever creates an object should be responsible for 
removing it ;)


> 
> Also something that seems a bit odd - why an in scene graph Camera has
> a GraphicsContext assigned to it. Normally in scene graph Camera
> don't have an GraphicsContext, instead inherit the GraphicsContext
> from the viewer's Camera. If Camera needs it's own
> GraphicsContext/Window then would typically best done by having a
> Camera at the Viewer level rather than in the scene graph. Again I
> don't know why you've gone for the approach you have, all I can say it
> might not be appropriate.

I assigned the same GraphicsContext that I'm using for the window. I thought 
that would be equivalent to just leaving the GraphicsContext as NULL and 
letting it inherit, I didn't realize there might be side effects to explicitely 
setting the GraphicsContext.

Thanks for this note, now I have a better understanding of what 
Camera::setGraphicsContext actually does :)

So I guess we have at least 3 different workarounds then:

- Leave the camera's GraphicsContext as NULL
- Remove the Camera's children before removing the Camera
- Wait for the graphics thread to finish (i.e. stop viewer threading) before 
removing the camera

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





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

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Jannik Heller]

Hi,


> 
> The releaseGLObjects() and removeCamera() are there to make sure 
> resources are correctly cleaned up. If you really try you can break 
> it, like hiding resources from that active parts of the viewer/scene 
> graph that are their to clean up things
> 


Yes you can break it that way but I'm actually talking about a different 
breakage - the fact that resources get cleaned up that should *not* be cleaned 
up because they're still in use.

Consider:

- Camera1
-- Node1
--- Geometry1

- Camera2
-- Node2
--- Geometry1  

Now if we remove Camera1, Geometry1 gets releaseGLObjects() even though it's 
still being used by Camera2. This will result in frame drops because the 
objects have to be recompiled on the next frame.

This is not a "corner case", doing resource sharing between cameras is 
something that everyone will do to improve the performance.

My argument is that the releaseGLObjects() in GraphicsContext::removeCamera is 
so broken that we should simply remove it.

That cleanup shouldn't be necessary anyway because the GL objects are released 
when objects are destroyed. So if the object was only in use by that Camera 
(i.e. no other reference to it), the object gets destroyed and 
releaseGLObjects() after the Camera is destroyed. If there are still references 
to the object, then the user is obviously still using it so we should not 
releaseGLObjects() on it.

Cheers,
Jannik

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





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

Re: [osg-users] [About VertexArrayObject Branch] FeedBack and Insight

[Jannik Heller]

Hi,

please correct me if I'm wrong (I have a naive understanding of VAO). I don't 
see the point of VAO sharing. If a VAO can be "shared" between two Geometries, 
that means the Geometries have the same set of vertex arrays, correct? So then 
why use two separate Geometries to begin with if they are identical? You can 
re-use a Geometry by attaching it to multiple parents.

The only downside I could think of when re-using a Geometry is that a Node with 
more than one parent can cause problems (certain functions like 
getWorldMatrices() suddenly return multiple results). Or you might want to 
assign a different StateSet to each copy of the Geometry (but in that case you 
could decorate the Geometry with an intermediate node and set the StateSet 
there).

I guess this might be a case where the pre-OSG3.4 way of having a Geometry 
attached to a Geode instead of directly into the scene graph makes more sense. 
That way doing Geometry sharing doesn't result in a multi-parented graph...

Cheers,
Jannik

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





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

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Jannik Heller]

Hi,


> 
> Your crash suggests otherwise :-) 
> 


Given that there is no documentation suggesting that removing RTT camera's is 
unsafe - I just assumed it was a bug :)

As a workaround I believe that removing the Camera's children before removing 
the camera should fix the crash. That means releaseGLObjects() won't be called 
on the Camera's subgraph on destruction but to be honest that feature seems 
broken to me anyway:

What the intent probably was:
- release any GL resources that are only used by this Camera

What the code actually does:
- release any GL resources of a Node only used by this Camera *and* all its 
child-nodes (which may be shared resources still in use by other Cameras).

What are your thoughts on removing the releaseGLObjects() stuff from 
GraphicsContext::removeCamera - it is not working as intended, and removing it 
would fix the race condition as a side effect :)

Cheers,
Jannik

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





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

Re: [osg-users] Crash on exit (graphics thread removing camera)

[Jannik Heller]

Hi Robert,

I know about the restriction with viewer-level cameras (add/removeSlave).  I'm 
not using those. I'm using in-scenegraph cameras for render to texture effects.

subgraph->addChild(rttCamera);

As far as I'm aware, in-scene graph cameras are not supposed to be subject to 
threading issues and *should* be safely removable without stopping the viewer 
threading. 

Thank you!

Cheers,
Jannik

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





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

[osg-users] Crash on exit (graphics thread removing camera)

[Jannik Heller]

Hi,

I just noticed a semi-random crash on exit in my application that seems to 
point to a design issue in OSG.

In theory a crash can happen when you remove a previously used camera from the 
scene graph, then modify something in the subgraph of that camera (e.g. remove 
a node's child).

The race condition comes from the clearReferencesToDependentCameras() call in 
the graphics thread. If the graphics thread held the last reference to that 
camera, then the camera will be deleted *from the graphics thread*. The camera 
destructor indirectly includes a call to releaseGLObjects() on the camera's sub 
graph. The releaseGLObjects() will crash if the sub graph is currently being 
modified by the main thread.

Due to the race condition involved the crash is highly random so it's hard to 
make a reproducible example.

I suspect we haven't noticed this crash in the past because 
clearReferencesToDependentCameras() used to be broken (see commit 
b5a3a580762ffbeb615d73ddff732f5e8fe487b7 ).

Here's a stack trace:


Code:

Thread 2 (Thread 0x7f322525c700 (LWP 12096)):
#0  0x7f3232957ed9 in __libc_waitpid (pid=12105, stat_loc=0x7f322525b58c, 
options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40
resultvar = 12105
oldtype = 0
#1  0x009a758e in crash_catcher (signum=11, siginfo=, 
context=) at 
/home/scrawl/Dev/openmw/apps/openmw/crashcatcher.cpp:274
status = 0
dbg_pid = 12105
fd = {24, 25}
#2  
No locals.
#3  0x in ?? ()
No symbol table info available.
#4  0x7f3236a03dd3 in osg::Group::releaseGLObjects(osg::State*) const () 
from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#5  0x7f3236a03dd3 in osg::Group::releaseGLObjects(osg::State*) const () 
from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#6  0x7f3236a03dd3 in osg::Group::releaseGLObjects(osg::State*) const () 
from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#7  0x7f32369fd365 in osg::GraphicsContext::removeCamera(osg::Camera*) () 
from /home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#8  0x7f323699d0ef in osg::Camera::~Camera() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#9  0x7f323699d629 in osg::Camera::~Camera() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#10 0x7f323615ca01 in 
osgUtil::RenderStage::clearReferencesToDependentCameras() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosgUtil.so.145
No symbol table info available.
#11 0x7f3236168fa5 in 
osgUtil::SceneView::clearReferencesToDependentCameras() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosgUtil.so.145
No symbol table info available.
#12 0x7f3235a357d9 in osgViewer::Renderer::draw() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosgViewer.so.145
No symbol table info available.
#13 0x7f32369fed19 in osg::GraphicsContext::runOperations() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#14 0x7f3236a83b7a in osg::OperationThread::run() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#15 0x7f3236a01418 in osg::GraphicsThread::run() () from 
/home/scrawl/Dev/osg/build/install/lib64/libosg.so.145
No symbol table info available.
#16 0x7f323666f8e5 in OpenThreads::ThreadPrivateActions::StartThread(void*) 
() from /home/scrawl/Dev/osg/build/install/lib64/libOpenThreads.so.20
No symbol table info available.




If I had to suggest a fix I'd suggest that the 
clear/collateReferencesToDependentCameras mechanism needs to be re-designed in 
a way that it's impossible for the graphics thread to delete the camera.

Thank you!

Cheers,
Jannik

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





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

Re: [osg-users] Rendering in-scene camera from different cameras

[Jannik Heller]

Looking at the OSG code more closely there may be an easier way.

If you set the Camera's render order to NESTED_RENDER, it *will* inherit the 
currently used render target.

Then set a RenderBin number on the camera to make sure it's drawn after the 
scene. That should do it.

Cheers,
Jannik

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





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

Re: [osg-users] Rendering in-scene camera from different cameras

[Jannik Heller]

Hi,

A Camera does not inherit the render target implementation, it will simply use 
what is specified (default FRAMEBUFFER).

You bring up a valid use case, perhaps adding an "inherit render target" mode 
for Cameras would be a nice feature for the osg core to have.

For the time being what I would suggest is that you don't really need a Camera, 
you just need a way to set the modelView and projection matrices to identity 
before drawing your GUI (i.e. work in screen relative coordinates). You can do 
that with a cull callback:


Code:

class ScreenRelativeCallback : public osg::NodeCallback
{
   virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
   {
   osgUtil::CullVisitor* cv = dynamic_cast(nv);
   if (cv)
   {
   cv->pushModelViewMatrix(new osg::RefMatrix(), 
osg::Transform::ABSOLUTE_RF);
   cv->pushProjectionMatrix(new osg::RefMatrix());
   
   traverse(node, nv);

   cv->popModelViewMatrix();
   cv->popProjectionMatrix();
   }
   else
  traverse(node, nv);
   }



Then instead of decorating your GUI with a Camera, you decorate it with a Group 
and add the cull callback: group->addCullCallback(new ScreenRelativeCallback);

In addition you may need to set a RenderBin so that the GUI is drawn after the 
scene.

I haven't tested this out but I believe it will work.

Cheers,
Jannik

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





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

Re: [osg-users] Get openGL version with the Help of osg

[Jannik Heller]

Hi,

Unfortunately OpenGL doesn't support getting the supported version without 
creating a context first.

https://gamedev.stackexchange.com/questions/28451/how-do-i-properly-check-if-a-particular-opengl-version-is-available

https://stackoverflow.com/questions/12184506/why-does-glgetstringgl-version-return-null-zero-instead-of-the-opengl-versio

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





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

Re: [osg-users] Keep Geometry always visible withtout occlusions

[Jannik Heller]

Hi,

Indeed, the depth attribute is the way to go. You also need to set a high 
RenderBin number to make sure that the object you don't want occluded is always 
rendered last:


Code:

mygeometry->getOrCreateStateSet()->setAttributeAndModes(new 
osg::Depth(osg::Depth::ALWAYS), osg::StateAttribute::ON);
mygeometry->getOrCreateStateSet()->setRenderBinDetails(1000, "RenderBin");




Cheers,
Jannik

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





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

Re: [osg-users] Pass an osg::Texture2D to CUDA driver api

[Jannik Heller]

Hi Philipp,


> 
> Also, Im having the issue that my drawCallback is only executed during the 
> first frame and then skipped. Ive disabled culling and depth testing. 
> 

You need to disable display lists on your drawable. With display lists enabled 
it will only draw once and then use the display list. This makes no sense when 
using Cuda obviously.


> 
> Does anyone know why that happens? From my understanding, the renderbin 
> number should determine the order of draw (and therefore also of the 
> drawCallback?) operations. 
> 

I think this may also be related to the display list being enabled, the 
compileGLObjects() that is run in the first frame will compile display lists 
but not necessarily in the order of the render bins.

Cheers,
Jannik

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Jannik Heller]

Hi Robert,

Thanks for fixing the warning.

Just let you know, I did a build of OpenMW against OSG 3.5.3 and did not 
encounter any build- or runtime problems.

Cheers,
Jannik

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





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

Re: [osg-users] Preparing to make 3.5.3 dev release, please test

[Jannik Heller]

Hi Robert,

I haven't finished building yet, but right off the bat I get about a million of 
these warnings:

Code:

/home/scrawl/Dev/osg/include/osg/Vec3us:34:58: warning: declaration of ‘g’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Vec4f:46:9: warning: declaration of ‘y’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Vec3i:53:9: warning: declaration of ‘g’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Vec3i:53:9: warning: declaration of ‘r’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Vec4f:46:9: warning: declaration of ‘x’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Vec4f: In constructor ‘osg::Vec4f::Vec4f(const 
osg::Vec3f&, osg::Vec4f::value_type)’:
/home/scrawl/Dev/osg/include/osg/Vec4f:54:9: warning: declaration of ‘w’ 
shadows a member of 'this' [-Wshadow]

/home/scrawl/Dev/osg/include/osg/Viewport:34:79: warning: declaration of 
‘width’ shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Viewport:34:79: warning: declaration of ‘y’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Viewport:34:79: warning: declaration of ‘x’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Viewport: In member function ‘void 
osg::Viewport::setViewport(osg::Viewport::value_type, 
osg::Viewport::value_type, osg::Viewport::value_type, 
osg::Viewport::value_type)’:
/home/scrawl/Dev/osg/include/osg/Viewport:80:9: warning: declaration of 
‘height’ shadows a member of 'this' [-Wshadow]

/home/scrawl/Dev/osg/include/osg/Image: In member function ‘void 
osg::Image::scaleImage(int, int, int)’:
/home/scrawl/Dev/osg/include/osg/Image:218:44: warning: declaration of ‘r’ 
shadows a member of 'this' [-Wshadow]
 void scaleImage(int s,int t,int r) { scaleImage(s,t,r, getDataType()); 
}
^
/home/scrawl/Dev/osg/include/osg/Image:218:44: warning: declaration of ‘t’ 
shadows a member of 'this' [-Wshadow]
/home/scrawl/Dev/osg/include/osg/Image:218:44: warning: declaration of ‘s’ 
shadows a member of 'this' [-Wshadow]




I'm using g++ 4.8.4.

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





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

Re: [osg-users] Submission/Pull Request problems on github

[Jannik Heller]

Hi Robert,

by fixing the author names you have essentially re-written the repository 
history. This means that everyone who submitted pull-requests in the past will 
have to manually rebase their changes on top of the new history. But it's not 
so difficult to do that if you know how to use the git rebase tool.

The github document "Changing author info" (which I assume you were looking 
at?) does state this caveat:

"Note: Running this script rewrites history for all repository collaborators. 
After completing these steps, any person with forks or clones must fetch the 
rewritten history and rebase any local changes into the rewritten history."

In the future you may want to avoid rewriting history (i.e. anything that 
requires a force-push) since it does cause disruption for people that have 
already sent in changes. But it's not a big deal now since github is not even 
the official submission route yet.

As for checking out the changes in pull requests that were not adapted, you can 
look at the author's repository (e.g. 
https://github.com/vivijind/OpenSceneGraph/commits/master shows the commits for 
PR https://github.com/openscenegraph/OpenSceneGraph/pull/68). In some cases it 
looks like the authors have deleted their repository, but you can still check 
out the pull request locally ( 
https://help.github.com/articles/checking-out-pull-requests-locally/ ) and from 
there look at the included commits.

Cheers,
Jannik

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





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

Re: [osg-users] Clear scene data and underlying memory structures

[Jannik Heller]

Hi,

There may be some memory allocations left in the graphics driver. OSG does all 
the OpenGL work from a background thread, so the memory used by OpenGL can not 
be reclaimed immediately upon removing the node from the scene. Try calling 
frame() a few times and then see if your memory usage decreases again.

Cheers,
Jannik

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





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

Re: [osg-users] setCullMask and computeBounds of nodes

[Jannik Heller]

Hi Andrew,

the computeBound() does not respect node masks. In theory it would be possible 
to skip the bounds update for nodes that were filtered by the cull mask, but 
implementing this would get complicated quickly - you have to consider there 
may be different cameras with different masks, maybe even running their cull 
phase in different threads (e.g. with the CullThreadPerCamera threading mode). 
So, for simplicity, the OSG will just computeBound() once per frame before the 
culling starts. Note, however, that bounds will *not* be updated for nodes that 
have not moved, so the bounding update is usually not a performance issue 
anyway.

Cheers,
Jannik

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





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

Re: [osg-users] Doxygen thinks Drawable inherits from Node

[Jannik Heller]

Hi,

Actually the docs are correct, since OSG version 3.4 Drawable does inherit from 
Node. It seems that you might have a version older than 3.4 locally.

Cheers,
Jannik

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





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

Re: [osg-users] Segfault when using addChild on Group object

[Jannik Heller]

Hi,

turns out that my error was caused by mismatched OSG headers / libs. I had a 
LD_LIBRARY_PATH in my .bashrc that pointed to a different OSG installation than 
the one in /usr. Could you double check what libraries your executable is 
linked against. To do so run:

Code:

ldd ./executable



Example:libosg.so.130 => /usr/lib/x86_64-linux-gnu/libosg.so.130 
(0x7ff47bdd9000)

These libraries should match the include path (-I) to the OSG headers. Don't 
mix headers/libs of a different version.

Cheers
Jannik

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





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

Re: [osg-users] Segfault when using addChild on Group object

[Jannik Heller]

Hi,

I confirm that your example crashes. I actually reduced the code even further 
and still got a crash:


Code:

#include 
#include 

#include 

int main()
{
  osg::ref_ptr foo = new osg::Group;
  foo->addChild(new osg::Group);

  std::cout << "foo has " << foo->getNumChildren() << " children" << std::endl;
}




Seems to be a memory corruption going on... I'm sure there's just a really 
silly mistake in the code but I can't spot it for the life of me.

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





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

Re: [osg-users] Why isn't OpenSceneGraph used in games?

[Jannik Heller]

Hi,

Good point, but I think there's more to it than just performance. There are 
games using off-the-shelf scene graphs, for example Bethesda RPG games (Elder 
Scrolls, Fallout) are built on Gamebryo, which is a general purpose scene graph 
much like the OSG. (Note Gamebryo is a bit more than just a scenegraph, it also 
has game engine functionality e.g. physics, but that's besides the point).

https://en.wikipedia.org/wiki/Category:Gamebryo_engine_games

I think we can categorise most AAA devs into two groups:
1. People that want to roll everything on their own (and have the resources to 
do so)
and 2. People that want to build on a complete game engine (asset pipeline, 
physics engine, etc. think Unity, Unreal, Gamebryo).

OSG is kind of in a niche since it doesn't fit either group.

I also think there may be a stigma against free/open sources engines. (Maybe 
related to licensing and/or paid support). 

Third, there is the fact that Direct3D has had a dominant position in the games 
industry for years, and OSG in built on OpenGL only.

Cheers,
Jannik

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





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

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

[Jannik Heller]

Hi Robert

Actually there is a bug here. The ShaderComposer::releaseGLObjects does not 
override because it is declared without the const specifier. 
Object::releaseGLObjects is declared const.


> osg::Object::releaseGLObjects is virtual, but 
> osg::ShaderComposer::releaseGLObjects is not. Is there a reason why? 

The virtual keyword doesn't really have a meaning in overridden functions. 
Still wouldn't hurt to add it though.

Cheers
Jannik

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





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

Re: [osg-users] Sync main camera with slave camera rotation

[Jannik Heller]

Hi,

The camera manipulator (which sets the main camera's view matrix) is updated at 
the end of the update traversal. So, you need to make sure your sync code runs 
after the update traversal and not before - else you'll be working with the 
last frame's data which is probably what's introducing the flicker.

Something like this should work. There may be a more elegant solution.

// instead of mViewer->frame(); syncCamera(); :

mViewer->eventTraversal();
mViewer->updateTraversal();
syncCamera();
mViewer->renderingTraversals();

Cheers,
Jannik

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





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

Re: [osg-users] cull traversal

[Jannik Heller]

>  I did it in a simpler way by adding a node at the end of the scenegraph and 
> set a cullcallback and it works 

Yes, that should work. You could also set a cull callback on the root node, and 
in the callback do this:

traverse(node, nv); // cull scene root

// end of cull traversal

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





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

Re: [osg-users] Whether a viewer is required for every osg based application?

[Jannik Heller]

Hi,

osgViewer is what dispatches updates to the scene graph, fires off cull and 
rendering, manages the camera, and abstracts the platform-specific graphics 
context creation routines, among other things. You could bypass osgViewer if 
you implemented these tasks yourself, but I imagine it would be quite tedious. 
I would suggest to use Viewer even with off-screen applications.

Cheers,
Jannik

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





___
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

[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] GraphicContext null

[Jannik Heller]

You can work around the issue using ScreenIdentifier::readDISPLAY() and passing 
that ScreenIdentifier to WindowingSystemInterface::getNumScreens()


Code:

osg::GraphicsContext::ScreenIdentifier si;
si.readDISPLAY();

windowingSystemInterface->getNumScreens(si); 




I wonder if OSG should read the display by default in the ScreenIdentifier() 
constructor?

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





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

Re: [osg-users] Processor Affinity and forked processes

[Jannik Heller]

Hi Robert,


> I merged what were supposed to be "fixes" to the OpenThreads from a user 
> submissions between OSG-3.2 and 3.4.  The change in behaviour might stem from 
> this, try reverting these changes and see what happens. 
> 


the setting of thread affinity for the main thread in 
ViewerBase::setUpThreading 
https://github.com/openscenegraph/osg/blob/master/src/osgViewer/ViewerBase.cpp#L153
 has been there since at least 2007. The recent change on osg-submissions 
simply enabled the thread affinity feature to work on Linux (as it was 
previously a no-op), but there is nothing wrong with the submission as such.

Curiously the affinity setting in ViewerBase::setUpThreading is only done when 
threadingMode is set to SingleThreaded, which is probably why the issue wasn't 
noticed sooner.

It's not advisable to set the cpu affinity for the main thread (especially not 
in a general purpose library), since the setting also affects threads spawned 
from client code.

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





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

Re: [osg-users] Compute occluding transparent objects

[Jannik Heller]

Hi Pierre-Jean,

put your objects in the SORT_FRONT_TO_BACK render bin.

stateset->setRenderBinDetails(binNumber, "SORT_FRONT_TO_BACK"); 

Ensure that this particular binNumber is only used for objects you want sorted 
front to back, so that the render bin can be created correctly.

The render bin prototypes provided by default in OSG are documented here: 
https://github.com/openscenegraph/osg/blob/master/src/osgUtil/RenderBin.cpp#L35

Cheers,
Jannik

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





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

Re: [osg-users] Mac compilation error

[Jannik Heller]

Hi,

There is already a submission addressing this, but it wasn't merged yet.

http://forum.openscenegraph.org/viewtopic.php?t=15401


Cheers,
Jannik

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





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

[osg-users] LineSegmentIntersector NaN warnings on zero-scaled nodes.

[Jannik Heller]

Hi,

The LineSegmentIntersector creates NaN warnings when applied to a node with 
zero scale. I've attached a 3 line change to osgintersection.cpp to reproduce 
the issue.

The NaN's first pop up when OSG tries to invert a zero matrix here: 
https://github.com/openscenegraph/osg/blob/master/src/osgUtil/LineSegmentIntersector.cpp#L294

Check with the following code snippet:

Code:

osg::Matrix zero(0,0,0,0, 0,0,0,0, 0,0,0,0, 0,0,0,1);

if (zero.invert(zero))
std::cout << "inverted " << zero << std::endl;



invert() returns true but the inverted matrix is 

inverted {
-nan -nan -nan 0 
-nan -nan -nan 0 
-nan -nan -nan 0 
nan nan nan 1 
}

This looks like a bug in the Matrix invert function.

However even if the matrix was still zero instead of NaN, there is another 
issue here:

osg::ref_ptr lsi = new 
LineSegmentIntersector(_start * matrix, _end * matrix);

Multiplying a vec3 with a zero matrix will cause NaN's, because there is an 1.0 
/ (mat * vec ...) in the Matrix::preMult(Vec3) function.

Not sure on the best way to fix this. Should we add explicit checks for zero 
scaled matrices in the LineSegmentIntersector, or fix the Matrix and Vec 
classes so they don't produce NaN's under any circumstances for (borderline) 
valid input? The latter seems the cleaner fix but would have a performance 
impact all over OSG.

Thank you!

Cheers,
Jannik

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



/* OpenSceneGraph example, osgintersection.
*
*  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 

struct MyReadCallback : public osgUtil::IntersectionVisitor::ReadCallback
{
#if 0
virtual osg::Node* readNodeFile(const std::string& filename)
{
return osgDB::readRefNodeFile(filename).release();
}
#endif
virtual osg::ref_ptr readNodeFile(const std::string& filename)
{
return osgDB::readRefNodeFile(filename);
}
};


int main(int argc, char **argv)
{
// use an ArgumentParser object to manage the program arguments.
osg::ArgumentParser arguments(,argv);

osg::ref_ptr scene = osgDB::readRefNodeFiles(arguments);

if (!scene)
{
std::cout<<"No model loaded, please specify a valid model on the command line."<addChild(scene);
transform->setScale(osg::Vec3f(0,0,0));
transform->setCullingActive(false);


std::cout<<"Intersection "<getBound();

scene = transform;


bool useIntersectorGroup = true;
bool useLineOfSight = true;

//osg::CoordinateSystemNode* csn = dynamic_cast(scene.get());
//osg::EllipsoidModel* em = csn ? csn->getEllipsoidModel() : 0;

if (useLineOfSight)
{

osg::Vec3d start = bs.center() + osg::Vec3d(0.0,bs.radius(),0.0);
osg::Vec3d end = bs.center() - osg::Vec3d(0.0, bs.radius(),0.0);
osg::Vec3d deltaRow( 0.0, 0.0, bs.radius()*0.01);
osg::Vec3d deltaColumn( bs.radius()*0.01, 0.0, 0.0);

osgSim::LineOfSight los;

#if 1
unsigned int numRows = 20;
unsigned int numColumns = 20;
osgSim::HeightAboveTerrain hat;
hat.setDatabaseCacheReadCallback(los.getDatabaseCacheReadCallback());

for(unsigned int r=0; rtick();

Re: [osg-users] First steps to improve culling

[Jannik Heller]

There is a very high number of PrimitiveSets in your screenshot. In fact you 
seem to have roughly one PrimitiveSet per 4 vertices, that is ridiculous. Each 
PrimitiveSet needs an OpenGL draw call to render it. Try reorganizing your 
models to use as few PrimitiveSet's as possible.

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





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

Re: [osg-users] [build] using 3Ds Model in osgFX::BumpMapping and the Texture UV Coords for diffuse are not loaded

[Jannik Heller]

Hi Tobias,

The texture matrix is a fixed function state that may not have an effect when a 
shader is used. To get the desired effect, the shader code needs to get the 
texture matrix via gl_TextureMatrix built in variable and then multiply the 
texture coordinates with it. I presume the osgFX::BumpMapping shader is not 
doing this.

The osgFX::BumpMapping shader appears to be written in ARB assembly rather than 
GLSL, so it's a bit difficult to modify it. You might be better off writing 
your own shader in GLSL.

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





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

[osg-users] status of git mirror

[Jannik Heller]

Hi,

I noticed that the git mirror at https://github.com/openscenegraph/osg hasn't 
been updated in a few weeks. It's still at r15151 while the svn is at r15172. 
Is there a problem?

I found the mirror really useful for looking at changes, as well I used git to 
prepare all my patches, so hopefully the git mirror can be restored!

In the meantime, is there a webinterface for looking at the latest svn changes? 
http://svn.openscenegraph.org/osg/OpenSceneGraph/ gives access to files, but no 
revision log.

Thank you!

Cheers,
Jannik

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





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

Re: [osg-users] particle speed in OSG Particle Effects

[Jannik Heller]

Hi Nick,

the particle template's velocity isn't used, it's the particle emitter that 
determines initial particle velocity. Have a look at the ModularEmitter / 
Shooter classes in osgParticle.

If you wanted to globally make particles simulate faster (as in a time lapse) 
you could just change the osg simulationTime to run faster.

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





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

Re: [osg-users] Culling with custom clip planes

[Jannik Heller]

Hi Robert,

I have just noticed that approach of adding culling planes doesn't work 100% 
accurately. Some meshes that have their bounding box fully outside of the 
culling plane don't get culled.

To test with please check the attached osgreflect.cpp. I added a culling plane 
so that everything above the mirror mesh should get culled. The aircraft and 
the sphere are clearly above, but don't get culled for some reason:

https://i.imgur.com/ip0iIc9.png

Once I move the sphere up by 2 more units then it gets culled.
transform->setMatrix(osg::Matrix::translate(osg::Vec3f(20, 20, z + 
sphereRadius + 4)));

For the aircraft, the inaccuracy seems to be larger. I have to move the culling 
plane down by 21 units before the aircraft gets culled:

rootNode->addCullCallback(new 
PlaneCullCallback(osg::Plane(osg::Vec3d(0,0,-1),osg::Vec3d(0,0,z-21;

Any ideas why this could be happening?

Thanks,
Jannik

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



/* OpenSceneGraph example, osgreflect.
*
*  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 

//
// A simple demo demonstrating planar reflections using multiple renderings
// of a subgraph, overriding of state attribures and use of the stencil buffer.
//
// The multipass system implemented here is a variation of Mark Kilgard's
// paper "Improving Shadows and Reflections via the Stencil Buffer" which
// can be found on the developer parts of the NVidia web site.
//
// The variations comes from the fact that the mirrors stencil values
// are done on the first pass, rather than the second as in Mark's paper.
// The second pass is now Mark's first pass - drawing the unreflected scene,
// but also unsets the stencil buffer.  This variation stops the unreflected
// world poking through the mirror to be seen in the final rendering and
// also obscures the world correctly when on the reverse side of the mirror.
// Although there is still some unresolved issue with the clip plane needing
// to be flipped when looking at the reverse side of the mirror.  Neither
// of these issues are mentioned in the Mark's paper, but trip us up when
// we apply them.



class PlaneCullCallback : public osg::NodeCallback
{
public:
PlaneCullCallback(const osg::Plane& cullPlane)
: osg::NodeCallback()
, mCullPlane(cullPlane)
{
}

PlaneCullCallback(const PlaneCullCallback& copy, const osg::CopyOp& copyop)
: osg::NodeCallback(copy, copyop)
, mCullPlane(copy.mCullPlane)
{
}

PlaneCullCallback()
{
}

META_Object(MWRender, PlaneCullCallback)

virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor* cv = dynamic_cast(nv);
if (cv)
{
osg::Polytope::PlaneList origPlaneList = cv->getCurrentCullingSet().getFrustum().getPlaneList();

cv->getCurrentCullingSet().getFrustum().add(mCullPlane);

traverse(node, nv);

// undo
cv->getCurrentCullingSet().getFrustum().set(origPlaneList);
}
else
traverse(node, nv);
}

void setCullPlane (const osg::Plane& plane)
{
mCullPlane = plane;
}

private:
osg::Plane mCullPlane;
};

osg::StateSet* createMirrorTexturedState(const std::string& filename)
{
osg::StateSet* dstate = new osg::StateSet;
dstate->setMode(GL_CULL_FACE,osg::StateAttribute::OFF|osg::StateAttribute::PROTECTED);

// set up the texture.
osg::Image* image = osgDB::readImageFile(filename.c_str());
if (image)
{
osg::Texture2D* texture = new osg::Texture2D;
texture->setImage(image);
dstate->setTextureAttributeAndModes(0,texture,osg::StateAttribute::ON|osg::StateAttribute::PROTECTED);
}

return dstate;
}


osg::Drawable* 

Re: [osg-users] Culling with custom clip planes

[Jannik Heller]

Oops, wrong file. Use this one please.

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



/* OpenSceneGraph example, osgreflect.
*
*  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 

//
// A simple demo demonstrating planar reflections using multiple renderings
// of a subgraph, overriding of state attribures and use of the stencil buffer.
//
// The multipass system implemented here is a variation of Mark Kilgard's
// paper "Improving Shadows and Reflections via the Stencil Buffer" which
// can be found on the developer parts of the NVidia web site.
//
// The variations comes from the fact that the mirrors stencil values
// are done on the first pass, rather than the second as in Mark's paper.
// The second pass is now Mark's first pass - drawing the unreflected scene,
// but also unsets the stencil buffer.  This variation stops the unreflected
// world poking through the mirror to be seen in the final rendering and
// also obscures the world correctly when on the reverse side of the mirror.
// Although there is still some unresolved issue with the clip plane needing
// to be flipped when looking at the reverse side of the mirror.  Neither
// of these issues are mentioned in the Mark's paper, but trip us up when
// we apply them.



class PlaneCullCallback : public osg::NodeCallback
{
public:
PlaneCullCallback(const osg::Plane& cullPlane)
: osg::NodeCallback()
, mCullPlane(cullPlane)
{
}

PlaneCullCallback(const PlaneCullCallback& copy, const osg::CopyOp& copyop)
: osg::NodeCallback(copy, copyop)
, mCullPlane(copy.mCullPlane)
{
}

PlaneCullCallback()
{
}

META_Object(MWRender, PlaneCullCallback)

virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor* cv = dynamic_cast(nv);
if (cv)
{
osg::Polytope::PlaneList origPlaneList = cv->getCurrentCullingSet().getFrustum().getPlaneList();

cv->getCurrentCullingSet().getFrustum().add(mCullPlane);

traverse(node, nv);

// undo
cv->getCurrentCullingSet().getFrustum().set(origPlaneList);
}
else
traverse(node, nv);
}

void setCullPlane (const osg::Plane& plane)
{
mCullPlane = plane;
}

private:
osg::Plane mCullPlane;
};

osg::StateSet* createMirrorTexturedState(const std::string& filename)
{
osg::StateSet* dstate = new osg::StateSet;
dstate->setMode(GL_CULL_FACE,osg::StateAttribute::OFF|osg::StateAttribute::PROTECTED);

// set up the texture.
osg::Image* image = osgDB::readImageFile(filename.c_str());
if (image)
{
osg::Texture2D* texture = new osg::Texture2D;
texture->setImage(image);
dstate->setTextureAttributeAndModes(0,texture,osg::StateAttribute::ON|osg::StateAttribute::PROTECTED);
}

return dstate;
}


osg::Drawable* createMirrorSurface(float xMin,float xMax,float yMin,float yMax,float z)
{

// set up the drawstate.

// set up the Geometry.
osg::Geometry* geom = new osg::Geometry;

osg::Vec3Array* coords = new osg::Vec3Array(4);
(*coords)[0].set(xMin,yMax,z);
(*coords)[1].set(xMin,yMin,z);
(*coords)[2].set(xMax,yMin,z);
(*coords)[3].set(xMax,yMax,z);
geom->setVertexArray(coords);

osg::Vec3Array* norms = new osg::Vec3Array(1);
(*norms)[0].set(0.0f,0.0f,1.0f);
geom->setNormalArray(norms, osg::Array::BIND_OVERALL);

osg::Vec2Array* tcoords = new osg::Vec2Array(4);
(*tcoords)[0].set(0.0f,1.0f);
(*tcoords)[1].set(0.0f,0.0f);
(*tcoords)[2].set(1.0f,0.0f);
(*tcoords)[3].set(1.0f,1.0f);
geom->setTexCoordArray(0,tcoords);

osg::Vec4Array* colours = new osg::Vec4Array(1);
(*colours)[0].set(1.0f,1.0f,1.0,1.0f);

Re: [osg-users] Culling with custom clip planes

[Jannik Heller]

Hi,

The interaction of CullingSet, CullStack and CullVisitor is really confusing to 
look at, but I think I have a lead!

It seems like the added frustum plane is reset right here: 
https://github.com/openscenegraph/osg/blob/master/src/osg/CullStack.cpp#L214 
when the cull visitor applies a transform.  So the approach of adding a plane 
in the CullCallback won't work on the whole subgraph.

Looking at the code if I change the frustum on the projectionCullingStack 
instead of modelViewCullingStack, it should persist for the whole subgraph... 
but then I have to specify my culling plane in projection space instead of 
model space, which is a bit annoying. I will keep looking for a solution.

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





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

Re: [osg-users] Culling with custom clip planes

[Jannik Heller]

Ok, setting on projectionCullingStack works fine for the whole subgraph, you 
just have to transform the plane to view space first:


Code:

virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
{
osgUtil::CullVisitor* cv = dynamic_cast(nv);
if (cv)
{
osg::CullingSet& cullingStack = 
cv->getProjectionCullingStack().back();

osg::Polytope::PlaneList origPlaneList = 
cullingStack.getFrustum().getPlaneList();

osg::Plane transformed = mCullPlane;
transformed.transform(cv->getCurrentCamera()->getViewMatrix());

cullingStack.getFrustum().add(transformed);

traverse(node, nv);

// undo
cullingStack.getFrustum().set(origPlaneList);
}
else
traverse(node, nv);
}



It's a bit ugly, but good enough for me. Unless Robert has a better idea, I'll 
stick with this approach!

Cheers,
Jannik[/code]

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





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

[osg-users] Many lights in OSG - solution

[Jannik Heller]

Hi OSG friends,

I will be wrapping up my OpenMW port to OpenSceneGraph soon and wanted to share 
a few things with you that I learned along the way. One such thing is the 
lighting system that I wrote. If you do a quick search on the mailing list, you 
will see that the OpenGL fixed pipeline supports a maximum of 8 simultaneous 
lights and OSG inherits this limit. I have a lot more lights in my scenes, so I 
had to come up with a solution.

What I ended up with is a new lighting system, that allows you to place any 
number of light sources in the scene graph, but then prior to rendering a 
particular model will set the 8 closest lights as the OpenGL lights. This is 
implemented as CullCallback for the individual models, pushing a StateSet with 
the correct lights onto the CullVisitor. I also needed to implement a custom 
StateAttribute for the light state, this is because when applying lights OpenGL 
multiplies the position specified with the current modelView matrix (which is 
no problem when you apply lights at beginning of frame like OSG does, but in my 
case the lights are applied in between renderning of models,Ii need to apply 
the lights in world space rather than relative to that model). The solution was 
to write a custom light StateAttribute that resets the modelView matrix to just 
the view matrix before applying the state, then reset again to modelView when 
done.

The code is here and it should be easily adaptable to your own applications:

https://github.com/OpenMW/openmw/blob/master/components/sceneutil/lightmanager.cpp
https://github.com/OpenMW/openmw/blob/master/components/sceneutil/lightmanager.hpp

Usage is pretty straight forward:

- Decorate your scene graph with a LightManager node.
- Create any number of LightSource's in the scene graph. The lightNum of the 
contained lights do not matter as they are not used.
- Make sure that you have Mask_Lit (1<<16) in your update and cull masks where 
lighting is desired.
- Add some LightListCallback's as CullCallback in your scene graph. Where you 
put the callbacks determines the granularity of the light lists, so can have an 
impact on visuals and performance. I recommend adding the callback onto 
individual model(s) (but not necessarily individual Drawable's as that would be 
slower).

You can also combine the LightManager with regular OSG lighting. For example, 
if you need a "global" directional light in your scene that is always active, 
you can create it as a regular osg::LightSource and tell the LightManager to 
skip over it, using setStartLight(1). This would mean the LightManager is only 
managing lights 1-7 rather than all 8.

Hope this might be useful to some OSG users as it took me a while to put 
together. I did find a previous topic about the subject ( 
http://forum.openscenegraph.org/viewtopic.php?t=8325=previous ) but no 
satisfying solution was posted.

I wonder if there is enough interest, could this turn into an official OSG 
example? Or even a new NodeKit or part of the core scene graph? 

By the way, I am super impressed that I was able to implement this feature 
without changing one line of code within OSG - the flexibility you get with the 
various visitors and callbacks is amazing. A big kudos goes to Robert for 
making the OSG so extensible!

Cheers,
Jannik

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





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

Re: [osg-users] Many lights in OSG - solution

[Jannik Heller]

Hi Chris,

Thanks for the comment. From what I can tell, Forward+ is the same technique 
that I'm doing, except that it uses grid culling to accelerate the building of 
light lists. This will give you a performance boost in scenes with thousands of 
lights, but isn't necessary otherwise. For me the light list collection isn't 
really a bottleneck at the moment, but this will depend on your scene of course.


> 
> Have you considered a non-FFP solution? Withthis, you could have more than 8 
> lights. 
> 

Yeah, I know. I will add shaders at some later point, but the FFP will remain 
as fallback (I want it to run on old hardware).

Shaders are always very engine specific, so you couldn't really make them into 
a general purpose plugin like I'm proposing here ;)

There are two interesting ways to leverage shaders:
- Adjust the fragment shader to handle more than GL_MAX_LIGHTS, pass the lights 
via uniforms. This would raise the "simultaneous" light limit per object, but 
you'll still want some sort of light culling or performance would be bad.
- Switch to a deferred shading. Gives you freedom to run thousands of lights 
with good performance, but if you don't use that many lights then forward 
rendering will perform better. Also, deferred shading has problems with 
transparent objects, and problems with material variety since the final shading 
all runs through the same fragment shader (there is a "spin-off" technique of 
deferred shading that addresses the material variety problem, I forgot what 
it's called). Sometimes you can reuse channels of the g-buffer for other 
effects like SSAO or depth of field. All this requires a careful consideration 
of your requirements before you start so deferred rendering is not something 
you would add to your engine overnight.

Cheers,
Jannik

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





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

Re: [osg-users] Maximizing rendering throughput

[Jannik Heller]

Hi Sebastian,

You may be interested in this topic, where I discuss some workarounds to 
setting objects to DYNAMIC: 
http://forum.openscenegraph.org/viewtopic.php?t=14849

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





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

[osg-users] Using a custom StateAttribute

[Jannik Heller]

Hi,

How is one supposed to use a custom StateAttribute?

The docs say that:

"When extending the osg's StateAttribute's simply define your own Type value 
which is unique, using the StateAttribute::Type enum as a guide of what values 
to use"

As it is, returning a unique value simply isn't possible because the getType() 
function returns an enum:

/** Return the Type identifier of the attribute's class type.*/
virtual Type getType() const = 0;

Type is the enum defined here containing the default types, with no room for 
user types:


Code:

enum Type
{
TEXTURE,

POLYGONMODE,
 

FRAME_BUFFER_OBJECT
};




I suppose that you could choose some integer, static_cast it back to enum Type 
and then hope that will work. (it will most likely work if the enum has a large 
enough bit size, but it's technically undefined behaviour, so I can't imagine 
that's how Robert intended it to be used).

To me it seems the feature advertised in docs of creating your own 
StateAttributes simply isn't possible, just because of this one function 
returning enum instead of int, which would be an easy fix. Am I missing 
something here?

Cheers,
Jannik

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





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

Re: [osg-users] Error: Not able to create requested visual. for osg application utilizing multi-sampling, ran with optirun.

[Jannik Heller]

This might be simply a driver limitation. Not all hardware and drivers support 
multisampling. For example, I'm using OSG on Mesa + Intel HD Graphics which 
doesn't support multisampling at all.

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





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

Re: [osg-users] OSG 3.4.0 RC10 OSX - Viewport spans multiple monitors

[Jannik Heller]

Hi Paolo,


 On a related topic, is there a way to query how many screens are available? 
 


Try this:


Code:

unsigned int numScreens = 
osg::GraphicsContext::getWindowingSystemInterface()-getNumScreens();




Cheers,
Jannik

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





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

Re: [osg-users] NodeVisitor finds the named Node, but NodeCallback doesn't rotate it

[Jannik Heller]

The MatrixTransform you are creating isn't actually in the scene graph.

What you have now is:

Root - (some parent) - Node

as well as a completely detached graph that won't have an effect.
MatrixTransform - Node

What you need instead is:

Root - (some parent) - MatrixTransform - Node

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





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

Re: [osg-users] How can I delete skybox from the memory totally

[Jannik Heller]

 If I use m_SkyNode.release(), the memory increases again and again. 
 


The release() function unassigns the pointer, but without freeing it (see the 
function documentation). What you want instead is


Code:

m_SkyNode = NULL;




You seem to be fairly confused about the concept of shared pointers, so perhaps 
you should read up on that concept before diving into using them with the OSG.
 
[/code]

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





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

Re: [osg-users] what's wrong with removechild

[Jannik Heller]

Looks like you aren't showing us the whole code. I don't see a removeChild in 
the attached file.

In general, when removing a node you need to remove it as child of its 
particular parent(s) (which is not necessarily the root node).


Code:

while (node-getNumParents())
node-getParent(0)-removeChild(node);




[/code]

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





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

Re: [osg-users] [build] Compile on Release error: LNK2001 OpenThreads::Atomic::operator++

[Jannik Heller]

Hi,

AFAIK all OSG applications must link to OpenThreads. Even if you are not using 
it directly, you might be calling an inlined OSG function that uses OpenThreads.

Are you using CMake in your project? If you do, then 
${OPENSCENEGRAPH_LIBRARIES} should include the OpenThreads library by default.

Cheers,
Jannik

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





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

Re: [osg-users] issue about getting the material properties from the current state in rendering info

[Jannik Heller]

Hi Gianluca,


 The _attributeMap actually contains as MATERIAL attribute exactly the pointer 
 to the osg::Material property that I created. 
 But in the attribute stack it appears as the ‘last_applied_attribute’, and 
 ‘changed’ is set to true. 
 For all other attributes the pointers stored in ‘last_applied_attribute’ are 
 correct as well, but ‘changed’ is set to false. 


try calling osg::State::apply() to apply changed state that hasn't been applied 
yet.

Cheers,
Jannik

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





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

Re: [osg-users] How to use more than 4 texture units?

[Jannik Heller]

Hi,

I seem to have hit the same problem. Texture slots 0-3 work fine, 4 and up 
don't show.

To reproduce is very simple, you change the osgbillboard example to bind to 
texture slot 4.


Code:

diff --git a/examples/osgbillboard/osgbillboard.cpp 
b/examples/osgbillboard/osgbillboard.cpp
index a6243e8..07e9274 100644
--- a/examples/osgbillboard/osgbillboard.cpp
+++ b/examples/osgbillboard/osgbillboard.cpp
@@ -67,7 +67,7 @@ osg::Drawable* createSquare(const osg::Vec3 corner,const 
osg::Vec3 width,const
 (*tcoords)[1].set(1.0f,0.0f);
 (*tcoords)[2].set(1.0f,1.0f);
 (*tcoords)[3].set(0.0f,1.0f);
-geom-setTexCoordArray(0,tcoords);
+geom-setTexCoordArray(3,tcoords);
 
 geom-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
 
@@ -76,7 +76,7 @@ osg::Drawable* createSquare(const osg::Vec3 corner,const 
osg::Vec3 width,const
 osg::StateSet* stateset = new osg::StateSet;
 osg::Texture2D* texture = new osg::Texture2D;
 texture-setImage(image);
-
stateset-setTextureAttributeAndModes(0,texture,osg::StateAttribute::ON);
+
stateset-setTextureAttributeAndModes(3,texture,osg::StateAttribute::ON);
 geom-setStateSet(stateset);
 }
 




I'm starting to think there's an OSG bug. I know that my graphics card is 
capable of handling at least 16 fixed function texture units, because it worked 
fine in my non-OSG based app. I will look more into this and report back.

Cheers,
Jannik

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





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

Re: [osg-users] How to use more than 4 texture units?

[Jannik Heller]

Oops, posted wrong code - that should have been 4 instead of 3, of course.


Code:

diff --git a/examples/osgbillboard/osgbillboard.cpp 
b/examples/osgbillboard/osgbillboard.cpp
index a6243e8..64f893c 100644
--- a/examples/osgbillboard/osgbillboard.cpp
+++ b/examples/osgbillboard/osgbillboard.cpp
@@ -67,7 +67,7 @@ osg::Drawable* createSquare(const osg::Vec3 corner,const 
osg::Vec3 width,const
 (*tcoords)[1].set(1.0f,0.0f);
 (*tcoords)[2].set(1.0f,1.0f);
 (*tcoords)[3].set(0.0f,1.0f);
-geom-setTexCoordArray(0,tcoords);
+geom-setTexCoordArray(4,tcoords);
 
 geom-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::QUADS,0,4));
 
@@ -76,7 +76,7 @@ osg::Drawable* createSquare(const osg::Vec3 corner,const 
osg::Vec3 width,const
 osg::StateSet* stateset = new osg::StateSet;
 osg::Texture2D* texture = new osg::Texture2D;
 texture-setImage(image);
-
stateset-setTextureAttributeAndModes(0,texture,osg::StateAttribute::ON);
+
stateset-setTextureAttributeAndModes(4,texture,osg::StateAttribute::ON);
 geom-setStateSet(stateset);
 }
 




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





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

Re: [osg-users] How to use more than 4 texture units?

[Jannik Heller]

Hi Farshid,


 Are you sure the non-OSG based app was using the fixed function pipeline?

Ah, that's most definitely it. Yes, I was using shaders before. I totally 
forgot there were separate limits for fixed-function and shader texture units.

Thanks for the help,
Jannik

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





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

Re: [osg-users] osgQt versioning problem

[Jannik Heller]

Hi,


 
 You just have to build OSG twice using each version of Qt in turn. OSG
 respects the DESIRED_QT_VERSION already.
 
 cmake -DDESIRED_QT_VERSION=5 - use Qt 5.x
 cmake -DDESIRED_QT_VERSION=4 - use the Qt 4.x series
 

Yes, but then you won't be able to install those two OSG versions at the same 
time.
Unless you renamed libraries or used a completely separate prefix for each OSG 
build, but there isn't an established pattern to do so, so what we'd end up 
with is each distribution inventing its own ways to cope with the versioning 
problem. That is what should be avoided at all cost.


 
 You can specify in the spec file (if you are building for
 RPM-based distro) or the manifest for .dpkg (for Debian/Ubuntu/...)
 which library version your application needs. Then the package will
 not build for the repository maintainer until the requirements are
 met.
 
 I don't see how - if you set up your package requirements properly,
 then there is no way the repository maintainer could build your
 package requiring one version of Qt and build OSG using another one.
 

Speaking for some popular distro's that I've seen, there is a way to request a 
version of the OSG, but no way to request a Qt version of osgQt. No one 
bothered to add separate versioning for it, probably because the OSG itself 
doesn't provide one either so doesn't set a precedent on how it should be done. 
See my earlier comment w.r.t each distribution being forced to invent their own 
solutions.

Yes, it can work, if you jump through some hoops and are careful in what you 
do. My point is: it *should* work out of the box. A framework is supposed to 
make the developer's job easier, not harder, after all.

In my experience with packaged repositories, whatever can go wrong, *will* go 
wrong eventually. Thus having proper safeguards in place can safe you a lot of 
time.


 1) Maintain two separate osgQt libraries, an osgQt4 and an osgQt5
 

That sounds good. It wouldn't have to be a separately maintained source tree, 
just building the same tree twice with different build parameters.


Cheers,
Jannik

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





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

Re: [osg-users] osgQt versioning problem

[Jannik Heller]

Hi Robert,

that's certainly an option, and it seems like the option that would place the 
least burden on developers. I like the idea.

Counting the lines of code in osgQt we have just under 2000 lines in 
implementation files, having that much code in headers shouldn't be too much of 
a problem.


 
 I don't know how feasible it is, it'd require us to automatically select 
 between Qt4 and Qt4 based in someway.  Perhaps an osgQT/QT4 and osgQT/QT5 
 headers could include all the appropriate parts required, and then have 3rd 
 party apps include which one they want, and have these set defines to select 
 the different paths.
 

Not even that is necessary, I think. The osgQt headers already have #if 
QT_VERSION_CHECK(...) macros to select the appropriate code. Users would be 
able to #include  osgQt/...  and automatically get the correct code for the 
Qt version that their application is using.

It's a bit more work though to move that much code around, so for now I'm 
submitting the osgQt/Version fix. We can undo it later if the better fix comes 
around.

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





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

Re: [osg-users] osgQt versioning problem

[Jannik Heller]

On second thought, I'm not sure how this solution would interact with the MOC 
(QT meta object compiler). osgQt::QGraphicsViewAdapter is a Q_OBJECT, meaning 
the MOC needs to run on it and produce an object file. If we move all code to 
the headers, then it would fall on the users responsibility to make sure they 
run the MOC on osg-headers. That's not too optimal.

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





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

Re: [osg-users] osgQt versioning problem

[Jannik Heller]

Hi,

as a first step to rectify the problem I have introduced a version check within 
osgQt (include/osgQt/Version) to store the Qt version that osgQt has been 
compiled against. If there is a version mismatch, the build process will abort 
with an #error rather than crashing at runtime later on. Will post to 
osg-submissions in a second.

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





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

[osg-users] osgQt versioning problem

[Jannik Heller]

Hi,

Recently I have had my application tested on a wide range of linux 
distributions. Some users are running into a problem with Qt version mismatch. 
My application gets built with Qt4, but osgQt might be built with Qt4 or Qt5. 
If you load Qt4 and Qt5 libraries in the same executable, a crash ensues.

This forces users to rebuild the OSG with a particular version of Qt, just to 
run a certain application, which is bad. 

For a proper solution, the OSG could provide libosgQt4 and libosgQt5 libraries, 
along with find scripts that allow the application to request a particular 
osgQt version to be used. What do you think about the idea?

Thank you!

Cheers,
Jannik

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





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

Re: [osg-users] osgQt versioning problem

[Jannik Heller]

Hi Jan,


 The only way you could have problems is if you rely on the OSG 
 libraries shipped by the distro, where you don't have control over how 
 it was compiled. 


That is precisely what's going to happen. My application is likely to become 
available in distro repositories (FWIW, an older version of my application that 
isn't using the OSG *is* already in distro repositories). Packaging guidelines 
typically require a package to use the established library stack. A package 
isn't likely to get accepted if it ships its own forks of already packaged 
software. That would be a maintenance and security nightmare.


 
 I don't think that is necessary - you need to ensure in your
 application that it is built against the correct version of Qt which
 is the *same as the version you use for osgQt*.
 

Sounds easy in principle, but will cause a waterfall of problems for package 
repositories.

- Not all application developers are willing or able to upgrade to Qt5 yet.
- *if* there is a mismatch, we just get a crash, instead of the mismatch being 
detected at the build system stage. The packager or tester is left to dig into 
the crash to find out what's wrong. There is no way for the application to 
detect what version of Qt the osgQt was built with, so the application can't 
provide a sensible error message either. Ultimately, the developer will be left 
to deal with lots of support requests by frustrated users.
- If one package requires osgQt5, but a different one requires osgQt4, we get a 
conflict. The user wouldn't be able to install those two packages at the same 
time. 

Yes, these aren't problems if you ship your application with static libs, but 
not everyone can or wants to ship software in this way.


 In addition, if you are trying to distribute a binary-only package

I don't. I just distribute source-code and let others worry about the rest ;)

My suggestion is:

- Provide separate libosgQt4/5 libraries.
- Provide a libosgQt library that points to the default, either 4 or 5, for 
backwards compatibility.
- Add an OSGQT_DESIRED_QT_VERSION switch for the FindosgQt.cmake script, 
allowing applications to opt for a specific version.

For now, I'm going with the workaround of upgrading my application to Qt5. 

Still, I'm convinced there's a bigger issue here. I'd be curious what Robert's 
thoughts are.

Thanks,
Jannik[/quote]

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





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

Re: [osg-users] Possible improvement for CullThreadPerCameraDrawThreadPerContext threading model

[Jannik Heller]

Hi again,

I just noticed that what I need to achieve is actually quite simple: the 
dynamicObjectRenderingCompletedCallback needs to be called from the culling 
thread, rather than the drawing thread. This would ensure the next frame can 
commence when the culling phase has ended, rather than commencing when the last 
camera starts drawing.

Then I read the OSG code again, and noticed that precisely the same idea *is* 
already in the OSG, but it's commented out. See: 
https://github.com/openscenegraph/osg/blob/master/src/osgViewer/Renderer.cpp#L641

I don't know why it's commented out, the svn history doesn't give any 
indication.

I will try enabling that code and if it works, post to osg-submissions.

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





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

Re: [osg-users] Ready to tag OpenSceneGraph-3.3.8 dev release, please test

[Jannik Heller]

Here's the profiling data...

apply this change to osgclip.cpp:


Code:
diff --git a/examples/osgclip/osgclip.cpp b/examples/osgclip/osgclip.cpp
index 3b74bd2..b202e35 100644
--- a/examples/osgclip/osgclip.cpp
+++ b/examples/osgclip/osgclip.cpp
@@ -28,6 +28,8 @@
 #include osg/LineStipple
 #include osg/AnimationPath
 
+#include osgViewer/ViewerEventHandlers
+
 #include osgDB/Registry
 #include osgDB/ReadFile
 
@@ -136,8 +138,13 @@ int main( int argc, char **argv )
 // run optimization over the scene graph
 osgUtil::Optimizer optimzer;
 optimzer.optimize(rootnode);
+
+for (int i=0; i1; ++i)
+rootnode-addUpdateCallback(new osg::NodeCallback);
 
 osgViewer::Viewer viewer;
+
+viewer.addEventHandler(new osgViewer::StatsHandler);
  
 // set the scene to render
 viewer.setSceneData(rootnode);




Release build, Ubuntu 14.04 64 bit, g++ 4.8.2

In 3.2, the Update phase for this change takes 0.15ms.
In svn/trunk, it's 1 ms.

That's a factor 6 performance regression for the base cost of node callbacks.

You might think that 1 callbacks is a lot. But callbacks are used quite 
liberally all throughout the OSG, and it's not too difficult to reach that 
number in a big scene with lots of skeletal animations, texture animations, 
etc. The flexibility of callbacks available is IMO one of the biggest strengths 
of the OSG, so it's in our best interest to make them run fast.

What was the rationale for unifying all callbacks under a common base class?

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





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

Re: [osg-users] Ready to tag OpenSceneGraph-3.3.8 dev release, please test

[Jannik Heller]

Hi Robert,

I tried my application using the latest trunk and didn't notice any functional 
regressions.

However, I did notice a performance decrease in the Update phase of about 20%, 
compared to OSG 3.2.0. This had me a bit concerned, so I digged through the 
changes and found commit 
https://github.com/openscenegraph/osg/commit/e967420323bb6e500425144cb305cf8060c1c515
 .
Since that commit, we now get *four* dynamic_cast's per frame and NodeCallback, 
which I suspect is causing the slowdown. Two dynamic_cast's are in 
NodeCallback::run, then another two in NodeCallback::traverse.

Changing to the non-deprecated Callback instead of NodeCallback gives a slight 
improvement with now just two dynamic_cast's in Callback::traverse, but still 
isn't optimal.

Ideally, the application should be able to decide on the level of safety vs. 
level of performance it needs. If a Callback is only intended to be used on 
Nodes, there is little point in dynamic_casting to Node every frame.

I think I can workaround the casts by using a custom class derived from 
osg::Callback as the base class for all my node callbacks. Still, it's quite a 
peculiar situation that does affect all users of the OSG.

I guess my question comes down to, are there any plans on optimizing the 
Callback code before a final 3.4 release? If you aren't convinced, I can throw 
together a repro case and some profiling data, but I think the impact of 4 
dynamic_cast's per frame and NodeCallback should be obvious.

Cheers,
Jannik

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





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

[osg-users] Possible improvement for CullThreadPerCameraDrawThreadPerContext threading model

[Jannik Heller]

Hi,

I was playing around with threading models today and found something odd.

For the sake of experiment, I used a osgViewer with a master camera, a slave 
camera using the same graphics context as the master camera, and the 
CullThreadPerCameraDrawThreadPerContext threading model.

I found that the osgViewer does not commence the next frame until the last 
camera's draw dispatch has started. That is strange. My scene has 0 dynamic 
objects in it, so logically speaking the next frame could commence as soon as 
all the cull threads are done and the first camera's draw dispatch starts.

I attached some pictures to illustrate what I mean. The first picture is what I 
am seeing, the second picture is what I would have expected to see.

I fired up the debugger and found OSG was blocking in the _endDynamicDrawBlock. 
The block gets released in Renderer::draw, but each camera needs to get there 
first, i.e. start drawing.

The idea for a fix would be simple: if there are no dynamic objects in the 
scene, we release the block in GraphicsContext::runOperations, for each camera, 
before the cameras start drawing.

i.e., we move this piece of code from Renderer::draw to 
GraphicsContext::runOperations:

state-setDynamicObjectCount(sceneView-getDynamicObjectCount());

if (sceneView-getDynamicObjectCount()==0  
state-getDynamicObjectRenderingCompletedCallback())
{
// OSG_NOTICECompleted in cullstd::endl;

state-getDynamicObjectRenderingCompletedCallback()-completed(state);
}

In practice it may not be simple, for starters the GraphicsContext would need 
access to the SceneView, which is a no go as the core osg can't depend on 
osgViewer. Some refactoring would be needed to work around this issue, so 
before I dive in head first, I want to ask if anyone has an alternative 
suggestion, or done this kind of optimization before.

Thanks,
Jannik

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



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

[osg-users] Multithreading osgShadow

[Jannik Heller]

Hi,

I'm running the osgshadow example and noticed that no extra cameras (beside the 
main one) are to be seen in the stats handler.

Why is that?

I'd assume the light's view point is essentially a Camera, so why not handle it 
as one? Assigning a separate cull thread to each shadow map (with the 
CullThreadPerContext thread model) could increase performance by a lot, I 
imagine. Even more so with split shadow techniques, where each split needs 
another cull pass.

Has anyone tried multithreading osgShadow in this way? Am I overlooking 
something obvious?

Thanks,
Jannik

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





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

Re: [osg-users] Forcing a scene to rebind textures

[Jannik Heller]

Hi filnet,


 
 Code looks like this 
 
 But I still get the invalid enumerant error followed by a crash.
 


there is one missing step in your code - you said you have a detached subgraph. 
The OSG does not hold any pointers to detached subgraphs, so it can't do the 
cleanup on its own. Only your application knows where those subgraphs are 
stored.

So instead of


Code:

view-releaseGLObjects(); 



You need to

Code:

for all detached subgraphs:
node-releaseGLObjects();




View::releaseGLObjects can only release objects that are currently attached to 
the root scene graph.

Cheers,
Jannik[/quote][/code]

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





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

[osg-users] Crash when frequently recreating VBOs

[Jannik Heller]

Hi,

I get random crashes when recreating VBOs in my app. I managed to isolate the 
crash into a small reproduction case.

Basically I have a cull thread filling in draw commands with VBOs, and the draw 
thread executes them. Recreating the VBOs is what makes the crash appear.


Code:

#include osg/Geode

#include osg/Drawable
#include osg/Array

#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers

class VertexBuffer
{
public:
VertexBuffer()
{
create();
}

osg::ref_ptrosg::VertexBufferObject mVBO;
osg::ref_ptrosg::UByteArray mArray;

void destroy()
{
mVBO = NULL;
mArray = NULL;
}

void create()
{
mVBO = new osg::VertexBufferObject;
mVBO-setDataVariance(osg::Object::DYNAMIC);
mVBO-setUsage(GL_DYNAMIC_DRAW);
mArray = new osg::UByteArray(6 + std::rand()/float(RAND_MAX) * 1000);
mVBO-setArray(0, mArray);
}
};

class MyDrawable : public osg::Drawable
{
public:
MyDrawable()
: mWriteTo(0)
, mReadFrom(0)
{
osg::ref_ptrFillBatchCallback callback = new FillBatchCallback;
callback-setDrawable(this);
setCullCallback(callback);

setDataVariance(osg::Object::STATIC);

setSupportsDisplayList(false);

for (int i=0; i1000; ++i)
{
mVertexBuffers.push_back(VertexBuffer());
}
}

MyDrawable(const MyDrawable copy, const osg::CopyOp copyop)
: mWriteTo(copy.mWriteTo)
, mReadFrom(copy.mReadFrom)
{

}

META_Object(example, MyDrawable)

class FillBatchCallback : public osg::Drawable::CullCallback
{
public:

/** do customized cull code, return true if drawable should be culled.*/
virtual bool cull(osg::NodeVisitor* nv, osg::Drawable* drawable, 
osg::RenderInfo* renderInfo) const
{
mDrawable-collectBatches();

return false;
}

void setDrawable(MyDrawable* drawable)
{
mDrawable = drawable;
}

private:

MyDrawable* mDrawable;
};

void collectBatches()
{
clear();

for (std::vectorVertexBuffer::iterator it = mVertexBuffers.begin(); 
it != mVertexBuffers.end(); ++it)
{
VertexBuffer vertexbuffer = *it;

if (std::rand()/float(RAND_MAX)  0.9)
{
vertexbuffer.destroy();
vertexbuffer.create();
}

addBatch(vertexbuffer);
}
}

virtual void drawImplementation(osg::RenderInfo renderInfo) const
{
mReadFrom = (mReadFrom+1)%2;

osg::State* state = renderInfo.getState();

const std::vectorVertexBuffer vec = mBatchVector[mReadFrom];

for (std::vectorVertexBuffer::const_iterator it = vec.begin(); it != 
vec.end(); ++it)
{
const VertexBuffer b = *it;
osg::GLBufferObject* obj = state-isVertexBufferObjectSupported() ? 
b.mVBO-getOrCreateGLBufferObject(state-getContextID()) : 0;
if (obj)
{
state-bindVertexBufferObject(obj);
}
}

state-unbindVertexBufferObject();
}

private:
std::vectorVertexBuffer mVertexBuffers;


std::vectorVertexBuffer mBatchVector[2];
int mWriteTo;
mutable int mReadFrom;

public:

void addBatch(const VertexBuffer batch)
{
mBatchVector[mWriteTo].push_back(batch);
}

void clear()
{
mWriteTo = (mWriteTo+1)%2;
mBatchVector[mWriteTo].clear();
}
};

int main( int argc, char **argv )
{
osg::ref_ptrosg::Geode rootnode = new osg::Geode;
rootnode-addDrawable(new MyDrawable);

osgViewer::Viewer viewer;

viewer.addEventHandler(new osgViewer::StatsHandler);
 
// set the scene to render
viewer.setSceneData(rootnode);

return viewer.run();
}




Leaving that example running for one or two minutes, I get the message

Warning: deleting still referenced object 0x7f846c3d7ac0 of type 
'PN3osg10ReferencedE'
 the final reference count was 1, memory corruption possible.

and then shortly after it crashes, presumably accessing a deleted 
GLBufferObject:


Code:


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x71650700 (LWP 4610)]
0x779953a0 in osg::GLBufferObject::compileBuffer() () from 
/home/scrawl/Downloads/OpenSceneGraph-3.2.0/build/lib/libosg.so.100
(gdb) bt
#0  0x779953a0 in osg::GLBufferObject::compileBuffer() () from 
/home/scrawl/Downloads/OpenSceneGraph-3.2.0/build/lib/libosg.so.100
#1  0x00406649 in MyDrawable::drawImplementation(osg::RenderInfo) 
const ()
#2  0x7561cb27 in osgUtil::RenderLeaf::render(osg::RenderInfo, 
osgUtil::RenderLeaf*) () from 
/home/scrawl/Downloads/OpenSceneGraph-3.2.0/build/lib/libosgUtil.so.100
#3  0x756173c0 in 
osgUtil::RenderBin::drawImplementation(osg::RenderInfo, osgUtil::RenderLeaf*) 
() from 

Re: [osg-users] Crash when frequently recreating VBOs

[Jannik Heller]

I solved it, see osg-submissions: 
http://forum.openscenegraph.org/viewtopic.php?p=63652#63652

Cheers, Jannik

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





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

Re: [osg-users] Best practice for dynamic StateSets Geometry

[Jannik Heller]

 I am surprised you saw a boost with disable double precision.  What specific 
 element you do you change w.r.t double precision? 

I enabled OSG_USE_FLOAT_MATRIX and OSG_USE_FLOAT_PLANE and observed a 10% 
framerate improvement.

Might be related to particle systems, which I forgot to mention I'm also using.


 
 For the change to double precision making a difference it's a hint that you 
 have a scene that is poorly balanced.  
 

W.r.t. balancing, for exterior environments I have objects organized in a grid 
of 3x3 cells. A quad tree might yield better results. Main problem though is 
that I am restricted to runtime optimizations - the scene itself comes from a 
third party source that I am not at liberty to modify or distribute. The scenes 
were created for a game in 2002, so not surprising they're CPU bound on modern 
hardware now.

I plan on trying the osgUtil::Optimizer at some point though I'm afraid I can 
only run it on individual models and not the whole scene - as the scene is 
tightly connected to game logics, scripting, physics, etc.


 
 Are you using CPU based animation?  Could you shift it onto the GPU? 
 

Yes and yes - I am using software skinning at the moment just because it works. 
I will try and move to hardware skinning later, but for now I am focused on 
porting the rest of my rendering code to OSG before optimizing more.

Thanks,
Jannik[/quote]

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





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

Re: [osg-users] Best practice for dynamic StateSets Geometry

[Jannik Heller]

Hi Robert,

Thanks for the hints - I am using a release build, and I already disabled 
double precision from cmake which gave me another nice boost.

In the stats handler I am seeing roughly the same amount of time spent in the 
cull, draw and GPU threads. After adding the double buffering the 3 threads all 
run in parallel so performance is decent now.
I know that my app is CPU bound but there's not much I can do about it.
Some of the time in the cull thread is spent updating vertex animations, and 
some time for organizing light lists. I have scenes with a lot more than 8 
lights, so I have to check what lights are closest to a given sub-graph before 
rendering it. This system was really slow to begin with but I already optimized 
it a lot. Non the less setting the lights still has a noticable overhead.
Next problem is the sheer number of objects - often thousands per scene. I 
tried batching before but the problem is the scenes I am working with are 
scripted, so objects can be moved or removed at any time, also, batching 
objects would interfere with the light lists - i.e. with too many objects 
sharing a large batch I can not set fine grained light lists on them.
I'm looking forward to switching the light system to deferred shading in the 
future - I'm sure then it will be GPU bound. I still need a forward rendering 
fallback in place though. 

Cheers,
Jannik

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





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

[osg-users] Best practice for dynamic StateSets Geometry

[Jannik Heller]

Hi OSG friends,

A common challenge for OSG users are the implications of the viewer threading 
model - by default the viewer.frame() will return before the draw dispatch is 
complete, meaning users (and the OSG) can start preparing the next frame before 
the current frame has completed. However, if you attempt to change a StateSet 
or Drawable in the frame update, you run the risk of modifying data that the 
OSG is still working with in a background thread, resulting in crashes.
Often times you will see code dealing with this by setting the DataVariance of 
the object to DYNAMIC. Unfortunately as result the draw dispatch has to 
complete before the frame() returns, for me this dropped the frame rate in 
half. 
Recently I developed a more efficient solution for dealing with this and would 
like to hear your thoughts.
The idea is similar to double buffering with the framebuffer - you create two 
copies of the data on start, one copy is write only, another copy is read only, 
and when the frame completes the roles are swapped. You can implement this idea 
for both Drawables and StateSets:
- Dynamic Drawables (RigGeometry, MorphGeometry, etc): create a deep copy of 
the Drawable, decorate both Drawables with a FrameSwitch node. A FrameSwitch 
node is a variant of Group that only traverses even or non-even children based 
on the current FrameStamp. Code 
(https://github.com/OpenMW/openmw/blob/f7da9796692e14c79632cb85fa75a90b082cd863/components/nifosg/nifloader.cpp#L179)
 
- Dynamic StateSets: Create two copies of the StateSet on start, then every 
frame in a NodeCallback swap the roles of these StateSets, apply changes to the 
first StateSet, then set the currently active StateSet on the Node. Code 
(https://github.com/scrawl/openmw/blob/osg/components/sceneutil/statesetupdater.cpp#L8)

There are some downsides to this approach (mostly that for data that is just 
rarely changing, you have to apply every change twice), but other than that it 
works beautifully and now I've got 2x the framerate again.

I'm curious how the OSG veterans are dealing with this. Anything I've missed?

Cheers
Jannik

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





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

Re: [osg-users] Culling with custom clip planes

[Jannik Heller]

I have implemented the CullCallback way and it seems to work great. Thanks for 
the tip!

Cheers
Jannik

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





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

Re: [osg-users] [osgPlugins] ffmpeg plugin halting during playback of some videos

[Jannik Heller]

Thanks for sharing your changes Trystan! Always good to have more choices with 
regards to video plugins. FWIW, I have another very stable FFmpeg plugin here: 
https://github.com/scrawl/ogre-ffmpeg-videoplayer 
It's currently using Ogre for rendering rather than OSG, but should be really 
easy to port. I will be porting it to OSG when I'm done with porting the rest 
of my engine.

Cheers,
Jannik

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





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

[osg-users] Culling with custom clip planes

[Jannik Heller]

Hi,

In the osgreflect example a ClipNode is used to remove unwanted objects 
behind the reflection. Is there a way that in addition to clipping these 
objects, we could also cull them? Objects that are entirely behind the 
reflection obviously do not need to be rendered. From what I could tell in the 
source code OSG performs no such culling. Is there an easy way to achieve that? 

Thank you!

Cheers,
Jannik

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





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

Re: [osg-users] testing for multisampling capability

[Jannik Heller]

Hi Robert,


 OpenGL doesn't provide any capability query system without first opening a 
 graphics context... which means the OSG can't provide anything similar.

Are you sure about this? The Ogre3D engine implements such a query feature for 
multisampling levels, not requiring a graphics window to be created. It's using 
glXGetFBConfigAttrib, you can check the source code here: 
https://bitbucket.org/sinbad/ogre/src/aa7a1ea160eddccaa362e51525a37fb53f1ff13f/RenderSystems/GL/src/GLX/OgreGLXGLSupport.cpp?at=default#cl-122

I have no idea how such a solution would fit in with the design of OSG, but it 
might be worth a try.

Cheers
Jannik[/quote]

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





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

Re: [osg-users] [osgOcean] Compilation under linux

[Jannik Heller]

Looks like a missing include. Try adding an #include fstream to the top of 
that file.

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





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