Re: [osg-users] Segfault in VTP, but looks like OSG: SOLVED

2008-11-10 Thread Ben Discoe
Thanks Robert, for include/osg/Config.  Starting with OSG 2.6, the VTP can now 
check OSG_USE_FLOAT_MATRIX to detect whether OSG was built with float matrices 
or not.  That makes it easy to handle both cases, so the user doesn't need it 
built one way or the other.

It is not so surprising that the VTP prefers float matrices:

1. It is pointless to use the extra RAM (and memory bandwidth, and CPU time) 
for double matrices, when they aren't needed.

2. The rest of VTP's stack uses single matrices, so having OSG use doubles does 
not even gain theoretical precision improvement.  It would have to be all 
doubles, top to bottom.

3. OpenGL itself is single-precision, so at best doubles would affect 
temporary, intermediate computations.

4. In many years, i have never encountered any rare situation that would be 
improved with double matrices.  I'm certain they exist (among the many unusual 
uses of OSG) but since they are less common, it would make far more sense for 
single matrices to be the default.

The VTP uses double-precision for GIS data, and single-precision for the 3d 
scenegraph.  A design which requires the scenegraph to be double-precision is 
arguably.. an odd choice.

-Ben

 -Original Message-
 From: Robert Osfield
 Sent: Saturday, September 13, 2008 2:29 AM
 
 Hi Pascal,
 
 I wonder if you could add something to the VTP build system to detect
 problems with Matrixd being used for Matrix.  The other thing one
 might be able to do is adapt VTP so that it can handle Matrxf and
 Matrixd versions of Matrix.  With OSG 2.6 onward there now is an
 include/osg/Config which includes details of the which version of
 Matrix is used, perhaps this might be of some help.
 
 As a general note, I've always been surprised by VTP using float
 Matrices, as GIS related app I would have expect double Matrices as it
 solves many of the precision problems associated with real world data.
 
 Robert.
 
 On Sat, Sep 13, 2008 at 9:40 AM, Pascal Rheinert
 [EMAIL PROTECTED] wrote:
  Hi,
  I got exactly the same error when trying to start VTP
  And I solved it now:
  The reason is (as expected) a discrepency between what
  OSG does by default and what VTP expects concerning
  the Matrix

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


Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Robert Osfield
Hi Jan,

On Sun, Nov 9, 2008 at 7:03 PM, Jan Ciger [EMAIL PROTECTED] wrote:
 Just a parenthesis - I gave quite a bit of feedback to Cedric about
 this. I think that there are some design issues that need to be
 addressed first, before it even reaches basic feature parity with
 existing code in osgCal or Replicant when concerning basic animation
 support (not the more advanced stuff in Replicant).

And this is why I wanted to encourage discussion about it from those
experienced with osgCal etc. ;-)

osgAnimation does have a lot of promise, that promise is most likely
to be fulfilled with usage and refinement.  This is exactly how the
core OSG shaped up from being a tiny niche scene graph that could
render a shiny cow to one that can do what it does today.

 Physics is an integration issue as we'll never attempt to do wholesale
 physics ourselves, I haven't reviewed any strong candidates for this
 role yet.

 I wouldn't try to integrate physics as such - that is a monstrous job
 and you would be tied to one engine that doesn't fit everyone (which
 one? ODE? Bullet? Havoc? ...)

 I would rather make things easy to integrate by the end users (e.g. an
 easy way to get bounding boxes and meshes from  the nodes at runtime for
 collision detection) and perhaps include a collision detection support
 in the core scenegraph. This has been a persistent question over the
 years and a good integration of collision detection needs support from
 the scenegraph.

I covered this point in my email on the physics integration thread - I
don't want an osgPhysics library tied to specific physics engine, but
rather a NodeKit that facilitates the integration of physics engines.
It's best to track down this email as it goes into my thoughts on this
topic in far more detail than is appropriate to repeat here.

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


[osg-users] Getting a Camera to Render Only Once.

2008-11-10 Thread Kim C Bale
I've created a custom switch inherited from osg::Group that is designed
to control a series of RTT cameras which only need to render to texture
once at varying times.

 

So I achieve this by modifying the traverse method. I check for a
CullVisitor, then if a child state is set to render a single frame, I
pass the CullVisitor to the child and then tell the CullVisitor to
ignore it on subsequent visits. (See attached code).

 

So in my test app, my graph looks a bit like this:

 

Root

|___ CustomSwitch - RTTCamera - Scene

|

|___ PostRenderCam - ScreenAlignedQuad

 

This works as long as viewer.frame() has been called at least once on
graph. Otherwise the objects are rendered black.

 

So this test code works:

 

-

viewer.frame();

 

while(!viewer.done()) 

{

   static bool addMe = true;

   if(addMe){

  frameSwitch-addChild( cam1, FrameSwitch::SINGLE_FRAME );

  addMe = false;

   }

   viewer.frame();

}

-

 

Whilst this code renders black objects:

 

-

while(!viewer.done()) 

{

   static bool addMe = true;

   if(addMe){

  frameSwitch-addChild( cam1, FrameSwitch::SINGLE_FRAME );

  addMe = false;

   }

   viewer.frame();

}

-

 

So, my question is what's happening on that first CullVisitor that's not
later on? Obviously doing that extra call to frame() fixes it but it's
not a very tidy solution.

 

Cheers.

 

Kim.

 

 



traverse.cpp
Description: traverse.cpp
*
To view the terms under which this email is distributed, please go to 
http://www.hull.ac.uk/legal/email_disclaimer.html
*___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] camera postion problem

2008-11-10 Thread Wiebe Hoekstra
I have used the follow node tutorial to get the track the node. 

http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/CameraControlNodeFollowing

This seems to be working fine. But a look at the wrong site off the
ship. Therefore i have changed the getInverseMatrix() to the following:

m = m_matrix *
osg::Matrixd::rotate(osg::DegreesToRadians(180.0),osg::Vec3(1,0,0));

I was expecting to look at the top of the ship, but it is the bottom and
it looks like the area is mirrored. 

I thing the wrong movements off the mouse is a side affect off the wrong
orientation off the camera.

Wiebe


On Mon, 2008-11-10 at 13:03 +, Robert Osfield wrote:
 Hi Wiebe,
 
 I'm afraid your email lacks enough information to be able to comment.
 You have to start by explaining how you are trying to track the node
 in the scene, and how this relates to how you are managing mouse
 movements.
 
 Robert.
 
 On Mon, Nov 10, 2008 at 12:53 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
  Hi users,
 
  I try to track a node in a scene. This scene is a area with a ship. The
  node i try to follow is the ship. All seems oke but the complete scene
  seems to be mirrored.
  Even the mousse movents in x direction are inverse.
 
  Wiebe
 
 
 
  ing. Wiebe Hoekstra
  Software Engineer
  Maritime Simulation Group
  mailto:[EMAIL PROTECTED]
  T +31 317 49 35 19
 
  MARIN
  2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands
  T +31 317 49 39 11, F +31 317 49 32 45, I http://www.marin.nl/
 
 
 
 
 
  MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
 
 
  This e-mail may be confidential, privileged and/or protected by copyright. 
  If you are not the intended recipient, you should return it to the sender 
  immediately and delete your copy from your system.
 
  
MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
This e-mail may be confidential, privileged and/or protected by copyright. If 
you are not the intended recipient, you should return it to the sender 
immediately and delete your copy from your system.
___


  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] Many RTT cameras, strange out of memory errors on Linux

2008-11-10 Thread J.P. Delport

Hi,

Robert Osfield wrote:

Hi J.P,

On Mon, Nov 10, 2008 at 6:56 AM, J.P. Delport [EMAIL PROTECTED] wrote:

if anyone has some spare time, please execute the attached test app under
Linux. I am still unsure if our problems are related to NVidia driver, Linux
distribution, ...


I haven't had a chance to test but I will this test it this week.  In
fact I will be writing a general memory test program that will
allocate till exhaustion on a range of OSG classes that manage OpenGL,
FBO's will be among the tests.  I've had feedback that of poorer
scaling in OSG/OpenGL memory under Vista (an 8GB machine) than I'm
getting under 4GB linux box, so my guess is that we may well find
different OpenGL/OSG features scaling well on some
OS's/drivers/hardware and poorly on others, each with their own
oddities...


This would be very informative, thanks Robert. I'm still unsure whether 
 our problem is related to FBOs/Cameras+Renderstage.


regards
jp



Robert.


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


Re: [osg-users] camera postion problem

2008-11-10 Thread Robert Osfield
Hi Wiebe,

I'm afraid your email lacks enough information to be able to comment.
You have to start by explaining how you are trying to track the node
in the scene, and how this relates to how you are managing mouse
movements.

Robert.

On Mon, Nov 10, 2008 at 12:53 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
 Hi users,

 I try to track a node in a scene. This scene is a area with a ship. The
 node i try to follow is the ship. All seems oke but the complete scene
 seems to be mirrored.
 Even the mousse movents in x direction are inverse.

 Wiebe



 ing. Wiebe Hoekstra
 Software Engineer
 Maritime Simulation Group
 mailto:[EMAIL PROTECTED]
 T +31 317 49 35 19

 MARIN
 2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands
 T +31 317 49 39 11, F +31 317 49 32 45, I http://www.marin.nl/





 MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao


 This e-mail may be confidential, privileged and/or protected by copyright. If 
 you are not the intended recipient, you should return it to the sender 
 immediately and delete your copy from your system.

 ___
 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] GL Books

2008-11-10 Thread Robert Osfield
Hi Can,

OpenGL Distilled, OpenGL Shading Language and OpenGL Reference Manual
(blue book) are all on my shelf.  Paul Martz gave me the OpenGL
Distilled as gift, and while it's a bit too introductory for me it is
a great intro for those coming to OpenGL for the first time.

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


Re: [osg-users] controlling swap

2008-11-10 Thread Robert Osfield
Hi Ed,

I wrote about this exact topic a couple of weeks back, so go have look
through the archives on this discussion.

The short story is that I moving between the two is not difficult, and
I'd start with the easier of the two viewers's - osgViewer::Viewer but
learn a bit about CompisteViewer too so you know roughly what you
might need to change later.

Robert.

On Mon, Nov 10, 2008 at 3:34 AM, Ed [EMAIL PROTECTED] wrote:
 After reading osgViewer::Viewer vs osgViewer::CompositeViewer, I think I
 might need to use CompositeViewer at some point in the future of my project,
 but not at the outset.  Should I begin with the CompositeViewer, or make the
 necessary mods later?  How difficult is it to change from Viewer to
 CompositeViewer later?

 Ed
 ___
 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] GL Books

2008-11-10 Thread Can T. Oguz
Hi,

As an intermediate openGL and OSG user I'm just about to order an openGL
book. Is there any favorite one in your bookshelf to advice me?

Thanks for reading,

P.S. Please let me state that there's no intention of advertising any
author's book before the discussion cheers up :)

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


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-10 Thread Robert Osfield
HI Sekender,

The colour array is required when you have the glColorMaterial
enabled, this is driven by osg::Material::setColorMode(), or when
lighting is disabled.  Have a read of OpenGL docs of the affect of
materials, color material and colour arrays on geometries and OpenGL
lighting.

As this has not fixed the issue then have a look to see if lighting is
on, but no normals are attached, again you need normals if you are
using lighting.

Robert.

On Sun, Nov 9, 2008 at 9:12 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert and Jean-Sébastien,

 Thanks for your ideas. My model is an .osg so I know there is a normal array 
 and no texturing, and I manually replaced OPAQUE/DEFAULT.

 You both said that I need a colour array with at least one overall colour.
 Well, can you tell me why I need a colour array? I don't know why the color 
 array from some other drawables will bleed into any other drawable which does 
 not have a color array. Maybe an openGL consideration I'm not aware of...
 Anyway, there is a Material in my object (as posted before), but no colour 
 array. So I added:
  ColorArray 1 {
1.0 1.0 1.0 1.0
  }
  ColorBinding BIND_OVERALL
 in each Geometry in the .osg, just as you both suggested, but it has no 
 effect.

 That's *really really* strange... As maybe noone has enough time for such a 
 problem, I think I'm going to drop it and create a workaround by tweaking the 
 Blender exporter. If I'm wrong (= someone has enough time), just tell me so 
 that I send the code.

 Thank you very much for your help.

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Fri, 07 Nov 2008 10:51:19 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 On Fri, Nov 7, 2008 at 12:14 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I confirm that the strange behavior still exist while compiling against the 
 rev 9119 (branch osgWidget-dev).

 I don't have any further suggests beyond my earlier suggestion that
 some vertex data such as normals, texcoord or colour arrays aren't
 assigned to geometries that they should be.  Write you model out to
 .osg and have a look through them.  If you have lighting on then
 you'll need a normal array, if you are use default osg::Material
 you'll need at a colour array with at least one overall colour, if you
 are doing texturing then you'll need texture coords.

 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

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


Re: [osg-users] camera postion problem

2008-11-10 Thread Robert Osfield
Hi Wiebe,

Only you know what the right position is for your app.  This is once
you have the model matrix that the codes provide is all boils down
basic a vector maths question, it's not my role to teach you this,
there are plenty of books that do this.

Robert.

On Mon, Nov 10, 2008 at 1:43 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
 hi,

 I have tried to use the NodeTrackerManipulator as well but i can't get
 it in the right place. If you could tell me how to rotate the camera to
 the right position maybe this could be a solution.
 For the trackball manipulator it is possible to set the rotation. I
 haven't found a way to do this with the NodeTrackerManipulator.

 Grtz Wiebe



 On Mon, 2008-11-10 at 13:37 +, Robert Osfield wrote:
 Hi Wiebe,

 I'm afraid I'm not familiar with this particular tutorial code so
 answer a question on it would have learn it first, which puts me one
 step behind where you are already.

 The osgGA library has a similar class call NodeTrackerManipulator
 which might not server your purpose exactly might be a better base.
 I wrote NodeTrackerManipulator so am a little better on off
 understanding what on earth it's supposed to do front.

 Robert.

 On Mon, Nov 10, 2008 at 1:19 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
  I have used the follow node tutorial to get the track the node.
 
  http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/CameraControlNodeFollowing
 
  This seems to be working fine. But a look at the wrong site off the
  ship. Therefore i have changed the getInverseMatrix() to the following:
 
  m = m_matrix *
  osg::Matrixd::rotate(osg::DegreesToRadians(180.0),osg::Vec3(1,0,0));
 
  I was expecting to look at the top of the ship, but it is the bottom and
  it looks like the area is mirrored.
 
  I thing the wrong movements off the mouse is a side affect off the wrong
  orientation off the camera.
 
  Wiebe
 
 
  On Mon, 2008-11-10 at 13:03 +, Robert Osfield wrote:
  Hi Wiebe,
 
  I'm afraid your email lacks enough information to be able to comment.
  You have to start by explaining how you are trying to track the node
  in the scene, and how this relates to how you are managing mouse
  movements.
 
  Robert.
 
  On Mon, Nov 10, 2008 at 12:53 PM, Wiebe Hoekstra [EMAIL PROTECTED] 
  wrote:
   Hi users,
  
   I try to track a node in a scene. This scene is a area with a ship. The
   node i try to follow is the ship. All seems oke but the complete scene
   seems to be mirrored.
   Even the mousse movents in x direction are inverse.
  
   Wiebe
  
  
  
   ing. Wiebe Hoekstra
   Software Engineer
   Maritime Simulation Group
   mailto:[EMAIL PROTECTED]
   T +31 317 49 35 19
  
   MARIN
   2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands
   T +31 317 49 39 11, F +31 317 49 32 45, I http://www.marin.nl/
  
  
  
  
  
   MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, 
   Bilbao
  
  
   This e-mail may be confidential, privileged and/or protected by 
   copyright. If you are not the intended recipient, you should return it 
   to the sender immediately and delete your copy from your system.
  
  
  MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
  This e-mail may be confidential, privileged and/or protected by copyright. 
  If you are not the intended recipient, you should return it to the sender 
  immediately and delete your copy from your system.
 
 MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
 This e-mail may be confidential, privileged and/or protected by copyright. If 
 you are not the intended recipient, you should return it to the sender 
 immediately and delete your copy from your system.
 ___


 
 
   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

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


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-10 Thread Sukender
Hi Robert,

Thanks for the openGL explanation.
Well, I already checked for the normals (I didn't know for the 
Material/ColorArray, but I knew for this!)... And they're ok (Lighting is on).

Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


Le Mon, 10 Nov 2008 10:29:14 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 HI Sekender,

 The colour array is required when you have the glColorMaterial
 enabled, this is driven by osg::Material::setColorMode(), or when
 lighting is disabled.  Have a read of OpenGL docs of the affect of
 materials, color material and colour arrays on geometries and OpenGL
 lighting.

 As this has not fixed the issue then have a look to see if lighting is
 on, but no normals are attached, again you need normals if you are
 using lighting.

 Robert.

 On Sun, Nov 9, 2008 at 9:12 PM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert and Jean-Sébastien,

 Thanks for your ideas. My model is an .osg so I know there is a normal array 
 and no texturing, and I manually replaced OPAQUE/DEFAULT.

 You both said that I need a colour array with at least one overall colour.
 Well, can you tell me why I need a colour array? I don't know why the color 
 array from some other drawables will bleed into any other drawable which 
 does not have a color array. Maybe an openGL consideration I'm not aware 
 of...
 Anyway, there is a Material in my object (as posted before), but no colour 
 array. So I added:
  ColorArray 1 {
1.0 1.0 1.0 1.0
  }
  ColorBinding BIND_OVERALL
 in each Geometry in the .osg, just as you both suggested, but it has no 
 effect.

 That's *really really* strange... As maybe noone has enough time for such a 
 problem, I think I'm going to drop it and create a workaround by tweaking 
 the Blender exporter. If I'm wrong (= someone has enough time), just tell me 
 so that I send the code.

 Thank you very much for your help.

 --
 Sukender
 PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/


 Le Fri, 07 Nov 2008 10:51:19 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 On Fri, Nov 7, 2008 at 12:14 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi again Robert,

 I confirm that the strange behavior still exist while compiling against 
 the rev 9119 (branch osgWidget-dev).

 I don't have any further suggests beyond my earlier suggestion that
 some vertex data such as normals, texcoord or colour arrays aren't
 assigned to geometries that they should be.  Write you model out to
 .osg and have a look through them.  If you have lighting on then
 you'll need a normal array, if you are use default osg::Material
 you'll need at a colour array with at least one overall colour, if you
 are doing texturing then you'll need texture coords.

 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

 ___
 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] GL Books

2008-11-10 Thread Peter Wraae Marino
Hi,

I would recommend the red-book and opengl super-bible.
the blue book is a reference book and most of the information in
it is available on the net.

Peter

On Mon, Nov 10, 2008 at 1:13 PM, Can T. Oguz [EMAIL PROTECTED] wrote:

 Hi,

 As an intermediate openGL and OSG user I'm just about to order an openGL
 book. Is there any favorite one in your bookshelf to advice me?

 Thanks for reading,

 P.S. Please let me state that there's no intention of advertising any
 author's book before the discussion cheers up :)

 Can

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




-- 
Regards,
Peter Wraae Marino

www.osghelp.com - OpenSceneGraph support site
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Using slave cameras for composite rendering (part II)

2008-11-10 Thread Peter Wraae Marino
Hi users,

I have create a little test code here:
http://www.osghelp.com/downloads/SlaveCameras.txt

basically I add two slave games
the application runs and the view is doing what I expect
but I get the following messags:

The interface is unknown.
A null context handle was passed from the client to the host during a
remote procedure call.
The binding handle is invalid.
anyone know what's wrong?
also an added note:
if I addSlave twice
and try to remove them then the application is unstable and crashes.
seems to be something broken here?

anyone?

-- 
Regards,
Peter Wraae Marino

www.osghelp.com - OpenSceneGraph support site
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] GraphicsContext

2008-11-10 Thread Peter Wraae Marino
Hi users,

In our attempt to make a composite view using slave camera.. we have
had some succes but also failure.

Biggest problem is getting the render order of the cameras to work.
We tried adding them in the correct order, but we needed to use
the removeSlave (which seems to be broken)

Now we tried to use the GraphicsContext render order, but had a problem
that they did not sort correctly.

looking into the code:

struct CameraRenderOrderSortOp
{
inline bool operator() (const Camera* lhs,const Camera* rhs) const
{
if (lhs-getRenderOrder()rhs-getRenderOrder()) return true;
if (rhs-getRenderOrder()lhs-getRenderOrder()) return false;
return lhs-getRenderOrderNum()lhs-getRenderOrderNum();
}
};

if you notice the last line, it is using lhs for both getRenderOrderNum()
which will result in a constant return false value. I believe this is a bug,
correct me if I'm wrong.

-- 
Regards,
Peter Wraae Marino

www.osghelp.com - OpenSceneGraph support site
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] need to port an application from OSG v1.2 (OSG::Producer based) to OSG 2.0 (OsgViewer based)

2008-11-10 Thread Eric Sokolowsky

Jean-Sébastien Guay wrote:

Hi Eric,


hiding the mouse pointer is not supported


osgViewer::GraphicsWindow::useCursor(false) should do that... Though 
you're on Mac so perhaps GraphicsWindowCarbon doesn't work properly?


J-S


Hey, thanks! I guess I should have looked more carefully.

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


Re: [osg-users] osgCairo and osgPango on Windows : some progress

2008-11-10 Thread Jeremy Moles
On Mon, 2008-11-10 at 00:23 -0500, Jean-Sébastien Guay wrote:
 Hi Jeremy,
 
  I'm working on packing up my changes for osgCairo and osgPango now. Will 
  send soon.
 
 I've finished my first pass of changes to make osgCairo and osgPango 
 build and run on Windows. The result is attached to this message, as SVN 
 patches.
 
 I've tried to comment changes to the CMake files so that you know why 
 they're required. In general, they're analogous to things in OSG's CMake 
 files. Also, there is one added file in each case 
 (include/osg{Pango|Cairo}/Export), make sure you don't miss it.
 
 Note that some changes might strike you as unneeded, but MSVC requires 
 them. Such changes are for example the cast to double in fabs (MSVC 
 gives an ambiguous function call error if fabs is called with an int 
 but returning a double), and the default arguments for some constructors 
 so that you get the equivalent of a default constructor.
 
 One thing I didn't test is anything that depends on recent changes in 
 the osgWidget branch. I didn't compile the osgWidget branch here at 
 home, so I just wanted things to compile for this first pass (anything 
 else was gravy). As a result, I just commented out such things and 
 compiled. One example is in osgPango/src/Label.cpp (Label::parented() 
 and Label::_removeDrawables()). Also, I commented out osgpangoanimation 
 and osgpangoguiviewer from the osgPango CMakeLists.txt file just so I 
 could get a full build and install. I haven't included those changes, 
 but I also haven't tested those functionalities as a result.
 
 I've taken a bit more time in order to actually test some things. Here 
 are the results:
 
 * osgcairoviewer runs and gives the image attached
(osgcairoviewer.jpg, resized to 25%)
 
 * osgcairowidget runs and gives the image attached
(osgcairowidget.jpg, resized to 25%)
 
 * osgcairomatrix runs and gives the output in osgcairomatrix.txt
 
 * osgpangofonts runs and gives the output in osgpangofonts.txt
 
 * osgpangoviewer --font Arial 20 --width 800 --alignment justify
 --alpha 0.6 runs and gives the image attached (only the bottom part
 of the screen, with the cow rotated slightly to show the alpha is
 correct)

So, are you able to notice any difference in font quality under Windows?
Each glyph should be sharp and crisp, with absolutely not visual
anomalies of any sort. This is harder to do than you might think, so it
was always the most important (and the reason for writing the kit in the
first place!)

Also, add:

--cache outline 2

...as an arg, or:

--cache shadowOffset 1

...or something like that. :)

 * osgpangocustomrenderer runs and gives the image attached
(osgpangocustomrenderer.jpg, resized to 25%) but also outputs the
following warning (though it seems normal since I really don't have
that font :-) ):
 
(osgpangocustomrenderer.exe:1476): Pango-WARNING **: couldn't load
font iNked God Not-Rotated 45, falling back to Sans Not-Rotated
45, expect ugly output.
 
 So, all the examples I've been able to compile seem to run perfectly, 
 both in debug and release, on Windows. I think that's pretty cool. :-)
 
 As soon as you can integrate these changes, I'll re-update at work 
 (where I have the osgWidget branch compiling regularly) and try out the 
 other things.
 
 Good night,
 
 J-S
 plain text document attachment (osgCairo.patch)
 Index: CMakeLists.txt
 ===
 --- CMakeLists.txt(revision 26)
 +++ CMakeLists.txt(working copy)
 @@ -4,6 +4,12 @@
  
  SET(CMAKE_MODULE_PATH ${PROJECT_SOURCE_DIR}/etc/)
  
 +# Use a debug postfix to distinguish build products. Mostly important on
 +# Windows, because linking a debug library into a release executable (or
 +# vice-versa, or just mixing C++ runtime versions) on Windows will lead
 +# to crashes if the libraries use the C++ runtime.
 +SET(CMAKE_DEBUG_POSTFIX d CACHE STRING Add a postfix, usually d on 
 windows)
 +
  # On GCC, we need to set these compiler flags.
  IF(NOT WIN32)
   SET(CMAKE_CXX_FLAGS -W -Wall -Wno-unused)
 @@ -27,6 +33,7 @@
  )
  
  SET(HEADER_FILES
 + ${osgCairo_SOURCE_DIR}/include/osgCairo/Export
   ${osgCairo_SOURCE_DIR}/include/osgCairo/Glyph
   ${osgCairo_SOURCE_DIR}/include/osgCairo/Image
   ${osgCairo_SOURCE_DIR}/include/osgCairo/Matrix
 @@ -55,9 +62,28 @@
  
  ADD_LIBRARY(osgCairo SHARED ${SRC_FILES} ${HEADER_FILES})
  
 -TARGET_LINK_LIBRARIES(osgCairo osg osgUtil osgViewer cairo)
 +# Add debug postfix to OSG libraries so we link to the right ones in debug.
 +# Cairo is a C-only library so the same one (release) can be linked to both
 +# debug and release without problems.
 +TARGET_LINK_LIBRARIES(osgCairo
 +  debug OpenThreads${CMAKE_DEBUG_POSTFIX}
 +  optimized OpenThreads
 +  debug osg${CMAKE_DEBUG_POSTFIX}
 +  optimized osg
 +  

Re: [osg-users] controlling swap

2008-11-10 Thread Ed
I think the discussion you refer to was initiated by my question then 
too.  I am not sure how this question ended up in this email...  I was 
copying and pasting and something went wrong, but the subject line 
indicates what the topic was meant to be.  I have resubmitted the 
correct question.

Ed

Robert Osfield wrote:

Hi Ed,

I wrote about this exact topic a couple of weeks back, so go have look
through the archives on this discussion.

The short story is that I moving between the two is not difficult, and
I'd start with the easier of the two viewers's - osgViewer::Viewer but
learn a bit about CompisteViewer too so you know roughly what you
might need to change later.

Robert.

On Mon, Nov 10, 2008 at 3:34 AM, Ed [EMAIL PROTECTED] wrote:
  

After reading osgViewer::Viewer vs osgViewer::CompositeViewer, I think I
might need to use CompositeViewer at some point in the future of my project,
but not at the outset.  Should I begin with the CompositeViewer, or make the
necessary mods later?  How difficult is it to change from Viewer to
CompositeViewer later?

Ed
___
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] osgCairo and osgPango on Windows : some progress

2008-11-10 Thread Jean-Sébastien Guay

Hi Jeremy,


So, are you able to notice any difference in font quality under Windows?


Versus what, normal osgText? Or the osgfont example?

I'll check that out when I get home tonight (unless you've already 
merged my changes? :-) )



Each glyph should be sharp and crisp, with absolutely not visual
anomalies of any sort. This is harder to do than you might think, so it
was always the most important (and the reason for writing the kit in the
first place!)


Oh, I believe you! If it were easy, osgText would do it by default I 
imagine...



Also, add:

--cache outline 2

...as an arg, or:

--cache shadowOffset 1

...or something like that. :)


OK, once again I'll check that out tonight.

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   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] Controlling swap (Not the question about View vs. Composite View)

2008-11-10 Thread Ed
In the Viewer examples I have seen, it appears that the rendering is 
initiated by calling viewer.run().



In my code I am implementing hardware based synchronization amonst  multiple 
renderers and I need to control the render or draw, as well as  the swap.  How 
do I get this control?  Do I use draw traversals?  Are there examples of this?  
Also under what situations would I want to use cull and update traversals?  
Examples of these?

Ed


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


Re: [osg-users] Need explanation about a strange behaviour with RenderBin

2008-11-10 Thread Robert Osfield
On Mon, Nov 10, 2008 at 10:06 AM, Sukender [EMAIL PROTECTED] wrote:
 Thanks for the openGL explanation.
 Well, I already checked for the normals (I didn't know for the 
 Material/ColorArray, but I knew for this!)... And they're ok (Lighting is on).

Are you able to export an .osg or .ive file that contains your
complete but not working model?  Others could then load it to see if
it's a platform specific issue.

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


Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Wang Rui
Hi Robert,
I agree that a new library should be added carefully, or it will become a
burden for developers and users. I plan to devide the modeling library into
several parts: basic modelers (extrusions, revolutions), parametric curves
and surfaces (Bezier and NURBS), polygon technologies (simplification,
subdivision and triangle striping) and helpers (BSP, animation deformers,
k-dop, OBB bounding boxes, boolean operators). Some of them are in
progress and some in design. It need a long time before practical uses, but
I will try to make the library stable and usable and prepare for
the integration at any time.
I would also help improve the documents of OSG classes and functions. At
present, I am a maintainer of the osgchina website and try to help some of
the Chinese beginners realize OSG principles more easily, also have
translated Paul Martz's famous OSGQSG into Chinese and finished
writing series of tutorials. Maybe I could help complete some of the
comments in comming days.

Regards,
Wang Rui

2008/11/10 Robert Osfield [EMAIL PROTECTED]

 Hi Wang Rui,

 I was wondering about mentioning modelling functionality in my email,
 but held back as it's potentially a huge and complex topic in itself.

 I certainly open to nurbs support in the core OSG, hard stuff are
 items like computing accurate intersections between nurbs.  The same
 goes for basic geometry construction.  Currently we have various
 things for creating scene graph elements in osgUtil, and the
 ShapeDrawable in core osg.  If we had a osgModelling NodeKit/utility
 library then these elements might be best moved into osgModelling.

 The are a number of areas in geometry creation that can get very
 complex, I know because I've done a work in this in the past -
 sometimes things get far more complex than original expected once you
 deal with real world data.  This complexity also raises the bar for
 how many users are capable of helping maintain it.  The fewer the
 users available to maintain the more often it falls on my shoulders to
 fix problems, but given my role these days I have to function as a
 multi-tasker covering many different topics it makes it very hard for
 me to have sufficient time and focus to tackle these complex problems.
  Due to this maintenance issue taking on any NodeKit makes me bit
 nervous, the more advanced it is the more of challenge it will be for
 me to keep on top of it.

 There already couple of NodeKit's in the OSG that I already feel not
 fully able to maintain them, and these NodeKit's have been effectively
 orphaned so it has ended up on my shoulders to maintain them.  New
 NodeKit's don't solve these existing maintenance issue only add to the
 possible burden so I have to be very careful.   Having NodeKit's
 develop out in the community and be shook down prior to integration is
 the way forward on this.

 Robert.

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


Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-10 Thread Alberto Luaces
Hi JP,

I always get the same errors (92  80) during execution (see below). My system 
is

Linux 2.6.26-1-amd64
GeForce 7600 GS, driver 173.14.12
256 MB

Got an X11ErrorHandling call display=0x114f600 event=0x7fff4f229750
BadWindow (invalid Window parameter)
Major opcode: 92
Minor opcode: 4
Error code: 3
Request serial: 3a86
Current serial: 3a86
  ResourceID: 2e3
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5
Got an X11ErrorHandling call display=0x114f600 event=0x7fff4f2296e0
BadAlloc (insufficient resources for operation)
Major opcode: 80
Minor opcode: 1b
Error code: b
Request serial: 3a87
Current serial: 3a88
ResourceID: 2e3


El Lunes 10 Noviembre 2008ES 07:56:25 J.P. Delport escribió:
 Hi all,

 if anyone has some spare time, please execute the attached test app
 under Linux. I am still unsure if our problems are related to NVidia
 driver, Linux distribution, ...

 thanks
 jp

 J.P. Delport wrote:
  Hi all,
 
  a colleague of mine is trying to implement an image processing algorithm
  that requires many RTT cameras (+-150).
 
  His algorithm runs on his Windows machine, but fails under Linux (I'm
  quite sad about it :) with some of the following errors:
 
  --8--
 
  Got an X11ErrorHandling call display=0x80a8c80 event=0xbf991100
  BadAlloc (insufficient resources for operation)
 
  Got an X11ErrorHandling call display=0x80a8c80 event=0xbf991160
  BadDrawable (invalid Pixmap or Window parameter)
 
  Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
  RenderStage::drawInner(,) FBO status= 0x8cd5
 
  --8--
 
  We've narrowed the problem down to just camera creation and frame
  rendering. Texture sizes do not seem to influence the error. I've made a
  small test application (attached) that creates the errors.
 
  On my Linux laptop the errors start appearing at around 220 cameras. On
  another Linux machine we can get about 10 more. On Windows we've been
  able to test up to 3000 (the apps starts up too slowly if we add more).
 
  Does anyone have any ideas about why and where the cameras are creating
  X resources?
 
  Art (if you are around), does osgPPU use osg::Camera? Maybe we can move
  to osgPPU if not.
 
  Any pointers to help us debug are welcome.
 
  regards
  jp
 
 
 
  
 
  ___
  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] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Sukender
 Hi Sukender,

 On Mon, Nov 10, 2008 at 11:06 AM, Sukender [EMAIL PROTECTED] wrote:
 I agree that dependencies are generally a burden when compiling OSG (thanks 
 to those who maintain 3rd party libs!). And I won't suggest intagration of 
 huge libs anymore!
 But do you think some users could be interested in code that has 
 dependencies, but distrubuted *outside* OSG? I mean perhaps some people 
 already said I want library XYZ to be integrated into OSG ; so maybe this 
 could be useful to put links to existing code on the wiki? Maybe a 
 Already-coded libs integrations-like paragraph anywhere on the wiki could 
 be useful? Well, that's just an idea...

 We already have a Wiki page for community maintained NodeKits.

  http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits

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

Allright, I thought it was only for nodekits, not for integration of a specific 
library.

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] X3D content

2008-11-10 Thread Jan Ciger
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ami guru wrote:
 Does OSG has any support node to load X3D content?

Try to look in the archives, this was discussed before. I believe the
OpenVRML loader will load some of it, but I didn't try it. OpenVRML
library provides the parsing, so you need to look there.

Regards,

Jan

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFJGGLnn11XseNj94gRAvWqAJ9cjS04cGMtO7V72eFCLLZr/+FfcACggeGz
3bBJXvbTpHLqMcWz/2EoI6c=
=xIua
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Robert Osfield
Hi Sukender,

On Mon, Nov 10, 2008 at 11:06 AM, Sukender [EMAIL PROTECTED] wrote:
 I agree that dependencies are generally a burden when compiling OSG (thanks 
 to those who maintain 3rd party libs!). And I won't suggest intagration of 
 huge libs anymore!
 But do you think some users could be interested in code that has 
 dependencies, but distrubuted *outside* OSG? I mean perhaps some people 
 already said I want library XYZ to be integrated into OSG ; so maybe this 
 could be useful to put links to existing code on the wiki? Maybe a 
 Already-coded libs integrations-like paragraph anywhere on the wiki could 
 be useful? Well, that's just an idea...

We already have a Wiki page for community maintained NodeKits.

 http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits

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


[osg-users] Which data to test osgvolume?

2008-11-10 Thread Mario Valle

Which kind of data file do I need to test osgvolume?
Is it possible to distribute a small example with OSG-Data?
Thanks a lot!
mario

--
Ing. Mario Valle
Data Analysis Group  | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS)  | Tel:  +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax:  +41 (91) 610.82.82
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Animation (was: Re: NodeKit integration in OpenSceneGraph-2.x series)

2008-11-10 Thread Jan Ciger
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Eric,

Erik den Dekker wrote:
 Jan, I followed your comments to Cedric and above with interest. You made
 several important remarks to ensure that osgAnimation will properly support
 character animation / skeletal animation. 
 
 However, I wonder if you are not putting too much emphasis on just this
 aspect while there may be more ways to do and use animation. It is my
 understanding that animation means that a certain aspect of a scene is under
 control so it can be changed over time. This aspect is usually orientation,
 position or scale, but may also be color, a float weight, a bool, a string,
 etc... maybe some custom type. IMHO osg should take a generic approach
 towards animation, albeit probably not too generic :).

I think that basic position/orientation/scale style animation is
supported by OSG already. No need to reinvent the wheel there.


 Perhaps 3D studio max
 (or similar - I just happen to have some experience with this app) can be
 taken as an example how to approach animation. It uses animation controllers
 and key frame animation to implement animation and in my experience this is
 quite flexible. I wonder how far osgAnimation should go in replicating
 similar functionality.

That's fine, however I would be extremely wary of an all-encompassing
animation framework that tries to do everything and does nothing well. I
think that it is better to take the Unix-like approach - a set of
small tools that do one thing, but do it really well. That means, that
if you need only translation/rotation/scaling you use a simple
keyframing support that is in OSG already, if you need skeleton you use
osgAnimation or osgCal, if you need morphing, you use a (yet not
existing) morphing library.

The only thing these things have in common is a that they vary over
time. That is already well supported in OSG - both the real time and
simulation time.

There is nothing else really common in the code and shoehorning all this
into one is not a good thing from the maintainability and usability
point of view. The Max example is a red herring - unless you plan to
develop an animation package, it has little relation to OSG.  In Max it
makes sense to have all under a single roof, because the animator
usually uses several of the tools at once and Max authors cannot predict
whether he or she is going to make characters or animate flying boxes.
However, the underlying code is very different under the hood for each
tool.

That said, there is nothing that prevents Cedric (or someone else) to
implement e.g. support for morph targets in the skeletal animation lib
or making osgAnimation a collection of tools to support different types
of animation instead of just a skeleton-based one. However, I think that
this is as far as it should go - if you need something special, you are
better off developing a special tool for it, than trying to bend the
existing codebase to do things it was not intended for.


 This said, I must admit that I have only quickly glanced over osgAnimation
 in its current state, and I believe it already supports much of what I
 mentioned.

I am not sure what you mean - right now all it does is a simple software
skinning of models animated via skeletons. There isn't really a notion
of a controller or anything.

Regards,

Jan


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFJGBCon11XseNj94gRAreEAJ9jVs08NPYxrnaWv04hsmLweiz9OwCfabz3
vNWQmiXZghXnfaqIUOzL4eU=
=UeSJ
-END PGP SIGNATURE-
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Controlling swap (Not the question about View vs. Composite View)

2008-11-10 Thread Robert Osfield
Hi Ed,

The examples are written to be focus primarily on the feature they
demonstrate so a rather minimal in terms of viewer code, viewer.run()
being a helper function that wraps up the whole rendering.  Have a
look at the implementation of run() and you'll find essentially:

 if (!viewer.isRealize()) viewer.realize();
 while(!viewer.done())
{
 viewer.frame();
}


Now viewer frame() in term is basically another help function that
wraps up the traversals, so you can rewrite in your own app:

 while(!viewer.done())
 {
viewer.advance();
viewer.updateTraversal();
viewer.eventTraversal());
viewer.renderingTraversals();
  }

The cull and draw are all wrapped up in the renderingTraversal()
method that dispatches the traversals when running single threaded or
coordinates the blocks/barriers required by each of the threading
models.

You can subclass from rendreinTraversals() if you so wished but most
of the time this will be unnecessary.  You can add your own sync code
if you want into camera initial/pre,post and final callbacks, and no
matter what threading model these will be called.  You can also add
Rendering operations into the GraphicsContext's operations list, or
override the osgViewer::Renderer which does the actual cull and draw
traversals.

Robert.


On Mon, Nov 10, 2008 at 2:29 PM, Ed [EMAIL PROTECTED] wrote:
 In the Viewer examples I have seen, it appears that the rendering is
 initiated by calling viewer.run().


 In my code I am implementing hardware based synchronization amonst  multiple
 renderers and I need to control the render or draw, as well as  the swap.
  How do I get this control?  Do I use draw traversals?  Are there examples
 of this?  Also under what situations would I want to use cull and update
 traversals?  Examples of these?

 Ed


 ___
 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] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Sukender
Hi Robert,

 Hi Sukender,

 On Mon, Nov 10, 2008 at 9:56 AM, Sukender [EMAIL PROTECTED] wrote:
 ** About utilities:
 I coded some little features that could be integreated into OSG, but I have 
 one problem: these are often specific and very small (not enough to create a 
 nodekit). So what? May I suggest them to be integrated into osgUtil or such? 
 In osg-submissions perhaps?
 Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP 
 networking (TNL).

 We have to be careful about when and where we do feature integration.
 Sometime integration could be put into a pre-exisitng library, I do
 raise this point in my first post, but countering this if extra
 external dependencies are brought in by an addition.

Err... well, I'm not sure I explained myself the right way. I was saying that I 
coded some utilities *that have no other depedency* than OSG but that could be 
a little bit specific. So you think that I may discuss them on osg-submissions, 
or here? (The note about openAL/TNL was something completely different...)


 ** About dependencies:
 I agree that dependencies should be added only when really needed, but in 
 another hand, it is sometimes useful to link against lower-level portable 
 libraries. I'm actually thinking about boost libraries (filesystem.path, 
 program_options, and smart pointers).
 For instance, I coded overloads of osgSB::read*() that take 
 boost::filesystem::path. The main benefit is of course to handle paths the 
 same way under many OSes. Do you think that it could be possible in OSG?

 Each dependency needs to be viewed on its own merit, and kept to
 specific scope.  The larger the dependency the smaller the scope it
 should have, i.e. be kept to a plugin or a specific NodeKit.  This
 approach allows users to be able to gain the bulk of OSG functionality
 without needing to pull together other significant libs.  Boost is
 something that I'd put under the category of a big dependency and as
 such isn't something that should go any where near the core OSG that
 needs to be kept as light and easily portable with minimal
 dependencies.  You are welcome to add such dependencies to your own
 app, but for the OSG I need to keep the core clean as possible as it's
 the common denominator that we all share.

 As guide I'd recommend having a look at the way I've managed exisiting
 NodeKits and dependencies.  You'll find the core OSG libs all just
 depend upon principally C++ and OpenGL, this is something that has
 guided OSG development right from the beginning and is something that
 has helped the OSG port to far more platforms than competing real-time
 graphics toolkits.

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


I agree that dependencies are generally a burden when compiling OSG (thanks to 
those who maintain 3rd party libs!). And I won't suggest intagration of huge 
libs anymore!
But do you think some users could be interested in code that has dependencies, 
but distrubuted *outside* OSG? I mean perhaps some people already said I want 
library XYZ to be integrated into OSG ; so maybe this could be useful to put 
links to existing code on the wiki? Maybe a Already-coded libs 
integrations-like paragraph anywhere on the wiki could be useful? Well, that's 
just an idea...


Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Segfault in VTP, but looks like OSG: SOLVED

2008-11-10 Thread Paul Speed



Ben Discoe wrote:

Thanks Robert, for include/osg/Config.  Starting with OSG 2.6, the VTP can now 
check OSG_USE_FLOAT_MATRIX to detect whether OSG was built with float matrices 
or not.  That makes it easy to handle both cases, so the user doesn't need it 
built one way or the other.

It is not so surprising that the VTP prefers float matrices:

1. It is pointless to use the extra RAM (and memory bandwidth, and CPU time) 
for double matrices, when they aren't needed.

2. The rest of VTP's stack uses single matrices, so having OSG use doubles does 
not even gain theoretical precision improvement.  It would have to be all 
doubles, top to bottom.

3. OpenGL itself is single-precision, so at best doubles would affect 
temporary, intermediate computations.


As Robert states, the double matrix accumulation means that precision 
errors are eliminated on their way to the openGL model/view matrices. 
So if you are close to something, you get really good precision.  If you 
are far away, you don't but it also doesn't matter.




4. In many years, i have never encountered any rare situation that would be 
improved with double matrices.  I'm certain they exist (among the many unusual 
uses of OSG) but since they are less common, it would make far more sense for 
single matrices to be the default.


Anecdotally, in one of our apps we could not draw city blocks on a 
float-based whole earth database because the buildings tended to stack 
on top of each other.  Resolution was something awful (I remember it 
being as high as 100 meters).  Double matrices fix that problem 
completely without anything else special.


-Paul



The VTP uses double-precision for GIS data, and single-precision for the 3d 
scenegraph.  A design which requires the scenegraph to be double-precision is 
arguably.. an odd choice.

-Ben


-Original Message-
From: Robert Osfield
Sent: Saturday, September 13, 2008 2:29 AM

Hi Pascal,

I wonder if you could add something to the VTP build system to detect
problems with Matrixd being used for Matrix.  The other thing one
might be able to do is adapt VTP so that it can handle Matrxf and
Matrixd versions of Matrix.  With OSG 2.6 onward there now is an
include/osg/Config which includes details of the which version of
Matrix is used, perhaps this might be of some help.

As a general note, I've always been surprised by VTP using float
Matrices, as GIS related app I would have expect double Matrices as it
solves many of the precision problems associated with real world data.

Robert.

On Sat, Sep 13, 2008 at 9:40 AM, Pascal Rheinert
[EMAIL PROTECTED] wrote:

Hi,
I got exactly the same error when trying to start VTP
And I solved it now:
The reason is (as expected) a discrepency between what
OSG does by default and what VTP expects concerning
the Matrix


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

2008-11-10 Thread Paul Speed

From the peanut gallery (since I'm watching this with great interest)...

If this new node kit is only going to handle skeleton-based animation 
then maybe osgAnimation is not the best name.

-Paul

Jan Ciger wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Eric,

Erik den Dekker wrote:

Jan, I followed your comments to Cedric and above with interest. You made
several important remarks to ensure that osgAnimation will properly support
character animation / skeletal animation. 


However, I wonder if you are not putting too much emphasis on just this
aspect while there may be more ways to do and use animation. It is my
understanding that animation means that a certain aspect of a scene is under
control so it can be changed over time. This aspect is usually orientation,
position or scale, but may also be color, a float weight, a bool, a string,
etc... maybe some custom type. IMHO osg should take a generic approach
towards animation, albeit probably not too generic :).


I think that basic position/orientation/scale style animation is
supported by OSG already. No need to reinvent the wheel there.



Perhaps 3D studio max
(or similar - I just happen to have some experience with this app) can be
taken as an example how to approach animation. It uses animation controllers
and key frame animation to implement animation and in my experience this is
quite flexible. I wonder how far osgAnimation should go in replicating
similar functionality.


That's fine, however I would be extremely wary of an all-encompassing
animation framework that tries to do everything and does nothing well. I
think that it is better to take the Unix-like approach - a set of
small tools that do one thing, but do it really well. That means, that
if you need only translation/rotation/scaling you use a simple
keyframing support that is in OSG already, if you need skeleton you use
osgAnimation or osgCal, if you need morphing, you use a (yet not
existing) morphing library.

The only thing these things have in common is a that they vary over
time. That is already well supported in OSG - both the real time and
simulation time.

There is nothing else really common in the code and shoehorning all this
into one is not a good thing from the maintainability and usability
point of view. The Max example is a red herring - unless you plan to
develop an animation package, it has little relation to OSG.  In Max it
makes sense to have all under a single roof, because the animator
usually uses several of the tools at once and Max authors cannot predict
whether he or she is going to make characters or animate flying boxes.
However, the underlying code is very different under the hood for each
tool.

That said, there is nothing that prevents Cedric (or someone else) to
implement e.g. support for morph targets in the skeletal animation lib
or making osgAnimation a collection of tools to support different types
of animation instead of just a skeleton-based one. However, I think that
this is as far as it should go - if you need something special, you are
better off developing a special tool for it, than trying to bend the
existing codebase to do things it was not intended for.



This said, I must admit that I have only quickly glanced over osgAnimation
in its current state, and I believe it already supports much of what I
mentioned.


I am not sure what you mean - right now all it does is a simple software
skinning of models animated via skeletons. There isn't really a notion
of a controller or anything.

Regards,

Jan


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFJGBCon11XseNj94gRAreEAJ9jVs08NPYxrnaWv04hsmLweiz9OwCfabz3
vNWQmiXZghXnfaqIUOzL4eU=
=UeSJ
-END PGP SIGNATURE-
___
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] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Sukender
Hi Robert, hi everyone,

I agree with your vision and think that this will push OSG to more power and 
popularity. Grouping, refactoring and factorizing are always great ideas - even 
if that would require a lot of work from the whole community.

About physics: I want to say something, but I didn't found the physics 
integration thread... (I just changed my email address so that my inbox is 
almost empty!)


** About utilities:
I coded some little features that could be integreated into OSG, but I have one 
problem: these are often specific and very small (not enough to create a 
nodekit). So what? May I suggest them to be integrated into osgUtil or such? In 
osg-submissions perhaps?
Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP 
networking (TNL).


** About organization:
I think that work that is enough general purpose should be integrated into 
OSG, but that maybe needs a little bit organization: as the number of functions 
and classes will grow, the user may get lost. Here are some ideas:
- Create sub-namespaces to split big ones
- Create an index (in reference docs) by theme (meshes boolean operations, 
image processing, post-render effects, spatialized audio...)
- And of course update the wiki as it is already!
For me, that's leaving less and less code in my engine, which is great news - 
since it could be useful to more people of course.


** About dependencies:
I agree that dependencies should be added only when really needed, but in 
another hand, it is sometimes useful to link against lower-level portable 
libraries. I'm actually thinking about boost libraries (filesystem.path, 
program_options, and smart pointers).
For instance, I coded overloads of osgSB::read*() that take 
boost::filesystem::path. The main benefit is of course to handle paths the same 
way under many OSes. Do you think that it could be possible in OSG?


Sincerely,

-- 
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/



Le Sun, 09 Nov 2008 17:25:34 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 Hi All,

 There has been lots of discussion about various NodeKit or last month
 or two.  In OSG-2.6 we saw the introduction of osgWidget from the
 community, in OSG-2.8 we'll see the integration of new osgVolume
 library.  OSG-2.10 is likely to see the integration of osgAnimation,
 but if things converge quickly for this NodeKIt it might even make it
 into OSG-2.8.

 There are other NodeKits out into the community, some are up to date
 and well maintained others rather dormant or even orphaned.  Each of
 these NodeKit could be put forward for integration with the core OSG.
 Whether any of these should be integrated and if so how one goes about
 is something that is worthy of discussion. I don't think we need
 heavily structured metrics to measure NodeKits against, but some
 informal metrics might help provide some transparency in the process.
 Here's a couple to get started with:

 1) What overall feature set does the OpenSceneGraph need as it evolves
 to better meet the common needs of the community?

All NodeKits needs to be take as a step towards this goal, this
 includes ones already in OpenSceneGraph trunk.

But how to define the goals for the OpenSceneGraph for the 2.x and
 3.x series and beyond?

 2) All NodeKit to make into the core OpenSceneGraph need to be
 portable across all platforms. (Or might there be exceptions??)

 3) All NodeKit to make into the core OpenSceneGraph need to fit to the
 C++ design and coding style

 4) All NodeKit need to be activity used and supported by a range of
 members in the community.

 5) Granularity of NodeKits need to fit the function as well as the
 breadth/complexity of functionality encompassed.

 6) Where functionality of two NodeKits overlap then for integration to
 occur the NodeKit need to be merged in some fashion,
 this might be that osgOriginal and osgNew get merged into
 osgOriginal, or even into a osgBetterNameForCombination.

 Migration to new merged classes/NodeKits would require a system
 for helping existing users migrate / provide deprecated functionality
 for a defined period.

 7) Naming of NodeKits should be descriptive of it's function, prefer
 long descriptive name over short acronyms.

 8) NodeKits should have ascii read/write support, but ideally binary
 support too (we really need an extensible binary format).

 9) NodeKits must be wrap-able via osgIntrospection/genwrapper.

 10) NodeKit should facilitate collaboration and quell fragmentation of
 code and developer resources.

 11) NodeKit should be of solid design and implementation quality.

 12) NodeKit and dependency proliferation should be deemed a negative
 quality - a NodeKit must add real value to compensate for the
  extra complexity it introduces.

 OK, feel free to add more/refine the above.  Once this discussion
 reaches some kind of conclusion I'll put up a page on the WIKI
 summarising it all.

 Putting the above 

[osg-users] X3D content

2008-11-10 Thread ami guru
Does OSG has any support node to load X3D content?


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


Re: [osg-users] Segfault in VTP, but looks like OSG: SOLVED

2008-11-10 Thread Robert Osfield
Hi Ben,

On Mon, Nov 10, 2008 at 8:11 AM, Ben Discoe [EMAIL PROTECTED] wrote:
 Thanks Robert, for include/osg/Config.  Starting with OSG 2.6, the VTP can 
 now check OSG_USE_FLOAT_MATRIX to detect whether OSG was built with float 
 matrices or not.  That makes it easy to handle both cases, so the user 
 doesn't need it built one way or the other.

Kudos to Matthias Froehilch on this useful feature :-)

 It is not so surprising that the VTP prefers float matrices:

 1. It is pointless to use the extra RAM (and memory bandwidth, and CPU time) 
 for double matrices, when they aren't needed.

Um a small number of double Matrix is unlikely to ever be a memory
issue.  If you running on a 16k ZX Spectrum then I might say that this
is a valid point, but these days with multi-gigabyte machines as
standard.

 2. The rest of VTP's stack uses single matrices, so having OSG use doubles 
 does not even gain theoretical precision improvement.  It would have to be 
 all doubles, top to bottom.

Perhaps it's time to change the VTP stack so it supports double matrices

 3. OpenGL itself is single-precision, so at best doubles would affect 
 temporary, intermediate computations.

This is the key point to using double Matrices in the OSG, all the
Camera and scene graph Transform nodes are accumulated in double
matrices so that as far as possible the intermediate computation all
cancel out as far as possible prior to being passed to OpenGL.   This
strategy works extremely well - allowing the OSG to work with full
gecentric databases and still zoom into ground level and not see any
jitter.

 4. In many years, i have never encountered any rare situation that would be 
 improved with double matrices.  I'm certain they exist (among the many 
 unusual uses of OSG) but since they are less common, it would make far more 
 sense for single matrices to be the default.

I guess you've never built a whole earth database yet...  This is what
VirtualPlanetBuilder does, and scales very well to multi-terrabyte
databases, the use of double Matrices is central to the OSG being able
to cope with the precision issues seamlessly.


 The VTP uses double-precision for GIS data, and single-precision for the 3d 
 scenegraph.  A design which requires the scenegraph to be double-precision is 
 arguably.. an odd choice.

Wow, like the year 2000 never ticked over.

There are many OSG users that absolutely rely upon the use of double
Matrices.  All the vis-sim, the GIS apps, any app that does paged
databases.  All I can say is that you are out of touch with the needs
of all these users.

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


Re: [osg-users] GL Books

2008-11-10 Thread Can T. Oguz
Thank you Peter,

I think it will be super-bible and plus something more.

Can


2008/11/10 Peter Wraae Marino [EMAIL PROTECTED]

 Hi,

 I would recommend the red-book and opengl super-bible.
 the blue book is a reference book and most of the information in
 it is available on the net.

 Peter

   On Mon, Nov 10, 2008 at 1:13 PM, Can T. Oguz [EMAIL PROTECTED] wrote:

   Hi,

 As an intermediate openGL and OSG user I'm just about to order an openGL
 book. Is there any favorite one in your bookshelf to advice me?

 Thanks for reading,

 P.S. Please let me state that there's no intention of advertising any
 author's book before the discussion cheers up :)

 Can

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




 --
 Regards,
 Peter Wraae Marino

 www.osghelp.com - OpenSceneGraph support site

 ___
 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] camera postion problem

2008-11-10 Thread Wiebe Hoekstra
Hi users,

I try to track a node in a scene. This scene is a area with a ship. The
node i try to follow is the ship. All seems oke but the complete scene
seems to be mirrored. 
Even the mousse movents in x direction are inverse. 

Wiebe


 
ing. Wiebe Hoekstra
Software Engineer
Maritime Simulation Group
mailto:[EMAIL PROTECTED]
T +31 317 49 35 19

MARIN
2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands
T +31 317 49 39 11, F +31 317 49 32 45, I http://www.marin.nl/





MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao


This e-mail may be confidential, privileged and/or protected by copyright. If 
you are not the intended recipient, you should return it to the sender 
immediately and delete your copy from your system.

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


Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Robert Osfield
Hi Wang Rui,

I was wondering about mentioning modelling functionality in my email,
but held back as it's potentially a huge and complex topic in itself.

I certainly open to nurbs support in the core OSG, hard stuff are
items like computing accurate intersections between nurbs.  The same
goes for basic geometry construction.  Currently we have various
things for creating scene graph elements in osgUtil, and the
ShapeDrawable in core osg.  If we had a osgModelling NodeKit/utility
library then these elements might be best moved into osgModelling.

The are a number of areas in geometry creation that can get very
complex, I know because I've done a work in this in the past -
sometimes things get far more complex than original expected once you
deal with real world data.  This complexity also raises the bar for
how many users are capable of helping maintain it.  The fewer the
users available to maintain the more often it falls on my shoulders to
fix problems, but given my role these days I have to function as a
multi-tasker covering many different topics it makes it very hard for
me to have sufficient time and focus to tackle these complex problems.
  Due to this maintenance issue taking on any NodeKit makes me bit
nervous, the more advanced it is the more of challenge it will be for
me to keep on top of it.

There already couple of NodeKit's in the OSG that I already feel not
fully able to maintain them, and these NodeKit's have been effectively
orphaned so it has ended up on my shoulders to maintain them.  New
NodeKit's don't solve these existing maintenance issue only add to the
possible burden so I have to be very careful.   Having NodeKit's
develop out in the community and be shook down prior to integration is
the way forward on this.

Robert.

On Mon, Nov 10, 2008 at 12:45 AM, Wang Rui [EMAIL PROTECTED] wrote:
 Hi Robert.

 I wonder if there is a plan to add a modeling library to the core OSG in
 future. Not because I'm working on a similar library 'osgModeling', but also
 from the experiences of other 3D graphics APIs. Take VRS3D for example, it
 has a number of common functionalitys which help build user customized
 models from curves and parameters, like extrusions (VRS::Extrusion),
 revolutions (VRS::Hyperboloid), torus and the most important, Bezier and
 NURBS.
 Of course, OSG focuses on how to improve the efficiency of rendering and
 most models are generated from external libraries and software (like
 3dsmax). But some times we may need build models from curve and point data
 of end-users. It is a trouble if these data should be converted by other
 software and transferred back to OSG, especially on the network. Also a
 modeling nodekit is a good place for some of existing classes to live in,
 like Delaunay, Simplifier and SmoothingVisitor, and a good start for future
 developments. Maybe we could create and assemble models using a modeling
 nodekit and control them with an animation nodekit in comming days.

 I would like to help develop such nodekits and share my existing code if
 others have better plans and actions. Also I would keep on developing
 osgModeling as a external project if a modeling library is not needed at
 present, and be glad to do any work to improve and popularize OSG. There are
 thousands of OSG members in China (statistics from the osgchina forum) and
 it will be a great power of the OSG community in any time.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] A patch to enable making hardware extensions disabled in Texture.cpp

2008-11-10 Thread Robert Osfield
HI Tat,

Could you post the whole modified file to osg-submissions I can then
review it their alongside the rest of the code submissions.

Thanks,
Robert.

On Sun, Nov 9, 2008 at 5:38 PM, Tatsuhiro Nishioka
[EMAIL PROTECTED] wrote:
 Hi there,

 I received some crash reports on FlightGear/OSG from a user who uses nVidia 
 7300GT on Macs.
 Debugging on an iMac gave me that hardware mipmapping on its driver caused 
 the crash.
 so I once made a fix-it-only-for-this-issue kinda patch that simply disable 
 hardware mipmapping when
 the renderer is NVIDIA GeForce 7300GT OpenGL Engine,  and that actually 
 fixed the problem.
 (see http://www.mail-archive.com/[EMAIL PROTECTED]/msg18674.html
 for more detail on this problem and the patch.)

 However, I'm wondering if users can disable hardware extensions to avoid such 
 problems.
 I tried 
 OSG_GL_EXTENSION_DISABLE=GL_SGIS_generate_mipmap;GL_EXT_framebuffer_object 
 but nothing happened.
 Taking a look at Texture.cpp tells me you can never disable hardware 
 extensions if your OpenGL driver version = 1.4 (or 2.0)
 It calls isGLExtensionSupported to check if an extension is supported but 
 these will never called.
 For example, the following code is for checking hardware mipmapping extension:

_isGenerateMipMapSupported = (strncmp((const 
 char*)glGetString(GL_VERSION),1.4,3)=0) ||
   
 isGLExtensionSupported(contextID,GL_SGIS_generate_mipmap);

 This means that isGLExtensionSupported will never be called when GL_VERSION 
 = 1.4, resulting that you cannot disable it
 since environment variable is evaluated in isGLExtensionSupported.

 Attached is the patch to make hardware extensions disabled using the 
 environment variable.
 I'm not so sure on the real purpose of the OR logic in the if statement 
 above, but it is good to give users a choice.
 Can anyone test this and check if this is a right solution?

 Best,

 Tat





 ___
 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] GL Books

2008-11-10 Thread Can T. Oguz
Never been to SGI's manuals before.

Thanks,

Can

2008/11/10 Tomlinson, Gordon [EMAIL PROTECTED]

  Pauk Martz's OpenGl Distilled
 Red Book
 Orange Book
 Opengl Bible

 As to OSG there are minimal books arounds but see www.osgbooks.com

 As a general guide to scene graphs I still recommend SGI's Performer
 Programmers Guide
 http://www.sgi.com/products/software/performer/manuals.html 99% concepts
 cross over to OSG


 *Gordon*

 __
 *Gordon Tomlinson*

 *Product Manager 3D
 **Email * : gtomlinson @ overwatch.textron.com
 __
 *(C): (+1) 571-265-2612
 (W)**: (+1) 703-437-7651*

 Self defence is not a function of learning tricks
 but is a function of how quickly and intensely one
 can arouse one's instinct for survival
 - *Master Tambo Tetsura*



  --
 *From:* [EMAIL PROTECTED] [mailto:
 [EMAIL PROTECTED] *On Behalf Of *Can T. Oguz
 *Sent:* Monday, November 10, 2008 7:13 AM
 *To:* OpenSceneGraph Users
 *Subject:* [osg-users] GL Books

   Hi,

 As an intermediate openGL and OSG user I'm just about to order an openGL
 book. Is there any favorite one in your bookshelf to advice me?

 Thanks for reading,

 P.S. Please let me state that there's no intention of advertising any
 author's book before the discussion cheers up :)

 Can

 ___
 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] Using slave cameras for composite rendering

2008-11-10 Thread Peter Wraae Marino
Hi users,

I have create a little test code here:
http://www.osghelp.com/downloads/SlaveCameras.txt

basically I add two slave games
the application runs and the view is doing what I expect
but I get the following messags:


The interface is unknown.

A null context handle was passed from the client to the host during a
remote procedure call.

The binding handle is invalid.

anyone know what's wrong?
-- 
Regards,
Peter Wraae Marino

www.osghelp.com - OpenSceneGraph support site
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] osgPPU vs RTT

2008-11-10 Thread Patrick Castonguay
Art,
From what I can understand, it uses cameras, views and viewports.  I believe 
mostly from the osgSDLView, but it also uses xlsignal? to pass the pointers 
around (this should be transparent and I am hoping that a simple casting will 
do the trick).  The way MPV works at the hi level is that a single window is 
defined (per process).  This window makes use of a single viewer which possibly 
has multiple viewports. (I guess this is pretty normal...) The views are 
defined in a definition file and the information driving them comes through the 
CIGI protocol.  Can I use the viewports and apply the osgPPU processors to 
it(them) or do I have to attach the processor to the cameras(which might be 
harder for me to do)? Also, I am still struggling with extracting my current 
scene as a texture...

Thanks for the help

Patrick



Hi Patrick.

I am not familar with MPV, however let my try to help you ;)

To
let the ppu pipeline be applied for the complete scene, you have to
provide it with a texture containing your scene as input. If you use
the standard way, scene-osgPPU::Processor-osgPPU::Unit..., and
attach a camera which views on your scene to the processor, then the
camera output (which should be an RTT) will be provided into the
pipeline. 

How is MPV handling scene rendering? Does it use
osg's camera or does it render directly to some texture without camera
intervention? If the second is true, then you can use UnitTexture as a
root unit of your pipeline to provide your rendering texture into the
pipeline.

Best regards,
Art


Hi, 
I am trying to get osgPPU to work with the MPV project (a CIGI
compliant IG)...  I am having a little bit of a hard time figuring out
how to get the two to talk to each other.  As MPV is very modular and
based on a plugin stucture, what I have to work with (so far) is the
root node of the scene.  The examples all have their own viewer that
are used by PPU but I would like to stay away from that and just
insert the pipeline to affect the intire scene (the displaying of the
scene is handled by an other plugin inside MPV).

Anybody have an idea of how could I attach a PPU pipeline to the scene? 

My other option is to not use osgPPU and start doing my own RTT, a little like 
Åsa Engvall is intending to do...


Patrick Castonguay
 
Technology Innovation Management (TIM) Student - Modeling and Simulation stream

Carleton University, Ottawa, ON___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] osgPPU vs RTT-more

2008-11-10 Thread Patrick Castonguay
Art,
As well looking into how the camera is handled, I could not find anywhere that 
uses osg::Camera, all of the camera references are using osg::Matrix which I 
am not sure how this behaves...
Cheers
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] NodeKit integration in OpenSceneGraph-2.x series

2008-11-10 Thread Robert Osfield
Hi Sukender,

On Mon, Nov 10, 2008 at 9:56 AM, Sukender [EMAIL PROTECTED] wrote:
 ** About utilities:
 I coded some little features that could be integreated into OSG, but I have 
 one problem: these are often specific and very small (not enough to create a 
 nodekit). So what? May I suggest them to be integrated into osgUtil or such? 
 In osg-submissions perhaps?
 Note : I'm also working a lille bit on audio (OpenAL - osgAL) and UDP 
 networking (TNL).

We have to be careful about when and where we do feature integration.
Sometime integration could be put into a pre-exisitng library, I do
raise this point in my first post, but countering this if extra
external dependencies are brought in by an addition.

 ** About dependencies:
 I agree that dependencies should be added only when really needed, but in 
 another hand, it is sometimes useful to link against lower-level portable 
 libraries. I'm actually thinking about boost libraries (filesystem.path, 
 program_options, and smart pointers).
 For instance, I coded overloads of osgSB::read*() that take 
 boost::filesystem::path. The main benefit is of course to handle paths the 
 same way under many OSes. Do you think that it could be possible in OSG?

Each dependency needs to be viewed on its own merit, and kept to
specific scope.  The larger the dependency the smaller the scope it
should have, i.e. be kept to a plugin or a specific NodeKit.  This
approach allows users to be able to gain the bulk of OSG functionality
without needing to pull together other significant libs.  Boost is
something that I'd put under the category of a big dependency and as
such isn't something that should go any where near the core OSG that
needs to be kept as light and easily portable with minimal
dependencies.  You are welcome to add such dependencies to your own
app, but for the OSG I need to keep the core clean as possible as it's
the common denominator that we all share.

As guide I'd recommend having a look at the way I've managed exisiting
NodeKits and dependencies.  You'll find the core OSG libs all just
depend upon principally C++ and OpenGL, this is something that has
guided OSG development right from the beginning and is something that
has helped the OSG port to far more platforms than competing real-time
graphics toolkits.

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


Re: [osg-users] camera postion problem

2008-11-10 Thread Robert Osfield
Hi Wiebe,

I'm afraid I'm not familiar with this particular tutorial code so
answer a question on it would have learn it first, which puts me one
step behind where you are already.

The osgGA library has a similar class call NodeTrackerManipulator
which might not server your purpose exactly might be a better base.
I wrote NodeTrackerManipulator so am a little better on off
understanding what on earth it's supposed to do front.

Robert.

On Mon, Nov 10, 2008 at 1:19 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
 I have used the follow node tutorial to get the track the node.

 http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/CameraControlNodeFollowing

 This seems to be working fine. But a look at the wrong site off the
 ship. Therefore i have changed the getInverseMatrix() to the following:

 m = m_matrix *
 osg::Matrixd::rotate(osg::DegreesToRadians(180.0),osg::Vec3(1,0,0));

 I was expecting to look at the top of the ship, but it is the bottom and
 it looks like the area is mirrored.

 I thing the wrong movements off the mouse is a side affect off the wrong
 orientation off the camera.

 Wiebe


 On Mon, 2008-11-10 at 13:03 +, Robert Osfield wrote:
 Hi Wiebe,

 I'm afraid your email lacks enough information to be able to comment.
 You have to start by explaining how you are trying to track the node
 in the scene, and how this relates to how you are managing mouse
 movements.

 Robert.

 On Mon, Nov 10, 2008 at 12:53 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
  Hi users,
 
  I try to track a node in a scene. This scene is a area with a ship. The
  node i try to follow is the ship. All seems oke but the complete scene
  seems to be mirrored.
  Even the mousse movents in x direction are inverse.
 
  Wiebe
 
 
 
  ing. Wiebe Hoekstra
  Software Engineer
  Maritime Simulation Group
  mailto:[EMAIL PROTECTED]
  T +31 317 49 35 19
 
  MARIN
  2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands
  T +31 317 49 39 11, F +31 317 49 32 45, I http://www.marin.nl/
 
 
 
 
 
  MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
 
 
  This e-mail may be confidential, privileged and/or protected by copyright. 
  If you are not the intended recipient, you should return it to the sender 
  immediately and delete your copy from your system.
 
 
 MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
 This e-mail may be confidential, privileged and/or protected by copyright. If 
 you are not the intended recipient, you should return it to the sender 
 immediately and delete your copy from your system.
 ___


  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] Many RTT cameras, strange out of memory errors on Linux

2008-11-10 Thread Robert Osfield
Hi J.P,

On Mon, Nov 10, 2008 at 6:56 AM, J.P. Delport [EMAIL PROTECTED] wrote:
 if anyone has some spare time, please execute the attached test app under
 Linux. I am still unsure if our problems are related to NVidia driver, Linux
 distribution, ...

I haven't had a chance to test but I will this test it this week.  In
fact I will be writing a general memory test program that will
allocate till exhaustion on a range of OSG classes that manage OpenGL,
FBO's will be among the tests.  I've had feedback that of poorer
scaling in OSG/OpenGL memory under Vista (an 8GB machine) than I'm
getting under 4GB linux box, so my guess is that we may well find
different OpenGL/OSG features scaling well on some
OS's/drivers/hardware and poorly on others, each with their own
oddities...

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


Re: [osg-users] Which data to test osgvolume? (+one question)

2008-11-10 Thread Mario Valle

Answering my own question:
It is sufficient a stack of images.
But how do you set the interslice distance? --zScale and --zMultiplier do nothing and my 
pollen seems an hamburger...


Thanks!
mario


Mario Valle wrote:

Which kind of data file do I need to test osgvolume?
Is it possible to distribute a small example with OSG-Data?
Thanks a lot!
mario



--
Ing. Mario Valle
Data Analysis Group  | http://www.cscs.ch/~mvalle
Swiss National Supercomputing Centre (CSCS)  | Tel:  +41 (91) 610.82.60
v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax:  +41 (91) 610.82.82
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] osgPPU vs RTT

2008-11-10 Thread Patrick Castonguay
Art,
From what I can understand, it uses cameras, views and viewports.  I believe 
mostly from the osgSDLView, but it also uses xlsignal? to pass the pointers 
around.  The way MPV works at the hi level is that a single window is defined 
(per process).  This window makes use a a viewer which possibly has multiple 
viewports. (I guess this is pretty normal...) The views are defined in a 
definition file and the information driving them comes through the CIGI 
protocol.  Can I use the viewports and apply the osgPPU processors to it(them) 
or do I have to attach the processor 

 
Patrick Castonguay
H: 613 435 2235
C: 613 325 1341
 
Technology Innovation Management (TIM) Student - Modeling and Simulation stream

Carleton University, Ottawa, ON
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] GL Books

2008-11-10 Thread Tomlinson, Gordon
Pauk Martz's OpenGl Distilled 
Red Book
Orange Book
Opengl Bible
 
As to OSG there are minimal books arounds but see www.osgbooks.com 
 
As a general guide to scene graphs I still recommend SGI's Performer
Programmers Guide
http://www.sgi.com/products/software/performer/manuals.html 99% concepts
cross over to OSG
 

Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

Self defence is not a function of learning tricks 
but is a function of how quickly and intensely one 
can arouse one's instinct for survival 
- Master Tambo Tetsura

 
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Can T.
Oguz
Sent: Monday, November 10, 2008 7:13 AM
To: OpenSceneGraph Users
Subject: [osg-users] GL Books


Hi,
 
As an intermediate openGL and OSG user I'm just about to order an openGL
book. Is there any favorite one in your bookshelf to advice me?
 
Thanks for reading,
 
P.S. Please let me state that there's no intention of advertising any
author's book before the discussion cheers up :)

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


Re: [osg-users] Animation

2008-11-10 Thread Robert Osfield
H Paul,

On Mon, Nov 10, 2008 at 5:54 PM, Paul Speed [EMAIL PROTECTED] wrote:
 From the peanut gallery (since I'm watching this with great interest)...

 If this new node kit is only going to handle skeleton-based animation then
 maybe osgAnimation is not the best name.

That is nothing better that criticism

Ohh yeah there *is*, it called CONSTRUCTIVE CRITICISM.

So oh of great wisdom you need to come forward with a better name.

FYI, AnimTK which has become osgAnimation is not just about skeleton
based animation, it just one of introductory features.

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


Re: [osg-users] GL Books

2008-11-10 Thread Paul Martz
I appreciate the OSG community plugging my OpenGL Distilled whenever this
subject comes up. Thanks!
 
Bob Kuehne, also in the OSG community, co-authored the recently-released
OpenGL on Mac OSX. I was a technical reviewer for that book, and as a recent
Mac convert, I can state that it contains useful and valuable information.
 
Prior to the first release of the red and blue books back in 1994, I had
already read the OpenGL spec forwards and backwards, and didn't really see
much value in the red and blue books. However, it's clear to me now that
they are much more readable than the spec, and contain much additional info
not included in the spec. So, while you can still learn OpenGL from the spec
alone, which is free to download as a PDF, you'll probably get much more use
out of a more traditional OpenGL book.
 
By the way, the OpenGL man pages (essentially the contents of the blue book)
are available online at opengl.org.
 
Paul Martz
Skew Matrix Software LLC
http://www.skew-matrix.com http://www.skew-matrix.com/ 
+1 303 859 9466
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Animation

2008-11-10 Thread Paul Speed



Robert Osfield wrote:

H Paul,

On Mon, Nov 10, 2008 at 5:54 PM, Paul Speed [EMAIL PROTECTED] wrote:

From the peanut gallery (since I'm watching this with great interest)...

If this new node kit is only going to handle skeleton-based animation then
maybe osgAnimation is not the best name.


That is nothing better that criticism

Ohh yeah there *is*, it called CONSTRUCTIVE CRITICISM.


Yikes!



So oh of great wisdom you need to come forward with a better name.

FYI, AnimTK which has become osgAnimation is not just about skeleton
based animation, it just one of introductory features.


Yeah, I was being too subtle.  The previous poster seemed to be arguing 
for only including bones/skeleton/skinning support... with everything 
else falling into different node kits.  So you either end up with 
osgAnimation not really being about general animation (osgBones?) and a 
handful of other animation related nodekits, or you (the collective 
you*) solidify the description of osgAnimation to more clearly align 
with what you (the specific you) feel it should contain.  (Which for the 
record, I agree with your take on it... ie: not just bones)


Never meant to step in the bear-trap, though.
-Paul

(*) - I might have said we but did not want to presume to include 
myself based on one errant and poorly received comment. :)


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


Re: [osg-users] osgPPU vs RTT

2008-11-10 Thread Art Tevs
Hi Patrick,

osgPPU does use the camera only in to get its texture (so the texture to which 
the scene is rendered). You do not require a camera at all, you can use 
UnitTexture to provide osgPPU pipeline with any texture (or with the texture 
you get from MPV). To provide a texture you need some protocol to get the 
texture from MPV into osg::Texture container. Have you some link to the MPV, so 
that I can get more info about it?

How are you managing the combination of osg and mpv?


cheers

--- Patrick Castonguay [EMAIL PROTECTED] schrieb am Mo, 10.11.2008:

 Von: Patrick Castonguay [EMAIL PROTECTED]
 Betreff: [osg-users] osgPPU vs RTT
 An: osg-users@lists.openscenegraph.org
 Datum: Montag, 10. November 2008, 20:46
 Art,
 From what I can understand, it uses cameras, views and
 viewports.  I believe mostly from the osgSDLView, but it
 also uses xlsignal? to pass the pointers around.
  The way MPV works at the hi level is that a single window
 is defined (per process).  This window makes use a a viewer
 which possibly has multiple viewports. (I guess this is
 pretty normal...) The views are defined in a definition file
 and the information driving them comes through the CIGI
 protocol.  Can I use the viewports and apply the osgPPU
 processors to it(them) or do I have to attach the processor 
 
  
 Patrick Castonguay
 H: 613 435 2235
 C: 613 325 1341
  
 Technology Innovation Management (TIM) Student - Modeling
 and Simulation stream
 
 Carleton University, Ottawa, ON
 ___
 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] GL Books (UNCLASSIFIED)

2008-11-10 Thread Buckley, Bob CTR MDA/IC
Classification:  UNCLASSIFIED 
Caveats: NONE




Also at the Scene Graph level I'd recommend 'Realtime Rendering' by
Haines and Moeller.

I highly recommend it's companion webpage for reference material:

   http://www.realtimerendering.com/


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Tomlinson, Gordon
Sent: Monday, November 10, 2008 5:20 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] GL Books

Pauk Martz's OpenGl Distilled
Red Book
Orange Book
Opengl Bible
 
As to OSG there are minimal books arounds but see www.osgbooks.com 
 
As a general guide to scene graphs I still recommend SGI's Performer
Programmers Guide
http://www.sgi.com/products/software/performer/manuals.html 99% concepts
cross over to OSG
 

Gordon

__
Gordon Tomlinson

Product Manager 3D
Email  : gtomlinson @ overwatch.textron.com
__
(C): (+1) 571-265-2612
(W): (+1) 703-437-7651

Self defence is not a function of learning tricks but is a function of
how quickly and intensely one can arouse one's instinct for survival 
- Master Tambo Tetsura

 
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Can T.
Oguz
Sent: Monday, November 10, 2008 7:13 AM
To: OpenSceneGraph Users
Subject: [osg-users] GL Books


Hi,
 
As an intermediate openGL and OSG user I'm just about to order an openGL
book. Is there any favorite one in your bookshelf to advice me?
 
Thanks for reading,
 
P.S. Please let me state that there's no intention of advertising any
author's book before the discussion cheers up :)

Can





Classification:  UNCLASSIFIED 
Caveats: NONE

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


[osg-users] Exception invalid lock sequence thrown from OSG App

2008-11-10 Thread Brian Stewart
I have an application that is built against OpenSceneGraph (2.6.1). The
application initializes and begins to run, but then I get the following
exception attempt was made to execute an invalid lock sequence in
OpenGL32.dll. When I re-run it, I sometimes get this exception, and
sometimes an exception about a privileged instruction. The call stack
looks like it is corrupted, so I can't really tell exactly where the
exception is being thrown from. I ran the app quite a bit a couple of days
ago and never saw this behavior. Since then I have added an else clause to a
couple of ifs, and that is all. My app is a console application, is built
with Visual Studio 2008, and it sets OpenScenGraph to SingleThreaded mode.
Anybody seen this before? Any debugging tips?

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


[osg-users] osgVR - anyone using this NodeKit?

2008-11-10 Thread Paul Pocock
Is anyone using Michael Gronager's old nodekit?


IMPORTANT: This email remains the property of the Australian Defence 
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 
1914.  If you have received this email in error, you are requested to contact 
the sender and delete the email.


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


Re: [osg-users] osgCairo and osgPango on Windows : some progress

2008-11-10 Thread Jean-Sébastien Guay

Hi Jeremy,


So, are you able to notice any difference in font quality under Windows?
Each glyph should be sharp and crisp, with absolutely not visual
anomalies of any sort. This is harder to do than you might think, so it
was always the most important (and the reason for writing the kit in the
first place!)


Yep, looks great, much better than normal osgText output (which has 
blurry characters at some sizes and characters that seem clipped one or 
two columns sometimes).



Also, add:

--cache outline 2

...as an arg, or:

--cache shadowOffset 1

...or something like that. :)


Heh, looks great too!

So, when are you going to merge my changes? :-)

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   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] OSG and OpenGL ES?

2008-11-10 Thread Hartmut Seichter


Hi there,

last time I asked nobody answered, so I try my luck again: is there 
anybody working on an OpenGL ES port? Robert, you hinted in an email 
earlier somebody works on a port - has there been anything substantial 
been created? I am just not interested reinventing the wheel ...


Cheers,
Hartmut


--
Dr. Hartmut Seichter
PhD (HKU), Dipl.-Ing. (BUW)
Post-Doctoral Fellow, HIT Lab NZ
+64 3 364 2987 Ext. 3078
http://www.hitlabnz.org/people/hse25

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


Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-10 Thread J.P. Delport

Hi Alberto,

thanks for the testing, it does seem that the problem is more general 
than my specific Linux setup.


jp

Alberto Luaces wrote:

Hi JP,

I always get the same errors (92  80) during execution (see below). My system 
is


Linux 2.6.26-1-amd64
GeForce 7600 GS, driver 173.14.12
256 MB

Got an X11ErrorHandling call display=0x114f600 event=0x7fff4f229750
BadWindow (invalid Window parameter)
Major opcode: 92
Minor opcode: 4
Error code: 3
Request serial: 3a86
Current serial: 3a86
  ResourceID: 2e3
Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5
Got an X11ErrorHandling call display=0x114f600 event=0x7fff4f2296e0
BadAlloc (insufficient resources for operation)
Major opcode: 80
Minor opcode: 1b
Error code: b
Request serial: 3a87
Current serial: 3a88
ResourceID: 2e3


El Lunes 10 Noviembre 2008ES 07:56:25 J.P. Delport escribió:

Hi all,

if anyone has some spare time, please execute the attached test app
under Linux. I am still unsure if our problems are related to NVidia
driver, Linux distribution, ...

thanks
jp

J.P. Delport wrote:

Hi all,

a colleague of mine is trying to implement an image processing algorithm
that requires many RTT cameras (+-150).

His algorithm runs on his Windows machine, but fails under Linux (I'm
quite sad about it :) with some of the following errors:

--8--

Got an X11ErrorHandling call display=0x80a8c80 event=0xbf991100
BadAlloc (insufficient resources for operation)

Got an X11ErrorHandling call display=0x80a8c80 event=0xbf991160
BadDrawable (invalid Pixmap or Window parameter)

Warning: detected OpenGL error 'out of memory' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5

--8--

We've narrowed the problem down to just camera creation and frame
rendering. Texture sizes do not seem to influence the error. I've made a
small test application (attached) that creates the errors.

On my Linux laptop the errors start appearing at around 220 cameras. On
another Linux machine we can get about 10 more. On Windows we've been
able to test up to 3000 (the apps starts up too slowly if we add more).

Does anyone have any ideas about why and where the cameras are creating
X resources?

Art (if you are around), does osgPPU use osg::Camera? Maybe we can move
to osgPPU if not.

Any pointers to help us debug are welcome.

regards
jp





___
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



--
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] Runtime error in ODE tutorial

2008-11-10 Thread Filip R. Andersson
Hi all,

I downloaded the ODE tutorial from the following page:
http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials/LMBs_ODE_Demo.zip

The code uses OSGProducer and since I don't have Producer or OSGProducer
installed on my machine I made some minor changes in the code to use
osgViewer instead.


The code compiles fine but I get the following run-time error:

---
ODE Message 2: zero length vector in dRFrom2Axes() File rotation.cpp Line
113

ODE Message 2: zero length vector in dRFrom2Axes() File rotation.cpp Line

ODE INTERNAL ERROR 2: colliders array not initialized in dCollide()
Aborted


Has anyone encountered this and how did you solve it?

I downloaded the ode-0.10.1 source code and built it  with default settings
on my Linux Machine.


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