Re: [osg-users] osgOcean 1.0 (LGPL) Released

[Jean-Sébastien Guay]

Hi Chris,


  I curious if you evaluated the (very free) DJBFFT library and if so, if you 
found it
insufficient. I know someone else who is evaluating FFT libraries and just 
wanted your
input if you had already tried it out and found it lacking.


Well, Kim had initially implemented osgOcean using FFTW, and searching 
for an easy replacement that would remove the GPL limitation, I found 
FFTSS which has an identical API, so the change was pretty painless 
(most of the work went into supporting compile-time choice between the 
two, not in actually supporting FFTSS).


I know Kim looked at a few others and had problems with badly documented 
API with KissFFT notably, but I don't know which others (if any) he 
checked out.


I read the articles on FFT benchmarking on DJBFFT's site, and especially 
noted that they were quite old. They say version 0.75 was released in 
1999, and the current version is 0.76. And also, their install docs 
state "The djbfft installation procedure assumes that you have a UNIX 
system with gcc." So that kind of put me off, personally, as I don't 
know if a library dating from 1999 and specifically made for gcc will 
support newer compilers and Windows... And if it really can be that 
optimized versus a current library that probably has special 
optimizations for newer chipsets/SSEx/...


It would be worth a try if we really wanted to compare speed and wanted 
another alternative. It should be easy to implement another option for 
choosing DJBFFT in addition to the 3 choices right now (FFTW 
single-precision, FFTW double-precision, FFTSS). But for now FFTW and 
FFTSS kind of fill the needs we have (one really fast, the other more 
flexible licensing-wise).


Hope that clears things up,

J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgOcean 1.0 (LGPL) Released

[Jean-Sébastien Guay]

Hi Alejandro,


But apparently it doesn't find the instaled resources, neither in the
bin directory (instaled there by default) nor in the OSG data
directory (where osgDB find things). Only finds them if I run it from
the source directory. 


Not sure about this, I think the easiest way right now is to put 
resources in a "resources" subdirectory of your current directory from 
which you run the executable. So you would have the executable, and in 
the same directory you'd have resources/shaders, resources/textures, 
resources/islands.


This is configurable if you're developing an app with osgOcean. Just add 
the path to the resources directory to the osgDB search paths and it 
will find its resources.



I got these output in the console:

Building scene...
  . Loading cubemaps: 0.321772s
  . Generating ocean surface: 0.000128s
  . Creating ocean scene: 0.001092s
  . Loading islands: cannot change type of Shader
cannot change type of Shader
0.08298s
  . Setting up lighting: 7.6e-05s
complete.
Time Taken: 0.406433s

Why it cannot change type of Shader?


Not sure what would cause this message. I'll have a look when I get back 
to my desk tomorrow morning.



I'm running it in a Debian GNU/Linux 2.6.26, 8GB RAM, OSG 2.9.3, NV
Quadro FX 1700.


Thanks for testing, and keep us informed of any cool things you do with 
osgOcean! :-)


J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgOcean 1.0 (LGPL) Released

[Chris 'Xenon' Hanson]

Kim C Bale wrote:
> Hi all,
> - FFT ocean simulation model and rendering
> - Choice of FFT library dependancy
> Possibly the most important change is that the library is now held under
> a LGPL license.
> The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL)
> for the FFT library dependancy which resolves the license issue. FFTW is
> the faster option, but the differance if fairly negliable within the
> context that it's used.

  I curious if you evaluated the (very free) DJBFFT library and if so, if you 
found it
insufficient. I know someone else who is evaluating FFT libraries and just 
wanted your
input if you had already tried it out and found it lacking.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"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] temporary emphasis/change of colors

[Chris 'Xenon' Hanson]

Jason Daly wrote:
> Butler, Lee Mr CIV USA USAMC wrote:
>> I want to highlight certain nodes (or de-emphasize others) without
>> killing performance (I'm at the lower limit already) or requiring a
>> second render pass.  Any good suggestions? 
>> I was thinking of setting temporary colors.  What is the appropriate OSG
>> way to change the color on something temporarily?  For example, setting
>> the color on "picked" items or "items not picked".  I'm thinking a
>> StateSet that gets applied to all the nodes?

  in similar situations, I've used fog as a way to highlight something without 
otherwise
disturbing the state of the underlying geometry. It can be easily toggled on an 
off at any
time.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"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] osgOcean 1.0 (LGPL) Released

[Alejandro Aguilar Sierra]

Nevermind, I made it compile.

It looks nice (see attached image) and is fast for a real time ocean simulation.

But apparently it doesn't find the instaled resources, neither in the
bin directory (instaled there by default) nor in the OSG data
directory (where osgDB find things). Only finds them if I run it from
the source directory. I got these output in the console:

Building scene...
  . Loading cubemaps: 0.321772s
  . Generating ocean surface: 0.000128s
  . Creating ocean scene: 0.001092s
  . Loading islands: cannot change type of Shader
cannot change type of Shader
0.08298s
  . Setting up lighting: 7.6e-05s
complete.
Time Taken: 0.406433s

Why it cannot change type of Shader?

I'm running it in a Debian GNU/Linux 2.6.26, 8GB RAM, OSG 2.9.3, NV
Quadro FX 1700.

Regards,

Alejandro



On Mon, Jun 15, 2009 at 5:53 PM, Alejandro Aguilar
Sierra wrote:
> Hi Kim,
>
> Great news, congratulations!
>
> To compile, is there a way to avoid using the debug libraries of
> openthreads, fftw and osgviewer?
>
> Regards,
>
> Alejandro
>
>
> On Mon, Jun 15, 2009 at 5:02 PM, Kim C Bale wrote:
>> Hi all,
>>
>> After much clawing and gnashing of teeth I've tagged version 1.0 of
>> osgOcean.
>>
>> http://code.google.com/p/osgocean/
>>
>> Feature list:
>>
>> - FFT ocean simulation model and rendering
>> - Foam caps
>> - Refraction/Reflection Passes
>> - God Rays
>> - Surface glare
>> - Underwater depth of field
>> - Underwater/above water fogging
>> - Simulated light absorption and scattering
>> - Silt effects
>> - Screen distortion effects
>> - Choice of FFT library dependancy
>>
>> Possibly the most important change is that the library is now held under a
>> LGPL license.
>>
>> The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for
>> the FFT library dependancy which resolves the license issue. FFTW is the
>> faster option, but the differance if fairly negliable within the context
>> that it's used.
>>
>> The library now searches for it's resource dependancies using the osgDB
>> registry so they're not bound to a specific path.
>>
>> I've also included a fix for the shader bug on 7 series nVidia cards which
>> caused an error when indexing arrays using uniform variables.
>>
>> The example application now supports real-time changes to the ocean surface
>> and effects so you can have a play with the settings to see what they do.
>>
>> A lot of the work has been submitted by Jean-Sebastian. If anybody else
>> would like to contribute do get in touch. Many hands make light work and all
>> that ;)
>>
>> For those of you that suggested features/enhancement that aren't in this
>> release, don't worry I haven't forgotten about them, they're still on my
>> list of things to do.
>>
>>
>> Regards,
>>
>>
>> Kim.
>>
>>
>> *
>> To view the terms under which this email is distributed, please go to
>> http://www.hull.ac.uk/legal/email_disclaimer.html
>> *
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
<>___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Render-To-Texture.

[Jason Daly]

Ignore me, I just found it...

--"J"



Guy Volckaert wrote:

Hi,

I was wondering is someone can help me with a specific problem I'm having with render-to-texture. In essence, I have a pre-render camera (i.e m_pRttCamera) that renders the entire scene to a rectangular texture (i.e m_pRttTexture). This texture is the mapped to a simple quad that fills the entire screen. 


The problem occurs when the user resizes the window (note: all's well before 
resizing the window). The result of resizing the window is a fully black scene.

I know that I need to "invalidate" the texture since the window size has 
changed. The following code gets called whenever the window is resized:


Code:

void CGeViewport::ResizeRtt( )
{
if( m_pRttTexture )
{
// Get the size of the main camera's viewport. This is *not* 
// the RTT camera.

int32 nWidth = m_pCamera->getViewport()->width();
int32 nHeight = m_pCamera->getViewport()->height();

// Resize the render-to-texture according to the viewports size.
m_pRttTexture->dirtyTextureObject( );
m_pRttTexture->setTextureSize( nWidth, nHeight );

// Adjust the quad's texture coordinates.
osg::Vec2Array* pTexCoords = (osg::Vec2Array*)( 
m_pRttQuad->getTexCoordArray( 0 ) );
(*pTexCoords)[1].set( 0, 0 );
(*pTexCoords)[1].set( nWidth, 0 );
(*pTexCoords)[2].set( nWidth, nHeight );
(*pTexCoords)[3].set( 0, nHeight );
}
}




The viewport of the RTT camera is the same as the main camera. To do so, I call 
the following function:

m_pRttCamera->setViewport( m_pCamera->getViewport( ) );

I tried several things but nothing worked. Any advice would be appreciated.

Cheers,
Guy

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





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

[Jason Daly]

Hi, Guy,

Great explanation, except you didn't say what the problem was  :-)

--"J"



Guy Volckaert wrote:

Hi,

I was wondering is someone can help me with a specific problem I'm having with render-to-texture. In essence, I have a pre-render camera (i.e m_pRttCamera) that renders the entire scene to a rectangular texture (i.e m_pRttTexture). This texture is the mapped to a simple quad that fills the entire screen. 


The problem occurs when the user resizes the window (note: all's well before 
resizing the window). The result of resizing the window is a fully black scene.

I know that I need to "invalidate" the texture since the window size has 
changed. The following code gets called whenever the window is resized:


Code:

void CGeViewport::ResizeRtt( )
{
if( m_pRttTexture )
{
// Get the size of the main camera's viewport. This is *not* 
// the RTT camera.

int32 nWidth = m_pCamera->getViewport()->width();
int32 nHeight = m_pCamera->getViewport()->height();

// Resize the render-to-texture according to the viewports size.
m_pRttTexture->dirtyTextureObject( );
m_pRttTexture->setTextureSize( nWidth, nHeight );

// Adjust the quad's texture coordinates.
osg::Vec2Array* pTexCoords = (osg::Vec2Array*)( 
m_pRttQuad->getTexCoordArray( 0 ) );
(*pTexCoords)[1].set( 0, 0 );
(*pTexCoords)[1].set( nWidth, 0 );
(*pTexCoords)[2].set( nWidth, nHeight );
(*pTexCoords)[3].set( 0, nHeight );
}
}




The viewport of the RTT camera is the same as the main camera. To do so, I call 
the following function:

m_pRttCamera->setViewport( m_pCamera->getViewport( ) );

I tried several things but nothing worked. Any advice would be appreciated.

Cheers,
Guy

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





___
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] Render-To-Texture.

[Guy Volckaert]

Hi,

I was wondering is someone can help me with a specific problem I'm having with 
render-to-texture. In essence, I have a pre-render camera (i.e m_pRttCamera) 
that renders the entire scene to a rectangular texture (i.e m_pRttTexture). 
This texture is the mapped to a simple quad that fills the entire screen. 

The problem occurs when the user resizes the window (note: all's well before 
resizing the window). The result of resizing the window is a fully black scene.

I know that I need to "invalidate" the texture since the window size has 
changed. The following code gets called whenever the window is resized:


Code:

void CGeViewport::ResizeRtt( )
{
if( m_pRttTexture )
{
// Get the size of the main camera's viewport. This is *not* 
// the RTT camera.
int32 nWidth = m_pCamera->getViewport()->width();
int32 nHeight = m_pCamera->getViewport()->height();

// Resize the render-to-texture according to the viewports size.
m_pRttTexture->dirtyTextureObject( );
m_pRttTexture->setTextureSize( nWidth, nHeight );

// Adjust the quad's texture coordinates.
osg::Vec2Array* pTexCoords = (osg::Vec2Array*)( 
m_pRttQuad->getTexCoordArray( 0 ) );
(*pTexCoords)[1].set( 0, 0 );
(*pTexCoords)[1].set( nWidth, 0 );
(*pTexCoords)[2].set( nWidth, nHeight );
(*pTexCoords)[3].set( 0, nHeight );
}
}




The viewport of the RTT camera is the same as the main camera. To do so, I call 
the following function:

m_pRttCamera->setViewport( m_pCamera->getViewport( ) );

I tried several things but nothing worked. Any advice would be appreciated.

Cheers,
Guy

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





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

Re: [osg-users] temporary emphasis/change of colors

[Jason Daly]

Butler, Lee Mr CIV USA USAMC wrote:

I want to highlight certain nodes (or de-emphasize others) without
killing performance (I'm at the lower limit already) or requiring a
second render pass.  Any good suggestions?  


I was thinking of setting temporary colors.  What is the appropriate OSG
way to change the color on something temporarily?  For example, setting
the color on "picked" items or "items not picked".  I'm thinking a
StateSet that gets applied to all the nodes?  
  


Easiest way would be to use an osg::Material in OVERRIDE mode.  For 
example, this would turn all of the geometry bright red (regardless of 
lighting):



osg::StateSet *ss = pickedNode->getOrCreateStateSet();
osg::Material *mtl = new osg::Material():
mtl->setAmbient(osg::Material::FRONT_AND_BACK,
   osg::Vec4(0.0, 0.0, 0.0, 1.0));
mtl->setDiffuse(osg::Material::FRONT_AND_BACK,
   osg::Vec4(0.0, 0.0, 0.0, 1.0));
mtl->setSpecular(osg::Material::FRONT_AND_BACK,
osg::Vec4(0.0, 0.0, 0.0, 1.0));
mtl->setEmission(osg::Material::FRONT_AND_BACK,
osg::Vec4(1.0, 0.0, 0.0, 1.0));
ss->setAttributeAndModes(mtl, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE);


--"J"


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

Re: [osg-users] osgOcean 1.0 (LGPL) Released

[Alejandro Aguilar Sierra]

Hi Kim,

Great news, congratulations!

To compile, is there a way to avoid using the debug libraries of
openthreads, fftw and osgviewer?

Regards,

Alejandro


On Mon, Jun 15, 2009 at 5:02 PM, Kim C Bale wrote:
> Hi all,
>
> After much clawing and gnashing of teeth I've tagged version 1.0 of
> osgOcean.
>
> http://code.google.com/p/osgocean/
>
> Feature list:
>
> - FFT ocean simulation model and rendering
> - Foam caps
> - Refraction/Reflection Passes
> - God Rays
> - Surface glare
> - Underwater depth of field
> - Underwater/above water fogging
> - Simulated light absorption and scattering
> - Silt effects
> - Screen distortion effects
> - Choice of FFT library dependancy
>
> Possibly the most important change is that the library is now held under a
> LGPL license.
>
> The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for
> the FFT library dependancy which resolves the license issue. FFTW is the
> faster option, but the differance if fairly negliable within the context
> that it's used.
>
> The library now searches for it's resource dependancies using the osgDB
> registry so they're not bound to a specific path.
>
> I've also included a fix for the shader bug on 7 series nVidia cards which
> caused an error when indexing arrays using uniform variables.
>
> The example application now supports real-time changes to the ocean surface
> and effects so you can have a play with the settings to see what they do.
>
> A lot of the work has been submitted by Jean-Sebastian. If anybody else
> would like to contribute do get in touch. Many hands make light work and all
> that ;)
>
> For those of you that suggested features/enhancement that aren't in this
> release, don't worry I haven't forgotten about them, they're still on my
> list of things to do.
>
>
> Regards,
>
>
> Kim.
>
>
> *
> To view the terms under which this email is distributed, please go to
> http://www.hull.ac.uk/legal/email_disclaimer.html
> *
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] temporary emphasis/change of colors

[Butler, Lee Mr CIV USA USAMC]

I want to highlight certain nodes (or de-emphasize others) without
killing performance (I'm at the lower limit already) or requiring a
second render pass.  Any good suggestions?  

I was thinking of setting temporary colors.  What is the appropriate OSG
way to change the color on something temporarily?  For example, setting
the color on "picked" items or "items not picked".  I'm thinking a
StateSet that gets applied to all the nodes?  

Lee

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

Re: [osg-users] ATI cards and openscenegraph

[Rodrigo Salvador]

Hi, Peted

I have worked with an ATI card for months, and I have found only one issue: If 
you add shadows to the scene, they may be inverted.

Cheers,
Rodrigo

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





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

[osg-users] osgOcean 1.0 (LGPL) Released

[Kim C Bale]

Hi all,
 
After much clawing and gnashing of teeth I've tagged version 1.0 of osgOcean. 
 
http://code.google.com/p/osgocean/  
 
Feature list:
 
- FFT ocean simulation model and rendering
- Foam caps
- Refraction/Reflection Passes
- God Rays
- Surface glare
- Underwater depth of field
- Underwater/above water fogging
- Simulated light absorption and scattering
- Silt effects
- Screen distortion effects
- Choice of FFT library dependancy
 
Possibly the most important change is that the library is now held under a LGPL 
license. 
 
The CMake build now offers the choice between FFTW (GPL) or FFTSS (LGPL) for 
the FFT library dependancy which resolves the license issue. FFTW is the faster 
option, but the differance if fairly negliable within the context that it's 
used. 
 
The library now searches for it's resource dependancies using the osgDB 
registry so they're not bound to a specific path.
 
I've also included a fix for the shader bug on 7 series nVidia cards which 
caused an error when indexing arrays using uniform variables. 
 
The example application now supports real-time changes to the ocean surface and 
effects so you can have a play with the settings to see what they do.
 
A lot of the work has been submitted by Jean-Sebastian. If anybody else would 
like to contribute do get in touch. Many hands make light work and all that ;)
 
For those of you that suggested features/enhancement that aren't in this 
release, don't worry I haven't forgotten about them, they're still on my list 
of things to do.
 
 
Regards,
 
 
Kim.
 
 
*
To view the terms under which this email is distributed, please go to 
http://www.hull.ac.uk/legal/email_disclaimer.html
*___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] ViewerBase::stopThreading() and renderers

[Cory Riddell]

ViewerBase::stopThreading() includes this block of code:

  for(Cameras::iterator camItr = cameras.begin();
  camItr != cameras.end();
  ++camItr)
  {
  osg::Camera* camera = *camItr;
  Renderer* renderer =
dynamic_cast(camera->getRenderer());
  if (renderer)
  {
  renderer->setGraphicsThreadDoesCull( true );
  renderer->setDone(false);
  }
  }

Since threading is being stopped, shouldn't the line in red be setting
done to true? 

Cory


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

[osg-users] CMake 2.6 for RHEL 5/CentOS 5

[Jason Daly]

Well, what do you know?  All that fuss and now there's a CMake 2.6 RPM 
available.  I swear I checked just two weeks ago and it wasn't there.  
It figures... :-)


http://www.atrpms.net/dist/el5/cmake


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

Re: [osg-users] SVG plugin

[Jason Daly]

Vincent Bourdier wrote:

Hi all,

I saw in the osg 2.6 release log a svg plugin.
But, it does not appear in the cmake config or in the compiled plugin 
and 3rd parties.


So i can assume there are some external dependencies, or a special 
procedure to install it... but I did'nt found anything.

So the first question is : how to get it ?

And my second question : does the .svg file is imported into OSG as a 
texture ? an Image ? a sceneGraph ? what kind of osg elements does the 
importer return ?


A quick look at the source code shows that the plugin is called with 
osgDB::readImageFile(), and hence returns an osg::Image. 

Based on the #include's, it looks like the plugin requires librsvg and 
cairo.


--"J"

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

[osg-users] should ViewerBase::_done be volatile?

[Cory Riddell]

Subject says it all: shouldn't the done flag be volatile? If it isn't,
how can you be certain that the viewer thread will ever notice it has
changed from false to true?

Some context here: I call ViewerBase::run() in its own thread. To shut
it down, I call viewerBase->setDone(true) from my main thread.

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

Re: [osg-users] VPB refusal to build under certain conditions

[Chris 'Xenon' Hanson]

Robert Osfield wrote:
> I haven't seen this problem myself, and have built a wide range of
> small to whole earth databases so there must be something specific
> about the options/source data you are using.   Would it be possible to
> post a test dataset and osgdem options used online so others can test
> it?

  I'm sending you this dataset privately under separate cover with instructions.

> Robert.

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"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] Annotating large numbers of objects

[Chris 'Xenon' Hanson]

Andrew Cunningham wrote:
> Hi Chris,
> Thanks for the suggestion - I am backed into a corner a bit by the need to 
> support access via  Windows RDC ( remote desktop connection) which works 
> quite well for small/medium models but only supports basic OpenGL(1.1?) 
> without shaders. Of course I can test for that and use an alternative 
> approach.

  Perhaps you could use some sort of LOD mechanism or culling visitor to defer 
the
creation of the Text annotations until they would become visible?

> Andrew

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"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] Annotating large numbers of objects

[Andrew Cunningham]

Hi Chris,
Thanks for the suggestion - I am backed into a corner a bit by the need to 
support access via  Windows RDC ( remote desktop connection) which works quite 
well for small/medium models but only supports basic OpenGL(1.1?) without 
shaders. Of course I can test for that and use an alternative approach.

Andrew

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





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

Re: [osg-users] Annotating large numbers of objects

[Chris 'Xenon' Hanson]

Andrew Cunningham wrote:
> Hi,
> I need to label or annotate large numbers of 3D locations  with a short label 
> like a number. Think possibly 100,000+ locations or nodes (for example, 
> represented as small cubes). I naively used osg::Text to create labels and 
> ended up consuming 100's of MB of memory. 
> This seems like a case where I should perhaps derive my own drawable (or 
> geode?) perhaps and draw things 'on the fly' rather than creating huge 
> numbers of objects. The old trade-off of memory vs speed of drawing. Any 
> suggestions from those who have been there before??

  I think a GLSL shader could do this on-the-fly efficiently. I think there's 
an example
of such a text shader in The Orange Book.

> Thanks
> Andrew

-- 
Chris 'Xenon' Hanson, omo sanza lettere  Xenon AlphaPixel.com
PixelSense Landsat processing now available! http://www.alphapixel.com/demos/
"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

[osg-users] Annotating large numbers of objects

[Andrew Cunningham]

Hi,
I need to label or annotate large numbers of 3D locations  with a short label 
like a number. Think possibly 100,000+ locations or nodes (for example, 
represented as small cubes). I naively used osg::Text to create labels and 
ended up consuming 100's of MB of memory. 
This seems like a case where I should perhaps derive my own drawable (or 
geode?) perhaps and draw things 'on the fly' rather than creating huge numbers 
of objects. The old trade-off of memory vs speed of drawing. Any suggestions 
from those who have been there before??


Thanks
Andrew

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





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

Re: [osg-users] zbuffer issue

[Christian Sam]

Hi, thanks for all the reply

like colin noted, the render problem vanished as i stripped off the offsets 
which caused the large coordinates and work now with "localized" coordinates.

if i ever need to display the real coordinates in an text-insert, i can re-add 
the stripped offset before display them.

Thank you!

Cheers,
Christian

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





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

Re: [osg-users] Writing to an image file

[Benoît Bayol]

Hi,

I have the same problem than Amanda.
I am creating a class SimpleBillboard which load a Model, create an ortho 
projection of it and a Quad and try to put the texture projeted onto that quad.

I think that Amanda try to output the texture loaded into an image file.
The problem is that after the allocation of the image, we write our image but 
there is no information in the buffer at this point. Because the loop has not 
started may be.

So the question should be :
How I can force OSG to render the texture into the buffer and then put it into 
the image. And not waiting for the loop. Is callback could be usefull here ?

Thank you!

Cheers,
Benoît


-- 
Benoît Bayol
benoit.ba...@gmail.com

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





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

Re: [osg-users] Using the z Buffer

[Tomlinson, Gordon]

See http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html

The values in the Zbuffer is 1.0 to 0.0 ( all realworld  values are
transformed in to this )  but it is NOT linear 


Gordon
Product Manager 3d
__
Gordon Tomlinson
Email  : gtomlinson @ overwatch.textron.com
__


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Roland
Leitner
Sent: Monday, June 15, 2009 3:29 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] Using the z Buffer

Hi folks,

I am using the z-Buffer in osg 2.4 and have problems getting reasonable
values. When the camera is about two meters away from any flat object
surface, I'll get the value 0.995, and when the camera  is about eight
meters away i'll get 0.997 from the z buffer. I have also tried to
transform the z value into a distance value, but the distance value
makes no sense! Below is my code!

Cheers, Roland

osgViewer::View* view = new osgViewer::View; viewer.addView(view);

view->setSceneData(root);
 
view->getCamera()->setProjectionMatrixAsPerspective(V_FoV_deg,V_FoV_deg/
H_FoV_deg,1,100);
view->getCamera()->setViewport(new osg::Viewport(traits->width/2,0, 64, 
view->48 )); getCamera()->setGraphicsContext(gc.get());

osg::Image* image = new osg::Image();
view->getCamera()->attach(osg::Camera::DEPTH_BUFFER,image);

image->allocateImage(64,48,1,GL_DEPTH_COMPONENT,GL_FLOAT);

float z;

while( !viewer.done() )
{
   viewer.frame();

z = ((float*)pmdimage->data())[1];
std::cout << "z value : " << z << std::endl; }

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





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

[osg-users] SVG plugin

[Vincent Bourdier]

Hi all,

I saw in the osg 2.6 release log a svg plugin.
But, it does not appear in the cmake config or in the compiled plugin and
3rd parties.

So i can assume there are some external dependencies, or a special procedure
to install it... but I did'nt found anything.
So the first question is : how to get it ?

And my second question : does the .svg file is imported into OSG as a
texture ? an Image ? a sceneGraph ? what kind of osg elements does the
importer return ?

Thanks.

Regards,
   Vincent

PS : I use osg 2.8.1 under win XP with VS2008 sp1
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] Can't build libraries under windows

[stefan nortd]

Hey Ümit,
Thanks for your answer.
It's actually not that complicated. jonim8or compiled osg for mingw and posted 
it online. Unfortunately the link above in the thread is down. I was just 
wondering if these mingw binaries can be made available again. I think people 
would find them useful including me ;)

I am trying to get an osg app cross-platform (xcode, code::blocks linux, VS9, 
code::blocks mingw) and would be happy to take this shortcut.

/stefanix

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





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

Re: [osg-users] Using the z Buffer

[Robert Osfield]

On Mon, Jun 15, 2009 at 11:13 AM, Roland Leitner wrote:
> Thanks Robert. Do you think the problem exists, because of not clearing the z 
> buffer at the beginning?

Sorry I have no clue as you didn't mention anything about switching
off zbuffer clear, the code you included mentions nothing about it
either.

I really can't help you much with such sketchy info.  Please go search
the archives for reading the z buffer, others have done it before you
and the discussion will probably help you much more than trying to
convey what exactly your are doing and expecting others to debug this.

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

Re: [osg-users] zbuffer issue

[Colin Rayment]

Christian

I have noticed a similar effect when having large coordinates. I think it’s a 
precision issue. Having objects or polygons that are overlapping or co-planar 
with large coordinates will give you z-fighting. Its best to group the related 
objects under a transform node which provides the overall offset and then the 
individual objects are just defined relative to the origin of the transform 
node.

Colin Rayment

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Christian Sam
Sent: 14 June 2009 23:07
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] zbuffer issue

Hi community,

i noticed an annoying rendering problem in my application. my application is 
based on the osgforest example, with the difference that not every tree is 
represented with its own drawable, but many trees are merge into a handful of 
drawables, placed at a regular-grid.

the rendering problem occurs only when i use real-world coordinates for the 
tree postions: e.g. 683006, 213213, 0. instead of "localized" equivalent of  6, 
213, 0 and when using the approach described above. 
there are no problems when i use such large coordinates with "one-drawable per 
tree", like in the original osgforest implementation.

it happens when i zoom in very near, the trees (only the trees, not the terrain 
or anything else) begin to flicker and overlapped faces of the tree's 
double-quads gets revealed, while others gets hidden. after i zoom out, 
rendering problems stops.

maybe some z-buffer resolution related issue? i hope i described it in a way 
you can imagine it. if not i can send the whole example/resources.

btw. i'm using osg-2.8.0

best regards,
christian

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





This email has been scanned for all known viruses by the MessageLabs Email 
Security System.

Please help out the environment by only printing this e-mail if absolutely 
necessary - Thank You.

This email has been scanned for all known viruses by the MessageLabs Email 
Security System.

Systems Engineering & Assessment Ltd - Beckington Castle, 17 Castle Corner, 
Beckington, Frome, Somerset, BA11 6TA, UK 
is registered in England and Wales with the company number 2430846.

The contents of this email (including any attachments) are confidential and may 
be legally privileged. 

If you are not the intended recipient of this email any disclosure, copying, 
distribution or use of its contents is strictly prohibited.  You should notify 
the sender immediately and then delete it (including any attachments) from your 
system.

Please help out the environment by only printing this e-mail if absolutely 
necessary - Thank You.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Using the z Buffer

[Roland Leitner]

Thanks Robert. Do you think the problem exists, because of not clearing the z 
buffer at the beginning?

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





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

Re: [osg-users] Using the z Buffer

[Robert Osfield]

Hi Roland,

A couple of points.  First up if the CompositeViewer is being run
multi-theaded then the draw traversal may not be complete, and the
values not copied yet to the osg::Image by the time your frame loop
reaches your image data output line.  In this context it probably will
just mean getting values a bit out of step with the current frame, but
it is a potential cause for threading issues that you should be
careful about.

W.r.t distance values, are you expecting them to be in eye coords?  If
so you'll need to transform using the near/far distances of the
current projection matrix.  I can't recall the equation off the top of
my head but it's something you should be able to derive from docs on
OpenGL.

Robert.

On Mon, Jun 15, 2009 at 8:28 AM, Roland Leitner wrote:
> Hi folks,
>
> I am using the z-Buffer in osg 2.4 and have problems getting reasonable 
> values. When the camera is about two meters away from any flat object 
> surface, I'll get the value 0.995, and when the camera  is about eight meters 
> away i'll get 0.997 from the z buffer. I have also tried to transform the z 
> value into a distance value, but the distance value makes no sense! Below is 
> my code!
>
> Cheers, Roland
>
> osgViewer::View* view = new osgViewer::View;
> viewer.addView(view);
>
> view->setSceneData(root);
>   
> view->getCamera()->setProjectionMatrixAsPerspective(V_FoV_deg,V_FoV_deg/H_FoV_deg,1,100);
> view->getCamera()->setViewport(new osg::Viewport(traits->width/2,0, 64, 48 ));
> view->getCamera()->setGraphicsContext(gc.get());
>
> osg::Image* image = new osg::Image();
> view->getCamera()->attach(osg::Camera::DEPTH_BUFFER,image);
>
> image->allocateImage(64,48,1,GL_DEPTH_COMPONENT,GL_FLOAT);
>
> float z;
>
> while( !viewer.done() )
> {
>   viewer.frame();
>
>    z = ((float*)pmdimage->data())[1];
>    std::cout << "z value : " << z << std::endl;
> }
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13976#13976
>
>
>
>
>
> ___
> 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] OSGSpotLight example on a GLSL material

[Robert Osfield]

HI Albino,

I'm not quite sure where to start... your GLSL shader doesn't seem to
have any reference whatsoever to projective texture coord setup in the
vertex shader or application of the projective texture in the fragment
shader.  To me this suggests that you haven't yet learnt enough about
the way GLSL shaders work.  GLSL shaders replace the fixed function
pipeline entirely, which means techniques like ones used in the spot
light that used the fixed function pipeline will need to replicated in
your GLSL shader.

Robert.

On Mon, Jun 15, 2009 at 1:20 AM, Albino Rodrigues wrote:
> Hi,
>
>>>Try including the vertex and fragment shaders you are using then
>>>others might have a chance of spotting what is up.
>
> My apologies for the lack of source code.
>
> The Normal Vertex Map Shader:
>
> varying vec3 lightVec;
> varying vec3 eyeVec;
> varying vec2 texCoord;
> attribute vec3 tangent;
>
>
> void main(void)
> {
>        gl_Position = ftransform();
>        texCoord = gl_MultiTexCoord0.xy;
>
>        vec3 n = normalize(gl_NormalMatrix * gl_Normal);
>        vec3 t = normalize(gl_NormalMatrix * tangent);
>        vec3 b = cross(n, t);
>
>        vec3 vVertex = vec3(gl_ModelViewMatrix * gl_Vertex);
>        vec3 tmpVec = gl_LightSource[0].position.xyz - vVertex;
>
>        lightVec.x = dot(tmpVec, t);
>        lightVec.y = dot(tmpVec, b);
>        lightVec.z = dot(tmpVec, n);
>
>        tmpVec = -vVertex;
>        eyeVec.x = dot(tmpVec, t);
>        eyeVec.y = dot(tmpVec, b);
>        eyeVec.z = dot(tmpVec, n);
> }
>
>
> The Normal Fragment Map Shader:
>
>
> varying vec3 lightVec;
> varying vec3 eyeVec;
> varying vec2 texCoord;
> uniform sampler2D diffuseMap;
> uniform sampler2D normalMap;
> uniform float lightFallOff;
>
> void main (void)
> {
>        float distSqr = dot(lightVec, lightVec);
>        float att = clamp(1.0 - lightFallOff * sqrt(distSqr), 0.0, 1.0);
>        vec3 lVec = lightVec * inversesqrt(distSqr);
>
>        vec3 vVec = normalize(eyeVec);
>
>        vec4 base = texture2D(diffuseMap, texCoord.xy);
>
>        vec3 bump = normalize( texture2D(normalMap, texCoord.xy).xyz * 2.0 -
> 1.0);
>
>        vec4 vAmbient = gl_LightSource[0].ambient *
> gl_FrontMaterial.ambient;
>
>        float diffuse = max( dot(lVec, bump), 0.0 );
>
>        vec4 vDiffuse = gl_LightSource[0].diffuse * gl_FrontMaterial.diffuse
> *
>                                        diffuse;
>
>        float specular = pow(clamp(dot(reflect(-lVec, bump), vVec), 0.0,
> 1.0),
>                         gl_FrontMaterial.shininess );
>
>        vec4 vSpecular = gl_LightSource[0].specular *
> gl_FrontMaterial.specular *
>                                         specular;
>
>        vec3 color = vec3(( vAmbient*base +
>                                         vDiffuse*base +
>                                         vSpecular) * att);
>
>
>        gl_FragColor = vec4(color,gl_FrontMaterial.ambient.a);
>        gl_FragColor = mix(base, colour, gl_FrontMaterial.ambient.a);
>        gl_FragColor = vec4(1,0,0,1);
> }
>
> -Original Message-
> From: osg-users-boun...@lists.openscenegraph.org
> [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
> Osfield
> Sent: Friday, 12 June 2009 6:10 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] OSGSpotLight example on a GLSL material
>
> Hi Bino,
>
> I can't see how many of us will be able divine what is up with your
> shaders as we have absolutely no knowledge of what you've put into
> your shader.   You question is equivalent to "I have a piece of string
> you can't see, but can you tell me exactly how long it is".
>
> Try including the vertex and fragment shaders you are using then
> others might have a chance of spotting what is up.
>
> Robert.
>
> On Fri, Jun 12, 2009 at 6:28 AM, Albino Rodrigues
> wrote:
>> Hi,
>>
>>
>>
>> I have been using the OSGSpotLight example as a starting base to simulate
> a
>> flashlight with success.
>>
>>
>>
>> The scene I was using has now been updated to be drawn with a GLSL
> NormalMap
>> shader (included as part of the .ive). The spotlight can no longer be
> seen.
>> It does however appear to affect the general lighting of the area it's in,
>> but the spotlight and the texture image that goes with it can no longer be
>> seen.
>>
>>
>>
>> Any ideas on how to get around this would be much appreciated.
>>
>>
>>
>> Cheers,
>>
>> Bino
>>
>>
>>
>>
>>
>>
>>
>> ___
>> 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] zbuffer issue

[Robert Osfield]

Hi Christian,

I really doubt you have a general z-buffer issue, but from the
pictures is looks like you have problems with geometry that is
overlapping that shouldn't be. Any chance that you are accidentally
creating quads that overlap in your code?

Robert.


On Sun, Jun 14, 2009 at 11:06 PM, Christian Sam wrote:
> Hi community,
>
> i noticed an annoying rendering problem in my application. my application is 
> based on the osgforest example, with the difference that not every tree is 
> represented with its own drawable, but many trees are merge into a handful of 
> drawables, placed at a regular-grid.
>
> the rendering problem occurs only when i use real-world coordinates for the 
> tree postions: e.g. 683006, 213213, 0. instead of "localized" equivalent of  
> 6, 213, 0 and when using the approach described above.
> there are no problems when i use such large coordinates with "one-drawable 
> per tree", like in the original osgforest implementation.
>
> it happens when i zoom in very near, the trees (only the trees, not the 
> terrain or anything else) begin to flicker and overlapped faces of the tree's 
> double-quads gets revealed, while others gets hidden. after i zoom out, 
> rendering problems stops.
>
> maybe some z-buffer resolution related issue? i hope i described it in a way 
> you can imagine it. if not i can send the whole example/resources.
>
> btw. i'm using osg-2.8.0
>
> best regards,
> christian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13967#13967
>
>
>
>
> ___
> 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] MatrixManipulator::home(double) doesn't seem to work

[Robert Osfield]

Hi Brian,

When setting the home position use :

  viewer.getCameraManipualtor()->setHomePosition(..);


And when you want to move to this position use:

  viewer.home();

Robert.

On Sun, Jun 14, 2009 at 11:25 PM, Brian Stewart wrote:
> Hi,
>
> I am trying to reset my viewer's position in response to an external UI event 
> using the home(double) function on MatrixManipulator, but to no avail. The 
> call to setHomePosition() is working correctly, as I can hit the spacebar, 
> and it takes me to the proper location. The online page for MatrixManipulator 
> does not say what the double parameter does, but a comment in the code says 
> it is the current time. I tried passing in viewer->elapsedTime() and then I 
> tried 0.0 - and neither seemed to work. On digging through the code, it 
> appears that KeyswitchMatrixManipulator does not actually implement this 
> function (at least in my version of OSG - 2.6.1). I then tried getting the 
> current MatrixManipulator from it and calling home(double) directly on that - 
> still with no effect.
>
> Am I doing something wrong? Is there a better way to set the view to a 
> desired location and orientation? Is this a bug that's been fixed in a more 
> recent version?
>
> Thank you!
>
> Cheers,
> Brian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13969#13969
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Using the z Buffer

[Roland Leitner]

Hi folks,

I am using the z-Buffer in osg 2.4 and have problems getting reasonable values. 
When the camera is about two meters away from any flat object surface, I'll get 
the value 0.995, and when the camera  is about eight meters away i'll get 0.997 
from the z buffer. I have also tried to transform the z value into a distance 
value, but the distance value makes no sense! Below is my code!

Cheers, Roland

osgViewer::View* view = new osgViewer::View; 
viewer.addView(view);

view->setSceneData(root); 
   
view->getCamera()->setProjectionMatrixAsPerspective(V_FoV_deg,V_FoV_deg/H_FoV_deg,1,100);
view->getCamera()->setViewport(new osg::Viewport(traits->width/2,0, 64, 48 )); 
view->getCamera()->setGraphicsContext(gc.get());

osg::Image* image = new osg::Image();
view->getCamera()->attach(osg::Camera::DEPTH_BUFFER,image);

image->allocateImage(64,48,1,GL_DEPTH_COMPONENT,GL_FLOAT);

float z;

while( !viewer.done() )
{
   viewer.frame();

z = ((float*)pmdimage->data())[1];
std::cout << "z value : " << z << std::endl;
}

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





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