Re: [osg-users] Volume image crash on the latest version of Nvidia driver

[Robert Osfield]

HI Clement,

Curious... but what I don't understand is how the Intel compiler was
progressing on to the if (num_iteration!=num_iterators) as this should only
be run on NVidia cards thank to the #idef NVIDIA_Corportion guard around it,

Are you backporting the shaders to 3,2,x?

Robert.

On 17 August 2015 at 07:33,  wrote:

> Hi Robert,
>
>I got funny volume display problem on intel card (it lost some opacity
> values).  I checked the shader code and I found the problem on handling NaN
> with using if statement.
>
> Your code is :
>
>  "if (num_iterations num_iterations = min_iterations;\n"
>  "else if (num_iterations>max_iterations)
> num_iterations = max_iterations;\n"
>  "else if (num_iterations!=num_iterations)
> num_iterations = max_iterations;\n"
>
>
>I checked NaN on wiki https://en.wikipedia.org/wiki/NaN.  The
> non-signaling value won't do standard comparison, so I changed the code as
> below.
>
>  "if (num_iterations!=num_iterations)
> num_iterations = max_iterations;\n"
>  "else if (num_iterations num_iterations = min_iterations;\n"
>  "else if (num_iterations>max_iterations)
> num_iterations = max_iterations;\n"
>
>   Check the value whether it is NaN on first condition and it works as
> normal on intel card now.
>
>
>
> Regards,
> Clement
>
>
> 
> From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of
> Robert Osfield [robert.osfi...@gmail.com]
> Sent: Wednesday, 12 August 2015 23:58
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Volume image crash on the latest version of
> Nvidia driver
>
> On 12 August 2015 at 14:47,  clement@csiro.au>> wrote:
> Hi Robert,
>
>   I have tested on both Intel and Nvidia machines.  The solution works
> without any issue.  Thanks.
>
> I have applied this fix to OSG-svn/trunk, OSG-3.2.3 and OSG-3.4.0 so we
> should now be good to go.
>
> 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] Volume image crash on the latest version of Nvidia driver

[Clement.Chu]

Hi Robert,

  Yes.  I am using 3.2.3 since I got a problem to show image in the center on 
3.4 (My program is using MFC).  Then I used 3.2.3.



Regards,
Clement



From: osg-users [osg-users-boun...@lists.openscenegraph.org] on behalf of 
Robert Osfield [robert.osfi...@gmail.com]
Sent: Monday, 17 August 2015 17:06
To: OpenSceneGraph Users
Subject: Re: [osg-users] Volume image crash on the latest version of Nvidia 
driver

HI Clement,

Curious... but what I don't understand is how the Intel compiler was 
progressing on to the if (num_iteration!=num_iterators) as this should only be 
run on NVidia cards thank to the #idef NVIDIA_Corportion guard around it,

Are you backporting the shaders to 3,2,x?

Robert.

On 17 August 2015 at 07:33, mailto:clement@csiro.au>> 
wrote:
Hi Robert,

   I got funny volume display problem on intel card (it lost some opacity 
values).  I checked the shader code and I found the problem on handling NaN 
with using if statement.

Your code is :

 "if (num_iterationsmax_iterations) 
num_iterations = max_iterations;\n"
 "else if (num_iterations!=num_iterations) 
num_iterations = max_iterations;\n"


   I checked NaN on wiki https://en.wikipedia.org/wiki/NaN.  The non-signaling 
value won't do standard comparison, so I changed the code as below.

 "if (num_iterations!=num_iterations) num_iterations = 
max_iterations;\n"
 "else if (num_iterationsmax_iterations) 
num_iterations = max_iterations;\n"

  Check the value whether it is NaN on first condition and it works as normal 
on intel card now.



Regards,
Clement



From: osg-users 
[osg-users-boun...@lists.openscenegraph.org]
 on behalf of Robert Osfield 
[robert.osfi...@gmail.com]
Sent: Wednesday, 12 August 2015 23:58
To: OpenSceneGraph Users
Subject: Re: [osg-users] Volume image crash on the latest version of Nvidia 
driver

On 12 August 2015 at 14:47, 
mailto:clement@csiro.au>>
 wrote:
Hi Robert,

  I have tested on both Intel and Nvidia machines.  The solution works without 
any issue.  Thanks.

I have applied this fix to OSG-svn/trunk, OSG-3.2.3 and OSG-3.4.0 so we should 
now be good to go.

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] Advice on how to implement custom file format

[Robert Osfield]

Hi Aaron,

The OSG has a DatabasePager built in, something you can leverage by
creating a paged database composed of PageLOD nodes, where the PagedLOD
nodes have file references to the tiles you want to load.

You can either use files directory or encode a tile via the filename string
and have the plugin that does the loading unpack the details of what to
load.

The VirtualPlanetBuilder tool creates native OSG paged databases from DEM's
and imagery, using the PagedLOD to create a paged quad tree hierarchy of
files and subgraph they map too.

The osgEarth NodeKit also uses PagedLOD but creates the tiles on the fly
reading the DEM and imagery on demand rather than re-processing like VPB
does.

Both VPB and osgEarth provide examples of PagedLOD usage, but with the two
approaches - loading pre-processed tiles directory or using a pseudo loader.

Robert.


On 16 August 2015 at 22:11, Aaron Andersen  wrote:

> Hello,
>
> I'm planning to render a custom (preexisting) map file format using osg
> and was looking for some guidance. I haven't been using osg for that long
> so I figure it is worth asking if there is either a way to adapt some
> existing code in the library to fit this custom format, or if not, what
> people might suggest as a good way to go about implementing loading and
> rendering this map file format with osg.
>
> The map is composed of individual 3d mesh tiles of variable size that are
> "snapped" together side by side somewhat similar to toy Lego blocks. Most
> mesh tiles are relatively small so there are a large number of these mesh
> tiles required to draw the map. As for the file format itself, the map is
> broken up spatially into many separate files (known as "regions").
>
> I wish to write some code so that the map will be read into my application
> and populate the scene graph seamlessly so there won't need to be a loading
> screen every time the camera zooms to a new area of the map. The maps
> stored in this format are *way* too large to load into memory all at once,
> so I will need to stream data in as the camera approaches new areas and out
> as it leaves other areas, always keeping the scene graph up to date.
>
> I should mention that the map file format is a little peculiar in that
> none of the 3d mesh tiles have any absolute position information listed at
> all. Each and every mesh tile is placed relative to the an adjacent mesh
> tile. I can arbitrarily choose any mesh tile from a map file and place it
> at 0,0,0 and from there start placing adjacent tiles, and for each adjacent
> tile place the adjacent tiles, recursively over and over, to build up the
> map. I mention this placement peculiarity because it means that I can only
> ever know the absolute position of any mesh tile that is relatively close
> to the camera (ie. the area of the map I'm currently rendering).
>
> If any clarification is required please let me know and thank you kindly
> for any advice anyone can offer me.
>
> Aaron Andersen
>
> ___
> 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

[Alistair Baxter]

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

Re: [osg-users] Geometry of Generic 3D Surface from Collection of Points

[Robert Osfield]

Hi Erik,

The OSG has the osgUtil::DelaunayTriangulator and the GLU based
osgUtil::Tessellator can be used for tessellating meshes, but both utilize
a 2D projection to a plan to work out the connectivity so aren't
appropriate for meshes that will be folded.


Robert.

On 17 August 2015 at 02:21, Erik Hensens  wrote:

> Hi everyone!
>
> I have a collection of Vec3 vertices that define the shape of a geometry
> that I'd like to create. Typically I would create the geometry by adding a
> primitive set of the POLYGON type, but what should I do if the vertices are
> not all in the same plane?
>
> I'm sure this is a very common task and that there's probably a simple way
> to achieve this. What is the best basic approach to creating such a
> geometry?
>
> Ideally I'd like to be able to do this without having to choose the
> individual triangles or quads that will make up the entire geometry. For
> example, if I wanted to model any generic three-dimensional surface and all
> I had was a large sample of points on the surface.
>
> In case I'm not doing a good job explaining what I need, I've attached an
> image - let's say I had many points on the surface of that shape and I need
> to make a geometry that depicts it. How would I do this?
>
> Thanks in advance for your help![/img]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64792#64792
>
>
>
>
> ___
> 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] ColorMask and depth information issue.

[Alessandro Terenzi]

Hi Robert,
thank you for the answer, I managed to get to the expected result following 
your suggestion.

Thanks.
Alessandro

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





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

Re: [osg-users] Qt5 integration

[Robert Osfield]

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

Re: [osg-users] ClipNode Opposite Behavior

[Christian Buchner]

whatever float your boat... ;)

Here's a shader routine that evaluates if a fragment coordinate in object
space is within a polygon described by up to 16 vertices in the x/y plane.
We use it to cut a hole into a city scenario, so we can see into the
basement of a house. The shader does a simple point in polygon test.

The weird osgShadow_ naming for my uniforms comes from the fact that
we've extended the one of OSG's shadow implementations of OSG with support
for cutting holes into the shadowed scene.

const char MyShadowMap::fragmentShaderSource_HoleCutter[] =
{
"#version 120\n"
"uniform vec2 osgShadow_polygon[16]; \n"
"uniform float osgShadow_nvert; \n"
"\n"
"bool pnpoly(vec2 test)\n"
"{\n"
"bool c = false;"
"if (osgShadow_nvert >= 3)\n"
"{\n"
"int i, j;\n"
"for (i = 0, j = int(osgShadow_nvert) - 1; i <
int(osgShadow_nvert); j = i++) {\n"
"if (((osgShadow_polygon[i].y>test.y) !=
(osgShadow_polygon[j].y>test.y)) &&\n"
"(test.x < (osgShadow_polygon[j].x -
osgShadow_polygon[i].x) * (test.y - osgShadow_polygon[i].y) /
(osgShadow_polygon[j].y - osgShadow_polygon[i].y) +
osgShadow_polygon[i].x))\n"
"c = !c;\n"
"}\n"
"}\n"
"return c;\n"
"}\n"
"\n"
"bool is_hole(vec3 pos)\n"
"{\n"
"return pnpoly(pos.xy);\n"
"}\n"
};

static const char fragmentShaderSource[] =
"#version 120\n"
"\n"
"bool is_hole(vec3 pos);\n"
"\n"
"void main(void) \n"
"{ \n"
"\n"
//   early discard
//   NOTE: we've previously set up gl_TexCoord[4].xyz to contain vertex
coordinates
//   so we don't require a vertex shader here that passes us a varying
of vertex coords.
"if (is_hole(gl_TexCoord[4].xyz)) discard;\n"
"\n"
 // remainder of shader is here
"}\n";



2015-08-17 3:03 GMT+02:00 Erik Hensens :

> I just wanted to mention that I never got the fragment shader approach to
> work for what I wanted. I ended up using polygon tessellation to build the
> geometry out of triangles.
>
> Thanks anyway to everyone who attempted to help!
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=64791#64791
>
>
>
>
>
> ___
> 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] Geometry of Generic 3D Surface from Collection of Points

[Erik Hensens]

Thanks for the response Robert!

So, does that mean that there is no way to do what I want without somehow 
determining the coordinates of every individual triangle? And there's not even 
any way to do a 3D tessellation to get such triangle coordinates? :'


robertosfield wrote:
> Hi Erik,
> 
> 
> The OSG has the osgUtil::DelaunayTriangulator and the GLU based 
> osgUtil::Tessellator can be used for tessellating meshes, but both utilize a 
> 2D projection to a plan to work out the connectivity so aren't appropriate 
> for meshes that will be folded.
> 
> 
> 
> Robert.
> 
> 
> On 17 August 2015 at 02:21, Erik Hensens < ()> wrote:
> 
> > Hi everyone!
> > 
> > I have a collection of Vec3 vertices that define the shape of a geometry 
> > that I'd like to create. Typically I would create the geometry by adding a 
> > primitive set of the POLYGON type, but what should I do if the vertices are 
> > not all in the same plane?
> > 
> > I'm sure this is a very common task and that there's probably a simple way 
> > to achieve this. What is the best basic approach to creating such a 
> > geometry?
> > 
> > Ideally I'd like to be able to do this without having to choose the 
> > individual triangles or quads that will make up the entire geometry. For 
> > example, if I wanted to model any generic three-dimensional surface and all 
> > I had was a large sample of points on the surface.
> > 
> > In case I'm not doing a good job explaining what I need, I've attached an 
> > image - let's say I had many points on the surface of that shape and I need 
> > to make a geometry that depicts it. How would I do this?
> > 
> > Thanks in advance for your help![/img]
> > 
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=64792#64792 
> > (http://forum.openscenegraph.org/viewtopic.php?p=64792#64792)
> > 
> > 
> > 
> > 
> > ___
> > 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=64802#64802





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

Re: [osg-users] Geometry of Generic 3D Surface from Collection of Points

[Sebastian Messerschmidt]

Hi Erik,

From what I understand you have a function generating a z value for x,y 
pairs. So basically you simply have to sample your function in regular 
distances to get the triangle coordinates.
If you already have the sampled points without further information you 
need to use the delaunay triangulation. IIRC, If it is a function the 
folding should not be problem for the delaunay algorithm, so I don't 
know if Roberts comment might be misleading.


Cheers
Sebastian

Thanks for the response Robert!

So, does that mean that there is no way to do what I want without somehow 
determining the coordinates of every individual triangle? And there's not even 
any way to do a 3D tessellation to get such triangle coordinates? :'


robertosfield wrote:

Hi Erik,


The OSG has the osgUtil::DelaunayTriangulator and the GLU based 
osgUtil::Tessellator can be used for tessellating meshes, but both utilize a 2D 
projection to a plan to work out the connectivity so aren't appropriate for 
meshes that will be folded.



Robert.


On 17 August 2015 at 02:21, Erik Hensens < ()> wrote:


Hi everyone!

I have a collection of Vec3 vertices that define the shape of a geometry that 
I'd like to create. Typically I would create the geometry by adding a primitive 
set of the POLYGON type, but what should I do if the vertices are not all in 
the same plane?

I'm sure this is a very common task and that there's probably a simple way to 
achieve this. What is the best basic approach to creating such a geometry?

Ideally I'd like to be able to do this without having to choose the individual 
triangles or quads that will make up the entire geometry. For example, if I 
wanted to model any generic three-dimensional surface and all I had was a large 
sample of points on the surface.

In case I'm not doing a good job explaining what I need, I've attached an image 
- let's say I had many points on the surface of that shape and I need to make a 
geometry that depicts it. How would I do this?

Thanks in advance for your help![/img]

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




___
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=64802#64802





___
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] Geometry of Generic 3D Surface from Collection of Points

[Erik Hensens]

Thanks Sebastian,

My requirement is not actually as simple as trying to graph a 3D function, I 
was just trying to keep my question clear. In reality I just have the 
coordinates of the boundary of a three-dimensional path that I need to 
represent with a Geometry. It looks like the CGAL library is capable of 
performing 3D tessellation, so maybe that's the way to go.


SMesserschmidt wrote:
> Hi Erik,
> 
> From what I understand you have a function generating a z value for x,y 
> pairs. So basically you simply have to sample your function in regular 
> distances to get the triangle coordinates.
> If you already have the sampled points without further information you 
> need to use the delaunay triangulation. IIRC, If it is a function the 
> folding should not be problem for the delaunay algorithm, so I don't 
> know if Roberts comment might be misleading.
> 
> Cheers
> Sebastian
> 
> > Thanks for the response Robert!
> > 
> > So, does that mean that there is no way to do what I want without somehow 
> > determining the coordinates of every individual triangle? And there's not 
> > even any way to do a 3D tessellation to get such triangle coordinates? :'
> > 
> > 
> > robertosfield wrote:
> > 
> > > Hi Erik,
> > > 
> > > 
> > > The OSG has the osgUtil::DelaunayTriangulator and the GLU based 
> > > osgUtil::Tessellator can be used for tessellating meshes, but both 
> > > utilize a 2D projection to a plan to work out the connectivity so aren't 
> > > appropriate for meshes that will be folded.
> > > 
> > > 
> > > 
> > > Robert.
> > > 
> > > 
> > > On 17 August 2015 at 02:21, Erik Hensens < ()> wrote:
> > > 
> > > 
> > > > Hi everyone!
> > > > 
> > > > I have a collection of Vec3 vertices that define the shape of a 
> > > > geometry that I'd like to create. Typically I would create the geometry 
> > > > by adding a primitive set of the POLYGON type, but what should I do if 
> > > > the vertices are not all in the same plane?
> > > > 
> > > > I'm sure this is a very common task and that there's probably a simple 
> > > > way to achieve this. What is the best basic approach to creating such a 
> > > > geometry?
> > > > 
> > > > Ideally I'd like to be able to do this without having to choose the 
> > > > individual triangles or quads that will make up the entire geometry. 
> > > > For example, if I wanted to model any generic three-dimensional surface 
> > > > and all I had was a large sample of points on the surface.
> > > > 
> > > > In case I'm not doing a good job explaining what I need, I've attached 
> > > > an image - let's say I had many points on the surface of that shape and 
> > > > I need to make a geometry that depicts it. How would I do this?
> > > > 
> > > > Thanks in advance for your help![/img]
> > > > 
> > > > --
> > > > Read this topic online here:
> > > > http://forum.openscenegraph.org/viewtopic.php?p=64792#64792 
> > > > (http://forum.openscenegraph.org/viewtopic.php?p=64792#64792)
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > 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=64802#64802
> > 
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> > 
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > 
> 
> ___
> 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=64804#64804





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

Re: [osg-users] Geometry of Generic 3D Surface from Collection of Points

[Robert Osfield]

Hi Erik,

On 17 August 2015 at 13:39, Erik Hensens  wrote:

> So, does that mean that there is no way to do what I want without somehow
> determining the coordinates of every individual triangle? And there's not
> even any way to do a 3D tessellation to get such triangle coordinates? :'


The OSG itself doesn't provide a general 3D mesh generalization, this is
non trivial problem to solve.  Go on the web and search for different
solutions.

The OSG is primarily and rendering library, the extra's such as
DealunayTriangulator are for convinience, but don't attempt to provide
complete solutions.  Tessellation of point clouds is a huge topic in itself.

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

Re: [osg-users] Geometry of Generic 3D Surface from Collection of Points

[Erik Hensens]

Thanks Robert. That answers my question perfectly - I figured there was a 
simple way to do what I wanted using OSG only but that I just couldn't find it. 
I'm fine with using a different approach to solve this problem. I haven't 
looked too far but perhaps CGAL can provide me with what I need.

Thanks again!


robertosfield wrote:
> Hi Erik,
> 
> On 17 August 2015 at 13:39, Erik Hensens < ()> wrote:
> 
> > So, does that mean that there is no way to do what I want without somehow 
> > determining the coordinates of every individual triangle? And there's not 
> > even any way to do a 3D tessellation to get such triangle coordinates? :'
> 
> 
> The OSG itself doesn't provide a general 3D mesh generalization, this is non 
> trivial problem to solve.  Go on the web and search for different solutions.
> 
> 
> The OSG is primarily and rendering library, the extra's such as 
> DealunayTriangulator are for convinience, but don't attempt to provide 
> complete solutions.  Tessellation of point clouds is a huge topic in itself.
> 
> 
> Robert.
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
>  --
> Post generated by Mail2Forum


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





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

Re: [osg-users] Geometry of Generic 3D Surface from Collection of Points

[Robert Osfield]

Hi Erik,

On 17 August 2015 at 14:18, Erik Hensens  wrote:

> Thanks Robert. That answers my question perfectly - I figured there was a
> simple way to do what I wanted using OSG only but that I just couldn't find
> it. I'm fine with using a different approach to solve this problem. I
> haven't looked too far but perhaps CGAL can provide me with what I need.
>

I really don't know enough about the specifics of your dataset to know what
you can use.  CGAL might the tool for you task, or it might be that the OSG
tools are sufficient.

Alternatively it may be possible to come up with solutions that are
tailored to the dataset and can produce results of better quality and
faster than general purpose solution. For instance if you had a data set
that has two input variables that specify a surface in 3D then you could
create a regular tessellation in the 2D input space then map the 2D
coordinates to their final 3D coordinates - think of table cloth with a
regular grid that you then scrunch up.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Geometry of Generic 3D Surface from Collection of Points

[Erik Hensens]

Hi Robert,

Sorry but could you expand just a little bit on what you mean by "For instance 
if you had a data set that has two input variables that specify a surface in 3D 
then you could create a regular tessellation in the 2D input space then map the 
2D coordinates to their final 3D coordinates - think of table cloth with a 
regular grid that you then scrunch up." In particular, what do you mean by 'map 
the 2D coordinates to their final 3D coordinates'?

Sorry and thanks very much for your patience... :-* 


robertosfield wrote:
> Hi Erik,
> 
> On 17 August 2015 at 14:18, Erik Hensens < ()> wrote:
> 
> > Thanks Robert. That answers my question perfectly - I figured there was a 
> > simple way to do what I wanted using OSG only but that I just couldn't find 
> > it. I'm fine with using a different approach to solve this problem. I 
> > haven't looked too far but perhaps CGAL can provide me with what I need.
> > 
> 
> 
> I really don't know enough about the specifics of your dataset to know what 
> you can use.  CGAL might the tool for you task, or it might be that the OSG 
> tools are sufficient.
> 
> Alternatively it may be possible to come up with solutions that are tailored 
> to the dataset and can produce results of better quality and faster than 
> general purpose solution. For instance if you had a data set that has two 
> input variables that specify a surface in 3D then you could create a regular 
> tessellation in the 2D input space then map the 2D coordinates to their final 
> 3D coordinates - think of table cloth with a regular grid that you then 
> scrunch up.
> 
>  
> 
>  --
> Post generated by Mail2Forum


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





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

Re: [osg-users] Geometry of Generic 3D Surface from Collection of Points

[Robert Osfield]

Hi Erik,

On 17 August 2015 at 14:44, Erik Hensens  wrote:

> Sorry but could you expand just a little bit on what you mean by "For
> instance if you had a data set that has two input variables that specify a
> surface in 3D then you could create a regular tessellation in the 2D input
> space then map the 2D coordinates to their final 3D coordinates - think of
> table cloth with a regular grid that you then scrunch up." In particular,
> what do you mean by 'map the 2D coordinates to their final 3D coordinates'?
>
> Sorry and thanks very much for your patience... :-*
>

I don't know what part needs clarifying.

There are OSG examples like osggeometry that illustrate creating
osg::Geometry to represent points, lines and meshes by specifying the raw
3D coordinates, normals, texcoords and meshes.

The osganimation example creates a mesh with a regular grid like a chess
board.

The osgdalunay and osgtesselate illustrate how to use the
osgUtil::DelanayTriangulator and osgUtil::Tessellator respectively.

The osgshaderterrain creates a flat grid and then uses a vertex shader that
reads a texture for a height field and then modifies the flat geometry to
produce the final deformed mesh.  This function only modifies the Z value
using the height field, but it's possible to modify all coordinates if you
so wish, i.e. use a vec3 vertex  = myfunction( vec2(x,y) );

You could do something similar to the original mesh coordinates in C++
rather than shaders.

All these possibilities mean there might be plenty of ways to do what you
need to do, but it may also be that your particular problem domain isn't
amenable to these approaches.  You've never really said exactly what type
of data you have to work with so it really isn't possible to tell you
exactly what to do.

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

Re: [osg-users] [osgPlugins] DDS textures not loading on Mac OSX and the latest trunk(3.5.0)

[Curtis Rubel]

Hi Robert,

After some checking around with our development team,
we discovered that after updating to the latest OSX release
the newest GL package from Apple was also installed
as part of this update and this issue seems to have been resolved...

The numbers from my particular mac:

Version: 4.1 NVIDIA-10.4.2 310.41.35f01

Shading language version: 4.10

Then removing and reconverting all our files into .osgb again
things are loading properly now.

So my apologies for not thinking about updating this before
getting everyone here involved.   Normally all our macs are
kept up to date, so was not even thinking about this
as a possibility.  

Anyone else having similar issues should try to update their
systems to the latest release of OSX to ensure they have
the latest Apple versions of OpenGL installed.

... 

Thank you!

Cheers,
Curtis  :-*

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





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

Re: [osg-users] Qt5 integration

[Werner Modenbach]

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