Re: [osg-users] How to implement a Laser Simulation?

[Chris Hanson]

Is this like a scanning sweep laser beam?

I'd model it as a triangular frustum with a texture on it generated by a
shader with some kind of animated fBm (Fractal Brownian Motion) noise.

Is this a work project or school or what?

On Fri, May 24, 2019 at 7:35 PM Matheus Santos 
wrote:

> Hi, I need to implement a laser inside an underwater simulation. The
> simulation uses the physics from the gazebo and renders the scene with OSG.
> Now I need to project a green laser (vertical or horizontal) from the
> robot, inside the scene. I have no idea how to do something like that (and
> have almost 0 experience with OSG). Can someone help me? Any help is
> welcome (suggestion, links, specific tutorials, GitHub repositories,
> videos, etc...), I tried to find some code but didn't help so much.
>
> So, I'm completely lost :o
>
> ...
>
> Thank you!
>
> Cheers,
> Matheus
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=76140#76140
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel  facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] How to implement a Laser Simulation?

[Matheus Santos]

Hi, I need to implement a laser inside an underwater simulation. The simulation 
uses the physics from the gazebo and renders the scene with OSG. Now I need to 
project a green laser (vertical or horizontal) from the robot, inside the 
scene. I have no idea how to do something like that (and have almost 0 
experience with OSG). Can someone help me? Any help is welcome (suggestion, 
links, specific tutorials, GitHub repositories, videos, etc...), I tried to 
find some code but didn't help so much.

So, I'm completely lost :o

... 

Thank you!

Cheers,
Matheus

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





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

Re: [osg-users] Running multiple (independent) viewers in different threads

[Robert Osfield]

Hi Antoine,

It's not possible to know what is causing the issues with running your
setup from your description, stack trace of the seg fault is the bare
minimum for starting to guess at what might be the issue.  It could be
an OSG bug as you are not using the OSG how it's intended or usually
used, or it could be an error in your application, or in the driver.

As a general note, graphics hardware is geared up for massive
parallelism at the vertex and fragment level but, in particular
OpenGL, is less engineered for multiprocessing at the higher level.
Vulkan is better in this respect but still having many graphics
context and associated threads running is going to contend the memory
and buses.

>From your description it may be most efficient to have multiple
threads handling the sim side and have it post requests into a thread
safe queue that is read from the graphics thread and have that
graphics thread deal with all the work in series and send it into the
OpenGL FIFO and when the results are provided then signal the original
requests for rendering.  This scheme could keep the OSG/OpenGL side
down to using one graphics context and one graphics thread so this
side most efficiently.

A Vulkan based approach could move more of the work to the original
threads requesting the work as they can build their own
VkCommandBuffers that get submitted into a graphics or compute queue
for dispatch to the processing on graphics/compute on the GPU.

While in theory the VSG work could do the above I haven't attempted
this type of work before and have built into any architecture for it
specifically, longer term this is something it'll support.  The VSG is
really just in a alpha state at this point and under heavy development
so I wouldn't yet recommend general adoption, it might be worth
thinking about though if rendering you want to do is quite simple but
very specialized.

If you want to continue using the OSG then I'd recommend the queue
approach, with your creating a high level architecture that abstracts
away the work request from the OSG backend that deals with the work.

Cheers,
Robert.

On Fri, 24 May 2019 at 12:17, Antoine Cully  wrote:
>
> Dear OSG Community,
>
> I searched quite a lot through the source code and the beginner guide, but I 
> was unable to find a way to make this work, so I am posting here hoping that 
> you could help me.
>
> I am developing a tool to run physical simulations (of robots) in parallel. 
> This tool is used to run stochastic optimisation (like deep reinforcement 
> learning) algorithms, and for this I need to be able to run several, but 
> fully independent, simulations in parallel thanks to multithreading. This 
> enables to collect data faster and for instance with a 32-core multithreaded 
> CPU the speed-up factor is quite significant.
>
> In each simulation, I have one camera that observes the environment, and 
> which can be used to change the behaviour of the robot running in this 
> simulation. The camera is currently implemented as a pbuffer following 
> closely the osgscreencapture example. The actual code of the camera can be 
> found on github, but apprently I am not allowed to post URLs at the moment.
> The multithreading is managed by TBB (an Intel library that I have been using 
> for 6 years now).
>
> If I run my code in a "sequential mode", i.e., all the simulations running 
> one after the other, everything is going well.  However, if I run it in 
> parallel, then I have some unstable behaviours. For instance, I can have a 
> segmentation fault happening after a random number of simulations or suddenly 
> after again a random number of simulations, the pbuffer cannot be created 
> anymore (OSG displays "Error: Unable to create pbuffer."). It seems to me 
> that "::osg::ref_ptr<::osg::GraphicsContext> pbuffer =  
> ::osg::GraphicsContext::createGraphicsContext(traits.get()); "
> does not work in this setup.
>
> If I remove the cameras (and all OSG components) from my code, it is working 
> well in parallel, but of course I would like to have cameras in my 
> simulations.
>
> Ideally, I would like to run OSG in a single-thread mode and let TBB 
> distribute the different instances of the simulator and OSG in different 
> threads, but even with 
> "setThreadingModel(osgViewer::ViewerBase::ThreadingModel::SingleThreaded);" 
> it does not work.
> I tried different threading modes, with the same result.
>
> So here is my question:
> What would be the most appropriate way to run several independent viewers and 
> pbuffers, each in a different thread?
> The rendered scenes are really simple (no texture, just several primitive 
> shapes) and I am only rendering a couple of frames in each simulation, so I 
> don't need a complex threading model for OSG.
>
>
> Some information about my system:
> - Ubuntu 18.04
> - OSG 3.6.4
>
> Thank you in advance for your help.
>
> Best regards,
>
> Antoine
>
> --
> Read this topic online here:
> 

Re: [osg-users] Running multiple (independent) viewers in differentthreads

[Garfield Pig]

Hi Cully,
It seems like the problem that split window or frame buffer to different 
part.
There are two way to do this in osg.
1.add slave camera to osgViewer::view,each camera has different 
graphiccontext.
2.add osgViewer::view to osgViewer::compositeViewer,and one osgViewer::view 
correspond one camera,and has the same graphiccontext.


method 1 prefer the situation that each camera has different view or proj 
matrix but has same node tree.like Virtual Reality rendering,or cad design.
method 2 prefer each view(camera) has independent node tree.Like multi-doc edit 
in Word.


And the thread problem,I think you'd better do update in osg update thread,like 
add updateCallback to node.By this way,your thread will not have sync problem 
with osg render thread.


To be honest,I don't pretty understand your problem.
you'd better simplify your code to a problem example.


Qi Yu.
-- Original --
From: "Antoine Cully";
Date: Thu, May 23, 2019 00:49 AM
To: "osg-users";

Subject: [osg-users] Running multiple (independent) viewers in differentthreads



Dear OSG Community, 

I searched quite a lot through the source code and the beginner guide, but I 
was unable to find a way to make this work, so I am posting here hoping that 
you could help me. 

I am developing a tool to run physical simulations (of robots) in parallel. 
This tool is used to run stochastic optimisation (like deep reinforcement 
learning) algorithms, and for this I need to be able to run several, but fully 
independent, simulations in parallel thanks to multithreading. This enables to 
collect data faster and for instance with a 32-core multithreaded CPU the 
speed-up factor is quite significant. 

In each simulation, I have one camera that observes the environment, and which 
can be used to change the behaviour of the robot running in this simulation. 
The camera is currently implemented as a pbuffer following closely the 
osgscreencapture example. The actual code of the camera can be found on github, 
but apprently I am not allowed to post URLs at the moment. 
The multithreading is managed by TBB (an Intel library that I have been using 
for 6 years now). 

If I run my code in a "sequential mode", i.e., all the simulations running one 
after the other, everything is going well.  However, if I run it in parallel, 
then I have some unstable behaviours. For instance, I can have a segmentation 
fault happening after a random number of simulations or suddenly after again a 
random number of simulations, the pbuffer cannot be created anymore (OSG 
displays "Error: Unable to create pbuffer."). It seems to me that 
"::osg::ref_ptr<::osg::GraphicsContext> pbuffer =  
::osg::GraphicsContext::createGraphicsContext(traits.get()); "
does not work in this setup. 

If I remove the cameras (and all OSG components) from my code, it is working 
well in parallel, but of course I would like to have cameras in my simulations. 

Ideally, I would like to run OSG in a single-thread mode and let TBB distribute 
the different instances of the simulator and OSG in different threads, but even 
with 
"setThreadingModel(osgViewer::ViewerBase::ThreadingModel::SingleThreaded);" it 
does not work. 
I tried different threading modes, with the same result.

So here is my question: 
What would be the most appropriate way to run several independent viewers and 
pbuffers, each in a different thread? 
The rendered scenes are really simple (no texture, just several primitive 
shapes) and I am only rendering a couple of frames in each simulation, so I 
don't need a complex threading model for OSG. 


Some information about my system:
- Ubuntu 18.04
- OSG 3.6.4

Thank you in advance for your help. 

Best regards, 

Antoine

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





___
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] Question about method of building osgQt

[Tim Whowantstoknow]

I ran into the same problem. I tried around a bit, and I got it to generate 
solution files with cmake.

First, open the CMakeLists.txt in the osgQt and edit line 95 and remove the 
"3.6.0" version number.

The result is then

Code:
FIND_PACKAGE(OpenSceneGraph REQUIRED osgDB osgGA osgUtil osgText osgViewer 
osgWidget)



Then configure everything in cmake and generate it. Even if you still get the 
error (I think I had it in the GUI when using configure, but not when using 
generate), it should generate the Visual Studio files (I was going for VS2017, 
so ymmv).

When I tried to compile, it didn't work though. This may have been a wrong 
setup on my side, but the include paths where absolute paths to the osgDB, 
osgGA, osgUtil, ... submoduls, rather than having only OpenSceneGraphs include 
file. 

Having changed that, I end up with a few errors of 

> C4430 missing type specifier - int assumed. Note: C++ does not support 
> default-int

and 

> C2146 syntax error: missing '>' before identifier 'GLFloat'

in the file GL, as well as

> C2065 'GLenum': undeclared identifier

in the file qopenglext.h

Usually this indicates that your project lacks the 
Code:
#include windows.h

 (this should be , but the forum somehow doesn't display that 
correctly) line, however that is obviously only for windows and I have tried 
including it in the osgQOpenGLWindow file, and that did not work. I will try a 
bit more and post, if I find the solution to that last problem

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





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

[osg-users] Running multiple (independent) viewers in different threads

[Antoine Cully]

Dear OSG Community, 

I searched quite a lot through the source code and the beginner guide, but I 
was unable to find a way to make this work, so I am posting here hoping that 
you could help me. 

I am developing a tool to run physical simulations (of robots) in parallel. 
This tool is used to run stochastic optimisation (like deep reinforcement 
learning) algorithms, and for this I need to be able to run several, but fully 
independent, simulations in parallel thanks to multithreading. This enables to 
collect data faster and for instance with a 32-core multithreaded CPU the 
speed-up factor is quite significant. 

In each simulation, I have one camera that observes the environment, and which 
can be used to change the behaviour of the robot running in this simulation. 
The camera is currently implemented as a pbuffer following closely the 
osgscreencapture example. The actual code of the camera can be found on github, 
but apprently I am not allowed to post URLs at the moment. 
The multithreading is managed by TBB (an Intel library that I have been using 
for 6 years now). 

If I run my code in a "sequential mode", i.e., all the simulations running one 
after the other, everything is going well.  However, if I run it in parallel, 
then I have some unstable behaviours. For instance, I can have a segmentation 
fault happening after a random number of simulations or suddenly after again a 
random number of simulations, the pbuffer cannot be created anymore (OSG 
displays "Error: Unable to create pbuffer."). It seems to me that 
"::osg::ref_ptr<::osg::GraphicsContext> pbuffer =  
::osg::GraphicsContext::createGraphicsContext(traits.get()); "
does not work in this setup. 

If I remove the cameras (and all OSG components) from my code, it is working 
well in parallel, but of course I would like to have cameras in my simulations. 

Ideally, I would like to run OSG in a single-thread mode and let TBB distribute 
the different instances of the simulator and OSG in different threads, but even 
with 
"setThreadingModel(osgViewer::ViewerBase::ThreadingModel::SingleThreaded);" it 
does not work. 
I tried different threading modes, with the same result.

So here is my question: 
What would be the most appropriate way to run several independent viewers and 
pbuffers, each in a different thread? 
The rendered scenes are really simple (no texture, just several primitive 
shapes) and I am only rendering a couple of frames in each simulation, so I 
don't need a complex threading model for OSG. 


Some information about my system:
- Ubuntu 18.04
- OSG 3.6.4

Thank you in advance for your help. 

Best regards, 

Antoine

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





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