Re: [osg-users] Thoughts on Vulkan

[Cor Jansen]

robertosfield wrote:
> 
> 
> This is not far from my own viewpoint.  I do have a rough plan in mind that 
> is still evolving. I'll open my own thoughts for discussion once OSG-3.4 is 
> out the door.
> 
> 


What is the status of this white paper?
I really would like to discus this.

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





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

[osg-users] [3rdparty] libAgar GUI in the OpenSceneGraph

[Nickolai Medvedev]

Hi,

I recently found the GUI library - libAgar. Has anyone used it together with 
OpenSceneGraph? 

Thank you!

Cheers,
Nickolai

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





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

Re: [osg-users] Migration from OSG 3.1.5 to 3.4.0 / Qt 4 to Qt 5

[Robert Osfield]

HI Andrew

The issue revolves around the default osg::Camera constructing without
a StateSet, in this default state it doesn't set any state when you
attach it to a Viewer.  It leaves the responsibility up to you as the
developer to set up the state which is appropriate for your viewer.
Prior to OSG-3.2 a bug in osgUtil::SceneView overridded the state set
by the viewer's Camera adding in it's own global settings - this meant
you couldn't set your own which is the bug, but had a side affect of
hiding the lack of set global state by adding in some defaults, so
your application looked like it was fine even though it wasn't setting
state that it should have been doing.

The View(er) itself has osg::Camera and by default it sets up Camera
StateSet with with some defaults appropriate for viewer by calling
StateSet::setGlobalDefaults().  This means that by default the viewer
actually enables depth test etc.  However, if you replace the View(er)
Camera's without your own without the state set up in a similar way it
breaks.

The original Qt example replaced the Camera and didn't set up state so
if you ported it to OSG-3.2 or later it.  In Qt and other examples in
OSG-3.2 and later the View's Camera is used directly rather than
assigned a new one.

If you still want to assign your own Camera (something this is
actually unnecessary) you should set up the global state that you
want, sensible defaults for a 3d viewer are set up by:

   view.getCamera()->getOrCreateStateSet()->setGlobalDefaults();

If you don't do this then you application will be using OpenGL defaults.

Robert.



On 4 January 2016 at 22:57, Andrew Cunningham  wrote:
> [quote="robertosfield"]Hi Andrew
> The reason why z buffer etc. Is off is the your setup hasn't set it up as 
> there is no global stateset to the camera you are passing to the Viewer.
> I have discussed this topic quite a but since OSG-3.2. Please see the 
> archives.
> Robert. [quote]
>
> OK thanks, but my forum searching did not turn up much on this topic. Wrong 
> keywords I suppose.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65940#65940
>
>
>
>
>
> ___
> 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] Thoughts on Vulkan

[Robert Osfield]

On 29 December 2015 at 23:30, Cor Jansen  wrote:
> What is the status of this white paper?

Afraid I've been too busy with client work to write it yet.

> I really would like to discus this.

As a spare time activity I've begun design work exploring what a next
gen scene graph that supports multiple graphics APIs that would
include OpenGL/GLES and Vulkan.  I have many sheets of white paper
with writing and diagrams on but none of it is in a form that can be
published and when I get a time slot I'll dive in a start
experimenting with the implementation side.

The general gist is I don't believe the OSG itself can be morphed to
support a radically new API like Vulkan without massively breaking the
existing OSG API.  We either retain the bulk of the existing OSG API,
stay focused on OpenGL/GLES and retain our existing user base or we
break the API in extensive ways to support Vulkan and accept that we
won't carry the majority of the existing community with us.

In my design work on a next gen scene graph I have sought ways of
making it compatible with existing OSG applications so users could bit
by bit move across when they feel the need.  In you'd want to move
across to Vulkan and still use the OSG one would need to replace
extensive parts of the OSG scene graph across to the next gen scene
graph. It may be even appropriate at some point to enable a build of
the OSG that doesn't have any OpenGL calls, so that the whole
GL/Vulkan calls are deferred to the next gen scene graph.

Exactly what this next gen scene graph would look like and the exact
mechanics of integration of the OSG is not something I can say yet -
original designs very often don't survive implementation.  For the OSG
community though I have the intention to try and make this integration
possible.  My clients are all OSG users so there is plenty of
motivation for me to make sure this path works out as well.  So I
won't be turning my back on the OSG and it's community.

I can't really say too much more at this point.  Vulkan hasn't been
released yet.  I haven't begun implementing the next gen scene graph
that wafting around my head and on bits of paper.  The only big
decisions I've made so far is that a new scene graph would be written
in C++11, use it's threading etc, support multiple graphics APIs and
be possible to integrate it with OSG and other applications and will
be open source.

When concrete progress happens I will keep the OSG community involved.

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

[osg-users] [osgPlugins] osgPlugins / ive

[D. Christopher Fennell]

Hello,

Since Drawables can have description lists, Drawable.cpp should write out 
osg::Node instead of osg::Object. 

The same is true for the read.

Thanks,
Chris

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





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

Re: [osg-users] Dynamic terrains, DatabasePager + PagedLODs

[Nickolai Medvedev]

Hi, Daniel

You found the solution?

I try to make similarity of game with OSG, but
also it isn't clear to me how to make dynamic
terrain. Vertex Displacement through a shader
looks very well, but there is a problem - vertices
heights don't remain in geode, they is generated
in the course of work of the program. Therefore
it is necessary to use tessellation shader.

Thank you!

Cheers,
Nickolai

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





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

Re: [osg-users] Dynamic terrains, DatabasePager + PagedLODs

[Chris Hanson]

Personally, I'd be using osgEarth myself. It supports on the fly terrain
vertex height modification by shaders and other heightmaps if needed.

On Tue, Jan 5, 2016 at 10:08 AM, Nickolai Medvedev 
wrote:

> Hi, Daniel
>
> You found the solution?
>
> I try to make similarity of game with OSG, but
> also it isn't clear to me how to make dynamic
> terrain. Vertex Displacement through a shader
> looks very well, but there is a problem - vertices
> heights don't remain in geode, they is generated
> in the course of work of the program. Therefore
> it is necessary to use tessellation shader.
>
> Thank you!
>
> Cheers,
> Nickolai
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65947#65947
>
>
>
>
>
> ___
> 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 • Code Forensics • Digital Imaging • 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

Re: [osg-users] Dynamic terrains, DatabasePager + PagedLODs

[Nickolai Medvedev]

Hi, Chris

I don't think that osgEarth and VirtualPlanetBuilder are suitable for creation 
of games. They have too many unnecessary bindings. 

Thank you!

Cheers,
Nickolai

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





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

Re: [osg-users] Dynamic terrains, DatabasePager + PagedLODs

[Robert Osfield]

On 5 January 2016 at 17:53, Nickolai Medvedev  wrote:
> Hi, Chris
>
> I don't think that osgEarth and VirtualPlanetBuilder are suitable for 
> creation of games. They have too many unnecessary bindings.

VirtualPlanetBuilder just creates paged databases in native OSG
format, it's not an dependency on final graphics application - you use
the databases with vanilla OSG applications.

osgEarth does add extra dependencies but most of these will be optional.

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

Re: [osg-users] Dynamic terrains, DatabasePager + PagedLODs

[Nickolai Medvedev]

Hello, Robert.

In VirtualPlanetBuilder there is no "manual" control, to be exact - it is 
impossible to specify the fixed quantity of triangles or vertices, or the 
landscape size. Why so?

Thank you!

Cheers,
Nickolai

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





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

Re: [osg-users] Dynamic terrains, DatabasePager + PagedLODs

[Chris Hanson]

Well, then you can just hack on heightfields manually and stick a shader on
there.

On Tue, Jan 5, 2016 at 10:53 AM, Nickolai Medvedev 
wrote:

> Hi, Chris
>
> I don't think that osgEarth and VirtualPlanetBuilder are suitable for
> creation of games. They have too many unnecessary bindings.
>
> Thank you!
>
> Cheers,
> Nickolai
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65950#65950
>
>
>
>
>
> ___
> 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 • Code Forensics • Digital Imaging • 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] OpenThreads won't stop on Windows...

[Shayne Tueller]

Hi,

I'm using OpenThreads in an app that's using osgEarth. When I go to stop the 
thread, I call the cancel() method but it doesn't seem to be working. The 
thread is still running. Is there something else I need to do to stop the 
thread and shut it down? I have a stopThread() method that breaks out of my 
loop in the run() method, however, the thread is sometimes paused in execution 
inside the loop when I go to shut it down. I need to stop the thread 
unconditionally when I go to exit. I thought cancel() would do it but it 
doesn't work.

Thoughts?

Thank you!

Shayne

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





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

Re: [osg-users] Testing osgUI library

[Robert Osfield]

Hi Rocio,

I haven't yet had a chance to test the example (it's holidays here :-)
but in principle it should be possible to use osgUI within a HUD as
well as in the 3D scene.  One of the motivations for developing osgUI
was the need to have a GUI in a 3D scene with full stereo rendering
(HMD's and powerwalls) so this is where I've done all the testing.

My best guess for why it isn't working in the HUD case is a precision
issue with the intersection routines. As a test try rotating the GUI
very slightly so it has some depth rather being planner.  If this gets
things working then we know that it's an issue with intersection tests
and these need to be adapted to handle the planar HUD case.

Robert.

On 23 December 2015 at 12:12, Rocio Tortajada
 wrote:
> Hi!
>
> I've tried the osgUI library. I loaded the TabWidget.lua from the osg-data
> into the scene and when I clicked on the tabs it worked as expected
>
> The problem arises when I added the TabWidget in the HUD camera, as far as
> we tested the intersections to the widget seems not to be working. Is the
> osgUI library supporting HUD cameras?  Are we missing something?
>
> Find attached an example with my test code, on the left of the scene there
> is a 3D TabWidget and on the right there is a TabWidget inside the HUD
> camera. The test is very simple, but  if you find it interesting it can be
> added to the OSG examples.
>
> Thank you!
>
> Rocío
>
> ___
> 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] Enable, Disable Multible Shaders

[Robert Osfield]

Hi Brain,

OpenGL program/shaders can't be enabled/disabled using
glEnable/glDisable so the OSG can't enable/disable them through this
mechanism.  The only way to disable a shader in OSG is assign a null
(empty) osg::Program to a StateSet that decorates the subgraph that
you want to disable the shaders for.  Another approach is to avoid
placing an osg::Program above the whole scene graph, instead keep it
local where it's needed so it doesn't switch it one for all subgraphs.

On 25 December 2015 at 19:28, Brian Perry  wrote:
> Hi,
>
> I having a similar problem with stateset.  I have a program where all the 
> geometry has a shader attached at the point of loading.  There is one object 
> in this entire database of objects that have shaders attached to it somewhere 
> and is causing this object to cast a shadow based on a singular shader based 
> light source.  I tried to solve this problem by disabling the PROGRAM state 
> attribute but disabling doesn't seem to prevent it from casting a shadow.  I 
> don't understand though.  I can get the node for these objects and derive the 
> state sets from those nodes but I can't seem to disable the object from 
> casting a shadow.  Someone told me that there are attributes on textures and 
> geometry that allow you to make it so that texture or geometry doesn't cast a 
> shadow.
>
> Thank you!
> Brian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65923#65923
>
>
>
>
>
> ___
> 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] Enable, Disable Multible Shaders

[Brian Perry]

Hi,

Thank you for the reply.  I actually found another solution that was a better 
solution than turning off shaders by the stateset.  Originally, I just wanted 
to turn off shaders for a stateset so that the objects in that stateset would 
not cast a shadow.  I though that this would work because the entire scenegraph 
has been created in a way so that all objects displayed are rendered through a 
shader.  I did some research and found out there was a way to disable shadows 
in the scenegraph.  I was skeptical at first that this would work but turning 
off the bit for casting shadows worked.  It was a lot more elegant solution to 
use than turning off shaders for the object.  I tried putting in an empty 
program object and that didn't work.  This was the only thing that worked.

Thank you!

Cheers,
Brian

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





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