Re: [osg-users] osgdem segmentation fault

[Robert Osfield]

Hi Mohammed,

Could you run osgdem without the -a option, and also run osgdem within
a debugger so you can get the stack trace where it crashes.

Thanks,
Robert.

On 26 January 2012 00:08, Mohammed Rashad mohammedrasha...@gmail.com wrote:

 osgdem --xx 10 --yy 10 -t ps_texture_16k.tif --xx 10 --yy 10 -d
 ps_height_16k.tif  -l 8 -v 0.1 -o puget.ive -a pegout.osga
 Warning: archive option -a is temporarily disabled, building with archive.
 --xx 10
 --yy 10
 -t ps_texture_16k.tif
 ADD: ps_texture_16k.tif
 loaded layer ps_texture_16k.tif
 --xx 10
 --yy 10
 -d ps_height_16k.tif
 ADD: ps_height_16k.tif
 loaded layer ps_height_16k.tif
 -o puget.ive
 Adding terrainTile
 DataSet::_run() 0 0
 Now checking for plug-in osgPlugins-3.0.0/osgdb_nvtt.so
 DataSet::assignDestinationCoordinateSystem() : assigning first source file
 as the destination coordinate system
 started DataSet::createDestination(8)
 Time for after_reproject 0.08
 DataSet::assignDestinationCoordinateSystem() : assigning first source file
 as the destination coordinate system
 local_extents = xMin() 0.00 163850.00
                 yMin() 0.00 163850.00
 AR=1.00 C1=1 R1=1
 createNewDestinationGraph
 Time for _destinationGraph-computeMaximumSourceResolution() = 0.005384
 Time for createDestinationGraph 0.038835
 Time for after_computeNeighbours 0.005547
 completed DataSet::createDestination(8)
 There are 2 contributing source files:
     ps_height_16k.tif
     ps_texture_16k.tif
 Segmentation fault

 --
 Regards,
    Rashad


 ___
 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] Render to FBO and multiSamples

[Robert Osfield]

Hi Aurelien,

Try using more modest values for the sampleBuffers and samples values
when you are setting up the graphics context.  BTW, you won't need a
multi-sampled graphics context to use multi-sampling on the FBO and
visa-versa, these are decoupled and you can mix and match them.

Robert.

On 25 January 2012 22:10, Aurelien Albert aurelien.alb...@alyotech.fr wrote:
 Hi,

 I use a camera to render my main graph to an FBO.
 Then I render this FBO to screen with another camera and a quad.

 Like this :


 Code:
 Main camera (render to FBO)
 |
 |-- Main graph
 |
 |--- Camera (render to screen)
       |
       |- Quad




 I try to setup multisampling for the main camera :


 Code:
 p_camera-setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
 p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, 
 false, 4, 4);
 p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth, 0, 0, 
 false, 4, 4);




 I also try to set sampleBuffers and samples on the traits before creating 
 context, but all I get is a black screen.

 When I render to screen, MSAA works great, but how to configure it for a FBO 
 target ?

 My textures are created as follow :


 Code:
 // Main color texture
 p_renderTextureColor = new osg::Texture2D();
 p_renderTextureColor-setTextureSize(p_osgViewport-width(), 
 p_osgViewport-height());
 p_renderTextureColor-setInternalFormat(GL_RGBA32F_ARB);
 p_renderTextureColor-setSourceFormat(GL_RGBA);
 p_renderTextureColor-setSourceType(GL_FLOAT);
 p_renderTextureColor-setFilter(osg::Texture2D::MIN_FILTER, 
 osg::Texture2D::NEAREST);
 p_renderTextureColor-setFilter(osg::Texture2D::MAG_FILTER, 
 osg::Texture2D::NEAREST);
 p_renderTextureDepth-setWrap(osg::Texture::WRAP_S, 
 osg::Texture::CLAMP_TO_EDGE);
 p_renderTextureDepth-setWrap(osg::Texture::WRAP_T, 
 osg::Texture::CLAMP_TO_EDGE);

 // Main depth texture
 p_renderTextureDepth = new osg::Texture2D();
 p_renderTextureDepth-setTextureSize(p_osgViewport-width(), 
 p_osgViewport-height());
 p_renderTextureDepth-setSourceFormat(GL_DEPTH_COMPONENT);
 p_renderTextureDepth-setSourceType(GL_FLOAT);
 p_renderTextureDepth-setInternalFormat(GL_DEPTH_COMPONENT32F);
 p_renderTextureDepth-setFilter(osg::Texture2D::MIN_FILTER, 
 osg::Texture2D::NEAREST);
 p_renderTextureDepth-setFilter(osg::Texture2D::MAG_FILTER, 
 osg::Texture2D::NEAREST);
 p_renderTextureDepth-setWrap(osg::Texture::WRAP_S, 
 osg::Texture::CLAMP_TO_EDGE);
 p_renderTextureDepth-setWrap(osg::Texture::WRAP_T, 
 osg::Texture::CLAMP_TO_EDGE);




 Any help would be greatly appreciated.

 Aurelien

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





 ___
 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] Render to FBO and multiSamples

[Aurelien Albert]

Hi Robert,

I've try with :

p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, false, 
2, 2); 
p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth, 0, 0, false, 
2, 2); 

and 0 for sampleBuffers and samples on the traits, but the problem is still 
there.

(My video card is a Quadro FX 4800)

Is there anything else to configure ?

What is the difference between the parameters sampleBuffers and samples ?

Thanks,
Aurelien

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





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

Re: [osg-users] Play audio files

[Héctor Martínez]

Hi Laurens,

thank you for your reply. I still have the same problem. I can't figure out
why this is happening. With SDL it was working fine (without delays and cuts
in the audio). The strange thing is that if the video finishes and starts
again, the audio doesn't sound with cuts (until it goes to pause again).
On the other hand, I don't get this problem when playing audio files instead
of video files.

If anyone can give an idea about the problem, you are welcome.

Best regards

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Laurens
Voerman
Sent: martes, 24 de enero de 2012 16:49
To: OpenSceneGraph Users
Subject: Re: [osg-users] Play audio files

Hi Héctor,

I have no solution, our software just calls pause() from osg::ImageStream,
and has the same stuttering on restart.

Laurens.

On 1/24/2012 10:32 AM, Héctor Martínez wrote:
 Thank you Mattias and Laurens. I am testing the code you (Laurens) 
 have attached and it is working, but the audio is not synchronized and 
 if I pause the audio and then I play again, it seems that it plays 
 some kind of buffered audio and then the audio begins to sound with cuts.
 I am trying to find the reason of this behavior, but I write it here 
 in case you now the solution.

 Best regards.

 -Original Message-
 From: osg-users-boun...@lists.openscenegraph.org
 [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of 
 Laurens Voerman
 Sent: lunes, 23 de enero de 2012 15:12
 To: OpenSceneGraph Users
 Subject: Re: [osg-users] Play audio files

 Hi All,

 I have ffmpeg movie audio working with osgAudio, but have been to busy 
 to clean up the code, create an example and submit  for inclusion in 
 the osgAudio library. To avoid duplicate work I attach my current code as
is.
 Currently this is working part of our program, running both on linux
 (AMD64) and win7 (x64) . It compiles and runs on Win32 x86 but is 
 probably never tested.

 attached is a zipfile with AudioSink.h

 example should be a variation on osgMovie, but should be in the 
 osgAudio library, because osgAudio depends on osg.

 Laurens.

 Quick cut and paste from our program to show how to use this 'audioSink':

 // includes:
 #define OV_EXCLUDE_STATIC_CALLBACKS
 #includeosgAudio/SoundManager.h
 #includeosgAudio/SoundRoot.h

 #include AudioSink.h
 //init
   osgAudio::SoundManager::instance()-init( 16 );

 osgAudio::SoundManager::instance()-getEnvironment()-setDistanceModel
 (osgAu
 dio::InverseDistance);

 osgAudio::SoundManager::instance()-getEnvironment()-setDopplerFactor
 (1);

   if (!noAudio) {
   _sceneRootGroup-addChild(new osgAudio::SoundRoot);
   }
 // play movie audio
   osg::ImageStream::AudioStreams  audioStreams =
 ffstream-getAudioStreams();
   if (_playAudio  (!audioStreams.empty())
 audioStreams[0].valid())
   {
   osg::AudioStream* audioStream =
audioStreams[0].get();
   osg::notify(osg::NOTICE)AudioStream read 
 [audioStream-getName()]std::endl;
   osgRCAudio::AudioSink *sink;
   try {
   sink = new osgAudio::AudioSink(audioStream);
   }
   catch (...)
   {
   osg::notify(osg::WARN)  new AudioSink 
 failed  std::endl;
   }
   audioStream-setAudioSink(sink);
   }
 // cleanup
   osgAudio::SoundManager *sndMgr = osgAudio::SoundManager::instance();
   if (sndMgr-initialized()) sndMgr-shutdown();

   if (osg::Referenced::getDeleteHandler())
   {

 osg::Referenced::getDeleteHandler()-setNumFramesToRetainObjects(0);
   osg::Referenced::getDeleteHandler()-flushAll();
   }


 On 1/23/2012 11:22 AM, Mattias Helsing wrote:
 Hello Héctor

 You need to extend osg::AudioSink with the osgAudio code that you 
 have working. Have a look at the osgmovie exemple. It (optionally) 
 implements the osg::AudioSink interface using SDL. You need to do it 
 using osgAudio (or whatever sound backend you prefer).

 cheers
 Mattias

 2012/1/23 Héctor Martínezhector.marti...@sensetrix.com:
 Hi,


 Now, the following question: is there a straight way to connect the 
 audio from a video to osgAudio? I am using the ffmpeg plugin to read 
 the videos and I get audioStreams as it is done in the osgmovie example.

 Thank you in advance.
 ___
 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] Render to FBO and multiSamples

[Robert Osfield]

Hi Aurelien,

Could you try tests using the standard examples, for FSAA try:

Without FSAA:
   osgviewer cow.osg

Wih FSAA:

  osgviewer cow.osg --samples 2

Have a look around the edges of the cow for the classic stair stepping
in the non FSAA image and then compare to the FSAA one to see if it's
functioning correctly.  --samples sets both the Traits::samplesBuffers
and Traits::samples to the user specified value.

  osgprerender cow.osg  --fbo-samples 2 --color-samples 2

Then try enabling the use of multi-sampled FBO in the osgprerender example:

  osgprerender cow.osg  --fbo-samples 2 --color-samples 2

Finally add in the --samples 2 option to enable FSAA as well:

  osgprerender cow.osg  --fbo-samples 2 --color-samples 2 --samples 2

I've done this on my system and all the above tests work and observe
the expected reduction in stair stepping on the outlines of the cow
and flag respectively.

If all the above work fine on your system then the error will be
somewhere in your own code, if they don't work then it points to a
problem in the driver.

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

Re: [osg-users] Render to FBO and multiSamples

[Aurelien Albert]

Hi,

I've done all the tests, and they are all ok.

May the problem comes from the depth buffer attachment ?

When I use :


Code:
p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, false, 
4, 4);
p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth, 0, 0, false, 
4, 4);

or :

p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, false, 
4, 4);
p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth);




There is black screen, but if I don't attach depth buffer, I got something 
rendered and no Warning: detected OpenGL error 'invalid operation' at after 
RenderBin::draw(..) errors in the console.

Here is how I create my textures :


Code:
// Main color texture
p_renderTextureColor = new osg::Texture2D();
p_renderTextureColor-setTextureSize(p_osgViewport-width(), 
p_osgViewport-height());
p_renderTextureColor-setInternalFormat(GL_RGBA32F_ARB);
p_renderTextureColor-setSourceFormat(GL_RGBA);
p_renderTextureColor-setSourceType(GL_FLOAT);
p_renderTextureColor-setFilter(osg::Texture2D::MIN_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureColor-setFilter(osg::Texture2D::MAG_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureColor-setWrap(osg::Texture::WRAP_S, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureColor-setWrap(osg::Texture::WRAP_T, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureColor-setDataVariance(osg::Object::DYNAMIC); 
p_renderTextureColor-setUseHardwareMipMapGeneration(false);
p_renderTextureColor-setResizeNonPowerOfTwoHint(false);

// Main depth texture
p_renderTextureDepth = new osg::Texture2D();
p_renderTextureDepth-setTextureSize(p_osgViewport-width(), 
p_osgViewport-height());
p_renderTextureDepth-setSourceFormat(GL_DEPTH_COMPONENT);
p_renderTextureDepth-setSourceType(GL_FLOAT);
p_renderTextureDepth-setInternalFormat(GL_DEPTH_COMPONENT32F);
p_renderTextureDepth-setFilter(osg::Texture2D::MIN_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureDepth-setFilter(osg::Texture2D::MAG_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureDepth-setWrap(osg::Texture::WRAP_S, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureDepth-setWrap(osg::Texture::WRAP_T, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureDepth-setDataVariance(osg::Object::DYNAMIC); 
p_renderTextureDepth-setUseHardwareMipMapGeneration(false);
p_renderTextureDepth-setResizeNonPowerOfTwoHint(false);





Thank you!

Cheers,
Aurelien[/code]

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





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

Re: [osg-users] Render to FBO and multiSamples

[Robert Osfield]

Hi Aurelien,

I'm afraid I can't spot what might be wrong at your end.

Robert.

On 26 January 2012 10:13, Aurelien Albert aurelien.alb...@alyotech.fr wrote:
 Hi,

 I've done all the tests, and they are all ok.

 May the problem comes from the depth buffer attachment ?

 When I use :


 Code:
 p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, 
 false, 4, 4);
 p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth, 0, 0, 
 false, 4, 4);

 or :

 p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, 
 false, 4, 4);
 p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth);




 There is black screen, but if I don't attach depth buffer, I got something 
 rendered and no Warning: detected OpenGL error 'invalid operation' at after 
 RenderBin::draw(..) errors in the console.

 Here is how I create my textures :


 Code:
 // Main color texture
 p_renderTextureColor = new osg::Texture2D();
 p_renderTextureColor-setTextureSize(p_osgViewport-width(), 
 p_osgViewport-height());
 p_renderTextureColor-setInternalFormat(GL_RGBA32F_ARB);
 p_renderTextureColor-setSourceFormat(GL_RGBA);
 p_renderTextureColor-setSourceType(GL_FLOAT);
 p_renderTextureColor-setFilter(osg::Texture2D::MIN_FILTER, 
 osg::Texture2D::LINEAR);
 p_renderTextureColor-setFilter(osg::Texture2D::MAG_FILTER, 
 osg::Texture2D::LINEAR);
 p_renderTextureColor-setWrap(osg::Texture::WRAP_S, 
 osg::Texture::CLAMP_TO_EDGE);
 p_renderTextureColor-setWrap(osg::Texture::WRAP_T, 
 osg::Texture::CLAMP_TO_EDGE);
 p_renderTextureColor-setDataVariance(osg::Object::DYNAMIC);
 p_renderTextureColor-setUseHardwareMipMapGeneration(false);
 p_renderTextureColor-setResizeNonPowerOfTwoHint(false);

 // Main depth texture
 p_renderTextureDepth = new osg::Texture2D();
 p_renderTextureDepth-setTextureSize(p_osgViewport-width(), 
 p_osgViewport-height());
 p_renderTextureDepth-setSourceFormat(GL_DEPTH_COMPONENT);
 p_renderTextureDepth-setSourceType(GL_FLOAT);
 p_renderTextureDepth-setInternalFormat(GL_DEPTH_COMPONENT32F);
 p_renderTextureDepth-setFilter(osg::Texture2D::MIN_FILTER, 
 osg::Texture2D::LINEAR);
 p_renderTextureDepth-setFilter(osg::Texture2D::MAG_FILTER, 
 osg::Texture2D::LINEAR);
 p_renderTextureDepth-setWrap(osg::Texture::WRAP_S, 
 osg::Texture::CLAMP_TO_EDGE);
 p_renderTextureDepth-setWrap(osg::Texture::WRAP_T, 
 osg::Texture::CLAMP_TO_EDGE);
 p_renderTextureDepth-setDataVariance(osg::Object::DYNAMIC);
 p_renderTextureDepth-setUseHardwareMipMapGeneration(false);
 p_renderTextureDepth-setResizeNonPowerOfTwoHint(false);





 Thank you!

 Cheers,
 Aurelien[/code]

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





 ___
 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] Render to FBO and multiSamples

[J.P. Delport]

Hi,

maybe check code in osgfpdepth example.

jp

On 26/01/2012 12:13, Aurelien Albert wrote:

Hi,

I've done all the tests, and they are all ok.

May the problem comes from the depth buffer attachment ?

When I use :


Code:
p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, false, 
4, 4);
p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth, 0, 0, false, 
4, 4);

or :

p_camera-attach(osg::Camera::COLOR_BUFFER, p_renderTextureColor, 0, 0, false, 
4, 4);
p_camera-attach(osg::Camera::DEPTH_BUFFER, p_renderTextureDepth);




There is black screen, but if I don't attach depth buffer, I got something rendered and 
no Warning: detected OpenGL error 'invalid operation' at after 
RenderBin::draw(..) errors in the console.

Here is how I create my textures :


Code:
// Main color texture
p_renderTextureColor = new osg::Texture2D();
p_renderTextureColor-setTextureSize(p_osgViewport-width(), 
p_osgViewport-height());
p_renderTextureColor-setInternalFormat(GL_RGBA32F_ARB);
p_renderTextureColor-setSourceFormat(GL_RGBA);
p_renderTextureColor-setSourceType(GL_FLOAT);
p_renderTextureColor-setFilter(osg::Texture2D::MIN_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureColor-setFilter(osg::Texture2D::MAG_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureColor-setWrap(osg::Texture::WRAP_S, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureColor-setWrap(osg::Texture::WRAP_T, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureColor-setDataVariance(osg::Object::DYNAMIC);
p_renderTextureColor-setUseHardwareMipMapGeneration(false);
p_renderTextureColor-setResizeNonPowerOfTwoHint(false);

// Main depth texture
p_renderTextureDepth = new osg::Texture2D();
p_renderTextureDepth-setTextureSize(p_osgViewport-width(), 
p_osgViewport-height());
p_renderTextureDepth-setSourceFormat(GL_DEPTH_COMPONENT);
p_renderTextureDepth-setSourceType(GL_FLOAT);
p_renderTextureDepth-setInternalFormat(GL_DEPTH_COMPONENT32F);
p_renderTextureDepth-setFilter(osg::Texture2D::MIN_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureDepth-setFilter(osg::Texture2D::MAG_FILTER, 
osg::Texture2D::LINEAR);
p_renderTextureDepth-setWrap(osg::Texture::WRAP_S, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureDepth-setWrap(osg::Texture::WRAP_T, 
osg::Texture::CLAMP_TO_EDGE);
p_renderTextureDepth-setDataVariance(osg::Object::DYNAMIC);
p_renderTextureDepth-setUseHardwareMipMapGeneration(false);
p_renderTextureDepth-setResizeNonPowerOfTwoHint(false);





Thank you!

Cheers,
Aurelien[/code]

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





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


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

Re: [osg-users] Render to FBO and multiSamples

[Aurelien Albert]

I'm still investigating on it, and it's really weird : the depth buffer seems 
to be drawn over the color buffer : when I come close to my model, the image 
because darker...

This doesn't appear with FRAME_BUFFER render target.

Is that possible ? I saw some messages on the forum about implicit 
attachment... is there any link with my problem ?

My full render graph  is below (the problem seems to be in the post process 
camera) :


Code:
- Main camera (color / depth render to FBO)
|
|--- main scene
  |
  |--- Post process camera (render a quad using main camera color texture to a 
new FBO)
  |  |
  |  |-- Quad
  |
  |--- No post process camera (color / depth render to FBO,  color FBO is 
shared with post process camera, depth FBO is shared with main camera)
  |  |
  |  |-- Objects without post processing
  |
  |
  |--- Render to screen camera (render a quad to screen using post process 
camera color texture)
  |  |
  |  |-- Quad



Aurelien

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





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

Re: [osg-users] osgmaxexp problems

[Seppo]

The problem with the using svn rev 236 remains, but about the others:

 

animations needed sequence helper, and at material problem was not the
submaterial, but raytrace-material within the submaterial.

Hope this helps if someone is struggling with same problems.

 

-Seppo

 

From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Seppo
Sent: 24. tammikuuta 2012 10:38
To: 'OpenSceneGraph Users'
Subject: [osg-users] osgmaxexp problems

 

Hi,

 

I have compiled osgmaxexp svn rev 236 without problems, but when using that
I get this error when running 3DS max 2012 (32bit version):

DLL (OSGEXP.dle) failed to initialize. Error code 998 - Invalid access to
memory location.

 

Anyone else had the same problem, with possible solution?

 

Also, how to get multi/sub materials exported correctly? It seems none of
the submaterials exports.

 

And third question, how to get keyframeless animations to get exported?

 

-Seppo

 

 

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

Re: [osg-users] osgmaxexp problems

[Alessandro Terenzi]

 Hi,
 I have compiled osgmaxexp svn rev 236 without problems, but when using that
 I get this error when running 3DS max 2012 (32bit version):

 DLL (OSGEXP.dle) failed to initialize. Error code 998 - Invalid access to
 memory location.



 Anyone else had the same problem, with possible solution?

Don't know if this is your case, but: are you sure you are using the
32 bit version of OSGEXP.dle? Be sure to use the correct version
depending on the version of Max you are really using (32 vs. 64 bit).

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

Re: [osg-users] Play audio files

[Chris 'Xenon' Hanson]

On 1/26/2012 2:45 AM, Héctor Martínez wrote:
 Hi Laurens,
 If anyone can give an idea about the problem, you are welcome.

  I'd love to help you, but I only wrote the FMOD side of osgAudio -- the 
openAL/openalpp
side was part of osgAL, and I never really worked with it because I couldn't 
get openAL to
work on my Vista box at the time.

-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
http://www.alphapixel.com/
  Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. 
Contracting.
There is no Truth. There is only Perception. To Perceive is to Exist. - 
Xen
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgUtil::Optimizer and transparent objects

[Sebastian Messerschmidt]

Anyone any hint regarding this?

I'd really need an advice if I should fix the optimizer or where to 
solve this.


cheers
Sebastian

Hello,

I've encountered a problem when using the OpenFlight plugin with 
preserveFace/preserveObject option not used.
If the perserveFace options is not used, the importer uses the 
Optimizer with the following options:


osgUtil::Optimizer::SHARE_DUPLICATE_STATE |
osgUtil::Optimizer::MERGE_GEOMETRY |
osgUtil::Optimizer::MERGE_GEODES |
osgUtil::Optimizer::TESSELLATE_GEOMETRY |
osgUtil::Optimizer::STATIC_OBJECT_DETECTION;


This unfortunately breaks the sorting of transparent objects, as in my 
example all forests (represented by simple quads/polygons) are put 
into one geode.
After digging into the optimizer, I realized, that it will not check 
if the statesets contain any transparency.
Would you consider this rather a bug in the Optimizer or more a 
mis-usage in the OpenFlight importer?


As the osgviewer doesn't disable depth writes for transparent objects, 
the problem is only visible if you use the transparent-bin with depth 
writes off, which leads me to another question:


Would it be wise to turn off depth writes for the transparent bin by 
default ( or a least make it configurable for the osgviewer)?



cheers
Sebastian

___
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] Render to FBO and multiSamples

[Aurelien Albert]

Hi,

I solved my problem, but I don't really understand how.

What I did :

1. attach the same depth buffer FBO to all cameras
2. configure multisamples only on the first camera color buffer attachment
3. always use a shader program to render post processing, even if there is no 
post processing

Point 1 : I really don't understand what difference it makes

Point 2 : I use a color buffer shared between 2 cameras, it seems I can only 
configure multisamples for the firs one

Point 3 : really strange : if I render the textured quad to screen whitout any 
shader, all screen become darker when the camera is very close to an object



Cheers,
Aurelien

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





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

Re: [osg-users] osgdem segmentation fault

[Mohammed Rashad]

Hi Robert,

this is the valgrind output

valgrind osgdemd --xx 10 --yy 10 -t ps_texture_16k.png --xx 10 --yy 10 -d
ps_height_16k.png  -l 8 -v 0.1 -o puget.ive -a pegout.osga
==12136== Memcheck, a memory error detector
==12136== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==12136== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
copyright info
==12136== Command: osgdemd --xx 10 --yy 10 -t ps_texture_16k.png --xx 10
--yy 10 -d ps_height_16k.png -l 8 -v 0.1 -o puget.ive -a pegout.osga
==12136==
Warning: archive option -a is temporarily disabled, building with archive.
--xx 10
--yy 10
-t ps_texture_16k.png
ADD: ps_texture_16k.png
loaded layer ps_texture_16k.png
--xx 10
--yy 10
-d ps_height_16k.png
ADD: ps_height_16k.png
loaded layer ps_height_16k.png
-o puget.ive
Adding terrainTile
DataSet::_run() 0 0
Now checking for plug-in osgPlugins-3.0.0/osgdb_nvtt.so
DataSet::assignDestinationCoordinateSystem() : assigning first source file
as the destination coordinate system
started DataSet::createDestination(8)
Time for after_reproject 0.012247
DataSet::assignDestinationCoordinateSystem() : assigning first source file
as the destination coordinate system
local_extents = xMin() 0.00 163850.00
yMin() 0.00 163850.00
AR=1.00 C1=1 R1=1
createNewDestinationGraph
Time for _destinationGraph-computeMaximumSourceResolution() = 1.153935
Time for createDestinationGraph 4.648750
Time for after_computeNeighbours 2.396875
completed DataSet::createDestination(8)
There are 2 contributing source files:
ps_height_16k.png
ps_texture_16k.png
==12136== Syscall param ioctl(generic) points to uninitialised byte(s)
==12136==at 0x613A619: ioctl (syscall-template.S:82)
==12136==by 0x714304A: drmCommandWriteRead (in /lib/libdrm.so.2.4.0)
==12136==by 0x4315B7E: radeon_cs_manager_gem_ctor (in
/lib/libdrm_radeon.so.1.0.0)
==12136==by 0x7DEA1AF: r600InitCmdBuf (in /usr/lib/dri/r600_dri.so)
==12136==by 0x7DE9E26: r600CreateContext (in /usr/lib/dri/r600_dri.so)
==12136==by 0x7DE0C3A: ??? (in /usr/lib/dri/r600_dri.so)
==12136==by 0x7DE0CD5: ??? (in /usr/lib/dri/r600_dri.so)
==12136==by 0x5DC143C: ??? (in /usr/lib/mesa/libGL.so.1.2)
==12136==by 0x5D99E6A: ??? (in /usr/lib/mesa/libGL.so.1.2)
==12136==by 0x5D9A30D: glXCreateContext (in /usr/lib/mesa/libGL.so.1.2)
==12136==by 0x521D033: osgViewer::PixelBufferX11::init() (in
/usr/local/lib/libosgViewer.so.3.0.0)
==12136==by 0x521C17F:
osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*)
(in /usr/local/lib/libosgViewer.so.3.0.0)
==12136==  Address 0xbe8c0bf4 is on thread 1's stack
==12136==
==12136== Syscall param ioctl(generic) points to uninitialised byte(s)
==12136==at 0x613A619: ioctl (syscall-template.S:82)
==12136==by 0x714304A: drmCommandWriteRead (in /lib/libdrm.so.2.4.0)
==12136==by 0x7DEA22F: r600InitCmdBuf (in /usr/lib/dri/r600_dri.so)
==12136==by 0x7DE9E26: r600CreateContext (in /usr/lib/dri/r600_dri.so)
==12136==by 0x7DE0C3A: ??? (in /usr/lib/dri/r600_dri.so)
==12136==by 0x7DE0CD5: ??? (in /usr/lib/dri/r600_dri.so)
==12136==by 0x5DC143C: ??? (in /usr/lib/mesa/libGL.so.1.2)
==12136==by 0x5D99E6A: ??? (in /usr/lib/mesa/libGL.so.1.2)
==12136==by 0x5D9A30D: glXCreateContext (in /usr/lib/mesa/libGL.so.1.2)
==12136==by 0x521D033: osgViewer::PixelBufferX11::init() (in
/usr/local/lib/libosgViewer.so.3.0.0)
==12136==by 0x521C17F:
osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*)
(in /usr/local/lib/libosgViewer.so.3.0.0)
==12136==by 0x52188AF:
X11WindowingSystemInterface::createGraphicsContext(osg::GraphicsContext::Traits*)
(in /usr/local/lib/libosgViewer.so.3.0.0)
==12136==  Address 0xbe8c0c38 is on thread 1's stack
==12136==
==12136== Invalid read of size 4
==12136==at 0x5DBD0B0: ??? (in /usr/lib/mesa/libGL.so.1.2)
==12136==by 0x521D60E: osgViewer::PixelBufferX11::init() (in
/usr/local/lib/libosgViewer.so.3.0.0)
==12136==by 0x521C17F:
osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*)
(in /usr/local/lib/libosgViewer.so.3.0.0)
==12136==by 0x52188AF:
X11WindowingSystemInterface::createGraphicsContext(osg::GraphicsContext::Traits*)
(in /usr/local/lib/libosgViewer.so.3.0.0)
==12136==by 0x4EB4866:
osg::GraphicsContext::createGraphicsContext(osg::GraphicsContext::Traits*)
(in /usr/local/lib/libosg.so.3.0.0)
==12136==by 0x41B356F:
MyGraphicsContext::MyGraphicsContext(vpb::BuildLog*) (DataSet.cpp:2518)
==12136==by 0x41AE8E9: vpb::DataSet::_run() (DataSet.cpp:3243)
==12136==by 0x41ADE7B: vpb::DataSet::run() (DataSet.cpp:3102)
==12136==by 0x804E1D9: main (osgdem.cpp:288)
==12136==  Address 0xb8 is not stack'd, malloc'd or (recently) free'd
==12136==
==12136==
==12136== Process terminating with default action of signal 11 (SIGSEGV)
==12136==  Access not within mapped region at address 0xB8
==12136==at 0x5DBD0B0: ??? (in 

Re: [osg-users] Request for input

[Jason Daly]

Hi, JP,


On 01/26/2012 01:53 AM, J.P. Delport wrote:

very interesting and thorough investigation. I can't really add anything
and unfortunately don't have representative hardware to test on. It
would be interesting to see if different bus configs
(motherboards/chipsets) make any difference.


The target hardware is a dual Xeon system with a 5400 chipset (the last 
chipset with a FSB) and a pair of QuadroPlex D2's.  I've been working on 
an Alienware desktop with an X58 chipset and two GeForce 260's.  One 
would expect that the X58 with its QPI interconnect would succumb to bus 
contention later than the 5400 (the specs say so, at least), but on the 
largest data set, it appears that the X58 is still having the scaling 
problem, while on the workstation, the bottleneck has moved elsewhere.




  I also would not rule out
the NVidia driver doing silly things. I remember once looking at some of
the glue code for the binary blob and seeing TLB flushes that caused a
Xenomai kernel to fail ito timing in interesting ways.

Have you tried OProfile to get some idea of time spent in the driver?


I'm not familiar with OProfile.  I'll take a look.

Thanks for the reply!

--J

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

Re: [osg-users] osgdem segmentation fault

[Robert Osfield]

HI Mohammed,

The trace points to the OpenGL driver failing when trying to create the pbuffer.

osgdem uses an OpenGL graphics context to create the GL compressed
textures, you can avoid the use of the GL driver if you using NVTT.
To use this you'll need to install NVTT SDK and rebuild VPB against
it.  When running osgdem you'll need to add the --compressor-nvtt
command line option to tell osgdem to use NVTT.

Alternatively you could avoid use of OpenGL compressed textures by
using the --RGB-24 command option.

Or... just install an non broken OpenGL driver.

Robert.

On 26 January 2012 16:37, Mohammed Rashad mohammedrasha...@gmail.com wrote:
 Hi Robert,

 this is the valgrind output

 valgrind osgdemd --xx 10 --yy 10 -t ps_texture_16k.png --xx 10 --yy 10 -d
 ps_height_16k.png  -l 8 -v 0.1 -o puget.ive -a pegout.osga
 ==12136== Memcheck, a memory error detector
 ==12136== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
 ==12136== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
 copyright info
 ==12136== Command: osgdemd --xx 10 --yy 10 -t ps_texture_16k.png --xx 10
 --yy 10 -d ps_height_16k.png -l 8 -v 0.1 -o puget.ive -a pegout.osga
 ==12136==
 Warning: archive option -a is temporarily disabled, building with archive.
 --xx 10
 --yy 10
 -t ps_texture_16k.png
 ADD: ps_texture_16k.png
 loaded layer ps_texture_16k.png
 --xx 10
 --yy 10
 -d ps_height_16k.png
 ADD: ps_height_16k.png
 loaded layer ps_height_16k.png
 -o puget.ive
 Adding terrainTile
 DataSet::_run() 0 0
 Now checking for plug-in osgPlugins-3.0.0/osgdb_nvtt.so
 DataSet::assignDestinationCoordinateSystem() : assigning first source file
 as the destination coordinate system
 started DataSet::createDestination(8)
 Time for after_reproject 0.012247
 DataSet::assignDestinationCoordinateSystem() : assigning first source file
 as the destination coordinate system
 local_extents = xMin() 0.00 163850.00
                 yMin() 0.00 163850.00
 AR=1.00 C1=1 R1=1
 createNewDestinationGraph
 Time for _destinationGraph-computeMaximumSourceResolution() = 1.153935
 Time for createDestinationGraph 4.648750
 Time for after_computeNeighbours 2.396875
 completed DataSet::createDestination(8)
 There are 2 contributing source files:
     ps_height_16k.png
     ps_texture_16k.png
 ==12136== Syscall param ioctl(generic) points to uninitialised byte(s)
 ==12136==    at 0x613A619: ioctl (syscall-template.S:82)
 ==12136==    by 0x714304A: drmCommandWriteRead (in /lib/libdrm.so.2.4.0)
 ==12136==    by 0x4315B7E: radeon_cs_manager_gem_ctor (in
 /lib/libdrm_radeon.so.1.0.0)
 ==12136==    by 0x7DEA1AF: r600InitCmdBuf (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x7DE9E26: r600CreateContext (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x7DE0C3A: ??? (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x7DE0CD5: ??? (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x5DC143C: ??? (in /usr/lib/mesa/libGL.so.1.2)
 ==12136==    by 0x5D99E6A: ??? (in /usr/lib/mesa/libGL.so.1.2)
 ==12136==    by 0x5D9A30D: glXCreateContext (in /usr/lib/mesa/libGL.so.1.2)
 ==12136==    by 0x521D033: osgViewer::PixelBufferX11::init() (in
 /usr/local/lib/libosgViewer.so.3.0.0)
 ==12136==    by 0x521C17F:
 osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*) (in
 /usr/local/lib/libosgViewer.so.3.0.0)
 ==12136==  Address 0xbe8c0bf4 is on thread 1's stack
 ==12136==
 ==12136== Syscall param ioctl(generic) points to uninitialised byte(s)
 ==12136==    at 0x613A619: ioctl (syscall-template.S:82)
 ==12136==    by 0x714304A: drmCommandWriteRead (in /lib/libdrm.so.2.4.0)
 ==12136==    by 0x7DEA22F: r600InitCmdBuf (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x7DE9E26: r600CreateContext (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x7DE0C3A: ??? (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x7DE0CD5: ??? (in /usr/lib/dri/r600_dri.so)
 ==12136==    by 0x5DC143C: ??? (in /usr/lib/mesa/libGL.so.1.2)
 ==12136==    by 0x5D99E6A: ??? (in /usr/lib/mesa/libGL.so.1.2)
 ==12136==    by 0x5D9A30D: glXCreateContext (in /usr/lib/mesa/libGL.so.1.2)
 ==12136==    by 0x521D033: osgViewer::PixelBufferX11::init() (in
 /usr/local/lib/libosgViewer.so.3.0.0)
 ==12136==    by 0x521C17F:
 osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*) (in
 /usr/local/lib/libosgViewer.so.3.0.0)
 ==12136==    by 0x52188AF:
 X11WindowingSystemInterface::createGraphicsContext(osg::GraphicsContext::Traits*)
 (in /usr/local/lib/libosgViewer.so.3.0.0)
 ==12136==  Address 0xbe8c0c38 is on thread 1's stack
 ==12136==
 ==12136== Invalid read of size 4
 ==12136==    at 0x5DBD0B0: ??? (in /usr/lib/mesa/libGL.so.1.2)
 ==12136==    by 0x521D60E: osgViewer::PixelBufferX11::init() (in
 /usr/local/lib/libosgViewer.so.3.0.0)
 ==12136==    by 0x521C17F:
 osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*) (in
 /usr/local/lib/libosgViewer.so.3.0.0)
 ==12136==    by 0x52188AF:
 

Re: [osg-users] osgUtil::Optimizer and transparent objects

[Sergey Polischuk]

Hi

About optimizer - i would rather count this one as misusage. And for 
transparent stuff with depth write disabled by default - there are some cons 
for this (alpha masked geometry with alpha test f.e.). And if you want correct 
blending you should draw transparent objects after solid and sort them either 
back to front or front to back (depending on blending function), in case of 
back to front sorting there are no difference between depth write enabled or 
disabled anyway (as long as sorted objects not overlap).
So disabling depth write would only help in cases when sorting are not an 
option for some reason, sorted objects overlaps(in depth), or objects are very 
transparent (as in latter case draw order often dont make big visual 
difference, at least you cant say that something completely wrong looking at 
picture :)

Cheers

26.01.2012, 20:19, Sebastian Messerschmidt sebastian.messerschm...@gmx.de:
 Anyone any hint regarding this?

 I'd really need an advice if I should fix the optimizer or where to
 solve this.

 cheers
 Sebastian

  Hello,

  I've encountered a problem when using the OpenFlight plugin with
  preserveFace/preserveObject option not used.
  If the perserveFace options is not used, the importer uses the
  Optimizer with the following options:

  osgUtil::Optimizer::SHARE_DUPLICATE_STATE |
  osgUtil::Optimizer::MERGE_GEOMETRY |
  osgUtil::Optimizer::MERGE_GEODES |
  osgUtil::Optimizer::TESSELLATE_GEOMETRY |
  osgUtil::Optimizer::STATIC_OBJECT_DETECTION;

  This unfortunately breaks the sorting of transparent objects, as in my
  example all forests (represented by simple quads/polygons) are put
  into one geode.
  After digging into the optimizer, I realized, that it will not check
  if the statesets contain any transparency.
  Would you consider this rather a bug in the Optimizer or more a
  mis-usage in the OpenFlight importer?

  As the osgviewer doesn't disable depth writes for transparent objects,
  the problem is only visible if you use the transparent-bin with depth
  writes off, which leads me to another question:

  Would it be wise to turn off depth writes for the transparent bin by
  default ( or a least make it configurable for the osgviewer)?

  cheers
  Sebastian

  ___
  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] Render to FBO and multiSamples

[Sergey Polischuk]

Hi

About 3rd point - i think fixed pipeline opengl lighting may screw that.

26.01.2012, 20:32, Aurelien Albert aurelien.alb...@alyotech.fr:
 Hi,

 I solved my problem, but I don't really understand how.

 What I did :

 1. attach the same depth buffer FBO to all cameras
 2. configure multisamples only on the first camera color buffer attachment
 3. always use a shader program to render post processing, even if there is no 
 post processing

 Point 1 : I really don't understand what difference it makes

 Point 2 : I use a color buffer shared between 2 cameras, it seems I can only 
 configure multisamples for the firs one

 Point 3 : really strange : if I render the textured quad to screen whitout 
 any shader, all screen become darker when the camera is very close to an 
 object

 Cheers,
 Aurelien

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

 ___
 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] osgUtil::Optimizer and transparent objects

[Sebastian Messerschmidt]

Am 26.01.2012 17:51, schrieb Sergey Polischuk:

Hi

About optimizer - i would rather count this one as misusage.
Okay, still I think it'll be possible to fix the merge geode visitor 
easily.  I don't want to loose the ability to merge the literally 
thousands of openflight geometries if they are not transparent.
I've come up with a quick fix which I'm testing currently. It required a 
simple check in the mergeGeode function:



bool Optimizer::MergeGeometryVisitor::mergeGeode(osg::Geode geode)
{
if (!isOperationPermissibleForObject(geode)) return false;
#if 1 //new check
osg::StateSet*  geode_stateset = geode.getStateSet();
if (geode_stateset  osg::StateSet::TRANSPARENT_BIN  == 
geode_stateset-getRenderingHint())

{
return false;
}
#endif

I'm wondering if the best solution would be to use an additional flag in 
the MERGE_GEODE optimizer to either skip transparent state sets or 
optimize them anyways.

Maybe Robert can give an advice, how to solve this question.







  And for transparent stuff with depth write disabled by default - there are 
some cons for this (alpha masked geometry with alpha test f.e.). And if you 
want correct blending you should draw transparent objects after solid and sort 
them either back to front or front to back (depending on blending function), in 
case of back to front sorting there are no difference between depth write 
enabled or disabled anyway (as long as sorted objects not overlap).
So disabling depth write would only help in cases when sorting are not an 
option for some reason, sorted objects overlaps(in depth), or objects are very 
transparent (as in latter case draw order often dont make big visual 
difference, at least you cant say that something completely wrong looking at 
picture :)
I do separate my drawing by issuing the opaque stuff first and draw the 
transparent stuff sorted.
Still a lot of models I've come across (e.g. simple vegetation) uses a 
lot if intersecting quads, so for this it really makes a difference 
whether depth writes are enabled or not.


Anyways, right now I'm trying to post-process my scenes in order to 
control some stuff, so it doesn't hurt to much to decide for my self if 
depth writes are on or not.
Question was more pointed to the fact, that in each classical example 
you find, depth writes are off for blended stuff.


cheers
Sebastian


Cheers

26.01.2012, 20:19, Sebastian Messerschmidtsebastian.messerschm...@gmx.de:

Anyone any hint regarding this?

I'd really need an advice if I should fix the optimizer or where to
solve this.

cheers
Sebastian


  Hello,

  I've encountered a problem when using the OpenFlight plugin with
  preserveFace/preserveObject option not used.
  If the perserveFace options is not used, the importer uses the
  Optimizer with the following options:

  osgUtil::Optimizer::SHARE_DUPLICATE_STATE |
  osgUtil::Optimizer::MERGE_GEOMETRY |
  osgUtil::Optimizer::MERGE_GEODES |
  osgUtil::Optimizer::TESSELLATE_GEOMETRY |
  osgUtil::Optimizer::STATIC_OBJECT_DETECTION;

  This unfortunately breaks the sorting of transparent objects, as in my
  example all forests (represented by simple quads/polygons) are put
  into one geode.
  After digging into the optimizer, I realized, that it will not check
  if the statesets contain any transparency.
  Would you consider this rather a bug in the Optimizer or more a
  mis-usage in the OpenFlight importer?

  As the osgviewer doesn't disable depth writes for transparent objects,
  the problem is only visible if you use the transparent-bin with depth
  writes off, which leads me to another question:

  Would it be wise to turn off depth writes for the transparent bin by
  default ( or a least make it configurable for the osgviewer)?

  cheers
  Sebastian

  ___
  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] osgdem segmentation fault

[Mohammed Rashad]

robert.osfi...@gmail.com

On Thu, Jan 26, 2012 at 10:20 PM, Robert Osfield
robert.osfi...@gmail.comwrote:

 HI Mohammed,

 The trace points to the OpenGL driver failing when trying to create the
 pbuffer.

 osgdem uses an OpenGL graphics context to create the GL compressed
 textures, you can avoid the use of the GL driver if you using NVTT.
 To use this you'll need to install NVTT SDK and rebuild VPB against

how to rebuilt VPB agains NVTT SDK

 it.  When running osgdem you'll need to add the --compressor-nvtt
 command line option to tell osgdem to use NVTT.

 Alternatively you could avoid use of OpenGL compressed textures by
 using the --RGB-24 command option.

 Or... just install an non broken OpenGL driver.

 Robert.

 On 26 January 2012 16:37, Mohammed Rashad mohammedrasha...@gmail.com
 wrote:
  Hi Robert,
 
  this is the valgrind output
 
  valgrind osgdemd --xx 10 --yy 10 -t ps_texture_16k.png --xx 10 --yy 10 -d
  ps_height_16k.png  -l 8 -v 0.1 -o puget.ive -a pegout.osga
  ==12136== Memcheck, a memory error detector
  ==12136== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
  ==12136== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for
  copyright info
  ==12136== Command: osgdemd --xx 10 --yy 10 -t ps_texture_16k.png --xx 10
  --yy 10 -d ps_height_16k.png -l 8 -v 0.1 -o puget.ive -a pegout.osga
  ==12136==
  Warning: archive option -a is temporarily disabled, building with
 archive.
  --xx 10
  --yy 10
  -t ps_texture_16k.png
  ADD: ps_texture_16k.png
  loaded layer ps_texture_16k.png
  --xx 10
  --yy 10
  -d ps_height_16k.png
  ADD: ps_height_16k.png
  loaded layer ps_height_16k.png
  -o puget.ive
  Adding terrainTile
  DataSet::_run() 0 0
  Now checking for plug-in osgPlugins-3.0.0/osgdb_nvtt.so
  DataSet::assignDestinationCoordinateSystem() : assigning first source
 file
  as the destination coordinate system
  started DataSet::createDestination(8)
  Time for after_reproject 0.012247
  DataSet::assignDestinationCoordinateSystem() : assigning first source
 file
  as the destination coordinate system
  local_extents = xMin() 0.00 163850.00
  yMin() 0.00 163850.00
  AR=1.00 C1=1 R1=1
  createNewDestinationGraph
  Time for _destinationGraph-computeMaximumSourceResolution() = 1.153935
  Time for createDestinationGraph 4.648750
  Time for after_computeNeighbours 2.396875
  completed DataSet::createDestination(8)
  There are 2 contributing source files:
  ps_height_16k.png
  ps_texture_16k.png
  ==12136== Syscall param ioctl(generic) points to uninitialised byte(s)
  ==12136==at 0x613A619: ioctl (syscall-template.S:82)
  ==12136==by 0x714304A: drmCommandWriteRead (in /lib/libdrm.so.2.4.0)
  ==12136==by 0x4315B7E: radeon_cs_manager_gem_ctor (in
  /lib/libdrm_radeon.so.1.0.0)
  ==12136==by 0x7DEA1AF: r600InitCmdBuf (in /usr/lib/dri/r600_dri.so)
  ==12136==by 0x7DE9E26: r600CreateContext (in
 /usr/lib/dri/r600_dri.so)
  ==12136==by 0x7DE0C3A: ??? (in /usr/lib/dri/r600_dri.so)
  ==12136==by 0x7DE0CD5: ??? (in /usr/lib/dri/r600_dri.so)
  ==12136==by 0x5DC143C: ??? (in /usr/lib/mesa/libGL.so.1.2)
  ==12136==by 0x5D99E6A: ??? (in /usr/lib/mesa/libGL.so.1.2)
  ==12136==by 0x5D9A30D: glXCreateContext (in
 /usr/lib/mesa/libGL.so.1.2)
  ==12136==by 0x521D033: osgViewer::PixelBufferX11::init() (in
  /usr/local/lib/libosgViewer.so.3.0.0)
  ==12136==by 0x521C17F:
  osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*)
 (in
  /usr/local/lib/libosgViewer.so.3.0.0)
  ==12136==  Address 0xbe8c0bf4 is on thread 1's stack
  ==12136==
  ==12136== Syscall param ioctl(generic) points to uninitialised byte(s)
  ==12136==at 0x613A619: ioctl (syscall-template.S:82)
  ==12136==by 0x714304A: drmCommandWriteRead (in /lib/libdrm.so.2.4.0)
  ==12136==by 0x7DEA22F: r600InitCmdBuf (in /usr/lib/dri/r600_dri.so)
  ==12136==by 0x7DE9E26: r600CreateContext (in
 /usr/lib/dri/r600_dri.so)
  ==12136==by 0x7DE0C3A: ??? (in /usr/lib/dri/r600_dri.so)
  ==12136==by 0x7DE0CD5: ??? (in /usr/lib/dri/r600_dri.so)
  ==12136==by 0x5DC143C: ??? (in /usr/lib/mesa/libGL.so.1.2)
  ==12136==by 0x5D99E6A: ??? (in /usr/lib/mesa/libGL.so.1.2)
  ==12136==by 0x5D9A30D: glXCreateContext (in
 /usr/lib/mesa/libGL.so.1.2)
  ==12136==by 0x521D033: osgViewer::PixelBufferX11::init() (in
  /usr/local/lib/libosgViewer.so.3.0.0)
  ==12136==by 0x521C17F:
  osgViewer::PixelBufferX11::PixelBufferX11(osg::GraphicsContext::Traits*)
 (in
  /usr/local/lib/libosgViewer.so.3.0.0)
  ==12136==by 0x52188AF:
 
 X11WindowingSystemInterface::createGraphicsContext(osg::GraphicsContext::Traits*)
  (in /usr/local/lib/libosgViewer.so.3.0.0)
  ==12136==  Address 0xbe8c0c38 is on thread 1's stack
  ==12136==
  ==12136== Invalid read of size 4
  ==12136==at 0x5DBD0B0: ??? (in /usr/lib/mesa/libGL.so.1.2)
  ==12136==by 0x521D60E: osgViewer::PixelBufferX11::init() (in
  

[osg-users] Compilation fails with recent version of osg for IOS / opengl es-builds

[Stephan Maximilian Huber]

Hi all / Robert,

a recent commit to the repository (rev. 12912) broke compilation for ios
/ open gl es 1.1 as GL_UNPACK_ROW_LENGTH is not supported on that devices.

Before fixing this with some dumb ifdefs I'll ask for any consequences
when doing so, or for a better solution.

cheers,

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

Re: [osg-users] osgdem segmentation fault

[Robert Osfield]

On 26 January 2012 17:25, Mohammed Rashad mohammedrasha...@gmail.com wrote:
 how to rebuilt VPB agains NVTT SDK

Go fetch NVTT from NVidia's website, install it.

cd VirtualPlanetBuilder
rm CMakeCache.txt  // to force it to search for dependencies a fresh
./configure
make
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Request for input

[Peter Kilpatrick]

Hello,

This may be relevant:

Memory Speed, QPI and Multicore

http://www.masm32.com/board/index.php?PHPSESSID=afe5222fb85c769a44da28f1eb5d4b82topic=17296.0

Peter

- Original Message - 
From: Jason Daly jd...@ist.ucf.edu

To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Thursday, January 26, 2012 6:49 PM
Subject: Re: [osg-users] Request for input




Hi, JP,


On 01/26/2012 01:53 AM, J.P. Delport wrote:

very interesting and thorough investigation. I can't really add anything
and unfortunately don't have representative hardware to test on. It
would be interesting to see if different bus configs
(motherboards/chipsets) make any difference.


The target hardware is a dual Xeon system with a 5400 chipset (the last 
chipset with a FSB) and a pair of QuadroPlex D2's.  I've been working on 
an Alienware desktop with an X58 chipset and two GeForce 260's.  One would 
expect that the X58 with its QPI interconnect would succumb to bus 
contention later than the 5400 (the specs say so, at least), but on the 
largest data set, it appears that the X58 is still having the scaling 
problem, while on the workstation, the bottleneck has moved elsewhere.




  I also would not rule out
the NVidia driver doing silly things. I remember once looking at some of
the glue code for the binary blob and seeing TLB flushes that caused a
Xenomai kernel to fail ito timing in interesting ways.

Have you tried OProfile to get some idea of time spent in the driver?


I'm not familiar with OProfile.  I'll take a look.

Thanks for the reply!

--J

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



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

Re: [osg-users] osgmaxexp problems

[Farshid Lashkari]

Hi Seppo,

On Tue, Jan 24, 2012 at 12:37 AM, Seppo se...@kuutio.net wrote:

 I have compiled osgmaxexp svn rev 236 without problems, but when using
 that I get this error when running 3DS max 2012 (32bit version):

 DLL (OSGEXP.dle) failed to initialize. Error code 998 - Invalid access to
 memory location.


 Are you getting this error when 3ds max starts up or when you try to
export?

Cheers,
Farshid


 ** **

 ** **

 ___
 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] Compilation fails with recent version of osg for IOS / opengl es-builds

[Robert Osfield]

HI Stephan,

On 26 January 2012 17:46, Stephan Maximilian Huber
ratzf...@digitalmind.de wrote:
 Hi all / Robert,

 a recent commit to the repository (rev. 12912) broke compilation for ios
 / open gl es 1.1 as GL_UNPACK_ROW_LENGTH is not supported on that devices.

 Before fixing this with some dumb ifdefs I'll ask for any consequences
 when doing so, or for a better solution.

The only consequence for not support unpack row length is that you'd
have to only use osg::Image that are contiguous.  However, this is not
an onerous requirement as up until last week osg::Image could only
handle contiguous store of image data, and even now all existing image
plugins load osg::Image that don't use the now RowLength feature so
will all provide contiguous imagery.

The use or RowLength is really just a niche feature that a small
number of users will use, such as when handling textures that are
small portion of large imagery heading in main memory.

So disabling the feature would be fine for OpenGL ES, but on setting a
non zero RowLength osg::Image under OpenGL ES it should emit a warning
that it's not supported.

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

Re: [osg-users] Request for input

[Tim Moore]

On Wed, Jan 25, 2012 at 10:59 PM, Jason Daly jd...@ist.ucf.edu wrote:

 Hi, all,

 This is a general request to the community for some advice and expertise.
  This is a bit lengthy, but if you can spare a few minutes to look over this
 and send along your thoughts, we would really appreciate it.

 I've been working on a project for NIST recently.  For background, you might
 find this osg-users thread from December 2010 useful:

 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/63954/focus=64014


 Briefly, an OSG-based test application loads a scene and displays it in a
 window on one or more screens (Single Viewer, multiple slave cameras, one
 GPU and context per screen).  The problem was that a single screen would
 draw the scene at a given frame rate, but as additional screens were added,
 the frame rate would drop significantly (427 fps on one screen, 396 fps on
 two, 291 on four).
...
 At this point, I started looking for something else to blame.  Examining the
 data set itself, I discovered that it was composed of about 5500 triangle
 strips, none of which were longer than 112 vertices (the data set had about
 600,000 vertices total).  There were only about 10 different StateSets in
 the scene, so state changes aren't a problem.  After some digging, I found
 the MeshOptimizers portion of osgUtil::Optimizer, and based on a message I
 found from Jean-Sebastian, I tried a pass of VERTEX_PRETRANSFORM |
 INDEX_MESH | VERTEX_POSTTRANSFORM, followed by another pass of MERGE_GEODES
 | MERGE_GEOMETRY.  This reduced the number of draw calls from around 5500 to
 9, and completely eliminated the scalability problem for both the OSG test
 program, and the pure OpenGL program.  This leads me to believe that bus
 contention was causing the lack of scalability.  As more screens were added,
 the thousands of draw calls required by the unoptimized data set couldn't
 fit within the bus bandwidth, effectively causing the draw calls to take
 longer.  The unoptimized data, only requiring 9 draw calls per screen, could
 easily fit.

That is what I found at the time of that thread, testing with some
models supplied by NIST. Newer hardware is highly optimized for
massive geometry.

For the record, I don't think the problem is bus contention, but lock
contention in the NVidia driver. The amount of bus traffic involved
in the OpenGL command stream is tiny.

 So, here are our questions.  Does it make sense that bus contention would be
 causing the lack of scalability?  Are the mesh optimizations mentioned above
 the most effective way to solve the problem?  Are there any cases where the
 mesh optimizations wouldn't be sufficient, and additional steps would need
 to be taken (I briefly mentioned state changes above, which could be
 problematic, anything else)?  Why doesn't the 64x data set seem to scale as
 well as the 1x and 8x data sets (does this indicate that the bottleneck has
 moved from the bus to somewhere else)?

 Any thoughts on these issues or other thoughts you could provide would be
 very valuable.

The key to OpenGL performance in the 21st century is reducing the
number of OpenGL function calls to a minimum... so says Captain
Obvious.

I'm glad the mesh optimizers turned out to be useful!

Btw, the Linux tool oprofile is mentioned later in the thread, but I
find the newer tool perf to be more useful.

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

Re: [osg-users] Request for input

[Jason Daly]

On 01/26/2012 01:01 PM, Peter Kilpatrick wrote:

Hello,

This may be relevant:

Memory Speed, QPI and Multicore

http://www.masm32.com/board/index.php?PHPSESSID=afe5222fb85c769a44da28f1eb5d4b82topic=17296.0


Hi, Peter,

So the lesson there is to ensure that your RAM is running at optimal 
timings before blaming the bus.  I'll look into that, thanks!


--J

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

Re: [osg-users] Request for input

[Jason Daly]

On 01/26/2012 01:02 PM, Tim Moore wrote:


That is what I found at the time of that thread, testing with some
models supplied by NIST. Newer hardware is highly optimized for
massive geometry.

For the record, I don't think the problem is bus contention, but lock
contention in the NVidia driver. The amount of bus traffic involved
in the OpenGL command stream is tiny.


Thanks for that.  A couple of people have mentioned bringing this to 
NVidia's attention.  We'll probably end up doing that.




The key to OpenGL performance in the 21st century is reducing the
number of OpenGL function calls to a minimum... so says Captain
Obvious.

I'm glad the mesh optimizers turned out to be useful!


Yeah, once you get down to the data itself, it ends up being pretty 
obvious (5,500 draw calls runs slower than 9 draw calls?  Really?  :-) ).


There was a bit of digging to do before we got to that point, though.  
At the outset, we originally thought that an OpenGL program wasn't 
showing the same problem that an OSG program was, which pointed the 
blame at OSG.  Turns out that we weren't doing an apples-to-apples 
comparison with the data sets.  It wasn't until we could get precisely 
the same set of data into the OpenGL program that we could start looking 
at the data itself as the culprit.


Definitely a big thanks for the mesh optimizers.  I was all set to start 
writing something myself, but then I realized they were already there  :-)




Btw, the Linux tool oprofile is mentioned later in the thread, but I
find the newer tool perf to be more useful.


Thanks, I'll check that out.

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

Re: [osg-users] osgdem segmentation fault

[Mohammed Rashad]

still same error..

can you give me a step by step explanation

On Thu, Jan 26, 2012 at 11:27 PM, Robert Osfield
robert.osfi...@gmail.comwrote:

 On 26 January 2012 17:25, Mohammed Rashad mohammedrasha...@gmail.com
 wrote:
  how to rebuilt VPB agains NVTT SDK

 Go fetch NVTT from NVidia's website, install it.

 cd VirtualPlanetBuilder
 rm CMakeCache.txt  // to force it to search for dependencies a fresh
 ./configure
 make
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




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

Re: [osg-users] Request for input

[J.P. Delport]

Hi,

On 26/01/2012 20:02, Tim Moore wrote:

Btw, the Linux tool oprofile is mentioned later in the thread, but I
find the newer tool perf to be more useful.


niiice, new tools :) I've used gprof2dot with oprofile before to get a 
nice graphic view of execution. I see it supports perf too now, yay.


http://code.google.com/p/jrfonseca/wiki/Gprof2Dot#linux_perf

jp



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


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