Re: [osg-users] Camera render order and Threading models

[Riccardo Corsi]

Hi Robert,

I've tried to reproduce the issue with a minimal example, without success
so far, even though the essential bits should be the same.
I'm also thinking it might have something to do with the data variance of
the affected geometries, I'll double check.
If I find something I'll report back here,
Thanks,
Riccardo



*Riccardo Corsi*  co-founder, software engineering
*Kairos3D srl*  Via Agostino da Montefeltro 2, 10134 Torino Italy
*T* +390113157111  *M* +393288522785

This e-mail is confidential and intended only for the use of the above
named addressee. If you have received this e-mail in error, please delete
it immediately and notify us by e-mail or telephone.


On Thu, Jan 7, 2021 at 6:45 PM Robert Osfield 
wrote:

> Hi Ricard,
>
> Both the RTT Camera and the main Camera should both be traversed in the
> cull traversal within the same frame and accumulated modelview matrices
> cached in the rendering backend to sent to the GPU as part of the draw
> traversal together.  Ordinarily this system should prevent problems like
> your describe as the rendering backend is double buffered so that the cull
> writes to the currently recording frames rendering backend, while the draw
> traverses the previous rendering backend structures.
>
> The behaviour you describe makes it seem like some state is being modified
> across the frames, I don't have your app or data so can't say what this
> might be.  The best I can suggest is to investigate what state seems to be
> changed inappropriately.  It might be that you need to double buffer the
> state that is being updated whilst it's being used for rendering.
>
> Robert
>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenSceneGraph Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWM4Cn4KooZoHxnv2nncmpHtrftT1aNEjGNnwows06OGA%40mail.gmail.com
> <https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BWM4Cn4KooZoHxnv2nncmpHtrftT1aNEjGNnwows06OGA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAHhSftgzALxeG69w%2B1jJXuZQRxyt6NE4fBkAae%3DFtgVHdgMFgg%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Camera render order and Threading models

[Riccardo Corsi]

Hi all,

I'm facing an issue when using multiple cameras and different threading
models.
In my scene I have a slave camera which renders to a texture (using FBO +
texture attachment) in PRE_RENDER order; the texture is then attached to a
geometry which in turns is rendered by the main viewer camera.
I have verified that both cameras' view matrices are updated consistently
during the same frame update traversal (as they are linked one another).

When I run this setup with SingleThreaded model, everything works as
expected.

If I run it with DrawThreadPerContext (default on Windows), there is a
one-frame delay of the RTT camera result, meaning that during frame N the
main camera sees the render result of frame N-1 in the FBO camera texture
attachment.

I don't think this is an expected behavior.
Is there a way to fix the issue without switching to SingleThreaded mode?

Thank you,
Riccardo

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAHhSftjmptB8SwzDj32QE4Ex1ZoxXahKxzREcCpWw7O5MO6C5A%40mail.gmail.com.
___
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 embed OSG into imgui as a widget ?

[Riccardo Corsi]

Hi Jishen,

if by ImGui you refer to the Dear Imgui library
, what you're after is pretty odd, as
ImGui is specifically designed to be embedded in other applications with
their own rendering backend.
This is why the library does create a window handle, nor is able to render
itself, but just provides you vertex buffers that you have to use in your
rendering backend.



On Sun, Sep 29, 2019 at 12:32 PM Jishen Li  wrote:

> Hi,
>
> I found people tried to embed ImGui into OSG, not vice verse. I am using
> OSG to render a scene in a separate thread. Since my main GUI is built by
> using ImGui, I want to embed OSG as a widget-like sub-window inside imgui.
>
> How can I do it ?
>
> Thanks!
>
> ...
>
> Thank you!
>
> Cheers,
> Jishen
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76757#76757
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenGL viewport error (with Oculus)

[Riccardo Corsi]

Hi Robert,

yes, it's single context, single thread, all GL calls are done by osg and
osgOculusViewer in the various camera draw callbacks.

On Fri, Oct 19, 2018 at 4:55 PM Robert Osfield 
wrote:

> Hi Riccardo,
>
> On Fri, 19 Oct 2018 at 15:38, Riccardo Corsi 
> wrote:
>
>> I've tracked the issue down to the fact that it is necessary to call
>> viewer.setReleaseContextAtEndOfFrameHint(false);
>> for the Oculus to work properly.
>>
>
> Is it running single context, single threading and then using GL calls in
> the main thread?
>
> Robert.
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenGL viewport error (with Oculus)

[Riccardo Corsi]

I've tracked the issue down to the fact that it is necessary to call
viewer.setReleaseContextAtEndOfFrameHint(false);
for the Oculus to work properly.

Thanks,
Riccardo



On Wed, Oct 17, 2018 at 2:33 PM Robert Osfield 
wrote:

> On Wed, 17 Oct 2018 at 12:17, Riccardo Corsi 
> wrote:
>
>> the error I've reported is what I get with the env var already ON.
>> Unfortunately it doesn't add any more details.
>>
>
> Try adding GL checks around any of the Oculus related code.
>
> Robert.
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenGL viewport error (with Oculus)

[Riccardo Corsi]

Hi Robert,

the error I've reported is what I get with the env var already ON.
Unfortunately it doesn't add any more details.
Riccardo

On Wed, Oct 17, 2018 at 12:56 PM Robert Osfield 
wrote:

> Hi Riccardo,
>
> The OSG doesn't do fine grained GL error checking by default so when it
> does check for a GL error this error may have occurred many GL operations
> before, so while the error may have been reported just after a viewport is
> set it could well be prior operations that are the cause.
>
> You can enable finer grained GL error checking by setting the
> OSG_GL_ERROR_CHECKING env var to ON i.e.
>
> set OSG_GL_ERROR_CHECKING=ON
>
> This will hopefully give you a more precise location of the error.
>
> Robert.
>
> On Wed, 17 Oct 2018 at 11:43, Riccardo Corsi 
> wrote:
>
>> Hi all,
>>
>> when using my application with the Oculus I get the following GL error at
>> every frame:
>> *Warning: detected OpenGL error 'invalid operation' after applying
>> attribute Viewport *
>>
>> This error is coming from the call RenderStage::drawImplementation()
>> <https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgUtil/RenderStage.cpp#L1333>
>>  but
>> the _viewport is valid. I'm not so familiar with the backend to understand
>> where this error might come from.
>> Any hint to debug this?
>>
>> Note: I'm using the Oculus through osgOculusViewer
>> <https://github.com/bjornblissing/osgoculusviewer>.
>> The sample Oculus viewer works fine without GL errors.
>> My app is setup the same way, I cannot spot any sensible difference.
>>
>> I'm using win10, osg 3.6.3
>>
>> Thanks,
>> Riccardo
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenGL viewport error (with Oculus)

[Riccardo Corsi]

Hi all,

when using my application with the Oculus I get the following GL error at
every frame:
*Warning: detected OpenGL error 'invalid operation' after applying
attribute Viewport *

This error is coming from the call RenderStage::drawImplementation()

but
the _viewport is valid. I'm not so familiar with the backend to understand
where this error might come from.
Any hint to debug this?

Note: I'm using the Oculus through osgOculusViewer
.
The sample Oculus viewer works fine without GL errors.
My app is setup the same way, I cannot spot any sensible difference.

I'm using win10, osg 3.6.3

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

Re: [osg-users] GL profiles issues on Windows

[Riccardo Corsi]

Sorry Robert,

at the moment I can only test on Win and Mac, but the second is not a
candidate as it requires GL Core profile.

On Thu, Sep 6, 2018 at 6:05 PM Robert Osfield 
wrote:

> Hi Riccardo,
>
> On Thu, 6 Sep 2018 at 16:43, Riccardo Corsi 
> wrote:
> > I tried adding the setShaderHint() line but things get a bit worse -
> alpha issue still there and not text at all, see attached screenshot.
> >
> > I get display errors also in my other HUD contents where I actually use
> gl_ builtins so your guess might be right,
> > but unfortunately adding the ShaderHint does not fix it.
>
> Do you know if this combination of OSG usage fails on other platforms?
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] GL profiles issues on Windows

[Riccardo Corsi]

Hi Robert,

I tried adding the setShaderHint() line but things get a bit worse - alpha
issue still there and not text at all, see attached screenshot.

I get display errors also in my other HUD contents where I actually use gl_
builtins so your guess might be right,
but unfortunately adding the ShaderHint does not fix it.

Riccardo

On Thu, Sep 6, 2018 at 12:42 PM Robert Osfield 
wrote:

> Hi Ricardo,
>
> On Thu, 6 Sep 2018 at 10:49, Riccardo Corsi 
> wrote:
> > good guess! I've enabled the aliasing and my shaders works now with osg
> default build!
> > With this configuration there is still a side effect though: something
> is wrong with alpha settings for HUD cameras.
> > See attached screenshot that shows the issue: it's a modified
> osgsimplegl3 example with stats handler enabled, but I have alpha issues
> with other HUDs as well.
> > I've counter checked in my examples that the 2 aliasing/uniform calls
> are the culprit: if I comment them out the shaders don't work anymore but
> the stats are displayed correctly.
>
> I'm busy with other work right now so can't look at the modified code
> right away.
>
> My best guess right now is that osgText and the StatsHandler are using
> GL2 shader paths that assume gl_ builtins are available, but with the
> aliasing enabled perhaps this is causing problem.  Could you set the
> DIsplaySettings ShaderHint to GL3 to see if that helps i.e.
>
> To the main before the scene graph setup add:
>
>
>  
> osg::DisplaySettings::instance()->setShaderHint(osg::DisplaySettings::SHADER_GL3);
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] GL profiles issues on Windows

[Riccardo Corsi]

Hi all,

I've rebuilt osg as suggested by Robert and still getting no GL errors but
nothing shows up.
To sum it up, running a test app which only uses libA (which addresses only
GL3 functions and shaders version 150)
under windows:
- if I link my code to OSG built with  GLCORE profile everything works
- if I link the same code to OSG build with defaults, nothing shows up

As further check, I tried the same with osgsimplegl3 example which works in
both OSG builds.
Any idea on what could be the culprit of my code not working in the same
way?

@Werner you're correct, I'd like to use both libs in the same app on
Windows,
I think this should be possible with Compatibility profile.

Thank you


On Wed, Sep 5, 2018 at 12:17 PM Werner Modenbach 
wrote:

> Hi Robert,
>
> I thin k Riccardo wants to use both libs (libA glcore, linB non glcore)
> in the same app on Windows.
> In my understanding this is not possible at all.
>
> - Werner -
>
> Am 05.09.2018 um 11:36 schrieb Robert Osfield:
> > Hi Riccardo,
> >
> > On Wed, 5 Sep 2018 at 10:23, Riccardo Corsi 
> wrote:
> >> Now what I'd like to do (on Win only) is to use libA and libB together.
> >> To do so I expected it was enough to add the OSG_GL3_AVAILABLE flag to
> build OSG and to request a Compatibility GL context.
> >> What happens instead is that I don't see anything of what libA is
> supposed to render, even though I don't get any GL error on the console.
> > I you are just building the OSG with defaults, so will provide a
> > compatibility profile. then the OSG at runtime will check for all the
> > GL3/GL4 features and allow you to use this, you don't need to
> > explicitly enable them via OSG_GL3_AVAILABLE.
> >
> > For compatibility with OSX then you'll need to use the CMake option of
> > OPENGL_PROFILE=GLCORE.
> >
> > If you create an application that works with GLCORE then this same
> > application will build and run just fine on the OSG built with
> > defaults.
> >
> > Robert.
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] GL profiles issues on Windows

[Riccardo Corsi]

Hi Robert,

thanks for your reply but I probably didn't explain clearly my issue.

Say I have:
- libA (using only GL Core features, because I want to use this lib also on
Mac)
- libB (using also GL 2.x features, target Win only)

If I compile and use only libA against osg built with GLCORE profile,
everything works both on Win and Mac.

Now what I'd like to do (on Win only) is to use libA and libB together.
To do so I expected it was enough to add the OSG_GL3_AVAILABLE flag to
build OSG and to request a Compatibility GL context.
What happens instead is that I don't see anything of what libA is supposed
to render, even though I don't get any GL error on the console.
Riccardo


On Wed, Sep 5, 2018 at 9:27 AM Robert Osfield 
wrote:

> Hi Riccardo,
>
> The OSG_GL*_AVAILABLE flags are the lower level switches, if you want
> a core profile with none of the fixed funcion pipeline then the
> OSG_GL1 + GL2_AVAILABLE will need to be OFF.  There are other controls
> as well.
>
> The best way to get everything set correct is to run CMake with
> OSG_GL_PROFILE set to GLCORE, this high level mechanisn will set all
> the low level stuff you need.
>
> Cheers,
> Robert.
> On Tue, 4 Sep 2018 at 21:44, Riccardo Corsi 
> wrote:
> >
> > Hi all,
> >
> > I have some osg-based libraries that are addressing only GL3+ Core
> profile functionalities, as I need them to work on Mac.
> >
> > Now on Windows, I expected them to work just by compiling osg with the
> OSG_GL3_AVAILABLE flag.
> > What happens instead is:
> > - if I build osg with GL core profile (no GL 1 and 2, no FFP enabled,
> ecc...) everything works
> > - if I build osg just adding the OSG_GL3_AVAILABLE flag and launch the
> application by specifying a GL 3.2 Compatibility profile, I get no errors
> but nothing shows up
> >
> > Are my expectations correct? Should I check some more compilation /
> runtime settings to have it working?
> >
> > My setup is:
> > osg 3.6.2
> > win 10
> > nvidia GTX card
> >
> > Thank you,
> > Riccardo
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] GL profiles issues on Windows

[Riccardo Corsi]

Hi all,

I have some osg-based libraries that are addressing only GL3+ Core profile
functionalities, as I need them to work on Mac.

Now on Windows, I expected them to work just by compiling osg with the
OSG_GL3_AVAILABLE flag.
What happens instead is:
- if I build osg with GL core profile (no GL 1 and 2, no FFP enabled,
ecc...) everything works
- if I build osg just adding the OSG_GL3_AVAILABLE flag and launch the
application by specifying a GL 3.2 Compatibility profile, I get no errors
but nothing shows up

Are my expectations correct? Should I check some more compilation / runtime
settings to have it working?

My setup is:
osg 3.6.2
win 10
nvidia GTX card

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

Re: [osg-users] Bug in osgDB::findFileInDirectory

[Riccardo Corsi]

​Thanks Robert​

*Riccardo Corsi*  sw engineering & co-founder
*Kairos3D srl*  Via Agostino da Montefeltro 2, 10134 Torino Italy
*T* +390113157111  *M* +393288522785
*Check out our ground-breaking 3D CAD-to-VR toolchain: www.kairos3d.it
<http://www.kairos3d.it>*

On Wed, Mar 28, 2018 at 12:50 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Ricardo,
>
> On 27 March 2018 at 19:42, Robert Osfield <robert.osfi...@gmail.com>
> wrote:
> > ./test --dir ~/OpenSceneGraph/include/osg/ --file version
> > Result with findFileInDirectory(): 0
> > Result with fileExists(): 0
> > concatenated=/home/robert/OpenSceneGraph/include/osg/version
> >
> > Which confirms your suggestion that the trailing slash isn't handled
> > by findFileInDirectory().
>
> I have checked in a catch for users passing in directories with a
> trailing / or \.  This fix is checked into OSG master and the 3.6
> branch.
>
> Robert
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in osgDB::findFileInDirectory

[Riccardo Corsi]

Hi Robert,

thanks for the tests.
You're right I was not concatenating the paths correctly,
but the concatenation was ok in the default case,
as the directory path contains a final slash.

Now I've realised THAT is the case when the issue comes up:
if you use a directory path which has the final slash,
findFileInDirectory() fails to find the full path.
Remove the trailing slash and everything works fine.

This happens (at least on OSX) even if you run the example you sent me back
without arguments.

I'm re-attaching your example with the concatenation done the right way as
you suggested.

Thanks,
Riccardo


On Tue, Mar 27, 2018 at 6:38 PM, Robert Osfield 
wrote:

> I have just run the test case with a file with the wrong case to see
> what would happen, the results look 100% correct:
>
> $ ./test --dir ~/OpenSceneGraph/include/osg  --file version
> Result with findFileInDirectory(): 1
> /home/robert/OpenSceneGraph/include/osg/Version
> Result with fileExists(): 0
> concatenated=/home/robert/OpenSceneGraph/include/osgversion
> Result with fileExists(): 0
> proper_fileExsists=/home/robert/OpenSceneGraph/include/osg/version
>
> This test was run under Linux, so at least on the Linux side things
> are working correctly.  I have to defer to others to test under OSX.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


main.cpp
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Bug in osgDB::findFileInDirectory

[Riccardo Corsi]

Hi Robert and all,

I found a bug in osgDB::findFileInDirectory() which does not return the
expected result on MacOS (and I guess under Linux, but I cannot verify),
while it works as expected under Windows.

I'm attaching a modified osgversion.cpp which reproduces the issue.

Tested with:
osg 3.6.0-rc2
Win10
MacOS 10.13

Thank you,
riccardo


osgversion.cpp
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [3rdparty] ImGui integration

[Riccardo Corsi]

Hi Florian,

I have a working implementation with non-FFP, which I cannot disclose,
but I can give you some pointers:
- I suggest to go for the "osg version" that you mention, using native osg
geometries, not to have conflict with GL state and rendering in all osg
threading schemes
- you can either
1) create and destroy geometries
2) reuse them (updating vertex arrays and primitives).
In both method, make sure to manipulate the geometries only when it's safe,
as in some threading models update and draw will overlap.
For instance take a look at the FrameSwitch node mentioned in these threads:
http://forum.openscenegraph.org/viewtopic.php?t=14849
http://forum.openscenegraph.org/viewtopic.php?t=16463

HTH,
Riccardo


On Mon, Dec 18, 2017 at 3:51 PM, Florian GOLESTIN <
florian.goles...@gmail.com> wrote:

> Hi Everyone,
>
> I was thinking to integrate ImGUI with the non FPP version but I'm not
> sure how to do it.
>
> Itself, ImGUI render the ui inside a vector of (vector of ) struct
> containing the triplet Vertex Position, UV coordinates and Color value. As
> it's and "immediate GU", It refresh and refill the buffers every frames.
>
> Here, I see two solution:
>  - Non-OSG'ish: render the UI still using the GL function (glGen...) and
> shader
>  - OSG version using geometries (created and destructed each frame)
>
> What would be the recommended solution to integrate such library?
>
>
> Thank you!
> Florian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=72599#72599
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt Quick and Android

[Riccardo Corsi]

Hi all,

James can you just confirm that, with the QQuickRenderControl approach,
it's no more mandatory to have the main application loop handled by a Qt
application class?

At the time when I wrote https://github.com/rickyviking/qmlosg (probably it
was against Qt 4.8) the only option available was to render custom GL stuff
within a QtQuick node, and as such I had opted for osgViewer to render into
an FBO created on a separate GL context, to avoid any conflict between the
GL state used/updated by OSG and the one used by Qt to render its own
widgets.

Riccardo

On Mon, Sep 25, 2017 at 5:53 PM, James Turner  wrote:

>
> On 22 Sep 2017, at 20:55, Kamil Zaripov  wrote:
>
> I don’t sure that using QQuickWindow::beforeRendering() or
> QQuickWindow::afterRendering() signal will help since it also uses same
> OpenGL context as Qt Quick Scene Graph, but I will try it.
>
>
> Is that a problem? Keep in mind you can set any QSurfaceFormat as the
> default (before creating the first QQuickWindow, if you want to work on
> Mac) and hence request an arbitrary frame-buffer format or context profile,
> with the Qt API, and QtQuick can still use it.
>
> (And there is QQuickView::resetOpenGLState to avoid any state pollution)
>
> Of course the QQFBOItem approach is nice if you want to keep the contexts
> separate for some reason.
>
>
>
> Solution that uses QQuickRender sound good, I will lock at FlightGear
> sources.
>
>
> The QQuickRenderControl part isn’t pushed to FlightGear yet, I have it on
> a local branch since right now it’s not threadsafe, until I find a safe way
> to run QQuickRenderControl::sync from the OSG graphics thread, but with the
> main thread guaranteed to be locked. I can guess a few solutions to that
> but I’m hoping some people more familiar with the threading in
> osgViewer[base] will have some definitive answers.
>
> BTW both of my solutions above rely on using my GraphicsWindowQt5 which is
> a port+evolution of the old GraphicsWindowQt5 to QWIndow+QOpenGLContext;
> that part /is/ in FlightGear already but I’m still debugging some issues,
> especially mouse-pointer-warping, which FlightGear uses, is not working
> reliably compared to the ‘native’ GraphicsWindows (Cocoa, Win32, X11, etc)
>
> Kind regards,
> James
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Next developer release

[Riccardo Corsi]

​Hi Robert,

have you got any plan to tag the next developer release?

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

Re: [osg-users] Error with InputStream reading osgb files

[Riccardo Corsi]

Hi Robert,

I've eventually tested the submission on my project and everything works as
expected.
Big files are now written and read correctly.
Thank you,
Riccardo.

On Mon, Jun 19, 2017 at 6:44 PM, Riccardo Corsi <riccardo.co...@kairos3d.it>
wrote:

> Hi Robert,
>
> this week I'm out of office, I'll give it a test as soon as I come back.
> Cheers,
> Riccardo
>
> On Jun 19, 2017 6:03 PM, "Robert Osfield" <robert.osfi...@gmail.com>
> wrote:
>
>> HI Riccardo,
>>
>> On 14 June 2017 at 19:32, Robert Osfield <robert.osfi...@gmail.com>
>> wrote:
>> > Thanks Riccardo.  I'm just heading offline for the evening so will
>> > have a look tomorrow.
>>
>> I finally got the chance to do a review and merge your PR.  I made a
>> couple of further commits, first changing the long long to uint64,
>> then added an if (version) check to the writing to mirror what you
>> added to the reading, to leave the door open to eventually allowing us
>> to write files that are compatible with older OSG versions, finally I
>> bumped the version number up to 149 to enable the feature.  All these
>> changes are now checked into git master.
>>
>> I have tested by writing a .osgb file prior to bumping the version
>> number, then the same model after bumping the version number.  Both
>> versions load just fine with the recent file just a little larger
>> indicating the 64bit sizes are being written and read correctly :-)
>>
>> Could you test things out to confirm everything works at your end.
>>
>> Cheers,
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Error with InputStream reading osgb files

[Riccardo Corsi]

Hi Robert,

this week I'm out of office, I'll give it a test as soon as I come back.
Cheers,
Riccardo

On Jun 19, 2017 6:03 PM, "Robert Osfield"  wrote:

> HI Riccardo,
>
> On 14 June 2017 at 19:32, Robert Osfield  wrote:
> > Thanks Riccardo.  I'm just heading offline for the evening so will
> > have a look tomorrow.
>
> I finally got the chance to do a review and merge your PR.  I made a
> couple of further commits, first changing the long long to uint64,
> then added an if (version) check to the writing to mirror what you
> added to the reading, to leave the door open to eventually allowing us
> to write files that are compatible with older OSG versions, finally I
> bumped the version number up to 149 to enable the feature.  All these
> changes are now checked into git master.
>
> I have tested by writing a .osgb file prior to bumping the version
> number, then the same model after bumping the version number.  Both
> versions load just fine with the recent file just a little larger
> indicating the 64bit sizes are being written and read correctly :-)
>
> Could you test things out to confirm everything works at your end.
>
> Cheers,
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Error with InputStream reading osgb files

[Riccardo Corsi]

Hi Robert,

I've created a pull request
<https://github.com/openscenegraph/OpenSceneGraph/pull/264>.
You can modify the SO version number on the PR branch to make it consistent
before merging back to the main repo,
I've allowed contributions from maintainers.
Thanks,
Riccardo


On Mon, Jun 12, 2017 at 5:49 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Riccardo,
>
> On 12 June 2017 at 12:35, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
> > from within the BinaryStreamOperator we can get the file version with
> > getInputStream()->getFileVersion()
> > and decide to read/write the block size on 4 or 8 bytes accordingly.
> >
> > For the file version check would you use > 148 (i.e. osg 3.5.6) ?
>
> I would bump the SO version number specifically for this addtion, so
> bump it to 149 at the same time as merging the change this way we
> avoid any chance that there might be problem .osgb's created.
>
> Robert
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Error with InputStream reading osgb files

[Riccardo Corsi]

Hi Robert,

from within the BinaryStreamOperator we can get the file version with
getInputStream()->getFileVersion()
and decide to read/write the block size on 4 or 8 bytes accordingly.

For the file version check would you use > 148 (i.e. osg 3.5.6) ?
Riccardo



On Sun, Jun 11, 2017 at 2:05 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Good to hear you've tracked down the problem.  We might be able to
> version to use of long uints for future rev's of the OSG.
>
> On 9 June 2017 at 17:22, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
> > Hi again,
> >
> > I think I've found what's going on.
> > Basically the BinaryStreamOperator used to read the osgb format saves the
> > block size currently read with an int - see here - which is not large
> enough
> > to express very large blocks.
> >
> > I've patched the code with unsigned int (both when writing and reading
> block
> > size, always on 4 bytes) and I can now write and read correctly the files
> > that showed the problem.
> > Of course unsigned int is not large enough for arbitrarily huge blocks,
> but
> > at least it doubles the current max size.
> > I'll post a pull request with the patch.
> >
> > Using a type bigger than 4 bytes would make the current files
> unreadable, so
> > I don't think it's something that can be changed.
> > Riccardo
> >
> >
> > On Thu, Jun 8, 2017 at 1:15 PM, Riccardo Corsi <
> riccardo.co...@kairos3d.it>
> > wrote:
> >>
> >> Hi all,
> >>
> >> I'm getting an error when reading some (pretty big) osgb files and
> having
> >> hard time in finding what's causing the issue.
> >>
> >> I'm creating the files myself with osgDB::writeNodeFile, without any
> error
> >> message when writing them.
> >> The files' contents are only Groups and Geometries with basic data
> >> (vertices, normals, stateset).
> >> The files are created and read with the same osg libraries, version
> 3.5.3.
> >> The error message I receive on the console (even at DEBUG level) is
> only:
> >>
> >> Error reading file sample.osgb: read error (InputStream: Failed to read
> >> from stream. At osg::Group )
> >>
> >> with no additional details, as it normally happens when file is not well
> >> formatted.
> >>
> >> Additional info:
> >> - I've spotted the issue for big file (2GB or more), but not always
> from a
> >> given size up. I have some 4GB files working and some 3GB causing the
> error.
> >> - in some cases, if I create foo.osgb and bar.osgb they are both loaded
> >> correctly, but if I create foo+bar.osgb (writing works ok) I get the
> error
> >> when reading it.
> >>
> >> Unfortunately I cannot share example files.
> >> I'm looking for some pointers on how to investigate further to find the
> >> culprit.
> >>
> >> My configuration is:
> >> - osg 3.5.3
> >> - windows 10
> >> - visual studio 2013
> >>
> >> Thank you,
> >> Riccardo
> >>
> >>
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Error with InputStream reading osgb files

[Riccardo Corsi]

Hi again,

I think I've found what's going on.
Basically the BinaryStreamOperator used to read the osgb format saves the
block size currently read with an int - see here
<https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgPlugins/osg/BinaryStreamOperator.h#L282>
-
which is not large enough to express very large blocks.

I've patched the code with unsigned int (both when writing and reading
block size, always on 4 bytes) and I can now write and read correctly the
files that showed the problem.
Of course unsigned int is not large enough for arbitrarily huge blocks, but
at least it doubles the current max size.
I'll post a pull request with the patch.

Using a type bigger than 4 bytes would make the current files unreadable,
so I don't think it's something that can be changed.
Riccardo


On Thu, Jun 8, 2017 at 1:15 PM, Riccardo Corsi <riccardo.co...@kairos3d.it>
wrote:

> Hi all,
>
> I'm getting an error when reading some (pretty big) osgb files and having
> hard time in finding what's causing the issue.
>
> I'm creating the files myself with osgDB::writeNodeFile, without any error
> message when writing them.
> The files' contents are only Groups and Geometries with basic data
> (vertices, normals, stateset).
> The files are created and read with the same osg libraries, version 3.5.3.
> The error message I receive on the console (even at DEBUG level) is only:
>
> *Error reading file sample.osgb: read error (InputStream: Failed to read
> from stream. At osg::Group )*
>
> with no additional details, as it normally happens when file is not well
> formatted.
>
> Additional info:
> - I've spotted the issue for big file (2GB or more), but not always from a
> given size up. I have some 4GB files working and some 3GB causing the error.
> - in some cases, if I create foo.osgb and bar.osgb they are both loaded
> correctly, but if I create foo+bar.osgb (writing works ok) I get the error
> when reading it.
>
> Unfortunately I cannot share example files.
> I'm looking for some pointers on how to investigate further to find the
> culprit.
>
> My configuration is:
> - osg 3.5.3
> - windows 10
> - visual studio 2013
>
> Thank you,
> Riccardo
>
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Error with InputStream reading osgb files

[Riccardo Corsi]

Hi all,

I'm getting an error when reading some (pretty big) osgb files and having
hard time in finding what's causing the issue.

I'm creating the files myself with osgDB::writeNodeFile, without any error
message when writing them.
The files' contents are only Groups and Geometries with basic data
(vertices, normals, stateset).
The files are created and read with the same osg libraries, version 3.5.3.
The error message I receive on the console (even at DEBUG level) is only:

*Error reading file sample.osgb: read error (InputStream: Failed to read
from stream. At osg::Group )*

with no additional details, as it normally happens when file is not well
formatted.

Additional info:
- I've spotted the issue for big file (2GB or more), but not always from a
given size up. I have some 4GB files working and some 3GB causing the error.
- in some cases, if I create foo.osgb and bar.osgb they are both loaded
correctly, but if I create foo+bar.osgb (writing works ok) I get the error
when reading it.

Unfortunately I cannot share example files.
I'm looking for some pointers on how to investigate further to find the
culprit.

My configuration is:
- osg 3.5.3
- windows 10
- visual studio 2013

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

Re: [osg-users] Recommended way to render a scene from multiple independent viewpoints

[Riccardo Corsi]

Hi Hannes,

for the camera setup you're after I recommend using a SlaveUpdateCallback,
which will be called once per frame for each slave camera, allowing you to
manipulate the camera position/orientation at will.

Here's a code snippet:

// implement a slave callback to place the camera as you want
class MySlaveCallback : public osg::View::Slave::UpdateSlaveCallback
{
   // implement update method
   virtual void updateSlave(osg::View& view, osg::View::Slave& slave){ ... }
}

// add the camera as slave
slaveCam->setGraphicsContext(gc);
viewer.addSlave(slaveCam, true);

// install your callback
osg::View::Slave* slave = viewer.findSlaveForCamera(slaveCam);
slave->_updateSlaveCallback = pMirrorCallback;

Ricky

On Tue, Apr 11, 2017 at 2:11 PM, Hannes Naude  wrote:

> I think I solved my own problem. I was planning to use
>
> viewer.addSlave(cam,...)
>
>
> and then use
>
> cam->setReferenceFrame(osg::Transform::ABSOLUTE_RF)
>
>
> to decouple the slave camera from the master. (If this is not the best
> approach, I would still like to hear, but it seems pretty clean)
>
> It turned out that I did not even need the second call. I think this is
> because I have an update callback attached to each of the slave cameras
> that explicitly sets the view matrix to match the world-to-local matrix of
> some node in the scenegraph and thereby overrides the slaving.
>
> By the way, this is something else that has bothered me. The requirement
> for a camera to track a node in the scenegraph seems like it should be
> extremely common. But in order to implement this I had to write my own
> little NodeTracker Callback as follows:
>
> class NodeTracker : public NodeCallback
>
> {
>
> public:
>
>NodePath _nodepath;
>
>
>NodeTracker(Node* node):_nodepath(node->getParentalNodePaths()[0]){}
>
>
>virtual void operator()(Node* node, NodeVisitor* nv)
>
>{
>
>  ref_ptr cam=node->asCamera();
>
>  if(cam)
>
>  {
>
>  Matrix mat2=cam->getViewMatrix();
>
>  Matrix mat=computeWorldToLocal(_nodepath);
>
> cam->setViewMatrix(mat);
>
>  }
>
>  traverse(node, nv);
>
>}
>
> };
>
> It feels like this is such a common requirement that something like it
> should be built into OSG. I had a look at the tutorial on the subject :
>
> http://trac.openscenegraph.org/projects/osg//wiki/Support/Tutorials/
> CameraControlNodeFollowing
>
> but it recommends a solution that seems even more generally useful and is
> quite verbose, yet is not included in osg. What am I missing here?
>
> Regards
> Hannes Naude
>
>
> On Tue, Apr 11, 2017 at 1:08 PM, Hannes Naude  wrote:
>
>> Hi all
>>
>> I am trying to render a single scene from multiple viewpoints. I
>> initially implemented this with a compositeviewer as per the
>> osgthirdpersonview example. This worked fine except that my update
>> callbacks appeared to be getting called more than once per render cycle. I
>> assumed that the update traversal was being done for each view separately
>> and therefore nodes that are present in multiple views will have their
>> update callbacks called multiple times. So, at this point I tried to do the
>> same thing but with a single View, somewhat similar to the osgCamera
>> example. But, I do not want to add my cameras with viewer.addSlave as I
>> want them to move independently of one another. So I tried adding them into
>> the scene graph and giving each their own GraphicsContext, but even though
>> the windows corresponding to these GraphicsContexts get created, it appears
>> as if all rendering is done in a single window with multiple viewpoints
>> being rendered over one another.
>>
>> Obviously there are many ways to skin this cat, but I would appreciate
>> some guidance on the recommended approach. To recap my requirements are :
>>  - Multiple cameras viewing the same scene.
>>  - Camera positions and orientations must be independently controlled.
>>  - Node update callbacks should be called only once per Node per render
>> cycle.
>>
>> Any help will be appreciated
>>
>> Regards
>> Hannes Naude
>>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Early events handling

[Riccardo Corsi]

Hi all,

what I'm after is very similar to what the osg viewer does when checking if
the QUIT event has happened during the last frame - link

-
with all the events collected in a frame available at the same time.

I'd like to do that before the other callbacks (placed as node callback or
viewer events handler) are invoked, with one event passed at the time.

At the moment, the best workaround that I could come up with is to collect
all the events in a node callback, and use the FRAME event to know that I
have finished the collection for the current frame.

Robert, do you think it's advisable to add a new callback/entry point in
the Viewer and CompositeViewer classed for such usage?

Thank you,
Riccardo
___
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

[Riccardo Corsi]

@Jannik ahah sorry, I didn't realize from the author's name :D  I
remembered the post as I've successfully used a solution similar to yours
to render DYNAMIC elements that I want to render at the end of the frame.

Anyway, as the frame number issue is fixed, no more need for workarounds.
Cheers,
Ricky


On Thu, Feb 2, 2017 at 6:25 PM, Jannik Heller  wrote:

> 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Riccardo Corsi]

Hi Jannik,

depending on what you are doing in the drawImplementation(), I can think of
2 options.

If you need to modify the drawable/stateset you can actually deep copy you
drawable and use a "FrameSwitch" class as explained in this post (contains
a link to the code): http://forum.openscenegraph.org/viewtopic.php?t=14849

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.

Ricky


On Wed, Feb 1, 2017 at 9:33 PM, Jannik Heller  wrote:

> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] corrupted rendering

[Riccardo Corsi]

Hi Robert and Laurens,

thanks for the fix, it works in my setup as well.
Riccardo

On Wed, Dec 21, 2016 at 10:30 AM, Robert Osfield 
wrote:

> Hi Laurens,
>
> On 21 December 2016 at 08:45, Voerman, L.  wrote:
> > I created a pull request for the master branch (link).
>
> Thanks for the fix.  I've reviewed it and decided that it would be
> more in keeping with how osgViewer::View's master Camera() sets it's
> StateSet::setGlobalStateSet() to do the same with the StatsHandler, so
> I've added a:
>
> _camera->getOrCreateStateSet()->setGlobalDefaults();
>
> To the StatsHandler constructor.  I've checked this into git master,
> 3.4 and 3.2 branches.
>
> I have tested this with Riccardo's modified osgviewer.cpp and it works
> properly once this fix is applied.
>
> Thanks to both of you for your help homing and fixing this long standing
> bug.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] corrupted rendering

[Riccardo Corsi]

Hi Robert,

please find attached the hacked viewer which starts also without any loaded
model.

Here are the details of my setup (even though I've noticed this issue since
several osg versions now)
- Win10 / VisualStudio 2013
- nVidia GTX970 with recent drivers
- osg 3.5.3

Thank you,
Riccardo



On Thu, Dec 15, 2016 at 8:16 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Riccardo,
>
> Could you post your modified osgviewer so we can attempt to reduce things.
>
> Also please provide details on the OS platform, OSG version, drivers,
> hardware as these are all likely to affect the result.
>
> Robert.
>
> On 15 December 2016 at 18:44, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
> > Hi all,
> >
> > I've found out that when I show the stats handler without having set any
> > data on the viewer,
> > its rendering is corrupted (fonts, transparency) - see attached
> screenshot,
> > I simply forced osgViewer to run without any loaded model.
> >
> > The Stats are rendered without being attached to the scene or as a slave,
> > the stats camera instead is directly added to the first available
> graphics
> > context,
> > so I'm afraid some initialization is missing.
> >
> > I have the same problem with another GUI tool I'm rendering with the same
> > technique.
> > Can anybody provide an hint?
> > Thank you,
> > Riccardo
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
 *
 * This application is open source and may be redistributed and/or modified
 * freely and without restriction, both in commercial and non commercial applications,
 * as long as this copyright notice is maintained.
 *
 * This application is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*/

#include 
#include 
#include 

#include 
#include 
#include 

#include 
#include 

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

#include 

#include 


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

arguments.getApplicationUsage()->setApplicationName(arguments.getApplicationName());
arguments.getApplicationUsage()->setDescription(arguments.getApplicationName()+" is the standard OpenSceneGraph example which loads and visualises 3d models.");
arguments.getApplicationUsage()->setCommandLineUsage(arguments.getApplicationName()+" [options] filename ...");
arguments.getApplicationUsage()->addCommandLineOption("--image ","Load an image and render it on a quad");
arguments.getApplicationUsage()->addCommandLineOption("--dem ","Load an image/DEM and render it on a HeightField");
arguments.getApplicationUsage()->addCommandLineOption("--login   ","Provide authentication information for http file access.");
arguments.getApplicationUsage()->addCommandLineOption("-p ","Play specified camera path animation file, previously saved with 'z' key.");
arguments.getApplicationUsage()->addCommandLineOption("--speed ","Speed factor for animation playing (1 == normal speed).");
arguments.getApplicationUsage()->addCommandLineOption("--device ","add named device to the viewer");

osgViewer::Viewer viewer(arguments);

unsigned int helpType = 0;
if ((helpType = arguments.readHelpType()))
{
arguments.getApplicationUsage()->write(std::cout, helpType);
return 1;
}

// report any errors if they have occurred when parsing the program arguments.
if (arguments.errors())
{
arguments.writeErrorMessages(std::cout);
return 1;
}


#if 0
if (arguments.argc()<=1)
{
arguments.getApplicationUsage()->write(std::cout,osg::ApplicationUsage::COMMAND_LINE_OPTION);
return 1;
}
#endif


std::string url, username, password;
while(arguments.read("--login",url, username, password))
{
if (!osgDB::Registry::instance()->getAuthenticationMap())
{
osgDB::Registry::instance()->setAuthenticationMap(new osgDB::AuthenticationMap);
osgDB::Registry::instance()

[osg-users] corrupted rendering

[Riccardo Corsi]

Hi all,

I've found out that when I show the stats handler without having set any
data on the viewer,
its rendering is corrupted (fonts, transparency) - see attached screenshot,
I simply forced osgViewer to run without any loaded model.

The Stats are rendered without being attached to the scene or as a slave,
the stats camera instead is directly added to the first available graphics
context,
so I'm afraid some initialization is missing.

I have the same problem with another GUI tool I'm rendering with the same
technique.
Can anybody provide an hint?
Thank you,
Riccardo
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] PrimitiveSets and performance

[Riccardo Corsi]

Hi Glenn and Robert,

thank you for your suggestion.

I have written a little stress test application to try different
PrimitiveSet sizes,
but so fat it's providing inconsistent results with respect to my previous
benchmark (and in line to what I expected).
I wasn't able to isolate a culprit so far, I'll let you know if I spot
something.

Ricky


On Fri, Dec 2, 2016 at 6:36 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Riccardo,
>
> I'm a surprised you saw a significant change in performance, in
> particular for the worse, this suggest that the merging has some kind
> of error in it or the driver isn't handling the larger sized
> primitives efficiently for some reason.
>
> One thing of note is that both the draw dispatch and the draw GPU are
> around the same amount slower in the merged case, this suggest that
> the something in happening in the driver/GPU combination that is
> blocking the OpenGL FIFO and then in turn blocking the OSG draw
> dispatch that is putting data into the OpenGL FIFO.
>
> There isn't any way for us to pinpoint what this might be with the
> details given.
>
> Check for GL errors being printed to the console.  Also try writing a
> your scene graph out to a .osgt  before and after the merge so you can
> QA the merge by hand - do this for a subset of your whole scene graph
> as reviewing a really big dataset will be really heavy on an editor.
>
> Robert.
>
>
> On 2 December 2016 at 15:32, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
> > Hi all,
> >
> > I'm trying to find out the best geometries and primitive sets layout on a
> > model that I'm using as performance benchmark.
> >
> > The model is quite heavy in terms of vertices and polygons, and
> everything
> > is rendered at the moment with DrawArrays.
> >
> > In the attempt to reduce the draw calls, I've recombined the primitive
> sets
> > contained in every geometry into a single primitive set.
> > I expected draw/gpu time to improve, and I've found the exact opposite -
> > find attached the 2 screenshots with the stats (before and after
> primitives
> > merge).
> >
> > After merging the primitive sets I've also tried to force VBO usage
> instead
> > of display lists, which improve things slightly, but always far worse
> than
> > before merging.
> >
> > Can anyone comment on this result?
> >
> > Thank you,
> > Riccardo
> >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Using StatsHandler rendering method

[Riccardo Corsi]

Hi all,

I've found out that the camera of the StatsHandler is added directly to the
GraphicsContext and not to the viewer/scene.

Besides the fact that this ensures it to work in all scenarios, are there
other advantages in using this method rather than attaching the camera to
the viewer as slave on in the scene graph?


Another question: I expected the StatsHandler's geometry contents to be set
with DYNAMIC DataVariance, as they are modified frame by frame, but I could
not find any explicit code for that.
How do you tackle the geometry modification?

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

Re: [osg-users] Use OSG with an existing renderer in OpenGL ES

[Riccardo Corsi]

Hi Fabien,

in your situation the approach suggested by Chris is certainly the most
promising.
Create a second GL context (shared), render everything you need to with osg
in the second context to an FBO target and have Qt retrieve the fbo's
texture content, to display it in one of its widgets/primitives.
This way you don't need to know which GL states Qt/qml uses and/or modifies
and you're sure neither qml nor osg rendering will be corrupted.

You can find a sample integration I wrote some times ago here:
https://github.com/rickyviking/qmlosg
and a more recent example here: https://github.com/podsvirov/osgqtquick

Ricky


On Mon, Nov 21, 2016 at 11:52 AM, Robert Osfield 
wrote:

> On 21 November 2016 at 09:12, Fabien Boco  wrote:
> > This is why I'm looking for an OpenGL ES alternative for
> glPush/PopAttrib which works fine on the Windows version application.
>
>
> The alternative to using glPush/glPop on the OSG would be to dirty the
> associated modes and attributes that are tracked in osg::State.  In
> osg::State there are series of haveApplied*() methods to help with
> tell the OSG's state tracking mechanism something has externally
> changed.  This requires you to know what modes and attributes will
> have been changed by the 3rd party code so it's not an easy
> alternative to glPush/glPop.
>
> Personally I find Qt's approach of changing GL state problematic, I
> much prefer windowing libraries to just create a graphics context and
> leave GL work entirely to dedicated graphics libraries.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Plugins errors for unsupported files

[Riccardo Corsi]

Hi Robert,

maybe I wasn't clear in my previous message.

I'm not suggesting to remove the code,
only to move it down few lines, and possibly inside an if block which
checks if the video is loaded from internet (filename containing an URL
path).

That should cover the use case of streaming the video from a server and
improve a more general file type handling.



On Wed, Oct 19, 2016 at 12:29 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Riccardo,
>
> Just removing a code block might fix the problem you are seeing but
> it'll break things for others so isn't an appropriate thing to do as
> we'll just end up flip flopping between who's code we break today.
>
> I haven't looked into the error itself yet, but my inclination would
> be to see if is possible to improve the OSG's ffmpeg plugins' file
> opening so that it handles the inability to read a file more
> elegantly.
>
> Robert.
>
> On 19 October 2016 at 10:31, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
> > Hi Robert,
> >
> > right, the ffmpeg plugin is trying to load files without knowing if they
> are
> > of a supported format.
> > The related code is here:
> > https://github.com/openscenegraph/OpenSceneGraph/
> blob/master/src/osgPlugins/ffmpeg/ReaderWriterFFmpeg.cpp#L149
> >
> > The comment explains something related to videos served from internet.
> > I'm wondering if it would be ok to move that code below, after having
> > checked whether the filename contains a URL (performed a few lines
> below).
> > This would stop the plugin to try loading every possible image and
> printing
> > errors on the console.
> >
> > Thanks,
> > Ricky
> >
> >
> > On Tue, Oct 18, 2016 at 7:54 PM, Robert Osfield <
> robert.osfi...@gmail.com>
> > wrote:
> >>
> >> Hi Ricky,
> >>
> >> The OSG uses the Chain Of Responsibility Design Pattern for the
> >> plugins - so it's the plugins themselves to decide what formats they
> >> can load.  This enables them to handle multiple formats if they can
> >> support it.  From the description it sounds like the ffmpeg isn't
> >> doing a good enough at deciding what it can or cannot load.
> >>
> >> Robert.
> >>
> >> On 18 October 2016 at 18:18, Riccardo Corsi <riccardo.co...@kairos3d.it
> >
> >> wrote:
> >> > Hi Robert and all,
> >> >
> >> > I'm currently using the ffmpeg plugin to load some movies - it works
> >> > just
> >> > fine but my application started generating a lot of errors on console
> >> > like
> >> > this:
> >> >> FFmpegImageStream::open : av_open_input_file() failed : AVERROR_NOENT
> >> > every time an image has to be loaded.
> >> >
> >> > You can reproduce the issue with the modified osgMovie example in
> >> > attach,
> >> > which also loads the textured cow model.
> >> >
> >> > Digging a bit I've seen that's because the file reading mechanism
> tries
> >> > to
> >> > read from all the already loaded plugins, reagardless of their
> >> > extension(s)
> >> > support.
> >> > See here:
> >> >
> >> > https://github.com/openscenegraph/OpenSceneGraph/
> blob/master/src/osgDB/Registry.cpp#L1176
> >> >
> >> > I thought that the extension supported by each plugin was checked
> before
> >> > trying to use it.
> >> > Besides the annoying errors on the console, wouldn't it be more
> >> > efficient?
> >> >
> >> > Thanks,
> >> > Ricky
> >> >
> >> > ___
> >> > osg-users mailing list
> >> > osg-users@lists.openscenegraph.org
> >> >
> >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >> >
> >> ___
> >> osg-users mailing list
> >> osg-users@lists.openscenegraph.org
> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Plugins errors for unsupported files

[Riccardo Corsi]

Hi Robert,

right, the ffmpeg plugin is trying to load files without knowing if they
are of a supported format.
The related code is here:
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgPlugins/ffmpeg/ReaderWriterFFmpeg.cpp#L149

The comment explains something related to videos served from internet.
I'm wondering if it would be ok to move that code below, after having
checked whether the filename contains a URL (performed a few lines below).
This would stop the plugin to try loading every possible image and printing
errors on the console.

Thanks,
Ricky


On Tue, Oct 18, 2016 at 7:54 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Ricky,
>
> The OSG uses the Chain Of Responsibility Design Pattern for the
> plugins - so it's the plugins themselves to decide what formats they
> can load.  This enables them to handle multiple formats if they can
> support it.  From the description it sounds like the ffmpeg isn't
> doing a good enough at deciding what it can or cannot load.
>
> Robert.
>
> On 18 October 2016 at 18:18, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
> > Hi Robert and all,
> >
> > I'm currently using the ffmpeg plugin to load some movies - it works just
> > fine but my application started generating a lot of errors on console
> like
> > this:
> >> FFmpegImageStream::open : av_open_input_file() failed : AVERROR_NOENT
> > every time an image has to be loaded.
> >
> > You can reproduce the issue with the modified osgMovie example in attach,
> > which also loads the textured cow model.
> >
> > Digging a bit I've seen that's because the file reading mechanism tries
> to
> > read from all the already loaded plugins, reagardless of their
> extension(s)
> > support.
> > See here:
> > https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgDB/
> Registry.cpp#L1176
> >
> > I thought that the extension supported by each plugin was checked before
> > trying to use it.
> > Besides the annoying errors on the console, wouldn't it be more
> efficient?
> >
> > Thanks,
> > Ricky
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Plugins errors for unsupported files

[Riccardo Corsi]

Hi Robert and all,

I'm currently using the ffmpeg plugin to load some movies - it works just
fine but my application started generating a lot of errors on console like
this:
> FFmpegImageStream::open : av_open_input_file() failed : AVERROR_NOENT
every time an image has to be loaded.

You can reproduce the issue with the modified osgMovie example in attach,
which also loads the textured cow model.

Digging a bit I've seen that's because the file reading mechanism tries to
read from all the already loaded plugins, reagardless of their extension(s)
support.
See here:
https://github.com/openscenegraph/OpenSceneGraph/blob/master/src/osgDB/
Registry.cpp#L1176

I thought that the extension supported by each plugin was checked before
trying to use it.
Besides the annoying errors on the console, wouldn't it be more efficient?

Thanks,
Ricky
/* OpenSceneGraph example, osgmovie.
*
*  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 

class MovieEventHandler : public osgGA::GUIEventHandler
{
public:

MovieEventHandler():_trackMouse(false) {}

void setMouseTracking(bool track) { _trackMouse = track; }
bool getMouseTracking() const { return _trackMouse; }

void set(osg::Node* node);

virtual bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor* nv);

virtual void getUsage(osg::ApplicationUsage& usage) const;

typedef std::vector< osg::observer_ptr > ImageStreamList;

protected:

virtual ~MovieEventHandler() {}

class FindImageStreamsVisitor : public osg::NodeVisitor
{
public:
FindImageStreamsVisitor(ImageStreamList& imageStreamList):
_imageStreamList(imageStreamList) {}

virtual void apply(osg::Geode& geode)
{
apply(geode.getStateSet());

for(unsigned int i=0;igetStateSet());
}

traverse(geode);
}

virtual void apply(osg::Node& node)
{
apply(node.getStateSet());
traverse(node);
}

inline void apply(osg::StateSet* stateset)
{
if (!stateset) return;

osg::StateAttribute* attr = stateset->getTextureAttribute(0,osg::StateAttribute::TEXTURE);
if (attr)
{
osg::Texture2D* texture2D = dynamic_cast(attr);
if (texture2D) apply(dynamic_cast(texture2D->getImage()));

osg::TextureRectangle* textureRec = dynamic_cast(attr);
if (textureRec) apply(dynamic_cast(textureRec->getImage()));
}
}

inline void apply(osg::ImageStream* imagestream)
{
if (imagestream)
{
_imageStreamList.push_back(imagestream);
}
}

ImageStreamList& _imageStreamList;

protected:

FindImageStreamsVisitor& operator = (const FindImageStreamsVisitor&) { return *this; }

};


bool_trackMouse;
ImageStreamList _imageStreamList;
unsigned int_seekIncr;

};



void MovieEventHandler::set(osg::Node* node)
{
_imageStreamList.clear();
if (node)
{
FindImageStreamsVisitor fisv(_imageStreamList);
node->accept(fisv);
}
}


bool MovieEventHandler::handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor* nv)
{
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::MOVE):
case(osgGA::GUIEventAdapter::PUSH):
case(osgGA::GUIEventAdapter::RELEASE):
{
if (_trackMouse)
{
osgViewer::View* view = dynamic_cast();
osgUtil::LineSegmentIntersector::Intersections intersections;
 

Re: [osg-users] GUIEventHandler called twice - possible bug(s)

[Riccardo Corsi]

Hi Robert,

both double call and crash fixed on my side as well.

Now that one can safely implement a callback by deriving directly from
osg::Callback, I think most users should go that way for their new code.
If that's the case, the not-very-intuitive path of implementing operator()
rather than run() in the NodeCallback should be a minor issue.

Maybe a note in the comments suggesting to derive from osg::Callback rather
than the legacy classes could be worth it?

Thank you,
Riccardo






On Thu, Oct 6, 2016 at 7:30 PM, Robert Osfield 
wrote:

> Hi Riccardo,
>
> I have found the cause of the double call, fixed it and have now
> checked in this fix and the other fixes to event callback handling.
> Changes checked into OSG git master.
>
> Could you test them out on your application to make sure that things
> are now behaving themselves.
>
> Thanks,
> Robert
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] GUIEventHandler called twice - possible bug(s)

[Riccardo Corsi]

Hi Robert,

please find attached a simple example that shows the issues I was trying to
explain:
- launch with no args to see the initial issue
- launch with "--crash" to get the crash i ran into when implementing the
callback deriving from osg::Callback
- launch with "--fix" to see the way I fixed it with the NodeCallback:
comments on the run() and operator() methods explain some concerns for this
solution

Hope this clarifies things :)
Ricky


On Mon, Aug 29, 2016 at 4:29 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Ricky,
>
> The changes to Drawable and the knock on effect to the callbacks is an
> awkward one - it would be easy if it we could just discard backwards
> compatibility, so it's a far from ideal code, but alas you can't
> rewrite history once it's happened.
>
> From your description I don't have a clear idea of what is being
> called twice and whether this is a problem.  Could you create a small
> example that illustrates the problem, once I can see first hand I can
> review the behaviour and decide whether this is acceptable or is an
> bug.
>
> Thanks,
> Robert.
>
> On 29 August 2016 at 15:00, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
> > Hi all,
> >
> > I report what I believe could be considered a bug, probably introduced
> after
> > the promotion of the Drawable class to a node, together with the new
> > callback system.
> >
> > I have a GUIEventHandler derived class installed on a Drawable.
> > After some digging I've realized that it's called twice for every event
> due
> > to the EventVisitor code here:
> > https://github.com/openscenegraph/OpenSceneGraph/
> blob/master/include/osgGA/EventVisitor#L86
> >
> > GUIEventHandler happens to derive both from NodeCallback and
> > DrawableEventCallback, resulting in it being called twice. I think this
> > might be considered as a bug if the intended behavior was to keep using
> the
> > old GUIEventHandler interface the way it was (when attached to the viewer
> > for instance, it is called only once as expected).
> >
> > Relate issue:
> > I've re-implemented my callback deriving from osg::Callback, but this
> > results in a crash as the osg::CallbackObject interface is used even if
> the
> > cast does not succeed (first if condition)
> > https://github.com/openscenegraph/OpenSceneGraph/
> blob/master/include/osgGA/EventVisitor#L93
> >
> > I fixed that by deriving from osg::NodeCallback, but I had to reimplement
> > the operator() method instead of run(), as the second is not called by
> the
> > visitor - that also it's a bit counter-intuitive with respect to the
> > osg::Callback class interface.
> >
> > Ricky
> >
> >
> >
> >
> >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
/* OpenSceneGraph example, osgcallback.
*
*  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 

class TwiceEventCallback : public osgGA::GUIEventHandler
{
public:
   virtual bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa, osg::Object*, osg::NodeVisitor* nv) 
   { 
  if (ea.getEventType() == osgGA::GUIEventAdapter::PUSH)
  {
 OSG_ALWAYS << "[Twice] Mouse PUSH on frame: " << nv->getFrameStamp()->getFrameNumber() << std::endl;
  }

  return false;
   }
};


class CrashEventCallback : public

[osg-users] GUIEventHandler called twice - possible bug(s)

[Riccardo Corsi]

Hi all,

I report what I believe could be considered a bug, probably introduced
after the promotion of the Drawable class to a node, together with the new
callback system.

I have a GUIEventHandler derived class installed on a Drawable.
After some digging I've realized that it's called twice for every event due
to the EventVisitor code here: https://github.com/
openscenegraph/OpenSceneGraph/blob/master/include/osgGA/EventVisitor#L86

GUIEventHandler happens to derive both from NodeCallback
and DrawableEventCallback, resulting in it being called twice. I think this
might be considered as a bug if the intended behavior was to keep using the
old GUIEventHandler interface the way it was (when attached to the viewer
for instance, it is called only once as expected).

Relate issue:
I've re-implemented my callback deriving from osg::Callback, but this
results in a crash as the osg::CallbackObject interface is used even if the
cast does not succeed (first if condition)
https://github.com/openscenegraph/OpenSceneGraph/blob/master/include/osgGA/EventVisitor#L93

I fixed that by deriving from osg::NodeCallback, but I had to reimplement
the operator() method instead of run(), as the second is not called by the
visitor - that also it's a bit counter-intuitive with respect to the
osg::Callback class interface.

Ricky
___
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

[Riccardo Corsi]

Hi Jannik,

NESTED_RENDER plus a higher renderBin number is exactly the way I've sorted
out the issue,
even though there's no way to use the standard camera draw-callback.

So based on your first reply, the POST in-scene camera, if nothing is
assigned to its renderTargetImplementation, will render to the default
Frame Buffer,
and that's the reason why nothing shows up in the slave's FBO when its draw
is fired from the slave camera, right?

Ricky

On Fri, Aug 5, 2016 at 5:53 PM, Jannik Heller  wrote:

> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Riccardo Corsi]

Hi all,

I have an in-scene POST camera to render a GUI.
I don't specify anything regarding its RenderTargetImplementation and it
renders to the frame buffer as expected.

Now I have to render the same scene + GUI with an FBO camera: I attach as
slave to the viewer specifying to use the same scene the main viewer camera.

As expected, the in-scene camera gets invoked for drawing both from the
main viewer camera and the slave one (verified with a debug callback).
Unfortunately its contents don't get rendered only for the main camera, not
for the slave one.

Should I setup the POST camera in some custom way to work both with the
main (rendering to the Frame Buffer) and the slave (rendering to FBO)?
Does the in-scene camera "inherit" the current render target from the top
camera attached to the viewer?

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

Re: [osg-users] Convertions w.r.t .gitignore

[Riccardo Corsi]

Hi Robert,

what we normally do with VisualStudio is to build our projects out of
source in a folder at the same level as include or src.
It is then enough to either add that folder to the OSG gitignore, or to
create another gitignore file within the build folder, with just an * in it.
This way we don't care about specific VisualStudio paths.

Cheers,
Ricky

On Tue, Jan 26, 2016 at 10:59 AM, Robert Osfield 
wrote:

> Thanks for the suggest Bjorn.  I have merged the C++ .gitignore
> entries, the VisualStudio one looks to be a huge collection of
> possibilities that I suspect aren't relevant to the OSG.  Could
> windows users report what they see when building the OSG and we can
> add specific entries to clean these up.
>
> On 26 January 2016 at 09:51, Björn Blissing  wrote:
> > Hi Robert,
> >
> > GitHub have a collection of useful gitignore templates:
> > https://github.com/github/gitignore
> >
> > It may be a good idea to add the patterns from the C++.gitignore as well
> as the patterns from VisualStudio.gitignore.
> >
> > Best regards,
> > Björn
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=66119#66119
> >
> >
> >
> >
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] plugin v8 in version 3.3.1

[Riccardo Corsi]

Hi Scott,

I believe Robert refers to project like:
* duktape: http://duktape.org/
* v7: https://github.com/cesanta/v7

which are small and open source javascript interpreters (like one .h and
one .c file),
with a binding API similar to Lua.

I have no experience with any of them, if someone has it would be
interesting to know how they perform.
Ricky



On Mon, Jan 25, 2016 at 8:43 PM, Scott Duensing  wrote:

> Thanks for the detailed reply.  I did look over the Lua plugin and learned
> quickly that I don't know enough about OSG to make sense of it yet!  :-)
>
>
> robertosfield wrote:
> >
> > If I were to tackle javascript integration I'd probably look for
> > another route than using V8, for instance that are now open source
> > projects that are smaller and more suitable for application
> > integration that fit more in with the lua level of size and complexity
> > i.e. minimal on both counts.
> >
>
>
> Oh?  Can you give me some pointers?  Thanks again.
>
>
> Scott
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=66110#66110
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus + external view

[Riccardo Corsi]

Hi all,

a small update:
with the same settings as in my previous email, but setting the Oculus
slave cameras to POST_RENDER,
both the main view and the Oculus work fine.
Maybe with the PRE render settings, the pre/post draw callback on the
oculus slave cameras
were not called at the right moment.

That said, I'm not sure if what I've tried is optimal/enough to achieve the
scenario I'm after...
Can anyone comment on this?

Thanks
Ricky


On Wed, Jan 20, 2016 at 1:16 PM, Riccardo Corsi <riccardo.co...@kairos3d.it>
wrote:

> Hi Björn and all,
>
> at the moment the setup created by the osgOculusViewer is to blit the
> Oculus mirror texture in the viewer window on screen.
>
> I'd like to have the screen win to show a different result, from a third
> non-distorted camera.
>
> As a first test, I've tried to comment out the blit instruction (here
> <https://github.com/bjornblissing/osgoculusviewer/blob/master/src/oculusdevice.cpp#L772>)
> and re-enable the main camera graphics context, but it doesn't work:
> screen view is ok, but the Oculus is blank.
>
> Is there a simple way to test the scenario I'm after?
>
> Thanks,
> Ricky
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Oculus + external view

[Riccardo Corsi]

Hi Björn and all,

at the moment the setup created by the osgOculusViewer is to blit the
Oculus mirror texture in the viewer window on screen.

I'd like to have the screen win to show a different result, from a third
non-distorted camera.

As a first test, I've tried to comment out the blit instruction (here
)
and re-enable the main camera graphics context, but it doesn't work:
screen view is ok, but the Oculus is blank.

Is there a simple way to test the scenario I'm after?

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

Re: [osg-users] user stats update

[Riccardo Corsi]

Hi Robert,

I wasn't able to reproduce the issue with as osg example.
But I've found that if just set to true the "average" flag when calling I
addUserStatsLine(), the flickering disappear.
Don't know if this is helpful, but the result just works for me.

Regarding the drawing stats affected by the driver blocking behavior,
is the only drawback is a "fake" stats or there might be actual performance
penalties?

Thanks,
Ricky

On Wed, Nov 18, 2015 at 8:08 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Ricky,
>
> This type of behaviour can be difficult to diagnose when you have all the
> data and software in front of you, when you only have reports from a 3rd
> party it's unfortunately next to impossible to diagnose.
>
> Since I can't determine the problem there isn't anything I can suggest.
> If you can reproduce the problem in an OSG example that you can share then
> there is chance then that others can pitch in and see if they can spot the
> cause of the problem and what to do about it.
>
> Robert.
>
> On 18 November 2015 at 17:46, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
>
>> Hi Robert,
>>
>> with "flickering" I mean that the labels of my custom stats lines are
>> always showing,
>> while the numeric value besides them disappear in some frames.
>> They apparently disappear under the conditions explained in my previous
>> email.
>> This is true only for my custom stats, and not the default one updated by
>> osg.
>> (with vsync disabled things improve, but sometimes the issue is still
>> visible).
>>
>> I might try to reproduce the issue with a heavy enough osg model loaded
>> in the osguserstats example.
>>
>> As for the draw, disabling the vsync dramatically reduces the draw time
>> shown in the stats.
>> Should I live with this blocking behavior when vsync is on?
>> The only drawback is a "fake" (and misleading) stats or there are real
>> performance penalties?
>>
>> Thanks,
>> Ricky
>>
>> On Wed, Nov 18, 2015 at 6:28 PM, Robert Osfield <robert.osfi...@gmail.com
>> > wrote:
>>
>>> Hi Ricky,
>>>
>>> When you mean flickering, could it simply be that the frame timing stats
>>> is jumping between two extremes on alternate frames.
>>>
>>> In certain circumstances the driver can block and draw dispatch times
>>> can suddenly go up massively even though that actual system shouldn't be
>>> overloaded.  In the example you show this is happening. It could possibly
>>> be something else on the OSG side that is blocking.
>>>
>>> As a sanity test try disabling vsync as this can change the behaviour of
>>> the driver w.r.t blocking.
>>>
>>> Robert.
>>>
>>> On 18 November 2015 at 16:20, Riccardo Corsi <riccardo.co...@kairos3d.it
>>> > wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> yes for the flickering I refer to the stats on screen.
>>>>
>>>> Here's what I've noticed:
>>>> - I place my stats update between event and update traversal
>>>> - the flickering appears when I use threading models other than
>>>> singleThreaded (typically the default DrawThreadPerContext one)
>>>> AND the cull+draw time hits the frame duration time (around 16ms at
>>>> 60Hz).
>>>>
>>>> Like if the onscreen stats were "dropping" when the application doesn't
>>>> keep 60Hz.
>>>> I don't tweak the render code in any way, just a regular osg loop with
>>>> some custom code in between osg calls.
>>>>
>>>>
>>>> Side note:
>>>> the draw time shown in the stats almost always fills up the frame time
>>>> when using threading scheme other than SingleThreaded,
>>>> even if the drawing thread has little to do.
>>>> SingleThreaded scheme does not suffer the same issue (see attached
>>>> screenshot, simple osgviewer).
>>>> I presume this is due to OS + driver combination,
>>>> I'm on Win7 64bits + nVidia 970 GTX.
>>>>
>>>> Thank you,
>>>> Ricky
>>>>
>>>>
>>>> On Wed, Nov 18, 2015 at 4:46 PM, Robert Osfield <
>>>> robert.osfi...@gmail.com> wrote:
>>>>
>>>>> On 18 November 2015 at 15:14, Riccardo Corsi <
>>>>> riccardo.co...@kairos3d.it> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> in my project I'm using s

Re: [osg-users] user stats update

[Riccardo Corsi]

Hi Robert,

with "flickering" I mean that the labels of my custom stats lines are
always showing,
while the numeric value besides them disappear in some frames.
They apparently disappear under the conditions explained in my previous
email.
This is true only for my custom stats, and not the default one updated by
osg.
(with vsync disabled things improve, but sometimes the issue is still
visible).

I might try to reproduce the issue with a heavy enough osg model loaded in
the osguserstats example.

As for the draw, disabling the vsync dramatically reduces the draw time
shown in the stats.
Should I live with this blocking behavior when vsync is on?
The only drawback is a "fake" (and misleading) stats or there are real
performance penalties?

Thanks,
Ricky

On Wed, Nov 18, 2015 at 6:28 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Ricky,
>
> When you mean flickering, could it simply be that the frame timing stats
> is jumping between two extremes on alternate frames.
>
> In certain circumstances the driver can block and draw dispatch times can
> suddenly go up massively even though that actual system shouldn't be
> overloaded.  In the example you show this is happening. It could possibly
> be something else on the OSG side that is blocking.
>
> As a sanity test try disabling vsync as this can change the behaviour of
> the driver w.r.t blocking.
>
> Robert.
>
> On 18 November 2015 at 16:20, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
>
>> Hi Robert,
>>
>> yes for the flickering I refer to the stats on screen.
>>
>> Here's what I've noticed:
>> - I place my stats update between event and update traversal
>> - the flickering appears when I use threading models other than
>> singleThreaded (typically the default DrawThreadPerContext one)
>> AND the cull+draw time hits the frame duration time (around 16ms at
>> 60Hz).
>>
>> Like if the onscreen stats were "dropping" when the application doesn't
>> keep 60Hz.
>> I don't tweak the render code in any way, just a regular osg loop with
>> some custom code in between osg calls.
>>
>>
>> Side note:
>> the draw time shown in the stats almost always fills up the frame time
>> when using threading scheme other than SingleThreaded,
>> even if the drawing thread has little to do.
>> SingleThreaded scheme does not suffer the same issue (see attached
>> screenshot, simple osgviewer).
>> I presume this is due to OS + driver combination,
>> I'm on Win7 64bits + nVidia 970 GTX.
>>
>> Thank you,
>> Ricky
>>
>>
>> On Wed, Nov 18, 2015 at 4:46 PM, Robert Osfield <robert.osfi...@gmail.com
>> > wrote:
>>
>>> On 18 November 2015 at 15:14, Riccardo Corsi <riccardo.co...@kairos3d.it
>>> > wrote:
>>>
>>>> Hi all,
>>>>
>>>> in my project I'm using some custom statistics as in the
>>>> osguserstats.cpp example.
>>>>
>>>> In the example, user stats are updated every frame between advance()
>>>> and eventTraversal().
>>>>
>>>> In my case, I was trying to update my stats between eventTRaversal()
>>>> and updateTraversal(), where I already execute some other code.
>>>>
>>>> But by doing so, stats do not always show up correctly - sometimes they
>>>> "flicker" and do not show.
>>>> Is the one used in the example the only one safe place to update user
>>>> stats?
>>>>
>>>
>>> The osg::Stats object that is used for recording stats uses a mutex
>>> internally to make sure that setting and getting stats is thread safe.
>>> osg::Stats itself is just a container object though it doesn't do any
>>> rendering so itself can't "flicker".
>>>
>>> When you say flicker I presume we are talking about onscreen stats.  I
>>> haven't seen reports of them flickering before.  Perhaps your usage model
>>> trips up the rendering code in some way.  What threading model are you
>>> running the viewer with?  Can you modify an OSG example to reproduce the
>>> issue?
>>>
>>> Robert.
>>>
>>>
>>>
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] user stats update

[Riccardo Corsi]

Hi all,

in my project I'm using some custom statistics as in the osguserstats.cpp
example.

In the example, user stats are updated every frame between advance() and
eventTraversal().

In my case, I was trying to update my stats between eventTRaversal() and
updateTraversal(), where I already execute some other code.

But by doing so, stats do not always show up correctly - sometimes they
"flicker" and do not show.
Is the one used in the example the only one safe place to update user stats?

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

Re: [osg-users] Cameras with same target and different near/far

[Riccardo Corsi]

Hi all,

sorry to revamp again my own thread, I'd just like to understand if there's
something I'm missing or if the issue I'm facing is an expected behavior.

So simplify even further my question, I sum it up as follows:
I want to render a scene from within a car. I want to use 2 different
cameras, one for the outside world, and one for the car internals, to
optimize near/far ratio for each of them.
I attach the outside scene under the main camera.
Then I have a camera setup as follows to render the car internals.

   osg::Camera* carCam = new osg::Camera;
   // draw subgraph after main camera
   carCam->setRenderOrder(osg::Camera::POST_RENDER, 1);
   // clear depth only
   carCam->setClearMask(GL_DEPTH_BUFFER_BIT);
   // force near/far values for the car camera

 carCam->setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR);
   carCam->setProjectionMatrixAsPerspective(fov, ar, 0.1, 10);
   // render the user vehicle
   carCam->addChild(carInternalModel);

Now:
- if I add the car camera as viewer's slave, everything works as expected,
near/far is fixed and independent from the main camera
- if I place the car camera in scene, cull settings are overwritten, and
near/far is inherited from the main camera no matter what

Is this the expected behavior?
Thank you,
Ricky



On Mon, Sep 14, 2015 at 11:37 AM, Riccardo Corsi <riccardo.co...@kairos3d.it
> wrote:

> Hi all,
>
> sorry to revamp my own thread, but I'm facing again the same problem I
> explained in the first post and couldn't find a correct setup.
> Any hint?
> thanks,
> ricky
>
>
>
> On Fri, Jul 10, 2015 at 5:46 PM, Riccardo Corsi <
> riccardo.co...@kairos3d.it> wrote:
>
>> Hi all,
>>
>> what I'm after is a sort of simple depth peeling, the aim is to render 2
>> different parts of a whole scene with different near/far settings to the
>> same render target. Something like:
>>
>> * mainCamera (render the huge surrounding scene)
>> |
>> |-- huge scene
>> |
>> |-- detailCamera (render a closer object in detail with small z near/far)
>>   |
>>   |-- detailed geometry
>>
>>
>> I thought the best option was to place the detailCamera in scene, to
>> share the render target, and:
>> - set a custom near/far settings
>> - set the clear depth bit
>> - set the render order to post (or nested?)
>> but I couldn't get it to work.
>>
>> I'm particular I have some doubts:
>> 1. does a PRE/POST and a NESTED ORDER camera have the same behavior with
>> respect to sharing the mainCamera render target, when placed in-scene under
>> it?
>> 2. for point 1, does anything change if mainCamera renders to the Frame
>> Buffer or to and FBO?
>> 3. is there any other/more correct way to get 2 cameras to render to the
>> same FBO with different near/far settings?
>>
>> Thank you!
>> Ricky
>>
>>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] event callback after viewer is done

[Riccardo Corsi]

Hi Robert,

I see your point, nevertheless do you think that either:
- having the event callback called with an "about-to-exit" event
- having a custom callback to added and called by the viewer right before
exiting

would be a sensible addition to osg?

Thanks.
ricky



On Wed, Oct 7, 2015 at 10:17 AM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Ricky,
>
> I don't have any suggestion for an alternate design as I still really know
> enough about ImGui.  My suggestion would be to look closely at the crash
> and why it's happening.
>
> Requiring different calls to be be done in a particular order is not
> unusual but having things crash when one traversal isn't followed by
> another suggests a problem somewhere in the design/implementation.
>
> Robert.
>
> On 7 October 2015 at 08:50, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
>
>> Hi Robert,
>>
>> what I'm trying to do is integrating the ImGui framework and render it
>> natively through osg primitives.
>> This gui works in immediate mode, meaning you have to call the code to
>> create your widgets every frame,
>> which is what I do in the custom code in the frame loop (as this changes
>> for every application).
>> All the rest is handled in custom callbacks attached to some nodes.
>>
>> Basically, ImGui needs these things to happen in order at every frame
>> 1. getting inputs (done in the event callback )
>> 2. call to NewFrame() (called on the "FRAME" event, which is the last one
>> received in the event callback)
>> 3. code to create widgets (explicit in the main loop)
>> 4. call to Render() which produces geometries to be rendered by osg (this
>> is done in the update callback)
>>
>> Now, a call to the code that creates widgets (3.) without a proper
>> NewFrame() (2.) causes a crash.
>> When osgViewer is done, I don't get the event callback, and the code
>> which creates the gui crashes.
>>
>> Any suggestion for an alternative design?
>>
>> Thank you,
>> Ricky
>>
>>
>>
>> On Tue, Oct 6, 2015 at 8:56 PM, Robert Osfield <robert.osfi...@gmail.com>
>> wrote:
>>
>>> Hi Ricky,
>>>
>>> I don't know what is in your event callback but for exit to cause a
>>> crash it sounds like something is probably not being managed robustly.  As
>>> I know so little I can't provide any specific advice.
>>>
>>> One possibility might be to call viewer.eventTravseral() after the main
>>> rendering loop.  I can't help be feel there is something amiss in the way
>>> your are managing your event callback and it's associated faculties, and
>>> suspect a small redesign could probably resolve the issue.
>>>
>>> Robert.
>>>
>>> On 6 October 2015 at 18:03, Riccardo Corsi <riccardo.co...@kairos3d.it>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have an event callback which needed to be called before some custom
>>>> code I call in the main application loop, something like:
>>>>
>>>> while()
>>>> {
>>>> viewer.eventTraversal();  // << needed callback here
>>>>
>>>> // custom code
>>>> // prepare stuff to be drawn during next frames
>>>>
>>>> viewer.updateTraversal();
>>>> // ...
>>>> }
>>>>
>>>> When the viewer is about to exit, the event callbacks are not called.
>>>> In my case the callback is needed instead,
>>>> not to cause a segfault to the custom code between osg calls.
>>>>
>>>> The obvious solution is to place the callback directly in the main loop,
>>>> but I'd like to avoid that
>>>> (to keep it more "transparent", as it's a kind of framework to be used
>>>> in several applications).
>>>>
>>>> Have you got any suggestion?
>>>> Thank you!
>>>> Ricky
>>>>
>>>> ___
>>>> osg-users mailing list
>>>> osg-users@lists.openscenegraph.org
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>>
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] event callback after viewer is done

[Riccardo Corsi]

Hi Robert,

what I'm trying to do is integrating the ImGui framework and render it
natively through osg primitives.
This gui works in immediate mode, meaning you have to call the code to
create your widgets every frame,
which is what I do in the custom code in the frame loop (as this changes
for every application).
All the rest is handled in custom callbacks attached to some nodes.

Basically, ImGui needs these things to happen in order at every frame
1. getting inputs (done in the event callback )
2. call to NewFrame() (called on the "FRAME" event, which is the last one
received in the event callback)
3. code to create widgets (explicit in the main loop)
4. call to Render() which produces geometries to be rendered by osg (this
is done in the update callback)

Now, a call to the code that creates widgets (3.) without a proper
NewFrame() (2.) causes a crash.
When osgViewer is done, I don't get the event callback, and the code which
creates the gui crashes.

Any suggestion for an alternative design?

Thank you,
Ricky



On Tue, Oct 6, 2015 at 8:56 PM, Robert Osfield <robert.osfi...@gmail.com>
wrote:

> Hi Ricky,
>
> I don't know what is in your event callback but for exit to cause a crash
> it sounds like something is probably not being managed robustly.  As I know
> so little I can't provide any specific advice.
>
> One possibility might be to call viewer.eventTravseral() after the main
> rendering loop.  I can't help be feel there is something amiss in the way
> your are managing your event callback and it's associated faculties, and
> suspect a small redesign could probably resolve the issue.
>
> Robert.
>
> On 6 October 2015 at 18:03, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
>
>> Hi all,
>>
>> I have an event callback which needed to be called before some custom
>> code I call in the main application loop, something like:
>>
>> while()
>> {
>> viewer.eventTraversal();  // << needed callback here
>>
>> // custom code
>> // prepare stuff to be drawn during next frames
>>
>> viewer.updateTraversal();
>> // ...
>> }
>>
>> When the viewer is about to exit, the event callbacks are not called.
>> In my case the callback is needed instead,
>> not to cause a segfault to the custom code between osg calls.
>>
>> The obvious solution is to place the callback directly in the main loop,
>> but I'd like to avoid that
>> (to keep it more "transparent", as it's a kind of framework to be used in
>> several applications).
>>
>> Have you got any suggestion?
>> Thank you!
>> Ricky
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] event callback after viewer is done

[Riccardo Corsi]

Hi all,

I have an event callback which needed to be called before some custom code
I call in the main application loop, something like:

while()
{
viewer.eventTraversal();  // << needed callback here

// custom code
// prepare stuff to be drawn during next frames

viewer.updateTraversal();
// ...
}

When the viewer is about to exit, the event callbacks are not called.
In my case the callback is needed instead,
not to cause a segfault to the custom code between osg calls.

The obvious solution is to place the callback directly in the main loop,
but I'd like to avoid that
(to keep it more "transparent", as it's a kind of framework to be used in
several applications).

Have you got any suggestion?
Thank you!
Ricky
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Oculus+OSG+PostProcess

[Riccardo Corsi]

Hi Björn and all,

I'd like to test an application on the Oculus with some post-process effect.

On the Oculus side, the only recommendation I've read (
https://developer.oculus.com/documentation/intro-vr/latest/concepts/bp_intro/
)
is to apply the post effect to both eyes independently (taking into account
their z-depth).

On the osg integration side, I see these points to be covered:
1. setup a scene with some post-processing cameras which is compatible with
the 2-slaves cameras setup done by the OculusViewer
2. the post effect should probably affect only the color buffer copied to
the Oculus, while the depth buffer (used for the time warp) should be the
one written by the main render camera with the actual 3d scene values.

I'm not sure which would be the best scheme to achieve that.
In particular, it would be good to keep the current slave cameras setup
with respect to projection and view matrices, but move the buffer
management to the latest stage camera of the post-processing.

What do you think?
I'd like to help in coding/testing a solution.
Ricky
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Riccardo Corsi]

Hi Björn,

first of all thank you for keeping up to date the Oculus integration!

I have just updated to SDK 0.7 + osgOculus head and the viewer works, but:

1. while the provided Oculus demos are really smooth with respect to
motion,
the osg viewer example results quite jerky, especially the rotation of the
head causes a sort of "hiccup"
during the motion

2. when using the osg viewer example, the right eye monitor has some
flickering every second or so,
a part of the screen becomes black/corrupted for some frames.

Have you ever noticed such behaviors?
Have you got any suggestion to fix them?

Thank you,
Ricky

On Wed, Sep 9, 2015 at 1:46 PM, Björn Blissing 
wrote:

> Hi,
>
> I just fixed a performance related bug.
>
> Due to misuse of an enum I had accidentally disabled all culling. (This
> bug would probably been avoided if strongly typed enum a'la C++11 were
> used).
>
> This bug only affects users using Oculus SDK 0.6 and 0.7. I urge all users
> of these versions of OsgOculusViewer to update to the head revision on
> GitHub.
>
> Best regards,
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65077#65077
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Oculus+OSG

[Riccardo Corsi]

Hi all,

thanks Björn for the MSAA pointer - it was not the cause of the issue but
the explanation on the 75Hz helped me solve the problem:
I had to remove the V-sync setting from the driver configuration.

Works like a charm now :)

So to keep a smooth experience the osg application must be able to render
at 75Hz for both eyes - is that correct?
This is an important tip to keep in mind...

I also have some questions about post-process but I'll switch to a
different thread.
Thanks again!
Ricky


On Fri, Sep 25, 2015 at 11:09 AM, Björn Blissing 
wrote:

> Hi Ricky,
>
> We have recently added support for MSAA in the OsgOculus integration
> (credits to Chris Denham). Rendering with MSAA enabled will require some
> extra GPU horse power and is probably the reason you see the stuttering in
> the rendering. If you look at the performance HUD (by pressing '2' on the
> keyboard), you will see what frame rate the compositor is working with.
> Anything under 75fps will cause stutter (on the DK2) and the performance
> HUD will report by incrementing the value: "Compositor Missed V-Sync Count".
>
> To disable the MSAA change this line to a zero (or you could try to lower
> the amount to 2 and see if that helps):
>
> https://github.com/bjornblissing/osgoculusviewer/blob/d0c425d3eda01b8134518ef524906e736a6aed9b/src/viewerexample.cpp#L50
>
> This is probably also related to the flickering you are seeing.
>
> Best regards
> Björn
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65210#65210
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cameras with same target and different near/far

[Riccardo Corsi]

Hi all,

sorry to revamp my own thread, but I'm facing again the same problem I
explained in the first post and couldn't find a correct setup.
Any hint?
thanks,
ricky



On Fri, Jul 10, 2015 at 5:46 PM, Riccardo Corsi <riccardo.co...@kairos3d.it>
wrote:

> Hi all,
>
> what I'm after is a sort of simple depth peeling, the aim is to render 2
> different parts of a whole scene with different near/far settings to the
> same render target. Something like:
>
> * mainCamera (render the huge surrounding scene)
> |
> |-- huge scene
> |
> |-- detailCamera (render a closer object in detail with small z near/far)
>   |
>   |-- detailed geometry
>
>
> I thought the best option was to place the detailCamera in scene, to share
> the render target, and:
> - set a custom near/far settings
> - set the clear depth bit
> - set the render order to post (or nested?)
> but I couldn't get it to work.
>
> I'm particular I have some doubts:
> 1. does a PRE/POST and a NESTED ORDER camera have the same behavior with
> respect to sharing the mainCamera render target, when placed in-scene under
> it?
> 2. for point 1, does anything change if mainCamera renders to the Frame
> Buffer or to and FBO?
> 3. is there any other/more correct way to get 2 cameras to render to the
> same FBO with different near/far settings?
>
> Thank you!
> Ricky
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt5 integration

[Riccardo Corsi]

Hi James,

sorry for the late reply!
Please, feel free to review and merge my code, let me know if you need
clarifications.

Ricky

On Mon, Aug 24, 2015 at 4:03 PM, James Turner <zakal...@mac.com> wrote:

>
> On 17 Aug 2015, at 17:33, Riccardo Corsi <riccardo.co...@kairos3d.it>
> wrote:
>
>
> Thanks Ricky.
>
> From my point of view the most desired feature is to be able to integrate
> a qt scene (a GUI layout or a browser/pdf/svg viewer widget) inside an osg
> driven application smoothly - i.e. without the need of a Qt application to
> run as main thread loop, but hiding it as a "slave" somewhere in an osg
> module/node, to make those widget pluggable in a "regular" osg application.
>
>
>
> As someone else pointed out, this is a less common scenario for what I’m
> trying to support. What I care more about is people who want to use Qt for
> the thing it’s good at, and integrate OSG within it. So they typically want
> menus, dialogs etc from QWidgets or QQ2 (potentially including Qt Quick
> Controls). That’s the use case I’m focusing on for now.
>
> Hiding Qt introduces a lot of complexity and also trades that rather
> detailed, tailored Qt event loops on each platform, for the rather basic
> ones in each of the GraphicsWindow subclasses.
>
> Instead if you're interested, a while ago I coded an integration to render
> with osg inside a QtQuick+QML application.
> Basically the solution implements a custom QtQuick node which renders an
> osgViewer scene to an FBO, and then copies the FBO contents back to the Qt
> context, to make it available in the qt/qml scenegraph which renders the
> widgets.
> The osgQuickNode uses a separate OpenGL context, not to interfere with the
> one used by Qt for its own scene rendering.
> All the code is here: https://github.com/rickyviking/qmlosg
> If you have questions about the implementation feel free to write me.
>
>
> The solution you propose of a custom QtQuick node rendering OSG is
> definitely interesting to me, and I would guess your code is likely 90% the
> same as what I would write, so with your permission I might attempt to
> merge it with my submission, once I have time to review it.
>
> Kind regards,
> James
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Qt5 integration

[Riccardo Corsi]

Hi Werner,

no problem, I was just sharing some use cases.

Regarding the embedding use case you mention, if that is QtQuick/qml based,
you're most welcome to take a look to the implementation I mentioned in my
previous email, hopefully that might helpful for your development.

Cheers,
Ricky

On Mon, Aug 17, 2015 at 6:54 PM, Werner Modenbach 
werner.modenb...@texion.eu wrote:

 Hi Ricky,
 I understand your point of view here. But I think there are multiple use
 cases.
 If I understand your approach well you intend having a 3d rendering app
 with some nice qt based features.
 On the other hand we are developing a lot of software in the textile
 environment and 3d simulation of the fabric is just an optional add-on. So
 the main aspect in our case is having a geometry managed embedded window
 showing an ist scene.
 So for us James's contribution is just what we need.
 As I said before, there are many scenarios for interacting qt and osg.


 On 17. August 2015 18:33:46 MESZ, Riccardo Corsi 
 riccardo.co...@kairos3d.it wrote:

 Hi James,

 I haven't looked into osg+qt integration since a while so I might not be
 aware of the latest features available.

 From my point of view the most desired feature is to be able to integrate
 a qt scene (a GUI layout or a browser/pdf/svg viewer widget) inside an osg
 driven application smoothly - i.e. without the need of a Qt application to
 run as main thread loop, but hiding it as a slave somewhere in an osg
 module/node, to make those widget pluggable in a regular osg application.

 Instead if you're interested, a while ago I coded an integration to
 render with osg inside a QtQuick+QML application.
 Basically the solution implements a custom QtQuick node which renders an
 osgViewer scene to an FBO, and then copies the FBO contents back to the Qt
 context, to make it available in the qt/qml scenegraph which renders the
 widgets.
 The osgQuickNode uses a separate OpenGL context, not to interfere with
 the one used by Qt for its own scene rendering.
 All the code is here: https://github.com/rickyviking/qmlosg
 If you have questions about the implementation feel free to write me.

 Ricky

 On Mon, Aug 17, 2015 at 12:54 PM, Robert Osfield 
 robert.osfi...@gmail.com wrote :

 HI Alistair,

 I'm not familiar with Qt5/QQuck2 so can't comment on the Qt side, so
 have to defer to others on this.

 On the OSG side osgViewer is designed specifically to handle a thread
 per graphics context/window - it's a core feature of how
 osg::GraphicsContext, osg::GraphicsThread are designed and implemented.  If
 Qt5 requires a thread per window then this is a model that osgViewer can be
 capable of handling since it's inception (well before Qt5), the only
 question would be to how to integrate the threading in synchronization
 operations that Qt5 is forcing upon the set up with the way that the OSG
 manages things.  Perhaps subclassing from osg::GraphicsThread might be one
 approach or other classes.

 I don't know if the other direction might be possible - stop Qt trying
 to do eve rything that the OSG can already do perfectly without it.

 Robert.

 On 17 August 2015 at 09:48, Alistair Baxter alist...@mve.com wrote:

 As you are no doubt aware, James, we've been looking into this sort of
 integration ourselves. QQuick 2 integration is part of our goal, although
 we hadn't been planning direct interaction between QML and out osg scenes,
 since we have a separate data model. Although if such a thing existed, and
 were sufficiently convenient to use, then we might be interested in
 integrating it in a similar way to how we use the existing 3D osg
 manipulators. We've never really been interested in QWidgetImage, we only
 ever used it to try and get round a window composition issue on OSX.

 Our main concern at the moment is that we need a multi-window viewer.
 Due to the way Qt 5 has a separate opengl render thread per Window, this
 has meant reimplementing a significant chunk of OSGCompositeViewer in order
 to get it to work at all, and we are discovering a variety of
 thread-synchronisation issues.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org

 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



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


 --

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


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


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

Re: [osg-users] Qt5 integration

[Riccardo Corsi]

Hi James,

I haven't looked into osg+qt integration since a while so I might not be
aware of the latest features available.

From my point of view the most desired feature is to be able to integrate a
qt scene (a GUI layout or a browser/pdf/svg viewer widget) inside an osg
driven application smoothly - i.e. without the need of a Qt application to
run as main thread loop, but hiding it as a slave somewhere in an osg
module/node, to make those widget pluggable in a regular osg application.

Instead if you're interested, a while ago I coded an integration to render
with osg inside a QtQuick+QML application.
Basically the solution implements a custom QtQuick node which renders an
osgViewer scene to an FBO, and then copies the FBO contents back to the Qt
context, to make it available in the qt/qml scenegraph which renders the
widgets.
The osgQuickNode uses a separate OpenGL context, not to interfere with the
one used by Qt for its own scene rendering.
All the code is here: https://github.com/rickyviking/qmlosg
If you have questions about the implementation feel free to write me.

Ricky

On Mon, Aug 17, 2015 at 12:54 PM, Robert Osfield robert.osfi...@gmail.com
wrote:

 HI Alistair,

 I'm not familiar with Qt5/QQuck2 so can't comment on the Qt side, so have
 to defer to others on this.

 On the OSG side osgViewer is designed specifically to handle a thread per
 graphics context/window - it's a core feature of how osg::GraphicsContext,
 osg::GraphicsThread are designed and implemented.  If Qt5 requires a thread
 per window then this is a model that osgViewer can be capable of handling
 since it's inception (well before Qt5), the only question would be to how
 to integrate the threading in synchronization operations that Qt5 is
 forcing upon the set up with the way that the OSG manages things.  Perhaps
 subclassing from osg::GraphicsThread might be one approach or other classes.

 I don't know if the other direction might be possible - stop Qt trying to
 do everything that the OSG can already do perfectly without it.

 Robert.

 On 17 August 2015 at 09:48, Alistair Baxter alist...@mve.com wrote:

 As you are no doubt aware, James, we've been looking into this sort of
 integration ourselves. QQuick 2 integration is part of our goal, although
 we hadn't been planning direct interaction between QML and out osg scenes,
 since we have a separate data model. Although if such a thing existed, and
 were sufficiently convenient to use, then we might be interested in
 integrating it in a similar way to how we use the existing 3D osg
 manipulators. We've never really been interested in QWidgetImage, we only
 ever used it to try and get round a window composition issue on OSX.

 Our main concern at the moment is that we need a multi-window viewer. Due
 to the way Qt 5 has a separate opengl render thread per Window, this has
 meant reimplementing a significant chunk of OSGCompositeViewer in order to
 get it to work at all, and we are discovering a variety of
 thread-synchronisation issues.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



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


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

[osg-users] Cameras with same target and different near/far

[Riccardo Corsi]

Hi all,

what I'm after is a sort of simple depth peeling, the aim is to render 2
different parts of a whole scene with different near/far settings to the
same render target. Something like:

* mainCamera (render the huge surrounding scene)
|
|-- huge scene
|
|-- detailCamera (render a closer object in detail with small z near/far)
  |
  |-- detailed geometry


I thought the best option was to place the detailCamera in scene, to share
the render target, and:
- set a custom near/far settings
- set the clear depth bit
- set the render order to post (or nested?)
but I couldn't get it to work.

I'm particular I have some doubts:
1. does a PRE/POST and a NESTED ORDER camera have the same behavior with
respect to sharing the mainCamera render target, when placed in-scene under
it?
2. for point 1, does anything change if mainCamera renders to the Frame
Buffer or to and FBO?
3. is there any other/more correct way to get 2 cameras to render to the
same FBO with different near/far settings?

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

[osg-users] Incremental GL compile

[Riccardo Corsi]

Hi all,

for a project I'm loading a scene which fits into system memory but most
likely not in video memory.
I prefer to load the whole scene at startup to run some pre-processing on
the scene elements.

What I'm after is then to dynamically precompile/release GL objects at
runtime for different elements of the scene - I want them precompiled
before merging into the visible scene to avoid frame drops.

The way I'm doing it right now is:
- when adding element, I push them into an
osgUtil::IncrementalCompileOperation. When compiled I merge them into the
visible scenegraph
- when removing, I simply detach the nodes

Is this a correct approach?

In particular, is it correct NOT to release explicitly the GL objects when
removing the nodes?
From what I've read in the archives, osg should do it automatically at an
appropriate time...

Other hints are welcome :)
Thanks,
ricky
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Incremental GL compile

[Riccardo Corsi]

Good to know then - my tests so far show a correct and solid behavior.
Thanks Robert,

ricky


On Tue, Jun 17, 2014 at 12:15 PM, Robert Osfield robert.osfi...@gmail.com
wrote:

 HI Ricky,

 Your approach sounds correct.  You are correct in that the user
 doesn't need to explicitly for the release of GL objects as the OSG
 will pass the GL objects across to the OSG's internal object cache to
 be release by automatically by the draw thread.  Reuse of GL objects
 will also happen automatically for you.

 Robert.

 On 17 June 2014 11:07, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
  Hi all,
 
  for a project I'm loading a scene which fits into system memory but most
  likely not in video memory.
  I prefer to load the whole scene at startup to run some pre-processing on
  the scene elements.
 
  What I'm after is then to dynamically precompile/release GL objects at
  runtime for different elements of the scene - I want them precompiled
 before
  merging into the visible scene to avoid frame drops.
 
  The way I'm doing it right now is:
  - when adding element, I push them into an
  osgUtil::IncrementalCompileOperation. When compiled I merge them into the
  visible scenegraph
  - when removing, I simply detach the nodes
 
  Is this a correct approach?
 
  In particular, is it correct NOT to release explicitly the GL objects
 when
  removing the nodes?
  From what I've read in the archives, osg should do it automatically at an
  appropriate time...
 
  Other hints are welcome :)
  Thanks,
  ricky
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] [build] error in moc_QGraphicsViewAdapter.cpp

[Riccardo Corsi]

Hi Remy,

same issue here.
My config is osg 3.2.0, qt 5.3-beta, all built 32bit with VS2013.

I had to use the patched version of CMake provided here:
https://groups.google.com/forum/#!msg/osg-users/LoSdfK9pyOU/SOg9N1V1xXsJ
and manually add the include file that you mention (thx!)

Ricky


On Sun, Jan 19, 2014 at 12:22 AM, Remi Thebault remi.theba...@gmail.comwrote:

 Hi,

 I built smoothly OSG-3.2 with Qt-5.2 and MingW 4.8 (as provided by Qt)
 except when it comes to osgQt.

 for some reason the moc generated file

 Code:
 src\osgQt\__\__\include\osgQt\moc_QGraphicsViewAdapter.cpp


 is missing the include directive at the top of the file

 Code:
 #include osgQt/QGraphicsViewAdapter



 Strange, because in my personal projects, this never occurred.

 Had anyone this problem?

 Anyway, adding the directive manually solves the issue.



 Cheers,
 Remi

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





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

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

Re: [osg-users] osgQt build error

[Riccardo Corsi]

Hi Alexey,

to build osgQt library with osg using full OpenGL,
you need to use the full OpenGL version of Qt as well.

Qt built with ANGLE expects OpenGL-ES compliant code.
If you want to use ANGLE version, I guess you should be fine if you compile
osg with ES flag as well - I never tried this path though.

ricky


On Wed, Apr 16, 2014 at 10:00 AM, Alexey Pavlov alex...@gmail.com wrote:

 Hi!

 I can't build OSG with Qt builded with ANGLE under Windows using
 Mingw-w64 toolchain. I get conflict types between ANGLE and OpenGL
 headers:
 http://pastebin.kde.org/pitat7w4x

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

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

Re: [osg-users] [ANN] 3rdParty Package released for Visual Studio 2012 Update 1 (v110)

[Riccardo Corsi]

Hi Torben,

thanks for the dependencies package!
I built successfully osg-3.1.5 (32 bit) with VC 2012 except for a little
tweak:
I had to replace the zconf.h file you provide in the package with the
original one shipped with zlib.
For some reasons you version adds the line:
#define Z_HAVE_UNISTD_H
and VS doesn't like it.

Besides that, everything run smooth.
Thanks again!
Ricky


On Sun, Jul 14, 2013 at 7:00 PM, Torben Dannhauer tor...@dannhauer.infowrote:

 Hello dear OSG-community,

 after a long time of absence, I am pleased to present you my updated
 3rdParty Package for OpenSceneGraph.

 It is compiled with Visual Studio 2012 Update 3 in 32 and 64 bit and uses
 platform toolset v110. Therefore it is not compatible with Windows XP,
 please use Windows Vista and above for this package.

 Some community members asked me years ago to spilt this package into
 several parts since it is quite large and not everybody uses all libraries.
 This updated package (V8) is released in 2 flavors: small and full. For a
 list of content and further details, please visit
 http://www.osgvisual.org/projects/osgvisual/wiki/Downloads .

 You can download it at
 http://www.openscenegraph.org/index.php/download-section/dependencies
 or directly at http://www.osgvisual.org/projects/osgvisual/wiki/Downloads.

 If you have further questions, please don't hesitate to contact me.

 Best regards,
 Torben

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





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

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

Re: [osg-users] qmlosg (QtQuick + osg integration)

[Riccardo Corsi]

Hi René,

sorry I forgot to reply my own thread when I found the solution.
I was simply missing a glFlush() call after rendering the osg frame in its
own gl context!
I still haven't update the code on github, will do it tonight.

Cheers,
ricky



On Fri, Jul 5, 2013 at 10:19 AM, René Schmitz r...@biosolveit.de wrote:

 Hi,

 after trying to create a osgQML item myself and finding both of your
 projects, I thought I'd let you know that I ended up using
 QuickPaintedItem as it can draw to a FBO (I had to use the y-inverted one).

 This solution works charming and spares me the hussle of creating FBOs
 myself or switch contexts. I have to admit though that I don't need
 permanent updates of the scene, just reacting to mouse and keyboard
 events and that there might be a drawback in performance if the scene is
 updated permanently using a timer. For that maybe the textureinthread
 example coming with the Qt sources might offer a better way.

 Hope that helps.

 Cheers,
   René

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





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

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

Re: [osg-users] qmlosg (QtQuick + osg integration)

[Riccardo Corsi]

Hi Preet,

thanks for the hints.
From what I've seen you render to the FBO by using
the QOpenGLFramebufferObject class,
instead of setting up the osg camera for rendering to FRAME_BUFFER_OBJECT
as target.

I'll try the same approach with the context switch and see if that helps.
Ricky


On Sat, Jun 1, 2013 at 8:10 AM, Preet prismatic.proj...@gmail.com wrote:

 Hi Riccardo,

 I can't speak to the specific slow down you're encountering with context
 switches. I tried to solve a similar problem (osg in qt quick) but I don't
 use context switching -- I could never figure out how to get that to work
 correctly so I'll have to go through what you did carelfully :)

 Have you checked out the following docs:


 http://doc-snapshot.qt-project.org/qt5-dev/qtquick/qtquick-visualcanvas-scenegraph.html

 http://doc-snapshot.qt-project.org/qt5-dev/qtquick/quick-scenegraph-textureinsgnode.html

 http://doc-snapshot.qt-project.org/qt5-dev/qtquick/quick-scenegraph-textureinthread.html

 And here's my attempt [copy of the method used in the docs but with an osg
 embedded viewer and *no* context switching -- I just reset some specific
 state]

 https://github.com/preet/scratch/tree/master/qt5/qquickfboviewport

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


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

Re: [osg-users] Change Camera FBO attachment

[Riccardo Corsi]

Hi Robert,

thanks for your suggestion.

The reason I went for a slave camera is that it makes it easier to add the
FBO path at a later point, without touching the scenegraph,
as it inherits the viewer's scene data by default.

Besides inserting the cameras subgraph into the main graph,
do you think it's reasonable to attach the FBO cameras group as the
subgraph of a fake slave camera,
and attach the main scene also as FBO camera child?
I draw a little graph below for clarity.

Thank you,
Ricky


VIEWER
   /  \
MAIN CAM SLAVE_CAM
 |   |
 |   |
 |switch
 |   |
 | / | \
  |/  |  \
 | fbo1 fbo2 fbo3
 | /   /   /
  \   /   /   /
   \ /   /   /
\   /   /   /
 | |  /   /
 | | /   /
  SCENE



On Tue, Dec 18, 2012 at 9:25 PM, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Riccardo,

 Setting up the camera's rendering backend on each frame will be
 expensive.  Personally I'd just using multiple RTT Camera each with their
 own FBO and Textures associated with them.  Using a Switch, Sequence or
 NodeMask's you can select which of the Camera you want to render to on each
 frame.

 Robert.

 On 18 December 2012 17:24, Riccardo Corsi riccardo.co...@kairos3d.itwrote:

 Hi All,

 in my application I need an FBO camera to render different frames into
 different textures, because they will be used by an encoder and thus need
 to persist for some time.

 I haven't found an easy way to copy the contents of a texture or of an
 FBO into another texture.
 So during the update traversal I change the camera texture attachment
 with a new texture and call Renderer::SetCameraRequiresSetUp(true).

 Eveything works fine, but I'm wondering if there's a better/cleaner
 approach to achieve the same result, as I don't know whether requesting
 the camera setup every frame has a huge impact on perfomances.

 Thank you,
 Ricky


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



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


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

[osg-users] Change Camera FBO attachment

[Riccardo Corsi]

Hi All,

in my application I need an FBO camera to render different frames into
different textures, because they will be used by an encoder and thus need
to persist for some time.

I haven't found an easy way to copy the contents of a texture or of an FBO
into another texture.
So during the update traversal I change the camera texture attachment with
a new texture and call Renderer::SetCameraRequiresSetUp(true).

Eveything works fine, but I'm wondering if there's a better/cleaner
approach to achieve the same result, as I don't know whether requesting the
camera setup every frame has a huge impact on perfomances.

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

Re: [osg-users] Scaling while retaining the center position of the object

[Riccardo Corsi]

Hi Jonathan,

I have done something similar to what you need by writing a custom dragger
callback instead of the standard one assigned to the manipulated objects.
In my case I manually rebuild the the motion matrix to apply to the target
matrix transform, instead of getting the one that the MotionCommand
provides.

An alternative might be writing a custom dragger to dispatch a
UniformScaleCommand, which is the motion type you want, and none of the
provided manipulators sends them.
In that case you can keep using the standard callback, as the command will
provide the correct motion matrix.

Hope this helps,
Ricky


On Tue, Dec 4, 2012 at 3:15 PM, Jonathan McLaughlin jonat...@mve.comwrote:

 Hi,

 I am using a osgManipulator::TabBoxDragger with
 osgManipulator::Scale2DDraggers to scale objects within my scene.

 Currently when dragging one of the 2D Draggers the object will scale
 accordingly but the centre of the object will not stay in the same
 position. For example, if I grab the top left corner of a square and drag
 to the left, the bottom right corner will stay where it is and the rest of
 the object will move left while being rescaled.

 What I would like to happen is for the bottom right corner to move right
 at the same rate as the top left corner moves left, all the while
 maintaining the centre position of the object being scaled

 Effectively, what I want to do is scale while maintaining the proportions
 on the plane I am scaling, however cant find a way to do this.

 Hopefully my explanation is comprehensible and not too long winded. Any
 help on this would be appreciated.

 Thanks

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





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

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

Re: [osg-users] [ANN] osgRecipes: Integrate OSG with almost everything, the second wave

[Riccardo Corsi]

Hi all,

regarding Flash I've seen that somebody successfully integrated OSG to
Hikari,
a library originally written to integrate Flash into Ogre.
Here are related forum topics:
1. http://agelessanime.com/hikari/forum/topic.php?id=72
2. http://agelessanime.com/hikari/forum/topic.php?id=97

Hikari main page is here: http://www.ogre3d.org/tikiwiki/Hikari

Cheers,
Ricky



On Wed, Sep 12, 2012 at 4:56 AM, Wang Rui wangra...@gmail.com wrote:

 Oh, you mean GameSWF. Yes it is in my TODO list. But in fact GameSWF
 doesn't handle AS3 so it may not be enough for Flash UI needs. I was
 interested in Vektrix before, which provides a better framework for
 Flash and AS3 (using Tamarin), but it seems inactivated now.

 Thanks for the notification,

 Wang Rui


 2012/9/12 michael kapelko korn...@gmail.com:
  I've just recalled that there also exist gameswf project which allows
  for Flash UI inside games.
  http://tulrich.com/textweb.pl?path=geekstuff/gameswf.txt
 
  Would be nice to see this one integrated. Would make a lot of hype
  with some easy flash demos :P
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] camera manipulator proposal

[Riccardo Corsi]

Hi Robert,

I agree that the Camera as an argument makes more sense.
Thanks for merging the submission.

Cheers,
Ricky



On Mon, Jul 9, 2012 at 7:38 PM, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Riccardo,

 On review of the submission I've decided that passing in a Camera
 rather than a pointer would make it clear that a valid Camera object
 should be passed in rather than a pointer which could be NULL or
 pointing to a valid Camera object.  This brings the method more into
 line with how this type of method is invoked elsewhere in the OSG.

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

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

Re: [osg-users] Instanced Arrays support

[Riccardo Corsi]

Hi guys,

anyone on this??
I have done some more digging in the code, but wasn't able to find support
for this feature...
Thanks!
Ricky

On Thu, Jun 7, 2012 at 11:48 AM, Riccardo Corsi
riccardo.co...@kairos3d.itwrote:

 Hi all,

 I'm about to implement some instanced rendering in my application and I
 was looking for the best way to pass
 per-instance data to the shaders.

 I've then discovered that besides the Draw Instaced ARB there is another
 extension called Instanced Arrays,
 which basically allows to bind vertex attributes per instance ( or per
 multiple instances, controlled by a divisor attribute)
 instead of per vertex.
 Here is the link to the specs:
 http://www.opengl.org/registry/specs/ARB/instanced_arrays.txt

 I couldn't find how to use this extension with osg. Is there support for
 this functionality?
 Thank you,
 Ricky




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

Re: [osg-users] Depth test and RenderBin details

[Riccardo Corsi]

Hi,

you can also use the TraversalOrderBin which renders children node in the
order they are visited,
and place in the correct order the different dragger primitives in your
subgraph.
Ricky

On Sat, Jun 9, 2012 at 12:00 PM, Sergey Polischuk pol...@yandex.ru wrote:

 Hi

 You may set different render bins to sphere and axis

 Cheers

 08.06.2012, 16:49, Bob Slobodan qgalv...@msn.com:
  Hi guys,
 
  I've been implementing my own dragger (from scratch, I didn't use the
 osg draggers for specific reasons) and I have some problem with the render
 order. Basically my dragger is composed of four sub-draggers :
  - 3 axis dragger (each one composed of a line and a cone)
  - 1 sphere dragger
  The 3 axis dragger and the sphere have the same origin.
 
  The thing is that I want my whole dragger (the 3 axis and the sphere) to
 always be rendered on top of the rest of the scene.
 
  But when I deactivate the depth test and set the RenderBinDetails on my
 main dragger (node that contains the four sub-draggers), the sphere (which
 is the last node to be added to my main dragger) always appears on top of
 the axis.
 
  Is there a way to render my dragger with the depth test between the axis
 and the sphere, and then to display the whole dragger on top of the rest of
 the scene ?
 
  Thank you!
 
  Cheers,
  Bob
 
  --
  Read this topic online here:
  http://forum.openscenegraph.org/viewtopic.php?p=48138#48138
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[osg-users] Instanced Arrays support

[Riccardo Corsi]

Hi all,

I'm about to implement some instanced rendering in my application and I was
looking for the best way to pass
per-instance data to the shaders.

I've then discovered that besides the Draw Instaced ARB there is another
extension called Instanced Arrays,
which basically allows to bind vertex attributes per instance ( or per
multiple instances, controlled by a divisor attribute)
instead of per vertex.
Here is the link to the specs:
http://www.opengl.org/registry/specs/ARB/instanced_arrays.txt

I couldn't find how to use this extension with osg. Is there support for
this functionality?
Thank you,
Ricky
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera manipulator proposal

[Riccardo Corsi]

Hi Robert and All,

I just wanted to know if the proposal I made some weeks ago doesn't seem to
fit some requirements,
or simply passed unnoticed.

Thank you,
Ricky


On Wed, Mar 14, 2012 at 15:42, Riccardo Corsi riccardo.co...@kairos3d.itwrote:

 Hi all,

 sorry that it took long to setup the proposal...
 Eventually the code change was minimal:

 1. added a method void updateCamera(osg::Camera*) on CameraManip base
 class. I propose a default implementation that sets the camera view matrix
 by using the existing getInverseMatrix method, so that standard
 manipulators don't need any change.

 2. viewer classes call the new method instead of setting explicitly the
 camera view matrix, for instance:

 //old call -_camera-setViewMatrix(_cameraManipulator-getInverseMatrix());
 _cameraManipulator-updateCamera(_camera);

 This brings enough flexibility for the cases that I have in mind at the
 moment.

 The changed files are in the attached zip, based on osg 3.1.0.
 If it's better not to provide a default implementation for the new method,
 I can remove it and re-implement it in all derived manipulators.

 If the approach looks reasonable I will make a submission out of it.

 Ricky



 On Tue, Mar 6, 2012 at 17:06, Robert Osfield robert.osfi...@gmail.comwrote:

 HI Ricky,

 On 6 March 2012 14:36, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
  I totally agree on the general approach.
  Still, if you want to go for the change on the  osgGA::CameraManipulator
  base class as a first step,
  I'd be glad to help with that.

 Why not have a bash at modifying osgGA::CameraManipulator to work for
 the purpose you have in mind then post this as proposal, we can then
 tweak this if required.

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



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

Re: [osg-users] camera manipulator proposal

[Riccardo Corsi]

Hi Robert,

I totally agree on the general approach.
Still, if you want to go for the change on the  osgGA::CameraManipulator
base class as a first step,
I'd be glad to help with that.

Ricky

On Tue, Mar 6, 2012 at 11:44, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Riccardo,

 The current osgGA::CameraManipulator's are a bit of mess, the way they
 just control the view matrix is one of their flaws.  I merged a set of
 sweeping changes from Jan Perciva back in May 2010 that added a new
 inheritance hierarchy and more features, but in hindsight I feels
 these have just made them more convoluted in design and
 implementation.

 Rather than tweak the current CameraManilulator API I feel that a
 wholesale review of osgGA and the CameraManipulator is long overdue.
 We have new devices such as multi-touch and MS's Kinect, as well as
 old ones like joysticks that are really not served properly by osgGA.
 We really should try and tie these all together.  Perhaps this should
 be an objective for 3.4.

 In terms of osgGA::CameraManipulator base class I'd like to distil it
 down to it's core functionality - allowing a manipulator to control a
 Camera.  Potentially we could introduce this change prior to the
 wholesale revamp.

 Robert.

 On 5 March 2012 17:35, Riccardo Corsi riccardo.co...@kairos3d.it wrote:
  Hi Robert and All,
 
  in more than one occasion I've noticed that having access to the camera
  manipulator in use is not enough to have full control over the camera
  motion handling.
 
  An example is if you want to temporary disable the manip to set the
 camera
  position explicitly (in this case you need to remove the manipulator from
  the viewer, not to get the position overwritten),
  or if you want to write a manip for an ortho camera, in which case you
 need
  access to the camera's projection matrix as well.
 
  At the same time we need to preserve the loose coupling between the
 camera
  and its manipulator.
 
  I think that a possible approach would be a virtual method in the base
  camera manip like:
  virtual void osgGA::CameraManipulator::UpdateCamera(osg::Camera* pCam)
  to be invoked by the viewer classes.
  Instead of asking the ViewMatrix to the manipulators, they would call
 this
  method passing the reference camera and leaving the matrix assignments to
  the implementation.
 
  Do you think it's a reasonable approach?
  The porting of the existing manipulators to the new interface would be an
  easy task.
 
  Please give me some feedback,
  if you like the approach I can submit a patch.
 
  Thanks,
  Ricky
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[osg-users] camera manipulator proposal

[Riccardo Corsi]

Hi Robert and All,

in more than one occasion I've noticed that having access to the camera
manipulator in use is not enough to have full control over the camera
motion handling.

An example is if you want to temporary disable the manip to set the camera
position explicitly (in this case you need to remove the manipulator from
the viewer, not to get the position overwritten),
or if you want to write a manip for an ortho camera, in which case you need
access to the camera's projection matrix as well.

At the same time we need to preserve the loose coupling between the camera
and its manipulator.

I think that a possible approach would be a virtual method in the base
camera manip like:
virtual void osgGA::CameraManipulator::UpdateCamera(osg::Camera* pCam)
to be invoked by the viewer classes.
Instead of asking the ViewMatrix to the manipulators, they would call this
method passing the reference camera and leaving the matrix assignments to
the implementation.

Do you think it's a reasonable approach?
The porting of the existing manipulators to the new interface would be an
easy task.

Please give me some feedback,
if you like the approach I can submit a patch.

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

[osg-users] FrameStamp on viewer's GUIEventHandler

[Riccardo Corsi]

Hi All,

while checking the code related to event handling,
I've noticed that node callbacks receives a NodeVisitor in their handle()
callback, and can then extract the frameStamp if needed.

The same does not apply to the GUIEventHandler added directly to the
osgViewer classes, as thy are invoked this way:
(*hitr)-handleWithCheckAgainstIgnoreHandledEventsMask( *event, *this, 0,
0); //no visitor passed in as argument

Being able to get the frame stamp could be quite useful, for instance if
one has to reset some information at every frame,
and doesn't want to place a dummy node somewhere in the scenegraph.

There are workarounds based on event timing,
but I think it would be more robust if the viewer passed this info to the
handler.
A simple solution could be to pass the same _eventVisitor used for the
scenegraph as an argument to the viewer's handlers, like
(*hitr)-handleWithCheckAgainstIgnoreHandledEventsMask( *event, *this, 0,
_eventVisitor); //no visitor passed in as argument

Robert, do you think it's a viable solution?
If so I will make a submission.

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

Re: [osg-users] FrameStamp on viewer's GUIEventHandler

[Riccardo Corsi]

Hi Robert,

cool, I was afraid there was a specific reason not to pass the visitor to
those handlers...
I've submitted the patch.

Also, while checking the event handling related code,
let me remind you that some people found in the past
that cameras sometimes receive twice the same event:
https://groups.google.com/d/topic/osg-users/9oj5XSRocB8/discussion

not sure where that issue comes from anyway... maybe you can spot it.

Cheers,
Ricky


On Wed, Feb 15, 2012 at 17:03, Robert Osfield robert.osfi...@gmail.comwrote:

 HI Riccardo,

 On 15 February 2012 15:38, Riccardo Corsi riccardo.co...@kairos3d.it
 wrote:
  while checking the code related to event handling,
  I've noticed that node callbacks receives a NodeVisitor in their handle()
  callback, and can then extract the frameStamp if needed.
 
  The same does not apply to the GUIEventHandler added directly to the
  osgViewer classes, as thy are invoked this way:
  (*hitr)-handleWithCheckAgainstIgnoreHandledEventsMask( *event, *this, 0,
  0); //no visitor passed in as argument

 Curious, and surprising - as far as I recall you're the first to spot
 this difference.  Thinking back I suspect I did this many years when
 transitioning from old osgProducer based viewer before there was an
 EventVisitor and this limitation just carried forward.



  Being able to get the frame stamp could be quite useful, for instance if
 one
  has to reset some information at every frame,
  and doesn't want to place a dummy node somewhere in the scenegraph.
 
  There are workarounds based on event timing,
  but I think it would be more robust if the viewer passed this info to the
  handler.
  A simple solution could be to pass the same _eventVisitor used for the
  scenegraph as an argument to the viewer's handlers, like
  (*hitr)-handleWithCheckAgainstIgnoreHandledEventsMask( *event, *this, 0,
  _eventVisitor); //no visitor passed in as argument
 
  Robert, do you think it's a viable solution?
  If so I will make a submission.

 I think this would be fine, I've just checked CompositeViewer.cpp and
 Viewer.cpp's use of the handleWithCheckAgainstIgnoreHandledEventsMask
 method and it looks to me like passing in the _eventVisitor as you
 have suggested would be fine.  So go ahead and make the change and
 send it into osg-submissions.

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

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

Re: [osg-users] FBO and mipmaps

[Riccardo Corsi]

Hi Aurelien,

if you ask the hardware to create the mipmaps for you (
setUseHardwareMipMapGeneration() ) they are generated automatically.
Otherwise you can write on a given mipmap level yourself, see the level
parameter of Camera::attach() method.

I believe that if you use  setUseHardwareMipMapGeneration() on a Texture,
its mipmaps are generated as soon as the texture is compiled, but I'm not
100% sure about this anyway.

Ricky

On Wed, Feb 1, 2012 at 15:21, Aurelien Albert
aurelien.alb...@alyotech.frwrote:

 Does that mean mipmap generation is fully automated ?

 If I try to access to FBO's mipmaps from a shader program, mipmaps will be
 available ?

 Are the mipmaps always generated (even if not used) or are they only
 generated on demand when they are used ?

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





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

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

Re: [osg-users] Is a render to texture master camera critical?

[Riccardo Corsi]

Hi all,

I've tried  to use the main camera as RTT in several applications and it
works for me as well.
But I'd like to ask a couple of questions on the post process passes
instead:
- is there any conceptual difference between using the final ortho camera
as a in-graph POST_RENDER or as a viewer's slave one?
- if using multiple post process passes, is it a good solution to add all
of the post cameras as children of a group with TraversalOrderBin, to
obtain a specific rendering order? Does this work correctly with all the
threading models?  Or is it better to explicitly assign to each camera its
render order via setRenderOrder()?

Thank you.
Ricky



On Fri, Jan 27, 2012 at 11:40, Tim Moore timoor...@gmail.com wrote:

 2012/1/17 Martin Großer grosser.mar...@gmx.de:
  Hello all,
 
  A few weeks ago, I want to render my scene into a texture, which I want
 to use in the final rendering on a screen aligned quad. My first problem
 was I lost the shadows, because view dependent shadow techniques don't work
 with nested cameras. So I used a RTT slave camera. Now my Callbacks don't
 work, because they don't work with slave cameras (no update visistors for
 slave scene graphs). So now my rtt camera is the master camera and my ortho
 camera for the quad is a nested camera (see the
 render_to_texture_scene_graph.png). It looks fine, but I am not sure
 whether it is a good idea.
 
  There are any special explanatory notes for me? Is it a good or bad
 scene graph pattern for my use case?
 A couple of points:
 The default for a slave camera is to use the master camera's scene
 graph. In that case you don't need to worry about callbacks in the
 main scene graph.

 You can install an UpdateSlaveCallback if you really need it. See osg/View.

 If you set up your windows and contexts explicitly and assign them to
 slave cameras before calling Viewer::realize() or Viewer::run(), then
 the master camera will not be given a graphics context and won't be
 used for rendering. The manipulators will still update the master and
 Its view and projection matrices will be used to control the slave
 cameras if desired.

 When I play with RTT, I like to open the window and set up the
 graphics context with GraphicsContext::createGraphicsContext(), then
 assign that to the slave cameras that render the scene graph and
 display the rendered texture on the screen. I don't put the RTT camera
 in the scene graph.

 Tim
 
  Cheers
 
  Martin
  --
  Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
  belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] How to get osg::State?

[Riccardo Corsi]

Hi Sebastian,

this is a little off-topic, but this might interst others as well.

I have been using  gDebugger 5.8 (the last before AMD decided to make it a
visual studio 2010 plugin, damn it!)
until 2 days ago, when my free 1-year-licence expired.
Since then I was unable to run it again, I tried uninstall-reinstall, asked
gRemedy if it was possible to renew the licence, but didn't get any reply...

Did someone get stuck on the same issue? Any suggetion?

Thank you,
Ricky



On Tue, Jan 24, 2012 at 23:52, Sebastian Messerschmidt 
sebastian.messerschm...@gmx.de wrote:

 I strongly suggest using gDebugger. It solved about 99% of my problems, as
 it can break at OpenGL errors and step into source code.

 cheers
 Sebastian

  I just hacked the State constructor and now I get this message:.


  Warning: detected OpenGL error 'invalid value' at
 Geometry::drawImplementation() after vertex arrays setup.

 Ok, so now I know there is an openGL error in the middle of the
 Geometry::drawImplementation() method.

 Is there an easy way to find out WHAT causes this error?

 Thank you!

 Cheers,
 Martin

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





 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] SharedStateManager usage in Registry

[Riccardo Corsi]

Hi Robert,

thank you for the clarification, I just wanted to make sure that was the
intended behavior.

I was mislead by this message thread:
http://forum.openscenegraph.org/viewtopic.php?p=30417
in which it seems that installing the ShareStateManager in the Registry
is enough to obtain the sharing feature.

Thanks,
Ricky


On Thu, Jan 5, 2012 at 21:35, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Roccardo,

 osgDB::Registry is the low level hooks for all the plugins so doesn't
 attempt to wrap up too much high level functionality.  If you wish to
 apply the SharedStateManager to all model calls you could write a
 custom Registry::ReadFileCallback that loads a model then does the
 share on it.

 Robert.

 On 21 December 2011 14:59, Riccardo Corsi riccardo.co...@kairos3d.it
 wrote:
  Hi All,
 
  in the attempt of enabling texture sharing when loading a scene at
  application startup,
  I've tried to use the SharedStateManager class as suggested in other
 posts,
  creating an instance of it in the Registry via:
  Registry::instance()-getOrCreateSharedStateManager()
 
  But after checking the code I've realized the SharedStateManager is used
  only by the DatabasePager when merging new subgraphs,
  and not by the Registry itself in methods like readNode()/Image/etc...
  which means that direct calls to load new objects don't make use of the
  state sharing.
 
  Is this the intended behaviour?
  I'd have expected that installing a sharing manager into the Registry
 would
  have influenced all calls that load some resource.
 
  Of course the workaround is to add somewhere an explicit call
  to SharedStateManager-share(),
  but I wanted to understand why the sharing mechanism is not used by the
  Registry automatically.
 
  Thank you,
  Ricky
 
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[osg-users] SharedStateManager usage in Registry

[Riccardo Corsi]

Hi All,

in the attempt of enabling texture sharing when loading a scene at
application startup,
I've tried to use the SharedStateManager class as suggested in other posts,
creating an instance of it in the Registry via:
Registry::instance()-getOrCreateSharedStateManager()

But after checking the code I've realized the SharedStateManager is used
only by the DatabasePager when merging new subgraphs,
and not by the Registry itself in methods like readNode()/Image/etc...
which means that direct calls to load new objects don't make use of the
state sharing.

Is this the intended behaviour?
I'd have expected that installing a sharing manager into the Registry would
have influenced all calls that load some resource.

Of course the workaround is to add somewhere an explicit call
to SharedStateManager-share(),
but I wanted to understand why the sharing mechanism is not used by the
Registry automatically.

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

Re: [osg-users] Problems with RTT, Shadowmaps and Callbacks

[Riccardo Corsi]

Hi Martin,

regarding the callback issue on slave cameras please check this thread:
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-November/019337.html

Cheers,
Ricky

On Tue, Oct 25, 2011 at 16:21, Wojciech Lewandowski
lewandow...@ai.com.plwrote:

 Hi, Martin

 I am assuming you are complaining about limitiation of techniques derived
 from ViewDependentShadowTechnique. If thats a such huge problem for you then
 you may try to fix ViewDependentShadowTechnique to use RenderStage ptr
 instead of CullVisitor ptr to index ViewDependentData. That requires some
 bravery but I think there is huge chance it may be quite easy to do... Just
 look at ViewDependentShadowTechnique / ViewDependentShadowTechnique.**cpp
 and see how CullVisitor pointer is used to recognize yet another view
 (slave) is drawn and shadowed. Nested cameras use the same CullVisitor as
 parent cam and thats the reason it does not work for nested cams, but
 RenderStages are unique (I believe) so you may try to use current
 RenderStages obtained from CullVisitior to index shadow instances

 I could help you with this, but not in this month... So have fun;-)

 Cheers,
 Wojtek


 -Oryginalna wiadomość- From: Martin Großer
 Sent: Tuesday, October 25, 2011 12:02 PM
 To: osg-users@lists.**openscenegraph.orgosg-users@lists.openscenegraph.org
 Subject: [osg-users] Problems with RTT, Shadowmaps and Callbacks


 Hello,

 I am so dissatisfied at the moment. I render my scene into a texture and
 put it on a quad. I want use shadow maps in my scene, so I have to use a
 slave camera, because shadowmap technique doesn't work with nested cameras.
 But my problem is, all my callback function doesn't work now. The only work
 with nested cameras. It is a big dilemma, isn't it? What can I do? Is there
 a typical solution for this problem?

 Thanks

 Martin
 --
 NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
 Jetzt informieren: 
 http://www.gmx.net/de/go/**freephonehttp://www.gmx.net/de/go/freephone
 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device

[Riccardo Corsi]

Hi Jorge,

I've added some Log as you suggested, and apparently as soon as it construct
the osgMainApp native object, something goes wrong.
In particular I've added a log in the EGL Renderer like this:

public void onSurfaceChanged(GL10 gl, int width, int height)
{
Log.e(TAG, BEFORE_NATIVE_INIT);

osgNativeLib.init(width, height);
}


and one log in the init() method of osgNativeLib.cpp like this:

JNIEXPORT void JNICALL Java_osg_AndroidExample_osgNativeLib_init(JNIEnv *
env, jobject obj, jint width, jint height)
{
__android_log_write(ANDROID_LOG_ERROR, OSGANDROID,
NATIVE_INIT_CODE);

mainApp.initOsgWindow(0,0,width,height);
}

Finally, I've also added 2 log as first and last instruction of the
OsgMainApp ctor (in the cpp file):

OsgMainApp::OsgMainApp()
{
  __android_log_write(ANDROID_LOG_ERROR, OSGANDROID,
OSG_MAIN_APP_CTOR_BEGIN);


_lodScale = 1.0f;
_prevFrame = 0;

_initialized = false;
_clean_scene = false;

__android_log_write(ANDROID_LOG_ERROR, OSGANDROID,
OSG_MAIN_APP_CTOR_END);

}


What happens is that BEFORE_NATIVE_INIT is printed, the 2 logs in the cpp
ctor are printed as well,
but NOT he NATIVE_INIT_CODE, which suggests some error related to the
native object right after it's created.

The new logcat is in attach.

One more info is that I've tried to build all the example with both 2.3.3
and 3.1 target profile, and they show the same problem on the tablet.
I've tried as well to modify manually the minimum and target version of the
sdk in the AndroidManifest.xml but nothing changed.

Ricky

P.S. I'll run some more tests today, but since tomorrow I'll be in vacation
for a couple of weeks =) My colleague Luca will run some tests and follow
this thread while I'm away. Thank you.




On Wed, Aug 17, 2011 at 18:44, Jorge Izquierdo Ciges jori...@gmail.comwrote:

 Well it's easy... there are some debug messages that I put them because the
 obscureness and difficulties to find some error so usually the trace should
 have first the message:


 08-16 15:59:29.331: WARN/EGLview(4904): creating OpenGL ES 1 context

 That message come from the EGL java class WHICH initializes the GLES context. 
 That message is in your logs. Now when you have the context the method 
 onSurfaceCreated is called and it's a do nothing in my example, for more 
 complex programs the correct initialization should be done there and the 
 surfaceChange have another initialization code, because that function is 
 called when you change possition on your device and on other places. So they 
 should not have the same code.

 When you enter onSurfaceChanged, that's when OSG initializes everything so 
 NOW we have the BIG trouble. the init function goes through a JNI bridge 
 (init function) and calls the function initOsgWindow of mainApp.

 Inside initOsgWindow there's another LOG  that should write. It's the FIRST 
 instruction and it is dispatchet through __android_log_write so that will 
 ever show whathever happens.

 Initializing geometry

 If you don't see that Log entry then no OSG code has been used.

 Then Maybe it's the same strange bug that Rafa told me once (he could fix it 
 for his samsung) but since 2.2 that bug dissapeared... And i don't know e

 Now you should test if the application can reach the JNI bridge, put some 
 __android_log_write in the osgNativeLib in the init function after and before 
 calling the osg function.

 And about the log that's just the full heap. There are some manuals if you
 want to know more to translate to code but just by looking what I've said to
 you... it's a strange bug.



 2011/8/17 Riccardo Corsi riccardo.co...@kairos3d.it

 Hi Jorge,

 I've set some breakpoints and stepped into the java code with the
 debugger.
 From the GLThread these methods are called in this order:
 - EGLView::onSurfaceCreated()
 - EGLView::onSurfaceChanged()

 Inside onSurfaceChanged(), when it calls the native method
 osgNativeLib.init(), it exits and thus never reaches onDrawFrame() is never
 reached.

 Ricky

 P.S. By the way... how did you get that info from the logcat? it's still
 quite obscure to me...





 On Wed, Aug 17, 2011 at 16:38, Jorge Izquierdo Ciges 
 jori...@gmail.comwrote:

 That's one hell of a error. ¡He doesn't reach the initOsgWindow function!

 I've never seen it, but I have some ideas. First it's the same error for
 both of them. This must be some Native compatibility isue. I've heard that
 the EglView in which the example is based has some troubles with some
 devices but no one has said something solid about it. So, try to check by
 debug or just Log (quicker) which methods of the EGLview.java if onDraw is
 calle before onSurfaceChange or if onSurfaceChanged is never called we'll
 hace to see if there has been some changes in the API that requiere a SDK
 target version on the manifest. If not... well we'll see.

 2011/8/17 Riccardo Corsi riccardo.co...@kairos3d.it

 Hi Jorge and all,

 I start a new thread as I

[osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device

[Riccardo Corsi]

Hi Jorge and all,

I start a new thread as I don't want to pollute the other -
http://forum.openscenegraph.org/viewtopic.php?t=8917start=17
which mainly talks about building for Android.

Basically the issue is that osgAndroidExampleGLES1 doesn't work when
deployed to my Acer Iconia A500, running Android 3.1
(while the same build works just fine on the Nexus S running Android 2.3.4)

The application starts up for a couple of seconds, and when it's about to
create the osg blue screen it dies.
I attach the logcat, even though I couldn't understand from it what's the
reason that makes the viewer die...

The same happens with the GLES2 example, for which I attach the logcat as
well.

I'm still investigating and will post if I have some news,
any hint is appreciated.
Ricky

08-16 15:59:29.091: INFO/ActivityManager(127): Start proc osg.AndroidExample 
for activity osg.AndroidExample/.osgViewer: pid=4904 uid=10085 gids={3003}
08-16 15:59:29.331: WARN/EGLview(4904): creating OpenGL ES 1 context
08-16 15:59:29.411: INFO/PowerManagerService(127): WakeLock: 
ActivityManager-Launch(PARTIAL_WAKE_LOCK ) is released by pid(127), 
uid(1000)
08-16 15:59:29.471: INFO/DEBUG(80): *** *** *** *** *** *** *** *** *** *** *** 
*** *** *** *** ***
08-16 15:59:29.471: INFO/DEBUG(80): Build fingerprint: 
'acer/picasso_generic1/picasso:3.1/HMJ37/1309327721:user/release-keys'
08-16 15:59:29.471: INFO/DEBUG(80): pid: 4904, tid: 4913   
osg.AndroidExample 
08-16 15:59:29.471: INFO/DEBUG(80): signal 4 (SIGILL), code 1 (ILL_ILLOPC), 
fault addr 8256b5be
08-16 15:59:29.471: INFO/DEBUG(80):  r0 0120  r1 0001  r2   r3 

08-16 15:59:29.471: INFO/DEBUG(80):  r4 001ead00  r5 826d6cf0  r6 001eacd8  r7 
826e12f4
08-16 15:59:29.471: INFO/DEBUG(80):  r8 b00133b8  r9 826dc000  10 006ee000  fp 
8200
08-16 15:59:29.471: INFO/DEBUG(80):  ip   sp 59217498  lr 8242b781  pc 
8256b5be  cpsr 2030
08-16 15:59:29.471: INFO/DEBUG(80):  d0  4978000f  d1  40dfae144970
08-16 15:59:29.471: INFO/DEBUG(80):  d2  bf80c47a  d3  3f80
08-16 15:59:29.471: INFO/DEBUG(80):  d4  3f80  d5  3ff03f80
08-16 15:59:29.471: INFO/DEBUG(80):  d6  3f00  d7  bf80
08-16 15:59:29.471: INFO/DEBUG(80):  d8    d9  
08-16 15:59:29.471: INFO/DEBUG(80):  d10   d11 
08-16 15:59:29.471: INFO/DEBUG(80):  d12   d13 
08-16 15:59:29.471: INFO/DEBUG(80):  d14   d15 
08-16 15:59:29.471: INFO/DEBUG(80):  scr 8012
08-16 15:59:29.651: INFO/DEBUG(80):  #00  pc 0056b5be  
/data/data/osg.AndroidExample/lib/libosgNativeLib.so 
(_ZN3osg7Matrixd12makeIdentityEv)
08-16 15:59:29.651: INFO/DEBUG(80):  #01  lr 8242b781  
/data/data/osg.AndroidExample/lib/libosgNativeLib.so
08-16 15:59:29.651: INFO/DEBUG(80): libc base address: afc3d000
08-16 15:59:29.651: INFO/DEBUG(80): code around pc:
08-16 15:59:29.651: INFO/DEBUG(80): 8256b59c 2318e9c0 2302e9d1 231ae9c0 
2304e9d1 
08-16 15:59:29.651: INFO/DEBUG(80): 8256b5ac 231ce9c0 bf004770  
1b00eef7 
08-16 15:59:29.651: INFO/DEBUG(80): 8256b5bc 0b12eddf 0b02edc0 0b04edc0 
0b06edc0 
08-16 15:59:29.651: INFO/DEBUG(80): 8256b5cc 0b08edc0 0b0cedc0 0b0eedc0 
0b10edc0 
08-16 15:59:29.651: INFO/DEBUG(80): 8256b5dc 0b12edc0 0b16edc0 0b18edc0 
0b1aedc0 
08-16 15:59:29.651: INFO/DEBUG(80): code around lr:
08-16 15:59:29.651: INFO/DEBUG(80): 8242b760 7a41edc4 7a42edc4 7a43edc4 
7a44edc4 
08-16 15:59:29.651: INFO/DEBUG(80): 8242b770 7a45edc4 7a46edc4 7a47edc4 
ff1cf13f 
08-16 15:59:29.651: INFO/DEBUG(80): 8242b780 70d0f504 ff18f13f f04f2300 
f8c432ff 
08-16 15:59:29.651: INFO/DEBUG(80): 8242b790 46203220 3224f884 2226f8a4 
3228f8c4 
08-16 15:59:29.651: INFO/DEBUG(80): 8242b7a0 4605bd70 f1884620 4628ff41 
ea84f656 
08-16 15:59:29.651: INFO/DEBUG(80): stack:
08-16 15:59:29.651: INFO/DEBUG(80): 59217458  006ee000  
08-16 15:59:29.651: INFO/DEBUG(80): 5921745c  afc5035b  /system/lib/libc.so
08-16 15:59:29.651: INFO/DEBUG(80): 59217460  826dc000  
08-16 15:59:29.651: INFO/DEBUG(80): 59217464  006ee000  
08-16 15:59:29.651: INFO/DEBUG(80): 59217468  001ead00  
08-16 15:59:29.651: INFO/DEBUG(80): 5921746c  00181138  
08-16 15:59:29.651: INFO/DEBUG(80): 59217470  001eacd8  
08-16 15:59:29.661: INFO/DEBUG(80): 59217474  82555bb3  
/data/data/osg.AndroidExample/lib/libosgNativeLib.so
08-16 15:59:29.661: INFO/DEBUG(80): 59217478  001ead00  
08-16 15:59:29.661: INFO/DEBUG(80): 5921747c  001225cc  
08-16 15:59:29.661: INFO/DEBUG(80): 59217480  001eacd8  
08-16 15:59:29.661: INFO/DEBUG(80): 59217484  825b471f  
/data/data/osg.AndroidExample/lib/libosgNativeLib.so
08-16 15:59:29.661: INFO/DEBUG(80): 59217488  001ead00  
08-16 15:59:29.661: INFO/DEBUG(80): 5921748c  002ab620  
08-16 15:59:29.661: INFO/DEBUG(80): 59217490  df002777  
08-16 15:59:29.661: 

Re: [osg-users] osgAndroidExampleGLES1 and 2 error on Android 3.x device

[Riccardo Corsi]

Hi Jorge,

I've set some breakpoints and stepped into the java code with the debugger.
From the GLThread these methods are called in this order:
- EGLView::onSurfaceCreated()
- EGLView::onSurfaceChanged()

Inside onSurfaceChanged(), when it calls the native method
osgNativeLib.init(), it exits and thus never reaches onDrawFrame() is never
reached.

Ricky

P.S. By the way... how did you get that info from the logcat? it's still
quite obscure to me...




On Wed, Aug 17, 2011 at 16:38, Jorge Izquierdo Ciges jori...@gmail.comwrote:

 That's one hell of a error. ¡He doesn't reach the initOsgWindow function!

 I've never seen it, but I have some ideas. First it's the same error for
 both of them. This must be some Native compatibility isue. I've heard that
 the EglView in which the example is based has some troubles with some
 devices but no one has said something solid about it. So, try to check by
 debug or just Log (quicker) which methods of the EGLview.java if onDraw is
 calle before onSurfaceChange or if onSurfaceChanged is never called we'll
 hace to see if there has been some changes in the API that requiere a SDK
 target version on the manifest. If not... well we'll see.

 2011/8/17 Riccardo Corsi riccardo.co...@kairos3d.it

 Hi Jorge and all,

 I start a new thread as I don't want to pollute the other -
 http://forum.openscenegraph.org/viewtopic.php?t=8917start=17
 which mainly talks about building for Android.

 Basically the issue is that osgAndroidExampleGLES1 doesn't work when
 deployed to my Acer Iconia A500, running Android 3.1
 (while the same build works just fine on the Nexus S running Android
 2.3.4)

 The application starts up for a couple of seconds, and when it's about to
 create the osg blue screen it dies.
 I attach the logcat, even though I couldn't understand from it what's the
 reason that makes the viewer die...

 The same happens with the GLES2 example, for which I attach the logcat as
 well.

 I'm still investigating and will post if I have some news,
 any hint is appreciated.
 Ricky

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



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


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

Re: [osg-users] OSG for Android

[Riccardo Corsi]

Hi Hector,

maybe you can try to use the ndk-build command instead of make, and see if
it runs smooth.
If so, probably there's something wrong with the makefile generated by
CMake...

Regarding the osg Android example, the folder structure is the same as the
one of the NDK examples.
Build instructions for native projects are very clear on the ndk online
documentation, especially if you use Eclipse.
You basically need to build the native part of the example before (under the
jni folder) the same way you compiled the native osg libs, and afterwards
build the java files under src. They make use of the native lib, and both
the java code and the native library will be packed in the apk by Eclipse
(or the compiler you're using).

HTH,
Ricky


2011/8/12 Héctor Martínez hector.marti...@sensetrix.com

 Hi and thank you.

 ** **

 I first tried with the Cmake GUI, but I got some errors. After that, I have
 read your answer pointing to command line. I have used the cmake command
 line (not without some problems J ):

 cmake - OK

 make - Error:

 make[3]: ***
 [/cygdrive/c/Projects/OpensSceneGraph-3.0.1/OpenSceneGraph/obj/local/armeabi-v7a/objs/osgdb_serializers_osg/BlendEquation..o]
 Error 126

 make[3]: *** Waiting for unfinished jobs….

 make[2]: *** [Android-OpenSceneGraph] Error 2

 make[1]: *** [CMakeFiles/ndk.dir/all] Error 2

 make: *** [all] Error 2

 After that, I have tried to use “make install” and it has finished without
 error, but I think this is a weird behavior.

 ** **

 Anyway, does somebody now how to solve the problem?

 ** **

 And another question, after compiling (if I can make it J ), what files
 (and where) will I need to include in the OSG Android example?

 ** **

 Thank you.

 ** **

 Cheers,

 ** **

 Héctor

 ** **

 *From:* osg-users-boun...@lists.openscenegraph.org [mailto:
 osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Mourad
 Boufarguine
 *Sent:* jueves, 11 de agosto de 2011 16:50

 *To:* OpenSceneGraph Users
 *Subject:* Re: [osg-users] OSG for Android

 ** **

 ** **

 On Thu, Aug 11, 2011 at 1:09 PM, Mourad Boufarguine 
 mourad.boufargu...@gmail.com wrote:

 Hi Hector,

 ** **

 2011/8/11 Héctor Martínez hector.marti...@sensetrix.com

 Thank you Mourad and Jorge.

  

 I have never used CygWin and I am trying to follow those instructions:

  


 http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Cygwin
 

 ** **

 Those are for building OSG with cygwin to be used on a PC.

  

  

 But it is a bit messy for me. Mourad, it seems like you have successfully
 compiled OSG for Android in Windows. Could you please give me a quick guide
 or some tips?

 ** **

 ** **

 1/ install Cygwin ^^ , make sure to install gcc , g++, make, ... (a full
 install may be helpful).

 ** **

 Please note that, although we won't be compiling osg with cygwin's g++ , it
 needs to be installed in order for cmake to get over compiler checks at the
 beginning of configuration. (and other packages may be also needed)

 ** **

 2/ in cmake gui, set the sources and binairies folders, hit configure and
 choose Unix Makefiles as generator

 ** **

 3/ Check OSG_BUILD_PLATFORM_ANDROID and hit configure

  

 4/ Set (if not set) ANDROID_NDK path

 ** **

 5/ Configure your build whether you want GLES1 or GLES2 following these
 instructions :
 http://www.openscenegraph.org/projects/osg/wiki/Community/OpenGL-ES 

 ** **

 6/ Configure and Generate

 ** **

 7/ open Cygwin batch, cd to binaires dir, and make

 ** **

  

 Héctor

  

 ** **

 Cheers,

 Mourad 

 ** **

 ** **

 After re trying and checking, i found out that it is preferable to use the
 command line cmake in cygwin rather than cmake gui :

 ** **

 ** **

 ** **

 cmake .. -DOSG_BUILD_PLATFORM_ANDROID=ON -DDYNAMIC_OPENTHREADS=OFF

 -DDYNAMIC_OPENSCENEGRAPH=OFF -DOSG_GL_DISPLAYLISTS_AVAILABLE=OFF

 -DOSG_GL_MATRICES_AVAILABLE=ON -DOSG_GL_VERTEX_FUNCS_AVAILABLE=ON

 -DOSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE=ON 
 -DOSG_GL_FIXED_FUNCTION_AVAILABLE=ON

 -DOSG_CPP_EXCEPTIONS_AVAILABLE=OFF -DOSG_GL1_AVAILABLE=OFF 
 -DOSG_GL2_AVAILABLE=OFF

 -DOSG_GL3_AVAILABLE=OFF -DOSG_GLES1_AVAILABLE=ON -DOSG_GLES2_AVAILABLE=OFF

 Mourad

 ** **

 ** **

 ** **

 ** **

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


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

Re: [osg-users] OSG for Android

[Riccardo Corsi]

Hi Mourad and all,

I've succesfully built osg_3.0.1 on Windows with Cygwin (without 3rd party
plugins for now).

I'm now trying to build the osgAndroidExampleGLES1, and everything compiles,
but the linker (ld) throws an error says that it cannot find the dds lib,
here it is:

$ ../../../../../Android/android-ndk-r6/ndk-build
NDK_APPLICATION_MK=Application.mk
Compile++ thumb  : osgNativeLib = osgNativeLib.cpp
Compile++ thumb  : osgNativeLib = OsgMainApp.cpp
Compile++ thumb  : osgNativeLib = OsgAndroidNotifyHandler.cpp
SharedLibrary  : libosgNativeLib.so
D:/SourceCode/Android/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/windows/bin/../
lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin/ld.exe:
cannot find -losgd
b_dds
collect2: ld returned 1 exit status
make: ***
[/cygdrive/d/SourceCode/OSG/osg_3.0.1/examples/osgAndroidExampleGLES1/obj/local/armeabi/libosgNativeLib.so]
Error 1

I'm checking the options of the Android.mk file and it looks like there's a
variable LIBDIR to specify the library path which is then used here:

[...]
LOCAL_LDFLAGS   := -L $(LIBDIR) \
-losgdb_dds \
[...]

I've already tried to set it to relative and absolute paths, I've also tried
to copy the compiled libraries in the local example folder,
but cannot get it finding the libraries!
Have you got any other suggestion?

Thank you,
Ricky




On Thu, Aug 11, 2011 at 13:09, Mourad Boufarguine 
mourad.boufargu...@gmail.com wrote:

 Hi Hector,

 2011/8/11 Héctor Martínez hector.marti...@sensetrix.com

 Thank you Mourad and Jorge.

 ** **

 I have never used CygWin and I am trying to follow those instructions:***
 *

 ** **


 http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Cygwin


 Those are for building OSG with cygwin to be used on a PC.


 

 ** **

 But it is a bit messy for me. Mourad, it seems like you have successfully
 compiled OSG for Android in Windows. Could you please give me a quick guide
 or some tips?

 **



 1/ install Cygwin ^^ , make sure to install gcc , g++, make, ... (a full
 install may be helpful).

 Please note that, although we won't be compiling osg with cygwin's g++ , it
 needs to be installed in order for cmake to get over compiler checks at the
 beginning of configuration. (and other packages may be also needed)

 2/ in cmake gui, set the sources and binairies folders, hit configure and
 choose Unix Makefiles as generator

 3/ Check OSG_BUILD_PLATFORM_ANDROID and hit configure

 4/ Set (if not set) ANDROID_NDK path

 5/ Configure your build whether you want GLES1 or GLES2 following these
 instructions :
 http://www.openscenegraph.org/projects/osg/wiki/Community/OpenGL-ES

 6/ Configure and Generate

 7/ open Cygwin batch, cd to binaires dir, and make

  **

 Héctor

 ** **


 Cheers,
 Mourad


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


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

Re: [osg-users] OSG for Android on Mac

[Riccardo Corsi]

Hi Busra,

I'm not familiar with Mac dev environment,
but I guess that you're trying to build osg with Eclipse CDT with the
regular gcc compiler, which is targetting pc architecture.
Instead you need to create a makefile suited for the ndk-build. The CMake
options you need are fully detailed in the wiki page and in other threads of
this mailing list.

Good luck,
Ricky


2011/8/11 Büsra Gülten busragul...@hotmail.de

 Hi,

 I am trying to build OSG for Android on Mac 10.6.7. I already get Eclipse,
 Android Plugin and CDT Plugin and also Android NDK.

 I configure the project with CMake and generate an Eclipse CDT4 project.
 After that, I create a new Android Project with Create project from
 existing source and add the generated Eclipse CDT4 project.
 Now, when I try to build this project, I get following error:


  Conversion to Dalvik format failed with error 1
  Dx no classfiles specified


 Are my steps to compile OSG for Android false?

 Cheers,
 Büsra

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





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

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

Re: [osg-users] OSG for Android

[Riccardo Corsi]

Hi guys,

it works!!
I had to tweak something and then I've run some tests, let me share some
points with you:

- Builing
I have made a floder called ndk-build inside the osg folder tree to place
all the nkd builind stuff. If I set the OSG_ANDROID_DIR to that folder, the
compiler doesn't file the osg includes, so I had to add the osg include
folder to the LOCAL_C_INCLUDES.
By doing that everything compile and link.
What I don't get is why it wasn't working before, when I had edited directly
the variables LOCAL_C_INCLUDES and LIBDIR by setting them to full paths -
any hints on this point??

- Running
I've been trying only the GLES1 example, and it works just fine on my Nexus
S (android 2.3.4)
Instead I've tried to build the example also for the 3.x platform target: it
build and upload on my tablet, but it just shows up for a couple of seconds
and then it dies.
I have no time to investigate right now, I'll run some more tests tomorrow.
Have you got any idea what it might be depending on?
My device is an Acer Iconia Tab A500.

Thank you for your support and great job!
Ricky



On Thu, Aug 11, 2011 at 17:05, Jorge Izquierdo Ciges jori...@gmail.comwrote:

 Mmmm look the Android make file inside the GLES example and change type
 your directory here into your path to OSG


 2011/8/11 Mourad Boufarguine mourad.boufargu...@gmail.com

 ed with my binaries folder path and it worked.



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


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

Re: [osg-users] [Phoronix] AMD Pushes gDEBugger Away From Linux, Mac OS X

[Riccardo Corsi]

Hi guys,

I agree it's really a shame for gDebugger...

there's another GL api tracer that might be worth to take a look at:
http://zrusin.blogspot.com/2011/04/apitrace.html

I've never tried it, but it seems very powerfufl.
hth,
ricky



On Fri, Jul 8, 2011 at 22:13, Jean-Sébastien Guay 
jean-sebastien.g...@cm-labs.com wrote:

 Hi Chris,

This is a shame.


 Definitely. In addition to dropping Linux and MacOS X support, they changed
 it to a Visual Studio plugin which currently ONLY works in VS 2010!

 I don't even want to ask whether they will still support the low-level
 counters in nvidia instrumented drivers...

 It's not just a shame, it downright sucks. The one tool that could come
 even remotely close to competing with MS PIX or nvidia PerfHUD (which are
 Direct3D only) for OpenGL just went down the drain...

 J-S
 --
 __**
 Jean-Sebastien Guay
 jean-sebastien.guay@cm-labs.**comjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/

 http://whitestar02.dyndns-web.**com/http://whitestar02.dyndns-web.com/

 __**_
 osg-users mailing list
 osg-users@lists.**openscenegraph.org osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.**org/listinfo.cgi/osg-users-**
 openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] [osgPPU] Render lower Resolution with unitOut than wandow / fullscreen

[Riccardo Corsi]

I Peter,

I've experienced the same issue some time ago, but could not find the real
cause.
I've tried several combinations of pre-post render order of cameras, and
renderbin order for processor, but none of them solved the issue.

If you make any progress please post some news... =)
Thanks you!
Ricky




On Tue, Jun 7, 2011 at 09:40, Peter Wrobel particlepe...@gmx.de wrote:

 Hi Art,

 Thx for your answer, that worked, kind of, but have now some new issues.
 I am using the Glow example, Blur and Original are out of Sync. Will try to
 figure out, and ask/answer later.


 Thank you!

 Cheers,
 ParticlePeter

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





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

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

Re: [osg-users] Fine-grained render ordering

[Riccardo Corsi]

Hi,

is the render order index another option?
This is the index that Camera::SetRenderOrder() takes as the second
parameter.
For instance if you place camera C in PreRender with index -1 and sibling A
and B in PreRender with a greater index,
I think you should get what you're after.

Ricky



On Sat, May 7, 2011 at 13:40, Sergey Polischuk pol...@yandex.ru wrote:

 Hi, Craig

 Will C be rendered twice? - yes
 Would it work to make C a child of A only, with A PRE_RENDER and B
 POST_RENDER? - yes

 You could also use linear structure like A - B - C

 Cheers, Sergey.


 06.05.2011, 17:55, Craig S. Bosma craig.bo...@gmail.com:

 Sergey,

 Thanks, that's been very helpful. I have some other questions though:
 suppose you have a graph with camera C, a child of sibling cameras A  B,
 e.g.

 A - C
 B - C

 Will C be rendered twice? If so, how would one make C render first, then
 render each of A, B with the output textures of C? Would it work to make C a
 child of A only, with A PRE_RENDER and B POST_RENDER?

 Thanks,
 Craig


 On Tuesday, May 3, 2011 at 2:30 AM, Sergey Polischuk wrote:

 Sent incomplete message by accident :)

 Example : camera1 - camera2(prerender) - camera4(prerender)
  - camera3(postrender)

 render order will be camera4 (rendered first), camera2, camera3,
 camera1(rendered last)

 Cheers, Sergey.

 03.05.2011, 11:28, Sergey Polischuk pol...@yandex.ru:

 Hi, Craig

 When you have nested cameras they work like nested render stages. All
 cameras under another camera node will render just before or just after
 (depending on render order set on camera) rendering parent camera. With that
 in mind you can build hierarchy that suits your purposes.

 Example : camera1 - camera2



 02.05.2011, 16:17, Craig S. Bosma craig.bo...@gmail.com;:

 Will the same technique work with a third camera C?

 Sent from my iPhone

 On Apr 28, 2011, at 11:06 AM, Sergey Polischuk pol...@yandex.ru wrote:



 Hi, Craig
 In your example, put camera A as child of B with render order on camera A
 set to prerender.

 Cheers, Sergey.


 27.04.2011, 18:38, Craig S. Bosma craig.bo...@gmail.com:

 Robert,

 Thanks for pointing out the TraversalOrderBin, I wasn't aware of that.
 However, I'm still a little unclear on how that might help for my use.
 Suppose I have a scene with with a root Group node and two child Camera
 Nodes, A and B. Suppose both render to a texture via FBO, and that B needs
 A's texture output. If I put the root node in the TraversalOrderBin, would
 that guarantee that camera A is rendered completely before camera B? What if
 A instead were a child of B?

 Thanks,
 Craig


 On Tuesday, April 26, 2011 at 5:01 AM, Robert Osfield wrote:

 Hi Craig,

 The best way to manage render bin is vis State::setRenderBinDetails(),
 and in the 2.9.x dev series you can now select a render bin that sorts
 on traversal order of a subgrpah which makes some techniques easier -
 use the RenderBin string TraversalOrderBin to select this bin.

 If you want to create and chain RenderStages then using an osg::Camera
 in the scene graph is often one of the best ways to do this, and use
 the Camera::setRenderOrder(..) to control the order. You can also use
 a custom cull traversal callback to create RenderStage/RenderBin and
 assign these to the rendering backend, but this does require a greater
 knowledge of the internals of the rendering backend.

 Robert.

 On Fri, Apr 22, 2011 at 9:52 PM, Craig S. Bosma  craig.bo...@gmail.com
 craig.bo...@gmail.com wrote:

 Hi,
 I'm working on a shader-driven graphics pipeline for an OSG-based app, and
 I
 want to better understand how I can better control the rendering order. I
 want to render my initial scene to several texture targets, with opaque and
 transparent objects handled separately. Currently I do this using node
 masks, but from this thread
 ( http://forum.openscenegraph.org/viewtopic.php?t=2374
 http://forum.openscenegraph.org/viewtopic.php?t=2374) it seems like it
 would be better to use renderbin/renderstages. I have several more
 post-processing stages to follow, so I'm convinced that's the way to go for
 me to have full control over the pipeline.
 I've dug into the source for SceneView, RenderBin, RenderStage, etc. but
 it's not obvious to me how to shift objects from one bin to another (aside
 from setRenderBinDetails), or how to add stages that form a dependency
 chain. If anyone has examples or general advice on where to look, I'd be
 glad to hear it.
 Thanks,
 Craig


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

 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.orgosg-users@lists.openscenegraph.org
 

Re: [osg-users] large VBOs for multiple Drawables

[Riccardo Corsi]

Hi All,

Paul, I think I've done some of the benchmark you're referring to on my end
right before starting this thread =)
In my example I replicate the same geometric primitive many times.
The geometric object is a little cube counting 40 vertex and 66 triangles
all rendered as a single drawElements in batch.
I'm using a very basic toon shader to render them, passing vertices, normals
and a vec4 attribute array.

Here's what I got when I test with 20.000 instances of the primitive when
they are all in the view frustum,
my box is Win7, i7 920 processor, nVidia 285GTX:

1) 20.000 separate drawables, each with its own VBO assigned.
CULL: 11ms, DRAW: ~40ms, GPU: ~37ms
Stats are very unstable with this scenario, even when I don't move and with
all of the threading models.


2) 20.000 separate drawables, sharing underneath the same VBO and EBO (at
least I hope I'm doing it the right way, check the code in my previous post)

CULL: ~8ms, DRAW: ~36ms, GPU: ~35ms


3) A single geode+geometry in which I combine all of the instances, rendered
in a single VBO + EBO
CULL: 0.04ms, DRAW: 0.18ms, GPU: ~4.5ms
Stats very stable, no differences among threading models.
With this scenario the fragment opeations becomes the bottleneck when I look
at the scene from a viewpoint that cause all the geometries to be rendered
almost back to front, so that nothing  is culled nor discarded by z test.

So scenario 3 provides a huge boost as expected, while the difference
between 1 and 2 is not as evident as I had hoped...

I'll see if I'm able to to patch the osg code to achive what Robert
suggests.

Thanks,
Ricky





On Thu, May 5, 2011 at 20:47, Robert Osfield robert.osfi...@gmail.comwrote:

 HI All,


 Current the OSG does unbind VBO's at the end of
 osg::Geometry::drawImplementation(..) so that VBO and EBO state
 doesn't leak into adjoining Drawables.  If an implementation is known
 to only use VBO's, with no display lists then potentially we could not
 bother with the unbind at the end of Geometry::drawImplemenation() and
 use lazy state updating.

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

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

Re: [osg-users] large VBOs for multiple Drawables

[Riccardo Corsi]

Hi Robert,

thank you for your advice, but I used 20.000 only for benchmarking purposes,

I'll balance better the scenegraph in the real application.

Even so, with the scenario number 2, I was hoping to achieve performances
closer to scenario 3 than 1,
as the stats scale quite in linear way with smaller number of drawables.
Do you think the approach you suggest, avoiding explicit buffer unbind,
would provide some benefit?

I also have another question: when assigning vertex attributes and using
VBO,
I've met some issues using methods Geometry::setNormal/ColorArray and
retrieving the related attributes with gl_Normal/Color in shaders,
while everything works smooth if I assign and bind specific attribute
indices.
What is the reason behind it?

Thank you,
Ricky


On Fri, May 6, 2011 at 11:29, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Ricky,

 Given you have 20,000 instances their will and cull and draw dispatch
 bottleneck.  Sharing VBO's won't really share this much.  The big
 elephant in the room is the number of seperate objects to traverse in
 the cull and draw traversals and the number of seperate GL calls that
 will have to be made.  As you've found batching the data ovoids these
 bottlenecks and is certainly the way forward.

 Robert.

 On Fri, May 6, 2011 at 9:49 AM, Riccardo Corsi
 riccardo.co...@kairos3d.it wrote:
  Hi All,
 
  Paul, I think I've done some of the benchmark you're referring to on my
 end
  right before starting this thread =)
  In my example I replicate the same geometric primitive many times.
  The geometric object is a little cube counting 40 vertex and 66 triangles
  all rendered as a single drawElements in batch.
  I'm using a very basic toon shader to render them, passing vertices,
 normals
  and a vec4 attribute array.
 
  Here's what I got when I test with 20.000 instances of the primitive when
  they are all in the view frustum,
  my box is Win7, i7 920 processor, nVidia 285GTX:
 
  1) 20.000 separate drawables, each with its own VBO assigned.
  CULL: 11ms, DRAW: ~40ms, GPU: ~37ms
  Stats are very unstable with this scenario, even when I don't move and
 with
  all of the threading models.
 
 
  2) 20.000 separate drawables, sharing underneath the same VBO and EBO (at
  least I hope I'm doing it the right way, check the code in my previous
 post)
  CULL: ~8ms, DRAW: ~36ms, GPU: ~35ms
 
 
  3) A single geode+geometry in which I combine all of the instances,
 rendered
  in a single VBO + EBO
  CULL: 0.04ms, DRAW: 0.18ms, GPU: ~4.5ms
  Stats very stable, no differences among threading models.
  With this scenario the fragment opeations becomes the bottleneck when I
 look
  at the scene from a viewpoint that cause all the geometries to be
 rendered
  almost back to front, so that nothing  is culled nor discarded by z test.
 
  So scenario 3 provides a huge boost as expected, while the difference
  between 1 and 2 is not as evident as I had hoped...
 
  I'll see if I'm able to to patch the osg code to achive what Robert
  suggests.
 
  Thanks,
  Ricky
 
 
 
 
 
  On Thu, May 5, 2011 at 20:47, Robert Osfield robert.osfi...@gmail.com
  wrote:
 
  HI All,
 
 
  Current the OSG does unbind VBO's at the end of
  osg::Geometry::drawImplementation(..) so that VBO and EBO state
  doesn't leak into adjoining Drawables.  If an implementation is known
  to only use VBO's, with no display lists then potentially we could not
  bother with the unbind at the end of Geometry::drawImplemenation() and
  use lazy state updating.
 
  Robert.
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

Re: [osg-users] large VBOs for multiple Drawables

[Riccardo Corsi]

Hi All,

I revamp this thread as my question is strictly related, as I'm trying to
pack multiple geometries into shared VBO.

I'm creating a shared osg::Vec3Array for vertices,
same for as many vertex attribute as I need,
and then assigning these shared arrays to the different geometries
(pGeom-setVertexArray() and pGeom-setVertexAttribArray() )
and telling the geometry to use VBO and not display lists.

Then I create a new DrawElements for each geometry, with the correct vertex
indices offset,
and as I want them to share the same EBO underneath,
I'm trying with:
pDrawElemsUInt-setElementBufferObject(pSharedEBO);
pGeom-addPrimitiveSet(pDrawElemsUInt);

But I think I' missing something because, with gDebugger, I see that there
are as many bindBuffer calls as num-geom * num-shared-buffers.

Am I wrong in the way I try to share the drawElems EBO? Or missing something
else?
Thank you!

Ricky




On Mon, Jan 3, 2011 at 19:31, Jason Beverage jasonbever...@gmail.comwrote:

 Hi Terry,

 I was generating all my geometry in code so I wrote some custom code
 to pack them tightly into a single vertex array.

 Jason

 On Mon, Jan 3, 2011 at 1:05 PM, Terry Welsh mogu...@gmail.com wrote:
  Hi Jason,
  Thank you for the suggestion.  I feel like I'm missing something
  still.  Is there an Optimizer feature or something that combines
  Arrays for you?  Or did you write a bunch of custom code that
  processes your models after you load them?
  --
  Terry Welsh
  mogumbo 'at' gmail.com
  www.reallyslick.com
 
 
 
  Message: 3
  Date: Sun, 2 Jan 2011 21:28:12 -0500
  From: Jason Beverage jasonbever...@gmail.com
  To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
  Subject: Re: [osg-users] large VBOs for multiple Drawables
  Message-ID:
 aanlktin2mdb-vewdrpkp0rwjxcok2jm4o0vdx31ao...@mail.gmail.com
  Content-Type: text/plain; charset=ISO-8859-1
 
  Hi Terry,
 
  You can pack the verts of your small objects into a single
  osg::Vec3Array and share that array across multiple osg::Geometry
  objects then use DrawElements for each geometry with the correct
  indices.  I've just recently done this actually for a project I'm
  working on and it's worked out great.
 
  Thanks,
 
  Jason
 
  On Sat, Jan 1, 2011 at 6:21 PM, Terry Welsh mogu...@gmail.com wrote:
  I found some email threads that hinted at this a little, but nothing
  seemed very specific. ?I have scenes where display lists perform a bit
  better than VBOs. ?My best guess is because my objects have relatively
  small vertex counts (usually between 20 and 200). ?Is there any way in
  OSG to use one large VBO to store the date for multiple Drawables in
  order to minimize buffer state changes?
  --
  Terry Welsh
  mogumbo 'at' gmail.com
  www.reallyslick.com
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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