Re: [osg-users] VertexBufferObject usage very slow...

2010-12-21 Thread Sean Spicer
Thanks Robert, will do.

Happy Holidays!
_
Sean Spicer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Tue, Dec 21, 2010 at 2:53 AM, Robert Osfield
robert.osfi...@gmail.com wrote:
 Hi Sean,

 On Tue, Dec 21, 2010 at 5:40 AM, Sean Spicer  While digging, it looks
 like there are several ways to optimize vertex
 arrays for the caches on various GPUs...have you looked at all at
 this?  Are there any reasonable rules-of-thumb for organizing the
 vertex arrays such that they make efficient use of the vertex cache
 across a wide swath of commodity hardware?  Both NVIDIA and ATI have
 published advice on the topic.

 Tim Moore implemented several utility classes for osgUtil that you can
 use to optimize meshes for caching, see
 include/osgUtil/MeshOptimizers.  The new osganalysis example has some
 code that illustrates there use.

 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] VertexBufferObject usage very slow...

2010-12-20 Thread Sean Spicer
Robert, Wojciech,

Thank you for the advice, this is pretty much exactly what I
discovered after some further research.  This particular code is
pretty old, and I've now re-factored it to use indexed tri-sets
instead of tri-strips and things are much better.

While digging, it looks like there are several ways to optimize vertex
arrays for the caches on various GPUs...have you looked at all at
this?  Are there any reasonable rules-of-thumb for organizing the
vertex arrays such that they make efficient use of the vertex cache
across a wide swath of commodity hardware?  Both NVIDIA and ATI have
published advice on the topic.

sean
_
Sean Spicer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Sun, Dec 19, 2010 at 6:20 AM, Robert Osfield
robert.osfi...@gmail.com wrote:
 Hi Sean,

 In general when moving from display listed data to VBO's it's best to
 avoid using tri-strips with separate osg::DrawElements and instead
 using a single osg::DrawElements containing just GL_TRIANGLES.  This
 will be more duplicated indices but far less overhead in set up and
 dispatch.

 With modern graphics hardware and API the biggest overhead is
 typically the dispatch rather than vertex load on the GPU.  Even mid
 range GPU's can comfortable handle a million+ vertices per frame at
 60hz, but... you have to pass the data to them efficiently, and the
 bottlenecks we were once familiar with have changed.

 Robert.

 On Fri, Dec 17, 2010 at 6:57 PM, Sean Spicer sean.spi...@aqumin.com wrote:
 Robert,

 Some more data...

 Looks like we're drawing approx 100K tri-strips every frame.  The
 glDrawElements call is the culprit...though I'm still baffled by why
 it is so much slower with VBOs than in immediate mode.  Perhaps the
 drawing isn't sorted by VBO so that all of the triangles drawn from
 each VBO are draw in single bind call ?

 sean
 _
 Sean Spicer
 Aqumin (www.aqumin.com)
 Office+1.713.781.2121
 Mobile...+1.713.447.2706
 Fax...+1.713.781.2123



 On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer sean.spi...@aqumin.com wrote:
 Hi Robert,

 We are not updating the data frame-to-frame, which is why this is so
 baffling.  I'm working through the issue with gDebugger now - if you
 don't have any suggestions off the top of your head, then I'll start
 digging and report back what I find, since I don't have time try and
 duplicate the issue outside our app.

 cheers,

 sean
 _
 Sean Spicer
 Aqumin (www.aqumin.com)
 Office+1.713.781.2121
 Mobile...+1.713.447.2706
 Fax...+1.713.781.2123



 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield
 robert.osfi...@gmail.com wrote:
 reproduces the problem you are seeing?


 ___
 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] VertexBufferObject usage very slow...

2010-12-17 Thread Sean Spicer
Hi Robert,

We are not updating the data frame-to-frame, which is why this is so
baffling.  I'm working through the issue with gDebugger now - if you
don't have any suggestions off the top of your head, then I'll start
digging and report back what I find, since I don't have time try and
duplicate the issue outside our app.

cheers,

sean
_
Sean Spicer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield
robert.osfi...@gmail.com wrote:
 reproduces the problem you are seeing?

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


Re: [osg-users] VertexBufferObject usage very slow...

2010-12-17 Thread Sean Spicer
Robert,

Some more data...

Looks like we're drawing approx 100K tri-strips every frame.  The
glDrawElements call is the culprit...though I'm still baffled by why
it is so much slower with VBOs than in immediate mode.  Perhaps the
drawing isn't sorted by VBO so that all of the triangles drawn from
each VBO are draw in single bind call ?

sean
_
Sean Spicer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Fri, Dec 17, 2010 at 11:37 AM, Sean Spicer sean.spi...@aqumin.com wrote:
 Hi Robert,

 We are not updating the data frame-to-frame, which is why this is so
 baffling.  I'm working through the issue with gDebugger now - if you
 don't have any suggestions off the top of your head, then I'll start
 digging and report back what I find, since I don't have time try and
 duplicate the issue outside our app.

 cheers,

 sean
 _
 Sean Spicer
 Aqumin (www.aqumin.com)
 Office+1.713.781.2121
 Mobile...+1.713.447.2706
 Fax...+1.713.781.2123



 On Fri, Dec 17, 2010 at 2:36 AM, Robert Osfield
 robert.osfi...@gmail.com wrote:
 reproduces the problem you are seeing?


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


[osg-users] VertexBufferObject usage very slow...

2010-12-16 Thread Sean Spicer
Hi Everyone,

Working off the OSG trunk this afternoon, I tried some experiments
with VertexBufferObjects and our geometry (all on the fast path).  The
only deltas in our code are as follows...all timing as measured by OSG
stats:

geometry-setUseDisplayList(true)
geometry-setUseVertexBufferObjects(false)
=== Draw time = 2ms, FrameTime = 12ms

geometry-setUseDisplayList(false)
geometry-setUseVertexBufferObjects(false)
=== Draw time = 13ms, FrameTime= 19ms

geometry-setUseDisplayList(false)
geometry-setUseVertexBufferObjects(true)
=== Draw time = 67ms !!!  FrameTime = 109ms

What is going on here ?  We are always on the fast path - however, our
vertex arrays are large (65535 verts).  VBOs *should* be way faster
than immediate mode...any ideas ?

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


[osg-users] OSX Install Locations

2010-09-21 Thread Sean Spicer
Hi All,

I'm wondering if someone can help me out with an OSX Install Question:

(1) Working from the OSG Trunk, I build the OpenSceneGraph using frameworks.
 I have the CMAKE install directory set to ~/work/OpenSceneGraph-trunk-inst
Everything builds cleanly and installs into the specified install directory.

(2) I copy the contents of ~/work/OpenSceneGraph-trunk-inst/lib (e.g. all
the frameworks + osgPlugins-2.9.9) to /Library/Frameworks

(3) I
run ~/work/OpenSceneGraph-trunk-inst/share/OpenSceneGraph/bin/osglogo.app
 Runs fine, but doesn't seem to use the freetype plugin.

I looked at the plugins dir, and I find that all the plugins have a .so
extension, I presume this doesn't matter.  Within the osgPlugins-2.9.9
directory there exists the file: osgdb_freetyperd.so

I've also tried putting the plugins in the directory:

/Library/ApplicationSupport/OpenSceneGraph/Plugins/osgdb_freetype.so

No luck there either.

Thoughts?

sean
_
Sean Spicer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Does OSG function over VNC?

2010-08-27 Thread Sean Spicer
Hi Harry,

Have a look at TurboVNC: http://www.virtualgl.org/Downloads/TurboVNC

http://www.virtualgl.org/Downloads/TurboVNCsean
_
Sean Spicer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123


On Fri, Aug 27, 2010 at 2:08 PM, Harry Johnson harry_c_john...@yahoo.comwrote:

 Hi Robert,

 Yeah, I understand that the issue is with limited GLX support in the VNC
 server. However, seeing the glsl_simple.osg actually render, albeit with
 errors, makes me wonder if there isn't some switch to OSG that would result
 in it using a 'dumbed down' set of glx features with the understanding that
 performance/appearance will likely suffer.

 osgviewer glider.osg does not work. :(  It also results in the
 GLXBadRenderRequest messages.

 I tried to include the glxinfo output for the VNC server in this post but
 the forums tell me I have to have 2 posts before I can post a URL... I guess
 it thinks some of the glxinfo output is actually a URL of some sort.

 Thank you!

 Cheers,
 Harry

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





 ___
 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] BUG REPORT: LineSegmentIntersector

2010-03-25 Thread Sean Spicer
I came across a nasty little bug today:

(a) Create an osg::Geometry and assign a vertex array that is an osg::Vec4Array
(b) Try to pick with a LineSegmentIntersector
(c) CRASH

Digging a little bit, it looks like LineSegmentIntersector assumes
that vertex arrays are always of type osg::Vec3Array.  Are there any
plans to change this ?  It looks like a tedious, but not terribly
invasive change.

sean
_
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] BUG REPORT: LineSegmentIntersector

2010-03-25 Thread Sean Spicer
Without giving away too much IP, one of the reasons why one might want
to think about using Vec4Arrays is to take advantage of host-side SIMD
operations - which commonly use 128bit registers (4 floats).

I agree, this is a can of worms.

sean
_
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Thu, Mar 25, 2010 at 2:53 PM, Jason Daly jd...@ist.ucf.edu wrote:
 Sean Spicer wrote:

 I came across a nasty little bug today:

 (a) Create an osg::Geometry and assign a vertex array that is an
 osg::Vec4Array
 (b) Try to pick with a LineSegmentIntersector
 (c) CRASH

 Digging a little bit, it looks like LineSegmentIntersector assumes
 that vertex arrays are always of type osg::Vec3Array.  Are there any
 plans to change this ?  It looks like a tedious, but not terribly
 invasive change.


 Interesting find, Sean...

 My first reaction is, Why would you ever use a Vec4Array for vertex
 coordinates?!, but an equally valid counter-argument would be that OpenGL
 allows 4-element vertices them, so OSG should support them.

 Next, you have to ask how to intersect a line segment with a geometry with
 Vec4Array vertices.  Would you have to do the w-divide on the vertices
 before you did the intersection tests to be correct, or is it more correct
 to not do it, or do you have to do the modelview transform, then the
 w-divide, then the intersection...

 Then, you have to start wondering if there are any other assumptions like
 this being made anywhere (I found other possible cases in Tessellator and
 Optimizer, though it looks as if they just bail out instead of crashing when
 they don't find a Vec3Array).

 I think you may have opened a can of worms here  :-)

 --J

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

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


Re: [osg-users] BUG REPORT: LineSegmentIntersector

2010-03-25 Thread Sean Spicer
Looking at osg::State::setVertexPointer(const Array *array), I see
that the stride parameter is always 0.  If we relaxed this
constraint, and allowed an Array to have a stride, I might be able to
overcome the problem I am working on.  Any comments on what impact
this might have ?

Also, in order to accomplish what I'm after, I'd need a mechanism to
allocate the underlying array on a 16 byte boundary.  It looks as if
this should be easily doable as MixinVector is a std::vector.  Any
thoughts on this?

sean
_
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Thu, Mar 25, 2010 at 3:05 PM, Sean Spicer sean.spi...@aqumin.com wrote:
 Without giving away too much IP, one of the reasons why one might want
 to think about using Vec4Arrays is to take advantage of host-side SIMD
 operations - which commonly use 128bit registers (4 floats).

 I agree, this is a can of worms.

 sean
 _
 Sean Spicer
 Executive Vice President  Chief Technology Officer
 Aqumin (www.aqumin.com)
 Office+1.713.781.2121
 Mobile...+1.713.447.2706
 Fax...+1.713.781.2123



 On Thu, Mar 25, 2010 at 2:53 PM, Jason Daly jd...@ist.ucf.edu wrote:
 Sean Spicer wrote:

 I came across a nasty little bug today:

 (a) Create an osg::Geometry and assign a vertex array that is an
 osg::Vec4Array
 (b) Try to pick with a LineSegmentIntersector
 (c) CRASH

 Digging a little bit, it looks like LineSegmentIntersector assumes
 that vertex arrays are always of type osg::Vec3Array.  Are there any
 plans to change this ?  It looks like a tedious, but not terribly
 invasive change.


 Interesting find, Sean...

 My first reaction is, Why would you ever use a Vec4Array for vertex
 coordinates?!, but an equally valid counter-argument would be that OpenGL
 allows 4-element vertices them, so OSG should support them.

 Next, you have to ask how to intersect a line segment with a geometry with
 Vec4Array vertices.  Would you have to do the w-divide on the vertices
 before you did the intersection tests to be correct, or is it more correct
 to not do it, or do you have to do the modelview transform, then the
 w-divide, then the intersection...

 Then, you have to start wondering if there are any other assumptions like
 this being made anywhere (I found other possible cases in Tessellator and
 Optimizer, though it looks as if they just bail out instead of crashing when
 they don't find a Vec3Array).

 I think you may have opened a can of worms here  :-)

 --J

 ___
 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] Load balancing on multiple cores

2010-03-25 Thread Sean Spicer
One suggestion that I will offer: build your code in release mode, but
do not optimize.  Under MSVC, use the following flags:

/MD /Zi /Od /Ob0 /RTC1 /D NDEBUG

You can add the following CMAKE Option to OSGs CMakeLists.txt to add
this type of build as an MSVC option in the configuration manager:

set(CMAKE_CONFIGURATION_TYPES
Debug;RelWithDebInfo;Development;DevelopmentNoOpt CACHE STRING 
FORCE)
set(CMAKE_CXX_FLAGS_DEVELOPMENT /MD /Zi /O2 /Ob1 /D NDEBUG CACHE
STRING CMAKE_CXX_FLAGS_DEVELOPMENT FORCE)
set(CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENT /debug /INCREMENTAL:YES
CACHE STRING CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENT FORCE)
set(CMAKE_CXX_FLAGS_DEVELOPMENTNOOPT /MD /Zi /Od /Ob0 /RTC1 /D
NDEBUG CACHE STRING CMAKE_CXX_FLAGS_DEVELOPMENTNOOPT FORCE)
set(CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENTNOOPT /debug
/INCREMENTAL:YES CACHE STRING
CMAKE_SHARED_LINKER_FLAGS_DEVELOPMENTNOOPT FORCE)

sean
_
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Fri, Mar 19, 2010 at 1:12 AM, J.P. Delport jpdelp...@csir.co.za wrote:
 Hi Jesse,

 Jesse Stimpson wrote:

 I feel that we're diverging from what I think is most perplexing about
 what I'm seeing. When I restrict the process to use less cores, I get
 increased rendering performance. This is what leads me to believe there are
 some load-balancing issues.

 yes, and it would be difficult to see what causes it. Is it OSG, the OpenGL
 driver or your OS? Unfortunately there is no magic way to get the balance
 right on all hardware combos. You'll just have to experiment and use what
 works best in your situation.


 Also, if I have the OSG process set to both cores and I run another
 single-threaded process in the background, the other process gets assigned
 to one core, and OSG rendering speeds up, presumably because it is being
 processed mainly on a single core.

 you might find this interesting:
 http://igoro.com/archive/gallery-of-processor-cache-effects/


 I've been playing with the OSG threading models as well. In debug,
 SingleThreaded mode seems to run the best on my machine. Is there
 documentation on the implications of the threading models?

 Not explicitly that I know of. A search in the archives for the long names
 should get you some discussions.

 If I understand correctly, SingleThreaded means only the rendering is
 single threaded, and the database pager is still a separate thread. Is this
 right? Are reasons we shouldn't consider using SingleThreaded mode?

 No, use whatever works best for you. We are using SingleThreaded for some of
 our apps, because they are just a small part of a larger application and we
 can't use all the resources in the machine for rendering. See also this:

 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52734

 rgds
 jp


 Thanks,
 Jesse


 

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

 --
 This message is subject to the CSIR's copyright terms and conditions, e-mail
 legal notice, and implemented Open Document Format (ODF) standard. The full
 disclaimer details can be found at http://www.csir.co.za/disclaimer.html.

 This message has been scanned for viruses and dangerous content by
 MailScanner, and is believed to be clean.  MailScanner thanks Transtec
 Computers for their support.

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

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


Re: [osg-users] osg::LOD range distance Coordinate System Question

2009-10-09 Thread Sean Spicer
Thanks Robert,

This is an odd corner-case I guess, I want the LODs to be selected
based upon global distance from the eye-point.  For various reasons,
onscreen size is inappropriate as a selector.  I think I can put
together a small example/patch and send it in for review.

cheers,

sean
_
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.713.781.2121
Mobile...+1.713.447.2706
Fax...+1.713.781.2123



On Fri, Oct 9, 2009 at 2:06 AM, Robert Osfield robert.osfi...@gmail.com wrote:
 Hi Sean,

 You are correct the range distance of LOD's are in the LOD's own local
 co-coordinate system.  This is appropriate as you almost aways want
 LOD's to scale relative to a screen size, and doing the calc in local
 coordinate allows you to decorate subgraphs with LOD's with transforms
 that scale up or down the subgraph and still have the LOD ranges
 computed appropriate for that new scaling.  This behavior is key to
 get a scene graph to be well encapsulated.

 It sounds like in your case you have transforms above your LOD's that
 scale your objects, but you still want their ranges to set in world
 coords, that ignore any transforms.  This would present the problem
 that is the transforms scale change then the LOD would choose
 different children - choosing an in-apprioriate level of detail for
 the on screen size.

 Robert.

 On Fri, Oct 9, 2009 at 5:21 AM, Sean Spicer sean.spi...@aqumin.com wrote:
 Studying the source a bit harder, I think the range-distance is
 definitely in Object (local) coordinate.  The distance calculation
 (osg::LOD.cpp) is:

 required_range = nv.getDistanceToViewPoint(getCenter(),true);

 where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp)

 (pos-getViewPointLocal()).length()*getLODScale();

 So, this raises the question: is there a good reason why there is no
 option to specify the LOD range distance in World Coordinates?  This
 would make complex LOD graphs like the one I'm working on much, much
 simpler.  Perhaps there is another method that I just do not see?

 cheers,

 sean

 On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer sean.spi...@aqumin.com wrote:

 This may be a simple question - is the LOD range distance specified in 
 object or world coordinates?  I seems as if it should be in world 
 coordinates, but I've got an example with numerous LOD nodes in sub-graphs, 
 and if I sent a constant distance range in each of them (0.0, 30.0f) so 
 that each LOD node has the same range - the LOD switch only behaves as 
 expected if the transforms above each LOD node are identical.  The moment I 
 have a scale matrix above the LOD the switch becomes dependent on the 
 scaling...e.g. larger LODs switch before smaller ones.  This leads me to 
 think that the LOD range distance is in object coordinates, and needs to be 
 scaled by the localToWorld transform.
 I've had a look at the source, and it seems logical (not to mention that 
 I'd be shocked if someone hadn't had a problem before this if it were 
 incorrect)  Comments?  Thoughts?
 cheers,
 sean
 ___
 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] osg::LOD range distance Coordinate System Question

2009-10-08 Thread Sean Spicer
This may be a simple question - is the LOD range distance specified in
object or world coordinates?  I seems as if it should be in world
coordinates, but I've got an example with numerous LOD nodes in sub-graphs,
and if I sent a constant distance range in each of them (0.0, 30.0f) so that
each LOD node has the same range - the LOD switch only behaves as expected
if the transforms above each LOD node are identical.  The moment I have a
scale matrix above the LOD the switch becomes dependent on the
scaling...e.g. larger LODs switch before smaller ones.  This leads me to
think that the LOD range distance is in object coordinates, and needs to be
scaled by the localToWorld transform.
I've had a look at the source, and it seems logical (not to mention that I'd
be shocked if someone hadn't had a problem before this if it were incorrect)
 Comments?  Thoughts?

cheers,

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


Re: [osg-users] osg::LOD range distance Coordinate System Question

2009-10-08 Thread Sean Spicer
Studying the source a bit harder, I think the range-distance is
definitely in Object (local) coordinate.  The distance calculation
(osg::LOD.cpp) is:

required_range = nv.getDistanceToViewPoint(getCenter(),true);

where getDistanceToViewPoint is (osgUtil::CullVisitor.cpp)

(pos-getViewPointLocal()).length()*getLODScale();

So, this raises the question: is there a good reason why there is no
option to specify the LOD range distance in World Coordinates?  This
would make complex LOD graphs like the one I'm working on much, much
simpler.  Perhaps there is another method that I just do not see?

cheers,

sean

On Thu, Oct 8, 2009 at 10:50 PM, Sean Spicer sean.spi...@aqumin.com wrote:

 This may be a simple question - is the LOD range distance specified in object 
 or world coordinates?  I seems as if it should be in world coordinates, but 
 I've got an example with numerous LOD nodes in sub-graphs, and if I sent a 
 constant distance range in each of them (0.0, 30.0f) so that each LOD node 
 has the same range - the LOD switch only behaves as expected if the 
 transforms above each LOD node are identical.  The moment I have a scale 
 matrix above the LOD the switch becomes dependent on the scaling...e.g. 
 larger LODs switch before smaller ones.  This leads me to think that the LOD 
 range distance is in object coordinates, and needs to be scaled by the 
 localToWorld transform.
 I've had a look at the source, and it seems logical (not to mention that I'd 
 be shocked if someone hadn't had a problem before this if it were incorrect)  
 Comments?  Thoughts?
 cheers,
 sean
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Perspective Axes Rotation Indicator

2009-10-06 Thread Sean Spicer
Hi Osg-Users,
Here's a topic that I cannot seem to find any reference in the archives for.
 I'm trying to create an Axes rotation indicator Glyph in the lower
left-hand corner of our viewer (X, Y, Z).  I've got working code for this
(see below), but it is an orthographic projection, while my scene is
perspective.  The axes rotation indicator works correctly, (e.g. it
correctly matches the rotation of the trackball  scene) but because it is
ortho and the scene is perspective, it's quite jarring to the user.  Can
someone suggest how I can modify the code below so that it correctly maps
the axes in perspective (ideally, the same perspective frustum as my scene)?

Many thanks.

Sean

Code
---

#ifndef OsgAxes_h
#define OsgAxes_h

// OSG Includes
#include osg/Group
#include osg/Geometry
#include osg/Camera
#include osg/Quat
#include osg/MatrixTransform
#include osg/Referenced
#include osg/NodeCallback
#include osgGA/TrackballManipulator

class OsgAxes : public osg::Group
{

public:

// Public Constructor
explicit OsgAxes(const osgGA::TrackballManipulator trackball);

// Public Destructor
virtual ~OsgAxes();

void updateCurrentRotation();

private:

osg::Geometry *createAxes();

// Prevent Copy  Assignment
 OsgAxes(const OsgAxes );
OsgAxes operator=(const OsgAxes );

osg::ref_ptrosg::MatrixTransform m_rotation;

const osgGA::TrackballManipulator m_trackball;
};

class AxesNodeCallback : public osg::NodeCallback
{
public:
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv)
 {
osg::ref_ptrOsgAxes axes =
dynamic_castOsgAxes* (node);
 if(axes)
{
axes-updateCurrentRotation();
 }
traverse(node, nv);
}
};

OsgAxes::OsgAxes(const osgGA::TrackballManipulator trackball)
: m_trackball(trackball)
{
osg::Camera *camera = new osg::Camera;
 //camera-setProjectionMatrix(osg::Matrix::ortho2D(0, 1280, 0, 1024));
camera-setProjectionMatrix(osg::Matrix::ortho2D(0, 1280, 0, 1024));
 camera-setReferenceFrame(osg::Transform::ABSOLUTE_RF);
camera-setViewMatrix(osg::Matrix::identity());
 camera-setClearMask(GL_DEPTH_BUFFER_BIT);
camera-setRenderOrder(osg::Camera::POST_RENDER);
 camera-setAllowEventFocus(false);

osg::Geode* geode = new osg::Geode();

// turn lighting off for the text and disable depth test to ensure it's
always ontop.
osg::StateSet* stateset = geode-getOrCreateStateSet();
 stateset-setMode(GL_LIGHTING,osg::StateAttribute::OFF);

geode-addDrawable(createAxes());

m_rotation = new osg::MatrixTransform();
m_rotation-setMatrix(osg::Matrix::identity());
 m_rotation-addChild(geode);

osg::MatrixTransform *scale = new osg::MatrixTransform();
 scale-setMatrix(osg::Matrix::scale(osg::Vec3(100.0f, 100.0f, 100.0f)));
scale-addChild(m_rotation.get());

osg::MatrixTransform *translate = new osg::MatrixTransform();
translate-setMatrix(osg::Matrix::translate(osg::Vec3(100.0f, 100.0f,
0.0f)));
 translate-addChild(scale);

camera-addChild(translate);
 addChild(camera);

setUpdateCallback(new AxesNodeCallback);
}

OsgAxes::~OsgAxes()
{

}

osg::Geometry * OsgAxes::createAxes()
{
osg::Geometry* geom = new osg::Geometry;

osg::Vec3Array* vertices = new osg::Vec3Array;
vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f));
 vertices-push_back(osg::Vec3(0.5f, 0.0f, 0.0f));
vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f));
 vertices-push_back(osg::Vec3(0.0f, 0.5f, 0.0f));
vertices-push_back(osg::Vec3(0.0f, 0.0f, 0.0f));
 vertices-push_back(osg::Vec3(0.0f, 0.0f, 1.0f));
geom-setVertexArray(vertices);

osg::Vec3Array* normals = new osg::Vec3Array;
normals-push_back(osg::Vec3(0.0f,0.0f,1.0f));
 geom-setNormalArray(normals);
geom-setNormalBinding(osg::Geometry::BIND_OVERALL);

osg::Vec4Array* colors = new osg::Vec4Array;
colors-push_back(osg::Vec4(1.0f,0.0,0.0f,1.0f));
 colors-push_back(osg::Vec4(0.0f,1.0,0.0f,1.0f));
colors-push_back(osg::Vec4(0.0f,0.0,1.0f,1.0f));
 geom-setColorArray(colors);
geom-setColorBinding(osg::Geometry::BIND_PER_PRIMITIVE);

geom-addPrimitiveSet(new osg::DrawArrays(GL_LINES,0,6));

osg::StateSet* stateset = geom-getOrCreateStateSet();
 osg::LineWidth *lw = new osg::LineWidth(2.0f);
stateset-setAttribute(lw);

return geom;
}

void OsgAxes::updateCurrentRotation()
{
osg::Matrix mat(m_trackball.getRotation().inverse());
 m_rotation-setMatrix(mat);
}


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


Re: [osg-users] Embedding OSG in QT 4.5.0 with QGLWidget + QGraphicsScene / drawBackground() - need a little help.

2009-04-21 Thread Sean Spicer
Hi J-S,

Try this:

void  QOsgScene::drawBackground ( QPainter * painter, const QRectF  rect )
{
if (m_redrawEnabled == false){
return;
}

emit aboutToDraw();

// Only works with OpenGL
if( painter-paintEngine()-type() == QPaintEngine::OpenGL )
{
GLenum errorNo;

// Qt OpenGL State Initialization takes
// place before we get here, on every frame.
// We can assume that OpenGL state is reset to
// default on every frame.

// Push initialized state onto the stack so that we can
// Recover it later for further Qt Drawing.
glPushAttrib(GL_ALL_ATTRIB_BITS);
glPushClientAttrib(GL_CLIENT_ALL_ATTRIB_BITS);

// Fixup stuff that Qt Modifies from default state that
// OSG expects.
glShadeModel(GL_SMOOTH);

// Push matricies
glMatrixMode(GL_TEXTURE);
glPushMatrix();
glLoadIdentity();
glMatrixMode(GL_PROJECTION);
glPushMatrix();
glLoadIdentity();
glMatrixMode(GL_MODELVIEW);
glPushMatrix();
glLoadIdentity();

// Make sure that OSG's state is prepared based on the last 
state
// recorded (if available).  The first frame is different.
osg::State *state = 
getCamera()-getGraphicsContext()-getState();
state-reset();
state-apply(m_lastStateSet.get());

// Run a frame: this is where the action happens.
frame();

// Store the OSG state for restoration in the next frame.

getCamera()-getGraphicsContext()-getState()-captureCurrentState(*m_lastStateSet);

// Pop matricies.
glMatrixMode(GL_PROJECTION);
glPopMatrix();
glMatrixMode(GL_TEXTURE);
glPopMatrix();
glMatrixMode(GL_MODELVIEW);
glPopMatrix();

// Pop Attribs, now we're ready to continue
// Drawing with OpenGL.
glPopAttrib();
glPopClientAttrib();

errorNo = glGetError();
if (errorNo!=GL_NO_ERROR)
{
LOG_MSG(logERROR) Post-Frame: Detected OpenGL error 
(frame  
m_frameNo  ) ' gluErrorString(errorNo)  ';
}

++m_frameNo;
}
else
{
qWarning(QOsgScene: drawBackground needs a QGLWidget to be set 
as
viewport on the graphics view.);
}
}
_
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.281.466.4848
Mobile...+1.713.447.2706
Fax...+1.281.466.4849



On Tue, Apr 21, 2009 at 1:28 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
 Hello Christian,

 I have run into another problem. With my current approach the scene
 loses all lighting after
 the first frame has been drawn. All polygons appear in flat shading. I
 have currently no idea what is causing this. At first I was not
 noticing this because I rendered cow.osg which uses a metallic effect
 (environment maps?). But on other scenes the loss of lighting is
 apparent.

 This suggests that when pushing and popping state in order for Qt to draw
 its widgets, something is not pushed/popped correctly, probably GL_LIGHTING,
 GL_LIGHT0-GL_LIGHT7 or something like that? Perhaps glShadeModel? ...

 Just a possible avenue for investigation. I know it sounds obvious, but the
 error is obviously caused by something you overlooked, so listing things
 that should not be overlooked seems like the only way I can help... :-)

 J-S
 --
 __
 Jean-Sebastien Guay    jean-sebastien.g...@cm-labs.com
                               http://www.cm-labs.com/
                        http://whitestar02.webhop.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] KDTree Picking (at an angle)

2008-12-04 Thread Sean Spicer
Robert,

I think I know why things go bad in KDTree,

I'm using KDTree to spoof the location of some actual geometry, which is
transformed in a vertex/geometry shader.

So, I compute a bounding box for where the geometry ought to be, and create
a dummy geometry from that - I then compute the KDTree for this dummy
geometry, and assign it to the actual geometry that will be sent down the
pipe, which is at the scene origin, not its final location.

When the line-segment intersector goes to pick, it first checks to see if
the line segment intersects the bounding box of the drawable, which as far
as I can tell is computed against the actual geometry (in this case the
geometry at the origin) and not the KDTree's bounding box.  When it doesn't
properly intersect, the line-segment intersector returns without hitting the
KDTree.

I think what is needed is to test against the KDTree bounding box, rather
than the geometry bounding box, if a KDTree is assigned.

Does this make any sense?

sean

On Wed, Dec 3, 2008 at 10:05 AM, Sean Spicer [EMAIL PROTECTED] wrote:

 Robert,

 I will see if I can repro the problem with osgpick and send you the osg
 file.  It may take me a week or two though as I've got a lot on my plate ;-)

 cheers,

 sean


 On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi Sean,

 This sounds like a bug, but without a dataset and example that
 reproduces the problem it's next to impossible to home in on a fix.
 Would it be possible for you to provide a problem dataset that
 illustrates the problem?  If it can be reproduced with one of the
 existing examples like osgpick then this will make it easier to track
 down.

 Robert.

 On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED]
 wrote:
  Hi Gang,
 
  I'm working on improving picking performance via KDTree, but I'm hitting
 an
  issue that is driving me nuts: If I pick a node from directly above
 (e.g. +
  Z axis) everything works great, and picking is *very* fast.  If I pick
 at an
  angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate -
 nodes
  to the left, right, top, or bottom get picked instead of what I'm after.
 
  Here is my KDTree Build function:
 
  #ifdef USE_KDTREE
 
  // Update the KDTree
  osg::KdTree::BuildOptions kdTreeBuildOptions;
  osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
 
  if(kdTree-build(kdTreeBuildOptions, geometry))
  {
  geometry-setShape(kdTree.get());
  }
  else
  {
  LOG_MSG(logERROR)  osg::KdTree::build() unsuccessful.;
  }
  #endif
 
  Any suggestions?
 
  cheers,
 
  sean
 
  ___
  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] KDTree Picking (at an angle)

2008-12-04 Thread Sean Spicer
Will do, and I'll report back...

sean

On Thu, Dec 4, 2008 at 1:07 PM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi Sean,

 Yes this makes sense.  There is a mechanism in Drawable that allows
 you to define an inital bound that is used in the compute of the
 geometry position, this was done quite a few years ago at begining of
 the journey in the land of vertex shader.  These days I think a better
 solution would be to just allow users to manually define it and
 disable the automatic compute of the bounding volume.

 So try using

  geometry-setInitialBound(bb);

 Where bb is the max size you expect the goemetry to get to/or the
 bound that you used for the KdTree.

 If that works OK I can look at cleaning up the overriding of the computed
 bound.

 Robert.

 On Thu, Dec 4, 2008 at 6:30 PM, Sean Spicer [EMAIL PROTECTED]
 wrote:
  Robert,
 
  I think I know why things go bad in KDTree,
 
  I'm using KDTree to spoof the location of some actual geometry, which
 is
  transformed in a vertex/geometry shader.
 
  So, I compute a bounding box for where the geometry ought to be, and
 create
  a dummy geometry from that - I then compute the KDTree for this dummy
  geometry, and assign it to the actual geometry that will be sent down the
  pipe, which is at the scene origin, not its final location.
 
  When the line-segment intersector goes to pick, it first checks to see if
  the line segment intersects the bounding box of the drawable, which as
 far
  as I can tell is computed against the actual geometry (in this case the
  geometry at the origin) and not the KDTree's bounding box.  When it
 doesn't
  properly intersect, the line-segment intersector returns without hitting
 the
  KDTree.
 
  I think what is needed is to test against the KDTree bounding box, rather
  than the geometry bounding box, if a KDTree is assigned.
 
  Does this make any sense?
 
  sean
 
  On Wed, Dec 3, 2008 at 10:05 AM, Sean Spicer [EMAIL PROTECTED]
 wrote:
 
  Robert,
 
  I will see if I can repro the problem with osgpick and send you the osg
  file.  It may take me a week or two though as I've got a lot on my plate
 ;-)
 
  cheers,
 
  sean
 
  On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield 
 [EMAIL PROTECTED]
  wrote:
 
  Hi Sean,
 
  This sounds like a bug, but without a dataset and example that
  reproduces the problem it's next to impossible to home in on a fix.
  Would it be possible for you to provide a problem dataset that
  illustrates the problem?  If it can be reproduced with one of the
  existing examples like osgpick then this will make it easier to track
  down.
 
  Robert.
 
  On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED]
  wrote:
   Hi Gang,
  
   I'm working on improving picking performance via KDTree, but I'm
   hitting an
   issue that is driving me nuts: If I pick a node from directly above
   (e.g. +
   Z axis) everything works great, and picking is *very* fast.  If I
 pick
   at an
   angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate
 -
   nodes
   to the left, right, top, or bottom get picked instead of what I'm
   after.
  
   Here is my KDTree Build function:
  
   #ifdef USE_KDTREE
  
   // Update the KDTree
   osg::KdTree::BuildOptions kdTreeBuildOptions;
   osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
  
   if(kdTree-build(kdTreeBuildOptions, geometry))
   {
   geometry-setShape(kdTree.get());
   }
   else
   {
   LOG_MSG(logERROR)  osg::KdTree::build() unsuccessful.;
   }
   #endif
  
   Any suggestions?
  
   cheers,
  
   sean
  
   ___
   osg-users mailing list
   osg-users@lists.openscenegraph.org
  
  
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
  
  
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
  ___
  osg-users mailing list
  osg-users@lists.openscenegraph.org
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
 
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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


Re: [osg-users] KDTree Picking (at an angle)

2008-12-03 Thread Sean Spicer
Robert,

I will see if I can repro the problem with osgpick and send you the osg
file.  It may take me a week or two though as I've got a lot on my plate ;-)

cheers,

sean

On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi Sean,

 This sounds like a bug, but without a dataset and example that
 reproduces the problem it's next to impossible to home in on a fix.
 Would it be possible for you to provide a problem dataset that
 illustrates the problem?  If it can be reproduced with one of the
 existing examples like osgpick then this will make it easier to track
 down.

 Robert.

 On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED]
 wrote:
  Hi Gang,
 
  I'm working on improving picking performance via KDTree, but I'm hitting
 an
  issue that is driving me nuts: If I pick a node from directly above (e.g.
 +
  Z axis) everything works great, and picking is *very* fast.  If I pick at
 an
  angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate -
 nodes
  to the left, right, top, or bottom get picked instead of what I'm after.
 
  Here is my KDTree Build function:
 
  #ifdef USE_KDTREE
 
  // Update the KDTree
  osg::KdTree::BuildOptions kdTreeBuildOptions;
  osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
 
  if(kdTree-build(kdTreeBuildOptions, geometry))
  {
  geometry-setShape(kdTree.get());
  }
  else
  {
  LOG_MSG(logERROR)  osg::KdTree::build() unsuccessful.;
  }
  #endif
 
  Any suggestions?
 
  cheers,
 
  sean
 
  ___
  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] KDTree Picking (at an angle)

2008-12-02 Thread Sean Spicer
Hi Gang,

I'm working on improving picking performance via KDTree, but I'm hitting an
issue that is driving me nuts: If I pick a node from directly above (e.g. +
Z axis) everything works great, and picking is *very* fast.  If I pick at an
angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate - nodes
to the left, right, top, or bottom get picked instead of what I'm after.

Here is my KDTree Build function:

#ifdef USE_KDTREE

// Update the KDTree
osg::KdTree::BuildOptions kdTreeBuildOptions;
osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();

if(kdTree-build(kdTreeBuildOptions, geometry))
{
geometry-setShape(kdTree.get());
}
else
{
LOG_MSG(logERROR)  osg::KdTree::build() unsuccessful.;
}
#endif

Any suggestions?

cheers,

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


[osg-users] osgDB loader question

2008-11-04 Thread Sean Spicer
Is there a way to load files from a byte-buffer?  I'd like to be able to
store certain shape-files as resources and load them with something similar
to:

osgDB::readNodeFile(shapeFile)

something like:

osgDb::readFromByteBuffer(char *buffer, size_t size);

I can't find anything like this in the API, does it exist?

cheers,

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


Re: [osg-users] Cull-Traversal Performance

2008-10-31 Thread Sean Spicer
Robert, interesting.  Thank you for the detailed explanation.

Looking at the osgforest shader-path, one challenge that I see is that if
one needs to be able to pick the geometry, then the SG doesn't know about
where it is in space to run an interesector.  Any thoughts on a strategy to
overcome this?  I was thinking about hidden geometry, but the intersector
wouldn't see it.

cheers,

sean

On Fri, Oct 31, 2008 at 4:31 AM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi Sean,

 Welcome back :-)

 Transforms are relatively expensive, as the transforms need to be
 tracked as well as the view frustum needing to be transformed into the
 local coords below the transform for culling performance.  You two
 subgraphs have 100 vs 10,000 transforms per frame, 100 won't take the
 cull traversal much at all, but 10,000 will.

 Second up having lots of separate osg::Geometry, even when a small
 number of shared many times, requires lots of work in cull in doing
 the actual cull test and more critically creating all the RenderLeaf
 back end data structure required to represent the Geometry instance
 with its final combination of modelview, projection and state.

 So as a general rule, keep the number of transforms down, by applying
 the transforms to the subgraphs and copying the geometry if required,
 and keep the the number of separate geometries down by combining
 smaller geometries into bigger groups.

 Since you culls do look rather high even with the small scene set up,
 while it's a bit of long shot, make sure that you do all your tests in
 release/optimized build.

 Another area you could look at at inspiration is the osgforest example
 - it provides a range of implementations of forests that you can step
 between, in the svn/trunk version of the OSG I've added in the
 StatsHandler to show the relative costs of cull/draw and GPU.   You
 run the osgforest example with a command line option to set the number
 of trees for instance:

  osgforest --trees 1

 This will give you an indication of the how each of the techniques
 might work in your instance.  In particular the shader path would
 probably be most applicable.

 Other items you could look at is the use the multi-threaded use of
 osgViewer, as the DrawThreadPerContext would certainly help hide the
 cost of your long cull.

 Finally we have had some check-in's since OSG-2.6 include
 optimizations in Matrix that reduce the overhead associated with
 Transforms.  So try out the SVN/trunk or 2.7.x developer releases.

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




-- 
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.281.466.4848
Mobile...+1.713.447.2706
Fax...+1.281.466.4849
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Cull-Traversal Performance

2008-10-31 Thread Sean Spicer
Thanks.  Is there a primmer on osg::KdTree anywhere?

sean

On Fri, Oct 31, 2008 at 9:37 AM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi Sean,

 On Fri, Oct 31, 2008 at 2:16 PM, Sean Spicer [EMAIL PROTECTED]
 wrote:
  Looking at the osgforest shader-path, one challenge that I see is that if
  one needs to be able to pick the geometry, then the SG doesn't know
 about
  where it is in space to run an interesector.  Any thoughts on a strategy
 to
  overcome this?  I was thinking about hidden geometry, but the
 intersector
  wouldn't see it.

 The where on earth is it paradox with vertex shaders..

 Probably the easiest way to solve would be to manually create an
 osg::KdTree for where the geometry would be if it had been transformed
 and then attach this KdTree to the Drawable where the vertex shader is
 playing games.  This would speed intersections as well as solve the
 where on earth is it.

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




-- 
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.281.466.4848
Mobile...+1.713.447.2706
Fax...+1.281.466.4849
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Reversed Normal in Smoothing Visitor on TRIANGLE_STRIP

2008-10-31 Thread Sean Spicer
Hi All,

OSG 2.7.4 - I'm seeing a reversed normal when running
osgUtil::SmoothingVisitor on a drawable containing only tri-strips.  Not
sure if it is the first or last vertex, but I've repeated it with several
different examples.

Has anyone else seen this?

sean

-- 
Sean Spicer
Executive Vice President  Chief Technology Officer
Aqumin (www.aqumin.com)
Office+1.281.466.4848
Mobile...+1.713.447.2706
Fax...+1.281.466.4849
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Cull-Traversal Performance

2008-10-30 Thread Sean Spicer
Hi Folks,

First off, let me say that it's good to be back on the list - it has been
awhile ;-)

I'm trying to tune a scene-graph representing a relatively-large model.  I'm
seeing what I think are abnormally long cull-traversal times.  The SG looks
as follows:

(State is constant across the entire scene)

[Group] x 1
   |
[Switch] x 1
   |
[MatrixTransform] x 100
   |
[Geode] x 1
   |
[Geometry] x 100

There are approx 10K Geometry Drawables in the overall scene.  The cull
traversal for this scene graph is approx 10ms on a 2.5GHz Core2Duo
processor.

If I change the SG to the following:

[Group] x 1
   |
[Switch] x 1
   |
[MatrixTransform] x 100
   |
[Switch] x 1
   |
   +-+
   | |
[Geode] x 1 [MatrixTransform] x 100
   | |
[Geometry] x 100  [Geode] x 1
 |
 [Geometry] x 1

and I turn on the new branch, the cull traversal jumps to 80ms.  If I
eliminate the single Geometry node below the new geode (so that the new
branch is still there, but doesn't draw anything, cull-traversal falls to
40ms.

Can anyone help explain what is going on here?  These cull-traversal times
seem long relative to the complexity of the scene and the speed of the
processor - I'm trying to hit a 60Hz frame-rate, and even 10ms for the cull
is just not going to cut it.  For better or worse, there isn't a good way to
simplify the complexity of the scene.

cheers,

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