date:20090807

The XXXd.dll is the debug version, it will be used by the debug build of osg.

Don't know why you don't have the release version.
As a test I think you should just be able to copy the debug dll to 
osgdb_jpeg.dll (although this might depend on how forgiving your compiler is)

Cheers,
Martin

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





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

Re: [osg-users] [osgPlugins] Unable to load plugin for jpeg file....

2009-08-07 Thread manish Choudhary

Hi,
I have osgdb_jpegd.dll and it directory is currently set


I have used other image plugin for *.rgb,*.bmp , it was working correctly for 
them
I have seen tht for *.rgb file it was using two dll i.e osgdb_rgbd.dll and 
osgdb_rgb.dll and it required both these dll.
same case i find for *.bmp file...  


But for *.jpef i have only osgdb_jpegd.dll  in the required directory ..

Is this because of not having osgdb_jpeg.dll  ,I'm finding this warning[could 
not find plugin to load *.jpeg file] ?  

or else there is other problem for this warning?

if this is the problem then where can i get this osdb_jpeg.dll 

plz help me in this regard

 

Thank you!

Cheers,
manish

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





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

Re: [osg-users] Hello from New Orleans

2009-08-07 Thread Hansoo Kim

Great time in BOF, Happy to meet many OSG users (especially over 2000 
friends in China) :D

Maybe I have to trip 26hrs again to return, but it's no matter.
I hope that I'm there in 2010.

Hansoo Kim.
Konkuk Univ., Korea.


Wang Rui 쓴 글:

Hi,
I'm in Seattle now, and will be back to China in 1-2 days. Really glad 
to meet many friends at the BOF. Hope to see you again next year, 
although it's diffcult to apply for visa here. :)

Wang Rui
2009/8/6 Paul MARTZ >


OSG BOF was a success. Attendance was light, 65 people, but
overall conference attendance was down this year. Traveling today,
more later including photos.

Paul Martz
Skew Matrix Software
http://www.skew-matrix.com 
+1 303 859 9466

___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




___
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] RTT with FBO then copy Texture to image using PBO results in blank image.

2009-08-07 Thread Steven Powers

Hi,

I should add that the RTT Texture is attached to one of two osg::Cameras in the 
scene.



Thank you!

Cheers,
Steven

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





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

[osg-users] RTT with FBO then copy Texture to image using PBO results in blank image.

2009-08-07 Thread Steven Powers

Hi,
using OSG 2.2

I'm currently rendering to a texture using a FBO with an attached texture:

Code:

_texture = new osg::Texture2D();
_texture->setTextureSize((int)_camera->getViewport()->width(),(int)_camera->getViewport()->height());
_texture->setFilter(osg::Texture2D::MIN_FILTER,osg::Texture2D::LINEAR);
_texture->setFilter(osg::Texture2D::MAG_FILTER,osg::Texture2D::LINEAR);
_camera->attach(osg::Camera::COLOR_BUFFER, _texture.get(), 0,0,false);
_camera->setRenderTargetImplementation(osg::Camera::FRAME_BUFFER_OBJECT);
_camera->setRenderOrder(osg::Camera::PRE_RENDER);




A 3rd party lib processes the texture in a postCallBack call:


Code:

virtual void operator()(const osg::Camera &cam) const
{
if (cam.isRenderToTextureCamera())
{
osg::Camera::BufferAttachmentMap bam = cam.getBufferAttachmentMap();
osg::Camera::BufferAttachmentMap::iterator iter = 
bam.find(osg::Camera::COLOR_BUFFER);
if (iter != bam.end())
{
osg::Texture *tex = iter->second._texture.get();
if (tex)
{
osg::Texture::TextureObject *texObj = ((osg::Texture2D 
*)tex)->getTextureObject(0);
int id = ((osg::Texture2D *)tex)->getTextureObject(0)->_id;

//do some processing here

copyToImage(cam, tex);
} 
}




My copyToImage() method creates a PBO to the texture and attempt to dump the 
memory into an associated osg::Image (really just a block of memory). This code 
was used to pull from the frame buffer using ReadPixels() which worked fine.


Code:


void copyToImage(const osg::Camera &camera, osg::Texture* tex = 
NULL) const
{

if (image.valid() && image->data())
{
int pixel_depth_bytes;
OpenThreads::ScopedLock 
lock(_mutex);

const osg::GraphicsContext *gc = 
camera.getGraphicsContext();
osg::BufferObject::Extensions* ext = 
osg::BufferObject::getExtensions(gc->getState()->getContextID(), true);
if (ext->isPBOSupported())
{
if (gc->getTraits())
{
int width = 
(int)camera.getViewport()->width();//gc->getTraits()->width;
int height = 
(int)camera.getViewport()->height();//gc->getTraits()->height;
int x = 
(int)camera.getViewport()->x();
int y = 
(int)camera.getViewport()->y();
pixel_depth_bytes = 
gc->getTraits()->depth / 8;

if (width != _width || height 
!= _height || x != _x || y != _y)
{
_width = width;
_height = height;
_x = x;
_y = y;
if (_pbo)
{

ext->glDeleteBuffers(1,&_pbo);
_pbo = 0;
}
}
}

//disable clamping
osg::ClampColor::Extensions *clamp_ext 
= osg::ClampColor::getExtensions(gc->getState()->getContextID(), true);
if (clamp_ext->isClampColorSupported())
{
clamp_ext->glClampColor( 
GL_CLAMP_READ_COLOR, GL_FALSE );
clamp_ext->glClampColor( 
GL_CLAMP_VERTEX_COLOR, GL_FALSE );
clamp_ext->glClampColor( 
GL_CLAMP_FRAGMENT_COLOR, GL_FALSE );
}

glReadBuffer(GL_BACK);

//configure pbo
unsigned int data_size = _width * 
_height * sizeof(float) * 4;
if (_pbo)
{
//bind for writing (pack)

ext->glBindBuffer(GL_PIXEL_PACK_BUFFER, _pbo);
} else
{
//create and bind for writing 
(pack)

Re: [osg-users] glMultiTexCoord4f , OSG with OGL code

2009-08-07 Thread Pau Moreno

Hi,

Thanks Ulrich, but I think this set one parameter for each vertex, and I really 
need 32 values for each vertex (that's what I'm using multitexcoord) Finally I 
think I have this problem solved, I had some problems with the glew 
initialization. Now I'm having other problems uploading a texture to the GPU :P

Thank you!

Cheers,
Pau

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





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

Re: [osg-users] osg::Image with signed int

2009-08-07 Thread Pau Moreno

Hi J.P.,

Finally I can figure out a way so I don't need the signed int. Anyway, I think 
my really problem is that by some reason, the texture is not uploading 
correctly to the GPU :S

In my OGL code I have:


Code:
glGenTextures(1, &(this->triTableTex));
glActiveTexture(GL_TEXTURE2);
glEnable(GL_TEXTURE_2D);

glBindTexture(GL_TEXTURE_2D, this->triTableTex);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_R, GL_CLAMP_TO_EDGE);

glTexImage2D( GL_TEXTURE_2D, 0, GL_ALPHA16I_EXT, 16, 256, 0, 
GL_ALPHA_INTEGER_EXT, GL_INT, &triTable);



and in osg I do:


Code:
osg::Texture2D *tex = new osg::Texture2D();

tex->setFilter( osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST );
tex->setFilter( osg::Texture2D::MAG_FILTER, osg::Texture2D::NEAREST );
tex->setWrap( osg::Texture2D::WRAP_S , osg::Texture2D::CLAMP_TO_EDGE );
tex->setWrap( osg::Texture2D::WRAP_T , osg::Texture2D::CLAMP_TO_EDGE );
tex->setWrap( osg::Texture2D::WRAP_R , osg::Texture2D::CLAMP_TO_EDGE );
//tex->setDataVariance( osg::Object::DYNAMIC );

unsigned char *cc = new unsigned char[256*16];

for ( int i = 0 ; i < 256 ; i++)
for ( int ii = 0 ; ii < 16 ; ii++)
{
//cc[ ii + i*16 ] = triTable[i][ii];
cc[ ii + i*16 ] = 127;
}


osg::Image *i = new osg::Image();
i->setImage( 16 , 256 , 0 , GL_ALPHA16I_EXT , GL_ALPHA_INTEGER_EXT , 
GL_INT , (unsigned char *)&triTable , osg::Image::NO_DELETE );

tex->setImage( i );
brickState->setTextureAttributeAndModes(1,tex,osg::StateAttribute::ON);



I'm just setting all the values to 127 so I can check in the GPU if the texture 
is uploaded to the geometry shader. I need this values to work in the GPU, as 
I'm using it for an Marching Cubes Algorithm based.

Do you think I need to do something else? Thanks!

Cheers,
Pau[/code]

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





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

Re: [osg-users] Feature request for 2.9: please include swig bindings in main release

2009-08-07 Thread john casu

Hi,

thanks for the replies..  I'd just like to state that the aim of my request is 
to get the basic swig prototypes/bindings in place, to ensure their 
correctness.  I think that process could be automated, somewhat.

Even though the automatically generated bindings would be unwieldy for end 
users, from there, one could generate the appropriate end-language bindings, in 
a clean, 2-step process.  

That way, you get the universality of having swig prototypes, and then language 
advocates can do their thing to get more language friendly/appropriate 
bindings.  

In any case, any changes that break SWIG would automatically generate a 
regression, and that's a damned useful thing to have happen.

Also, I'd like to point out that for all of osgswigs' goodness, it is mightily 
unfriendly to non-python users, and I don't think that works to our advantage, 
in the long term.   

My specific issue with the osgswig project is the way files get released (the 
only downloadable file from the project site is 
http://osgswig.googlecode.com/files/osgPython-2.6.1-0-py26.exe), and I have a 
philosophical issue, having been burnt *many* times, with being forced to grab 
files from svn, cvs or any other source control system, because things aren't 
stable in that regime, by definition.

By including the bindings with the releases, there is some notion of stability, 
even if it's just at a basic level, and that is an insanely valuable thing to 
have.

... 

Thank you!

Cheers,
john

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





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

Re: [osg-users] Open source projects for eye tracking

No, other than running the demo.
I once did something to automatically find pupil position/size for an opthalmic 
system but it didn't do gaze direction.
One thing that was very useful (if you can control the environment) was to use 
an IR LED which reflects off the cornea and an IR sensitive camera to find the 
eye.  For the opthalmic app we couldn't have bright lighting.

The openCV code is reasonably good but the community and forums aren't as 
helpfull as OSG. There are a lot of "how make seeing robot" newbie posts. For 
some reason openCV is very popular in India/China.

Martin

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





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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

2009-08-07 Thread Tanguy Fautre

Hi Robert,

>From our SVN log I've extracted a unified diff of the modifications I've
had to make on our branch of OSG (i.e. a stabilized trunk snapshot taken
around OSG 2.9.3). This should give a fair idea of the places where I
found a potentially dangerous getenv(). See attached file.

Be careful! It's not impossible I've missed a couple (especially in
other modules than osg.dll). 

But as importantly, I've probably commented out a couple false positives
(i.e. getenv() that are perfectly safe). I can probably help you making
a more exhaustive and safer list by using the debugger to see exactly
which getenv() are really getting called in DllMain() (note that's what
I already did for most, but not all).

> Init is usually done single threaded, is there something specific
> about the threading model you have that concerns you?  There may be
> cases which threading may be an issue, but most cases I'd guess as not
> being threaded, we'll want to avoid adding mutex locks across the
> board.

The problem with the getSingleton() solution is that you cannot tell
when they will be called. Hence, even with the best intentions in the
world you cannot guarantee that two threads won't call getSingleton() at
the same time. I'm afraid that if we don't make the getSingleton()
functions thread-safe, the fix will actually introduce more threading
bugs than it actually fixes.

I guess that what is needed to reduce the impact of locking in
getSingleton is to:

1. Check whether a particular getSingleton() is potentially called
frequently (if it is not, we can probably afford the lock).

2. Check whether the call to getSingleton() can be cached by the
object(s) using it. For example, if an object needs to call getSingleton
quite enough, then it should call it in its constructor and cache the
returned address/reference in a member variable.

3. See whether the call to getSingleton() is really necessary and
whether it could be moved somewhere else where it does not have to be
called that often. (same idea as 2.)

Cheers,

Tanguy

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 07 August 2009 15:51
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil

Hi Tanguy,

On Fri, Aug 7, 2009 at 3:14 PM, Tanguy
Fautre wrote:
> I had the chance to test your patch. As expected, it fixes the
problem.
> The debugger shows the singleton is only initialized well after
DllMain
> has been called. No deadlock to report.

Great, a good first step then.

> As you stated, we need to fix all the getenv() that can be called from
> constructing a global singleton. We've seen our app deadlocking on
them
> before.

With your other work I presume you've not enumerated all the files
that have this global static's that use getenv?  Do you have a list?

My thought is to look at the usage pattern and then come up with
standard implementation pattern for these variables.  Clearly it'll
involve a singleton access method/function, but this might be
something we can use macro's or templates to help keep regular.

> Not sure if you want to apply the patch as it stands though, as
> thread-safety is quite important to us.

Init is usually done single threaded, is there something specific
about the threading model you have that concerns you?  There may be
cases which threading may be an issue, but most cases I'd guess as not
being threaded, we'll want to avoid adding mutex locks across the
board.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
Index: 
D:/svn/ThirdParty/build/OpenSceneGraph-2.9.4-vc8/OpenSceneGraph/src/osgUtil/RenderBin.cpp
===
--- 
D:/svn/ThirdParty/build/OpenSceneGraph-2.9.4-vc8/OpenSceneGraph/src/osgUtil/RenderBin.cpp
   (revision 282)
+++ 
D:/svn/ThirdParty/build/OpenSceneGraph-2.9.4-vc8/OpenSceneGraph/src/osgUtil/RenderBin.cpp
   (revision 287)
@@ -114,7 +114,12 @@
 if (!s_defaultBinSortModeInitialized)
 {
 s_defaultBinSortModeInitialized = true;
-
+
+   /* ARIS: this function could be called in DllMain due to 
singletons construction.
+   * Unfortunately, getenv() uses an internal lock, which causes a 
deadlock (see DllMain doc).
+   * http://forum.openscenegraph.org/viewtopic.php?p=15636
+   */
+   /*
 const char* str = getenv("OSG_DEFAULT_BIN_SORT_MODE");
 if (str)
 {
@@ -123,6 +128,7 @@
 else if (strcmp(str,"SORT_FRONT_TO_BACK")==0) s_defaultBinSortMode 
= RenderBin::SORT_FRONT_TO_BACK;
 else if (strcmp(str,"SORT_BACK_TO_FRONT")==0) s_defaultBinSortMode 
= RenderBin::SORT_BACK_TO_FRONT;
 }
+   */
 }

 return s_default

Re: [osg-users] Vec2ul and isomorphic variants?

Robert Osfield wrote:
> HI Chris,
> OK, I understand better where you coming from now - making a template
> of Vec to enable easier implementation of the various implementations.
> I chose not to use templates in the first place to avoid the compiler
> doing too much work on such a commonly used class and to enable easier
> specialization to the specifics of each type.  Given I chose not to
> use templates for these classes in the first place, and my experience
> of maintaining these separate implementations has been very straight
> forward, they've existed without changes for quite some time, then I
> do see there a critical issue to change.  I believe "If it ain't broke
> don't fix it" is a good motto follow in this case.

  Ok. I'll create the other variations to flesh out the scalar types as 
individual files.

  What? You have some distrust of compilers not doing 
everything for
you perfectly? ;)

> 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] Open source projects for eye tracking

Hi Martin,

Thanks for the pointer.  Have you use TrackEye yourself?

Robert.

On Fri, Aug 7, 2009 at 4:32 PM, Martin Beckett wrote:
> It's fairly easy to do in OpenCV using Haar trackers.
> OpenCV also handles all the webcam stuff for you fairly painlessly.
>
> See http://www.codeproject.com/KB/cpp/TrackEye.aspx for example.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=15968#15968
>
>
>
>
>
> ___
> 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] Vec2ul and isomorphic variants?

HI Chris,

OK, I understand better where you coming from now - making a template
of Vec to enable easier implementation of the various implementations.

I chose not to use templates in the first place to avoid the compiler
doing too much work on such a commonly used class and to enable easier
specialization to the specifics of each type.  Given I chose not to
use templates for these classes in the first place, and my experience
of maintaining these separate implementations has been very straight
forward, they've existed without changes for quite some time, then I
do see there a critical issue to change.  I believe "If it ain't broke
don't fix it" is a good motto follow in this case.

Robert.

On Fri, Aug 7, 2009 at 4:28 PM, Chris 'Xenon'
Hanson wrote:
> Robert Osfield wrote:
>> Well I have no clue what you are specifically thinking of changing so
>> I can't say anything about it either one way or the other.  The
>> osg::Array classes already use templates, and are already extensible,
>> so I don't what you're trying to address.
>
>  Well, I'm not aiming at the osg::Array classes. I'm proposing a way to make 
> more
> osg::Vecnxx classes. For example, we have osg::Vec2d and Vec3d, 2 & 3 
> versions of b, f,
> and s for byte, float and short. My code called for a Vec2ul that would 
> contain a nice
> doublet of unsigned long coordinates (in practice there were used to 
> atomically store an X
> and Y subscript for an array, but they're not limited to that). The design of 
> the osg Vec
> classes is nice, because they each provide a common set of clear operations, 
> so I just
> adapted osg::Vec2b (I think) into 2ul.
>
>  What I'm asking is, if I create more variants of these to flesh out the 
> types, would you
> accept them into the osg codebase even though osg itself is not currently 
> using them?
>
>  And the second part of the question is, if it's a good idea to do this, 
> would it be a
> good idea to study the current design of the Vec classes to see if we could 
> make it into
> one or two templates. This would mean that osg::Vec2d and Vec2f might simply 
> be
> implemented as instances of a common osg::Vec2real template, and b, s, ul and 
> other
> integer types would be made from a common osg:Vec2integer template.
>
>  The motivation here is that there is a lot of copy & paste code between the 
> Vec classes,
> and if we're expanding the classes further, it will only get worse.
>
>> 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
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] Unable to load plugin for jpeg file....

Do you have a osgdb_jpeg.dll file? Is it in a directory on your path ?

Did you build OSG from source? 
You may need the 3rd party add-ons (especially if on windows) this contains the 
low level jpeg library needed the plugin.

Martin

ps. You should probably post in the 'general' forum - this is mainly for people 
writing/fixing plugins.

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





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

Re: [osg-users] Open source projects for eye tracking

Sorry forgot to add, OpenCV is C/C++, cross platfom is BSD licensed and works 
well with OSG.

The documentation isn't bad and it's used by a lot of vision courses so quite a 
few tutorials out there. There is a good intro book from O'Reilly


Martin

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





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

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

2009-08-07 Thread Jean-Sébastien Guay


Hello Peter,


that got cmake to build it, but now when trying to compile, it gives tons of 
errors and fails

compiler is vs08 sp1 32 bit


Are you sure about that? This:

C:\Program Files\Microsoft Visual Studio 9.0\VC\

in your log suggests you're using VC9.

Perhaps you have mixed-up include paths... Please check that your build 
environment is sane.


Hope this helps,

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] Open source projects for eye tracking

It's fairly easy to do in OpenCV using Haar trackers.
OpenCV also handles all the webcam stuff for you fairly painlessly.

See http://www.codeproject.com/KB/cpp/TrackEye.aspx for example.

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





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

Re: [osg-users] Infinite Grid in OSG

Brian R Hill wrote:
> Andrew,
> You could implement it as an ortho projection (look at HUD examples) and
> draw text and lines as geometry based on current scale and position.

  You can create a custom drawable that does anything at all you want when its 
code is called.

> Brian

-- 
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] Vec2ul and isomorphic variants?

J.P. Delport wrote:
> I'm no expert, but what I do know is that tr1::function and tr1::bind
> are much easier to understand than the original variants. I've once made
> a little test app for myself that I attach.

  I agree. However, I can't rely on tr1 in my build at this time. Likewise with 
boost. :(

> jp

-- 
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] Vec2ul and isomorphic variants?

Robert Osfield wrote:
> Well I have no clue what you are specifically thinking of changing so
> I can't say anything about it either one way or the other.  The
> osg::Array classes already use templates, and are already extensible,
> so I don't what you're trying to address.

  Well, I'm not aiming at the osg::Array classes. I'm proposing a way to make 
more
osg::Vecnxx classes. For example, we have osg::Vec2d and Vec3d, 2 & 3 versions 
of b, f,
and s for byte, float and short. My code called for a Vec2ul that would contain 
a nice
doublet of unsigned long coordinates (in practice there were used to atomically 
store an X
and Y subscript for an array, but they're not limited to that). The design of 
the osg Vec
classes is nice, because they each provide a common set of clear operations, so 
I just
adapted osg::Vec2b (I think) into 2ul.

  What I'm asking is, if I create more variants of these to flesh out the 
types, would you
accept them into the osg codebase even though osg itself is not currently using 
them?

  And the second part of the question is, if it's a good idea to do this, would 
it be a
good idea to study the current design of the Vec classes to see if we could 
make it into
one or two templates. This would mean that osg::Vec2d and Vec2f might simply be
implemented as instances of a common osg::Vec2real template, and b, s, ul and 
other
integer types would be made from a common osg:Vec2integer template.

  The motivation here is that there is a lot of copy & paste code between the 
Vec classes,
and if we're expanding the classes further, it will only get worse.

> 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] Infinite Grid in OSG

Ok, wise advise, just since this is a grid (Rendered once) per frame, I will 
need to resize the grid lines/thicknesses/spacing on every frame (as I zoom/pan 
my scene). 

I guess I have enough to go digging now though, certainly you've given me some 
good ideas, 

Thank you, 
Andrew

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





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

Re: [osg-users] Infinite Grid in OSG

2009-08-07 Thread Brian R Hill

Andrew,

I would recommend converting your glBegin/glEnd code to use native osg
drawing constructs (geode,geometry,primitives,...). Check out the
osggeometry example.

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •


-osg-users-boun...@lists.openscenegraph.org wrote: -


To: osg-users@lists.openscenegraph.org
From: "Andrew Thompson" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/07/2009 10:57AM
Subject: Re: [osg-users] Infinite Grid in OSG

Ok, so I could use a HUD and attach behind my scene - clever, I like it :-)

Now the question is, how do I get access to just glBegin/glEnd?

I was thinking of creating a class that inherits ShapeDrawable and just
rendering my lines (I have found some legacy code that calculates the lines
and subdivisions using simple GL calls). However I realised that was a
stupid idea as Shapes do not draw themselves, but ShapeDrawable draws them,
so I assume that a custom shape will not get rendered.

Thank you!

Andrew

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





___
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] Infinite Grid in OSG

Ok, so I could use a HUD and attach behind my scene - clever, I like it :-)

Now the question is, how do I get access to just glBegin/glEnd?

I was thinking of creating a class that inherits ShapeDrawable and just 
rendering my lines (I have found some legacy code that calculates the lines and 
subdivisions using simple GL calls). However I realised that was a stupid idea 
as Shapes do not draw themselves, but ShapeDrawable draws them, so I assume 
that a custom shape will not get rendered. 

Thank you!

Andrew

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





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

[osg-users] Open source projects for eye tracking

Hi VR-experts,

There is a project proposal that I'm looking into that will require
real-time eye tracking using standard PC webcams.  A quick search of
the web suggests that there are solutions out there, including some
open source ones, but as to how good they or how suitable they are for
use in a cross platform C++ app (that will built on top of the OSG) I
can't say without doing lots of download, building and testing.

Now there is quite a bit of VR expertise in this community, a pretty
decent place to asks for thoughts on best VR related technologies,
so... what do you guys think about this topic?  Are there good open
source eye tracking libs out there that are easy to use and integrate?

Thanks in advance for you thoughts/suggestions,
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

Hi Tanguy,

On Fri, Aug 7, 2009 at 3:14 PM, Tanguy
Fautre wrote:
> I had the chance to test your patch. As expected, it fixes the problem.
> The debugger shows the singleton is only initialized well after DllMain
> has been called. No deadlock to report.

Great, a good first step then.

> As you stated, we need to fix all the getenv() that can be called from
> constructing a global singleton. We've seen our app deadlocking on them
> before.

With your other work I presume you've not enumerated all the files
that have this global static's that use getenv?  Do you have a list?

My thought is to look at the usage pattern and then come up with
standard implementation pattern for these variables.  Clearly it'll
involve a singleton access method/function, but this might be
something we can use macro's or templates to help keep regular.

> Not sure if you want to apply the patch as it stands though, as
> thread-safety is quite important to us.

Init is usually done single threaded, is there something specific
about the threading model you have that concerns you?  There may be
cases which threading may be an issue, but most cases I'd guess as not
being threaded, we'll want to avoid adding mutex locks across the
board.

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

Re: [osg-users] Computing depth buffer in osgVolume

Hi Yvon,

On Fri, Aug 7, 2009 at 3:02 PM, Yvon Halbwachs wrote:
> Yes I agree that the z-buffer depth value makes more sense for the
> isosurface technique since it defines a single position. I only meant that I
> modified the shaders for the isosurface technique (volume_iso.frag and
> volume_tf_iso.frag).

Send along the mods then, there would certainly be welcome :-)

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

Re: [osg-users] Deadlock when loading osg.dll, singletons are evil

2009-08-07 Thread Tanguy Fautre

Hi Robert,

I had the chance to test your patch. As expected, it fixes the problem.
The debugger shows the singleton is only initialized well after DllMain
has been called. No deadlock to report.

As you stated, we need to fix all the getenv() that can be called from
constructing a global singleton. We've seen our app deadlocking on them
before.

Not sure if you want to apply the patch as it stands though, as
thread-safety is quite important to us.

Cheers,

T



-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tanguy
Fautre
Sent: 06 August 2009 13:59
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil

Hi Robert,

We've got a custom build of OSG where we've commented out all the unsafe
getenv (we do not use env variables in our application anyway).

I'm gonna give your patch a few runs. In theory, it should not deadlock
(considering all the other unsafe getenv are already commented out).


Cheers,

Tanguy


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert
Osfield
Sent: 06 August 2009 13:28
To: OpenSceneGraph Users
Subject: Re: [osg-users] Deadlock when loading osg.dll, singletons are
evil

Hi Tanguy,

As a first step I've just moved the GLExtension.cpp code that does the
static getenv() into the  osg::getGLExtensionDisableString() method so
it now reads:

std::string& osg::getGLExtensionDisableString()
{
static const char* envVar = getenv("OSG_GL_EXTENSION_DISABLE");
static std::string
s_GLExtensionDisableString(envVar?envVar:"Nothing defined");

return s_GLExtensionDisableString;
}

This isn't yet thread safe, but since the problem in hand isn't directly
a threading one this should be at least a little step towards helping
solve the problem.  Modified file attached.

Could you try this modification out at your end to see if it is
appropriate step forward.  A quick search shows other places where there
is static getenv in the global scope so I don't expect this one tweak to
be a complete solution, but if it does look like a way forward then we
can start rolling the fix out more generally.

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

Re: [osg-users] Computing depth buffer in osgVolume

2009-08-07 Thread Yvon Halbwachs

Yes I agree that the z-buffer depth value makes more sense for the 
isosurface technique since it defines a single position. I only meant 
that I modified the shaders for the isosurface technique 
(volume_iso.frag and volume_tf_iso.frag).


Yvon

Robert Osfield wrote:

Hi Yvon,

Good to hear you've got it working.

  

Maybe this should be integrated in the next release of OSG? I can send you
the code of each shaders if you are interested.



Possibly.  It's not clear to me which depth you are computing, as each
fragment can have only one depth, for a volume what depth to assume
will depend upon the technique, for instance the isosurface or mip
techniques will have a single position, but the blending ray tracing
techniques won't have any single position that can be identified.

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



--
---
Yvon Halbwachs Email : y...@kalkulo.no
  Mobile: +47 95 94 14 42
  WWW   : http://www.kalkulo.no
---
Kalkulo AS - A subsidiary of Simula Research Laboratory
--- 


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

Re: [osg-users] Infinite Grid in OSG

2009-08-07 Thread Brian R Hill

Andrew,

You could implement it as an ortho projection (look at HUD examples) and
draw text and lines as geometry based on current scale and position.

Brian

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to
any order or other contract unless pursuant to explicit written agreement
or government initiative expressly permitting the use of e-mail for such
purpose. •


-osg-users-boun...@lists.openscenegraph.org wrote: -


To: osg-users@lists.openscenegraph.org
From: "Andrew Thompson" 
Sent by: osg-users-boun...@lists.openscenegraph.org
Date: 08/07/2009 09:42AM
Subject: [osg-users] Infinite Grid in OSG

Hi there,

A simple question, would anyone know how I could implement an infinite grid
in OSG?

This is an image showing what I am trying to achieve.

[Image: http://i137.photobucket.com/albums/q217/andyb1979/InfiniteGrid.png]

Ideally as the user zooms in/out I would like the grid to subdivide.

Do forgive me if this has been asked before. I found some examples about
texturing a geode and moving it with your camera, but I need my grid to be
static, starting at the origin, and show divisions in 1/10 unit spacing.

Thank you!

Andrew

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





___
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] Infinite Grid in OSG

Edit: 

Perhaps another way of asking this question - I know how to render my grid 
using OpenGL calls, I would basically use glBegin(GL_LINES) / glEnd and draw 
the lines at the appropriate spacing and thickness. 

So the question is - is there a way to directly push something onto the GL 
rendering pipeline using OpenSceneGraph, prior to the rest of the scene being 
rendered?

Thank you,

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





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

[osg-users] Infinite Grid in OSG

Hi there, 

A simple question, would anyone know how I could implement an infinite grid in 
OSG?

This is an image showing what I am trying to achieve. 

[Image: http://i137.photobucket.com/albums/q217/andyb1979/InfiniteGrid.png ]

Ideally as the user zooms in/out I would like the grid to subdivide. 

Do forgive me if this has been asked before. I found some examples about 
texturing a geode and moving it with your camera, but I need my grid to be 
static, starting at the origin, and show divisions in 1/10 unit spacing. 

Thank you!

Andrew

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





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

Re: [osg-users] Computing depth buffer in osgVolume

Hi Yvon,

Good to hear you've got it working.

> Maybe this should be integrated in the next release of OSG? I can send you
> the code of each shaders if you are interested.

Possibly.  It's not clear to me which depth you are computing, as each
fragment can have only one depth, for a volume what depth to assume
will depend upon the technique, for instance the isosurface or mip
techniques will have a single position, but the blending ray tracing
techniques won't have any single position that can be identified.

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

Re: [osg-users] Blending Low Resolution Texture to Big Screen

2009-08-07 Thread kiruba nantham

Hi Robert,       Thank you, for your reply. i am tring some other method now 
(integrating image processing alogothms in my code) i hope this will help me. 
thanks again for suggesting me the third party implementations.
regards,K.Kiruba. 

--- On Wed, 8/5/09, Robert Osfield  wrote:

From: Robert Osfield 
Subject: Re: [osg-users] Blending Low Resolution Texture to Big Screen
To: "OpenSceneGraph Users" 
Date: Wednesday, August 5, 2009, 12:56 PM

Hi Kiruba,

Your problem is unreasonable expectations.  Mip mapping is purely for
minification and won't help you when you magnify.  What you should
expect is heavily un-sampled textures to look lousy, this is normal.
The fix is to sample your textures correctly so they aren't heavily
undersampled.

Robert.

On Fri, Jul 31, 2009 at 8:08 AM, kiruba nantham wrote:
> Hi Robert,
>       Yes i understand i am trying to do somthing that beyond OSG support. i
> have already done these teture mappings but i have never tried these
> mipmapping techniques. even now i am able mipmap it but my big problem here
> as you said undersampling. i checked with CImg Library (3rd party)
> applications but i am unable to integrate it in my application. please can
> you explain if you have any idea?
> regards,
> kiruba.
> --- On Mon, 7/27/09, Robert Osfield  wrote:
>
> From: Robert Osfield 
> Subject: Re: [osg-users] Blending Low Resolution Texture to Big Screen
> To: "OpenSceneGraph Users" 
> Date: Monday, July 27, 2009, 3:46 PM
>
> Hi Kurba,
>
> I'm Ulrich, this is classic undersampling, the best way to solve it is
> to choose you texture resolution far more appropriately, you certainly
> can't expect good results with such an aggressive undersampling,
> OpenGL certainly won't help you, and the OSG does have any magical
> pixie dust to help you either.
>
> If you really really must try and use such an undersampled image then
> go have a look at 3rd party tools for image processing to see if they
> can provide edge detection and filtering based on this, or some other
> specific method to handling such extreme undersampling.
>
> Robert.
>
> On Mon, Jul 27, 2009 at 11:08 AM, kiruba
> nantham wrote:
>> Hi Hertlein,
>>    Thank you for your reply,
>>    Yes, i accept as you said i am blowing each pixel in the texture to 8x
>> its size. but what all i want is after making this image bigger (i.e. 8x)
>> just adding some blur to overall picture so that the edges dostn't look
>> odd.
>> the problem here is i don't know how to add blur in OSG. if you can give
>> some tutorial links i can look in to it.
>> Regards,
>> Kiruba.
>>
>> --- On Mon, 7/27/09, Ulrich Hertlein  wrote:
>>
>> From: Ulrich Hertlein 
>> Subject: Re: [osg-users] Blending Low Resolution Texture to Big Screen
>> To: "OpenSceneGraph Users" 
>> Date: Monday, July 27, 2009, 3:01 PM
>>
>> On 27/07/09 10:48 AM, kiruba nantham wrote:
>>> Hi friends,   I am new to OSG. i am trying to map my small texture
>>> (128*128 pixel) to
>>> Big display (800*800 pixel). i am able to load successfully but i face
>>> one
>>> problem with
>>> it. the problem is my picture doesn't like smooth, my image looks very
>>> bad
>>> (picture is
>>> attached with this mail). can any one suggest any way to make my picture
>>> look proper?
>>
>> Increase the resolution.
>>
>> There is simply not enough information in a 128x128 image to make it look
>> nice at the output resolution.  Remember that your blowing up each pixel
>> in
>> the texture to 8x its size.
>>
>> Cheers,
>> /ulrich
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



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

Re: [osg-users] Z-buffer transparency / Alpha

2009-08-07 Thread Ulrich Hertlein


Hi Maxime,

On 7/08/09 12:02 PM, Maxime BOUCHER wrote:

Ulrich Hertlein wrote:

Hi Maxime, I'm extremely irritated by what you write and maybe I'm not the only 
one.


I am very sorry, please apologize. Maybe could you tell me why so that I won't 
do it
again.


No need to apologize.  (I meant 'irritated' as 'confused', not annoyed or angry, just  in 
case that's how you understood it; English can be fuzzy... :-}


You have to keep in mind that the people on the mailing list have absolutely no idea what 
you're trying to achieve and what the problem is.  You alone have that information so it 
helps to give as much detail as possible when posting a question.


What are you trying to accomplish and how do you approach it?  What is your 
shader doing?


Here is the camera view (with a green mask): [Image:
http://img7.hostingpics.net/pics/144972Z_buffer_colorimage.png ]

here the distance of fragments to the camera computed in shader: [Image:
http://img7.hostingpics.net/pics/850811Z_buffer_shader.png ]

and the Z-buffer image: [Image:
http://img7.hostingpics.net/pics/690702Z_buffer_pourri.png ]


Okay, the issue is with the last image, the parts that look like they're from a previous 
frame?  And these are areas that are covered by transparent geometry in the original image?


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

Re: [osg-users] [osgPPU] Running the processor between pre-render and main render

2009-08-07 Thread Miika Aittala

Hi Art and J.P., thanks for the quick replies. :)

art wrote:
> Is it possible that you provide me with a simple test case implementation to 
> test it. Because then maybe I would be able to find an answer how to correct 
> it.
> 

I'll probably put some simple test case together at the beginning of next week, 
that should help me isolate it too. I'll get back to you with that, unless I've 
managed to fix the problem otherwise by then. Who knows, maybe the problem is 
somehow specific to the bigger program I'm working on now.

> 
> I think osgViewer's camera is binded to FBO 0, because this is a main camera 
> which suppose to render to the screen.
> 

I've set it to render to a separate texture (viewer->getCamera()->attach() 
etc.) so it should do it, and normally it does it too. It's only when I try to 
alter the rendering order that it starts making that command for no apparent 
reason. It actually binds to the correct FBO just before it makes the call to 
FBO 0, so the call doesn't come from the regular source. It almost makes me 
think that OSG is somehow handling this incorrectly, though probably I'm just 
trying to feed it with a badly constructed graph.

> You could try to add a second camera below the osgviewer's, which renders 
> your scene into FBO. Then use the output of this camera for further 
> processing. So the graph could look like this:
> 
> osgViewer
> |
> +--- depthCamera (with PRE_RENDER, to an FBO) --- (stuff) 
> |
> +--- colorCamera (with PRE_RENDER, to an FBO) --- (stuff)
> |
> +--- PPU-Graph
> |
> +--- (same stuff)
> 
> 
> This will cause your rendering to be performed into FBOs and processed by 
> osgPPU. The ppu graph will have just no output to the screen, so no UnitOut 
> at the end. It will just process your renderings and the output textures 
> should be then used in the rendering of the main scene.
> 
> The ppu graph will look similar to this:
> 
>Processor
>   | |
> UnitCamera UnitCamera
>   \  /
>UnitInOut
> 
> 
> I am not exactly sure, but here it still can happen that osgPPU will be 
> executed after your main scene is rendered, so that you get this one frame 
> delay. 
> 

I'll probably end up trying things like that if I can't come up with a clean 
solution. I'm kind of hesitant to make the osgViewer camera into just some 
"post-hack" stage, because I guess it's in principle supposed to be somehow 
special. Also the problem seems to be quite persistent no matter how I try to 
arrange everything. But I'll look into that.

> 
> If you want to change the render bin number of processor, you do not have to 
> put it under a group and change the group's  bin number. you can try to do it 
> directly by getting processor's stateset and change the rende rbin number 
> there (processor is derived from Group).
> 

This is just for convenience - I think Processor::init() sets the bin number to 
100, and it's run at the first traversal so it would overwrite my value and I'd 
have to re-overwrite it later. Perhaps there could be a function to specify the 
default bin number?

J.P. Delport wrote:
> 
> I'm not sure if this is different from what you tried with the group, 
> but have you tried adding the processor as a sibling of the depthcamera, 
> i.e. not a child of depthcam, but child of viewer? We have some 
> algorithms with multiple passes where we just add a bunch of prerender 
> cameras to a group and they execute in the order they were added (no 
> need to fiddle with bins). I know this works with RTT cameras and FBOs 
> (see e.g. osgstereomatch example), not sure of osgPPU interaction though.
> 

This is pretty much the usual way to use osgPPU, so it should result in a 
typical last-stage processing. I think the "problem" is that osgPPU works 
basically by adding a bunch of screen-sized quad Geodes with a large renderbin 
number to the scene, whichever camera it is under (if I've understood it 
correctly). So in this case it will be under the osgViewer's camera and it'll 
render last. With that -1 group thing I tried to change the ordering such that 
the ppu-Geodes will render first thing in the main pass, but for some reason it 
causes that mystical FBO 0 problem.

Anyway, I'll probably get back at Monday and I'll try to put together some 
example code then.

- Miika

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

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

[osg-users] Using OSG Shadow mapping to compute a shadow map on a texture or bitmap

Hi there, 

I have a rather strange problem that I would like to tackle using OSG, I wonder 
if anyone could offer some advice on whether it is possible or not?

In brief, the application I am working on must allow users to detect what parts 
of a scene containing in a large CAD model are and are not visible (ie: 
occluded) when viewed from certain vantage points. To do this, I am currently 
using line of sight calculations from my eye (Detector) to points spaced 
equally throughout the scene in three dimensions, however this is proving very 
slow. 

I could simplify my problem greatly by saying "If the vantage point, or camera, 
was a light source, what is the shadow map on a horizontal plane placed at a 
certain level?"

I was thinking to use osgShadow functionality to generate a shadow map on a 
horizontal plane of a size/location that I specify, given a light source at the 
vantage point. However, I would need to get the bitmap (or other representation 
- I need to know what parts of the plane are in shadow and what parts are not) 
of the shadow map back in order to process it. 

Some questions:

- Is it possible to get the shadow map out as a texture or bitmap?

- Would the OSG fail to deliver a shadow map if I used osgShadow and the 
graphics card didn't have the correct features (i.e. would it fall back to CPU 
rendering?)

- What method of shadow mapping would best suit this problem?

The above operation does not have to be real time, but it has to work on a 
variety of hardware, ranging from onboard Intel graphics to top-end video 
cards. I would greatly appreciate something that defaulted to render on CPU as 
opposed to a GPU only technique, and I must be able to get the shadow map 
applied to the plane out as a bitmap. 

Thank you!
Andrew

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





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

Re: [osg-users] [osgPPU] Running the processor between pre-render and main render

2009-08-07 Thread J.P. Delport

Hi,

Miika Aittala wrote:

Hi,

... where do I put the Processor and what else do I need to do in
order to make its units render AFTER the depthCamera but BEFORE the
osgViewer's camera? The main camera needs to render to an FBO too,
because its results are also further processed with another Processor
(could multiple processors be a problem, by the way)?

> Also another approach of adding a group with renderbin -1 to the main
> level and parenting the processor to this gives pretty much the same
> results and problems.

I'm not sure if this is different from what you tried with the group,
but have you tried adding the processor as a sibling of the depthcamera,
i.e. not a child of depthcam, but child of viewer? We have some
algorithms with multiple passes where we just add a bunch of prerender
cameras to a group and they execute in the order they were added (no
need to fiddle with bins). I know this works with RTT cameras and FBOs
(see e.g. osgstereomatch example), not sure of osgPPU interaction though.

If it still does not work, maybe you could try make a minimal example of
osg RTT camera and osgPPU processor that shows the problem.

So... any ideas?

Thanks,

Miika

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

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

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

Re: [osg-users] Computing depth buffer in osgVolume

2009-08-07 Thread Yvon Halbwachs


Hi Robert,

Thanks for your tips, I managed to compute correctly the depth value in 
the fragment shader. I only needed access to the volume locator matrix 
to compute the right position of the ray, and then use the projection 
transformation matrix to compute the depth value in the range [-1,1]. 
Then I had to rescale it to [0,1] since this is what the Z-buffer expects.


To summarize, the fragment shader becomes something like:

   uniform mat4  LocatorMatrix;
   
   vec4 pos = LocatorMatrix * vec4(texcoord,1.0);
   vec4 transformedpos = gl_ModelViewProjectionMatrix * pos;

   gl_FragDepth = ((transformedpos.z / transformedpos.w) + 1.0) * 0.5;

Where "LocatorMatrix" is an extra uniform in the fragment shader that 
gives the locator matrix (added to osgVolume::RayTracedTechnique).


Maybe this should be integrated in the next release of OSG? I can send 
you the code of each shaders if you are interested.


Best regards,

Yvon

Robert Osfield wrote:

Hi Yvon,

The present osgVolume shaders that I've written compute the ray start
position from the initial fragment generated by rendered the backface
of the cube, then shoots the ray forward towards the eye point and
then clamps this to the dimensions of the cube.  It then computes the
texcoords for this from these ray coords.

Robert.

On Wed, Aug 5, 2009 at 7:40 PM, Yvon Halbwachs wrote:
  

Hi,

I would like to add the computation of the z-depth value in the ray traced
volume shaders. I'm pretty new to raytracing on gpu, so forgive me if this
is a naive question!

I've tried to add this code in the fragment shader, just after the line
"gl_FragColor = color":

 
 gl_FragColor = color;

 vec4 inter = gl_ModelViewProjectionMatrix * vec4(texcoord,1);
 gl_FragDepth = inter.z / inter.w;

 return;
 In theory my idea is to compute the position of the intersection with
the volume, and use the model view & projection transformation matrix to get
z buffer value computed. It looks good... but it's not right!

Does any one have an idea about what I'm doing wrong?

Thanks for any help,

Regards,

Yvon

___
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
  



--
---
Yvon Halbwachs Email : y...@kalkulo.no
  Mobile: +47 95 94 14 42
  WWW   : http://www.kalkulo.no
---
Kalkulo AS - A subsidiary of Simula Research Laboratory
--- 


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

Re: [osg-users] [osgPPU] Running the processor between pre-render and main render

2009-08-07 Thread Art Tevs

Hi Mika,


Is it possible that you provide me with a simple test case implementation to 
test it. Because then maybe I would be able to find an answer how to correct it.



> 
> However, this causes another problem which I don't even begin to understand 
> (which may or may not be related to osgPPU). Everything would be perfect, 
> except for some reason now there's an extra call for 
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the main osgViewer camera 
> renders (apparently after already having earlier bound the correct FBO). This 
> makes it draw directly to the screen, which is wrong. It does have its FBO 
> attachments and textures and they're even cleared correctly before rendering, 
> but for some unexplained reason it makes this binding that ruins everything. 
> I've spent hours stepping around in OSG's sources and while I can see where 
> this call is made, I have no idea why. It's in FrameBufferObject.cpp, 
> apply(State, BindTarget), this part:
> 
> if (_attachments.empty())
> {
> ext->glBindFramebufferEXT(target, 0);
> return;
> }
> 
> (called via osg::State::applyGlobalDefaultAttribute(), the buffer attachment 
> list for osgViewer's camera isn't empty - is it applying some default state 
> settings when they're not wanted?)
> 


I think osgViewer's camera is binded to FBO 0, because this is a main camera 
which suppose to render to the screen. You could try to add a second camera 
below the osgviewer's, which renders your scene into FBO. Then use the output 
of this camera for further processing. So the graph could look like this:

osgViewer
|
+--- depthCamera (with PRE_RENDER, to an FBO) --- (stuff) 
|
+--- colorCamera (with PRE_RENDER, to an FBO) --- (stuff)
|
+--- PPU-Graph
|
+--- (same stuff)


This will cause your rendering to be performed into FBOs and processed by 
osgPPU. The ppu graph will have just no output to the screen, so no UnitOut at 
the end. It will just process your renderings and the output textures should be 
then used in the rendering of the main scene.

The ppu graph will look similar to this:

   Processor
  | |
UnitCamera UnitCamera
  \  /
   UnitInOut


I am not exactly sure, but here it still can happen that osgPPU will be 
executed after your main scene is rendered, so that you get this one frame 
delay. 


> 
> Also another approach of adding a group with renderbin -1 to the main level 
> and parenting the processor to this gives pretty much the same results and 
> problems.
> 

If you want to change the render bin number of processor, you do not have to 
put it under a group and change the group's  bin number. you can try to do it 
directly by getting processor's stateset and change the rende rbin number there 
(processor is derived from Group).


cheers,
art

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





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

[osg-users] [osgPlugins] Unable to load plugin for jpeg file....

2009-08-07 Thread manish Choudhary

Hi,
I'm using  OSG-2.8.0 version.. on Visual studio-2008.
I have a problem with reading .jpg files with OpenSceneGraph (warning: "Could 
not find plugin to read objects from file X.jpg"). I see a source file in 
osgPlugin/jpeg but don't know how to use it
... 

Thank you!

Cheers,
manish

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





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

[osg-users] [osgPPU] Running the processor between pre-render and main render

2009-08-07 Thread Miika Aittala

Hi,

I'm implementing a more advanced SSAO algorithm using osgPPU.  I need to use 
the results more carefully than just multiplying them on top, so the resulting 
texture is used as an input to a regular surface fragment shader during the 
main rendering pass. Therefore the processing needs to happen exactly after the 
depth pre-render pass but before the main rendering pass.

At the moment, the algorithm works nicely, except it runs after the main 
render. This means that the results are only available at next frame, and the 
lighting lags one frame behind the rest of the scene. This of course causes 
unacceptable artefacts if anything is moving. 

There are plenty of other scenarios where doing this would also be necessary - 
e.g. processing reflections or processing shadow maps before use in some 
algorithms such as VSM or CSM. I've looked through all the examples and forum 
posts, but everyone seems to be happy with processing as the very last stage. 
Perhaps there's some really obvious simple way to do it, but I just can't make 
it happen.

So basically, if I have a scene graph roughly like follows:
 
osgViewer (renders to an FBO)
|
+--- depthCamera (with PRE_RENDER, to an FBO)  --- (stuff)
|
+--- (same stuff)

... where do I put the Processor and what else do I need to do in order to make 
its units render AFTER the depthCamera but BEFORE the osgViewer's camera? The 
main camera needs to render to an FBO too, because its results are also further 
processed with another Processor (could multiple processors be a problem, by 
the way)?




My current attempts are as follows (disregard this if there's some nice way to 
do it instead). I've tried simply adding the SSAO-processor as depthCamera's 
child. I'm not very familiar with all the renderbin/stage stuff, but the idea 
is that it would be included in the pre-render pass and thus rendered before 
the main pass begins. This actually almost works, though possibly by accident. 
Looking at glIntercept, the processor does indeed run before the main camera 
and does what is's supposed to.

However, this causes another problem which I don't even begin to understand 
(which may or may not be related to osgPPU). Everything would be perfect, 
except for some reason now there's an extra call for 
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0) before the main osgViewer camera 
renders (apparently after already having earlier bound the correct FBO). This 
makes it draw directly to the screen, which is wrong. It does have its FBO 
attachments and textures and they're even cleared correctly before rendering, 
but for some unexplained reason it makes this binding that ruins everything. 
I've spent hours stepping around in OSG's sources and while I can see where 
this call is made, I have no idea why. It's in FrameBufferObject.cpp, 
apply(State, BindTarget), this part:

if (_attachments.empty())
{
ext->glBindFramebufferEXT(target, 0);
return;
}

(called via osg::State::applyGlobalDefaultAttribute(), the buffer attachment 
list for osgViewer's camera isn't empty - is it applying some default state 
settings when they're not wanted?)

Also another approach of adding a group with renderbin -1 to the main level and 
parenting the processor to this gives pretty much the same results and problems.

So... any ideas?

Thanks,

Miika

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





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

Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator

2009-08-07 Thread Andrew Burnett-Thompson

Oh and for reference (forgot to add)

the method to update the camera is as follows

/
void CCameraView::UpdateCameraMatrices(osg::Camera * camera)
{
// Set the projection matrix on the camera
if (this->m_bIsOrthogonal)
{
camera->setProjectionMatrixAsOrtho(-m_fOrthoZoom, m_fOrthoZoom,
-m_fOrthoZoom, m_fOrthoZoom, m_fNearClip, m_fFarClip);
}
else
{
camera->setProjectionMatrixAsPerspective(m_fFieldOfView, m_fAspect,
m_fNearClip, m_fFarClip);
}

// Set the view matrix on the camera
camera->setViewMatrixAsLookAt(GetCameraPosition(), GetCameraTarget(),
GetUpVector());
}
/


On Fri, Aug 7, 2009 at 11:49 AM, Andrew Burnett-Thompson <
aburnettthomp...@googlemail.com> wrote:

> Hi Robert,
>
> Thanks for your helpful reply. I've sorted this problem by taking the
> following steps
>
> 1. Removal of camera manipulators from the scene (I had a custom
> manipulator that allowed you to set target/position, but event handling was
> done elsewhere in my external application)
>
> 2. Creation of a class CCameraView which does little more than hold
> variables to setup the camera, such as position, target, field of view,
> near/far, isOrthogonal, orthogonal zoom factor etc
>
> 3. Multiple instances of my CCameraView class are held by the application,
> one for the perspective freelook view, one for a plan view, plus others for
> various views around the scene that I need. These are updated appropriately
> by my applications event processing code.
>
> 4. Setting of the current active CCameraView on the scene as appropriate
> (depending on what mode the app is in)
>
> 5. Within the render loop, immediately prior to Viewer->Frame, call
> Viewer->getCamera() to get the main camera, and pass it to the current
> CameraView instance (a method called UpdateCameraMatrices). This then
> applies the desired view/projection matrix
>
> 6. Render the scene
>
> Simple really when you know how. I realise the above is not an OSG problem,
> more a "How to use OSG in my system in such a way" problem, but I am posting
> as others may find the solution useful.
>
> Thank you,
> Andrew
>
>
> On Wed, Aug 5, 2009 at 10:00 AM, Robert Osfield 
> wrote:
>
>> Hi Andrew,
>>
>> On Wed, Aug 5, 2009 at 9:35 AM, Andrew
>> Burnett-Thompson wrote:
>> > I noticed osg::Camera offers more direct access to the view/projection
>> than
>> > the camera manipulator (which only affects the View), so I've dumped
>> camera
>> > manipulator and created two cameras - perspective / plan.
>>
>> Yes this would be doable, although having two separate views in
>> CompositeViewer might be more logical an easier to manage.
>>
>> > Then I am directly updating the camera in the perspective/plan mode from
>> my
>> > own event handling code. (In addition I need multiple other cameras that
>> I
>> > can position around the scene in perspective mode and switch to on
>> various
>> > key presses).
>> >
>> > One problem - I am trying to swap the cameras in/out of the osg::Viewer
>> so I
>> > was using osg::Viewer::setCamera and getCamera to get/set the default
>> > camera, however it is not behaving as expected.
>>
>> What problem are you seeing?  Using the
>> viewer.getCamera()->set..MatrixAs..(..) methods work fine, but if you
>> need to make sure that you aren't also attaching a CameraManipulator
>> as this will overwrite your values on each frame.
>>
>> > Is this the right way to set the default camera?
>>
>> Just use the Camera that is already assigned to the Viewer.
>>
>> Robert.
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Perspective / Orthogonal projection matrix with CameraManipulator

2009-08-07 Thread Andrew Burnett-Thompson

Hi Robert,

Thanks for your helpful reply. I've sorted this problem by taking the
following steps

1. Removal of camera manipulators from the scene (I had a custom manipulator
that allowed you to set target/position, but event handling was done
elsewhere in my external application)

2. Creation of a class CCameraView which does little more than hold
variables to setup the camera, such as position, target, field of view,
near/far, isOrthogonal, orthogonal zoom factor etc

3. Multiple instances of my CCameraView class are held by the application,
one for the perspective freelook view, one for a plan view, plus others for
various views around the scene that I need. These are updated appropriately
by my applications event processing code.

4. Setting of the current active CCameraView on the scene as appropriate
(depending on what mode the app is in)

5. Within the render loop, immediately prior to Viewer->Frame, call
Viewer->getCamera() to get the main camera, and pass it to the current
CameraView instance (a method called UpdateCameraMatrices). This then
applies the desired view/projection matrix

6. Render the scene

Simple really when you know how. I realise the above is not an OSG problem,
more a "How to use OSG in my system in such a way" problem, but I am posting
as others may find the solution useful.

Thank you,
Andrew

On Wed, Aug 5, 2009 at 10:00 AM, Robert Osfield wrote:

> Hi Andrew,
>
> On Wed, Aug 5, 2009 at 9:35 AM, Andrew
> Burnett-Thompson wrote:
> > I noticed osg::Camera offers more direct access to the view/projection
> than
> > the camera manipulator (which only affects the View), so I've dumped
> camera
> > manipulator and created two cameras - perspective / plan.
>
> Yes this would be doable, although having two separate views in
> CompositeViewer might be more logical an easier to manage.
>
> > Then I am directly updating the camera in the perspective/plan mode from
> my
> > own event handling code. (In addition I need multiple other cameras that
> I
> > can position around the scene in perspective mode and switch to on
> various
> > key presses).
> >
> > One problem - I am trying to swap the cameras in/out of the osg::Viewer
> so I
> > was using osg::Viewer::setCamera and getCamera to get/set the default
> > camera, however it is not behaving as expected.
>
> What problem are you seeing?  Using the
> viewer.getCamera()->set..MatrixAs..(..) methods work fine, but if you
> need to make sure that you aren't also attaching a CameraManipulator
> as this will overwrite your values on each frame.
>
> > Is this the right way to set the default camera?
>
> Just use the Camera that is already assigned to the Viewer.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Z-buffer transparency / Alpha

2009-08-07 Thread Maxime BOUCHER

Hi Ulrich,


Ulrich Hertlein wrote:
> Hi Maxime,
> I'm extremely irritated by what you write and maybe I'm not the only one.
> 

 I am very sorry, please apologize.
Maybe could you tell me why so that I won't do it again.


Ulrich Hertlein wrote:
> 
> Why do you suspect that the Z-buffer is influenced by alpha blending?
> 

 Because problems only appear with models having alpha blending.


Ulrich Hertlein wrote:
> 
> So you're reading back the depth buffer and it's not what you expect?  Could 
> you post a 
> screenshot?
> 
> /ulrich
> 

 You're right, it would be clearer.

Here is the camera view (with a green mask):
[Image: http://img7.hostingpics.net/pics/144972Z_buffer_colorimage.png ] 
(http://www.hostingpics.net/viewer.php?id=144972Z_buffer_colorimage.png)

here the distance of fragments to the camera computed in shader:
[Image: http://img7.hostingpics.net/pics/850811Z_buffer_shader.png ] 
(http://www.hostingpics.net/viewer.php?id=850811Z_buffer_shader.png)

and the Z-buffer image:
[Image: http://img7.hostingpics.net/pics/690702Z_buffer_pourri.png ] 
(http://www.hostingpics.net/viewer.php?id=690702Z_buffer_pourri.png)

 Problems are only located on surfaces having transparency.


And to be complete:
- The Z image is computed from another viewer than the rendering one (I 
allocate an image and attach it to prerendering cam's Z-buffer then execute one 
frame() ). 
- The images are sampler2D in the shader, thus I retrieve pixels from them and 
put it in gl_FragColor to be able to display.


Thanks a lot for help, and once again I'm very sorry for being so irritating, 
please accept my apologies.

Cheers,

Max

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





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

Re: [osg-users] Z-buffer transparency / Alpha

2009-08-07 Thread Ulrich Hertlein


Hi Maxime,

On 6/08/09 4:41 PM, Maxime BOUCHER wrote:

I know Z-buffer isn't very in fond of transparency, and actually, when I 
capture it on
a model having transparent faces it stores strange things (a kind of luminance 
image of
some textures on parts corresponding to these transparents faces).

Thus, I tried to deactivate it, but I didn't find how. I tried all this stuff:
...

But, if one of it (ALPHA_TEST), stopped the transparency, my Z-buffer has 
always kept
being corrupted. Then, my question is, how can I really deactivate the 
transparency?

Of course, if you have good ideas to have transparency and a working Z-buffer, 
I would
be very pleased :).


I'm extremely irritated by what you write and maybe I'm not the only one.
Why do you suspect that the Z-buffer is influenced by alpha blending?

So you're reading back the depth buffer and it's not what you expect?  Could you post a 
screenshot?


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

Re: [osg-users] Vec2ul and isomorphic variants?

Hi Chris,

On Fri, Aug 7, 2009 at 3:07 AM, Chris 'Xenon'
Hanson wrote:
>  So, two questions:
>
>  1. Robert, are you even in support of refactoring the existing Vec* classes 
> into
> manifestations of a template if it can be done transparently and cleanly with 
> regard to
> existing code?

Well I have no clue what you are specifically thinking of changing so
I can't say anything about it either one way or the other.  The
osg::Array classes already use templates, and are already extensible,
so I don't what you're trying to address.

As a general principle the osg::Array classes are about supporting the
storage of OpenGL compatible vertex attribute data, they aren't
intended to have a general purpose role beyond this.

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

Re: [osg-users] Problems compiling OSG 2.8.2 on Solaris 10