Re: [osg-users] AutoTransform scaling precision.

[Robert Osfield]

Hi Jon,

The pixelSize function is an approximation of the mapping, making
assumptions, for the purposes of speed, with the intention of
providing good enough results for most purposes.  So rather than being
wrong, is just not accurate for your particular usage model.

The question then really is do we add another mode into AutoTransform
that uses a more expensive computation.  Feel free to adds such a mode
and support into AutoTransform and submit it.

Cheers,
Robert.

On Mon, Nov 24, 2008 at 2:04 PM, Marjamaa, Jonathon E
[EMAIL PROTECTED] wrote:
 Hi,

 I have been looking into this, and I really think there is something
 wrong with the way that AutoTransform calculates the scale.

 Attached is the screen shot showing what I am seeing in dual screen.
 Both screens are the same resolution, so I would guess the asymmetry in
 the horizontal frustum angles is confusing the algorithm somehow,
 although I am seeing problems with horizontally symmetric frustums as
 well.

 I was able to get this to work much more accurately by changing
 AutoTransform, line 182 from:

 float size = 1.0f/cs-pixelSize(getPosition(),0.48f);

 To:

 const osg::Matrix matrix = *(cs-getMVPW());
 osg::Vec3d one = cs-getUpLocal(); // get a screen aligned vector
 osg::Vec3d zeroTrans = osg::Vec3d(0, 0, 0) * matrix; // get node origin
 in screen space
 osg::Vec3d oneTrans = one * matrix;  // get vector in screen space
 float size = 1.0 / sqrt((zeroTrans[0] - oneTrans[0]) * (zeroTrans[0] -
 oneTrans[0]) +
(zeroTrans[1] - oneTrans[1]) * (zeroTrans[1] -
 oneTrans[1]) +
(zeroTrans[2] - oneTrans[2]) * (zeroTrans[2] -
 oneTrans[2])); // calculate the length of the vector in screen space

 I am sure this is more expensive, but it does get me to something more
 closely resembling localized screen space.

 Jon

 -Original Message-
 From: Marjamaa, Jonathon E
 Sent: Thursday, November 20, 2008 4:23 PM
 To: osg-users@lists.openscenegraph.org
 Subject: [osg-users] AutoTransform scaling precision.

 Hello,

 I am seeing some odd behavior with AutoTransform.  The following .osg
 file creates an AutoTransform with a grid of lines attached.  The
 lines are each separated by one unit of space.  When I look at the
 file in osgviewer, I see that this spacing is not kept.  It looks like

 the auto-scale is not exact.  The imprecision seems to vary with
 projection, viewport size, and on my windows dual-screen setup it
 varies with monitor!  If I make the window very wide and short, the
 shape is scaled so much as to actually shrink significantly in screen
 space.

 Am I using the AutoTransform incorrectly?  Am I expecting this to do
 more than was intended?

 Thanks,
 Jonathon Marjamaa

 AutoTransform {
   UniqueID AutoTransform_0
   nodeMask 0x
   cullingActive TRUE
   referenceFrame RELATIVE
   position 0 0 0
   rotation 0 0 0 1
   scale 1 1 1
   pivotPoint 0 0 0
   autoUpdateEyeMovementTolerance 0
   autoRotateMode ROTATE_TO_SCREEN
   autoScaleToScreen TRUE
   num_children 2
   Geode {
 UniqueID Geode_1
 nodeMask 0x
 cullingActive TRUE
 num_drawables 2
 Geometry {
   useDisplayList TRUE
   useVertexBufferObjects FALSE
   VertexArray UniqueID Vec3Array_3 Vec3Array 200
   {
 0 0 0
 0 150 0
 0 0 0
 150 0 0
 2 0 0
 2 150 0
 0 2 0
 150 2 0
 4 0 0
 4 150 0
 0 4 0
 150 4 0
 6 0 0
 6 150 0
 0 6 0
 150 6 0
 8 0 0
 8 150 0
 0 8 0
 150 8 0
 10 0 0
 10 150 0
 0 10 0
 150 10 0
 12 0 0
 12 150 0
 0 12 0
 150 12 0
 14 0 0
 14 150 0
 0 14 0
 150 14 0
 16 0 0
 16 150 0
 0 16 0
 150 16 0
 18 0 0
 18 150 0
 0 18 0
 150 18 0
 20 0 0
 20 150 0
 0 20 0
 150 20 0
 22 0 0
 22 150 0
 0 22 0
 150 22 0
 24 0 0
 24 150 0
 0 24 0
 150 24 0
 26 0 0
 26 150 0
 0 26 0
 150 26 0
 28 0 0
 28 150 0
 0 28 0
 150 28 0
 30 0 0
 30 150 0
 0 30 0
 150 30 0
 32 0 0
 32 150 0
 0 32 0
 150 32 0
 34 0 0
 34 150 0
 0 34 0
 150 34 0
 36 0 0
 36 150 0
 0 36 0
 150 36 0
 38 0 0
 38 150 0
 0 38 0
 150 38 0
 40 0 0
 40 150 0
 0 40 0
 150 40 0
 42 0 0
 42 150 0
 0 42 0
 150 42 0
 44 0 0
 44 150 0
 0 44 0
 150 44 0
 46 0 0
 46 150 0
 0 46 0
 150 46 0
 48 0 0
 48 150 0
 0 48 0
 150 48 0
 50 0 0
 50 

Re: [osg-users] osgswig confusion

[Gerwin de Haan]

Hi Randolph,
which osg version are you using?
Gerwin

On Mon, Nov 24, 2008 at 7:13 AM, R Fritz [EMAIL PROTECTED] wrote:
 I've been fiddling with osgswig on Mac OS (Leopard, 10.5.5), and I ran into
 a version of the vector mixin problem.  After some fuddling around, I came
 up with a patch for it (see
 http://code.google.com/p/osgswig/issues/detail?id=18) and the python
 bindings built.  But now, when I try to use them, I see:

 $ python simpleosg.py
 Traceback (most recent call last):
  File simpleosg.py, line 9, in module
import osgDB, osgViewer
  File
 /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/osgswig-0.9.0/osgDB.py,
 line 316, in module
class AuthenticationDetails(osg.Referenced):
 NameError: name 'osg' is not defined

 There seem to be some imports missing from the built code.  Did I make some
 obvious mistake?

 Randolph Fritz
  design machine group
  architecture department
  university of washington
 [EMAIL PROTECTED]

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

[Martin Großer]

Hello Alberto,

ok your example works great. I think the main difference is I change the
frustum direct on the camera object and you get the camera from the viewer
and than you change the frustum. Your way runs good, but my version doesn't
works.

I change the run function into the animation loop, like your example. Is the
idea to use the camera node as the root node the mistake?

Cheers,

Martin

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Alberto
Luaces
Gesendet: Montag, 24. November 2008 13:59
An: OpenSceneGraph Users
Betreff: Re: [osg-users] camera settings frustum

Hi Martin,

El Lunes 24 Noviembre 2008ES 13:14:03 Martin Großer escribió:
 Without the frustum definition, it works fine. With the definition, it
 works only when the value of zNear    greater is than the value of zFar.
Or
 is it normal?

Beware! There are some things to know:

- The value of near and far planes must be positive and obviously, zFar  
zNear.
- You were putting the object 25 units far away but your far plane cuts at 4

units.
- By using viewer.run(), you are adding an extra default manipulator 
(TrackballManipulator) which moves the scene for you in order to be seen by 
the camera at initialization, so it will overwrite your scene placement.
- The viewer has its own camera, you haven't to insert a new one.

This code works for me, try it out:

#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/Timer
#include osg/Group
#include osg/ArgumentParser
#include osgDB/ReadFile
#include osg/MatrixTransform

int main()
{
  // scene
  osg::ref_ptrosg::Group root = new osg::Group;

  // load object
  osg::MatrixTransform* mt = new osg::MatrixTransform;
  mt-setMatrix(::osg::Matrix::translate(0, 0, -25));
  root-addChild(mt);
  mt-addChild(osgDB::readNodeFile(cabina.obj));
  // viewer
  osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
  viewer-setSceneData(root.get());
  viewer-getCamera()-setProjectionMatrixAsFrustum(-2,2,-1.5,1.5,1,40);
  viewer-realize();

  while(!viewer-done())
{
  viewer-frame();
}
  return (0);
}
___
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 settings frustum

[Jean-Sébastien Guay]

Hello Martin,


I change the run function into the animation loop, like your example. Is the
idea to use the camera node as the root node the mistake?


As Alberto noted, the viewer already has a camera. When you were 
creating a new camera and adding that to the viewer, you effectively had 
two cameras one under the other:


  camera
camera
  scene

Because when you do setSceneData(), it adds whatever node you gave as 
child to the viewer's camera.


So having two cameras, whose projection and view matrices were being 
applied one after the other, was the mistake. You could have created a 
new camera, and then done viewer-setCamera(myCamera), and that would 
have probably worked (if your other settings were correct). But you 
might as well use the viewer's camera, and just add your actual scene 
using setSceneData(). That's the generally accepted usage model.


Hope this helps,

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

Re: [osg-users] AutoTransform scaling precision.

[Marjamaa, Jonathon E]

Hi Robert,

I agree that speed is important, but the current implementation is only
accurate for applications using near-square frustums.  With a very low
aspect ratio the returned pixel size can be as low a half of the true
pixel size.  It maybe fast but I don't think it is very robust.

I'll see what I can do about submitting my computation as an option in
AutoTransform and maybe I'll try to understand what the current
computation does.

Thanks,
Jon

-Original Message-
From: Robert Osfield [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 24, 2008 8:16 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] AutoTransform scaling precision.

Hi Jon,

The pixelSize function is an approximation of the mapping, making
assumptions, for the purposes of speed, with the intention of providing
good enough results for most purposes.  So rather than being wrong, is
just not accurate for your particular usage model.

The question then really is do we add another mode into AutoTransform
that uses a more expensive computation.  Feel free to adds such a mode
and support into AutoTransform and submit it.

Cheers,
Robert.

On Mon, Nov 24, 2008 at 2:04 PM, Marjamaa, Jonathon E
[EMAIL PROTECTED] wrote:
 Hi,

 I have been looking into this, and I really think there is something 
 wrong with the way that AutoTransform calculates the scale.

 Attached is the screen shot showing what I am seeing in dual screen.
 Both screens are the same resolution, so I would guess the asymmetry 
 in the horizontal frustum angles is confusing the algorithm somehow, 
 although I am seeing problems with horizontally symmetric frustums as 
 well.

 I was able to get this to work much more accurately by changing 
 AutoTransform, line 182 from:

 float size = 1.0f/cs-pixelSize(getPosition(),0.48f);

 To:

 const osg::Matrix matrix = *(cs-getMVPW()); osg::Vec3d one = 
 cs-getUpLocal(); // get a screen aligned vector osg::Vec3d zeroTrans 
 = osg::Vec3d(0, 0, 0) * matrix; // get node origin in screen space 
 osg::Vec3d oneTrans = one * matrix;  // get vector in screen space 
 float size = 1.0 / sqrt((zeroTrans[0] - oneTrans[0]) * (zeroTrans[0] -
 oneTrans[0]) +
(zeroTrans[1] - oneTrans[1]) * (zeroTrans[1] -
 oneTrans[1]) +
(zeroTrans[2] - oneTrans[2]) * (zeroTrans[2] - 
 oneTrans[2])); // calculate the length of the vector in screen space

 I am sure this is more expensive, but it does get me to something more

 closely resembling localized screen space.

 Jon

 -Original Message-
 From: Marjamaa, Jonathon E
 Sent: Thursday, November 20, 2008 4:23 PM
 To: osg-users@lists.openscenegraph.org
 Subject: [osg-users] AutoTransform scaling precision.

 Hello,

 I am seeing some odd behavior with AutoTransform.  The following .osg

 file creates an AutoTransform with a grid of lines attached.  The 
 lines are each separated by one unit of space.  When I look at the 
 file in osgviewer, I see that this spacing is not kept.  It looks 
 like

 the auto-scale is not exact.  The imprecision seems to vary with 
 projection, viewport size, and on my windows dual-screen setup it 
 varies with monitor!  If I make the window very wide and short, the 
 shape is scaled so much as to actually shrink significantly in screen

 space.

 Am I using the AutoTransform incorrectly?  Am I expecting this to do 
 more than was intended?

 Thanks,
 Jonathon Marjamaa

 AutoTransform {
   UniqueID AutoTransform_0
   nodeMask 0x
   cullingActive TRUE
   referenceFrame RELATIVE
   position 0 0 0
   rotation 0 0 0 1
   scale 1 1 1
   pivotPoint 0 0 0
   autoUpdateEyeMovementTolerance 0
   autoRotateMode ROTATE_TO_SCREEN
   autoScaleToScreen TRUE
   num_children 2
   Geode {
 UniqueID Geode_1
 nodeMask 0x
 cullingActive TRUE
 num_drawables 2
 Geometry {
   useDisplayList TRUE
   useVertexBufferObjects FALSE
   VertexArray UniqueID Vec3Array_3 Vec3Array 200
   {
 0 0 0
 0 150 0
 0 0 0
 150 0 0
 2 0 0
 2 150 0
 0 2 0
 150 2 0
 4 0 0
 4 150 0
 0 4 0
 150 4 0
 6 0 0
 6 150 0
 0 6 0
 150 6 0
 8 0 0
 8 150 0
 0 8 0
 150 8 0
 10 0 0
 10 150 0
 0 10 0
 150 10 0
 12 0 0
 12 150 0
 0 12 0
 150 12 0
 14 0 0
 14 150 0
 0 14 0
 150 14 0
 16 0 0
 16 150 0
 0 16 0
 150 16 0
 18 0 0
 18 150 0
 0 18 0
 150 18 0
 20 0 0
 20 150 0
 0 20 0
 150 20 0
 22 0 0
 22 150 0
 0 22 0
 150 22 0
 24 0 0
 24 150 0
 0 24 0
 150 24 0
 26 0 0
 26 150 0
 0 26 0
 150 26 0
 28 0 0
 28 150 0
 0 28 0
 150 28 0
 30 0 0
 30 150 0
 

Re: [osg-users] pragma warnings disabled in headers

[Wojciech Lewandowski]

Hi Robert,

I have restored MSVC disabled warnings in osg/Export. Difference is they are 
now disabled only when OSG_DISABLE_MSVC_WARNINGS macro is defined. This 
macro is set through CMake options and autogenerated  in osg/Config. Simon 
suggested that it would be cool if we had more control over selected 
warnings. I tried to learn how to make selection of individual warning 
numbers possible, but had to gave up as my cmake skills were not sufficient. 
The only way I saw this possible would be adding one define for each MSVC 
warning number. But many definitions seemed too be to much clutter for 
osg/Config file so I rejected thar idea. For this it would be cool if 
autogenerated Config entries could more powerful than simple #define/#undef 
flags. Maybe Cmake gurus know how to do it.


I have not reverted added Compiler options. I assume that one may want to 
have warnings enabled for the application but may not want to see them while 
OSG libraries and examples compile.


Modified files:

osg/Export   - now explicitly includes osg/Config to make sure 
OSG_DISABLE_MSVC_WARNINGS is read
osg/Config.in  - declares OSG_DISABLE_MSVC_WARNINGS flag to be added to 
autogenerated osg/Config
CMakeLists.txt - declares OSG_DISABLE_MSVC_WARNINGS as option with default 
ON setting


Cheers,
Wojtek 


Config.in
Description: Binary data

IF(WIN32)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
   IF(APPLE)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
   IF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4 AND 
${CMAKE_PATCH_VERSION} LESS 7)
   MESSAGE(Warning: A critical CMake bug exists in 2.4.6 and below. Trying 
to build Universal Binaries will result in a compile error that seems unrelated. Either 
avoid building Universal Binaries by changing the CMAKE_OSX_ARCHITECTURES field to list 
only your architecture, or upgrade to the current CVS version of CMake or a newer stable 
version if it exists.)
   ENDIF(${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4 
AND ${CMAKE_PATCH_VERSION} LESS 7)
   ELSE(APPLE)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
   ENDIF(APPLE)
ENDIF(WIN32)

if(COMMAND cmake_policy)
   # Works around warnings libraries linked against that don't
   # have absolute paths (e.g. -lpthreads)
   cmake_policy(SET CMP0003 NEW)

   # Works around warnings about escaped quotes in ADD_DEFINITIONS
   # statements.
   cmake_policy(SET CMP0005 NEW)

   # cmake-2.6.1 introduces policy cmp0008 decide how to treat full path 
libraries that do not appear to be valid library file names
   # quote from cvslog Such libraries worked by accident in the VS IDE and Xcode 
generators in CMake 2.4 and below.
   if(POLICY CMP0008)
   cmake_policy(SET CMP0008 OLD)
   endif(POLICY CMP0008)
endif(COMMAND cmake_policy)

PROJECT(OpenSceneGraph)

SET(OPENSCENEGRAPH_MAJOR_VERSION 2)
SET(OPENSCENEGRAPH_MINOR_VERSION 7)
SET(OPENSCENEGRAPH_PATCH_VERSION 6)
SET(OPENSCENEGRAPH_SOVERSION 50)

# set to 0 when not a release candidate, non zero means that any generated 
# svn tags will be treated as release candidates of given number

SET(OPENSCENEGRAPH_RELEASE_CANDIDATE 0)

SET(OPENSCENEGRAPH_VERSION 
${OPENSCENEGRAPH_MAJOR_VERSION}.${OPENSCENEGRAPH_MINOR_VERSION}.${OPENSCENEGRAPH_PATCH_VERSION})

SET(OSG_PLUGINS osgPlugins-${OPENSCENEGRAPH_VERSION})

SET(OSG_PLUGIN_PREFIX )

IF (CYGWIN)
   SET(OSG_PLUGIN_PREFIX cygwin_)
ENDIF(CYGWIN)

IF(MINGW)
   SET(OSG_PLUGIN_PREFIX mingw_)
ENDIF(MINGW)


# We want to build SONAMES shared librariess
SET(OPENSCENEGRAPH_SONAMES TRUE)
SET(OPENTHREADS_SONAMES TRUE)

SET(OpenThreads_SOURCE_DIR ${OpenSceneGraph_SOURCE_DIR})

# We have some custom .cmake scripts not in the official distribution.
# Maybe this can be used override existing behavior if needed?
SET(CMAKE_MODULE_PATH 
${OpenSceneGraph_SOURCE_DIR}/CMakeModules;${CMAKE_MODULE_PATH})

# Mainly for Windows as a convenience. This will find a directory in parallel 
with the
# OSG source that contains 3rd party headers and libraries.
# Use of relative paths in CMake is ill-advised, but don't know of any 
alternatives in this case
#SET(CMAKE_INCLUDE_PATH 
${OpenSceneGraph_SOURCE_DIR}/../3rdParty/include;${CMAKE_INCLUDE_PATH})
#SET(CMAKE_LIBRARY_PATH 
${OpenSceneGraph_SOURCE_DIR}/../3rdParty/lib;${CMAKE_LIBRARY_PATH})
IF(USING_OSG_OP_OT_TRIPLE_SET)
   SET(CMAKE_INCLUDE_PATH 
${OpenSceneGraph_SOURCE_DIR}/../../3rdParty/include;${CMAKE_INCLUDE_PATH})
   SET(CMAKE_LIBRARY_PATH 
${OpenSceneGraph_SOURCE_DIR}/../../3rdParty/lib;${CMAKE_LIBRARY_PATH})
ENDIF(USING_OSG_OP_OT_TRIPLE_SET)


# Okay, here's the problem: On some platforms, linking against OpenThreads
# is not enough and explicit linking to the underlying thread library
# is also required (e.g. FreeBSD). But OpenThreads may be built with different
# backends (Pthreads, Sproc, Windows) so we don't know what the underlying
# thread library is because some platforms support multiple backends (e.g.
# IRIX 

[osg-users] Request for testing Collada/dae plugin changes

[Smeenk, R.J.M. (Roland)]

Hello osg-users,
 
Robert just merged my changes for the Collada/dae plugin as posted on
osg-submission:
http://lists.openscenegraph.org/pipermail/osg-submissions-openscenegraph
.org/2008-November/002883.html
 
You are kindly invited to test the improved plugin.
 
--
Roland
This e-mail and its contents are subject to the DISCLAIMER at 
http://www.tno.nl/disclaimer/email.html
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DataVariance

[paul1492]

Using CullDrawThreadPerContext and it works.. 

If the problem is with stateset and Drawable not being set to DYNAMIC, why 
wouldn't my SetDataVariance NodeVisitor (see below) convert everything to 
DYNAMIC. I call this during my initialization of the scene graph.

Paul P.


- Original Message 
From: Robert Osfield [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Monday, November 24, 2008 8:45:47 AM
Subject: Re: [osg-users] DataVariance

Hi Paul,

Could you try the CullDrawThreadPerContext thread model to see if that
works safely.  If it does then the issue is almost certainly down to
some StateSet or Drawable in your scene graph that you are modifying
the contents that don't have the DataVariance set to DYNAMIC.

Robert.

On Mon, Nov 24, 2008 at 1:41 PM,  [EMAIL PROTECTED] wrote:
 I attempted to set all my nodes and state sets to DYNAMIC data variance by 
 doing the following and it still is locking up on me (i.e. with the same call 
 stack as below):

    SetDataVariance dataVariance;
    root-accept(dataVariance);

 Where:

 class SetDataVariance : public osg::NodeVisitor
 {
 public:
    SetDataVariance():  
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
  {};
    virtual void apply(osg::Node node);
    virtual void apply(osg::Geode node);
 };
 void SetDataVariance::apply(osg::Node node)
 {
    node.getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
    traverse(node);
 }
 void SetDataVariance::apply(osg::Geode geode)
 {
    geode.getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
    geode.setDataVariance(osg::Object::DYNAMIC);
    for(unsigned int i=0;igeode.getNumDrawables();++i)
    {
        osg::Drawable* drawable = geode.getDrawable(i);
        if (drawable)
        {
            
drawable-getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
            drawable-setDataVariance(osg::Object::DYNAMIC);
        }
    }
 }

 Removing a portion of my scene graph and the problem goes away (or is 
 hidden)..  In particular, if I remove the node-addDrawable(geometry), the 
 problem goes away. The problem exists even if node-addDrawable( new 
 osg::Geometry).  In addition, turning off optimization doesn't seem to help. 
 As I said before, using single threaded viewer and it works fine.

 Any idea what is going on?

 Paul P.

 - Original Message 
 From: Robert Osfield [EMAIL PROTECTED]
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Sent: Friday, November 21, 2008 4:10:20 AM
 Subject: Re: [osg-users] DataVariance

 Hi Paul P.

 You will have to debug this on your own I'm afraid, this type of issue
 is not something one can resolve without seeing it first hand.

 The best I can do is recommend that look into the using DataVariance
 set to DYNAMIC on all StateSet and Drawable that you have in your
 scene.  This is the most likely cause of problems like this, but we've
 already recommended this and you've made no comment whether you've
 tried this.  There have been lots written on this topic on osg-users
 so please don't overlook the archives.

 Robert.

 On Thu, Nov 20, 2008 at 7:32 PM,  [EMAIL PROTECTED] wrote:
 When I change to SingleThreaded, I do not see the problem. The standard OSG 
 examples work fine. Other cases of my problem also work fine.

 Clearly, it's something in this app that is causing problems.  In the 
 problem case, I'm rendering to two different image buffers and then reading 
 the images out on the CPU. My scene is a normal scene except I have two 
 cameras with each rendering to these different textures (i.e. a top and 
 bottom view of the scene). I also have another camera rendering an 
 orthogonal projection on top of the scene.

 Paul P.


 - Original Message 
 From: Robert Osfield [EMAIL PROTECTED]
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Sent: Wednesday, September 17, 2008 11:03:33 AM
 Subject: Re: [osg-users] DataVariance

 Hi Paul,

 I can't say why your app might be hanging.  Do the standard OSG
 example hang on your machine?

 Try running the view single threaded as something that might at least
 flesh out whether threading is an issue at all.

 Robert.

 On Wed, Sep 17, 2008 at 3:52 PM,  [EMAIL PROTECTED] wrote:
 Thanks for the quick response...

 Then, any idea why my application is hanging when I attempt to render my 
 first frame?? Below is the call stack of the two OSG threads.

 The problem seems to exist when I include two different parts of my scene 
 graph.  My scene graph consists of two Camera's at the root. Each renders 
 to a different image array (using camera-attach(..., image);).

 Each camera then has shared subgraphs attached which also contain a Camera 
 node (for Ortho view for part of the scene) but with no attachments.

 The osgViewer's camera is unchanged (and I really don't need to render 
 anything).

 Am I doing something wrong with these camera's?

 While I'm at it, one more questions:
 Is there  a way to turn on the 

Re: [osg-users] DataVariance

[Robert Osfield]

Hi Paul,

On Mon, Nov 24, 2008 at 3:57 PM,  [EMAIL PROTECTED] wrote:
 Using CullDrawThreadPerContext and it works..

 If the problem is with stateset and Drawable not being set to DYNAMIC, why 
 wouldn't my SetDataVariance NodeVisitor (see below) convert everything to 
 DYNAMIC. I call this during my initialization of the scene graph.

Your visitor shouldn't use getOrCreateStateSet as this will be
creating a StateSet on all nodes and drawables.  Use getStateSet and
an if statement to protect.

As to why it doesn't seem to fix the threading problem you have.
We'll I can't help you here.  You have to debug your app, as I don't
have it in front of me, and I have plenty of work to do myself.

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

Re: [osg-users] osgswig confusion

[R Fritz]

Gerwin, thanks for answering.

OSG 2.6.1, locally compiled (of course), but otherwise unmodified.

Randolph

On Nov 24, 2008, at 5:45 AM, Gerwin de Haan wrote:


Hi Randolph,
which osg version are you using?
Gerwin


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

[osg-users] bump mapping using GLSL shaders

[Morné Pistorius]

Hi all,
I added bump mapping to a model using osgFX::BumpMapping, but I need
something more flexible.  My model has two sided lighting and osgFX doesn't
support that.  Do we have GLSL shaders for bumpmapping in OSG?  I think that
would be easier to modify to suit my needs than the assembler coded shaders
used in osgFX.  If anyone has an example of applying normal mapping with
shaders in OSG, I would greatly appreciate it.

Thank you kindly,
Morne
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] bump mapping using GLSL shaders

[Alejandro Aguilar Sierra]

Hi,

I suggest you to see the osgshaders example (how osg deals with glsl)
and then consult chapter 11 of the orange book (OpenGL shading
language). You can find the shaders used in the book at
http://3dshaders.com/

Hope it helps.

-- A.

On Mon, Nov 24, 2008 at 10:39 AM, Morné Pistorius
[EMAIL PROTECTED] wrote:
 Hi all,
 I added bump mapping to a model using osgFX::BumpMapping, but I need
 something more flexible.  My model has two sided lighting and osgFX doesn't
 support that.  Do we have GLSL shaders for bumpmapping in OSG?  I think that
 would be easier to modify to suit my needs than the assembler coded shaders
 used in osgFX.  If anyone has an example of applying normal mapping with
 shaders in OSG, I would greatly appreciate it.
 Thank you kindly,
 Morne
 ___
 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] osgswig confusion

[Gerwin de Haan]

Hi Randolph,

The error message already seemed familiar, I see that it was in the
osgswig issue tracker already
(http://code.google.com/p/osgswig/issues/detail?id=15) . I think I
might have fixed :-) the problem in revision 177
(http://code.google.com/p/osgswig/source/detail?r=177). Could you
update and report your findings? BTW. I also added the osgidentify.py
file in the examples directory, which should give you a quick way of
reporting your versions in (future) bug reports.

regards,
Gerwin


On Mon, Nov 24, 2008 at 5:28 PM, R Fritz [EMAIL PROTECTED] wrote:
 Gerwin, thanks for answering.

 OSG 2.6.1, locally compiled (of course), but otherwise unmodified.

 Randolph

 On Nov 24, 2008, at 5:45 AM, Gerwin de Haan wrote:

 Hi Randolph,
 which osg version are you using?
 Gerwin

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

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

[osg-users] OSG_GECKO

[Adrian Egli OpenSceneGraph (3D)]

Hi Robert,

can you poste a screen shot of your CMake config : cmake -i .
i downloaded windows gecko sdk (xul-runner sdk) and also gecko, so i like to
get running the gecko plugin under windows, may i can work out what the
variables correspond to.

/adrian

-- 

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

Re: [osg-users] OSG_GECKO

[Robert Osfield]

Hi Adrian,

You'll need libxul 1.8.x, it's not compatible with 1.9.x

A copy and paste form ccmake .

XUL_DIR  /usr/lib/xulrunner
 XUL_INCLUDE_DIR  /usr/include/xulrunner
 XUL_LIBRARY  /usr/lib/libxul.so
 XUL_MOZJS_LIBRARY/usr/lib/libmozjs.so
 XUL_NSS_LIBRARY  /usr/lib/libnss3.so
 XUL_PLUGIN_LIBRARY   /usr/lib/libplds4.so
 XUL_XPCOM_LIBRARY/usr/lib/libxpcom.so

Robert.

On Mon, Nov 24, 2008 at 6:12 PM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] wrote:
 Hi Robert,

 can you poste a screen shot of your CMake config : cmake -i .
 i downloaded windows gecko sdk (xul-runner sdk) and also gecko, so i like to
 get running the gecko plugin under windows, may i can work out what the
 variables correspond to.

 /adrian

 --
 
 Adrian Egli

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


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

Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names?

[Paul Martz]

 Hi Guys,
 
 I flagged this thread up as one that might produce a fix to 
 the OSG's OpenFlight plugin.  Has anything been done in this 
 direction yet?  If so please don't forgot to post it to 
 osg-submissions.
 
 Cheers,
 Robert.

Hi Robert -- After reviewing this thread, it looks like the major issue has
a workaround. It might be helpful to add an export option to disable
interpretation of Polygon Offset as a request for subfacing. Or, better yet,
it might be worthwhile to dig into why subfacing was breaking the external
reference in the first place.

Bottom line is that the exporter was designed to export scene graphs that
are very similar to those created by the importer, and supporting a clean
export of an arbitrary scene graph is way outside the scope of the exporter
as it currently exists.

However, contributions are welcome. :-)
   -Paul

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

[osg-users] osgWidget Design Advice

[Jeremy Moles]

Hello all! Allow me to talk briefly about osgWidget's current design and
perhaps how I can change it for the better.

A number of people over the last few months have asked me why the
WindowManager object requires an osgViewer::View* to be created. This is
an interesting question, and it segues into something possibly more
complicated, and which potentially demonstrates my lack of understanding
of some things related to OSG. :)

To summarize, a WindowManager object in osgWidget is derived from
osg::Switch, and its purpose is to position and layer various Window
objects which are added to it. It does this in a kind of virtual
space--that is to say, it has no awareness of how it will be viewed,
and I leave that aspect up to the user. Windows in osgWidget are derived
from osg::MatrixTransform, so it is quite simple to position and size
these objects in a virtual space.

However, as I mentioned earlier, when created a WindowManager must have
access to an osgViewer::View* so that it can call the
computeInteresections() method on this pointer and perform proper
picking. This raises an interesting design question: what exactly is (or
should be) the relationship between a WindowManager and an osg::Camera?
There certainly is SOME relationship, but whether or not I am properly
utilizing it in osgWidget remains to be seen.

If any of you have used osgWidget you may be familiar with the following
convenience method:

osgWidget::WindowManager::createParentOrthoCamera()

What this member/method does is creates an orthographic 2D camera, adds
the this pointer as it's first child, and returns the newly created
Camera. This is a quick way to put the WindowManager object in a state
where it can be seen and behaves as expected, but I fear I may have this
all only accidentally working.

My question, then, is to the OSG Gurus: if you were designing osgWidget,
how would you model this relationship between the topmost osgWidget
manager object and the Camera to which it should be attached? Would
you use an osgViewer::View* like I do to perform picking, or would you
interface directly with the Camera and perform picking that way? If so,
the question of WindowManager-Camera relationship becomes even more
important. Furthermore, how would you handle 3D GUI objects, which can
certainly be added to a WindowManager's virtual space, but will appear
wildly differently depending on whether the object is viewed through an
orthographic or perspective camera?

(Please forgive me if I'm using some wrong terminology here, I hope I
get the idea across!)

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

Re: [osg-users] Effects of locale setting

[David Spilling]

Robert,

Only just caught this thread. I'm happy to update the OBJ plugin (reader
only, presumably) if you want to lose the sscanf, as it's only recently I
was looking at it anyway.

I assume that you want all sscanf(blah, %f, my_float); to be replaced by
sscanf(blah, %s, my_char); my_float=atof(my_char), more or less, or did
you want the whole thing done with std::string or something?

Was the original problem (top of the thread) a recent one, as I seem to have
missed it if it was...

And sorry to be dense, but is the issue also whether OBJ writers (modelling
programs) are locale specific, and how a user might choose the OSG .obj
plugin to respect locale or assume a default?

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

Re: [osg-users] pragma warnings disabled in headers

[Tomlinson, Gordon]

I thought a  push and pop pragma would work ( I use that in my code) ,
but that would be in the headers  which Robert wants to avoid


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

 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: Monday, November 24, 2008 4:38 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] pragma warnings disabled in headers

Hi all -- Sorry I'm coming into this a little late.

What I'd really like is a clean compile so that if I introduce some
suspicious code, I clearly see a new warning message displayed in the
output, so that I can investigate it. What I don't want is to have all
warnings disabled so that I never see a message about my bogus change.
If the warning is displayed, but I miss it because it's buried in
hundreds or thousands of other warnings unrelated to my code change,
then that's just as bad as having it disabled and not displayed at all.

 Perhaps the middle ground is to place the #pagma's in the CMake 
 generated include/osg/Config file?

This seems like the worst solution, because not only does it disable all
warnings in the OSG headers, it also disables it in my own application
code that directly or indirectly includes osg/Config. If I change code
and introduce a warning, I'll never see the warning message displayed
because osg/Config disabled it.

 The other approach is to do an explicit casts to avoid the warnings in

 the first place.  This is more wordy and while of dubious practical 
 value would at least fix the warnings.

Yes, this is probably the best solution, but is a prohibitive task to
bite off for a large existing code base.

A third solution, as Wojtek mentioned, is to wrap each OSG header file
with #pragma push/pop so that warnings can be disabled just in the
header, and not in user code that includes the header. This could be
done by changing all OSG headers to include CMake-generated prefix and
suffix files that contain the push/pops and disables. This is still an
undesirable solution because it turns all warnings off in OSG headers,
even for future code changes, but is no worse than what we had before
and is relatively easy to implement.
   -Paul

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

Re: [osg-users] pragma warnings disabled in headers

[Paul Martz]

 I thought a  push and pop pragma would work ( I use that in 
 my code) , but that would be in the headers  which Robert 
 wants to avoid

I'm usually opposed to push/pop too -- not because they're in the headers,
but because they disable displaying warnings for a block of code, and
therefore prevent a developer from being alerted when he changes the code
and introduces a legitimate issue that should be resolved.

However, I'd let push/pop slide in this case, as it restricts disabling the
warnings to the OSG headers themselves (as opposed to also disabling them
for application code that includes the headers). It's really the only
practical solution for large extant projects that display a great number of
probably harmless warnings.

Push/pop can be hidden with CMake-generated prefix and suffix files, just as
the current svn head hides them in osg/Config.
   -Paul

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

Re: [osg-users] osgswig confusion

[R Fritz]

Thanks for responding so quickly.  I saw you picked up my patches in  
issue 18--thanks.  But still no joy on 15.  I attached my latest  
results to the issue there, but the latest result is no result--I  
don't think anything changed.


On a different subject, I've made some small changes to FindOSG.cmake  
which make the osgswig build happier with linking to OSG library files  
in an Xcode build.  I'm not sure of the merits of these, so I'm  
putting them out here--what do people who know the Mac environment  
better than me think?


Randolph

Index: /Users/rfritz/Documents/osgswig/CMakeModules/FindOSG.cmake
===
--- /Users/rfritz/Documents/osgswig/CMakeModules/FindOSG.cmake	 
(revision 177)
+++ /Users/rfritz/Documents/osgswig/CMakeModules/FindOSG.cmake	 
(working copy)

@@ -39,11 +39,14 @@
 /usr/local/lib
 /usr/lib64
 /usr/lib
+$ENV{OSG_DIR}/lib/Release
 $ENV{OSG_DIR}/lib
 $ENV{OSG_DIR}/bin
 $ENV{OSG_DIR}
+$ENV{OSGDIR}/lib/Release
 $ENV{OSGDIR}/lib
 $ENV{OSGDIR}
+$ENV{OSG_ROOT}/lib/Release
 $ENV{OSG_ROOT}/lib
  /sw/lib
 /opt/local/lib
@@ -67,10 +70,13 @@
 /usr/local/lib
 /usr/lib64
 /usr/lib
+$ENV{OSG_DIR}/lib/Debug
 $ENV{OSG_DIR}/lib
 $ENV{OSG_DIR}
+$ENV{OSGDIR}/lib/Debug
 $ENV{OSGDIR}/lib
 $ENV{OSGDIR}
+$ENV{OSG_ROOT}/lib/Debug
 $ENV{OSG_ROOT}/lib
 /sw/lib
 /opt/local/lib


Randolph

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

Re: [osg-users] osgWidget Design Advice

[Stephan Huber]

Hi Jeremy,


Jeremy Moles schrieb:
 However, as I mentioned earlier, when created a WindowManager must have
 access to an osgViewer::View* so that it can call the
 computeInteresections() method on this pointer and perform proper
 picking. This raises an interesting design question: what exactly is (or
 should be) the relationship between a WindowManager and an osg::Camera?
 There certainly is SOME relationship, but whether or not I am properly
 utilizing it in osgWidget remains to be seen.

I add a custom Eventhandler to my views which does the picking and
handling vorrect MouseEnter/MouseLeave/etc on picked objects.

This EventHandler can call your WindowManager-routines handling the
results. You can even search your WindowManager-node in the first frame
via a nodevisitor

So to use your widget-code the user has to
1) create a WidgetManager and add it to the scene, whereever he wants to
2) create a WidgetEventHandler and add it to the view, which should
handle the event

The WidgetEventHandler searchs for a WidgetManager when ::handle is
called for the first time, and does the picking on every FRAME-event and
cache the result.

I don't know osgWidget for now, perhaps I am completly wrong with my
suggestions, but perhaps it helps you a little bit.


cheers,

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

Re: [osg-users] osgWidget Design Advice

[Sukender]

Hi Jeremy,

I'm no OSG guru, and I (still) didn't use osgWidget, but here is an idea:
Why does the WindowManager have to know anything about cameras? From my point 
of view, a WindowManager should only do what its name says: manage windows.
I think the picking ability shoud be separated into another class (say 
WindowPicker?). Maybe this WindowPicker have to know a camera and have to 
be passed to the WindowManager. I guess this is the user role to set a camera 
and then give it to the WindowPicker. Moreover, some users will certainly 
want to display windows (and other things) without needing the picking ability. 
And perhaps some would like to display windows/widgets in the 3D world (such as 
on a wall) using multiple cameras, but only one for picking (a camera that 
could change over time - I mean the user/player may switch between cameras).

The createParentOrthoCamera() would then be a free (convinience) function that 
have to know about a Camera and maybe a WindowManager to get bounds of the 
windows.

What do you think about it?

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


Le Mon, 24 Nov 2008 21:54:43 +0100, Jeremy Moles [EMAIL PROTECTED] a écrit:

 Hello all! Allow me to talk briefly about osgWidget's current design and
 perhaps how I can change it for the better.

 A number of people over the last few months have asked me why the
 WindowManager object requires an osgViewer::View* to be created. This is
 an interesting question, and it segues into something possibly more
 complicated, and which potentially demonstrates my lack of understanding
 of some things related to OSG. :)

 To summarize, a WindowManager object in osgWidget is derived from
 osg::Switch, and its purpose is to position and layer various Window
 objects which are added to it. It does this in a kind of virtual
 space--that is to say, it has no awareness of how it will be viewed,
 and I leave that aspect up to the user. Windows in osgWidget are derived
 from osg::MatrixTransform, so it is quite simple to position and size
 these objects in a virtual space.

 However, as I mentioned earlier, when created a WindowManager must have
 access to an osgViewer::View* so that it can call the
 computeInteresections() method on this pointer and perform proper
 picking. This raises an interesting design question: what exactly is (or
 should be) the relationship between a WindowManager and an osg::Camera?
 There certainly is SOME relationship, but whether or not I am properly
 utilizing it in osgWidget remains to be seen.

 If any of you have used osgWidget you may be familiar with the following
 convenience method:

   osgWidget::WindowManager::createParentOrthoCamera()

 What this member/method does is creates an orthographic 2D camera, adds
 the this pointer as it's first child, and returns the newly created
 Camera. This is a quick way to put the WindowManager object in a state
 where it can be seen and behaves as expected, but I fear I may have this
 all only accidentally working.

 My question, then, is to the OSG Gurus: if you were designing osgWidget,
 how would you model this relationship between the topmost osgWidget
 manager object and the Camera to which it should be attached? Would
 you use an osgViewer::View* like I do to perform picking, or would you
 interface directly with the Camera and perform picking that way? If so,
 the question of WindowManager-Camera relationship becomes even more
 important. Furthermore, how would you handle 3D GUI objects, which can
 certainly be added to a WindowManager's virtual space, but will appear
 wildly differently depending on whether the object is viewed through an
 orthographic or perspective camera?

 (Please forgive me if I'm using some wrong terminology here, I hope I
 get the idea across!)

 ___
 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] Recommendation for OpenGL debugger?

[Yefei He]

Hi, Folks,

Do you have any recommendation for a run-time OpenGL debugger, 
something like the GLIntercept (glintercept.nutty.org/index.html)?
GLIntercept appears out of date and does not work with multiple 
render contexts. 

I'm doing this because I'm having a problem with an OSG app 
that consistently crashes inside nvoglnt.dll, both on a Windows 
XP PC with two monitors, single NVidia GeForce 7900GS card and 
another one with two NVidia GeForce 8800 Ultra cards and four 
monitors, both with the latest NVidia driver applicable. Somehow 
the application runs fine when I load one set of terrain databases 
in ive format as the main scenegraph for rendering. But when I 
load another set of terrain databases in ive format as the 
alternative scenegraph rendering in an inset viewport, in addition
to the main scenegraph in the main viewing window, the application 
will crash consistently near several eyepoint locations. The 
alternative database set is identical to the main set in geometry, 
only difference being using texture made for an infrared shader 
applied on the alternative scene. I'm trying to figure out if 
there's something wrong with the databases, or perhaps the system 
runs out of resources, or something else. The shader is not the 
problem as it still crashes if I don't apply the shader to the 
alternative scene. And, if I simply make a copy of the main database
set and rename the copy as the infrared set for the alternative 
scene, it still crashes. But, all is well if I only load one 
database set. 

Thanks!

Yefei

  


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

Re: [osg-users] Recommendation for OpenGL debugger?

[Mike Weiblen]

Hi,

there gDEBugger from Graphics Remedy at http://www.gremedy.com/

Its a very comprehensive tool, and they offer a 30-day demo license.

cheers
-- mew




On Mon, Nov 24, 2008 at 5:41 PM, Yefei He [EMAIL PROTECTED] wrote:
 Hi, Folks,

Do you have any recommendation for a run-time OpenGL debugger,
 something like the GLIntercept (glintercept.nutty.org/index.html)?
 GLIntercept appears out of date and does not work with multiple
 render contexts.

I'm doing this because I'm having a problem with an OSG app
 that consistently crashes inside nvoglnt.dll, both on a Windows
 XP PC with two monitors, single NVidia GeForce 7900GS card and
 another one with two NVidia GeForce 8800 Ultra cards and four
 monitors, both with the latest NVidia driver applicable. Somehow
 the application runs fine when I load one set of terrain databases
 in ive format as the main scenegraph for rendering. But when I
 load another set of terrain databases in ive format as the
 alternative scenegraph rendering in an inset viewport, in addition
 to the main scenegraph in the main viewing window, the application
 will crash consistently near several eyepoint locations. The
 alternative database set is identical to the main set in geometry,
 only difference being using texture made for an infrared shader
 applied on the alternative scene. I'm trying to figure out if
 there's something wrong with the databases, or perhaps the system
 runs out of resources, or something else. The shader is not the
 problem as it still crashes if I don't apply the shader to the
 alternative scene. And, if I simply make a copy of the main database
 set and rename the copy as the infrared set for the alternative
 scene, it still crashes. But, all is well if I only load one
 database set.

Thanks!

Yefei




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




-- 
Mike Weiblen -- Boulder Colorado USA -- http://mew.cx/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Cullind Data

[oren david]

Hello,I need to know the vertex of all the polygon I'm about to draw on
screen (after the culling has choosen the right ones), what is the right
approach??
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgWidget Design Advice

[Jean-Sébastien Guay]

Hi Jeremy,


Why does the WindowManager have to know anything about cameras?


I have the same question, but with different results: unless I've missed 
something in your description, why does anyone need to know about the 
camera? If you get your click events (which you act upon to get 
intersections) through an event handler, then you can just get an 
osg::View* with aa.asView(), which then has a camera. No one really 
needs to hold on to a camera pointer.


I would definitely go with calculating intersections directly through 
osgUtil::IntersectionVisitor. You can use the constructor that takes one 
of the WINDOW, PROJECTION, VIEW and MODEL enum values to easily 
construct the right intersector. It should even work for 3D widgets in 
space... space ... space ... :-)


As for creating an ortho viewport, perhaps you can return an osg::Camera 
with the right setup, and the user can then assign that to their 
viewer/view/slave camera/scenegraph/whatever. It would be more general.


That way you can remove the dependency between osgWidget and osgViewer 
(not sure if that's the goal here, but if intersections was the only 
thing that forced that dependency, I'd definitely remove it).


Anyways, like the others who replied I don't really know the internals 
of osgWidget, so perhaps there's something I've overlooked, but that's 
how I see it at first glance.


Hope this helps,

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] osgswig: the bigobj problem rears its head again

[Randolph Fritz]

I'm writing this up so that people who aren't cmake experts have a  
note about this workaround.


For my next trick, I tried building this on Windows using Visual C++.  
After some blundering around, I found that adding /bigobj flag to  
CMAKE_CXX_FLAGS (edit the field in the cmake GUI--it is one of the  
advanced options) makes the build go, but only on Visual Studio 2005  
and later.


MS acknowledges the problem and recognizes that machine-generated code  
may trigger it in the page at http://msdn.microsoft.com/en-us/library/ms173499(VS.80).aspx 
.


Reported at http://code.google.com/p/osgswig/issues/detail?id=13.

Randolph Fritz
  design machine group
  architecture department
  university of washington
[EMAIL PROTECTED]

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

Re: [osg-users] osgWidget Design Advice

[Zahir Tezcan]

actually i should be considered as a newbie to osg, but as thinking of a
WindowManager class, i would appreciate if it is a non-group node which only
accepts WindowNodes as children. That would be very useful to have
independent window managed areas on the whole 3d space instead of one window
layer. This structure may look like geode/drawable fashion but it could be
more manageable with callback system, which has already parameters like
view/model/projection matrices...
--ZΛHIЯ


On Tue, Nov 25, 2008 at 6:22 AM, Jean-Sébastien Guay 
[EMAIL PROTECTED] wrote:

 Hi Jeremy,

  Why does the WindowManager have to know anything about cameras?


 I have the same question, but with different results: unless I've missed
 something in your description, why does anyone need to know about the
 camera? If you get your click events (which you act upon to get
 intersections) through an event handler, then you can just get an osg::View*
 with aa.asView(), which then has a camera. No one really needs to hold on to
 a camera pointer.

 I would definitely go with calculating intersections directly through
 osgUtil::IntersectionVisitor. You can use the constructor that takes one of
 the WINDOW, PROJECTION, VIEW and MODEL enum values to easily construct the
 right intersector. It should even work for 3D widgets in space... space ...
 space ... :-)

 As for creating an ortho viewport, perhaps you can return an osg::Camera
 with the right setup, and the user can then assign that to their
 viewer/view/slave camera/scenegraph/whatever. It would be more general.

 That way you can remove the dependency between osgWidget and osgViewer (not
 sure if that's the goal here, but if intersections was the only thing that
 forced that dependency, I'd definitely remove it).

 Anyways, like the others who replied I don't really know the internals of
 osgWidget, so perhaps there's something I've overlooked, but that's how I
 see it at first glance.

 Hope this helps,

 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Howto: compress an existing vpb database

[J.P. Delport]

Hi all,

last week I learned about the -O compressed IVE writer option.

I thought that maybe I can use osgconv to compress an existing vpb 
database. After some duelling with osgconv I got it to work and wrote 
down the procedure here:


http://www.openscenegraph.org/projects/VirtualPlanetBuilder/wiki/CompressExisting

Of course this is not needed if one just passes -O compressed to 
vpbmaster at the outset, but it might be useful for older or existing 
databases or just to test.


regards
jp

As a reference for more options that can be used in building, see these 
comments by Robert:



Another tool for compression is to switch off mipmapping
(--no-mip-mapping) and to tell the build that it can use non power of
two textures (--npot).


http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/35998



--
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] StateSetSwitchNode suggestion.

[Viggo Løvli]

Hi Robert,
 
 Thanks for the explanation. I don't think your needs are particular 
 different from most who are writing games/simulators with the OSG. While 
 large scenes LOD's is crucial, and for massive scenes Paging is also 
 crucial. The OSG supports both so should scale to larger scenes. 
Paging would require that all custom nodes we create is part of the IVE file 
format. Inserting the custom nodes that we need is done as a pre-processing 
step which result in an .ive file. Today we have to insert our custom nodes 
post load. It it therefore nice if we can extend the IVE format. You told me in 
an earlier mail that you are thinking about making the IVE format extendable. 
Doing that would be a great thing at least for us. It would make it much easier 
to implement and use custom nodes.
 
Is there currently (OSG 2.6) any way to extend the IVE format without doing the 
implementation directly in OSG? 
(We want to avoid that in order to make future OSG upgrades as easy to do as 
possible.)
 The other approach you could take is having custom nodes or drawables that 
 wrap up a the whole rendering of a class of object, or a how collection of 
 objects. The later is something would suit trees/forests. 
One of my future tasks is to combine large ammount of very simple trees into 
one drawable. Our tree rendering does not require alpha-blending and thus not 
depth sorting either, so we will most certainly gain a lot on both cull and 
draw by combining this kind of geometry.
 These approaches would all reduce the number of objects in your scene graph 
 in memory and in the view frustum on each frame and thereby cut the update, 
 cull and draw dispatch costs. If your switch node helps in keeping the 
 number of objects down then thumbs up for it. 
I chosed the StateSetSwitchNode approach and not the LayerNode approach because 
of the following reasons:
- It is much faster on initialization. (But, I am going to figure out why, and 
maybe then we wont need it after all.)
- It is robust against node-visitors that has too many node-mask-bits turned on.
- It is easier to work with.
 W.r.t init time, typically this is pretty low. Shaders can be expensive. 
 Texture objects and drawables aren't typically too expensive - the 
 osgmemorytest example illustrate this. 
My understanding on shaders is that they are compiled at the time they are 
needed to be used (runtime). If that is correct then I doubt that the shaders 
would take a lot of time during OSG's initialization process. I only see this 
initialization problem when working with the compositeViewer. Other viewers are 
fast on init.
 
Viggo
 
_
Få Windows Live Messenger på mobilen.
http://windowslivemobile.msn.com/Homepage.aspx?lang=nb-noocid=30032___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Effects of locale setting

[Sukender]

Hi Robert,

I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL 
pointer. Something you already encountered ( 
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html
 ). I can't answer your question then, sorry. (Or maybe you know how to avoid 
this NULL pointer?)

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

 [...]
 So... could users who's machine are set up for a locale that uses the
 command convention for decimal places please post what results they
 get for the OpenGL version string, and what the OSG parses this string
 to be (i.e. the result of osg::getGLVersionNumber()).

 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] Comments in osg files

[Stephane Lamoliatte]

Hello all,

I've just want to know if it is possible to add comments in osg files ?

Cheers,

--
Lamoliatte Stephane
RD Engineer

R.S.A. Cosmos
Z.I. de la Vaure - B.P.40
42290 Sorbiers, France
Tel : +33 (0)4 77 53 30 48
Fax : +33 (0)4 77 53 38 61

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

Re: [osg-users] Comments in osg files

[Paul Melis]

Stephane Lamoliatte wrote:

Hello all,

I've just want to know if it is possible to add comments in osg files ?

http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIinsertcommentsina.osgfileORhowdoIcommentoutablockwithina.osgfile

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

Re: [osg-users] Screen Space Ambient Occlusion

[Adrian Egli OpenSceneGraph (3D)]

osgPPU :: SSAO

the shader supports not my gpu :

NVidia quatro 570M , what kind of GLSL do you use

/adrian

2008/11/18 Art Tevs [EMAIL PROTECTED]

 Hi Adrian,

 implementing this effect as osg effect ala cartoon shader or so wouldn't be
 that easy. The problem is that it requires some offscreen rendering
 mechanism.

 I have already started to implemented this effect with osgPPU. It is a good
 base for implementig screen space based effects. Take a look into the svn
 version of osgPPU. You will find the example there, however it is currently
 disabled and doesn't included into the make file. Due to small amount of
 time, I wasn't able to complete the effect and wouldn't be able until
 december, I think. Hence you can use it as a starting point and write and
 example (or even a complete osgPPU:SSAOUnit :) which handles this effect.

 Just take a look,
 art

 P.S. Of course I can help you with the development of that effect, because
 it seems to be already almost complete :)


 --- Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] schrieb am Di,
 18.11.2008:

  Von: Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED]
  Betreff: [osg-users] Screen Space Ambient Occlusion
  An: OpenSceneGraph Users osg-users@lists.openscenegraph.org
  Datum: Dienstag, 18. November 2008, 17:36
  Hi all,
 
  I am testing a new effect. i would like to append to the
  osg effect, like
  cartoon shader, also a new one: SSAO.
 
  Se the attachements to understand what kind of inputs i
  used.
 
  what i have to do:
 
  by the way, i have set.
  set
  OSG_COMPUTE_NEAR_FAR_MODE=COMPUTE_NEAR_FAR_USING_PRIMITIVES
 
  algorithm:
  PASS 1
  (1) Render the scene
   (*) readback the z-buffer into a texture called Z
  (depth values are :
  nearest =0, farest=1)
   (*) smooth the texture Z - sZ : gauss(Z,16x16)
  - sZ
   (*) dZ = Z - sZ
   (*) scale dZ into the range of [0.00...0.5]
  scale(dZ,0.0,0.5) - sdZ
 
  PASS 2
  (*) F - sdZ - R : Final Image (may we have to transform
  sdZ with a sigmoid
  function : F -
  sigmoid(sdZ,alpha=0.01,beta=0.01,min=0,max=1) - R
  (2) Render final scene and remove the sdZ(x,y) from all
  Fragment.Color(x,y)
 
 
  have a look at may prototype implement in image filtering
  software (itk)
  SSA0_Sponza_test.jpg
 
 
  How should i implement this, is there a template i can add
  this new effect.
  ? someone like to help me in implmenting it?
 
  /regards adrian
 
 
 
 
 
  --
  
  Adrian Egli
  ___
  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




-- 

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

Re: [osg-users] StateSetSwitchNode suggestion.

[Robert Osfield]

Hi Viggo,

Unfortunately the .ive format just isn't extensible/nor forwards
compatible.  A new binary format replacement for it would take quite a
bit of work so isn't something that can be easily added.   Personally
I'd like to have a single scheme for both the ascii and binary forms
of serializing osg scene graphs.  The amount of work this will require
is not trivial so isn't something that can be addressed soon.

The .osg format is extensible so this is route right now for
extensible serialization of the scene grpah.

As for StateSetSwitchNode and Layer initialization costs, I would have
expected the same StateSet representation would cost the same to
initialize.  I don't know how you've implemented either at your end so
I just can't say why their may be differences.

W.r.t CompsiteViewer vs Viewer initialization - this should be the
same as its the same rendering and threading code under the hood, the
only real difference is the high level management of views/cameras, at
the low level is just the same osgViewer::Renderer and threading
models at play.   Again as I don't have your code in front of me to
test I really can't say too much.

Robert.



On Mon, Nov 24, 2008 at 8:08 AM, Viggo Løvli [EMAIL PROTECTED] wrote:
 Hi Robert,

 Thanks for the explanation. I don't think your needs are particular
 different from most who are writing games/simulators with the OSG.
 While large scenes LOD's is crucial, and for massive scenes Paging is
 also crucial. The OSG supports both so should scale to larger scenes.

 Paging would require that all custom nodes we create is part of the IVE file
 format. Inserting the custom nodes that we need is done as a pre-processing
 step which result in an .ive file. Today we have to insert our custom nodes
 post load. It it therefore nice if we can extend the IVE format. You told me
 in an earlier mail that you are thinking about making the IVE format
 extendable. Doing that would be a great thing at least for us. It would make
 it much easier to implement and use custom nodes.

 Is there currently (OSG 2.6) any way to extend the IVE format without doing
 the implementation directly in OSG?
 (We want to avoid that in order to make future OSG upgrades as easy to do as
 possible.)

 The other approach you could take is having custom nodes or drawables
 that wrap up a the whole rendering of a class of object, or a how
 collection of objects. The later is something would suit
 trees/forests.

 One of my future tasks is to combine large ammount of very simple trees into
 one drawable. Our tree rendering does not require alpha-blending and thus
 not depth sorting either, so we will most certainly gain a lot on both cull
 and draw by combining this kind of geometry.

 These approaches would all reduce the number of objects in your scene
 graph in memory and in the view frustum on each frame and thereby cut
 the update, cull and draw dispatch costs. If your switch node helps
 in keeping the number of objects down then thumbs up for it.

 I chosed the StateSetSwitchNode approach and not the LayerNode approach
 because of the following reasons:
 - It is much faster on initialization. (But, I am going to figure out why,
 and maybe then we wont need it after all.)
 - It is robust against node-visitors that has too many node-mask-bits turned
 on.
 - It is easier to work with.

 W.r.t init time, typically this is pretty low. Shaders can be
 expensive. Texture objects and drawables aren't typically too
 expensive - the osgmemorytest example illustrate this.

 My understanding on shaders is that they are compiled at the time they are
 needed to be used (runtime). If that is correct then I doubt that the
 shaders would take a lot of time during OSG's initialization process. I only
 see this initialization problem when working with the compositeViewer. Other
 viewers are fast on init.

 Viggo


 
 Windows Live SkyDrive. På tide å glemme minnepinnen.
 ___
 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] Effects of locale setting

[Ümit Uzun]

Hi Robert;

I have same problem as Sukender and set OSG_NOTIFY_LEVEL = DEBUG and result
is as follows;

glVersion=2, isGlslSupported=YES, glslLanguageVersion=1.1

Regards.

2008/11/24 Robert Osfield [EMAIL PROTECTED]

 Hi Sukender,

 You can only call getGLVersionNumber() or any releated OpenGL from a
 thread with a valid graphics context - there is nothing the OSG can do
 about this - it's a characteristic of OpenGL.   The locale issue does
 change this.

 Running osgviewer will call getGLVersionNumber() when it runs, so
 running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the
 results of all the extension checks, I'm not sure in the OpenGL
 version number is amongst these.  osgviewer doesn't set the locale
 though So perhaps osgviewerWX would be a better base.

 Robert.

 On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote:
  Hi Robert,
 
  I get a crash in osg::getGLVersionNumber()... glGetString() returns a
 NULL pointer. Something you already encountered (
 http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html).
  I can't answer your question then, sorry. (Or maybe you know how to avoid
 this NULL pointer?)
 
  Sukender
  PVLE - Lightweight cross-platform game engine -
 http://pvle.sourceforge.net/
 
  [...]
  So... could users who's machine are set up for a locale that uses the
  command convention for decimal places please post what results they
  get for the OpenGL version string, and what the OSG parses this string
  to be (i.e. the result of osg::getGLVersionNumber()).
 
  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




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

Re: [osg-users] Effects of locale setting

[Robert Osfield]

Hi Umit,

Which is the OpenGL version string you have on your machine?

Robert.

On Mon, Nov 24, 2008 at 9:57 AM, Ümit Uzun [EMAIL PROTECTED] wrote:
 Hi Robert;

 I have same problem as Sukender and set OSG_NOTIFY_LEVEL = DEBUG and result
 is as follows;

 glVersion=2, isGlslSupported=YES, glslLanguageVersion=1.1

 Regards.

 2008/11/24 Robert Osfield [EMAIL PROTECTED]

 Hi Sukender,

 You can only call getGLVersionNumber() or any releated OpenGL from a
 thread with a valid graphics context - there is nothing the OSG can do
 about this - it's a characteristic of OpenGL.   The locale issue does
 change this.

 Running osgviewer will call getGLVersionNumber() when it runs, so
 running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the
 results of all the extension checks, I'm not sure in the OpenGL
 version number is amongst these.  osgviewer doesn't set the locale
 though So perhaps osgviewerWX would be a better base.

 Robert.

 On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote:
  Hi Robert,
 
  I get a crash in osg::getGLVersionNumber()... glGetString() returns a
  NULL pointer. Something you already encountered (
  http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html
  ). I can't answer your question then, sorry. (Or maybe you know how to 
  avoid
  this NULL pointer?)
 
  Sukender
  PVLE - Lightweight cross-platform game engine -
  http://pvle.sourceforge.net/
 
  [...]
  So... could users who's machine are set up for a locale that uses the
  command convention for decimal places please post what results they
  get for the OpenGL version string, and what the OSG parses this string
  to be (i.e. the result of osg::getGLVersionNumber()).
 
  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



 --
 Ümit Uzun

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


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

Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names?

[Robert Osfield]

Hi Guys,

I flagged this thread up as one that might produce a fix to the OSG's
OpenFlight plugin.  Has anything been done in this direction yet?  If
so please don't forgot to post it to osg-submissions.

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

Re: [osg-users] Effects of locale setting

[Sukender]

Hi Robert,

I don't know if I did what you expected, but my GL string is always
1.4.0 - Build 7.14.10.4926
and OSG always reports
glVersion=1.4, isGlslSupported=NO, glslLanguageVersion=0
on the console even if I call setlocale(LC_ALL, FR_fr); or EN or C at 
the begining of main().
Please not that I my LANG env variable is set to FR and that French decimals 
should be separated with ','.
Is that enough info for you? Or should I run another test?
Hope it helps.

However, the strange thing is that I can't run GLSL in OSG, but the Spring 
(XTA) game has shaders that run on my machine and, well I'm not THAT sure, but 
I think it also uses GLSL since the reflective water shaders are .glsl 
files and that I can see the effects in the game. Anyone knows more about 
Spring and GLSL?

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


Le Mon, 24 Nov 2008 10:19:39 +0100, Robert Osfield [EMAIL PROTECTED] a écrit:

 Hi Sukender,

 You can only call getGLVersionNumber() or any releated OpenGL from a
 thread with a valid graphics context - there is nothing the OSG can do
 about this - it's a characteristic of OpenGL.   The locale issue does
 change this.

 Running osgviewer will call getGLVersionNumber() when it runs, so
 running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the
 results of all the extension checks, I'm not sure in the OpenGL
 version number is amongst these.  osgviewer doesn't set the locale
 though So perhaps osgviewerWX would be a better base.

 Robert.

 On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert,

 I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL 
 pointer. Something you already encountered ( 
 http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html
  ). I can't answer your question then, sorry. (Or maybe you know how to 
 avoid this NULL pointer?)

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

 [...]
 So... could users who's machine are set up for a locale that uses the
 command convention for decimal places please post what results they
 get for the OpenGL version string, and what the OSG parses this string
 to be (i.e. the result of osg::getGLVersionNumber()).

 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] Screen Space Ambient Occlusion

[Art Tevs]

Hi Adrian,

osgPPU::SSAO is not complete. I have just started to implement this, it need to 
be changed. You can use it as a starting point or wait until I get enough time 
to finish it. As to the GLSL version, the current code is Cg and I was 
currently converting it to GLSL, hence the shader isn't runnable or compilable 
yet ;(

Cheers,
art



--- Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] schrieb am Mo, 
24.11.2008:

 Von: Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED]
 Betreff: Re: [osg-users] Screen Space Ambient Occlusion
 An: [EMAIL PROTECTED], OpenSceneGraph Users 
 osg-users@lists.openscenegraph.org
 Datum: Montag, 24. November 2008, 10:37
 osgPPU :: SSAO
 
 the shader supports not my gpu :
 
 NVidia quatro 570M , what kind of GLSL do you use
 
 /adrian
 
 2008/11/18 Art Tevs [EMAIL PROTECTED]
 
  Hi Adrian,
 
  implementing this effect as osg effect ala cartoon
 shader or so wouldn't be
  that easy. The problem is that it requires some
 offscreen rendering
  mechanism.
 
  I have already started to implemented this effect with
 osgPPU. It is a good
  base for implementig screen space based effects. Take
 a look into the svn
  version of osgPPU. You will find the example there,
 however it is currently
  disabled and doesn't included into the make file.
 Due to small amount of
  time, I wasn't able to complete the effect and
 wouldn't be able until
  december, I think. Hence you can use it as a starting
 point and write and
  example (or even a complete osgPPU:SSAOUnit :) which
 handles this effect.
 
  Just take a look,
  art
 
  P.S. Of course I can help you with the development of
 that effect, because
  it seems to be already almost complete :)
 
 
  --- Adrian Egli OpenSceneGraph (3D)
 [EMAIL PROTECTED] schrieb am Di,
  18.11.2008:
 
   Von: Adrian Egli OpenSceneGraph (3D)
 [EMAIL PROTECTED]
   Betreff: [osg-users] Screen Space Ambient
 Occlusion
   An: OpenSceneGraph Users
 osg-users@lists.openscenegraph.org
   Datum: Dienstag, 18. November 2008, 17:36
   Hi all,
  
   I am testing a new effect. i would like to append
 to the
   osg effect, like
   cartoon shader, also a new one: SSAO.
  
   Se the attachements to understand what kind of
 inputs i
   used.
  
   what i have to do:
  
   by the way, i have set.
   set
  
 OSG_COMPUTE_NEAR_FAR_MODE=COMPUTE_NEAR_FAR_USING_PRIMITIVES
  
   algorithm:
   PASS 1
   (1) Render the scene
(*) readback the z-buffer into a texture
 called Z
   (depth values are :
   nearest =0, farest=1)
(*) smooth the texture Z - sZ :
 gauss(Z,16x16)
   - sZ
(*) dZ = Z - sZ
(*) scale dZ into the range of [0.00...0.5]
   scale(dZ,0.0,0.5) - sdZ
  
   PASS 2
   (*) F - sdZ - R : Final Image (may we have to
 transform
   sdZ with a sigmoid
   function : F -
   sigmoid(sdZ,alpha=0.01,beta=0.01,min=0,max=1)
 - R
   (2) Render final scene and remove the sdZ(x,y)
 from all
   Fragment.Color(x,y)
  
  
   have a look at may prototype implement in image
 filtering
   software (itk)
   SSA0_Sponza_test.jpg
  
  
   How should i implement this, is there a template
 i can add
   this new effect.
   ? someone like to help me in implmenting it?
  
   /regards adrian
  
  
  
  
  
   --
   
   Adrian Egli
   ___
   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
 
 
 
 
 -- 
 
 Adrian Egli


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

Re: [osg-users] Effects of locale setting

[Sukender]

Hum... forget about the Spring shaders, I found some .fp files (ARB fp ???) 
that describe water effects.

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


Le Mon, 24 Nov 2008 11:42:13 +0100, Sukender [EMAIL PROTECTED] a écrit:

 Hi Robert,

 I don't know if I did what you expected, but my GL string is always
 1.4.0 - Build 7.14.10.4926
 and OSG always reports
 glVersion=1.4, isGlslSupported=NO, glslLanguageVersion=0
 on the console even if I call setlocale(LC_ALL, FR_fr); or EN or C at 
 the begining of main().
 Please not that I my LANG env variable is set to FR and that French 
 decimals should be separated with ','.
 Is that enough info for you? Or should I run another test?
 Hope it helps.

 However, the strange thing is that I can't run GLSL in OSG, but the Spring 
 (XTA) game has shaders that run on my machine and, well I'm not THAT sure, 
 but I think it also uses GLSL since the reflective water shaders are 
 .glsl files and that I can see the effects in the game. Anyone knows more 
 about Spring and GLSL?

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


 Le Mon, 24 Nov 2008 10:19:39 +0100, Robert Osfield [EMAIL PROTECTED] a 
 écrit:

 Hi Sukender,

 You can only call getGLVersionNumber() or any releated OpenGL from a
 thread with a valid graphics context - there is nothing the OSG can do
 about this - it's a characteristic of OpenGL.   The locale issue does
 change this.

 Running osgviewer will call getGLVersionNumber() when it runs, so
 running it with the env var OSG_NOTIFY_LEVEL to DEBUG will output the
 results of all the extension checks, I'm not sure in the OpenGL
 version number is amongst these.  osgviewer doesn't set the locale
 though So perhaps osgviewerWX would be a better base.

 Robert.

 On Mon, Nov 24, 2008 at 9:06 AM, Sukender [EMAIL PROTECTED] wrote:
 Hi Robert,

 I get a crash in osg::getGLVersionNumber()... glGetString() returns a NULL 
 pointer. Something you already encountered ( 
 http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-July/014034.html
  ). I can't answer your question then, sorry. (Or maybe you know how to 
 avoid this NULL pointer?)

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

 [...]
 So... could users who's machine are set up for a locale that uses the
 command convention for decimal places please post what results they
 get for the OpenGL version string, and what the OSG parses this string
 to be (i.e. the result of osg::getGLVersionNumber()).

 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

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

Re: [osg-users] Effects of locale setting

[Paul Melis]

Robert Osfield wrote:

Hi All,

In response to problems with the obj loader when the c local is set to
one that use comma for the decimal place (same problem previously
affected the .osg) I have begun make the custom atof function I wrote
for the .osg plugin as public function of osgDB so it could be used
else where.   This then brought me to ask the question how widely
should I roll out this new osgDB::asciiToDouble/asciiToFloat(..)
function.

The key question is how widely the data formats that users will be
reading, .osg, .obj are starters as this as ascii formats.  What about
others like COLLADA files, or even version strings and env vars that
users set themselves.  If you know what local the data you are reading
is in then you can use what is appropriate, but this could change for
machine to machine, user to user.

There are some constraints for certain formats - like .osg does write
out only in the standard locale format, so we know always to read it
with the same locale.  Is .obj always going to be the same?  What
about OpenGL version strings?

The OpenGL version string is an interesting one, because I suspect
it'll always be reported in the standard local i.e the OSG version
number being 2.1 rather than 2,1.  The could be an issue if the locale
is set so that atof only looks for 2,1 but then reads 21... or would
that be 2.  Which ever way it'd be wrong and we could be getting wrong
behaviour.

So... could users who's machine are set up for a locale that uses the
command convention for decimal places please post what results they
get for the OpenGL version string, and what the OSG parses this string
to be (i.e. the result of osg::getGLVersionNumber()).
  
The OpenGL spec specifies that the return value of 
glGetString(GL_VERSION) should begin with 
major_number.minor_number[.release_number], so if the results are 
locale-dependent and suddenly use a comma instead of a period that's 
clearly a bug in the drivers. Or am I misunderstanding your question 
about the returned OpenGL version string?


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

[osg-users] camera settings frustum

[Martin Großer]

Hello,

I'm a little bit confused about the frustum of the camera node. I set the
position of the camera with the viewmatrix:

osg::MatrixTransform* mt = new MatrixTransform;
mt-setMatrix(::osg::Matrix::translate(0, 0, 25));
((::osg::Camera*)_root.get())-setViewMatrix(mt-getInverseMatrix());

After this, I create a projectionmatrix with the static function frustum
from the class osg::Matrix:

projectionMatrix = ::osg::Matrix::frustum(-2.0,2.0,-1.5,1.5,0.01,4.0);

But I don't see anything. When I swap the values of zNear and zFar, I can
see my scene. I don't know why? I think it is illogical that the distance of
the near plane is bigger as the distance of the far plane?!
What is my mistake?

Cheers,

Martin

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

Re: [osg-users] Effects of locale setting

[Ümit Uzun]

Hi Robert,

My OpenGL version string only 2. I can only see the major version number.
I have OSG-2.6.1 on XP SP2.

HTH.Regards.


2008/11/24 Paul Melis [EMAIL PROTECTED]

 Robert Osfield wrote:

 Hi All,

 In response to problems with the obj loader when the c local is set to
 one that use comma for the decimal place (same problem previously
 affected the .osg) I have begun make the custom atof function I wrote
 for the .osg plugin as public function of osgDB so it could be used
 else where.   This then brought me to ask the question how widely
 should I roll out this new osgDB::asciiToDouble/asciiToFloat(..)
 function.

 The key question is how widely the data formats that users will be
 reading, .osg, .obj are starters as this as ascii formats.  What about
 others like COLLADA files, or even version strings and env vars that
 users set themselves.  If you know what local the data you are reading
 is in then you can use what is appropriate, but this could change for
 machine to machine, user to user.

 There are some constraints for certain formats - like .osg does write
 out only in the standard locale format, so we know always to read it
 with the same locale.  Is .obj always going to be the same?  What
 about OpenGL version strings?

 The OpenGL version string is an interesting one, because I suspect
 it'll always be reported in the standard local i.e the OSG version
 number being 2.1 rather than 2,1.  The could be an issue if the locale
 is set so that atof only looks for 2,1 but then reads 21... or would
 that be 2.  Which ever way it'd be wrong and we could be getting wrong
 behaviour.

 So... could users who's machine are set up for a locale that uses the
 command convention for decimal places please post what results they
 get for the OpenGL version string, and what the OSG parses this string
 to be (i.e. the result of osg::getGLVersionNumber()).


 The OpenGL spec specifies that the return value of glGetString(GL_VERSION)
 should begin with major_number.minor_number[.release_number], so if the
 results are locale-dependent and suddenly use a comma instead of a period
 that's clearly a bug in the drivers. Or am I misunderstanding your question
 about the returned OpenGL version string?

 Paul

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




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

Re: [osg-users] camera settings frustum

[Alberto Luaces]

Hi Martin,

El Lunes 24 Noviembre 2008ES 11:52:01 Martin Großer escribió:
 mt-setMatrix(::osg::Matrix::translate(0, 0, 25));

I think you have placed the scene behind the camera. Try (0, 0, -25) instead.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Question about views, contexts and threading

[Ferdi Smit]

Robert,

I tried your suggestion, but it didn't have any effect. It's probably a 
driver issue then (nvidia 180.06 beta). I should receive a dual GTX260 
system any day now; I'll try and see if that works better.


Robert Osfield wrote:

HI Ferdi,

Could try the same tests but with the following env var  set:

  set OSG_SERIALIZE_DRAW_DISPATCH=OFF

This will disable the mutex that serializes the draw dispatch.  Have a
search through the archives on this topic as I've written lots about
this topic and the fact serialize draw curious improves performance on
systems that I've tested on.  I still haven't had feedback from the
community on this topic as it's likely to be something effected by
hardware/drivers and OS.

Robert.

On Thu, Nov 20, 2008 at 4:05 PM, Ferdi Smit [EMAIL PROTECTED] wrote:
  

Thank you, that at least explains some of the drawing times I've been
seeing.

I ran more tests on our dual-gpu system, summarized below. Not striclty OSG
related, but they may be interesting nonetheless...

- Scene of 25x 1 million polygon model, all visible. Culling etc neglibile.
- Stand-alone refers to one rendering context only; normal, non-parallel
rendering
- frame rates in FPS

CPU Affinity on different cores
OSG_THREADING=SingleThreaded
(1 core shows heavy use, 2nd core show moderate use, 2 cores idle)

  Quadro 56008800GTX
Single-GPU / Stand-alone1615

Single-GPU / Multi-Threaded7.57.5
Single-GPU / Multi-Processing7.57.5

Multi-GPU / Multi-Threaded6.56.5
Multi-GPU / Multi-Processing1615

  Quadro 56008800GTX

OSG_THREADING=ThreadPerContext
(CPU Affinity is set but appears to be ignored: 1 core shows heavy use,
others idle)

Single-GPU / Stand-alone1615

Single-GPU / Multi-Threaded7.57.5
Single-GPU / Multi-Processing7.57.5

Multi-GPU / Multi-Threaded3.511
Multi-GPU / Multi-Processing1114


  Quadro 56008800GTX
Baseline:
Multi-GPU / Multi-Threaded6.56.5

Speeding up one card by rendering empty scene*, effect on other card:
Multi-GPU / Multi-Threaded6000*15
Multi-GPU / Multi-Threaded714*


All results are reasonable, except:

Single-GPU / Multi-Processing7.57.5
Multi-GPU / Multi-Threaded6.56.5
Multi-GPU / Multi-Processing1615

Which is very strange; using two distinct GPUs simultaneously in a threaded
way in the same address space is slower than sharing a single GPU. I can
only conclude that OpenGL drivers can not handle multi-threading with
different contexts on different devices. It also seems that the Quadro is
the culprit, locking the driver or something. If you let the quadro render
fast, the 8800 also renders fast. However, if you allow the 8800 to render
fast, both will remain slow.




--
Regards,

Ferdi Smit
INS3 Visualization and 3D Interfaces
CWI Amsterdam, The Netherlands

___
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
  



--
Regards,

Ferdi Smit
INS3 Visualization and 3D Interfaces
CWI Amsterdam, The Netherlands

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

Re: [osg-users] Effects of locale setting

[Robert Osfield]

Hi Paul,

On Mon, Nov 24, 2008 at 10:51 AM, Paul Melis [EMAIL PROTECTED] wrote:
 The OpenGL spec specifies that the return value of glGetString(GL_VERSION)
 should begin with major_number.minor_number[.release_number], so if the
 results are locale-dependent and suddenly use a comma instead of a period
 that's clearly a bug in the drivers. Or am I misunderstanding your question
 about the returned OpenGL version string?

Thanks for the clarification.  This tells us that we should use my
asciiToDouble/Float functions in the OpenGL query code to avoid locale
issues with atof.

I will do a purge of the OpenGL related atof functions.  It'll be
interesting to see where problem points may have been, I'll ping this
thread once these changes are checked in.

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

Re: [osg-users] camera settings frustum

[Martin Großer]

Hi Alberto,

I don't think so. Because I create this simple example:

int main()
{
// scene
osg::ref_ptrosg::Camera root = new osg::Camera;

// frustum
  // root-setProjectionMatrixAsFrustum(-2,2,-1.5,1.5,0.01,4); // it
doesn't work
root-setProjectionMatrixAsFrustum(-2,2,-1.5,1.5,4,0.01); // it
works

// load object
Root-addChild(osgDB::readNodeFile(misc.osg));

// viewer
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
viewer-setSceneData(root.get());
viewer-realize();
viewer-run();

return (0);
}

Without the frustum definition, it works fine. With the definition, it works
only when the value of zNeargreater is than the value of zFar. Or is it
normal?

Cheers, Martin

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Im Auftrag von Alberto
Luaces
Gesendet: Montag, 24. November 2008 12:24
An: OpenSceneGraph Users
Betreff: Re: [osg-users] camera settings frustum

Hi Martin,

El Lunes 24 Noviembre 2008ES 11:52:01 Martin Großer escribió:
 mt-setMatrix(::osg::Matrix::translate(0, 0, 25));

I think you have placed the scene behind the camera. Try (0, 0, -25)
instead.
___
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] Screen Space Ambient Occlusion

[Adrian Egli OpenSceneGraph (3D)]

Ok, i understand.

2008/11/24 Art Tevs [EMAIL PROTECTED]

 Hi Adrian,

 osgPPU::SSAO is not complete. I have just started to implement this, it
 need to be changed. You can use it as a starting point or wait until I get
 enough time to finish it. As to the GLSL version, the current code is Cg and
 I was currently converting it to GLSL, hence the shader isn't runnable or
 compilable yet ;(

 Cheers,
 art



 --- Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] schrieb am Mo,
 24.11.2008:

  Von: Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED]
  Betreff: Re: [osg-users] Screen Space Ambient Occlusion
  An: [EMAIL PROTECTED], OpenSceneGraph Users 
 osg-users@lists.openscenegraph.org
  Datum: Montag, 24. November 2008, 10:37
  osgPPU :: SSAO
 
  the shader supports not my gpu :
 
  NVidia quatro 570M , what kind of GLSL do you use
 
  /adrian
 
  2008/11/18 Art Tevs [EMAIL PROTECTED]
 
   Hi Adrian,
  
   implementing this effect as osg effect ala cartoon
  shader or so wouldn't be
   that easy. The problem is that it requires some
  offscreen rendering
   mechanism.
  
   I have already started to implemented this effect with
  osgPPU. It is a good
   base for implementig screen space based effects. Take
  a look into the svn
   version of osgPPU. You will find the example there,
  however it is currently
   disabled and doesn't included into the make file.
  Due to small amount of
   time, I wasn't able to complete the effect and
  wouldn't be able until
   december, I think. Hence you can use it as a starting
  point and write and
   example (or even a complete osgPPU:SSAOUnit :) which
  handles this effect.
  
   Just take a look,
   art
  
   P.S. Of course I can help you with the development of
  that effect, because
   it seems to be already almost complete :)
  
  
   --- Adrian Egli OpenSceneGraph (3D)
  [EMAIL PROTECTED] schrieb am Di,
   18.11.2008:
  
Von: Adrian Egli OpenSceneGraph (3D)
  [EMAIL PROTECTED]
Betreff: [osg-users] Screen Space Ambient
  Occlusion
An: OpenSceneGraph Users
  osg-users@lists.openscenegraph.org
Datum: Dienstag, 18. November 2008, 17:36
Hi all,
   
I am testing a new effect. i would like to append
  to the
osg effect, like
cartoon shader, also a new one: SSAO.
   
Se the attachements to understand what kind of
  inputs i
used.
   
what i have to do:
   
by the way, i have set.
set
   
  OSG_COMPUTE_NEAR_FAR_MODE=COMPUTE_NEAR_FAR_USING_PRIMITIVES
   
algorithm:
PASS 1
(1) Render the scene
 (*) readback the z-buffer into a texture
  called Z
(depth values are :
nearest =0, farest=1)
 (*) smooth the texture Z - sZ :
  gauss(Z,16x16)
- sZ
 (*) dZ = Z - sZ
 (*) scale dZ into the range of [0.00...0.5]
scale(dZ,0.0,0.5) - sdZ
   
PASS 2
(*) F - sdZ - R : Final Image (may we have to
  transform
sdZ with a sigmoid
function : F -
sigmoid(sdZ,alpha=0.01,beta=0.01,min=0,max=1)
  - R
(2) Render final scene and remove the sdZ(x,y)
  from all
Fragment.Color(x,y)
   
   
have a look at may prototype implement in image
  filtering
software (itk)
SSA0_Sponza_test.jpg
   
   
How should i implement this, is there a template
  i can add
this new effect.
? someone like to help me in implmenting it?
   
/regards adrian
   
   
   
   
   
--

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



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




-- 

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

[osg-users] Basic question in get polygon data

[oren david]

Hello,
I need to know the distance of my camera to each polygon drawn on screen.
I thought the get for every frame all the polygon that will be drawn, but
how do I get such a pointer??
thank you
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] camera settings frustum

[Alberto Luaces]

Hi Martin,

El Lunes 24 Noviembre 2008ES 13:14:03 Martin Großer escribió:
 Without the frustum definition, it works fine. With the definition, it
 works only when the value of zNear    greater is than the value of zFar. Or
 is it normal?

Beware! There are some things to know:

- The value of near and far planes must be positive and obviously, zFar  
zNear.
- You were putting the object 25 units far away but your far plane cuts at 4 
units.
- By using viewer.run(), you are adding an extra default manipulator 
(TrackballManipulator) which moves the scene for you in order to be seen by 
the camera at initialization, so it will overwrite your scene placement.
- The viewer has its own camera, you haven't to insert a new one.

This code works for me, try it out:

#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osg/Timer
#include osg/Group
#include osg/ArgumentParser
#include osgDB/ReadFile
#include osg/MatrixTransform

int main()
{
  // scene
  osg::ref_ptrosg::Group root = new osg::Group;

  // load object
  osg::MatrixTransform* mt = new osg::MatrixTransform;
  mt-setMatrix(::osg::Matrix::translate(0, 0, -25));
  root-addChild(mt);
  mt-addChild(osgDB::readNodeFile(cabina.obj));
  // viewer
  osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer;
  viewer-setSceneData(root.get());
  viewer-getCamera()-setProjectionMatrixAsFrustum(-2,2,-1.5,1.5,1,40);
  viewer-realize();

  while(!viewer-done())
{
  viewer-frame();
}
  return (0);
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Effects of locale setting

[Robert Osfield]

Hi All,

On Mon, Nov 24, 2008 at 11:41 AM, Robert Osfield
[EMAIL PROTECTED] wrote:
 I will do a purge of the OpenGL related atof functions.  It'll be
 interesting to see where problem points may have been, I'll ping this
 thread once these changes are checked in.

I have now converted the OpenGL related atof usage across to using the
osg::asciiToFloat function instead, this is now checked into svn.

There are other places in the OSG that use atof, some main be
appropriate to leave as being locale sensitive, others I think it
would be best to convert to use osg::asciiToFloat/asciiToDouble.  The
big question which ones...

The files that still use atof are:

parsing env vars/ReaderWriter::Options:
--
./osg/DisplaySettings.cpp
./osg/CullSettings.cpp
./osgDB/DatabasePager.cpp
./osgGA/DriveManipulator.cpp
./osgViewer/ViewerEventHandlers.cpp
./osgPlugins/ive/DataOutputStream.cpp
./osgPlugins/txp/ReaderWriterTXP.cpp
./osgPlugins/txp/TXPParser.cpp
./osgPlugins/normals/ReaderWriterNormals.cpp

command line argument parsing:
--
./osg/ArgumentParser.cpp

file parsing:
--
./osgPlugins/x/types.cpp
./osgPlugins/dw/ReaderWriterDW.cpp
./osgPlugins/cfg/ConfigParser.cpp

--

All the file parsing code I think should be converted across to
asciiToFloat as these formats won't be explictly defining which
convention they use so one can't decide based on that particular file
- one has to assume a single interpretation on all files and the
standard '.' decimal place will the one used.

The env var/options and command line parsing are OSG specific, and
will be developer dependant, so if the user is consistent themselves
and set the locale to be consistent with this then they could probably
safely use either convention, however, there quite a bit of scope for
the locale to not be set at all times and on all platforms the same
(i.e. different end users will install on different platforms so
locale will vary), so my inclination is formal decide to use the '.'
decimal place convention for all OSG env vars/options and command line
parsing, and following on from this use osg::asciitToFloat for all
these parsing methods.

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

Re: [osg-users] Effects of locale setting

[Robert Osfield]

I was curious why the .obj plugin that parsing ascii files didn't come
up on my searches for atof usage, and the reason is that the code uses
sscanf for reading the files.  This means that it's a bit more
complicated to solve, I can't just do a search and replace...

What the code will need is either an explicit local setting in the
plugin and later restore of it's value or porting the code across from
using sscanf to a locally defined equivalent.  I don't know the
situation w.r.t thread safety of setting/restoring locale setting, as
our plugins can be used in background threads it's an important area
to clear up.

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

Re: [osg-users] DataVariance

[paul1492]

I attempted to set all my nodes and state sets to DYNAMIC data variance by 
doing the following and it still is locking up on me (i.e. with the same call 
stack as below):

   SetDataVariance dataVariance;
   root-accept(dataVariance);

Where:

class SetDataVariance : public osg::NodeVisitor
{
public:
   SetDataVariance():   
osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
 {};
   virtual void apply(osg::Node node);
   virtual void apply(osg::Geode node);
};
void SetDataVariance::apply(osg::Node node)
{
   node.getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
   traverse(node);
}
void SetDataVariance::apply(osg::Geode geode)
{
    geode.getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);    
    geode.setDataVariance(osg::Object::DYNAMIC);
    for(unsigned int i=0;igeode.getNumDrawables();++i)
    {
    osg::Drawable* drawable = geode.getDrawable(i);
    if (drawable)
    {
   
drawable-getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
   drawable-setDataVariance(osg::Object::DYNAMIC);
    }
    }
}

Removing a portion of my scene graph and the problem goes away (or is 
hidden)..  In particular, if I remove the node-addDrawable(geometry), the 
problem goes away. The problem exists even if node-addDrawable( new 
osg::Geometry).   In addition, turning off optimization doesn't seem to help. 
As I said before, using single threaded viewer and it works fine.
 
Any idea what is going on?
 
Paul P.

- Original Message 
From: Robert Osfield [EMAIL PROTECTED]
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Friday, November 21, 2008 4:10:20 AM
Subject: Re: [osg-users] DataVariance

Hi Paul P.

You will have to debug this on your own I'm afraid, this type of issue
is not something one can resolve without seeing it first hand.

The best I can do is recommend that look into the using DataVariance
set to DYNAMIC on all StateSet and Drawable that you have in your
scene.  This is the most likely cause of problems like this, but we've
already recommended this and you've made no comment whether you've
tried this.  There have been lots written on this topic on osg-users
so please don't overlook the archives.

Robert.

On Thu, Nov 20, 2008 at 7:32 PM,  [EMAIL PROTECTED] wrote:
 When I change to SingleThreaded, I do not see the problem. The standard OSG 
 examples work fine. Other cases of my problem also work fine.

 Clearly, it's something in this app that is causing problems.  In the problem 
 case, I'm rendering to two different image buffers and then reading the 
 images out on the CPU. My scene is a normal scene except I have two cameras 
 with each rendering to these different textures (i.e. a top and bottom view 
 of the scene). I also have another camera rendering an orthogonal projection 
 on top of the scene.

 Paul P.


 - Original Message 
 From: Robert Osfield [EMAIL PROTECTED]
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Sent: Wednesday, September 17, 2008 11:03:33 AM
 Subject: Re: [osg-users] DataVariance

 Hi Paul,

 I can't say why your app might be hanging.  Do the standard OSG
 example hang on your machine?

 Try running the view single threaded as something that might at least
 flesh out whether threading is an issue at all.

 Robert.

 On Wed, Sep 17, 2008 at 3:52 PM,  [EMAIL PROTECTED] wrote:
 Thanks for the quick response...

 Then, any idea why my application is hanging when I attempt to render my 
 first frame?? Below is the call stack of the two OSG threads.

 The problem seems to exist when I include two different parts of my scene 
 graph.  My scene graph consists of two Camera's at the root. Each renders to 
 a different image array (using camera-attach(..., image);).

 Each camera then has shared subgraphs attached which also contain a Camera 
 node (for Ortho view for part of the scene) but with no attachments.

 The osgViewer's camera is unchanged (and I really don't need to render 
 anything).

 Am I doing something wrong with these camera's?

 While I'm at it, one more questions:
 Is there  a way to turn on the OSG statistics overlay without using the 
 keyboard. I've added the StatsHandler event handler. With osgProducer, I 
 used to be able to do viewerEventHandler-setFrameStatsMode(mode).

 Paul P.

 THREAD #1
 #0  0x4146627d in pthread_cond_wait@@GLIBC_2.3.2 ()
    from /lib/tls/libpthread.so.0
 #1  0x41235a66 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libc.so.6
 #2  0x40b1e364 in OpenThreads::Condition::wait (this=0x8281f88,
    mutex=0x8281f80)
    at 
/src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/OpenThreads/pthreads/PThreadCondition.c++:137
 #3  0x40ad9241 in OpenThreads::BlockCount::block (this=0x8281f80) at 
 Block:133
 #4  0x40ad7506 in osgViewer::ViewerBase::renderingTraversals (this=0x827ab58)
    at 
/src/OpenSceneGraph_2.6/OpenSceneGraph-2.6.0/src/osgViewer/ViewerBase.cpp:733
 #5  0x40ad6a88 in osgViewer::ViewerBase::frame (this=0x827ab58,
    

Re: [osg-users] DataVariance

[Robert Osfield]

Hi Paul,

Could you try the CullDrawThreadPerContext thread model to see if that
works safely.  If it does then the issue is almost certainly down to
some StateSet or Drawable in your scene graph that you are modifying
the contents that don't have the DataVariance set to DYNAMIC.

Robert.

On Mon, Nov 24, 2008 at 1:41 PM,  [EMAIL PROTECTED] wrote:
 I attempted to set all my nodes and state sets to DYNAMIC data variance by 
 doing the following and it still is locking up on me (i.e. with the same call 
 stack as below):

SetDataVariance dataVariance;
root-accept(dataVariance);

 Where:

 class SetDataVariance : public osg::NodeVisitor
 {
 public:
SetDataVariance():   
 osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
  {};
virtual void apply(osg::Node node);
virtual void apply(osg::Geode node);
 };
 void SetDataVariance::apply(osg::Node node)
 {
node.getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
traverse(node);
 }
 void SetDataVariance::apply(osg::Geode geode)
 {
 geode.getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
 geode.setDataVariance(osg::Object::DYNAMIC);
 for(unsigned int i=0;igeode.getNumDrawables();++i)
 {
 osg::Drawable* drawable = geode.getDrawable(i);
 if (drawable)
 {

 drawable-getOrCreateStateSet()-setDataVariance(osg::Object::DYNAMIC);
drawable-setDataVariance(osg::Object::DYNAMIC);
 }
 }
 }

 Removing a portion of my scene graph and the problem goes away (or is 
 hidden)..  In particular, if I remove the node-addDrawable(geometry), the 
 problem goes away. The problem exists even if node-addDrawable( new 
 osg::Geometry).   In addition, turning off optimization doesn't seem to help. 
 As I said before, using single threaded viewer and it works fine.

 Any idea what is going on?

 Paul P.

 - Original Message 
 From: Robert Osfield [EMAIL PROTECTED]
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Sent: Friday, November 21, 2008 4:10:20 AM
 Subject: Re: [osg-users] DataVariance

 Hi Paul P.

 You will have to debug this on your own I'm afraid, this type of issue
 is not something one can resolve without seeing it first hand.

 The best I can do is recommend that look into the using DataVariance
 set to DYNAMIC on all StateSet and Drawable that you have in your
 scene.  This is the most likely cause of problems like this, but we've
 already recommended this and you've made no comment whether you've
 tried this.  There have been lots written on this topic on osg-users
 so please don't overlook the archives.

 Robert.

 On Thu, Nov 20, 2008 at 7:32 PM,  [EMAIL PROTECTED] wrote:
 When I change to SingleThreaded, I do not see the problem. The standard OSG 
 examples work fine. Other cases of my problem also work fine.

 Clearly, it's something in this app that is causing problems.  In the 
 problem case, I'm rendering to two different image buffers and then reading 
 the images out on the CPU. My scene is a normal scene except I have two 
 cameras with each rendering to these different textures (i.e. a top and 
 bottom view of the scene). I also have another camera rendering an 
 orthogonal projection on top of the scene.

 Paul P.


 - Original Message 
 From: Robert Osfield [EMAIL PROTECTED]
 To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Sent: Wednesday, September 17, 2008 11:03:33 AM
 Subject: Re: [osg-users] DataVariance

 Hi Paul,

 I can't say why your app might be hanging.  Do the standard OSG
 example hang on your machine?

 Try running the view single threaded as something that might at least
 flesh out whether threading is an issue at all.

 Robert.

 On Wed, Sep 17, 2008 at 3:52 PM,  [EMAIL PROTECTED] wrote:
 Thanks for the quick response...

 Then, any idea why my application is hanging when I attempt to render my 
 first frame?? Below is the call stack of the two OSG threads.

 The problem seems to exist when I include two different parts of my scene 
 graph.  My scene graph consists of two Camera's at the root. Each renders 
 to a different image array (using camera-attach(..., image);).

 Each camera then has shared subgraphs attached which also contain a Camera 
 node (for Ortho view for part of the scene) but with no attachments.

 The osgViewer's camera is unchanged (and I really don't need to render 
 anything).

 Am I doing something wrong with these camera's?

 While I'm at it, one more questions:
 Is there  a way to turn on the OSG statistics overlay without using the 
 keyboard. I've added the StatsHandler event handler. With osgProducer, I 
 used to be able to do viewerEventHandler-setFrameStatsMode(mode).

 Paul P.

 THREAD #1
 #0  0x4146627d in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/tls/libpthread.so.0
 #1  0x41235a66 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libc.so.6
 #2  0x40b1e364 in OpenThreads::Condition::wait (this=0x8281f88,
mutex=0x8281f80)
at 
 

[osg-users] svn does not compile - asciitofloat

[Cedric Pinson]

Hi Robert,

[  5%] Building CXX object src/osg/CMakeFiles/osg.dir/GraphicsContext.o
/home/mornifle/dev/osg-branch/src/osg/GLExtensions.cpp: In function 
'float osg::getGLVersionNumber()':
/home/mornifle/dev/osg-branch/src/osg/GLExtensions.cpp:50: error: 
'asciiToFloat' was not declared in this scope

make[2]: *** [src/osg/CMakeFiles/osg.dir/GLExtensions.o] Error 1


I guess there is a missing #include osg/Math in GLExtensions.cpp

Cheers,
Cedric

--
+33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED] 
http://www.plopbyte.net


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

Re: [osg-users] svn does not compile - asciitofloat

[Robert Osfield]

Hi Cedric,

You did a svn update right at the wrong moment, another svn update
will fix this ;-)

Robert.

On Mon, Nov 24, 2008 at 1:48 PM, Cedric Pinson [EMAIL PROTECTED] wrote:
 Hi Robert,

 [  5%] Building CXX object src/osg/CMakeFiles/osg.dir/GraphicsContext.o
 /home/mornifle/dev/osg-branch/src/osg/GLExtensions.cpp: In function 'float
 osg::getGLVersionNumber()':
 /home/mornifle/dev/osg-branch/src/osg/GLExtensions.cpp:50: error:
 'asciiToFloat' was not declared in this scope
 make[2]: *** [src/osg/CMakeFiles/osg.dir/GLExtensions.o] Error 1


 I guess there is a missing #include osg/Math in GLExtensions.cpp

 Cheers,
 Cedric

 --
 +33 (0) 6 63 20 03 56  Cedric Pinson mailto:[EMAIL PROTECTED]
 http://www.plopbyte.net


 ___
 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] AutoTransform scaling precision.

[Marjamaa, Jonathon E]

Hi,

I have been looking into this, and I really think there is something
wrong with the way that AutoTransform calculates the scale.

Attached is the screen shot showing what I am seeing in dual screen.
Both screens are the same resolution, so I would guess the asymmetry in
the horizontal frustum angles is confusing the algorithm somehow,
although I am seeing problems with horizontally symmetric frustums as
well.

I was able to get this to work much more accurately by changing
AutoTransform, line 182 from:

float size = 1.0f/cs-pixelSize(getPosition(),0.48f);

To:

const osg::Matrix matrix = *(cs-getMVPW());
osg::Vec3d one = cs-getUpLocal(); // get a screen aligned vector
osg::Vec3d zeroTrans = osg::Vec3d(0, 0, 0) * matrix; // get node origin
in screen space
osg::Vec3d oneTrans = one * matrix;  // get vector in screen space
float size = 1.0 / sqrt((zeroTrans[0] - oneTrans[0]) * (zeroTrans[0] -
oneTrans[0]) +
(zeroTrans[1] - oneTrans[1]) * (zeroTrans[1] -
oneTrans[1]) +
(zeroTrans[2] - oneTrans[2]) * (zeroTrans[2] -
oneTrans[2])); // calculate the length of the vector in screen space

I am sure this is more expensive, but it does get me to something more
closely resembling localized screen space.

Jon

-Original Message-
From: Marjamaa, Jonathon E 
Sent: Thursday, November 20, 2008 4:23 PM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] AutoTransform scaling precision.

Hello,

 I am seeing some odd behavior with AutoTransform.  The following .osg 
 file creates an AutoTransform with a grid of lines attached.  The 
 lines are each separated by one unit of space.  When I look at the 
 file in osgviewer, I see that this spacing is not kept.  It looks like

 the auto-scale is not exact.  The imprecision seems to vary with 
 projection, viewport size, and on my windows dual-screen setup it 
 varies with monitor!  If I make the window very wide and short, the 
 shape is scaled so much as to actually shrink significantly in screen 
 space.
 
 Am I using the AutoTransform incorrectly?  Am I expecting this to do 
 more than was intended?
 
 Thanks,
 Jonathon Marjamaa
 
 AutoTransform {
   UniqueID AutoTransform_0
   nodeMask 0x
   cullingActive TRUE
   referenceFrame RELATIVE
   position 0 0 0
   rotation 0 0 0 1
   scale 1 1 1
   pivotPoint 0 0 0
   autoUpdateEyeMovementTolerance 0
   autoRotateMode ROTATE_TO_SCREEN
   autoScaleToScreen TRUE
   num_children 2
   Geode {
 UniqueID Geode_1
 nodeMask 0x
 cullingActive TRUE
 num_drawables 2
 Geometry {
   useDisplayList TRUE
   useVertexBufferObjects FALSE
   VertexArray UniqueID Vec3Array_3 Vec3Array 200
   {
 0 0 0
 0 150 0
 0 0 0
 150 0 0
 2 0 0
 2 150 0
 0 2 0
 150 2 0
 4 0 0
 4 150 0
 0 4 0
 150 4 0
 6 0 0
 6 150 0
 0 6 0
 150 6 0
 8 0 0
 8 150 0
 0 8 0
 150 8 0
 10 0 0
 10 150 0
 0 10 0
 150 10 0
 12 0 0
 12 150 0
 0 12 0
 150 12 0
 14 0 0
 14 150 0
 0 14 0
 150 14 0
 16 0 0
 16 150 0
 0 16 0
 150 16 0
 18 0 0
 18 150 0
 0 18 0
 150 18 0
 20 0 0
 20 150 0
 0 20 0
 150 20 0
 22 0 0
 22 150 0
 0 22 0
 150 22 0
 24 0 0
 24 150 0
 0 24 0
 150 24 0
 26 0 0
 26 150 0
 0 26 0
 150 26 0
 28 0 0
 28 150 0
 0 28 0
 150 28 0
 30 0 0
 30 150 0
 0 30 0
 150 30 0
 32 0 0
 32 150 0
 0 32 0
 150 32 0
 34 0 0
 34 150 0
 0 34 0
 150 34 0
 36 0 0
 36 150 0
 0 36 0
 150 36 0
 38 0 0
 38 150 0
 0 38 0
 150 38 0
 40 0 0
 40 150 0
 0 40 0
 150 40 0
 42 0 0
 42 150 0
 0 42 0
 150 42 0
 44 0 0
 44 150 0
 0 44 0
 150 44 0
 46 0 0
 46 150 0
 0 46 0
 150 46 0
 48 0 0
 48 150 0
 0 48 0
 150 48 0
 50 0 0
 50 150 0
 0 50 0
 150 50 0
 52 0 0
 52 150 0
 0 52 0
 150 52 0
 54 0 0
 54 150 0
 0 54 0
 150 54 0
 56 0 0
 56 150 0
 0 56 0
 150 56 0
 58 0 0
 58 150 0
 0 58 0
 150 58 0
 60 0 0
 60 150 0
 0 60 0
 150 60 0
 62 0 0
 62 150 0
 0 62 0
 150 62 0
 64 0 0
 64 150 0
 0 64 0
 150 64 0
 66 0 0
 66 150 0
 0 66 0