Re: [osg-users] [osganimation branch] Review, test, critics

[Julien Valentin]

Thanks Raymond
I pr the branch to master
Cheers


reedev wrote:
> Hi Julien, Robert,
> 
> The fix in the osganimation branch is working with VS2015 too. Fyi, the 
> original nathan.osg in git is also working ok. Nice :-)
> 
> Cheers,
> Raymond
> 
> 
> 
> 
> On 11/6/2017 7:40 AM, Raymond de Vries wrote:
> 
> 
> >   Hi Julien,
> > 
> > Thanks for sharing. I will look at it this week, hopefully others can jump 
> > in too.
> > 
> > Cheers,
> > Raymond
> > 
> > 
> > 
> > On 11/3/2017 8:08 PM, Julien Valentin wrote:
> > 
> > 
> > >  
> > > > reedev wrote:
> > > > 
> > > > > Hi Julien,
> > > > > 
> > > > > Could you let me/us know to which mail you attached your modified 
> > > > > nathan? I can't find it. Can you let me/us know or send it directly?
> > > > > 
> > > > > Cheers
> > > > > Raymond
> > > > > 
> > > > > 
> > > > > 
> > > > > On 11/2/2017 7:30 PM, Julien Valentin wrote:
> > > > > 
> > > > > 
> > > > > > Hi
> > > > > > I'm a bit concerned about the nathan.osg compatibility with 
> > > > > > RigTransHW..
> > > > > > I attached in my last a modified version of nathan (without shared 
> > > > > > ss) that should work (and so would replace the current one in 
> > > > > > osgdata).
> > > > > > 
> > > > > > I would be glad if Raymond (or other) could validate this model 
> > > > > > (ideally under win32) with the following tests
> > > > > > softwaretest : osganimationviewer nathan2.osg
> > > > > > HWtest:  osganimationhardware --number 1 nathan2.osg
> > > > > > (Don't forget I changed the maxnumbones type from int to uint in 
> > > > > > skinning.vert )
> > > > > > Once these tests validated elsewhere than my computer, It will 
> > > > > > confort me in the validity of the branch so i can make PRs to 
> > > > > > master (and to osgdata).
> > > > > > 
> > > > > > Cheers
> > > > > > 
> > > > > > 
> > > > > > robertosfield wrote:
> > > > > > 
> > > > > > 
> > > > > > > Hi Raymond & Julien,
> > > > > > > 
> > > > > > > On 2 November 2017 at 14:17, Raymond de Vries < ()> wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > I have not seen any issues in our own use of the osgAnimation. 
> > > > > > > > We tested in a few different setups and all seems ok.
> > > > > > > > 
> > > > > > > > The only thing is that the example did not work for me with 
> > > > > > > > Visual Studio 2015, while it does work for Julien.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > >  Thanks for the testing.
> > > > > > > 
> > > > > > > 
> > > > > > > Julian, if you feel osganimation is now ready could you generate 
> > > > > > > a PR for the branch and I'll go ahead and merge it.
> > > > > > > 
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > Robert.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Post generated by Mail2Forum
> > > > > > > 
> > > > > > > 
> > > > > >  --
> > > > > > Read this topic online here:
> > > > > > http://forum.openscenegraph.org/viewtopic.php?p=72293#72293 
> > > > > > (http://forum.openscenegraph.org/viewtopic.php?p=72293#72293)
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ___
> > > > > > osg-users mailing list
> > > > > > 
> > > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > > > >  
> > > > > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > > > > 
> > > > > > 
> > > > > > ---
> > > > > > This email has been checked for viruses by AVG.
> > > > > > http://www.avg.com (http://www.avg.com)
> > > > > > 
> > > > > > 
> > > > >  ___
> > > > > osg-users mailing list
> > > > > 
> > > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > > >  
> > > > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > > > 
> > > > > --
> > > > > Post generated by Mail2Forum
> > > > > 
> > > >  
> > > > --
> > > > Read this topic online here:
> > > > http://forum.openscenegraph.org/viewtopic.php?p=72299#72299 
> > > > (http://forum.openscenegraph.org/viewtopic.php?p=72299#72299)
> > > > 
> > > > 
> > > > 
> > > > 
> > >  
> > > 
> > > 
> > > > ___
> > > > osg-users mailing list
> > > >  ()
> > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > > >  
> > > > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > > > 
> > >  
> >  
> > 
> >  
> > (http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient)
> >  Virus-free. www.avg.com 
> > (http://www.avg.com/email-signature?utm_medium=email_source=link_campaign=sig-email_content=emailclient)
> >   (#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2)
> > 
> > 
> > 
> > > Hi Julien,
> > > 
> > > Could you let me/us know to which mail you attached your modified 
> > > 

Re: [osg-users] [osganimation branch] Review, test, critics

[Raymond de Vries]

Hi Julien, Robert,

The fix in the osganimation branch is working with VS2015 too. Fyi, the 
original nathan.osg in git is also working ok. Nice :-)


Cheers,
Raymond




On 11/6/2017 7:40 AM, Raymond de Vries wrote:

Hi Julien,

Thanks for sharing. I will look at it this week, hopefully others can 
jump in too.


Cheers,
Raymond



On 11/3/2017 8:08 PM, Julien Valentin wrote:

reedev wrote:

Hi Julien,

Could you let me/us know to which mail you attached your modified
nathan? I can't find it. Can you let me/us know or send it directly?

Cheers
Raymond



On 11/2/2017 7:30 PM, Julien Valentin wrote:


Hi
I'm a bit concerned about the nathan.osg compatibility with RigTransHW..
I attached in my last a modified version of nathan (without shared ss) that 
should work (and so would replace the current one in osgdata).

I would be glad if Raymond (or other) could validate this model (ideally under 
win32) with the following tests
softwaretest : osganimationviewer nathan2.osg
HWtest:  osganimationhardware --number 1 nathan2.osg
(Don't forget I changed the maxnumbones type from int to uint in skinning.vert )
Once these tests validated elsewhere than my computer, It will confort me in 
the validity of the branch so i can make PRs to master (and to osgdata).

Cheers


robertosfield wrote:


Hi Raymond & Julien,

On 2 November 2017 at 14:17, Raymond de Vries < ()> wrote:



I have not seen any issues in our own use of the osgAnimation. We tested in a 
few different setups and all seems ok.

The only thing is that the example did not work for me with Visual Studio 2015, 
while it does work for Julien.



Thanks for the testing.


Julian, if you feel osganimation is now ready could you generate a PR for the 
branch and I'll go ahead and merge it.


Cheers,
Robert.



--
Post generated by Mail2Forum


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





___
osg-users mailing list

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


---
This email has been checked for viruses by AVG.
http://www.avg.com


___
osg-users mailing list

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

  --
Post generated by Mail2Forum

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





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



 
	Virus-free. www.avg.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>


___
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] Access to gl context

[Poojan Prabhu]

Hi,

We are using shared context, but have custom drawables that use Vertex Array 
Objects. This causes a problem in the case of multiple windows (where each is a 
separate gl context). 

We can manage/create vaos depending on the gl context id that we are currently 
rendering with.

But, we can't use context id as reported by render info, because that 
represents the shared context id and not the HGLRC

Prefer to avoid wglGetCurrentContext in each draw call obviously. And we _do_ 
want to use shared contexts.

How can we work around this so that we have access to the HGLRC or an id 
representing it?

Thank you!

Cheers,
Poojan

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





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

Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext

[Robert Osfield]

Hi Ben,

On 10 November 2017 at 11:11, Ben Meijering  wrote:
> Isn't an opengl context already used by multiple windows when you use 
> GraphicsContext::Traits::sharedContext ?

No.  Sharing a GL object is not sharing the whole context.

If you want to continue trying to hack some kind of solution then go
for it, I really don't think it's worth pursing, but it's your time.
At this point I have provided what insight I can, but I can't help you
further than advice.

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

Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext

[Ben Meijering]

Hi Robert,

Thanks again for your quick response.

Isn't an opengl context already used by multiple windows when you use 
GraphicsContext::Traits::sharedContext ?

I also came across the following function:

BOOL WINAPI wglMakeCurrent(
   HDC   hdc,
   HGLRC hglrc
);

A window device context can be specified here, so it would seem that you can 
change the window.

I also came across the following:

https://blog.gvnott.com/some-usefull-facts-about-multipul-opengl-contexts/

This also seems to state that a single opengl context can be used to render to 
multiple windows.

Thank you!

Cheers,

Ben

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





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

Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext

[Robert Osfield]

Hi Ben,

On 10 November 2017 at 09:41, Ben Meijering  wrote:
> I want this 1 opengl context to be shared by multiple windows.

I am afraid OpenGL doesn't work in this way, an OpenGL context is tied
to a single window or pixel buffer.

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

Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext

[Ben Meijering]

Hi Robert,

Thank you for your response.

I don't want to share the context or GL objects in multiple threads.
Basically what I want is 1 draw thread for the 1 opengl context if have and 1 
cull thread.

I want this 1 opengl context to be shared by multiple windows.
However, for each window that I create, a new draw thread is created, even when 
they share the same opengl context.

So I was hoping that it was possible to have 1 draw thread per opengl context, 
instead of 1 draw thread per window (GraphicsContext).

The opengl context would only be used by one thread, so thread safety shouldn't 
be an issue right?

Cheers,

Ben

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





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

Re: [osg-users] Draw thread per opengl context instead of per GraphicsContext

[Robert Osfield]

Hi Ben,

Neither the OSG or OpenGL can provide thread safe sharing of GL
objects when sharing contexts.  If you want to run multiple context
with multiple threads you will have to keep these contexts
independent.

Robert.

On 9 November 2017 at 14:23, Ben Meijering  wrote:
> Hi everyone,
>
> I want to use the GraphicsContext::Traits::sharedContext to render multiple 
> views (in multiple windows) that share the same context.
>
> I already read on some forums that the ThreadingModel::SingleThreaded  should 
> be used.
>
> However, I would still like to use ThreadingModel::DrawThreadPerContext so 
> that the cull and draw thread can overlap.
>
> I tried this, but a draw thread is created per GraphicsContext and thus per 
> window. Because all these windows share an opengl context, I would have 
> expected that only 1 thread would have been created.
>
> This results in all sorts of problems.
>
> Is there a way in which I can use 1 draw thread per opengl context ?
> And, if not, is this something that I can easily change by modifying the code 
> ?
>
> Thank you!
>
> Cheers,
> Ben
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=72344#72344
>
>
>
>
>
> ___
> 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] Correct way to modify scene graph [SEC=UNCLASSIFIED]

[Robert Osfield]

Hi Russel,

On 9 November 2017 at 03:49, Thamm, Russell
 wrote:
> Currently, if I want to actually modify the scene graph (adding, deleting
> nodes etc) while the render thread is running I do the following:
>
> parentNode->setNodeMask(0);
>
> modify scene graph below parent node
>
> parentNode->setNodeMask(~0);
>
> This seems to work but is there a better way?

OpenSceneGraph is quite a different beast to plib so there will be
quite a few advanced scene graphs concepts that you will likely need
to learn as you transition, this can be quite daunting but hopefully
it'll make sense once you work progresses.

The OSG osgViewer frame is broken down and managed in such a way a to
enable multi-threded, multi-graphics context/window/pipe usage, the
update, event traversals are all run from the main thread, it's these
phases of the frame that nodes of the scene graph would be modified.

The rendering traversals phase pairs cull and draw traversals for each
viewer Camera, these may be run SingleThreaded, CullDrawPerContext,
DrawThreadPerContext or CullTheadPerCameraDrawThreadPerContext
threading models (you set this with viewer.setThreadingModel().

For the SingleThreaded and CullDrawThreadPerContext the next frame is
held back till all the geometry and state data has been dispatched
into the OpenGL FIFO, so anything directly after the viewer returns
from viewer.renderingTraversals() you can begin modifying all parts
the scene graph without any worry about other per graphics context
threads running as they will all be iddlying waiting for the next
frame,

For DrawThreadPerContext and CullThreadPerCameraDrawThreadPerContext
threading models the next frame is allowed to commence as soon as all
of the DYNAMIC Geometry and StateSet in the rendering backends data is
dispatched into the OpenGL FIFO.  None of the internal nodes of the
scene graph are recorded into the rendering backend data structures so
you can actually modify these as soon as the cull traversal is
complete.  In general though one should still just wait till
renderingTraversals is complete before you start modifying - basically
keep things simple where possible, and only try to start to be
"clever" once you know that the defaults aren't going to perform well
enough.  For the vast majority of OSG users they don't need to try to
implement extra complicated code to manage scene graph updates.

For you I'd recommend just starting with updating nodes in the update
phases, and if you are updating osg::Geometry or osg::StateSet
contents then simply set the DataVariance property of these objects
you are dynamically updating to DYANMIC so the draw traversal knows to
hold back returning from renderingTraversals() till all these have
been updated.

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

Re: [osg-users] TBN Matrix for Normal Mapping - OSG and GLSL

[Robert Osfield]

Hi Rômulo,

On 8 November 2017 at 21:46, Rômulo Cerqueira
 wrote:
> thanks for your replies. I will have a look on osg::TangentSpaceVisitor, 
> however I have a question: I will have in my OSG scene a lot of objects 
> with/without normal mapping. How can I handle different normal textures using 
> the same osg::TangentSpaceVisitor?

To tailor the behavior to suit your scene graph usage case you could
subclass from the TengentSapceVisitor and add your own checks for
traversal.

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

Re: [osg-users] Osg 3.4.1 - Tutorial 12 Fails on Mac OSX Sierra - Framebuffer problem

[Robert Osfield]

Hi Jeff,

Could you provide a reference for the tutorial set that you are
referring to as the core OpenSceneGraph does have such a set.  This
will help others know what you are actually trying to work so can test
it themselves or provide some background knowledge on the issue.

Thanks,
Robert.


Robert.

On 4 November 2017 at 12:32, Jeff Sprenger  wrote:
> I have just built 3.4.1 from github on the mac (MacOS Sierra, 10.12.6). The 
> early tutorials Tut2 etc work fine.  Tutorial 12, which introduces shadows, 
> runs but dumps out warning messages. No shadows appear.
>
> here is the console output:
>
>
> Code:
>
> StatsHandler::StatsHandler() Setting up GL2 compatible shaders
> Warning: FrameBufferObject: could not create the FBO
> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0
> FRAGMENT glCompileShader "" FAILED
> glLinkProgram 0x7fb62e676ea0"" FAILED
> Warning: FrameBufferObject: could not create the FBO
> RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x0
>
>
>
>
> How to I fix or investigate the problem with failing to create the FBO?
> [/code]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=72304#72304
>
>
>
>
>
> ___
> 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