Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[J.P. Delport]

Hi Ralph,

if you can make a small OT vs OpenMP test app that people can run on a 
variety of Linux flavours, maybe something will jump out. E.g. how 
"standard" is the pthread lib in RHEL5.2?


jp

Ralph R. Peters wrote:

Hi Robert & all,

I did the "simple thing" to test if the call pthread_setaffinity_np( 
pthread_self(), sizeof(cpumask), &cpumask) was causing OpenMP problems.  
A code snippet from the function SetProcessorAffinityOfCurrentThread in 
PThread.c++ follows.  Changing "doit" from true to false and recompiling 
lets me test this call.

&&

#if defined(HAVE_PTHREAD_SETAFFINITY_NP)
   std::cout << "SetProcessorAffinityOfCurrentThread: cpunum=" << 
cpunum  << " sizeof(cpumask)=" << sizeof(cpumask) << std::endl;


   bool doit = true;
   if(doit)
   {
  pthread_setaffinity_np( pthread_self(), sizeof(cpumask), 
&cpumask);
  std::cout << "SetProcessorAffinityOfCurrentThread: 
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask) 
called immediately before this printout" << std::endl;

   }
   else
  std::cout << "SetProcessorAffinityOfCurrentThread: 
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask) NOT 
called immediately before this printout result"

<< std::endl;
#elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)



The result was what I suspected.  If the call to  pthread_setaffinity_np 
is NOT made then OpenMP recognizes that there are 8 processors, 
otherwise it thinks that there is only 1.  In both cases I used "strace 
-f -e sched_setaffinity -e sched_getaffinity" to keep an eye on system 
calls.  Output for both cases is listed below.


I am just trying to use OpenMP inside an application that uses 
OpenSceneGraph.  What needs to be done to fix this problem, wherever it 
may be, is "above my current paygrade".   :-)


However, getting our application (umbra  -  
http://robotics.sandia.gov/UMBRA.html) to use OpenMP may be important to 
many of us.


Thanks,
Ralph



Call pthread_setaffinity_np:

camera number: 0
SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
sched_getaffinity(32493, 128,  { ff, 0, 0, 0 }) = 32
SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np( 
pthread_self(), sizeof(cpumask), &cpumask) called immediately before 
this printout

INFO> navigation mode set to umbra
Warning: font file "fonts/arial.ttf" not found.
Setting savConfigCB to '::guiWrapper saveConfig'
sched_getaffinity(32493, 128,  { 1, 0, 0, 0 }) = 32
sLoadFile  filename:/home/vision_data/geometry_objects/test.cdf  
fileType:  lineRowCnt=-1  lineColCnt=-1

std::string UmbModCDFDataSet::LoadFile(const s

Enter test_openmp()
sched_getaffinity(32493, 128,  { 1, 0, 0, 0 }) = 32
OPENMP is 200505  Number of processors available:1 MAX number of OpenMP 
threads 1

GOMP_CPU_AFFINITY is unknown

Exit test_openmp()

do NOT call pthread_setaffinity_np:

camera number: 0
SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np( 
pthread_self(), sizeof(cpumask), &cpumask) NOT called immediately before 
this printout result

INFO> navigation mode set to umbra
Warning: font file "fonts/arial.ttf" not found.
Setting savConfigCB to '::guiWrapper saveConfig'
sched_getaffinity(1393, 128,  { ff, 0, 0, 0 }) = 32
sLoadFile  filename:/home/vision_data/geometry_objects/test.cdf  
fileType:  lineRowCnt=-1  lineColCnt=-1

std::string UmbModCDFDataSet::LoadFile(const s

Enter test_openmp()
sched_getaffinity(1393, 128,  { ff, 0, 0, 0 }) = 32
OPENMP is 200505  Number of processors available:8 MAX number of OpenMP 
threads 8

GOMP_CPU_AFFINITY is unknown

Exit test_openmp()



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



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


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


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

Re: [osg-users] Reporting Builds

[Mathieu MARACHE]

Hi Csaba,

Mathieu



2008/10/16 Csaba Halász <[EMAIL PROTECTED]>:
> On Thu, Oct 16, 2008 at 2:40 AM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>
>> Maybe I am missing something else that causes cmake to use the tcl
>> submit (and that doesn't seem to support http)
>
> /o\ so I don't even need the dart thing, ctest can do everything?

CTest is used yes. those DartConfig.tcl files seem to be leftovers
from the days where you had to install the Dart tool. However the file
is still used since it contains all the information about your
configuration site.

> Where do I change the build name? In cmake I only see SITE, and the
> dartconfig might get regenerated?

I'm looking into this. It seems that adding some definitions to cmake
would do the trick. Something like "cmake -DSITE='name' '' etc. More
on this when I get feedback from this night (CET).

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

Re: [osg-users] Reporting Builds

[Csaba Halász]

On Thu, Oct 16, 2008 at 2:40 AM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> Maybe I am missing something else that causes cmake to use the tcl
> submit (and that doesn't seem to support http)

/o\ so I don't even need the dart thing, ctest can do everything?

Where do I change the build name? In cmake I only see SITE, and the
dartconfig might get regenerated?

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

Re: [osg-users] Reporting Builds

[Csaba Halász]

On Thu, Oct 16, 2008 at 1:23 AM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> I also tried a mingw build, that seems to work too but the submission doesn't:

Comparing with the linux makefile, I spotted this difference:

CMakeFiles/NightlySubmit:

/C/msys/home/hcs/tcl-inst/bin/tclsh.exe
C:/msys/home/hcs/Dart/Source/Client/DashboardManager.tcl
C:/msys/home/hcs/OSG-build-nightly/DartConfiguration.tcl Nightly
Submit


-vs-

CMakeFiles/NightlySubmit: CMakeFiles/NightlySubmit.dir/build.make
/usr/bin/ctest -D NightlySubmit

I have ctest installed on mingw too, and cmake finds it as well:

//Path to ctest program executable.

CMAKE_CTEST_COMMAND:INTERNAL=C:/msys/home/hcs/cmake-inst/bin/ctest.exe


Maybe I am missing something else that causes cmake to use the tcl
submit (and that doesn't seem to support http)

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

Re: [osg-users] DDS textures flipped on flt files

[brettwiesner]

Hi,

Yes, the DDS textures were generated with 0,0 being top left. This is 
because DDS (aka microsoft and directX) has its origin in the upper left 
corner, while OpenGL  has its origin in the lower left corner. While I 
can flip the textures with an option, I wonder if the loader should do 
this automatically. BMP's have the same problem and they are loaded 
"correctly" (ie, the flipping is done automatically).


Thanks,
Brett


Gordon Tomlinson wrote:

This could be the way the DDS files have been generated,  a lot of DDS
creation tools by default start with 0,0 top left instead of top bottom (or
the other way round)  to the norm in vis-sim imagery, 


This has been covered before on the list and a search will most likely pop
out how you can fix this, tools supplied with things like Creator /VegaPrime
make sure the correct 0,0 is chosen, so check you DDS creation tool and
re-gen with the 0,0 origin flipped

__
Gordon Tomlinson 


[EMAIL PROTECTED]
IM: [EMAIL PROTECTED]
www.vis-sim.com www.gordontomlinson.com 
__


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
brettwiesner
Sent: Wednesday, October 15, 2008 10:38 AM
To: OpenSceneGraph Users
Subject: [osg-users] DDS textures flipped on flt files

Hi,

I have a sample terrain that shows that DDS textures are incorrect on flt
files. If you load up the flt file in osgviewer you should see a "framed"
terrain. However, the textures are flipped (it seems only vertically).

Thanks,
Brett

___
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] Reporting Builds

[Csaba Halász]

Hi,

I have set up a nightly 64 bit linux build (I guess you'll get more of
those) that seems to work fine.
Do we have fancy stuff like coverage, valgrind or tests? Also, I
wonder if you want a build from scratch? That took like 3 hrs :)

I also tried a mingw build, that seems to work too but the submission doesn't:

Testing completed

Submit Nightly

Beginning Submission

Built target Nightly


Any ideas?

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

Re: [osg-users] StateSet - newbie

[ami guru]

Hello Joakim,

It works fine now with little amendment mentioned in bold text
Are they conceptually ok  - the 2 lines in bold text?

**
  ref_ptr capsuleGeode = new Geode;
  ref_ptr capsuleShape = new Capsule(Vec3f(3,0,0),1,2);
  ref_ptr capsuleDrawable = new ShapeDrawable(capsuleShape.
get());

  capsuleGeode->addDrawable(capsuleDrawable.get());

  ref_ptr capsuleState = capsuleGeode->getOrCreateStateSet();


  //create the shader parameters
  ref_ptr capsuleProgramObject = new Program;

 * ref_ptr capsuleVertexObject = new Shader(*(Shader::**
readShaderFile(Shader::VERTEX,**"shaderSRC/gooch.vert")));
  ref_ptr capsuleFragmentObject = new Shader(*(Shader::**
readShaderFile(Shader::**FRAGMENT,"shaderSRC/gooch.**vert")));
*
  capsuleProgramObject->addShader(capsuleVertexObject.get());
  capsuleProgramObject->addShader(capsuleFragmentObject.get());


  //create a new stateset
  //with the default setting
  capsuleState->setAttribute(capsuleProgramObject.get());


  //Passing the uniform variable representing the texture to the shader
  capsuleState->addUniform(new
osg::Uniform("LightPosition",osg::Vec3(0,0,10)));
  capsuleState->addUniform(new
osg::Uniform("SurfaceColor",osg::Vec3(0.75,0.75,0.75)));
  capsuleState->addUniform(new osg::Uniform("WarmColor",osg::Vec3(1,0,0)));
  capsuleState->addUniform(new
osg::Uniform("CoolColor",osg::Vec3(0,0,0.6)));
  capsuleState->addUniform(new osg::Uniform("DiffuseWarm",0.45f));
  capsuleState->addUniform(new osg::Uniform("DiffuseCool", 0.45f));


  root->addChild(capsuleGeode.get());



I replaced them with the following one

***
 ref_ptr root = new Group();

  ref_ptr capsuleGeode = new Geode;
  ref_ptr capsuleShape = new Capsule(Vec3f(3,0,0),1,2);
  ref_ptr capsuleDrawable = new
ShapeDrawable(capsuleShape.get());

  capsuleGeode->addDrawable(capsuleDrawable.get());

  ref_ptr capsuleState = capsuleGeode->getOrCreateStateSet();


  //create the shader parameters
  ref_ptr capsuleProgramObject = new Program;

*  ref_ptr capsuleVertexShader = new Shader(Shader::VERTEX);
  capsuleVertexShader->loadShaderSourceFromFile("shaderSRC/gooch.vert");
  ref_ptr capsuleFragmentShader = new Shader(Shader::FRAGMENT);
  capsuleFragmentShader->loadShaderSourceFromFile("shaderSRC/gooch.frag");
*
  capsuleProgramObject->addShader(capsuleVertexShader.get());
  capsuleProgramObject->addShader(capsuleFragmentShader.get());


  //create a new stateset
  //with the default setting
  capsuleState->setAttribute(capsuleProgramObject.get());


  //Passing the uniform variable representing the texture to the shader
  capsuleState->addUniform(new
osg::Uniform("LightPosition",osg::Vec3(0,0,10)));
  capsuleState->addUniform(new
osg::Uniform("SurfaceColor",osg::Vec3(0.75,0.75,0.75)));
  capsuleState->addUniform(new osg::Uniform("WarmColor",osg::Vec3(1,0,0)));
  capsuleState->addUniform(new
osg::Uniform("CoolColor",osg::Vec3(0,0,0.6)));
  capsuleState->addUniform(new osg::Uniform("DiffuseWarm",0.45f));
  capsuleState->addUniform(new osg::Uniform("DiffuseCool", 0.45f));


  root->addChild(capsuleGeode.get());



***

Sajjad


On Wed, Oct 15, 2008 at 11:48 PM, ami guru <[EMAIL PROTECTED]> wrote:

> Thanks Joakim,
>
> I believe that sharing the stateset will be required here
>
> I am trying to attach a simple shader but sharing the stateset is not
> giving me the result
> that i am supposed to have
>
>
> **
>   ref_ptr capsuleGeode = new Geode;
>   ref_ptr capsuleShape = new Capsule(Vec3f(3,0,0),1,2);
>   ref_ptr capsuleDrawable = new
> ShapeDrawable(capsuleShape.get());
>
>   capsuleGeode->addDrawable(capsuleDrawable.get());
>
>   ref_ptr capsuleState = capsuleGeode->getOrCreateStateSet();
>
>
>   //create the shader parameters
>   ref_ptr capsuleProgramObject = new Program;
>
>   ref_ptr capsuleVertexObject = new
> Shader(*(Shader::readShaderFile(Shader::VERTEX,"shaderSRC/gooch.vert")));
>   ref_ptr capsuleFragmentObject = new
> Shader(*(Shader::readShaderFile(Shader::FRAGMENT,"shaderSRC/gooch.vert")));
>
>   capsuleProgramObject->addShader(capsuleVertexObject.get());
>   capsuleProgramObject->addShader(capsuleFragmentObject.get());
>
>
>   //create a new stateset
>   //with the default setting
>   capsuleState->setAttribute(capsuleProgramObject.get());
>
>
>   //Passing the uniform variable representing the texture to the shader
>   capsuleState->addUniform(new
> osg::Uniform("LightPosition",osg::Vec3(0,0,10)));
>   capsuleState->addUniform(new
> osg::Uniform("SurfaceColor",osg::Vec3(0.75,0.75,0.75)));
>   capsuleState->addUniform(new osg::Uniform("WarmColor",osg::Vec3(1,0,0)));
>   capsuleState->addUniform(new
> osg::Uniform("CoolColor",osg::Vec3(0,0,0.6)));
>   capsuleState->addUniform(new osg::Uniform("DiffuseWarm",0.45f));
>   capsuleState->addUniform(new osg::Uniform("DiffuseCool", 0.45f));
>
>
>   root->addChild(capsuleGeode.get());
>
>
> 
> A

Re: [osg-users] StateSet - newbie

[Joakim Simonsson]

It seems that you are now using the shader you are expecting. But you have  
error in your GLSL code...


Try replace the GLSL code, with a simple "Hello World" GLSL example. Just  
to see that the GLSL code compiles correctly.


On Thu, 16 Oct 2008 00:08:59 +0200, ami guru <[EMAIL PROTECTED]> wrote:


Hi Joakim,

Thats the error with the previous suggestion

*'
FRAGMENT glCompileShader "" FAILED




But works fine if i have the following instead...

ref_ptr nodess3 (myshapegeode3->getOrCreateStateSet());


I doubt that the above line compiles. You should use the clone function if  
you want to copy things.




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

Re: [osg-users] Reporting Builds

[Mathieu MARACHE]

Hi Jean-Sébastien,


2008/10/15 Jean-Sébastien Guay <[EMAIL PROTECTED]>:
> Hi Mathieu,
>
>> This new feature (BUILD_DASHBOARD_REPORTS
>> option defaulted to OFF) will permit to some people willing to share
>> some build time on various platforms to submit compilation results on
>> a regular if not automatic basis.
>
> Interesting!
>
> One question I have is, if CMake automatically updates the working copy (to
> 00:00 for Nightly, or to right now for continuous), does it then re-run
> itself to regenerate build files if some source files were added? If so,
> what happens if there's an error when generating the build files (error in
> the CMakeLists.txt or something like that)?

Good question, after testing, it fails without reporting. I tried this
with the Continuous build : after generating a valid makefile I
modified locally the root CMakeLists.txt so that it contained invalid
code. Calling 'make Continuous' tries (and fails without reporting) to
regenerate the Makefiles before doing an (svn) update. So if there is
an error committed in the repository, there is way cmake can recover
from this situation by itself.

This is a though situation. If this happens, the only way I see is to
do a manual svn update when the repository is clean again... Not very
satifying, I will think/sleep on this :-)

> As for build scripts, perhaps the one you have on the wiki could be included
> with the OSG sources in some subdirectory, and another could be developed
> for Windows that would do something similar. I'd be willing to make my work
> machine build nightly on Windows if we can get someone more versed in
> Windows batch programming make a good batch script that would do this.

Others have been looking into this, and I think It is necessary to
have some sort of scripts available for the community to (at least)
adapt from. Let's see tomorrow if their Nighly build scripts worked !

Another aspect needing attention is configuring (semi-automatically)
the information passed with the submission about the compiler, the os,
the site. So that for example the build name reflects a bit more the
system than a plain Linux-c++ :-)

> I think setting up this kind of thing (which IMHO is unobtrusive, since it
> runs at night when I'm not working) will give us more information about the
> status or general health of the SVN (and any branches we want to monitor)
> and thus would reduce the calls to test current SVN manually, and increase
> confidence that at least the releases will build correctly on various
> platforms.
>
> Now if we could convince Matthias to set up nightly builds on the large
> number of less used platforms he apparently has access to ;-)

I myself should be providing an IRIX64 Nightly and Continuous build.
Others are welcome to pop in.

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

Re: [osg-users] StateSet - newbie

[ami guru]

Hi Joakim,

Thats the error with the previous suggestion

*'
FRAGMENT glCompileShader "" FAILED
FRAGMENT Shader "" infolog:
Fragment shader failed to compile with the following errors:
ERROR: 0:19: 'gl_Vertex' : undeclared identifier
ERROR: 0:20: 'gl_Normal' : undeclared identifier
ERROR: 0:20: 'normalize' : no matching overloaded function found
ERROR: 0:20: '=' :  cannot convert from 'const float' to 'undefined
interpolation 3-component vector of float'
ERROR: 0:22: 'assign' :  l-value required "ReflectVec" (can't modify a
varying)
ERROR: 0:23: 'assign' :  l-value required "ViewVec" (can't modify a varying)
ERROR: 0:24: 'assign' :  l-value required "NdotL" (can't modify a varying)
ERROR: 0:25: 'gl_Position' : undeclared identifier
ERROR: 0:25: 'ftransform' : no matching overloaded function found
ERROR: 9 compilation errors.  No code generated.

glLinkProgram "" FAILED
Program "" infolog:
Fragment shader(s) were not successfully compiled before glLinkProgram() was
called.  Link failed.

Warning: detected OpenGL error 'invalid operation' after RenderBin::draw(,


'''

But works fine if i have the following instead...

ref_ptr nodess3 (myshapegeode3->getOrCreateStateSet());


Which is doing a copy , right?


Sajjad

On Wed, Oct 15, 2008 at 11:55 PM, Joakim Simonsson <[EMAIL PROTECTED]>wrote:

> On Wed, 15 Oct 2008 23:48:40 +0200, ami guru <[EMAIL PROTECTED]>
> wrote:
>
>
>   //create a new stateset
>>  //with the default setting
>>  capsuleState->setAttribute(capsuleProgramObject.get());
>>
>>
> Every thing look correct, but I am not sure about this line. Try this one
> instead:
>
> capsuleState->setAttributeAndModes(shaderNightDriving.get());
>
>
> --
> Joakim Simonsson
> ___
> 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] StateSet - newbie

[Joakim Simonsson]

On Wed, 15 Oct 2008 23:48:40 +0200, ami guru <[EMAIL PROTECTED]> wrote:



  //create a new stateset
  //with the default setting
  capsuleState->setAttribute(capsuleProgramObject.get());



Every thing look correct, but I am not sure about this line. Try this one  
instead:


capsuleState->setAttributeAndModes(shaderNightDriving.get());

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

Re: [osg-users] StateSet - newbie

[ami guru]

Thanks Joakim,

I believe that sharing the stateset will be required here

I am trying to attach a simple shader but sharing the stateset is not giving
me the result
that i am supposed to have


**
  ref_ptr capsuleGeode = new Geode;
  ref_ptr capsuleShape = new Capsule(Vec3f(3,0,0),1,2);
  ref_ptr capsuleDrawable = new
ShapeDrawable(capsuleShape.get());

  capsuleGeode->addDrawable(capsuleDrawable.get());

  ref_ptr capsuleState = capsuleGeode->getOrCreateStateSet();


  //create the shader parameters
  ref_ptr capsuleProgramObject = new Program;

  ref_ptr capsuleVertexObject = new
Shader(*(Shader::readShaderFile(Shader::VERTEX,"shaderSRC/gooch.vert")));
  ref_ptr capsuleFragmentObject = new
Shader(*(Shader::readShaderFile(Shader::FRAGMENT,"shaderSRC/gooch.vert")));

  capsuleProgramObject->addShader(capsuleVertexObject.get());
  capsuleProgramObject->addShader(capsuleFragmentObject.get());


  //create a new stateset
  //with the default setting
  capsuleState->setAttribute(capsuleProgramObject.get());


  //Passing the uniform variable representing the texture to the shader
  capsuleState->addUniform(new
osg::Uniform("LightPosition",osg::Vec3(0,0,10)));
  capsuleState->addUniform(new
osg::Uniform("SurfaceColor",osg::Vec3(0.75,0.75,0.75)));
  capsuleState->addUniform(new osg::Uniform("WarmColor",osg::Vec3(1,0,0)));
  capsuleState->addUniform(new
osg::Uniform("CoolColor",osg::Vec3(0,0,0.6)));
  capsuleState->addUniform(new osg::Uniform("DiffuseWarm",0.45f));
  capsuleState->addUniform(new osg::Uniform("DiffuseCool", 0.45f));


  root->addChild(capsuleGeode.get());



Any hint?


Sajjad


On Wed, Oct 15, 2008 at 10:56 PM, Joakim Simonsson <[EMAIL PROTECTED]>wrote:

> On Wed, 15 Oct 2008 22:43:14 +0200, ami guru <[EMAIL PROTECTED]>
> wrote:
>
>  Hello forum
>>
>> Is there any difference between these following:
>>
>> 1. osg::ref_ptr nodess3  = new
>> StateSet((myshapegeode3->getOrCreateStateSet()));
>> 2. osg::ref_ptr
>> nodess3((myshapegeode3->getOrCreateStateSet()));
>>
>
> Yes they differ. But do you want to do? Copy the stateset?
>
> If you want to share the stateset (for example, edit myshapegeode3's
> stateset) do this:
>
> osg::ref_ptr nodess3 = myshapegeode3->getOrCreateStateSet();
>
> If you want to copy it, do this:
>
> osg::ref_ptr nodess3 =
>
>  myshapegeode3->getOrCreateStateSet()->clone(osg::CopyOp::DEEP_COPY_ALL));
>
>
> --
> Joakim Simonsson
> ___
> 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] infinite block with CullThreadPerCameraDrawThreadPerContext

[Csaba Halász]

Hi again,

Now that I got threading running, I have run into this trouble:

draw() 0xee0b20
draw() got SceneView 0xf18a80
end draw() 0xee0b20
draw() 0xda1f80
cull()
cull() got SceneView 0xf03e90
end cull() 0xee0b20
cull()
cull() got SceneView 0xf7b020
_clampProjectionMatrix not applied, invalid depth range, znear =
3.40282e+38  zfar = -3.40282e+38
end cull() 0xda1f80
draw() got SceneView 0xf7b020
end draw() 0xda1f80
draw() 0xee0b20
draw() got SceneView 0xf03e90
end draw() 0xee0b20
draw() 0xda1f80
cull()
cull() got SceneView 0xf84a20
_clampProjectionMatrix not applied, invalid depth range, znear =
3.40282e+38  zfar = -3.40282e+38
end cull() 0xda1f80
draw() got SceneView 0xf84a20
cull()
cull() got SceneView 0xf18a80
end cull() 0xee0b20
end draw() 0xda1f80
draw() 0xee0b20
draw() got SceneView 0xf18a80
end draw() 0xee0b20
draw() 0xda1f80

It stops here.

(gdb) thr 5
[Switching to thread 5 (Thread 0x420a5950 (LWP 28584))]#0
0x2ae3f4c89b99 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib/libpthread.so.0
(gdb) bt
#0  0x2ae3f4c89b99 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0x2ae3f7a55c56 in OpenThreads::Condition::wait (this=, mutex=)
at 
/home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThreadCondition.c++:137
#2  0x2ae3f68d0bd3 in
osgViewer::Renderer::TheadSafeQueue::takeFront (this=0x10f8a78)
at /home/hcs/src/OpenSceneGraph/include/OpenThreads/Block:42
#3  0x2ae3f68d25de in osgViewer::Renderer::draw (this=0x10f8980)
at /home/hcs/src/OpenSceneGraph/src/osgViewer/Renderer.cpp:340
#4  0x2ae3f772eac4 in osg::GraphicsContext::runOperations (this=0x10f99a0)
at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsContext.cpp:688
#5  0x2ae3f776c688 in osg::OperationThread::run (this=0x11cd6c0)
at /home/hcs/src/OpenSceneGraph/src/osg/OperationThread.cpp:413
#6  0x2ae3f77351c0 in osg::GraphicsThread::run (this=0x11cd6c0)
at /home/hcs/src/OpenSceneGraph/src/osg/GraphicsThread.cpp:38
#7  0x2ae3f7a55537 in
OpenThreads::ThreadPrivateActions::StartThread (data=)
at /home/hcs/src/OpenSceneGraph/src/OpenThreads/pthreads/PThread.c++:172
#8  0x2ae3f4c853f7 in start_thread () from /lib/libpthread.so.0
#9  0x2ae3f839497d in clone () from /lib/libc.so.6
#10 0x in ?? ()

Any ideas?

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

Re: [osg-users] StateSet - newbie

[Joakim Simonsson]

On Wed, 15 Oct 2008 22:43:14 +0200, ami guru <[EMAIL PROTECTED]> wrote:


Hello forum

Is there any difference between these following:

1. osg::ref_ptr nodess3  = new
StateSet((myshapegeode3->getOrCreateStateSet()));
2. osg::ref_ptr
nodess3((myshapegeode3->getOrCreateStateSet()));


Yes they differ. But do you want to do? Copy the stateset?

If you want to share the stateset (for example, edit myshapegeode3's  
stateset) do this:


osg::ref_ptr nodess3 = myshapegeode3->getOrCreateStateSet();

If you want to copy it, do this:

osg::ref_ptr nodess3 =
myshapegeode3->getOrCreateStateSet()->clone(osg::CopyOp::DEEP_COPY_ALL));


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

[osg-users] StateSet - newbie

[ami guru]

Hello forum

Is there any difference between these following:

1. osg::ref_ptr nodess3  = new
StateSet((myshapegeode3->getOrCreateStateSet()));
2. osg::ref_ptr
nodess3((myshapegeode3->getOrCreateStateSet()));

The the second one works fine

and the first one gives error:

Game.cpp: In member function 'virtual osg::ref_ptr
Game::createSceneGraph()':
Game.cpp:89: error: no matching function for call to
'osg::StateSet::StateSet(osg::StateSet*)'
/usr/local/include/osg/StateSet:54: note: candidates are:
osg::StateSet::StateSet(const osg::StateSet&, const osg::CopyOp&)
/usr/local/include/osg/StateSet:53: note:
osg::StateSet::StateSet()
make: *** [Game.o] Error 1
*
In both cases it is taking a pointer to a State to instantiate a new
StateSet

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

Re: [osg-users] Advice on interacting with osgShadow

[Wojciech Lewandowski]

J-S,

I agree. I will make proposed changes and resubmit. I will do it tomorrow.

Cheers,
Wojtek

-Original Message-
From: Jean-Sébastien Guay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 10:21 PM
To: [EMAIL PROTECTED]; OpenSceneGraph Users
Subject: Re: [osg-users] Advice on interacting with osgShadow


Hi Wojtek,

> Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin
> override. I don't want to make decision that has to be its either this or
> that. I would like to leave RenderBin override as default. I would also
add
> setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to
allow
> user turn it off if he decides. So my conclusion is I would like to add
the
> submission as sent to the codebase.

Excellent, I agree with this. I tested your code and it works for me, so
you can send it to osg-submissions whenever you want.

I could suggest that instead of using

 OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1,
 SET_COLOR_MASK_TO_FALSE = 2,

you use the bit shift notation, which I find easier to read and maintain
(and please align the values... :-) ):

 OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1 << 0,
 SET_COLOR_MASK_TO_FALSE  = 1 << 1,
 SOME_OTHER_SETTING   = 1 << 2,

but that's just a style issue and subject to personal taste.

Also you could add a doxygen comment for the ShadowMapRenderingSettings
enum, which would explain what the values are useful for. Otherwise,
it's pretty cryptic for users (unless they search the mailing lists and
find this thread :-) ).

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] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hi Wojtek,


Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin
override. I don't want to make decision that has to be its either this or
that. I would like to leave RenderBin override as default. I would also add
setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to allow
user turn it off if he decides. So my conclusion is I would like to add the
submission as sent to the codebase.


Excellent, I agree with this. I tested your code and it works for me, so 
you can send it to osg-submissions whenever you want.


I could suggest that instead of using

OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1,
SET_COLOR_MASK_TO_FALSE = 2,

you use the bit shift notation, which I find easier to read and maintain 
(and please align the values... :-) ):


OVERRIDE_RENDER_BINS_WITH_OPAQUE_BIN = 1 << 0,
SET_COLOR_MASK_TO_FALSE  = 1 << 1,
SOME_OTHER_SETTING   = 1 << 2,

but that's just a style issue and subject to personal taste.

Also you could add a doxygen comment for the ShadowMapRenderingSettings 
enum, which would explain what the values are useful for. Otherwise, 
it's pretty cryptic for users (unless they search the mailing lists and 
find this thread :-) ).


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] Advice on interacting with osgShadow

[Wojciech Lewandowski]

J-S,

>> I suppose that single overriden render bin with AlphaFunc/AlphaTest
>> turned only when needed should be faster in theory. Other options turn
>> AlphaFunce even when not needed. But in practice I doubt difference will
>> be noticable.
>>
>> Even though you managed to activate AlphaFunc, I agree with you that
>> forcing one render bin may possibly bring some unexpected trouble. Its
>> hard to come up with exact scenario where it will fail, but I have the
>> feeling that render bin various sorting modes and renderbin prototype
>> extension mechanism may be at risk with such override.

> Err, ok, so what is the conclusion? What would you prefer to do? Remove
> the renderbin override (or set it to disabled by default in the options
> bitmask)?

Turning on AlphaTest/AlphaFunc is not mutually exclusive with RenderBin
override. I don't want to make decision that has to be its either this or
that. I would like to leave RenderBin override as default. I would also add
setShadowMapRenderingSettings/getShadowMapRenderingSettings methods to allow
user turn it off if he decides. So my conclusion is I would like to add the
submission as sent to the codebase.

Cheers,
Wojtek

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Csaba Halász]

On Wed, Oct 15, 2008 at 8:44 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 8:28 PM, Robert Osfield
> <[EMAIL PROTECTED]> wrote:
>
>> This sounds like a bug in osgViewer, it shouldn't matter which order
>> your set the threading model.
>
> Hmm, upon closer look Viewer::realize() does call setUpThreading()
> which in turn calls startThreading().
> Gotta do some debugging why it doesn't work for me.

Got it:

int ViewerBase::run()
{
if (!isRealized())
{
realize();
}

But the isRealized() function doesn't really say if realize() has been
called or not, it just checks if *any* of the gc's are realized. Our
code happened to call realize on the gc, so the viewer's realize()
never got called. Depending on whether it is allowed to realize gc's
manually it is either a bug or not :)

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

Re: [osg-users] Removing Configurable Origin In osgWidget

[Jeremy Moles]

On Wed, 2008-10-15 at 20:30 +0100, Robert Osfield wrote:
> Hi Jeremy,
> 
> I can certainly understand the desire to keep the code simple as
> possible - as there are always factors driving increased complexity as
> you introduce new functionality, so complexity that delivers little
> functionality is something that may well be bes to cull.
> 
> As for which coordinate frame to adopt, personally I'd go for OpenGL
> coordinate frame, as there shouldn't need to be any conversions of
> coordinate frame within the scene graph - it's all self consistent.
> OpenGL convention doe make it a little more of a learning curve for
> windowing centric developers, but shorten the learning curve for 3d
> centric developers so this aspect is a bit of six of one half a dozen
> of the other.

I totally agree. I think I was a bit too ambitious with osgWidget at
first--wanting to support everything I could imagine--and it's caused
way too many headaches than if I would have just kept things simple.

I shall make it so.

> Robert.
> 
> On Wed, Oct 15, 2008 at 7:58 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote:
> > Hello all!
> >
> > So, a quick question (particularly to Robert)...
> >
> > How would you feel if I removed the ability for the user to choose their
> > origin with osgWidget via the enum passed to the WindowManager during
> > creation? It's just becoming a code maintenance nightmare, and I'm
> > having to do a ton of "deferred" positioning since the WindowManager is
> > what defines this and I have to wait until a UI Object has
> > it's ::managed() method called before I can do anything. I don't imagine
> > there are really that many people using it right now other than
> > experimentation, so it shouldn't be a big deal.
> >
> > If so, would you want to keep the default OpenGL origin (which can be
> > somewhat confusing to 3rd party UI mod-makers expecting it to be more
> > consistent with traditional windowing coordinate systems)? Or should it
> > be in the upper-left? Either way is fine, but trying to support both via
> > a simple enum (and then having to write all this code to do it properly
> > and THEN expecting people remember this when they derive custom Widgets)
> > seems to be getting out of hand...
> >
> > ___
> > 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] Naive question about eyePoint and viewPoint

[Robert Osfield]

HI Roger,

For most cases EyePoint and VIewPoint are one of the same thing.

The cases where EyePoint can be different from ViewPoint is when you
have a technique such as a local render to texture effect that has its
own local Camera and therefore eye point that it's subgraph will see,
but you want operations such as LOD transitions to consistent with
main Camera's rendering of the scene graph, so here the RTT Camera
subgraph can be told to inherit the main Camera's eye point as it's
view point rather than the local eye point.   One good example of this
in action is when you are doing shadow mapping and you want the shadow
map to taken from one position, but have the same LOD children viewed
as the main view.

Robert.

On Wed, Oct 15, 2008 at 8:08 PM, Roger James
<[EMAIL PROTECTED]> wrote:
> I am sorry if this is a naive question, but can somebody explain to me what
> is the difference between what is returned by CullStack::getEyeLocal and
> CullStack::getViewPointLocal (i.e. the eyePointStack and the
> viewPointStack). I want to get the current main scene camera position in a
> cull pass and am wondering which one to use.
>
> Roger
>
> ___
> 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] Removing Configurable Origin In osgWidget

[Robert Osfield]

Hi Jeremy,

I can certainly understand the desire to keep the code simple as
possible - as there are always factors driving increased complexity as
you introduce new functionality, so complexity that delivers little
functionality is something that may well be bes to cull.

As for which coordinate frame to adopt, personally I'd go for OpenGL
coordinate frame, as there shouldn't need to be any conversions of
coordinate frame within the scene graph - it's all self consistent.
OpenGL convention doe make it a little more of a learning curve for
windowing centric developers, but shorten the learning curve for 3d
centric developers so this aspect is a bit of six of one half a dozen
of the other.

Robert.

On Wed, Oct 15, 2008 at 7:58 PM, Jeremy Moles <[EMAIL PROTECTED]> wrote:
> Hello all!
>
> So, a quick question (particularly to Robert)...
>
> How would you feel if I removed the ability for the user to choose their
> origin with osgWidget via the enum passed to the WindowManager during
> creation? It's just becoming a code maintenance nightmare, and I'm
> having to do a ton of "deferred" positioning since the WindowManager is
> what defines this and I have to wait until a UI Object has
> it's ::managed() method called before I can do anything. I don't imagine
> there are really that many people using it right now other than
> experimentation, so it shouldn't be a big deal.
>
> If so, would you want to keep the default OpenGL origin (which can be
> somewhat confusing to 3rd party UI mod-makers expecting it to be more
> consistent with traditional windowing coordinate systems)? Or should it
> be in the upper-left? Either way is fine, but trying to support both via
> a simple enum (and then having to write all this code to do it properly
> and THEN expecting people remember this when they derive custom Widgets)
> seems to be getting out of hand...
>
> ___
> 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] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

Hi Ralf,

I'm afraid there isn't anything more I can do to help you, as I have
absolutely no experience with OpenMP, and am not an expert on the
pthread affinity functions.  Perhaps others on the list might be able
to help.

What it does look like is that pthread_setaffinity_np/OpenMP
interoprability is buggy, and is beyond the scope of the
OSG/OpenThreads.  If there are better pthread calls/settings to use to
avoid the OpenMP interoprability problems then I'm open to integrating
these, but I personally can't say what these might be or whether it
might be possible.

The only other thing that might be doable on the OSG side is to allow
you disable the affinity setting functions completely for your app.
This would break some of the performance benefits of the threading in
the viewer class though, so this would be far from an ideal solution.

Robert.

On Wed, Oct 15, 2008 at 7:58 PM, Ralph R. Peters <[EMAIL PROTECTED]> wrote:
> Hi Robert & all,
>
> I did the "simple thing" to test if the call pthread_setaffinity_np(
> pthread_self(), sizeof(cpumask), &cpumask) was causing OpenMP problems.  A
> code snippet from the function SetProcessorAffinityOfCurrentThread in
> PThread.c++ follows.  Changing "doit" from true to false and recompiling
> lets me test this call.
> &&
>
> #if defined(HAVE_PTHREAD_SETAFFINITY_NP)
>   std::cout << "SetProcessorAffinityOfCurrentThread: cpunum=" << cpunum
>  << " sizeof(cpumask)=" << sizeof(cpumask) << std::endl;
>
>   bool doit = true;
>   if(doit)
>   {
>  pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask);
>  std::cout << "SetProcessorAffinityOfCurrentThread:
> pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask) called
> immediately before this printout" << std::endl;
>   }
>   else
>  std::cout << "SetProcessorAffinityOfCurrentThread:
> pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask) NOT
> called immediately before this printout result"
><< std::endl;
> #elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
>
> 
>
> The result was what I suspected.  If the call to  pthread_setaffinity_np is
> NOT made then OpenMP recognizes that there are 8 processors, otherwise it
> thinks that there is only 1.  In both cases I used "strace -f -e
> sched_setaffinity -e sched_getaffinity" to keep an eye on system calls.
>  Output for both cases is listed below.
>
> I am just trying to use OpenMP inside an application that uses
> OpenSceneGraph.  What needs to be done to fix this problem, wherever it may
> be, is "above my current paygrade".   :-)
>
> However, getting our application (umbra  -
>  http://robotics.sandia.gov/UMBRA.html) to use OpenMP may be important to
> many of us.
>
> Thanks,
> Ralph
>
>
> 
> Call pthread_setaffinity_np:
>
> camera number: 0
> SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
> sched_getaffinity(32493, 128,  { ff, 0, 0, 0 }) = 32
> SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np( pthread_self(),
> sizeof(cpumask), &cpumask) called immediately before this printout
> INFO> navigation mode set to umbra
> Warning: font file "fonts/arial.ttf" not found.
> Setting savConfigCB to '::guiWrapper saveConfig'
> sched_getaffinity(32493, 128,  { 1, 0, 0, 0 }) = 32
> sLoadFile  filename:/home/vision_data/geometry_objects/test.cdf  fileType:
>  lineRowCnt=-1  lineColCnt=-1
> std::string UmbModCDFDataSet::LoadFile(const s
>
> Enter test_openmp()
> sched_getaffinity(32493, 128,  { 1, 0, 0, 0 }) = 32
> OPENMP is 200505  Number of processors available:1 MAX number of OpenMP
> threads 1
> GOMP_CPU_AFFINITY is unknown
>
> Exit test_openmp()
> 
> do NOT call pthread_setaffinity_np:
>
> camera number: 0
> SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
> SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np( pthread_self(),
> sizeof(cpumask), &cpumask) NOT called immediately before this printout
> result
> INFO> navigation mode set to umbra
> Warning: font file "fonts/arial.ttf" not found.
> Setting savConfigCB to '::guiWrapper saveConfig'
> sched_getaffinity(1393, 128,  { ff, 0, 0, 0 }) = 32
> sLoadFile  filename:/home/vision_data/geometry_objects/test.cdf  fileType:
>  lineRowCnt=-1  lineColCnt=-1
> std::string UmbModCDFDataSet::LoadFile(const s
>
> Enter test_openmp()
> sched_getaffinity(1393, 128,  { ff, 0, 0, 0 }) = 32
> OPENMP is 200505  Number of processors available:8 MAX number of OpenMP
> threads 8
> GOMP_CPU_AFFINITY is unknown
>
> Exit test_openmp()
>
> 
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Naive question about eyePoint and viewPoint

[Roger James]

I am sorry if this is a naive question, but can somebody explain to me
what is the difference between what is returned by
CullStack::getEyeLocal and CullStack::getViewPointLocal (i.e. the
eyePointStack and the viewPointStack). I want to get the current main
scene camera position in a cull pass and am wondering which one to use.

Roger


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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Ralph R. Peters]

Hi Robert & all,

I did the "simple thing" to test if the call pthread_setaffinity_np( 
pthread_self(), sizeof(cpumask), &cpumask) was causing OpenMP problems.  
A code snippet from the function SetProcessorAffinityOfCurrentThread in 
PThread.c++ follows.  Changing "doit" from true to false and recompiling 
lets me test this call. 


&&

#if defined(HAVE_PTHREAD_SETAFFINITY_NP)
   std::cout << "SetProcessorAffinityOfCurrentThread: cpunum=" << 
cpunum  << " sizeof(cpumask)=" << sizeof(cpumask) << std::endl;


   bool doit = true;
   if(doit)
   {
  pthread_setaffinity_np( pthread_self(), sizeof(cpumask), 
&cpumask);
  std::cout << "SetProcessorAffinityOfCurrentThread: 
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask) 
called immediately before this printout" << std::endl;

   }
   else
  std::cout << "SetProcessorAffinityOfCurrentThread: 
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask) NOT 
called immediately before this printout result"

<< std::endl;
#elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)



The result was what I suspected.  If the call to  pthread_setaffinity_np 
is NOT made then OpenMP recognizes that there are 8 processors, 
otherwise it thinks that there is only 1.  In both cases I used "strace 
-f -e sched_setaffinity -e sched_getaffinity" to keep an eye on system 
calls.  Output for both cases is listed below.


I am just trying to use OpenMP inside an application that uses 
OpenSceneGraph.  What needs to be done to fix this problem, wherever it 
may be, is "above my current paygrade".   :-)


However, getting our application (umbra  -  
http://robotics.sandia.gov/UMBRA.html) to use OpenMP may be important to 
many of us.


Thanks,
Ralph



Call pthread_setaffinity_np:

camera number: 0
SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
sched_getaffinity(32493, 128,  { ff, 0, 0, 0 }) = 32
SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np( 
pthread_self(), sizeof(cpumask), &cpumask) called immediately before 
this printout

INFO> navigation mode set to umbra
Warning: font file "fonts/arial.ttf" not found.
Setting savConfigCB to '::guiWrapper saveConfig'
sched_getaffinity(32493, 128,  { 1, 0, 0, 0 }) = 32
sLoadFile  filename:/home/vision_data/geometry_objects/test.cdf  
fileType:  lineRowCnt=-1  lineColCnt=-1

std::string UmbModCDFDataSet::LoadFile(const s

Enter test_openmp()
sched_getaffinity(32493, 128,  { 1, 0, 0, 0 }) = 32
OPENMP is 200505  Number of processors available:1 MAX number of OpenMP 
threads 1

GOMP_CPU_AFFINITY is unknown

Exit test_openmp()

do NOT call pthread_setaffinity_np:

camera number: 0
SetProcessorAffinityOfCurrentThread: cpunum=0 sizeof(cpumask)=128
SetProcessorAffinityOfCurrentThread: pthread_setaffinity_np( 
pthread_self(), sizeof(cpumask), &cpumask) NOT called immediately before 
this printout result

INFO> navigation mode set to umbra
Warning: font file "fonts/arial.ttf" not found.
Setting savConfigCB to '::guiWrapper saveConfig'
sched_getaffinity(1393, 128,  { ff, 0, 0, 0 }) = 32
sLoadFile  filename:/home/vision_data/geometry_objects/test.cdf  
fileType:  lineRowCnt=-1  lineColCnt=-1

std::string UmbModCDFDataSet::LoadFile(const s

Enter test_openmp()
sched_getaffinity(1393, 128,  { ff, 0, 0, 0 }) = 32
OPENMP is 200505  Number of processors available:8 MAX number of OpenMP 
threads 8

GOMP_CPU_AFFINITY is unknown

Exit test_openmp()



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

[osg-users] Removing Configurable Origin In osgWidget

[Jeremy Moles]

Hello all!

So, a quick question (particularly to Robert)...

How would you feel if I removed the ability for the user to choose their
origin with osgWidget via the enum passed to the WindowManager during
creation? It's just becoming a code maintenance nightmare, and I'm
having to do a ton of "deferred" positioning since the WindowManager is
what defines this and I have to wait until a UI Object has
it's ::managed() method called before I can do anything. I don't imagine
there are really that many people using it right now other than
experimentation, so it shouldn't be a big deal.

If so, would you want to keep the default OpenGL origin (which can be
somewhat confusing to 3rd party UI mod-makers expecting it to be more
consistent with traditional windowing coordinate systems)? Or should it
be in the upper-left? Either way is fine, but trying to support both via
a simple enum (and then having to write all this code to do it properly
and THEN expecting people remember this when they derive custom Widgets)
seems to be getting out of hand...

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Csaba Halász]

On Wed, Oct 15, 2008 at 8:28 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 6:45 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>> On Wed, Oct 15, 2008 at 7:23 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>>
>>> The threading is set like so:
>>> viewer = new osgViewer::Viewer;
>>> viewer->setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext);
>>
>> And that's exactly the problem ... setting the threading mode before
>> the viewer is realized does not start threading.
>> I added an explicit call to startThreading() later, and get the printouts 
>> now :)
>
> This sounds like a bug in osgViewer, it shouldn't matter which order
> your set the threading model.

Hmm, upon closer look Viewer::realize() does call setUpThreading()
which in turn calls startThreading().
Gotta do some debugging why it doesn't work for me.

> Has the stats graph changed at all?

Yes, I now have overlapping bars. Unfortunately our code is doing
something from the wrong thread, so
CullThreadPerCameraDrawThreadPerContext doesn't work yet and even
CullDrawThreadPerContext crashes after some time. But these problems
are likely our fault.

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

On Wed, Oct 15, 2008 at 6:45 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 7:23 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>
>> The threading is set like so:
>> viewer = new osgViewer::Viewer;
>> viewer->setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext);
>
> And that's exactly the problem ... setting the threading mode before
> the viewer is realized does not start threading.
> I added an explicit call to startThreading() later, and get the printouts now 
> :)

This sounds like a bug in osgViewer, it shouldn't matter which order
your set the threading model.

Has the stats graph changed at all?

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Csaba Halász]

On Wed, Oct 15, 2008 at 7:23 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
> The threading is set like so:
> viewer = new osgViewer::Viewer;
> viewer->setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext);

And that's exactly the problem ... setting the threading mode before
the viewer is realized does not start threading.
I added an explicit call to startThreading() later, and get the printouts now :)

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

Re: [osg-users] Statistics display without needing a GUIEventHandler (UNCLASSIFIED)

[Buckley, Bob CTR MDA/IC]

Classification:  UNCLASSIFIED 
Caveats: NONE


This is how I do it:

Viewer *viewer = new Viewer;
viewer->addEventHandler(new StatsHandler);
viewer->getEventQueue()->keyPress('s'); // repeat as necessary


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, October 15, 2008 10:41 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Statistics display without needing a GUIEventHandler

 I previously asked this question about turning on the stats without a key 
process. With osgProducer, I used to do: 
viewerEventHandler->setFrameStatsMode(mode).  

Any chance something could be done with to osgViewer to make turning on the 
Statistics easier.  Seems like others in the OSG community would be interested.

Paul P.

- Original Message 
From: Alexander Löffler <[EMAIL PROTECTED]>
To: OpenSceneGraph Users 
Sent: Wednesday, October 15, 2008 10:16:02 AM
Subject: Re: [osg-users] Statistics display without needing a GUIEventHandler

Hi Mattias,

Mattias Helsing wrote:
> I do a similar thing with the HelpHandler. I subclassed the 
> HelpHandler like below.
> I then instantiate it and add it to the Viewer (and a osgWidget 
> menuitem). Then I call initialize on it *before* viewer.run() but
> *after* viewer.realize()

Thanks a lot for your reply. Your solution is similar to what I already had for 
my custom StatsHandler, except that I had to include a lot more in the 
initialize method, namely the entire switch statement from
StatsHandler::handle() that distinguishes between the different StatsTypes. I 
had to change that, too, such that it does not depend on having called the 
parts for the previous types when switching on a later type.

I am getting closer now; one thing I still cannot manage to do is display GPU 
stats correctly. This works with the original StatHandler, but not with my 
modified one. This obviously depends on whether the GraphicsContexts of all 
Cameras of the hosting Viewer (just one in my case) support the TimerQuery GL 
extension, which they obviously do in general (since the original StatsHandler 
shows the stats), but not at the time I check in the modified version. This 
seems to be a question of call timing. From what point of rendering progress on 
does the GraphicsContext of a Camera support a GL extension, and why does this 
not work earlier?

Alex.

> //! Simple wrapper of the osgViewer::HelpHandler to let me initialize  
>it before first invocation of it's \c handle()  struct MyHelpHandler : 
>public osgViewer::HelpHandler  {
>    MyHelpHandler(osg::ApplicationUsage* au) : 
>osgViewer::HelpHandler(au) {};
>    void initialize(osgViewer::ViewerBase* viewer)
>    {
>        if (!_initialized && viewer)
>        {
>            setUpHUDCamera(viewer);
>            setUpScene(viewer);
>            if(_camera.valid())
>            {
>                _camera->setNodeMask(0);
>                _helpEnabled = false;
>            }
>        }
>    }
> };
> 
> 
> On 10/15/08, Alexander Löffler <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am trying to display on-screen statistics as provided by the 
>> osgViewer::StatsHandler without the need for doing this via handling 
>> the key presses first. That is, I want to add a command line options 
>> to my application to either display statistics just as frame rate, 
>> full stats, or not at all.
>>
>> Is there an easy way to do that with the available StatsHandler? I 
>> tried subclassing from the handler with the option to set the StatsType 
>> initially.
>> Currently without success, as there seem to be lots of dependencies 
>> of what parts of OSG have to be set up before collecting of stats is 
>> actually possible.
>> For example, some cameras seem not yet to be set up when I 
>> instantiate my handler, collecting GPU stats is disabled in my HUD, etc..
>>
>> Has anyone ever done something similar before?
>>
>> Thanks a lot in advance,
>> Alex.
>> ___
>> 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
Classification:  UNCLASSIFIED 
Caveats: NONE

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Csaba Halász]

On Wed, Oct 15, 2008 at 7:07 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 6:01 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>
>> Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html
>> I have tried your debugging mods, with the osgcamera example I get the
>> expected printout:
>>
>> With our app (flightgear), however, I don't get any. I might have
>> messed up the compilation, but do you think there is another code path
>> to set threading model that could circumvent your prints?
>> In the meantime, I'll investigate too.
>
> I don't know anything about flight gear code I'm afraid.  There is
> only one method in ViewerBase that sets up threading so it should be
> called your method if flight gear is linking your app and set up
> threading the normal way.

As you can see on the screenshot, the statistics show that the
threading model is set, but no printout and the bars don't overlap
either.
The threading is set like so:
viewer = new osgViewer::Viewer;
viewer->setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext);

It seems to be loading the freshly compiled osg libs (fails to start
if I rename them)
We also use a databasepager, that seems to run on a different thread
as expected.

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

Hi Csaba,

On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> But if OSG happens to force 2 cpu intensive threads to the same core,
> performance will suffer anyway, and more than a simple cache
> efficiency issue.
> I have 3 cameras, two of which are using the same graph and a third
> that's drawing GUI elements. As such this third one is much less cpu
> intensive. So depending on what order they get instantiated the two
> "main" cameras might end up on the same cpu while the other cpu is
> bored to death with the GUI camera. (I have dual-core machine)

The setup in osgViewer does make assumptions about the loading across
cameras and does it best to guess what might be appropriate, but it
won't be perfect for all usages.

My long tmer plan for osg::GraphicsContext::Traits has been to put in
an cpu affinity field into it, and therefore provide users an ability
to explicitly set the affinity.  This is just another item on my TODO
list..  Feel free to jump and implement this yourself and submit the
changes.   Such as field could be used by users with "awkward" cases
which the defaults don't do well on.

> As a related question, in the stats display if multiple cpus are used
> properly, should that manifest itself as overlapping bars? Because I
> don't see any such, the different phases (draw, cull) for the cameras
> all appear to be run after each other. I am now building osg with your
> debug modifications, to see if that tells me something.

On my quad core system I certain do see overlap.  Milage will vary
across hardware, OS and OSG usage.

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

On Wed, Oct 15, 2008 at 6:01 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html
> I have tried your debugging mods, with the osgcamera example I get the
> expected printout:
>
> numProcessors = 2
> cpunum=1
> cpunum=0
> cpunum=1
> running and setting thread 0xd91d18 for cpunum=0
> running and setting thread 0xcb31c8 for cpunum=1
> running and setting thread 0xd1e528 for cpunum=1

This looks correct.

> With our app (flightgear), however, I don't get any. I might have
> messed up the compilation, but do you think there is another code path
> to set threading model that could circumvent your prints?
> In the meantime, I'll investigate too.

I don't know anything about flight gear code I'm afraid.  There is
only one method in ViewerBase that sets up threading so it should be
called your method if flight gear is linking your app and set up
threading the normal way.

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

On Wed, Oct 15, 2008 at 5:58 PM, Ralph R. Peters <[EMAIL PROTECTED]> wrote:
> Would you please send me your modified code and we can run the same code!

I already did, please trace back through the thread.

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

On Wed, Oct 15, 2008 at 6:01 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 15, 2008 at 6:47 PM, Robert Osfield
> <[EMAIL PROTECTED]> wrote:
>>
>> On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>
>>> As a related question, in the stats display if multiple cpus are used
>>> properly, should that manifest itself as overlapping bars? Because I
>>> don't see any such, the different phases (draw, cull) for the cameras
>>> all appear to be run after each other. I am now building osg with your
>>> debug modifications, to see if that tells me something.
>>
>> On my quad core system I certain do see overlap.  Milage will vary
>> across hardware, OS and OSG usage.
>
> Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html
> I have tried your debugging mods, with the osgcamera example I get the
> expected printout:
>
> numProcessors = 2
> cpunum=1
> cpunum=0
> cpunum=1
> running and setting thread 0xd91d18 for cpunum=0
> running and setting thread 0xcb31c8 for cpunum=1
> running and setting thread 0xd1e528 for cpunum=1
>
> With our app (flightgear), however, I don't get any. I might have
> messed up the compilation, but do you think there is another code path
> to set threading model that could circumvent your prints?
> In the meantime, I'll investigate too.
>
> --
> Csaba
> ___
> 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] OpenThreads/pthreads & OpenMP on RHEL5.2

[Csaba Halász]

On Wed, Oct 15, 2008 at 6:47 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>
>> As a related question, in the stats display if multiple cpus are used
>> properly, should that manifest itself as overlapping bars? Because I
>> don't see any such, the different phases (draw, cull) for the cameras
>> all appear to be run after each other. I am now building osg with your
>> debug modifications, to see if that tells me something.
>
> On my quad core system I certain do see overlap.  Milage will vary
> across hardware, OS and OSG usage.

Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html
I have tried your debugging mods, with the osgcamera example I get the
expected printout:

numProcessors = 2
cpunum=1
cpunum=0
cpunum=1
running and setting thread 0xd91d18 for cpunum=0
running and setting thread 0xcb31c8 for cpunum=1
running and setting thread 0xd1e528 for cpunum=1

With our app (flightgear), however, I don't get any. I might have
messed up the compilation, but do you think there is another code path
to set threading model that could circumvent your prints?
In the meantime, I'll investigate too.

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Ralph R. Peters]

Hi Robert,

Would you please send me your modified code and we can run the same code!

Ralph



{snip
Hi Ralf,

As a sanity test I've just added some debug code into
src/osgViewer/ViewerBase.cpp and src/OpenThreads/pthreads/PThead.c++
to track what cpu numbers as being assigned from the viewer, and what
is being recieved by OpenThreads, running osgwindow cow.osg I get:

numProcessors = 4
cpunum=1
cpunum=2
cpunum=3
cpunum=0
running and setting thread 0x737238 for cpunum=3
running and setting thread 0x737638 for cpunum=0
running and setting thread 0x734bf8 for cpunum=1
running and setting thread 0x736de8 for cpunum=2

So all looks correct in terms of num of processors and cpu number
assigned for affinity.

Could you please do such a test at your end, without OpenMP confusing
things.  Once you have this santity test that confirms that the basic
affinity functionality is working on the OpenThreads/osgVIewer side
then throw OpenMP into the mix.

Robert.
}




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

Re: [osg-users] dynamic LODs

[Robert Osfield]

Hi Tomas,

> many thanks for your reply.
> If I understand it right, the VPB creates a hierarchy of static LOD nodes
> that are paged.

That is correct.

> But is it possible to use the VPB for generation of such graph for general
> datasets, not only terrain data?

No.  It's for handle geospatial imagery and DEMs only.

> I have an large triangle mesh on input, let's say in STL format (can convert
> to OSG Geode or custom vectors).
> How can I give such input to VPB and get an PagedLOD hierarchy osga on
> output ?
> Simply generate osga and put it as input file (is it the
> vpb::Source::MODEL)?
>
> In the osgdem source I see the line osg::ref_ptr node =
> osgDB::readNodeFile(fileName);
> does it mean that the input file must fit into the memory to process it?

Well you can't do any geometry processing of the sort you are looking
for with VPB/osgdem.

Also readNodeFile only handles models that can fit in main memory.

If you want a general purpose LOD tool that handles source polygonal
data that is larger than what can fit in main memory then you'll need
to either find a specialist tool to do this or to write it yourself.

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

Re: [osg-users] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hello Wojtek,

I suppose that single overriden render bin with AlphaFunc/AlphaTest 
turned only when needed should be faster in theory. Other options turn 
AlphaFunce even when not needed. But in practice I doubt difference will 
be noticable.


Even though you managed to activate AlphaFunc, I agree with you that 
forcing one render bin may possibly bring some unexpected trouble. Its 
hard to come up with exact scenario where it will fail, but I have the 
feeling that render bin various sorting modes and renderbin prototype 
extension mechanism may be at risk with such override.


Err, ok, so what is the conclusion? What would you prefer to do? Remove 
the renderbin override (or set it to disabled by default in the options 
bitmask)?


From my point of view, I'm just interested in the results. Both 
solutions give good results visually, and the performance difference 
seems to be very small (perhaps unmeasurable in my scene/application). 
So whatever you decide is fine by me.


Thanks,

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] Statistics display without needing a GUIEventHandler

[paul1492]

 I previously asked this question about turning on the stats without a key 
process. With osgProducer, I used to do: 
viewerEventHandler->setFrameStatsMode(mode).  

Any chance something could be done with to osgViewer to make turning on the 
Statistics easier.  Seems like others in the OSG community would be interested.

Paul P.

- Original Message 
From: Alexander Löffler <[EMAIL PROTECTED]>
To: OpenSceneGraph Users 
Sent: Wednesday, October 15, 2008 10:16:02 AM
Subject: Re: [osg-users] Statistics display without needing a GUIEventHandler

Hi Mattias,

Mattias Helsing wrote:
> I do a similar thing with the HelpHandler. I subclassed the
> HelpHandler like below.
> I then instantiate it and add it to the Viewer (and a osgWidget
> menuitem). Then I call initialize on it *before* viewer.run() but
> *after* viewer.realize()

Thanks a lot for your reply. Your solution is similar to what I already had for
my custom StatsHandler, except that I had to include a lot more in the
initialize method, namely the entire switch statement from
StatsHandler::handle() that distinguishes between the different StatsTypes. I
had to change that, too, such that it does not depend on having called the parts
for the previous types when switching on a later type.

I am getting closer now; one thing I still cannot manage to do is display GPU
stats correctly. This works with the original StatHandler, but not with my
modified one. This obviously depends on whether the GraphicsContexts of all
Cameras of the hosting Viewer (just one in my case) support the TimerQuery GL
extension, which they obviously do in general (since the original StatsHandler
shows the stats), but not at the time I check in the modified version. This
seems to be a question of call timing. From what point of rendering progress on
does the GraphicsContext of a Camera support a GL extension, and why does this
not work earlier?

Alex.

> //! Simple wrapper of the osgViewer::HelpHandler to let me initialize
> it before first invocation of it's \c handle()
> struct MyHelpHandler : public osgViewer::HelpHandler
> {
>    MyHelpHandler(osg::ApplicationUsage* au) : osgViewer::HelpHandler(au) {};
>    void initialize(osgViewer::ViewerBase* viewer)
>    {
>        if (!_initialized && viewer)
>        {
>            setUpHUDCamera(viewer);
>            setUpScene(viewer);
>            if(_camera.valid())
>            {
>                _camera->setNodeMask(0);
>                _helpEnabled = false;
>            }
>        }
>    }
> };
> 
> 
> On 10/15/08, Alexander Löffler <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am trying to display on-screen statistics as provided by the
>> osgViewer::StatsHandler without the need for doing this via handling the key
>> presses first. That is, I want to add a command line options to my
>> application
>> to either display statistics just as frame rate, full stats, or not at all.
>>
>> Is there an easy way to do that with the available StatsHandler? I tried
>> subclassing from the handler with the option to set the StatsType initially.
>> Currently without success, as there seem to be lots of dependencies of what
>> parts of OSG have to be set up before collecting of stats is actually
>> possible.
>> For example, some cameras seem not yet to be set up when I instantiate my
>> handler, collecting GPU stats is disabled in my HUD, etc..
>>
>> Has anyone ever done something similar before?
>>
>> Thanks a lot in advance,
>> Alex.
>> ___
>> 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] OpenThreads/pthreads & OpenMP on RHEL5.2

[Csaba Halász]

On Wed, Oct 15, 2008 at 6:15 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
> Hi Csaba,
>
> On Wed, Oct 15, 2008 at 5:07 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>>> So all looks correct in terms of num of processors and cpu number
>>> assigned for affinity.
>>
>> I wonder why OSG assigns threads to cpus by itself and not rely on the
>> operating system.
>
> Because a OS will let that thread move from core to core and destroy
> cache coherency and with it most or sometimes all the performance
> benefit of going multi-threaded.  Setting thread affinity is *crucial*
> to getting good multi-threaded performance.

But if OSG happens to force 2 cpu intensive threads to the same core,
performance will suffer anyway, and more than a simple cache
efficiency issue.
I have 3 cameras, two of which are using the same graph and a third
that's drawing GUI elements. As such this third one is much less cpu
intensive. So depending on what order they get instantiated the two
"main" cameras might end up on the same cpu while the other cpu is
bored to death with the GUI camera. (I have dual-core machine)

As a related question, in the stats display if multiple cpus are used
properly, should that manifest itself as overlapping bars? Because I
don't see any such, the different phases (draw, cull) for the cameras
all appear to be run after each other. I am now building osg with your
debug modifications, to see if that tells me something.

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

Re: [osg-users] Advice on interacting with osgShadow

[Wojciech Lewandowski]

Hi J-S,

It looks like we are in sort of counter-phase.You convinced me to your 
arguments in the same time as I convinced you to mine ;-)


However, I've confirmed that disabling the renderbin override is not 
necessary if I put an AlphaFunc on my root node, so I'd also be happy with 
the status quo if no one needs this added configurability... See my other 
message in this thread.


It might even be confusing to have two ways to accomplish the same thing, 
one of which may or may not be faster than the other...


What do you think?


I suppose that single overriden render bin with AlphaFunc/AlphaTest turned 
only when needed should be faster in theory. Other options turn AlphaFunce 
even when not needed. But in practice I doubt difference will be noticable.


Even though you managed to activate AlphaFunc, I agree with you that forcing 
one render bin may possibly bring some unexpected trouble. Its hard to come 
up with exact scenario where it will fail, but I have the feeling that 
render bin various sorting modes and renderbin prototype extension mechanism 
may be at risk with such override.


Cheers,
Wojtek 


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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

Hi Csaba,

On Wed, Oct 15, 2008 at 5:07 PM, Csaba Halász <[EMAIL PROTECTED]> wrote:
>> So all looks correct in terms of num of processors and cpu number
>> assigned for affinity.
>
> I wonder why OSG assigns threads to cpus by itself and not rely on the
> operating system.

Because a OS will let that thread move from core to core and destroy
cache coherency and with it most or sometimes all the performance
benefit of going multi-threaded.  Setting thread affinity is *crucial*
to getting good multi-threaded performance.

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

Re: [osg-users] DDS textures flipped on flt files

[Gordon Tomlinson]

This could be the way the DDS files have been generated,  a lot of DDS
creation tools by default start with 0,0 top left instead of top bottom (or
the other way round)  to the norm in vis-sim imagery, 

This has been covered before on the list and a search will most likely pop
out how you can fix this, tools supplied with things like Creator /VegaPrime
make sure the correct 0,0 is chosen, so check you DDS creation tool and
re-gen with the 0,0 origin flipped

__
Gordon Tomlinson 

[EMAIL PROTECTED]
IM: [EMAIL PROTECTED]
www.vis-sim.com www.gordontomlinson.com 
__

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
brettwiesner
Sent: Wednesday, October 15, 2008 10:38 AM
To: OpenSceneGraph Users
Subject: [osg-users] DDS textures flipped on flt files

Hi,

I have a sample terrain that shows that DDS textures are incorrect on flt
files. If you load up the flt file in osgviewer you should see a "framed"
terrain. However, the textures are flipped (it seems only vertically).

Thanks,
Brett

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

Re: [osg-users] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hi Wojtek,

I think your observations prove that AlphaFunc is activated by 
Transparent bin. IMHO safest way with dealing with AlphaFunc/AlphaTest 
is to activate it explicitly as a node state attribute whenever BLEND is 
activated or TransparentBin is selected through RenderingBin hint. That 
way its always on when needed and we are not on mercy of default state 
sets ;-)


Sure. I can always run a visitor on any loaded models, check if there's 
BLEND or TransparentBin settings anywhere, and then add AlphaFunc there 
too (since they aren't in our source models).


I think that submission I have sent is still worth adding. I made my 
change slightly more general so that it may be easily extended to 
suppress other controversial optimizations when needed.


I agree.

Thanks,

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] OpenThreads/pthreads & OpenMP on RHEL5.2

[Csaba Halász]

On Wed, Oct 15, 2008 at 5:46 PM, Robert Osfield
<[EMAIL PROTECTED]> wrote:
>
> numProcessors = 4
> cpunum=1
> cpunum=2
> cpunum=3
> cpunum=0
> running and setting thread 0x737238 for cpunum=3
> running and setting thread 0x737638 for cpunum=0
> running and setting thread 0x734bf8 for cpunum=1
> running and setting thread 0x736de8 for cpunum=2
>
> So all looks correct in terms of num of processors and cpu number
> assigned for affinity.

I wonder why OSG assigns threads to cpus by itself and not rely on the
operating system. Or at least have a switch to disable this behaviour.
Suppose I have 3 cameras and 2 contexts, that could mean 5 threads
each with different cpu needs. How does OSG know what threads to put
on the same cpu? All I see is a simple round-robin distribution.
Am I missing something? Is this affinity possibly just a hint rather
than an enforced constraint, so threads might run on other cpus too?

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

Re: [osg-users] dynamic LODs

[Tomas Hnilica]

Hi Robert,
many thanks for your reply.
If I understand it right, the VPB creates a hierarchy of static LOD 
nodes that are paged.


But is it possible to use the VPB for generation of such graph for 
general datasets, not only terrain data?
I have an large triangle mesh on input, let's say in STL format (can 
convert to OSG Geode or custom vectors).
How can I give such input to VPB and get an PagedLOD hierarchy osga on 
output ?
Simply generate osga and put it as input file (is it the 
vpb::Source::MODEL)?


In the osgdem source I see the line 
osg::ref_ptr node = osgDB::readNodeFile(fileName);

does it mean that the input file must fit into the memory to process it?

Many thanks,
Tomas



Robert Osfield napsal(a):

Hi Tomas,

On Tue, Oct 14, 2008 at 2:07 PM, Tomas Hnilica
<[EMAIL PROTECTED]> wrote:
  

does anyone know about dynamic Level Of Details implementation in OSG?



The VirtualTerrainProject is based ontop of the OpenSceneGraph and
adds a number of CLOD techniques.

  

There are well described algorithms like several types of Hoppe's
Progressive Meshes or Garland's Quadric Error Metrics.
I am wondering if no one made an OSG implementation (or is there some major
problem for such dynamics in scenegraph?).



No problem in implementing them, but... these days CLOD is not as
compelling a solution than it once was.  Paged databases scale much
better - for instance the combination of VirtualPlanetBuilder and OSG
is currently being used to generate and view multi-Terrabyte whole
earth databases.

  

The chunkLOD by Vladimir Vukicevic referenced on vterrain.org is not
available.



chunkLOD is not a CLOD implementation, it's a paged system, since the
OSG has paging built into and it has VPB to build databases you
basically have something like chunkLOD right out of the box, and in
system that is far more flexible.

  

Also the Demeter project is not available on http://www.terrainengine.com,
but I found it on http://www.tbgsoftware.com/downloads.html. Anyway it's not
a general dymamic LOD, but it's mainly for terrains.



I never found Demeter to perform well so wouldn't recommend it so the
lack of availability of Demeter is probably not too much of a
hindrance.

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


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

Re: [osg-users] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hi Wojtek,


J-S please look at this and add/adapt to your needs.


Looks good and extensible too. Works fine as I expected.

However, I've confirmed that disabling the renderbin override is not 
necessary if I put an AlphaFunc on my root node, so I'd also be happy 
with the status quo if no one needs this added configurability... See my 
other message in this thread.


It might even be confusing to have two ways to accomplish the same 
thing, one of which may or may not be faster than the other...


What do you think?

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] Sharing Vertex Arrays between Geometry Nodes

[Paul Martz]

I can't say which method would be easier for you. Are you more comfortable
with modeling or with coding OSG? If you want to combine textures into a
texture atlas, you'll need to use modeling software to make sure the texture
coordinate are correct. If you want to make multiple Geometry objects
sharing the same vertex array, you'll need to write code to post-process the
model.
 
As J-S says, it'd probably be easier to get your models in the right
configuration from the start. However, it sounds like you have no control
over how the modelers created your models.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aitor
Arrieta
Sent: Wednesday, October 15, 2008 8:33 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes


Hi Paul

I don't know but maybe... Would it be easier to combine both textures (head
and body) and create a new obj file using this new texture? You should take
into account that I have never done something like that (I don't know even
which program should I use)

Regards,

Aitor




- Mensaje original 
De: Paul Martz <[EMAIL PROTECTED]>
Para: OpenSceneGraph Users 
Enviado: martes, 14 de octubre, 2008 17:38:17
Asunto: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes


The code I posted will work for the use case you describe. Indices are part
of the PrimitiveSet; assign a different PrimitiveSet (with different
indices) to each Geometry and they will index into the same vertex array.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aitor
Arrieta
Sent: Tuesday, October 14, 2008 9:05 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes


Hi Paul

Thanks a lot for your reply, but unfortunately I think that my question is
not as simple as you think. Sorry because it was my fault as I did not
explain myself correctly.

The problem is that I must have a single vertex arrays for many different
geometries but each geometry uses only a part of this vertex array.. That
is, imagine a single vertex array with indices from 1 to 100. I should have
geometry 1 with indices from 1 to 10, geometry 2 with indices from 11 to 20,
etc. But all of them sharing the same vertex array, which is used to do some
other things.

Sorry for my bad explanation and thanks again for your reply.

Best regards,

Aitor





- Mensaje original 
De: Paul Martz <[EMAIL PROTECTED]>
Para: OpenSceneGraph Users 
Enviado: martes, 14 de octubre, 2008 16:54:00
Asunto: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes


osg::Geometry* geom0 = new osg::Geometry;

osg::Geometry* geom1 = new osg::Geometry;
osg::Vec3Array* verts = osg::Vec3Array;
geom0->setVertexArray( verts );

geom1->setVertexArray( verts );
 
Hope that helps.
   -Paul


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Aitor
Arrieta
Sent: Tuesday, October 14, 2008 8:39 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Sharing Vertex Arrays between Geometry Nodes


Hi all,
 
I am developing an application in which I have to share the same vertex
array between different nodes in order to apply a different texture to each
of them. I know that this is possible to do because I have read it. However,
I am a beginner in the osg world and I am not able to find the way to do it.
 
Someone told me that I could use the same geode having different geometries
but how can I specify a vertex array for a geode? As far as I know this is
impossible, is not it?
I have also read something about using the DrawElementsUShort primitive but
how should I use it?
 
My question is: is there any example of sharing vertex arrays between
geometry nodes anywhere? Or has anybody done this before? In short, could
anybody please help me with this task?
 
Thank you very much in advance.
 
Regards,
 
Aitor




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

Re: [osg-users] Advice on interacting with osgShadow

[Wojciech Lewandowski]

Hi J-S,

I have sent proposed tweaks for submission.

I think your observations prove that AlphaFunc is activated by Transparent 
bin. IMHO safest way with dealing with AlphaFunc/AlphaTest is to activate it 
explicitly as a node state attribute whenever BLEND is activated or 
TransparentBin is selected through RenderingBin hint. That way its always on 
when needed and we are not on mercy of default state sets ;-)


I think that submission I have sent is still worth adding. I made my change 
slightly more general so that it may be easily extended to suppress other 
controversial optimizations when needed.


Cheers,
Wojtek


Hi Wojtek,

Ok, now I think I understand - I will submit fix for this case or if You 
prefer you may do it. Basically we would want to add setter and getter 
for the flag which will turn off render bin override, right ?


Hmmm... I added an osg::AlphaFunc with comparison GL_GREATER 0.0 to the 
root of my scene graph, and it works well. So if this is the expected 
behavior, perhaps the ShadowedScene could have this osg::AlphaFunc by 
default?


shadowedScene->getOrCreateStateSet()->setAttributeAndModes(
new osg::AlphaFunc(osg::AlphaFunc::GREATER, 0.0),
osg::StateAttribute::ON);

Just hypothetically, for the same end result, what would be faster:
A) overriding the renderbins and using an AlphaFunc
B) disabling the override on the renderbin

(I suspect A, but I'm not that familiar with AlphaFunc)

I think it's expected that objects with textures which have texels at 
alpha=0.0 will have holes in their shadows. So we should either document 
this clearly, or set it by default, as it wasn't at all obvious to me, at 
least.


Thanks,

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

Re: [osg-users] Advice on interacting with osgShadow

[Wojciech Lewandowski]

Hi Robert, J-S,

Attached are proposed fixes to supress overly aggressive optimizations in 
StandardShadowMap rendering. I added ShadowMapRenderingSettings enum and 
setShadowMapRenderingSettings / getShadowMapRenderingSettings methods to 
provide mechanism for similar tweaks in the future.


J-S please look at this and add/adapt to your needs.

Cheers,
Wojtek



Hi J-S,

No, they won't be solid. As they are not solid in for trees drawn in 
island scene. But you have to use alpha ref. On the other hand if your 
transparency does not use alpha ref and sets Z-values it will still be 
solid even if color buffer would end transparent.


Alpha ref? What's that? (I'm showing my ignorance, but all I know is that 
our objects just have textures with alpha=0 for some texels - I don't 
know anything about alpha ref)




Sorry for being imprecise. By alpha ref I meant using osg::AlphaFunc to 
discard pixels with alpha lower or equal to reference value. I think that 
OpenGL default is 0.0.


So I must admit I don't exactly understand why turning blending may 
change depth values in shadow map. Maybe its not blending but override 
on rendering bins ? I use only one bin to render shadow map - is this 
the reason of your problems ?


It's true that I was oversimplifying. I always put blending and renderbin 
settings in the same bucket as normally they're used together... You're 
absolutely right, it's the renderbin override that causes the shadows of 
my chain link fences (and other objects with textures having some texels 
alpha=0) to be totally opaque.


So coming back to what you said above, what would be the right solution? 
Is there a way to fix our models so that I don't have to comment out the 
renderbin override in StandardShadowMap.cpp?


Otherwise, I'd submit a setter/getter control for that particular 
setting. It's necessary in our situation.




I see. Maybe AlphaFunc is selectively turned on by Transparent bins  and 
turned off  by Opaque bins and maybe thats why you see the difference when 
your StateSets do not have AlphaFunc set explicitly. I must admit that we 
usually set AlphaFunc in our datasbases thts probably the reason I have 
not noticed this problem yet.


Ok, now I think I understand - I will submit fix for this case or if You 
prefer you may do it. Basically we would want to add setter and getter for 
the flag which will turn off render bin override, right ?


Cheers,
Wojtek


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


StandardShadowMap
Description: Binary data
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2006 Robert Osfield 
*
* This library is open source and may be redistributed and/or modified under  
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or 
* (at your option) any later version.  The full license is in LICENSE file

* included with this distribution, and on the openscenegraph.org website.
* 
* This library is distributed in the hope that it will be useful,

* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the 
* OpenSceneGraph Public License for more details.

*
* ViewDependentShadow codes Copyright (C) 2008 Wojciech Lewandowski
* Thanks to to my company http://www.ai.com.pl for allowing me free this work.
*/

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace osgShadow;

#define DISPLAY_SHADOW_TEXEL_TO_PIXEL_ERROR 0


StandardShadowMap::StandardShadowMap():
   BaseClass(),
   _polygonOffsetFactor( 1.1f ),

   _polygonOffsetUnits( 4.0f ),
   _textureSize( 1024, 1024 ),
   _baseTextureUnit( 0 ),
   _shadowTextureUnit( 1 ),
   _baseTextureCoordIndex( 0 ),
   _shadowTextureCoordIndex( 1 ),
   _shadowMapRenderingSettings( DEFAULT_SHADOW_MAP_RENDERING_SETTINGS )

{ 
   _mainFragmentShader = new osg::Shader( osg::Shader::FRAGMENT,

   " // following expressions are auto modified - do not change them:   
\n"
   " // gl_TexCoord[0]  0 - can be subsituted with other index  
\n"
   "
\n"
   "float DynamicShadow( ); 
\n"
   "
\n"
   "varying vec4 colorAmbientEmissive;  
\n"
   "
\n"
   "uniform sampler2D baseTexture;  
\n"
   "
\n"
   "void main(void) 
\n"
   "{   
\n"
   "  vec4 color = texture

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

Hi Ralf,

As a sanity test I've just added some debug code into
src/osgViewer/ViewerBase.cpp and src/OpenThreads/pthreads/PThead.c++
to track what cpu numbers as being assigned from the viewer, and what
is being recieved by OpenThreads, running osgwindow cow.osg I get:

numProcessors = 4
cpunum=1
cpunum=2
cpunum=3
cpunum=0
running and setting thread 0x737238 for cpunum=3
running and setting thread 0x737638 for cpunum=0
running and setting thread 0x734bf8 for cpunum=1
running and setting thread 0x736de8 for cpunum=2

So all looks correct in terms of num of processors and cpu number
assigned for affinity.

Could you please do such a test at your end, without OpenMP confusing
things.  Once you have this santity test that confirms that the basic
affinity functionality is working on the OpenThreads/osgVIewer side
then throw OpenMP into the mix.

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

Re: [osg-users] Statistics display without needing a GUIEventHandler

[Alexander Löffler]

Hi Jean-Sébastien,

Jean-Sébastien Guay wrote:
> If you're checking for an OpenGL extension, you need to be in a thread
> that has a graphics context valid, or use a pre/postdraw camera callback
> to do the check. Maybe call the initialize method in a pre-draw callback
> which you would put on your main camera?

This helped a lot: as you suggested I call initialize() in a pre-draw callback
of the main camera now, extensions are found and the Stats are displayed nicely.
Thank you!

Alex.

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

Re: [osg-users] OpenThreads/pthreads & OpenMP on RHEL5.2

[Robert Osfield]

Hi Ralf,

SetProcessorAffinityOfCurrentThread(0) is just setting the affinity of
thread to cpu number 0, this is a perfectly normal reasonable setting,
it in itself is nothing to worry about, the main rendering thread
being assigned to cpu number 0 is exactly what you want for most apps.

What the other threads are being assinged to depends upon the
existance of other threads.  What is your viewer setup?  How many
GraphicsContext/Camera's, and what threading model?

Also what value does OpenThreads::GetNumberOfProcessors() return?

Robert.

On Wed, Oct 15, 2008 at 4:14 PM, Ralph R. Peters <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I will try to be much more concise! :-)
> The problem appears to be that SetProcessorAffinityOfCurrentThread(unsigned
> int cpunum) is always being called with a cpunum value of zero.  More
> information follows.
>
> I am trying to use OpenMP with an application that uses OpenScenGraph.  When
> OpenMP runs it says that there is only 1 CPU available on an 8 processor PC.
>
> After numerous exchanges with jakub (thread may be found at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586), it appears that a call
> to sched_setaffinity, or its "wrapper"  pthread_setaffinity_np, is setting
> the number of processors available to 1 on my PC.
>
> After a fair amount of looking around, I dug deep into OpenSceneGraph
> software and found 3 instances in
> OpenSceneGraph-2.4.0/src/OpenThreads/pthreads/ PThread.c++ where calls of
> this sort are being made.  I put printouts in those places to check on what
> is going on.  I found that only one call to pthread_setaffinity_np was being
> run in SetProcessorAffinityOfCurrentThread(unsigned int cpunum) -- see
> below.  A short code fragment from SetProcessorAffinityOfCurrentThread
> follows which shows my printout.
>
> #if defined(HAVE_PTHREAD_SETAFFINITY_NP)
>   std::cout << "SetProcessorAffinityOfCurrentThread cpunum=" << cpunum
> << " sizeof(cpumask)=" << sizeof(cpumask) << std::endl;
>   pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask);
> #elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
>   sched_setaffinity( 0, sizeof(cpumask), &cpumask );
> #elif defined(HAVE_TWO_PARAM_SCHED_SETAFFINITY)
>   sched_setaffinity( 0, &cpumask );
> #endif
> #endif
>
> If I use strace -f -e sched_setaffinity to watch what is happening with
> sched_setaffinity I see (partial output listing follows):
>
> NOTE: usg::Scene using usg default data file path list
> path =
> .:/usr/local/share/OpenSceneGraph/data:/usr/local/share/OpenSceneGraph/data/Env:/usr/local/share/OpenSceneGraph/data/fonts:/usr/local/share/OpenSceneGraph/data/Images:/usr/share/OpenSceneGraph/data:/usr/share/OpenSceneGraph/data/Env:/usr/share/OpenSceneGraph/data/fonts:/usr/share/OpenSceneGraph/data/Images
> camera number: 0
> SetProcessorAffinityOfCurrentThread cpunum=0 sizeof(cpumask)=128
> sched_setaffinity(16718, 128,  { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> 0, 0 }) = 0
> INFO> navigation mode set to umbra
>
> which seems to imply that the call  pthread_setaffinity_np with zero
> processors is causing a problem.
>
> I looked for calls to this function and found the following which explains
> why cpunum is zero!
> ../src/osgViewer/ViewerBase.cpp:137:
>  OpenThreads::SetProcessorAffinityOfCurrentThread(0);
> ../src/osgViewer/ViewerBase.cpp:452:
>  OpenThreads::SetProcessorAffinityOfCurrentThread(0);
>
> What do you, particularly Robert, think?  (More information concerning my PC
> is available.)  How can we fix this?  I am quite happy to run some
> experiments to figure this out.
>
> Ralph
>
>
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hi Wojtek,

Ok, now I think I understand - I will submit fix for this case or if You 
prefer you may do it. Basically we would want to add setter and getter 
for the flag which will turn off render bin override, right ?


Hmmm... I added an osg::AlphaFunc with comparison GL_GREATER 0.0 to the 
root of my scene graph, and it works well. So if this is the expected 
behavior, perhaps the ShadowedScene could have this osg::AlphaFunc by 
default?


shadowedScene->getOrCreateStateSet()->setAttributeAndModes(
new osg::AlphaFunc(osg::AlphaFunc::GREATER, 0.0),
osg::StateAttribute::ON);

Just hypothetically, for the same end result, what would be faster:
A) overriding the renderbins and using an AlphaFunc
B) disabling the override on the renderbin

(I suspect A, but I'm not that familiar with AlphaFunc)

I think it's expected that objects with textures which have texels at 
alpha=0.0 will have holes in their shadows. So we should either document 
this clearly, or set it by default, as it wasn't at all obvious to me, 
at least.


Thanks,

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] OpenThreads/pthreads & OpenMP on RHEL5.2

[Ralph R. Peters]

Hi,

I will try to be much more concise! :-)

The problem appears to be that 
SetProcessorAffinityOfCurrentThread(unsigned int cpunum) is always being 
called with a cpunum value of zero.  More information follows.


I am trying to use OpenMP with an application that uses OpenScenGraph.  
When OpenMP runs it says that there is only 1 CPU available on an 8 
processor PC.


After numerous exchanges with jakub (thread may be found at 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586), it appears that a 
call to sched_setaffinity, or its "wrapper"  pthread_setaffinity_np, is 
setting the number of processors available to 1 on my PC.


After a fair amount of looking around, I dug deep into OpenSceneGraph 
software and found 3 instances in 
OpenSceneGraph-2.4.0/src/OpenThreads/pthreads/ PThread.c++ where calls 
of this sort are being made.  I put printouts in those places to check 
on what is going on.  I found that only one call to 
pthread_setaffinity_np was being run in 
SetProcessorAffinityOfCurrentThread(unsigned int cpunum) -- see below.  
A short code fragment from SetProcessorAffinityOfCurrentThread follows 
which shows my printout.


#if defined(HAVE_PTHREAD_SETAFFINITY_NP)
   std::cout << "SetProcessorAffinityOfCurrentThread cpunum=" << 
cpunum << " sizeof(cpumask)=" << sizeof(cpumask) << std::endl;

   pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask);
#elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
   sched_setaffinity( 0, sizeof(cpumask), &cpumask );
#elif defined(HAVE_TWO_PARAM_SCHED_SETAFFINITY)
   sched_setaffinity( 0, &cpumask );
#endif
#endif

If I use strace -f -e sched_setaffinity to watch what is happening with 
sched_setaffinity I see (partial output listing follows):


NOTE: usg::Scene using usg default data file path list
 path = 
.:/usr/local/share/OpenSceneGraph/data:/usr/local/share/OpenSceneGraph/data/Env:/usr/local/share/OpenSceneGraph/data/fonts:/usr/local/share/OpenSceneGraph/data/Images:/usr/share/OpenSceneGraph/data:/usr/share/OpenSceneGraph/data/Env:/usr/share/OpenSceneGraph/data/fonts:/usr/share/OpenSceneGraph/data/Images

camera number: 0
SetProcessorAffinityOfCurrentThread cpunum=0 sizeof(cpumask)=128
sched_setaffinity(16718, 128,  { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0 }) = 0

INFO> navigation mode set to umbra

which seems to imply that the call  pthread_setaffinity_np with zero 
processors is causing a problem.


I looked for calls to this function and found the following which 
explains why cpunum is zero!
../src/osgViewer/ViewerBase.cpp:137:
OpenThreads::SetProcessorAffinityOfCurrentThread(0);
../src/osgViewer/ViewerBase.cpp:452:
OpenThreads::SetProcessorAffinityOfCurrentThread(0);


What do you, particularly Robert, think?  (More information concerning 
my PC is available.)  How can we fix this?  I am quite happy to run some 
experiments to figure this out.


Ralph



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

Re: [osg-users] Advice on interacting with osgShadow

[Wojciech Lewandowski]

Hi J-S,

No, they won't be solid. As they are not solid in for trees drawn in 
island scene. But you have to use alpha ref. On the other hand if your 
transparency does not use alpha ref and sets Z-values it will still be 
solid even if color buffer would end transparent.


Alpha ref? What's that? (I'm showing my ignorance, but all I know is that 
our objects just have textures with alpha=0 for some texels - I don't know 
anything about alpha ref)




Sorry for being imprecise. By alpha ref I meant using osg::AlphaFunc to 
discard pixels with alpha lower or equal to reference value. I think that 
OpenGL default is 0.0.


So I must admit I don't exactly understand why turning blending may 
change depth values in shadow map. Maybe its not blending but override on 
rendering bins ? I use only one bin to render shadow map - is this the 
reason of your problems ?


It's true that I was oversimplifying. I always put blending and renderbin 
settings in the same bucket as normally they're used together... You're 
absolutely right, it's the renderbin override that causes the shadows of 
my chain link fences (and other objects with textures having some texels 
alpha=0) to be totally opaque.


So coming back to what you said above, what would be the right solution? 
Is there a way to fix our models so that I don't have to comment out the 
renderbin override in StandardShadowMap.cpp?


Otherwise, I'd submit a setter/getter control for that particular setting. 
It's necessary in our situation.




I see. Maybe AlphaFunc is selectively turned on by Transparent bins  and 
turned off  by Opaque bins and maybe thats why you see the difference when 
your StateSets do not have AlphaFunc set explicitly. I must admit that we 
usually set AlphaFunc in our datasbases thts probably the reason I have not 
noticed this problem yet.


Ok, now I think I understand - I will submit fix for this case or if You 
prefer you may do it. Basically we would want to add setter and getter for 
the flag which will turn off render bin override, right ?


Cheers,
Wojtek


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

Re: [osg-users] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hi David,


Thanks for the help.


My pleasure.

While I'm here, is there any reason why the shaded objects shouldn't do 
the TexGen in a vertex shader?


They do... :-)

Thinking about it though, I suppose that setting shadowCast to false on 
an intermediate node between the mirror and the reflected objects 
prevents the cull traverse from ever finding them, so they don't cast 
shadows twice. Sounds right? Although I'm still a bit uneasy about what 
the mirror might make of the repeated cull traverse attempts... I 
suppose I had just better try it out rather than blather on and on.


About your mirror problem, I admit I haven't seen this case. Your 
solution (getting the shadow map texture and applying it to nodes not 
under the ShadowedScene) might be the best way, I don't know. I have the 
opinion that adding too many multiple traversal paths can make things 
hard to understand when debugging why something is not rendering 
correctly. That's up to you of course.


But thanks for explaining, at least it shows me that I have to keep an 
open mind to situations that I haven't seen :-)


I would prefer an OSG wide setting that would be user controlled that 
set up some sort of relationship between default texture types and 
units(e.g. 0=DIFFUSE, 1=SHADOW, 2=NORMAL, 3=SPECULAR etc.) , so that all 
the loaders that cared would be consistent (e.g. 3ds, obj), and that the 
shadow map could refer to, and that any shader set could read sampler2D 
values from, etc. No idea where this would go, though.


I agree that all this is more complex than it should be. There are a few 
things OSG could do to simplify the art pipeline management, but I don't 
think it's really under its jurisdiction to do so. Applications will 
have different requirements, and even though some can be generalized, in 
many cases you want to try out different strategies in order to find the 
one that works best given your hardware and application-specific 
bottlenecks.


Now, an add-on library could be written that would help unify the art 
pipeline. Things like models, textures, mapping of textures to texture 
units, shader management, shader generation from chunks of shader code, 
effect management, etc. could be made much simpler and more 
user-friendly. But as I said, I don't think it's OSG's job to do this. 
OSG provides a framework, and this is a bit too domain-specific IMHO.


But it's a pretty large discussion that's bound to have widely different 
opinions from different people... I have no authority on OSG (other than 
sending submissions to suggest new directions) so I would be interested 
in Robert's opinion on the matter.


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] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hi Wojtek,

No, they won't be solid. As they are not solid in for trees drawn in 
island scene. But you have to use alpha ref. On the other hand if your 
transparency does not use alpha ref and sets Z-values it will still be 
solid even if color buffer would end transparent. 


Alpha ref? What's that? (I'm showing my ignorance, but all I know is 
that our objects just have textures with alpha=0 for some texels - I 
don't know anything about alpha ref)


So I must admit I 
don't exactly understand why turning blending may change depth values in 
shadow map. Maybe its not blending but override on rendering bins ? I 
use only one bin to render shadow map - is this the reason of your 
problems ?


It's true that I was oversimplifying. I always put blending and 
renderbin settings in the same bucket as normally they're used 
together... You're absolutely right, it's the renderbin override that 
causes the shadows of my chain link fences (and other objects with 
textures having some texels alpha=0) to be totally opaque.


So coming back to what you said above, what would be the right solution? 
Is there a way to fix our models so that I don't have to comment out the 
renderbin override in StandardShadowMap.cpp?


Otherwise, I'd submit a setter/getter control for that particular 
setting. It's necessary in our situation.


Thanks as always Wojtek,

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] Advice on interacting with osgShadow

[David Spilling]

Dear J-S,

Thanks for the help.

If you're using the ViewDependentShadow techniques, they already disable
> shaders while rendering the shadow pass.


Ah - I hadn't spotted that in the code yet. So no problems there then.

While I'm here, is there any reason why the shaded objects shouldn't do the
TexGen in a vertex shader?

I would subclass and just add a public getter for the texture since it's
> protected. Pretty simple.


Sounds like a good idea.


> I wonder what the "good architectural reasons" are, but let's not get into
> that discussion :-)
>

No, lets, as you might spot something I hadn't considered. Lets say I have a
node representing a mirror, which uses an RTT technique to draw reflections.
In a similar way to the shadows, the objects to be reflected are placed as
children of the mirror, in addition to their normal position in the SG.  The
mirror puts various transforms and clips on the reflection, so that the
reflected image is correct.

Now, the mirror is itself a shadowCaster, as are the objects it is trying to
reflect. If I put the objects and the mirror as children of the
shadowTechnique node, then the non-mirror objects cast shadows twice - once
in their normal orientation, and once in their reflected-child-of-mirror
orientation, which is wrong.

Thinking about it though, I suppose that setting shadowCast to false on an
intermediate node between the mirror and the reflected objects prevents the
cull traverse from ever finding them, so they don't cast shadows twice.
Sounds right? Although I'm still a bit uneasy about what the mirror might
make of the repeated cull traverse attempts... I suppose I had just better
try it out rather than blather on and on.

...multitexturing


Your comments agreed.


I think that the issue is a little bit more far ranging to manage in a
generic application way. For example, the set of incoming models I have to
draw unfortunately comes in with texture units all over the place. (e.g.
some have diffuse = 0, normal = 1, specular = 2, some have diffuse = 0,
specular = 1, no normal). This is in part because file formats that do
specify texture types (diffuse, normal, gloss etc.) like obj and 3ds, don't
specify which texture unit they should occupy. Openflight, in contrast,
specifies which textureUnit the incoming map actually is. Hence we end up
with a bit of a mishmash, thanks to not having an art path that is
historically well controlled, and receiving assets from various sources.

Therefore it is tricky for me to say that texture unit 0 = shadows and 1 =
diffuse, because it is hard to guarantee that in the general case. The
solution I'm likely to resort to is to say shadow = 7, and then if the model
comes in with anything in tex unit 7 then...well.. it has been warned. Can't
say that's happened often though. [Although one might be using tangentspace
generators to push normals into attributes 6,7,15, which could conceivably
get mangled with shadows's texgen (in the case of shadow=7) which means that
7 is a bad choice... and so on.] Not ideal.

I would prefer an OSG wide setting that would be user controlled that set up
some sort of relationship between default texture types and units(e.g.
0=DIFFUSE, 1=SHADOW, 2=NORMAL, 3=SPECULAR etc.) , so that all the loaders
that cared would be consistent (e.g. 3ds, obj), and that the shadow map
could refer to, and that any shader set could read sampler2D values from,
etc. No idea where this would go, though.


Thanks again for the pointers.

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

Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes

[Aitor Arrieta]

Hi Paul

I don't know but maybe... Would it be easier to combine both textures
(head and body) and create a new obj file using this new texture? You
should take into account that I have never done something like that (I
don't know even which program should I use)

Regards,

Aitor





- Mensaje original 
De: Paul Martz <[EMAIL PROTECTED]>
Para: OpenSceneGraph Users 
Enviado: martes, 14 de octubre, 2008 17:38:17
Asunto: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes


The code I posted will work for the use case you describe. Indices are 
part of the PrimitiveSet; assign a different PrimitiveSet (with different 
indices) to each Geometry and they will index into the same vertex 
array.
   -Paul
 



 From: [EMAIL PROTECTED]  [mailto:[EMAIL PROTECTED] On Behalf Of Aitor  Arrieta
Sent: Tuesday, October 14, 2008 9:05 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Sharing Vertex Arrays  between Geometry Nodes


Hi Paul

Thanks a lot for your reply, but unfortunately I think  that my question is not 
as simple as you think. Sorry because it was my fault  as I did not explain 
myself correctly.

The problem is that I must have  a single vertex arrays for many different 
geometries but each geometry uses  only a part of this vertex array.. That is, 
imagine a single vertex array with  indices from 1 to 100. I should have 
geometry 1 with indices from 1 to 10,  geometry 2 with indices from 11 to 20, 
etc.. But all of them sharing the same  vertex array, which is used to do some 
other things.

Sorry for my bad  explanation and thanks again for your reply.

Best  regards,

Aitor






-  Mensaje original 
De: Paul Martz  <[EMAIL PROTECTED]>
Para: OpenSceneGraph Users  
Enviado: martes, 14 de octubre,  2008 16:54:00
Asunto: Re: [osg-users] Sharing Vertex Arrays between  Geometry Nodes


osg::Geometry* geom0 = new osg::Geometry;
osg::Geometry* geom1 = new osg::Geometry;
osg::Vec3Array* verts = osg::Vec3Array;
geom0->setVertexArray(  verts );
geom1->setVertexArray(  verts );
 
Hope that  helps.
-Paul



 From: [EMAIL PROTECTED]  [mailto:[EMAIL PROTECTED] On Behalf Of Aitor Arrieta
Sent: Tuesday, October 14, 2008 8:39  AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Sharing Vertex Arrays between Geometry 
Nodes


Hi all,
 
I am developing an application in which I have to share the same vertex  array 
between different nodes in order to apply a different texture to each  of them. 
I know that this is possible to do because I have  read it. However, I am a 
beginner in the osg world and I am not able to find  the way to do it.
 
Someone told me that I could use the same geode having different  geometries 
but how can I specify a vertex array for a geode? As  far as I know this is 
impossible, is not it?
I have also read something about using the DrawElementsUShort primitive  but 
how should I use it?
 
My question is: is there any example of sharing vertex arrays  between geometry 
nodes anywhere? Or has anybody done this before? In  short, could anybody 
please help me with this task?
 
Thank you very much in advance.
 
Regards,
 
Aitor


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

Re: [osg-users] Advice on interacting with osgShadow

[Wojciech Lewandowski]

Hi David, J-S

As usual, Great thanks to J-S for doing my work ;-) But I would like to 
clarify the blending issue you mentioned.


In the case where the objects that are casting shadows have expensive 
fragment shaders, I would prefer to turn these shaders off so that we 
just get a quick depth only pass. Fortunately my expensive shaders sit 
above the object's scenegraph, and so I can envisage an approach in which 
my unshaded object has two parent nodes (say A and B), which are both 
children of the shadow node. A would have the castsShadow mask and a 
cheap shader, and B would have the receivesShadow mask and the expensive 
shader.


Does this sound like an acceptable approach?


If you're using the ViewDependentShadow techniques, they already disable 
shaders while rendering the shadow pass. (note that they also disable 
blending, which is a problem if you have objects which are solid but whose 
textures give holes, like a chain link fence for example - the object's 
shadow will look completely solid instead of showing the holes as it 
should)


No, they won't be solid. As they are not solid in for trees drawn in island 
scene. But you have to use alpha ref. On the other hand if your transparency 
does not use alpha ref and sets Z-values it will still be solid even if 
color buffer would end transparent. So I must admit I don't exactly 
understand why turning blending may change depth values in shadow map. Maybe 
its not blending but override on rendering bins ? I use only one bin to 
render shadow map - is this the reason of your problems ?


Cheers,
Wojtek


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

Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes

[Jean-Sébastien Guay]

Hi Aitor,

I can't use your code because I don't create new geometries. Instead of 
this, I get an osg::geode from an obj file. At this moment, I can only 
get a single geometry from the geode and apply a single texture to it. 
But this is not what I want.


The obj file represents a human figure, and I would like to separate the 
head from the body because they have different textures. I know which 
vertices are from the head and which ones for the body so this won't be 
a problem in this case. The problem is that they must share the same 
vertex array, which is used to do some morph tasks. My question is, how 
can I create two different geometries starting from the same geode and 
sharing the same vertex array? Is this possible or not?


Your life would be simpler if you could get a correct model as soon as 
you load it, instead of trying to massage it (and how you massage it 
might change from one model to the next).


However, yes, what you ask is possible. You can traverse your model to 
the Geode which contains the Geometry, then create new Geometry objects, 
attach them to the Geode, and remove the original one. The new Geometry 
objects can reference the original one's vertex arrays, and then when 
you remove the original one from the Geode the vertex arrays won't be 
deleted because other Geometry objects reference them.


Then on your new Geometry object(s), you can do what you want. So you 
could add primitive sets for the correct vertices to be used, you could 
add texture coordinate arrays (or reuse those from the original Geometry 
object), etc.


As I said, it's a lot of trouble. If you can get a valid model right 
away, your life will be easier. It's not the kind of thing that's best 
done in code... Modeling tools are specialized in manipulating these 
kinds of things...


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] Statistics display without needing a GUIEventHandler

[Jean-Sébastien Guay]

Hi Alex,


I am getting closer now; one thing I still cannot manage to do is display GPU
stats correctly. This works with the original StatHandler, but not with my
modified one. This obviously depends on whether the GraphicsContexts of all
Cameras of the hosting Viewer (just one in my case) support the TimerQuery GL
extension, which they obviously do in general (since the original StatsHandler
shows the stats), but not at the time I check in the modified version. This
seems to be a question of call timing. From what point of rendering progress on
does the GraphicsContext of a Camera support a GL extension, and why does this
not work earlier?


If you're checking for an OpenGL extension, you need to be in a thread 
that has a graphics context valid, or use a pre/postdraw camera callback 
to do the check. Maybe call the initialize method in a pre-draw callback 
which you would put on your main camera?


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] Sharing Vertex Arrays between Geometry Nodes

[Aitor Arrieta]

Hi Paul

I don't know if this is a stupid question or not but I'm already going crazy... 

I can't use your code because I don't create new geometries. Instead of this, I 
get an osg::geode from an obj file. At this moment, I can only get a single 
geometry from the geode and apply a single texture to it. But this is not what 
I want.

The obj file represents a human figure, and I would like to separate the head 
from the body because they have different textures. I know which vertices are 
from the head and which ones for the body so this won't be a problem in this 
case. The problem is that they must share the same vertex array, which is used 
to do some morph tasks. My question is, how can I create two different 
geometries starting from the same geode and sharing the same vertex array? Is 
this possible or not?

Thanks a lot Paul and sorry for the inconveniences

Regards,

Aitor








- Mensaje original 
De: Paul Martz <[EMAIL PROTECTED]>
Para: OpenSceneGraph Users 
Enviado: martes, 14 de octubre, 2008 17:38:17
Asunto: Re: [osg-users] Sharing Vertex Arrays between Geometry Nodes


The code I posted will work for the use case you describe. Indices are 
part of the PrimitiveSet; assign a different PrimitiveSet (with different 
indices) to each Geometry and they will index into the same vertex 
array.
   -Paul
 



 From: [EMAIL PROTECTED]  [mailto:[EMAIL PROTECTED] On Behalf Of Aitor  Arrieta
Sent: Tuesday, October 14, 2008 9:05 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Sharing Vertex Arrays  between Geometry Nodes


Hi Paul

Thanks a lot for your reply, but unfortunately I think  that my question is not 
as simple as you think. Sorry because it was my fault  as I did not explain 
myself correctly.

The problem is that I must have  a single vertex arrays for many different 
geometries but each geometry uses  only a part of this vertex array.. That is, 
imagine a single vertex array with  indices from 1 to 100. I should have 
geometry 1 with indices from 1 to 10,  geometry 2 with indices from 11 to 20, 
etc. But all of them sharing the same  vertex array, which is used to do some 
other things.

Sorry for my bad  explanation and thanks again for your reply.

Best  regards,

Aitor






-  Mensaje original 
De: Paul Martz  <[EMAIL PROTECTED]>
Para: OpenSceneGraph Users  
Enviado: martes, 14 de octubre,  2008 16:54:00
Asunto: Re: [osg-users] Sharing Vertex Arrays between  Geometry Nodes


osg::Geometry* geom0 = new osg::Geometry;
osg::Geometry* geom1 = new osg::Geometry;
osg::Vec3Array* verts = osg::Vec3Array;
geom0->setVertexArray(  verts );
geom1->setVertexArray(  verts );
 
Hope that  helps.
-Paul



 From: [EMAIL PROTECTED]  [mailto:[EMAIL PROTECTED] On Behalf Of Aitor Arrieta
Sent: Tuesday, October 14, 2008 8:39  AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Sharing Vertex Arrays between Geometry 
Nodes


Hi all,
 
I am developing an application in which I have to share the same vertex  array 
between different nodes in order to apply a different texture to each  of them. 
I know that this is possible to do because I have  read it. However, I am a 
beginner in the osg world and I am not able to find  the way to do it.
 
Someone told me that I could use the same geode having different  geometries 
but how can I specify a vertex array for a geode? As  far as I know this is 
impossible, is not it?
I have also read something about using the DrawElementsUShort primitive  but 
how should I use it?
 
My question is: is there any example of sharing vertex arrays  between geometry 
nodes anywhere? Or has anybody done this before? In  short, could anybody 
please help me with this task?
 
Thank you very much in advance.
 
Regards,
 
Aitor


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

[osg-users] Limits for OpenSceneGraph 3D Models

[Adrian Egli OpenSceneGraph (3D)]

Hi all,

I am working on a feature sheet for OpenSceneGraph based applications. It
would be helpfull, if we better understand some
limits for most of the systems we have, or we like to support.

If we assume that we have elder systems OpenGL 1

: UV limits / Multi-Texture layers
: Texture maps / Env. Map etc
: Texture Size / Resolution
NO : GLSL
: Polygons for 60FPS
: ...


If we assume that we have common systems OpenGL 2

: UV limits / Multi-Texture layers
: Texture maps / Env. Map etc
: Texture Size / Resolution
YES : GLSL
: Polygons for 60FPS
: ...


if we have latest systems OpenGL 3


: UV limits / Multi-Texture layers
: Texture maps / Env. Map etc
: Texture Size / Resolution
YES : GLSL
: Polygons for 60FPS
: ...

Or how should we work out our limits.. ?

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] Statistics display without needing a GUIEventHandler

[Alexander Löffler]

Hi Mattias,

Mattias Helsing wrote:
> I do a similar thing with the HelpHandler. I subclassed the
> HelpHandler like below.
> I then instantiate it and add it to the Viewer (and a osgWidget
> menuitem). Then I call initialize on it *before* viewer.run() but
> *after* viewer.realize()

Thanks a lot for your reply. Your solution is similar to what I already had for
my custom StatsHandler, except that I had to include a lot more in the
initialize method, namely the entire switch statement from
StatsHandler::handle() that distinguishes between the different StatsTypes. I
had to change that, too, such that it does not depend on having called the parts
for the previous types when switching on a later type.

I am getting closer now; one thing I still cannot manage to do is display GPU
stats correctly. This works with the original StatHandler, but not with my
modified one. This obviously depends on whether the GraphicsContexts of all
Cameras of the hosting Viewer (just one in my case) support the TimerQuery GL
extension, which they obviously do in general (since the original StatsHandler
shows the stats), but not at the time I check in the modified version. This
seems to be a question of call timing. From what point of rendering progress on
does the GraphicsContext of a Camera support a GL extension, and why does this
not work earlier?

Alex.

> //! Simple wrapper of the osgViewer::HelpHandler to let me initialize
> it before first invocation of it's \c handle()
> struct MyHelpHandler : public osgViewer::HelpHandler
> {
> MyHelpHandler(osg::ApplicationUsage* au) : osgViewer::HelpHandler(au) {};
> void initialize(osgViewer::ViewerBase* viewer)
> {
> if (!_initialized && viewer)
> {
> setUpHUDCamera(viewer);
> setUpScene(viewer);
> if(_camera.valid())
> {
> _camera->setNodeMask(0);
> _helpEnabled = false;
> }
> }
> }
> };
> 
> 
> On 10/15/08, Alexander Löffler <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I am trying to display on-screen statistics as provided by the
>> osgViewer::StatsHandler without the need for doing this via handling the key
>> presses first. That is, I want to add a command line options to my
>> application
>> to either display statistics just as frame rate, full stats, or not at all.
>>
>> Is there an easy way to do that with the available StatsHandler? I tried
>> subclassing from the handler with the option to set the StatsType initially.
>> Currently without success, as there seem to be lots of dependencies of what
>> parts of OSG have to be set up before collecting of stats is actually
>> possible.
>> For example, some cameras seem not yet to be set up when I instantiate my
>> handler, collecting GPU stats is disabled in my HUD, etc..
>>
>> Has anyone ever done something similar before?
>>
>> Thanks a lot in advance,
>> Alex.
>> ___
>> 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] Which Manipulator to simulate Submarine Motions?

[Gordon Tomlinson]

You’re going to have to write your own manipulator for your scenario

 

Pick one of the current ones to give you the template them setup your motion
and inputs as you need them for your requirements

 

 

 

__
Gordon Tomlinson 

  [EMAIL PROTECTED]
IM:   [EMAIL PROTECTED]
  www.vis-sim.com
 www.gordontomlinson.com 

__

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ümit Uzun
Sent: Wednesday, October 15, 2008 9:39 AM
To: OpenSceneGraph Users
Subject: [osg-users] Which Manipulator to simulate Submarine Motions?

 

Hi All,

I want to simulate a submarine motion in the sea. So I have look at the
osgGA namespace for usable manipulator for this purpose but couldn't find.

I want to use a camera in the sea as a FPS manipulator. I need a mouse and
keyboard ability. With using mouse I choose the forward view and with
keyboard arrow keys I manipulate throttle on or off and etc.

I have searched the archive and find a bug or drawback of mouse using
(http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/32161/matc
h=manipulator+fps), and I think there is no solution yet about re-centering
the mouse.

So What can I do for simulating submarine? Any advices will welcome with
appreciate. 

Best Regards.

Umit Uzun

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

Re: [osg-users] Advice on interacting with osgShadow

[Jean-Sébastien Guay]

Hi David,

In the case where the objects that are casting shadows have expensive 
fragment shaders, I would prefer to turn these shaders off so that we 
just get a quick depth only pass. Fortunately my expensive shaders sit 
above the object's scenegraph, and so I can envisage an approach in 
which my unshaded object has two parent nodes (say A and B), which are 
both children of the shadow node. A would have the castsShadow mask and 
a cheap shader, and B would have the receivesShadow mask and the 
expensive shader.


Does this sound like an acceptable approach? 


If you're using the ViewDependentShadow techniques, they already disable 
shaders while rendering the shadow pass. (note that they also disable 
blending, which is a problem if you have objects which are solid but 
whose textures give holes, like a chain link fence for example - the 
object's shadow will look completely solid instead of showing the holes 
as it should)


I don't remember if the osgShadow::ShadowMap does the same, but it 
should. It makes sense to disable as much as possible for the shadow 
pass since all you want is depth information.


If you find that your shaders are still being called, then yes, what you 
suggest above is reasonable.


For good architectural reasons, I can not place one of my desired shadow 
receiving items underneath the shadow node. Hence I would like access to 
the shadow texture, so that it can bind it explicitly. Would allowing 
the ShadowTechnique classes to expose their RTT shadow texture so that 
something else can also bind it be a problem in general? At the moment 
its protected. Is this something worth submitting or should I just 
subclass/rewrite?


I would subclass and just add a public getter for the texture since it's 
protected. Pretty simple. I wonder what the "good architectural reasons" 
are, but let's not get into that discussion :-)


I realise that multitextured items aren't really supported by the 
out-of-the-box shadow techniques, but at the moment the handling of the 
shadow texture units and "base" texture units seems a little clumsy, and 
difficult to extend. Does anybody else have any experience of using 
shadows with objects that are already multitextured (e.g. diffuse and 
normal mapped)? It looks to me that if you have any other shaders 
knocking around your scenegraph, you need to subclass ShadowTechnique to 
support your usage model. Is that what people have done in the past?


I don't really see why you can't just change the shaders, making sure 
your new shaders use the same uniform and sampler names and do the right 
calculations for shadows, while doing multitexturing.


For osgShadow::ShadowMap, as long as the base texture is in unit 0 and 
the shadow map in unit 1, you're OK, so you can use units 2, 3, 4... for 
other textures. In the case of the ViewDependentShadow techniques, you 
can change the texture units used by the base texture and shadow 
texture, which does a search-and-replace in the shader code, so you 
could use units 0, 1, 2 as textures and 3 as shadow map as long as you 
set it that way in the ShadowTechnique.


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] Which Manipulator to simulate Submarine Motions?

[Ümit Uzun]

Hi All,

I want to simulate a submarine motion in the sea. So I have look at the
osgGA namespace for usable manipulator for this purpose but couldn't find.

I want to use a camera in the sea as a FPS manipulator. I need a mouse and
keyboard ability. With using mouse I choose the forward view and with
keyboard arrow keys I manipulate throttle on or off and etc.

I have searched the archive and find a bug or drawback of mouse using (
http://article.gmane.org/gmane.comp.graphics.openscenegraph.user/32161/match=manipulator+fps),
and I think there is no solution yet about re-centering the mouse.

So What can I do for simulating submarine? Any advices will welcome with
appreciate.

Best Regards.

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

Re: [osg-users] Reporting Builds

[Jean-Sébastien Guay]

Hi Mathieu,


This new feature (BUILD_DASHBOARD_REPORTS
option defaulted to OFF) will permit to some people willing to share
some build time on various platforms to submit compilation results on
a regular if not automatic basis.


Interesting!

One question I have is, if CMake automatically updates the working copy 
(to 00:00 for Nightly, or to right now for continuous), does it then 
re-run itself to regenerate build files if some source files were added? 
If so, what happens if there's an error when generating the build files 
(error in the CMakeLists.txt or something like that)?


As for build scripts, perhaps the one you have on the wiki could be 
included with the OSG sources in some subdirectory, and another could be 
developed for Windows that would do something similar. I'd be willing to 
make my work machine build nightly on Windows if we can get someone more 
versed in Windows batch programming make a good batch script that would 
do this.


I think setting up this kind of thing (which IMHO is unobtrusive, since 
it runs at night when I'm not working) will give us more information 
about the status or general health of the SVN (and any branches we want 
to monitor) and thus would reduce the calls to test current SVN 
manually, and increase confidence that at least the releases will build 
correctly on various platforms.


Now if we could convince Matthias to set up nightly builds on the large 
number of less used platforms he apparently has access to ;-)


Thanks for this addition,

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] PDF rendering inside OSG

[Jean-Sébastien Guay]

Hi Jeremy,


Okay, so, from the man who brought you all kinds of other useless
software [...]


Hey, with an introduction like that how can you possibly go wrong!

> comes PDF rendering directly to an osg::Image (more

specifically, osgCairo::Image) using osgCairo + poppler.

Obligatory Screenshot:

http://the-bob.org/~jlmoles/osgCairo-pdf.png

...this is part of the GLSL presentation Mike gave...


That's extremely cool.

BTW, I'm still committed to getting your stuff (osgCairo and osgPango) 
to work on Win32, just been a little sidetracked. It's for a personal 
project so delays like that are to be expected... :-)


Good work yet again,

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] avoid writing some node on osgDB::writeNodeFile

[David Callu]

Hi Alexandre

You can just copy the Scene Graph structure (osg::Node, osg::Group, ...)
and share every other thing (StateSet, Drawable, texture, ...)
You can specify which object to share and which to clone with the
osg::CopyOp class.


HTH
David Callu

2008/10/6 amalric alexandre <[EMAIL PROTECTED]>

> Hi osg-users,
>
> I would have know if it was possible to avoid to write some node in a scene
> when calling osgDB::writeNodeFile on the current scene.
>
> Let's assume I got a group of nodes and I wand to save this group on disk
> without saving some chosen nodes from the group. But I don't want to modify
> the group because I need it to stay the same.
>
> My first choice was to make a copy from the group, modifying the copy
> keeping the original and writing the copy. But I think it's a bad choice
> because I got very big nodes (300Mo and more) and making a copy use more
> memory.
>
> If someone has a great idea, please let me know
>
> Thank you,
>
> --
> Alexandre AMALRIC   Ingénieur R&D
> ===
> PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille
> http://www.pixxim.fr
>
> ___
> 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] Advanced Particles

[Roman Grigoriev]

Thanx Robert! All works fine 
Now I try to implement aircraft flares 
Could you please advise me how to make smoke trails after flares 
Can I attach trail  to particle system that simulate flare's trails?
Thanx in advance
Bye
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert
Osfield
Sent: Wednesday, October 15, 2008 1:02 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Advanced Particles

HI Roman,

You need to place the ParticleSystem at the root of your scene graph,
and the emit on the leaf of the scene graph that you wish to move
around.

Have a look at the osgparticleeffects example as it has code in it
which illustrates what has to be done for moving emiters - note the
case where the moving model intersections are detected and handled.

Robert.

On Wed, Oct 15, 2008 at 6:35 AM, Roman Grigoriev <[EMAIL PROTECTED]>
wrote:
> Hi guys!
>
> I've tested osg particle system and have question how to make independent
> from emitter particles.
>
> I explain the situation. If I have static emitter all works fine - gravity
> and friction operator but when emitter moves or rotates all movement is
> relative from emitter but I think that emitter should only describe
starting
> impulse and then particle moves under physics law in world system and not
in
> relative emitter system. If there are any examples how to make this type
of
> particles please let me know
>
> Thanx in advance
>
> Bye
>
>
>
> ___
> 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] Advice on interacting with osgShadow

[David Spilling]

Dear All,

I'm just picking up osgShadow, and have a couple of questions that I would
appreciate some advice on. The intention is to use one of the ShadowMap type
methods.

Case1 : Shadow casters already have expensive fragment shaders

In the case where the objects that are casting shadows have expensive
fragment shaders, I would prefer to turn these shaders off so that we just
get a quick depth only pass. Fortunately my expensive shaders sit above the
object's scenegraph, and so I can envisage an approach in which my unshaded
object has two parent nodes (say A and B), which are both children of the
shadow node. A would have the castsShadow mask and a cheap shader, and B
would have the receivesShadow mask and the expensive shader.

Does this sound like an acceptable approach? I have read things about using
uniforms passed into the shader to control whether it is operating or not,
but the above seemed a little simpler. Does this already happen via the
shadow camera's use of GL_DEPTH

Case2 : Shadow receivers musn't be children of the shadow node.

For good architectural reasons, I can not place one of my desired shadow
receiving items underneath the shadow node. Hence I would like access to the
shadow texture, so that it can bind it explicitly. Would allowing the
ShadowTechnique classes to expose their RTT shadow texture so that something
else can also bind it be a problem in general? At the moment its protected.
Is this something worth submitting or should I just subclass/rewrite?

Case3 : Multitextured shadow receivers

I realise that multitextured items aren't really supported by the
out-of-the-box shadow techniques, but at the moment the handling of the
shadow texture units and "base" texture units seems a little clumsy, and
difficult to extend. Does anybody else have any experience of using shadows
with objects that are already multitextured (e.g. diffuse and normal
mapped)? It looks to me that if you have any other shaders knocking around
your scenegraph, you need to subclass ShadowTechnique to support your usage
model. Is that what people have done in the past?

Thanks,

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

Re: [osg-users] Statistics display without needing a GUIEventHandler

[Mattias Helsing]

Hi Alex,

I do a similar thing with the HelpHandler. I subclassed the
HelpHandler like below.
I then instantiate it and add it to the Viewer (and a osgWidget
menuitem). Then I call initialize on it *before* viewer.run() but
*after* viewer.realize()

hope this helps
Mattias

//! Simple wrapper of the osgViewer::HelpHandler to let me initialize
it before first invocation of it's \c handle()
struct MyHelpHandler : public osgViewer::HelpHandler
{
MyHelpHandler(osg::ApplicationUsage* au) : osgViewer::HelpHandler(au) {};
void initialize(osgViewer::ViewerBase* viewer)
{
if (!_initialized && viewer)
{
setUpHUDCamera(viewer);
setUpScene(viewer);
if(_camera.valid())
{
_camera->setNodeMask(0);
_helpEnabled = false;
}
}
}
};


On 10/15/08, Alexander Löffler <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am trying to display on-screen statistics as provided by the
> osgViewer::StatsHandler without the need for doing this via handling the key
> presses first. That is, I want to add a command line options to my
> application
> to either display statistics just as frame rate, full stats, or not at all.
>
> Is there an easy way to do that with the available StatsHandler? I tried
> subclassing from the handler with the option to set the StatsType initially.
> Currently without success, as there seem to be lots of dependencies of what
> parts of OSG have to be set up before collecting of stats is actually
> possible.
> For example, some cameras seem not yet to be set up when I instantiate my
> handler, collecting GPU stats is disabled in my HUD, etc..
>
> Has anyone ever done something similar before?
>
> Thanks a lot in advance,
> Alex.
> ___
> 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] Edge blending

[su hu]

Hi Robert

Thanks for your reply.

I will see the osghud example and try your method. Thanks.

Best Regards,

Su Hu

2008/10/15 Robert Osfield <[EMAIL PROTECTED]>

> Hi Su Hu,
>
> I haven't personally implemented edge blending yet, but it should be
> straight forward.  All you need to do is render a alpha blending quad
> over the edge of window as a HUD. See the osghud example for
> inspiration.
>
> Robert.
>
> On Wed, Oct 15, 2008 at 9:18 AM, su hu <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > I want to implement edge blending by osg, but I don't know which way is
> > better. Our requirement of edge blending is simple: overlapped area of
> two
> > screens is rectangular.
> >
> > If someone has done it, please give me some advice.
> >
> > Much appreciation to any reply.
> >
> > Regards,
> >
> > Su Hu
> >
> > ___
> > 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] Edge blending

[Robert Osfield]

Hi Su Hu,

I haven't personally implemented edge blending yet, but it should be
straight forward.  All you need to do is render a alpha blending quad
over the edge of window as a HUD. See the osghud example for
inspiration.

Robert.

On Wed, Oct 15, 2008 at 9:18 AM, su hu <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I want to implement edge blending by osg, but I don't know which way is
> better. Our requirement of edge blending is simple: overlapped area of two
> screens is rectangular.
>
> If someone has done it, please give me some advice.
>
> Much appreciation to any reply.
>
> Regards,
>
> Su Hu
>
> ___
> 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] Advanced Particles

[Robert Osfield]

HI Roman,

You need to place the ParticleSystem at the root of your scene graph,
and the emit on the leaf of the scene graph that you wish to move
around.

Have a look at the osgparticleeffects example as it has code in it
which illustrates what has to be done for moving emiters - note the
case where the moving model intersections are detected and handled.

Robert.

On Wed, Oct 15, 2008 at 6:35 AM, Roman Grigoriev <[EMAIL PROTECTED]> wrote:
> Hi guys!
>
> I've tested osg particle system and have question how to make independent
> from emitter particles.
>
> I explain the situation. If I have static emitter all works fine – gravity
> and friction operator but when emitter moves or rotates all movement is
> relative from emitter but I think that emitter should only describe starting
> impulse and then particle moves under physics law in world system and not in
> relative emitter system. If there are any examples how to make this type of
> particles please let me know
>
> Thanx in advance
>
> Bye
>
>
>
> ___
> 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] Edge blending

[su hu]

Hi all,

I want to implement edge blending by osg, but I don't know which way is
better. Our requirement of edge blending is simple: overlapped area of two
screens is rectangular.

If someone has done it, please give me some advice.

Much appreciation to any reply.

Regards,

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

[osg-users] Statistics display without needing a GUIEventHandler

[Alexander Löffler]

Hi,

I am trying to display on-screen statistics as provided by the
osgViewer::StatsHandler without the need for doing this via handling the key
presses first. That is, I want to add a command line options to my application
to either display statistics just as frame rate, full stats, or not at all.

Is there an easy way to do that with the available StatsHandler? I tried
subclassing from the handler with the option to set the StatsType initially.
Currently without success, as there seem to be lots of dependencies of what
parts of OSG have to be set up before collecting of stats is actually possible.
For example, some cameras seem not yet to be set up when I instantiate my
handler, collecting GPU stats is disabled in my HUD, etc..

Has anyone ever done something similar before?

Thanks a lot in advance,
Alex.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org