date:20090604

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

2009-06-04 Thread Ulrich Hertlein


Hi Amanda,

On 26/5/09 5:39 PM, Amanda Henn wrote:

I am very new to computer graphics and OSG/OpenGL.  I need to figure out how to 
write a
simple textured rectangle to a .tif file.  I've found many examples of this but 
some
are so complicated I can't understand them.


What do you mean by 'write a texture rectangle'?  Do you want to save the rendered frame 
to a file?  If so then please take a look at the osgscreencapture example - in brief you 
need to add a capture callback to read the rendered frame and save it to a file.



Here is the code I have so far, when I run it I can see a single rectangle with 
the
road texture on it.  I have some code that does create a result .tif file, but 
I can't
view it.  I'm sure I'm missing some things.  I'd appreciate any help, I know 
this is
probably a simple question...


'Can't view it' as in it's empty?  Or not a tif file?
Please give us a bit more detail to work with.


//write image code I've been playing with osg::Image* resultImage = new 
osg::Image;
resultImage->allocateImage(3000, 3000, 0, GL_RGB, GL_UNSIGNED_BYTE);

osgDB::writeImageFile(*resultImage, "D:\\C++_Projects\\result.tif");


This will write an empty image (probably black).

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

[osg-users] [VirtualPlanetBuilder]How to apply side texture to the escarpment?

2009-06-04 Thread wind

Hi, 
  I have two groups of terrain data with geotiff format. One has common 
vertical orthographic projected elevation data and image, while the other is a 
part of the first group, and with a higher resolution, furthermore, its 
elevation data and image are gradient orthographic projected data that 
represents a protuberant escarpment(assuming knowing the image's shooting 
angle). I can build each group of data separately by VirtualPlanetBuilder(abbr. 
VPB) without taking account of the gradient orthographic projection, and next i 
can't embeded the smaller part into the larger terrain perfectly. I think i 
should build whole data in a lump, because VPB could deal with different 
resolution well, but i don't known how to apply the second part's shooting 
angle to building process. Anyone advance ?
  
 Xuex Chen
 Thank you very much.___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Simulating glass shattering effect

2009-06-04 Thread Cheng Guan

Hi,

I'm looking into simulating glass shattering effect e.g. 
http://blog.wolfire.com/2009/05/detailed-physics-effects/, any advices?

Thank you!

Cheers,
Tim

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





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

Re: [osg-users] [3rdparty] osgART install

2009-06-04 Thread Karl Butler

Never mind I just realised the file within the zip that has no extension can be 
unpacked again.

Would help if this file had an extension to avoid confussion and wasted time!

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





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

Re: [osg-users] [3rdparty] osgART install

2009-06-04 Thread Karl Butler

I am working in windows is this a problem?

Could someone please post the osgART 2.0 zip I don't think I have the right 
file. It doesn't have a CMakeLists.txt or anything - just a file without any 
exstension named: osgART_2.0_RC3

That is all  :(

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





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

[osg-users] Examples and multiple monitors on Mac OS X

2009-06-04 Thread Brent Gulanowski

Hi,

The examples are fullscreen. Strangely, they span multiple monitors, instead of 
simply using the primary monitor. Perhaps there are some launch arguments I 
need.

Running from Xcode causes problems, like missing resources, for example with 
the osgforest.app:


Code:
Creating terrain...Warning: Could not find plugin to read objects from file 
"Images/lz.rgb".
done.
Creating tree locations...done.
Creating cell subdivision...done.
Warning: Could not find plugin to read objects from file "Images/tree0.rgba".
Creating osg::Billboard based forest...Warning: font file "fonts/arial.ttf" not 
found.
done.
Creating double quad based forest...Warning: font file "fonts/arial.ttf" not 
found.
done.
Creating osg::MatrixTransform based forest...Warning: font file 
"fonts/arial.ttf" not found.
done.
Creating OpenGL shader based forest...Warning: font file "fonts/arial.ttf" not 
found.
done.




Of course debug builds must be run from Xcode.

There are some other strange aspects of the Xcode project, such as building 
dSYM files and universal products for the Debug (aka "Development") build 
configuration, which is unnecessary unless you want to distribute debug builds 
(which is unusual).

... 

Thank you!

Cheers,
Brent

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





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

Re: [osg-users] Rendering image to memory

2009-06-04 Thread Michael Guerrero

Vinay Shah  writes:

> 
> Hi,
> 
> I would like to render an image to a scene that is later used for image
processing.  I am hoping to have the image
> in memory as an 24 bit RBG image.  
> 
> Is this possible without drawing it to the screen and taking a screen shot?
> 
> Can I render without using the graphics card (it is a very simple scene).
> 
> I'm new to the osg community so I apologize if this is an obvious question.
> 
> Thanks you!
> 
> Cheers,
> vinay
> 
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13538#13538
> 
> 

Hi Vinay, there is an osg example called osgPrerender that does exactly what you
want.  Look for the section with this:

 if (useImage)
{
osg::Image* image = new osg::Image;
//image->allocateImage(tex_width, tex_height, 1, GL_RGBA,
GL_UNSIGNED_BYTE);
image->allocateImage(tex_width, tex_height, 1, GL_RGBA, GL_FLOAT);

// attach the image so its copied on each frame.
camera->attach(osg::Camera::COLOR_BUFFER, image,
   samples, colorSamples);

camera->setPostDrawCallback(new MyCameraPostDrawCallback(image));

   ...
}


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

[osg-users] Rendering image to memory

2009-06-04 Thread Vinay Shah

Hi,

I would like to render an image to a scene that is later used for image 
processing.  I am hoping to have the image in memory as an 24 bit RBG image.  

Is this possible without drawing it to the screen and taking a screen shot?

Can I render without using the graphics card (it is a very simple scene).

I'm new to the osg community so I apologize if this is an obvious question.

Thanks you!

Cheers,
vinay

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





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

Re: [osg-users] build errors with 2.8.1

2009-06-04 Thread John Kelso


Hi again,

I made the change in CMakeLists.txt and cmake was happy.  It still bombs when
building- it's in the dicom plugin.

We have installed:

rpm -q InsightToolkit

InsightToolkit-2.8.1-5.fc6.i386

There's a large number of repetitious errors., included below.

Any ideas?

Many thanks,

John

Scanning dependencies of target osgdb_dicom
Building CXX object 
src/osgPlugins/dicom/CMakeFiles/osgdb_dicom.dir/ReaderWriterDICOM.o
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:306: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:306: 
warning: ISO C++ forbids initialization of member constant ‘zero’ of 
non-integral type ‘const float’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:308: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:308: 
warning: ISO C++ forbids initialization of member constant ‘one’ of 
non-integral type ‘const float’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:310: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:310: 
warning: ISO C++ forbids initialization of member constant ‘maxval’ of 
non-integral type ‘const float’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:329: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:329: 
warning: ISO C++ forbids initialization of member constant ‘zero’ of 
non-integral type ‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:331: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:331: 
warning: ISO C++ forbids initialization of member constant ‘one’ of 
non-integral type ‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:333: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:333: 
warning: ISO C++ forbids initialization of member constant ‘maxval’ of 
non-integral type ‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:352: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:352: 
warning: ISO C++ forbids initialization of member constant ‘zero’ of 
non-integral type ‘const long double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:354: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:354: 
warning: ISO C++ forbids initialization of member constant ‘one’ of 
non-integral type ‘const long double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:356: 
error: floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_numeric_traits.h:356: 
warning: ISO C++ forbids initialization of member constant ‘maxval’ of 
non-integral type ‘const long double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:55: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:55: warning: ISO 
C++ forbids initialization of member constant ‘e’ of non-integral type ‘const 
double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:56: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:56: warning: ISO 
C++ forbids initialization of member constant ‘log2e’ of non-integral type 
‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:57: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:57: warning: ISO 
C++ forbids initialization of member constant ‘log10e’ of non-integral type 
‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:58: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:58: warning: ISO 
C++ forbids initialization of member constant ‘ln2’ of non-integral type ‘const 
double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:59: error: 
floating-point literal cannot appear in a constant-expression
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:59: warning: ISO 
C++ forbids initialization of member constant ‘ln10’ of non-integral type 
‘const double’
/usr/include/InsightToolkit/Utilities/vxl/core/vnl/vnl_math.h:60: error

[osg-users] Writing to an image file

2009-06-04 Thread Amanda Henn

Hi,

I am very new to computer graphics and OSG/OpenGL.  I need to figure out how to 
write a simple textured rectangle to a .tif file.  I've found many examples of 
this but some are so complicated I can't understand them.

Here is the code I have so far, when I run it I can see a single rectangle with 
the road texture on it.  I have some code that does create a result .tif file, 
but I can't view it.  I'm sure I'm missing some things.  I'd appreciate any 
help, I know this is probably a simple question...


osgViewer::Viewer viewer;
osg::Group* root = new osg::Group;
osg::Geode* rectangleGeode = createRectangle();
root->addChild(rectangleGeode);

osg::Texture2D* RoadTexture = new osg::Texture2D();

RoadTexture->setDataVariance(osg::Object::DYNAMIC);

osg::Image* Road = 
osgDB::readImageFile("D:\\C++_Projects\\OSG_Test\\release\\road_texture.jpg");

if (!Road)
{
std::cout << " couldn't find texture, quitting." << std::endl;
return -1;
}

RoadTexture->setImage(Road);

osg::StateSet* stateOne = new osg::StateSet();

stateOne->setTextureAttributeAndModes(0, RoadTexture, osg::StateAttribute::ON);

rectangleGeode->setStateSet(stateOne);

viewer.setSceneData(root);

//write image code I've been playing with 
osg::Image* resultImage = new osg::Image;

resultImage->allocateImage(3000, 3000, 0, GL_RGB, GL_UNSIGNED_BYTE);

osgDB::writeImageFile(*resultImage, "D:\\C++_Projects\\result.tif");
//End of write image code

return viewer.run();


Thank you!
Amanda

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





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

Re: [osg-users] Can I change the plugin directory structure?

2009-06-04 Thread James Killian


There is one direction that I am tempted to pursue... my initial post was
that we cannot run OSG using the plugin folder structure as is.  When I saw
your initial post I manually copied over to the directory structure you said
where the plugin folder is in the same path as the bin.  The problem is the
plugins did not get loaded doing it this way... I have not investigated why
yet, but I believe it is because we manipulate the current working directory
to our art content folder.   If osgRegistry tries to obtain the plugins via
relative path or current working directory it would then fail.  If all my
guesses are correct then maybe there could be some DLL_OnProcessAttach that
could cache the CWD before we go and change it.

Rick was almost persuaded to use the OSG workflow, but this issue made it
too overwhelming to pursue.  I may go in this direction if it is easy to
determine.

I guess the main reason I would want to go in this way... is to offer a
solution that could benefit many.

- Original Message - 
From: "Jean-Sébastien Guay" 
To: "OpenSceneGraph Users" 
Sent: Thursday, June 04, 2009 3:28 PM
Subject: Re: [osg-users] Can I change the plugin directory structure?


> Hi James,
>
> > In short... I do not want to challenge the current workflow of either
> > paradigms, but rather describe how both are well-defined, and maybe
> > there are others out there who would like to see how we are doing it,
> > when/if we offer a submission.
>
> Thanks for explaining where you're coming from. It's good to take a step
> back and see what developers do with the dependencies that their
> products use.
>
> Sure, if you want to add a few options to the CMake scripts, you're
> welcome to submit them. As I said, if you find them useful then surely
> others will too.
>
> The current setup is kind of geared towards providing a good
> "out-of-the-box" experience, so new users don't have too many surprises,
> and also so that the setup is as similar as possible across platforms.
> If there are too many if(win32) paths in the cmake scripts then it makes
> them harder to support and keep in line with the mainline developments.
> Some are inevitable, but it's a good idea to keep them to a minimum.
>
> Thanks,
>
> 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
>

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

Re: [osg-users] Can I change the plugin directory structure?

2009-06-04 Thread Jean-Sébastien Guay


Hi James,

In short... I do not want to challenge the current workflow of either 
paradigms, but rather describe how both are well-defined, and maybe 
there are others out there who would like to see how we are doing it, 
when/if we offer a submission.


Thanks for explaining where you're coming from. It's good to take a step 
back and see what developers do with the dependencies that their 
products use.


Sure, if you want to add a few options to the CMake scripts, you're 
welcome to submit them. As I said, if you find them useful then surely 
others will too.


The current setup is kind of geared towards providing a good 
"out-of-the-box" experience, so new users don't have too many surprises, 
and also so that the setup is as similar as possible across platforms. 
If there are too many if(win32) paths in the cmake scripts then it makes 
them harder to support and keep in line with the mainline developments. 
Some are inevitable, but it's a good idea to keep them to a minimum.


Thanks,

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] Can I change the plugin directory structure?

2009-06-04 Thread Jean-Sébastien Guay


Hi Rick,

 > I even gave you a batch file that would do some of that 
automatically, and it's easy to supplement that with a couple more 
commands that will do it all automatically (see below).


You did?  Maybe I missed it.  Could you please send it again?  This does 
not look nearly as hard as I had imagined.  Perhaps I was making my 
ignorance of how to do it this way scare me away from trying it.  Thanks 
for being patient with my reticence.


Well perhaps "gave you a batch file" is the wrong wording, it wasn't an 
attachment... It was part of the message:


http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/45698/focus=45770


::--- Compile_OSG.bat ---
:: Clean old version
del C:\OSG_Staging_area\*.* /s /q /f
:: Change to OSG SVN directory
pushd C:\OSG-SVN\OpenSceneGraph
:: Update from SVN
svn up
:: Change to build subdirectory
md build
pushd build
:: Update project files using CMake in case files were added/removed
"C:\Program Files\CMake 2.6\cmake.exe" ..
:: Set up environment for Visual Studio
call "C:\MSVS8\VC\vcvarsall.bat"
:: Build INSTALL target
devenv OpenSceneGraph.sln /build Release /project INSTALL
:: Copy all contents of OSG_Staging_area to wherever
xcopy C:\OSG_Staging_area\*.* C:\wherever /s
::--- end Compile_OSG.bat ---

So as I said you could then add commands to check those binaries into 
SVN, and you'd have a one-step process that would compile a new version 
of OSG and check the binaries into your SVN repo.


Hope this helps,

J-S

P.S. It is of course good to be thankful for things you get basically 
for free. I just meant that if you had the idea that because it was free 
it meant you couldn't express wishes that would improve the experience 
for you, that's not the case! We're always glad to be able to make the 
software (and the experience of using it) better.

--
__
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] Destruction order for static objects

2009-06-04 Thread Fredrik Orderud

I've just discovered a potential solution for the initialization order for 
static objects. You can use the "depends_on"-pattern to let your classes 
inherit their dependencies.

http://www.entropygames.net/index.php?option=com_content&view=article&id=52

I don't know the OSG code enough in detail to know if this would fit into the 
design, but it is certainly an elegant solution.

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





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

Re: [osg-users] get the x-axis angle of a rotation

2009-06-04 Thread Christian Sam

Hi james,

thanks for the quick reply, now everything is clear. 

Best regards,
Christian

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





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

Re: [osg-users] Image pointer in the Intersected node is NULL

2009-06-04 Thread Cristina Paponi

Hi,

I guess I figure it out. The osgconv runs the optimizer, so I set the 
OSG_OPTIMIZER environment variable to OFF and now it works.

Thank you!

Cheers,
Cristina

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





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

Re: [osg-users] Image pointer in the Intersected node is NULL

2009-06-04 Thread Cristina Paponi

Hi Robert,

I just converted my flt file to an osg, and I started to have the same problem 
as before. My image pointer is NULL.
If I load the flt file the image pointer is OK, if I load the osg file the 
image pointer is NULL.
Any idea why? I used osgconv to convert the file.

Thank you!

Cheers,
Cristina

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





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

Re: [osg-users] get the x-axis angle of a rotation

2009-06-04 Thread James Killian


> regarding your last post, did you mean that you also tried to extract
angles from a rotation with the website's "matrixToEuler" or a similar
approach, but you encountered  problems that were depended on your current
camera-orientation?

It was quat to Euler
http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/index.htm


> i'm not sure what you are meaning with "..it was not a success.."
> does the attachment you included work, and won't it suffers from symptoms,
like described above?

The code is correct to the best of knowledge and of the tests I did, it
worked well.  The problem is that it wasn't compatible to the needs of what
I needed to do.  It has been over a year since I had dealt with it, and so I
don't quite remember the details except to say that it appeared to always
interpret the delta's from a global orientation perspective.  What I needed
is the deltas from its current local perspective, so for example if I just
turned the yaw, and watched the numbers... it looked correct.  The same is
true for the pitch and roll where I would start from the global orientation
and turn one axis exclusively.  Now lets say I apply a 45 angle pitch and
then apply a pure yaw rotation from this new orientation the Euler angles
would interpret that both yaw and pitch were changing, because from a global
orientation they were.

Once I figured out that this wasn't what I needed I finally saw the beauty
of the quaternion and the code snip that I initially sent is what I use
today.


- Original Message - 
From: "Christian Sam" 
To: 
Sent: Thursday, June 04, 2009 1:51 PM
Subject: Re: [osg-users] get the x-axis angle of a rotation


> Hi james,
>
> regarding your last post, did you mean that you also tried to extract
angles from a rotation with the website's "matrixToEuler" or a similar
approach, but you encountered  problems that were depended on your current
camera-orientation?
>
> i think the same happened to me: i wanted to get the pitch-angle of the
camera-orientation, to adjust the camera looking straight forward in certain
cases. (think of some: reset view, but only for the pitch angle). i
encountered that multiplying with the inverse rotation matrix of that angle
didn't work if a left or right camera-rotation has been done before.
> (actualy these negative-effects were only obvious when left/right rotation
was larger than 45°. so i don't know if also minor yaw-rotations did harm,
or only rotations exceeding a 45° threshold)
>
> in the end, it put out that i had to build the adjustment-rotation matrix
not with the pitch but the roll angle of the current camera-rotation in
cases of previous left/right camera-rotations from 45° to 135°
(respectively -45° to -135°)
>
> 3.)
> i'm not sure what you are meaning with "..it was not a success.."
> does the attachment you included work, and won't it suffers from symptoms,
like described above?
>
>
> Thanks in advance,
> Christian
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=13519#13519
>
>
>
>
>
> ___
> 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] build errors with 2.8.1

2009-06-04 Thread Paul Melis

John Kelso wrote:
> Hi,
>
> cmake 2.4-patch 8, that came with CentOS release 5.3.
>
> Our systems have been upgraded since my last OSG build, so I'll see if
> there's any relationship.  If I get stuck I'll mail again.
>
> Should I see if our system guy can install a newer cmake?
One thing cmake 2.6 has over 2.4 is that it seems to be smarter when it
comes to linking.
With 2.4 you get some kind of relinking stage when doing 'make install',
which doesn't occur with 2.6
I can't say anything about the other differences between 2.4 and 2.6

Paul
>
> Thanks again,
>
> John
>
> On Thu, 4 Jun 2009, Paul Melis wrote:
>
>> Ulrich Hertlein wrote:
>>> Hi John,
>>>
>>> On 4/6/09 7:24 PM, John Kelso wrote:
 After downloading 2.8.1 and typing cmake, I got this error:

 "The end of a CMakeLists file was reached with an IF statement that
 was not
 closed properly. Within the directory:
 /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion



 The arguments are: OSG_MAINTAINER"

 Are all bets off from this point, or can this be safely ignored?

 I plowed ahead anyway and the make died a horrible death. Before I
 waste
 time figuring out why, I'm wondering if I could get some advice about
 the
 relevance and importance of the cmake message.
>>>
>>> You're probably using a version of cmake that is too old (maybe 2.4?)
>> The toplevel CMakeLists.txt contains
>>
>> IF(WIN32)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
>> ELSE(WIN32)
>>IF(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
>>ELSE(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
>>ENDIF(APPLE)
>> ENDIF(WIN32)
>>
>> so either these checks are not strict enough and your version of CMake
>> is screwing up, or something else is going on.
>> What version of CMake do you use?
>>
>> Paul
>> ___
>> 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] build errors with 2.8.1

2009-06-04 Thread Paul Melis

Paul Melis wrote:
> Paul Melis wrote:
>   
>> John Kelso wrote:
>>   
>> 
>>> Hi,
>>>
>>> cmake 2.4-patch 8, that came with CentOS release 5.3.
>>>
>>> Our systems have been upgraded since my last OSG build, so I'll see if
>>> there's any relationship.  If I get stuck I'll mail again.
>>>
>>> Should I see if our system guy can install a newer cmake?
>>> 
>>>   
>> First, try this:
>>
>> In applications/osgversion/CMakeLists.txt change ENDIF() to
>> ENDIF(OSG_MAINTAINER)
>> That line looks fishy.
>>   
>> 
> If that solves it for you then I don't know how it ever got through the
> release candidate testing. The ENDIF() was introduced in rc4, and even
> that was followed by rc5. Perhaps it's only CMake 2.4 that stumbles over
> this.
>
> Checking...
>
> Indeed, no warning with 2.6, while 2.4 DOES warn (but continues with
> configuring).
>   
Robert, I fixed this on the 2.8 branch (r10313).

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

Re: [osg-users] How to apply LISPSM shadows to a scene with differentshaders - Part 3

2009-06-04 Thread Wojciech Lewandowski


Try this:

http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26683.html

Wojtek

--
From: "Michael Guerrero" 
Sent: Thursday, June 04, 2009 6:22 PM
To: 
Subject: Re: [osg-users]How to apply LISPSM shadows to a scene 
withdifferentshaders - Part 3


Wojciech Lewandowski  writes:



Miguel,

I am not sure whats the problem. Shadows on the ground look ok. So the
matrices must be ok as well. All I can notice is improper self shadowing 
on

soldier models. If this is the case then look at following thread:
http://www.mail-archive.com/osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF 


public.gmane.org/msg26683.html


Cheers,
Wojtek



Thanks Wojciech, this is a self shadowing issue.  However, that link 
doesn't

work for me.  Could you repost?



___
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] build errors with 2.8.1

2009-06-04 Thread Paul Melis

Paul Melis wrote:
> John Kelso wrote:
>   
>> Hi,
>>
>> cmake 2.4-patch 8, that came with CentOS release 5.3.
>>
>> Our systems have been upgraded since my last OSG build, so I'll see if
>> there's any relationship.  If I get stuck I'll mail again.
>>
>> Should I see if our system guy can install a newer cmake?
>> 
> First, try this:
>
> In applications/osgversion/CMakeLists.txt change ENDIF() to
> ENDIF(OSG_MAINTAINER)
> That line looks fishy.
>   
If that solves it for you then I don't know how it ever got through the
release candidate testing. The ENDIF() was introduced in rc4, and even
that was followed by rc5. Perhaps it's only CMake 2.4 that stumbles over
this.

Checking...

Indeed, no warning with 2.6, while 2.4 DOES warn (but continues with
configuring).

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

Re: [osg-users] build errors with 2.8.1

2009-06-04 Thread Paul Melis

John Kelso wrote:
> Hi,
>
> cmake 2.4-patch 8, that came with CentOS release 5.3.
>
> Our systems have been upgraded since my last OSG build, so I'll see if
> there's any relationship.  If I get stuck I'll mail again.
>
> Should I see if our system guy can install a newer cmake?
First, try this:

In applications/osgversion/CMakeLists.txt change ENDIF() to
ENDIF(OSG_MAINTAINER)
That line looks fishy.

Paul

>
> Thanks again,
>
> John
>
> On Thu, 4 Jun 2009, Paul Melis wrote:
>
>> Ulrich Hertlein wrote:
>>> Hi John,
>>>
>>> On 4/6/09 7:24 PM, John Kelso wrote:
 After downloading 2.8.1 and typing cmake, I got this error:

 "The end of a CMakeLists file was reached with an IF statement that
 was not
 closed properly. Within the directory:
 /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion



 The arguments are: OSG_MAINTAINER"

 Are all bets off from this point, or can this be safely ignored?

 I plowed ahead anyway and the make died a horrible death. Before I
 waste
 time figuring out why, I'm wondering if I could get some advice about
 the
 relevance and importance of the cmake message.
>>>
>>> You're probably using a version of cmake that is too old (maybe 2.4?)
>> The toplevel CMakeLists.txt contains
>>
>> IF(WIN32)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
>> ELSE(WIN32)
>>IF(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
>>ELSE(APPLE)
>>CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
>>ENDIF(APPLE)
>> ENDIF(WIN32)
>>
>> so either these checks are not strict enough and your version of CMake
>> is screwing up, or something else is going on.
>> What version of CMake do you use?
>>
>> Paul
>> ___
>> 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] build errors with 2.8.1

2009-06-04 Thread John Kelso


Hi,

cmake 2.4-patch 8, that came with CentOS release 5.3.

Our systems have been upgraded since my last OSG build, so I'll see if
there's any relationship.  If I get stuck I'll mail again.

Should I see if our system guy can install a newer cmake?

Thanks again,

John

On Thu, 4 Jun 2009, Paul Melis wrote:


Ulrich Hertlein wrote:

Hi John,

On 4/6/09 7:24 PM, John Kelso wrote:

After downloading 2.8.1 and typing cmake, I got this error:

"The end of a CMakeLists file was reached with an IF statement that
was not
closed properly. Within the directory:
/usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion


The arguments are: OSG_MAINTAINER"

Are all bets off from this point, or can this be safely ignored?

I plowed ahead anyway and the make died a horrible death. Before I waste
time figuring out why, I'm wondering if I could get some advice about
the
relevance and importance of the cmake message.


You're probably using a version of cmake that is too old (maybe 2.4?)

The toplevel CMakeLists.txt contains

IF(WIN32)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
   IF(APPLE)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
   ELSE(APPLE)
   CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
   ENDIF(APPLE)
ENDIF(WIN32)

so either these checks are not strict enough and your version of CMake
is screwing up, or something else is going on.
What version of CMake do you use?

Paul
___
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] VRML testing call

2009-06-04 Thread Seppo

Hi,

Might be simple one but I am not getting into it..

I get the following errors (and many more but I guess these few lines
describe  the problem enough) when building Plugins vrml:

1>Compiling...
1>ReaderWriterVRML2.cpp
1>C:\ohj\openvrml-0.17.12\src\libopenvrml\openvrml/basetypes.h(38) : error
C2059: syntax error : 'string'
1>C:\ohj\openvrml-0.17.12\src\libopenvrml\openvrml/basetypes.h(38) : error
C2146: syntax error : missing ';' before identifier 'color'

The OpenVRML itself compiled fine, these errors came at OSG..
Any idea of the problem?

Thanks in advance,
-Seppo


-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger
Sent: 26. toukokuuta 2009 15:10
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] VRML testing call

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jan Ciger wrote:
> Hello everyone,
> 
> I have updated the VRML plugin to use the latest OpenVRML 0.17.12 and
> Boost 1.38. Could the VRML users, test this, once Robert merges it,
please?
> 
> It works fine for me on Linux, but I didn't have a chance to test on
> other platforms.
> 
> Regards,
> 
> Jan


Here is a temporary location of the updated plugin sources before Robert
manages to put them into subversion:

http://www.aaue.dk/~janoc/files/download/vrml.zip

I am interested in people testing this on Windows and Mac - I do not
have these platforms available.

Regards,

Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFKG9wmn11XseNj94gRAvBOAKCRdgrij1E4RJQWRyaM1X9a6RGuTwCdFAHY
8VirDdCoMYuDGFC3H9sXH2M=
=Mmet
-END PGP SIGNATURE-
___
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] Database pager questions

2009-06-04 Thread Paul Martz

Hi Brett -- The "SingleThreaded" threading model is one of osgViewer's
threading models and is completely internal to osgViewer. It does not affect
the osgDB library. The DatabasePager's threading is orthogonal to
osgViewer's threading models used for rendering.

Paul Martz
Skew Matrix Software LLC
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

Re: [osg-users] get the x-axis angle of a rotation

2009-06-04 Thread Christian Sam

Hi james,

regarding your last post, did you mean that you also tried to extract angles 
from a rotation with the website's "matrixToEuler" or a similar approach, but 
you encountered  problems that were depended on your current 
camera-orientation? 

i think the same happened to me: i wanted to get the pitch-angle of the 
camera-orientation, to adjust the camera looking straight forward in certain 
cases. (think of some: reset view, but only for the pitch angle). i encountered 
that multiplying with the inverse rotation matrix of that angle didn't work if 
a left or right camera-rotation has been done before.
(actualy these negative-effects were only obvious when left/right rotation was 
larger than 45°. so i don't know if also minor yaw-rotations did harm, or only 
rotations exceeding a 45° threshold)

in the end, it put out that i had to build the adjustment-rotation matrix not 
with the pitch but the roll angle of the current camera-rotation in cases of 
previous left/right camera-rotations from 45° to 135° (respectively -45° to 
-135°) 

3.)
i'm not sure what you are meaning with "..it was not a success.." 
does the attachment you included work, and won't it suffers from symptoms, like 
described above?


Thanks in advance,
Christian

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





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

Re: [osg-users] Database pager questions

2009-06-04 Thread brettwiesner


Thanks!

Ralf Stokholm wrote:

Hi Brett
 
1&2) As far as I know the database pager is multithreaded regardless 
if osg is running multi or single threaded. Osg threading is related 
to threading of the cull and draw traversals.

3) How does the pager decide when to page something in?
My understanding is that this is based on the cull traversal if a 
pagedlod is (inside) the cull requirements based on the viewfrustrun 
and the lodscale of the camera. its children are loaded.


4) How does the pager decide when to page something out?
This depends on your sceme, when a given lod no longer fulfills the 
requirements to be in the scene it could be culled. The database pager 
pre 2.8 uses a sceme based on how much time has passed since the node 
last fulfilled the requirements to stay in the scene, in 2.8 the 
maximum number of nodes to keep can be capped.

5) How does the pager page something out?
Initially it is removed from the scenegraph and then the nodes are 
deleted (more likely they are dereferences and the ref_ptr takes care 
of freeing the memmory.
 
Brgs
 
Ralf Stokholm


2009/6/4 brettwiesner >


Hi,

Just validating some assumptions about the database pager...
1) Is paging in single threaded mode blocking? If OSG is in single
threaded mode, will the pager load data and stop rendering or will
it load in another thread anyway?
2) If OSG is running in multithreaded mode will the pager load
data asychronously?

Now some real questions:
3) How does the pager decide when to page something in?
4) How does the pager decide when to page something out?
5) How does the pager page something out?

Thanks,
Brett
___
osg-users mailing list
osg-users@lists.openscenegraph.org

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




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


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

Re: [osg-users] build errors with 2.8.1

2009-06-04 Thread Paul Melis

Ulrich Hertlein wrote:
> Hi John,
>
> On 4/6/09 7:24 PM, John Kelso wrote:
>> After downloading 2.8.1 and typing cmake, I got this error:
>>
>> "The end of a CMakeLists file was reached with an IF statement that
>> was not
>> closed properly. Within the directory:
>> /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion
>>
>>
>> The arguments are: OSG_MAINTAINER"
>>
>> Are all bets off from this point, or can this be safely ignored?
>>
>> I plowed ahead anyway and the make died a horrible death. Before I waste
>> time figuring out why, I'm wondering if I could get some advice about
>> the
>> relevance and importance of the cmake message.
>
> You're probably using a version of cmake that is too old (maybe 2.4?)
The toplevel CMakeLists.txt contains

IF(WIN32)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.6 FATAL_ERROR)
ELSE(WIN32)
IF(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6.0 FATAL_ERROR)
ELSE(APPLE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.4.0 FATAL_ERROR)
ENDIF(APPLE)
ENDIF(WIN32)

so either these checks are not strict enough and your version of CMake
is screwing up, or something else is going on.
What version of CMake do you use?

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

Re: [osg-users] Possible primitiveIndex inconsistency in osgUtil::LineSegmentIntersector

2009-06-04 Thread Andrew Cunningham

In my field of finite elements, mixtures of QUADS and TRIS are the rule , not 
the exception.
Anyway, the workaround is for me to always use a PolyTope intersector, even if 
it is only 1 pixel square...

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





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

Re: [osg-users] build errors with 2.8.1

2009-06-04 Thread Ulrich Hertlein


Hi John,

On 4/6/09 7:24 PM, John Kelso wrote:

After downloading 2.8.1 and typing cmake, I got this error:

"The end of a CMakeLists file was reached with an IF statement that was not
closed properly. Within the directory:
/usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion

The arguments are: OSG_MAINTAINER"

Are all bets off from this point, or can this be safely ignored?

I plowed ahead anyway and the make died a horrible death. Before I waste
time figuring out why, I'm wondering if I could get some advice about the
relevance and importance of the cmake message.


You're probably using a version of cmake that is too old (maybe 2.4?)

However, I've found that these messages can be ignored and the build would 
succeed.
What kind of errors are you getting?

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

Re: [osg-users] Database pager questions

2009-06-04 Thread Ralf Stokholm

Hi Brett

1&2) As far as I know the database pager is multithreaded regardless if osg
is running multi or single threaded. Osg threading is related to threading
of the cull and draw traversals.
3) How does the pager decide when to page something in?
My understanding is that this is based on the cull traversal if a pagedlod
is (inside) the cull requirements based on the viewfrustrun and the lodscale
of the camera. its children are loaded.

4) How does the pager decide when to page something out?
This depends on your sceme, when a given lod no longer fulfills the
requirements to be in the scene it could be culled. The database pager pre
2.8 uses a sceme based on how much time has passed since the node last
fulfilled the requirements to stay in the scene, in 2.8 the maximum number
of nodes to keep can be capped.
5) How does the pager page something out?
Initially it is removed from the scenegraph and then the nodes are deleted
(more likely they are dereferences and the ref_ptr takes care of freeing the
memmory.

Brgs

Ralf Stokholm

2009/6/4 brettwiesner 

> Hi,
>
> Just validating some assumptions about the database pager...
> 1) Is paging in single threaded mode blocking? If OSG is in single threaded
> mode, will the pager load data and stop rendering or will it load in another
> thread anyway?
> 2) If OSG is running in multithreaded mode will the pager load data
> asychronously?
>
> Now some real questions:
> 3) How does the pager decide when to page something in?
> 4) How does the pager decide when to page something out?
> 5) How does the pager page something out?
>
> Thanks,
> Brett
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] master/slave camera question

2009-06-04 Thread Wyatt Earp

Ok.  Thanks.  Not sure I understand the concept of cameras and master/slave
stuff as well as I should...  I searched the forum and mailing list
archives, but didn't come up with anything yet, but then again, searching on
something like "camera master slave" produces tons of hits.  Any
documentation that explains the camera concept and relation to viewer?


Thanks,

Wyatt

--
"Are you going to do something or just stand there and bleed?"
--




On Thu, Jun 4, 2009 at 3:06 AM, Robert Osfield wrote:

> HI Wyatt,
>
> Have a look at the osgdistortion example as it doesn't exactly what
> you are talking about.
>
> Robert.
>
> On Thu, Jun 4, 2009 at 12:36 AM, Wyatt Earp 
> wrote:
> > I want to render my scene to a texture using an FBO, then I want to take
> > that texture as input for another render pass, where I will do some magic
> in
> > a shader, finally displaying the results on a quad occupying the entire
> > fov.  How do I do this?  Does this involve slave cameras?
> >
> > In
> >
> http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuide/ViewerVSCompositeViewer
> > in the "Basic Explanation" section, it says that to do something like
> > distortion correction you would have one View, then have multiple slave
> > cameras along with the master.  Would my master render the scene to the
> > texture, and a slave do the magic?
> >
> > Where can I find more on OSG master/slave?  I found the cluster example,
> but
> > that isn't exactly what I am looking for.
> >
> >
> > Wyatt
> >
> > "I ain't nobody's huckleberry"
> >
> >
> > ___
> > 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] build errors with 2.8.1

2009-06-04 Thread John Kelso


Hi again,

As a stab in the dark to try and fix my memory leak I decided to try using
the latest OSG release.

After downloading 2.8.1 and typing cmake, I got this error:

 "The end of a CMakeLists file was reached with an IF statement that was not
 closed properly.  Within the directory:
 /usr/local/HEV-beta/apps/osg/osg-2.8.1/OpenSceneGraph/applications/osgversion
 The arguments are: OSG_MAINTAINER"

Are all bets off from this point, or can this be safely ignored?

I plowed ahead anyway and the make died a horrible death.  Before I waste
time figuring out why, I'm wondering if I could get some advice about the
relevance and importance of the cmake message.

I can send a typescript if it would be of use.

Thanks,

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

[osg-users] Database pager questions

2009-06-04 Thread brettwiesner


Hi,

Just validating some assumptions about the database pager...
1) Is paging in single threaded mode blocking? If OSG is in single 
threaded mode, will the pager load data and stop rendering or will it 
load in another thread anyway?
2) If OSG is running in multithreaded mode will the pager load data 
asychronously?


Now some real questions:
3) How does the pager decide when to page something in?
4) How does the pager decide when to page something out?
5) How does the pager page something out?

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

Re: [osg-users] Is clearing the nodemasks on loaded data a bad practice?

2009-06-04 Thread brettwiesner


Thanks!

Tomlinson, Gordon wrote:

Generically speaking changing the nodes masks is fine its up to you and
how your program is using them with-in the confines of how culling,
rendering uses them etc.

So no I would says it is not bad practice and is perfectly valid to do


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
brettwiesner
Sent: Thursday, June 04, 2009 12:00 PM
To: OpenSceneGraph Users
Subject: [osg-users] Is clearing the nodemasks on loaded data a bad
practice?

Hi,

We use nodemasks in our scenegraph to do things like figure out what can
be picked, what can be shadowed, etc. When we load data most of the time
the nodes come in with masks of 0x. Occasionally we get an .ive
or .osg file that has some other value set in the nodemask. We are going
to reset these values under the admonition "it's our scenegraph. we
control those bits". If we leave them alone we have to figure out
another way to do picking, shadows, etc.

So my question... is this bad practice?

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

Re: [osg-users] How to apply LISPSM shadows to a scene with differentshaders - Part 3

2009-06-04 Thread Michael Guerrero

Wojciech Lewandowski  writes:

> 
> Miguel,
> 
> I am not sure whats the problem. Shadows on the ground look ok. So the 
> matrices must be ok as well. All I can notice is improper self shadowing on 
> soldier models. If this is the case then look at following thread:
> http://www.mail-archive.com/osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF 
public.gmane.org/msg26683.html
> 
> Cheers,
> Wojtek
> 

Thanks Wojciech, this is a self shadowing issue.  However, that link doesn't
work for me.  Could you repost?



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

Re: [osg-users] Is clearing the nodemasks on loaded data a bad practice?

2009-06-04 Thread Tomlinson, Gordon

Generically speaking changing the nodes masks is fine its up to you and
how your program is using them with-in the confines of how culling,
rendering uses them etc.

So no I would says it is not bad practice and is perfectly valid to do


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
brettwiesner
Sent: Thursday, June 04, 2009 12:00 PM
To: OpenSceneGraph Users
Subject: [osg-users] Is clearing the nodemasks on loaded data a bad
practice?

Hi,

We use nodemasks in our scenegraph to do things like figure out what can
be picked, what can be shadowed, etc. When we load data most of the time
the nodes come in with masks of 0x. Occasionally we get an .ive
or .osg file that has some other value set in the nodemask. We are going
to reset these values under the admonition "it's our scenegraph. we
control those bits". If we leave them alone we have to figure out
another way to do picking, shadows, etc.

So my question... is this bad practice?

Thanks,
Brett
___
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] Is clearing the nodemasks on loaded data a bad practice?

2009-06-04 Thread brettwiesner


Hi,

We use nodemasks in our scenegraph to do things like figure out what can 
be picked, what can be shadowed, etc. When we load data most of the time 
the nodes come in with masks of 0x. Occasionally we get an .ive 
or .osg file that has some other value set in the nodemask. We are going 
to reset these values under the admonition "it's our scenegraph. we 
control those bits". If we leave them alone we have to figure out 
another way to do picking, shadows, etc.


So my question... is this bad practice?

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Robert Osfield

Hi Colin,

On Thu, Jun 4, 2009 at 4:25 PM, Colin Steinberg
 wrote:
> Have you considered some kind of layered approach?  Maybe an immediate
> interface to the physical keycodes, sending events for every _key_ press
> and release.  Another layer could then use the windowing-system mappings
> to convert these events to _character_ press/release events.

The window-system key mapping is something you want to do inside the
windowing specific code paths in osgViewer i.e.
GraphicsWindowX11/GraphicsWindowWin32 etc, so do this externally would
complicate things.  Would could potentially put some kind of
abstraction layer for this functionality, but there is a danger of
this all getting rather convoluted.

We may have to take a complicated route to get a full solution.  I'm
open to suggestions on different solutions, perhaps we can come up
with a solution that is small addition to what we already have,
provide users the additional control/informtation when/where they need
it without being too intrusive.

Right now may favored tweak would be adding support for non modified
key codes into GUIEventAdapter.  This would just be an initial step.

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Colin Steinberg

Hi Folks,

Have you considered some kind of layered approach?  Maybe an immediate
interface to the physical keycodes, sending events for every _key_ press
and release.  Another layer could then use the windowing-system mappings
to convert these events to _character_ press/release events.

If this second layer would be added per default it should not break
current applications.  Clients that need the physical codes could easily
disable the translation layer, or even replace it with their own
keyevent-translation scheme.

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Robert Osfield

Hi Ralf,

Thanks for the links and explanation, this makes is clearer.

So what I can read from this is they the virtual key codes mapped to
physical events, and the printable characters are akin to state.

Robert.

On Thu, Jun 4, 2009 at 3:33 PM, Ralph Kern  wrote:
> Hi Robert,
>
> here are the pointers to the MS docu:
>
> virtual key codes:
>
> http://msdn.microsoft.com/en-us/library/ms927178.aspx
>
> MS explanation for their term "virtual key code":
>
> http://msdn.microsoft.com/en-us/library/ms927175.aspx
>
> Reference for WM_KEYDOWN (has also links to WM_KEYUP and WM_CHAR in the
> "See also" section):
>
> http://msdn.microsoft.com/en-us/library/aa921842.aspx
>
> In short: virtual key codes represent the physical keys on the keyboard
> (including also mouse buttons) and are used in the KEYUP/KEYDOWN events,
> while the CHAR events represent *printable* characters for a text
> string. For example, the function key F1 produces KEYDOWN/KEYUP events,
> but never generates a CHAR event.
>
> So there is only one virtual key code for the "a" key, but it can
> generate a CHAR event for "a" or "A", depending on the keyboard state
> regarding SHIFT, SHIFT-LOCK, CTRL, ...
>
> I don't know whether these virtual key codes relate to X11 keysyms,
> because I have little knowledge of the X11 API.
>
> regards Ralph
>
> Robert Osfield schrieb:
>> HI Ralf,
>>
>> Thanks for the info.  Just to be clear on language and actions could
>> you clarify the following.
>>
>> By virtual key codes do you mean the raw keycodes?  I.e. whether you
>> press 'a' or have shift pressed to get 'A' you still get 'a'?    Or
>> are the WM_CHAR the raw keycodes?
>>
>> W.r.t key presses/key releases.  Are these just from the raw key
>> codes?  Or the final modified character codes?
>>
>> Robert.
>>
>> On Thu, Jun 4, 2009 at 2:43 PM, Ralph Kern  wrote:
>>> hi,
>>>
>>> perhaps some input from the MS Windows event API: They differentiate
>>> between key press and release events (WM_KEYDOWN/WM_KEYUP) using
>>> "virtual key codes" and "typed character" events (WM_CHAR) which is the
>>> UTF-16 code of a typo generated because of some key press.
>>>
>>> The virtual key codes include symbols for SHIFT, CTRL and any other
>>> button present on the keyboard. For the WM_CHAR events, there is no
>>> notion of press/release.
>>>
>>> regards Ralph
>>>
>>> Melchior FRANZ schrieb:
 Hi,

 * Robert Osfield -- Thursday 04 June 2009:
> I don't think calling it bug clarifies anything, [...]
 I didn't call it a "bug" to clarify anything, but because the current
 behaviour is without any doubt broken. Maybe I should have used the
 MS euphemism "issue" instead.  :-)

 Your examples use the comparatively trivial 'a' and 'A' case. Here clients
 can make the assumption that both are on the same physcial key (although
 even that is problematic). So, for an  aaaAAA  sequence you can assume
 that with the first 'a' physical key 38 was pressed, and with the third
 'A' the same key was released.

 But take '3' and '#' instead, and a sequence  333###. Here the client
 has no way to realize that this was one and the same physical key 12.
 It can *not* assume that the '#' is the successor of the '3' on the
 same key. Because the two symbols are only on one key on US-keyboards.
 On a German keyboard it's '3' and '§'. And clients know nothing about
 the layout.

 So there's not a question *if* release events have to be made up, but
 *where*. This can be done in OSG, or in client software (given the
 necessary, but currently missing information: the keycode). But it looks
 like we already agree on that one.  :-)



> One also will need to decide if press 'a' and hold down then press
> shift, then press release shift to do aAa should you get the events:
 True. The problem is that OSG events don't actually represent physical
 keys, but symbols. (The keycode information is thrown away, after all). So
 IMHO we have to think in terms of keySym sequences. And for me aaAAAaa is
 a-press ... a-release, A-press...A-release, a-press...a-release. The
 shift modifier changes symbol 'a' to 'A', and it's IMHO hard to argue
 that 'a' is still considered pressed during all of aaaAAA. That would
 mean that for the client there's 'a' and 'A' pressed at the same time
 for a while. That's especially bad if both keys are meant to have
 antagonistic effects, which is rather common, I guess.



> The proper solution probably lies in have raw keyboard events, and the
> modified virtual events handled in some coherent fashion exactly what
> I can't say yet.
 Agreed. Maybe it's also time for others to add their wisdom, now that
 we are already a bit tired and annoyed. (Aren't we?  ;-)

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

Re: [osg-users] Transparency on geode and shared stateSet

2009-06-04 Thread Vincent Bourdier

Hi,

I do a little UP of my question ...
Thanks :-)

Regards,
   Vincent.

2009/6/3 Vincent Bourdier 

> Hi all,
>
> I'm looking at a way to set some geodes with transparency level.
>
> This is the problem : these geodes share a stateSet with a lot of other
> geodes, so I cannot just set transparency on it...
>
>
> The only way I know to change the opacity on a geode is to set the StateSet
> with GL_Blend and change the color Array... That's why I need to un share
> the StateSet, because if I don't, Other geodes will be in Blend mode..
>
> For the moment, I've done a visitor which goal is to un-share the StateSet,
> but the graph traverse is slower now ... (FPS divided by two : lots of
> nodes)
>
> I would like to keep the StateSet, and to avoid beeing so much intrusive
> than changing the color Array...
>
> My algorithm is like this :
>
> ChangeAlpha(node * n)
> {
> if node as material
>change material with alpha component
> else
>   if node is a group
> for each children
>ChangeAlpha(group->getChild(i)
>   else if node is a geode
>  set StateSet with BLEND and Change colorArray with alpha.
>   endif
> endif
> }
>
> Do you have any idea ?
>
> Thanks.
>
> Regards,
>Vincent.
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Ralph Kern

Hi Robert,

here are the pointers to the MS docu:

virtual key codes:

http://msdn.microsoft.com/en-us/library/ms927178.aspx

MS explanation for their term "virtual key code":

http://msdn.microsoft.com/en-us/library/ms927175.aspx

Reference for WM_KEYDOWN (has also links to WM_KEYUP and WM_CHAR in the
"See also" section):

http://msdn.microsoft.com/en-us/library/aa921842.aspx

In short: virtual key codes represent the physical keys on the keyboard
(including also mouse buttons) and are used in the KEYUP/KEYDOWN events,
while the CHAR events represent *printable* characters for a text
string. For example, the function key F1 produces KEYDOWN/KEYUP events,
but never generates a CHAR event.

So there is only one virtual key code for the "a" key, but it can
generate a CHAR event for "a" or "A", depending on the keyboard state
regarding SHIFT, SHIFT-LOCK, CTRL, ...

I don't know whether these virtual key codes relate to X11 keysyms,
because I have little knowledge of the X11 API.

regards Ralph

Robert Osfield schrieb:
> HI Ralf,
> 
> Thanks for the info.  Just to be clear on language and actions could
> you clarify the following.
> 
> By virtual key codes do you mean the raw keycodes?  I.e. whether you
> press 'a' or have shift pressed to get 'A' you still get 'a'?Or
> are the WM_CHAR the raw keycodes?
> 
> W.r.t key presses/key releases.  Are these just from the raw key
> codes?  Or the final modified character codes?
> 
> Robert.
> 
> On Thu, Jun 4, 2009 at 2:43 PM, Ralph Kern  wrote:
>> hi,
>>
>> perhaps some input from the MS Windows event API: They differentiate
>> between key press and release events (WM_KEYDOWN/WM_KEYUP) using
>> "virtual key codes" and "typed character" events (WM_CHAR) which is the
>> UTF-16 code of a typo generated because of some key press.
>>
>> The virtual key codes include symbols for SHIFT, CTRL and any other
>> button present on the keyboard. For the WM_CHAR events, there is no
>> notion of press/release.
>>
>> regards Ralph
>>
>> Melchior FRANZ schrieb:
>>> Hi,
>>>
>>> * Robert Osfield -- Thursday 04 June 2009:
 I don't think calling it bug clarifies anything, [...]
>>> I didn't call it a "bug" to clarify anything, but because the current
>>> behaviour is without any doubt broken. Maybe I should have used the
>>> MS euphemism "issue" instead.  :-)
>>>
>>> Your examples use the comparatively trivial 'a' and 'A' case. Here clients
>>> can make the assumption that both are on the same physcial key (although
>>> even that is problematic). So, for an  aaaAAA  sequence you can assume
>>> that with the first 'a' physical key 38 was pressed, and with the third
>>> 'A' the same key was released.
>>>
>>> But take '3' and '#' instead, and a sequence  333###. Here the client
>>> has no way to realize that this was one and the same physical key 12.
>>> It can *not* assume that the '#' is the successor of the '3' on the
>>> same key. Because the two symbols are only on one key on US-keyboards.
>>> On a German keyboard it's '3' and '§'. And clients know nothing about
>>> the layout.
>>>
>>> So there's not a question *if* release events have to be made up, but
>>> *where*. This can be done in OSG, or in client software (given the
>>> necessary, but currently missing information: the keycode). But it looks
>>> like we already agree on that one.  :-)
>>>
>>>
>>>
 One also will need to decide if press 'a' and hold down then press
 shift, then press release shift to do aAa should you get the events:
>>> True. The problem is that OSG events don't actually represent physical
>>> keys, but symbols. (The keycode information is thrown away, after all). So
>>> IMHO we have to think in terms of keySym sequences. And for me aaAAAaa is
>>> a-press ... a-release, A-press...A-release, a-press...a-release. The
>>> shift modifier changes symbol 'a' to 'A', and it's IMHO hard to argue
>>> that 'a' is still considered pressed during all of aaaAAA. That would
>>> mean that for the client there's 'a' and 'A' pressed at the same time
>>> for a while. That's especially bad if both keys are meant to have
>>> antagonistic effects, which is rather common, I guess.
>>>
>>>
>>>
 The proper solution probably lies in have raw keyboard events, and the
 modified virtual events handled in some coherent fashion exactly what
 I can't say yet.
>>> Agreed. Maybe it's also time for others to add their wisdom, now that
>>> we are already a bit tired and annoyed. (Aren't we?  ;-)
>>>
>>> m.
>>> ___
>>> 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.openscenegr

Re: [osg-users] transparent object sorting and back face culling

2009-06-04 Thread Jason Daly


su hu wrote:

Hi

All transparent nodes should be found out and set to TRANSPARENT_BIN 
one bye one. Nodes should be small enough.


But there are lots of transparent nodes in scene. How to find out 
those transparent nodes quickly? Thanks for your help.


I can't think of a reason why you'd need to find nodes to be put in the 
transparent bin.  If you load your scene from files, the plugin that 
loaded them should take care of this for you.  If you are creating scene 
elements dynamically, then you should set the bin as they are created.


Finding transparency in an existing scene is possible.  You'd have to 
write a custom NodeVisitor to traverse the scene.  At each Node, you'd 
check for state sets with transparent Materials (alpha set to less than 
1) and Textures with transparent texels.  At each Geometry, you'd look 
for values in the color arrays with alpha less than 1.


As I said before, though, this shouldn't be necessary in most cases.

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Robert Osfield

HI Ralf,

Thanks for the info.  Just to be clear on language and actions could
you clarify the following.

By virtual key codes do you mean the raw keycodes?  I.e. whether you
press 'a' or have shift pressed to get 'A' you still get 'a'?Or
are the WM_CHAR the raw keycodes?

W.r.t key presses/key releases.  Are these just from the raw key
codes?  Or the final modified character codes?

Robert.

On Thu, Jun 4, 2009 at 2:43 PM, Ralph Kern  wrote:
> hi,
>
> perhaps some input from the MS Windows event API: They differentiate
> between key press and release events (WM_KEYDOWN/WM_KEYUP) using
> "virtual key codes" and "typed character" events (WM_CHAR) which is the
> UTF-16 code of a typo generated because of some key press.
>
> The virtual key codes include symbols for SHIFT, CTRL and any other
> button present on the keyboard. For the WM_CHAR events, there is no
> notion of press/release.
>
> regards Ralph
>
> Melchior FRANZ schrieb:
>> Hi,
>>
>> * Robert Osfield -- Thursday 04 June 2009:
>>> I don't think calling it bug clarifies anything, [...]
>>
>> I didn't call it a "bug" to clarify anything, but because the current
>> behaviour is without any doubt broken. Maybe I should have used the
>> MS euphemism "issue" instead.  :-)
>>
>> Your examples use the comparatively trivial 'a' and 'A' case. Here clients
>> can make the assumption that both are on the same physcial key (although
>> even that is problematic). So, for an  aaaAAA  sequence you can assume
>> that with the first 'a' physical key 38 was pressed, and with the third
>> 'A' the same key was released.
>>
>> But take '3' and '#' instead, and a sequence  333###. Here the client
>> has no way to realize that this was one and the same physical key 12.
>> It can *not* assume that the '#' is the successor of the '3' on the
>> same key. Because the two symbols are only on one key on US-keyboards.
>> On a German keyboard it's '3' and '§'. And clients know nothing about
>> the layout.
>>
>> So there's not a question *if* release events have to be made up, but
>> *where*. This can be done in OSG, or in client software (given the
>> necessary, but currently missing information: the keycode). But it looks
>> like we already agree on that one.  :-)
>>
>>
>>
>>> One also will need to decide if press 'a' and hold down then press
>>> shift, then press release shift to do aAa should you get the events:
>>
>> True. The problem is that OSG events don't actually represent physical
>> keys, but symbols. (The keycode information is thrown away, after all). So
>> IMHO we have to think in terms of keySym sequences. And for me aaAAAaa is
>> a-press ... a-release, A-press...A-release, a-press...a-release. The
>> shift modifier changes symbol 'a' to 'A', and it's IMHO hard to argue
>> that 'a' is still considered pressed during all of aaaAAA. That would
>> mean that for the client there's 'a' and 'A' pressed at the same time
>> for a while. That's especially bad if both keys are meant to have
>> antagonistic effects, which is rather common, I guess.
>>
>>
>>
>>> The proper solution probably lies in have raw keyboard events, and the
>>> modified virtual events handled in some coherent fashion exactly what
>>> I can't say yet.
>>
>> Agreed. Maybe it's also time for others to add their wisdom, now that
>> we are already a bit tired and annoyed. (Aren't we?  ;-)
>>
>> m.
>> ___
>> 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] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Melchior FRANZ

Hey,

* Mathias Fröhlich -- Thursday 04 June 2009:
> May be we need to track these up/down event pairs in *flightgear*.

We can't ATM, because we don't have the keycodes! That's why I started the
thread in the first place! And my assumption was that it's better fixed
once in OSG, than in every single application with the same issue. But
I don't insist, and not only because that wouldn't work.  ;-)


This key "issue" is why we have this gem in FlightGear's FGEventHandler.cxx:

// Release the letter key, for which the key press was reported. This
// is to deal with Ctrl-press -> a-press -> Ctrl-release -> a-release
// correctly.
if (key >= 0 && key < 128) {
if (modifiers & KEYMOD_RELEASED) {
key = release_keys[key];
} else {
release_keys[key] = key;
if (key >= 1 && key <= 26) {
release_keys[key + '@'] = key;
release_keys[key + '`'] = key;
} else if (key >= 'A' && key <= 'Z') {
release_keys[key - '@'] = key;
release_keys[tolower(key)] = key;
} else if (key >= 'a' && key <= 'z') {
release_keys[key - '`'] = key;
release_keys[toupper(key)] = key;
}
}
}

But that fixes the problem only for letter keys, for which, as I've said
already, the workaround is quite simple. It's impossible for all other
keys. There's another one that's even uglier in multikey.nas:

if (cmd == "" and key.getValue() == `;`)  # FIXME hack around kbd bug
key.setValue(`:`);

This considers that a ':' might never be released as ':', but as ';'.
*On US-layout!* (Screw all the rest, I say.  :-)



> ... if an application needs these synthetic events, exactly this application 
> should synthesize these events?

Well, if additional (we have some already!) artifical events are considered
undesirable, sure. Then we need the keycode in the key event structure.
Either is fine with me, really. At the moment it's broken and *unfixable*
in FlightGear.

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Robert Osfield

HI Mathias,

2009/6/4 Mathias Fröhlich :
>
> Hi Melchior,
>
> On Thursday 04 June 2009, Melchior FRANZ wrote:
> [...]
>
> May be we need to track these up/down event pairs in *flightgear*.
> ... if an application needs these synthetic events, exactly this application
> should synthesize these events?
> You cannot expect that this special usage pattern of one application matches
> the pattern of all other applications ...

I think part of the problem is we currently have a bit of half way
house on the OSG side.  It's returning key events in their modified
state, but only issuing events when the unmodified key is
pressed/released.

The current state of affairs makes it difficult to do the tracking on
the client side.  If we add support for passing back the unmodified
key codes in the events then one could start to think about doing the
matching on the client side.

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Ralph Kern

hi,

perhaps some input from the MS Windows event API: They differentiate
between key press and release events (WM_KEYDOWN/WM_KEYUP) using
"virtual key codes" and "typed character" events (WM_CHAR) which is the
UTF-16 code of a typo generated because of some key press.

The virtual key codes include symbols for SHIFT, CTRL and any other
button present on the keyboard. For the WM_CHAR events, there is no
notion of press/release.

regards Ralph

Melchior FRANZ schrieb:
> Hi,
> 
> * Robert Osfield -- Thursday 04 June 2009:
>> I don't think calling it bug clarifies anything, [...]
> 
> I didn't call it a "bug" to clarify anything, but because the current
> behaviour is without any doubt broken. Maybe I should have used the
> MS euphemism "issue" instead.  :-)
> 
> Your examples use the comparatively trivial 'a' and 'A' case. Here clients
> can make the assumption that both are on the same physcial key (although
> even that is problematic). So, for an  aaaAAA  sequence you can assume
> that with the first 'a' physical key 38 was pressed, and with the third
> 'A' the same key was released.
> 
> But take '3' and '#' instead, and a sequence  333###. Here the client
> has no way to realize that this was one and the same physical key 12.
> It can *not* assume that the '#' is the successor of the '3' on the
> same key. Because the two symbols are only on one key on US-keyboards.
> On a German keyboard it's '3' and '§'. And clients know nothing about
> the layout.
> 
> So there's not a question *if* release events have to be made up, but
> *where*. This can be done in OSG, or in client software (given the
> necessary, but currently missing information: the keycode). But it looks
> like we already agree on that one.  :-)
> 
> 
> 
>> One also will need to decide if press 'a' and hold down then press
>> shift, then press release shift to do aAa should you get the events:
> 
> True. The problem is that OSG events don't actually represent physical
> keys, but symbols. (The keycode information is thrown away, after all). So 
> IMHO we have to think in terms of keySym sequences. And for me aaAAAaa is
> a-press ... a-release, A-press...A-release, a-press...a-release. The
> shift modifier changes symbol 'a' to 'A', and it's IMHO hard to argue
> that 'a' is still considered pressed during all of aaaAAA. That would
> mean that for the client there's 'a' and 'A' pressed at the same time
> for a while. That's especially bad if both keys are meant to have
> antagonistic effects, which is rather common, I guess.
> 
> 
> 
>> The proper solution probably lies in have raw keyboard events, and the
>> modified virtual events handled in some coherent fashion exactly what
>> I can't say yet.
> 
> Agreed. Maybe it's also time for others to add their wisdom, now that
> we are already a bit tired and annoyed. (Aren't we?  ;-)
> 
> m.
> ___
> 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] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Mathias Fröhlich


Hi Melchior,

On Thursday 04 June 2009, Melchior FRANZ wrote:
[...]

May be we need to track these up/down event pairs in *flightgear*.
... if an application needs these synthetic events, exactly this application 
should synthesize these events?
You cannot expect that this special usage pattern of one application matches 
the pattern of all other applications ...

Greetings

Mathias

-- 
Dr. Mathias Fröhlich, science + computing ag, Software Solutions
Hagellocher Weg 71-75, D-72070 Tuebingen, Germany
Phone: +49 7071 9457-268, Fax: +49 7071 9457-511
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Paul Speed

From my perspective, if I were writing a game control scheme, I'd want 
all downs and all ups with raw key codes. 'a' down, left-shift down, 'a' 
up, left-shift up.


Just because application X is using the keys to type human words doesn't 
mean that application Y has any relationship between shift and 'a'.  (In 
this case, maybe 'a' is move left and shift is run... for a really 
really common example.)  Inserting extra events is at best unhelpful, at 
worst confusing.  What application X needs is a way to get from "shift + 
'a' key" to "A".  I'm not sure including the virtual character codes 
right in the event is the best way... though it may be the only way in 
OSG's API.


-Paul

Melchior FRANZ wrote:

Hi,

* Robert Osfield -- Thursday 04 June 2009:

I don't think calling it bug clarifies anything, [...]


I didn't call it a "bug" to clarify anything, but because the current
behaviour is without any doubt broken. Maybe I should have used the
MS euphemism "issue" instead.  :-)

Your examples use the comparatively trivial 'a' and 'A' case. Here clients
can make the assumption that both are on the same physcial key (although
even that is problematic). So, for an  aaaAAA  sequence you can assume
that with the first 'a' physical key 38 was pressed, and with the third
'A' the same key was released.

But take '3' and '#' instead, and a sequence  333###. Here the client
has no way to realize that this was one and the same physical key 12.
It can *not* assume that the '#' is the successor of the '3' on the
same key. Because the two symbols are only on one key on US-keyboards.
On a German keyboard it's '3' and '§'. And clients know nothing about
the layout.

So there's not a question *if* release events have to be made up, but
*where*. This can be done in OSG, or in client software (given the
necessary, but currently missing information: the keycode). But it looks
like we already agree on that one.  :-)




One also will need to decide if press 'a' and hold down then press
shift, then press release shift to do aAa should you get the events:


True. The problem is that OSG events don't actually represent physical
keys, but symbols. (The keycode information is thrown away, after all). So 
IMHO we have to think in terms of keySym sequences. And for me aaAAAaa is

a-press ... a-release, A-press...A-release, a-press...a-release. The
shift modifier changes symbol 'a' to 'A', and it's IMHO hard to argue
that 'a' is still considered pressed during all of aaaAAA. That would
mean that for the client there's 'a' and 'A' pressed at the same time
for a while. That's especially bad if both keys are meant to have
antagonistic effects, which is rather common, I guess.




The proper solution probably lies in have raw keyboard events, and the
modified virtual events handled in some coherent fashion exactly what
I can't say yet.


Agreed. Maybe it's also time for others to add their wisdom, now that
we are already a bit tired and annoyed. (Aren't we?  ;-)

m.
___
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] Set fog in the canera StateSet

2009-06-04 Thread Cristina Paponi

Hi,
Shayne
My code is more or less like yours, but I'm not using the Composite viewer. I'm 
not sure why it doesn't work.

Hi Wojtek Lewandowski
Your solution worked for me too.

Thank you both for your time!

Cheers,
Cristina

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





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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Melchior FRANZ

Hi,

* Robert Osfield -- Thursday 04 June 2009:
> I don't think calling it bug clarifies anything, [...]

I didn't call it a "bug" to clarify anything, but because the current
behaviour is without any doubt broken. Maybe I should have used the
MS euphemism "issue" instead.  :-)

Your examples use the comparatively trivial 'a' and 'A' case. Here clients
can make the assumption that both are on the same physcial key (although
even that is problematic). So, for an  aaaAAA  sequence you can assume
that with the first 'a' physical key 38 was pressed, and with the third
'A' the same key was released.

But take '3' and '#' instead, and a sequence  333###. Here the client
has no way to realize that this was one and the same physical key 12.
It can *not* assume that the '#' is the successor of the '3' on the
same key. Because the two symbols are only on one key on US-keyboards.
On a German keyboard it's '3' and '§'. And clients know nothing about
the layout.

So there's not a question *if* release events have to be made up, but
*where*. This can be done in OSG, or in client software (given the
necessary, but currently missing information: the keycode). But it looks
like we already agree on that one.  :-)



> One also will need to decide if press 'a' and hold down then press
> shift, then press release shift to do aAa should you get the events:

True. The problem is that OSG events don't actually represent physical
keys, but symbols. (The keycode information is thrown away, after all). So 
IMHO we have to think in terms of keySym sequences. And for me aaAAAaa is
a-press ... a-release, A-press...A-release, a-press...a-release. The
shift modifier changes symbol 'a' to 'A', and it's IMHO hard to argue
that 'a' is still considered pressed during all of aaaAAA. That would
mean that for the client there's 'a' and 'A' pressed at the same time
for a while. That's especially bad if both keys are meant to have
antagonistic effects, which is rather common, I guess.



> The proper solution probably lies in have raw keyboard events, and the
> modified virtual events handled in some coherent fashion exactly what
> I can't say yet.

Agreed. Maybe it's also time for others to add their wisdom, now that
we are already a bit tired and annoyed. (Aren't we?  ;-)

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

Re: [osg-users] memory leak in osg::StateSet::merge() ?

2009-06-04 Thread Paul Melis


Hi,

John Kelso wrote:

Hi Robert,

I must admit I used a pretty simplistic method.  While running my app 
I run

"top" in another window and look at the process' virtual memory size.

When running without the merge the virtual memory size never changes.  
When

running with the merge, the size steadily increases.  After about 16,000
merges my malloc's fail and the process crashes.

I too looked at the merge code and didn't see anything obvious.

I have the feeling that I'm doing something fundamentally wrong that 
will be
embarrassingly obvious in hindsight, but for now has me stumped.  I'm 
waiting

for the "Ah ha" moment to strike.

If you can suggest any tests to run, or have any other suggestions, it 
would

be appreciated.
Try using valgrind's massif. It makes snapshots of a program's heap 
allocation during its lifetime and
can report for each snapshot where the memory was allocated. Here's an 
example:


14:40|p...@tabu:~/cppexamples> cat osg_leak.cpp
// example leaky program
// g++ -o oll osg_leak.cpp -I ~/osg2.8/include/ -L ~/osg2.8/lib/ -losg 
-losgDB

#include 
int main()
{
   osg::Group* group;
   for (int i = 0; i < 10; i++)
   group = new osg::Group;
}
14:40|p...@tabu:~/cppexamples> g++ -g -o leak osg_leak.cpp -I 
~/osg2.8/include/ -L ~/osg2.8/lib/ -losg -losgDB

14:40|p...@tabu:~/cppexamples> valgrind --tool=massif ./leak
[...]
14:41|p...@tabu:~/cppexamples> ls -ltr
[...]
-rw---  1 paul paul 14848 Jun  4 14:41 massif.out.11415
14:41|p...@tabu:~/cppexamples> ms_print massif.out.11415
# actual output contains much more, including a nice graph

# of memory consumption over time ;-)
[...]

 ntime(i) total(B)   useful-heap(B) extra-heap(B)
stacks(B)


79 47,051,074   21,761,128   18,959,969 
2,801,1590
87.13% (18,959,969B) (heap allocation functions) malloc/new/new[], 
--alloc-fns, etc.

->66.17% (14,400,000B) 0x80486BD: main (osg_leak.cpp:7)
->12.87% (2,800,336B) 0x4378576: OpenThreads::Mutex::Mutex() 
(PThreadMutex.c++:38)
->03.68% (800,008B) 0x41C83C4: osg::Referenced::Referenced(bool) 
(Referenced.cpp:180)

->02.56% (557,370B) in 21 places, all below massif's threshold (01.00%)
->01.85% (402,255B) 0x92F65C: (within /usr/lib/libGL.so.96.43.01)

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

Re: [osg-users] memory leak in osg::StateSet::merge() ?

2009-06-04 Thread John Kelso


Hi Robert,

I must admit I used a pretty simplistic method.  While running my app I run
"top" in another window and look at the process' virtual memory size.

When running without the merge the virtual memory size never changes.  When
running with the merge, the size steadily increases.  After about 16,000
merges my malloc's fail and the process crashes.

I too looked at the merge code and didn't see anything obvious.

I have the feeling that I'm doing something fundamentally wrong that will be
embarrassingly obvious in hindsight, but for now has me stumped.  I'm waiting
for the "Ah ha" moment to strike.

If you can suggest any tests to run, or have any other suggestions, it would
be appreciated.

Thanks,

John

On Thu, 4 Jun 2009, Robert Osfield wrote:


Hi John,

Since StateSet uses ref_ptr<> internally for all StateAttribute, and
merge doesn't create anything on the heap - it just copies then it's
pretty unlikely there is a memory leak.

Far more likely is that the tool you are using for tracking memory
leaks is faulty.  Could you please explain what makes you think you
have a memory leak?

Robert.

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Robert Osfield

Hi Melchior,

On Thu, Jun 4, 2009 at 10:43 AM, Melchior FRANZ
 wrote:
> Making the physcial key number available in the event structure would
> allow us to fix our problem in FlightGear, though I think the bug
> is in OSG and should be fixed there.

I don't think calling it bug clarifies anything, rather it muddies the
waters with what is actually the problem as the GraphicsWindowX11 is
reported exactly what is going on w.r.t modified keys.  As fixing what
you see as a bug, could just as easily introduce a bug for others who
make different assumptions about how events modifications are handled.

I would like to see this problem addressed in a way that makes it easy
for end users to cope with this issue.  Injecting events in this
instance is a workaround, but it's a workaround that itself breaks
things.

One step we should take is to add support for reporting back
unmodified keycodes in GraphicsWindowX11/Win32/Carbon and Cocoa in
consistent way.

Another step will be to decide how to report changes in modification
of a key that has been pressed.  If we wanted to report just the key
events pressed then we'd just report the shift key being pressed, not
the other keys that have modified, so we wouldn't report the 'A' being
pressed after the 'a' has been held down, rather we'd report the shift
being pressed.  If one just works in unmodified keys then this works
fine.  Since we do modify the keys things get muddier - with the
later, effectively we'd need to create a layer on top of "virtual key
presses".

One also will need to decide if press 'a' and hold down then press
shift, then press release shift to do aAa should you get the events:

  a pressed.
  A pressed.
  A released.
  a pressed.
  a  released.

Or

  a pressed.
  a released, A pressed.
  A release, a pressed.
  a released.

Or

  a pressed.
  A pressed.
  A release.
  a released.

Or

  a pressed.
  A pressed
  a pressed.
  a released

All are potentially valid interpretations of how to map these virtue
key presses... who's to say which ones are buggy and which ones
aren't?  You basically can't.

The proper solution probably lies in have raw keyboard events, and the
modified virtual events handled in some coherent fashion exactly what
I can't say yet.

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

Re: [osg-users] [3rdparty] osgART install

2009-06-04 Thread Karl Butler

Thanks internetscooter I'll check it out :)

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





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

Re: [osg-users] Textures disappear when re-loading a previously closed scene?

2009-06-04 Thread Robert Osfield

Hi Christophe,

You can't use setUnRefImageDataAfterApply(true) and expect textures to
remain valid between open and closing and then reopening graphics
contexts as the texture will have no imagery to reapply when required.

Robert.

On Thu, Jun 4, 2009 at 10:18 AM, Herreman, Christophe
 wrote:
> Hello,
>
>
>
> When I close a scene and re-open it again without closing the application,
> all the textures have disappeared and only white rectangles are visible.
>
>
>
> An warning is logged by OSG: “Warning: detected opengl error ‘invalid value’
> after RenderBin::draw(,)”
>
>
>
> All resources are freed when a scene (document) is closed.
>
>
>
> Thinking that the registry was somehow keeping track of the texture, I tried
> to clear the registry with calls such as
>
> osgDB::Registry::instance()->clearObjectCache(); and
>
> osgDB::Registry::instance()->clearGLObjects();
>
> But this doesn’t improve it.
>
>
>
> BTW, I use the setUnRefImageDataAfterApply(true), to clear-up memory.
>
>
>
> Any ideas what I can try ?
>
>
>
> Thanks, Br
>
> Christophe
>
>
>
> OSG 2.8.1, Windows XP, nVidia quadro FX 2700
>
> DISCLAIMER:
> Unless indicated otherwise, the information contained in this message is
> privileged and confidential, and is intended only for the use of the
> addressee(s) named above and others who have been specifically authorized to
> receive it. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this message and/or
> attachments is strictly prohibited. The company accepts no liability for any
> damage caused by any virus transmitted by this email. Furthermore, the
> company does not warrant a proper and complete transmission of this
> information, nor does it accept liability for any delays. If you have
> received this message in error, please contact the sender and delete the
> message. Thank you.
>
> ___
> 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] [3rdparty] osgART install

2009-06-04 Thread Karl Butler

Yes I have installed ARToolKit and OSG already. 
What I need to know is how to use the file: osgART_2.0_RC3

It has no file extention and I am not sure how to use it with CMake as you 
suggested. Can you please elaborate on how to use CMake with it?

I have tried doing it the same way as I installed OSG but no success.

Do I even have the right file?

Thanks,
Karl.

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





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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Melchior FRANZ

* Robert Osfield -- Thursday 04 June 2009:
> I'm in two minds if I'd would classify this issue as a bug, and I'm in
> two minds about your suggested remedy.  The code is it stands right
> now doesn't enforce a matching of presses and releases, it just the
> way it works.  It's a bug if your assume that it does match.

Yes, and that's why applications can't do things for the duration of
a keypress. Consider the FightGear case again: pressing the SPACE
bar activates VoIP communication. If one releases the SPACE bar,
the microphone should be muted again. At the moment I can't rely
on that. There may never be a release event, because pressing the
Ctrl-key might modify 32 to 0. (Yes, we are hacking around this
unreliability, but that really only works for letters, as one can
assume that 'a', 'A', and 1 (Ctrl-a) are on the same physical key.
We can't make any assumptions for other keys.)

Making the physcial key number available in the event structure would
allow us to fix our problem in FlightGear, though I think the bug
is in OSG and should be fixed there. 



> Making them match does require inserting artificial events that the
> the person at the keyboard has never instigated directly,

Yes, but no unreasonable events. Actually, these are the events that
anyone would expect. And it's not like OSG wouldn't add other artificial
keypress/release events already. Remember my last keyboard patches?
If the window loses focus (e.g. by desktop switching), then all keys
are artificially released. If it regains focus, they are all artificially
pressed again. And that wasn't a convenience thing -- it solved another
stuck-keys problem (because while the window didn't have focus, modifiers
could be changed outside, and the OSG app wouldn't notice).



> if you press
> an 'a' key, then press shift to 'A', then release the 'A' then that is
> the sequence events.  What you haven't done is press 'a', release 'a',
> pressed 'A' then release 'A', which is what you are saying should
> happen be resented in events passed back from the OSG - this in itself
> could be considered a bug.

The problem starts where you drop information about what's *really*
going on (i.e. the physical key number), and replace it with keySym.
By dropping essential information, you take responsibility for the
sanity of what you pass. Keys that are undetectably, logically stuck
for the client are certainly not a feature. At least not one that
you'd want to mention in your ads.  ;-)   But I see your point ...



 
> I don't know what the solution should be yet, but I suspect it'll
> require some more information passed back via GUIEventAdapter, and
> make it easier to track unmodified key events.  Whatever solution we
> go for it'll have to work identically across all platforms.

Adding the physical key number to the key events sounds like a good
idea, but it's a two-edged sword: OSG "client" code that relies on
that can easily make questionable assumptions about the keyboard
hardware and thus stop working on other input devices. (But then again,
assuming that '3' is next to '4' isn't any better, and we don't have
problems with that.  :-)

But doing only that (without my patch) would require all clients
(that care about proper releases) to re-invent the fix. Adding the
fix to all platforms and adding a flag that says "this event is
artificial (was added by OSG), ignore it if you aren't into this
sort of stuff" might indeed be desirable.

m.



PS: in the patch I made a stupid untested last-minute change that
causes compiler warnings about signed/unsigned. Should have been:

for (unsigned int i = 0; i < sizeof(_lastKey) / sizeof(int); i++)

(But again, the patch was only a simplified version to show the
solution, and not meant to be applied.) 



PPS: this was badly worded:

  if (_lastKey[keycode] != -1) { // release key that isn't pressed? 
Shouldn't
 // happen, but just to be safe ...


the comment should have been:
 // if the key was actually reported pressed
 // before (which should really always be 
the
 // case, but better be safe)
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Textures disappear when re-loading a previously closed scene?

2009-06-04 Thread Herreman, Christophe

Hello,

 

When I close a scene and re-open it again without closing the
application, all the textures have disappeared and only white rectangles
are visible.

 

An warning is logged by OSG: "Warning: detected opengl error 'invalid
value' after RenderBin::draw(,)"

 

All resources are freed when a scene (document) is closed. 

 

Thinking that the registry was somehow keeping track of the texture, I
tried to clear the registry with calls such as 

osgDB::Registry::instance()->clearObjectCache(); and 

osgDB::Registry::instance()->clearGLObjects();

But this doesn't improve it.

 

BTW, I use the setUnRefImageDataAfterApply(true), to clear-up memory.

 

Any ideas what I can try ?

 

Thanks, Br

Christophe

 

OSG 2.8.1, Windows XP, nVidia quadro FX 2700  



DISCLAIMER:
Unless indicated otherwise, the information contained in this message is 
privileged and confidential, and is intended only for the use of the 
addressee(s) named above and others who have been specifically authorized to 
receive it. If you are not the intended recipient, you are hereby notified that 
any dissemination, distribution or copying of this message and/or attachments 
is strictly prohibited. The company accepts no liability for any damage caused 
by any virus transmitted by this email. Furthermore, the company does not 
warrant a proper and complete transmission of this information, nor does it 
accept liability for any delays. If you have received this message in error, 
please contact the sender and delete the message. Thank you.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Robert Osfield

Hi Melchoir,

Thanks for the extra explanations, this is really useful.

I'm in two minds if I'd would classify this issue as a bug, and I'm in
two minds about your suggested remedy.  The code is it stands right
now doesn't enforce a matching of presses and releases, it just the
way it works.  It's a bug if your assume that it does match.

Making them match does require inserting artificial events that the
the person at the keyboard has never instigated directly, if you press
an 'a' key, then press shift to 'A', then release the 'A' then that is
the sequence events.  What you haven't done is press 'a', release 'a',
pressed 'A' then release 'A', which is what you are saying should
happen be resented in events passed back from the OSG - this in itself
could be considered a bug.

I don't know what the solution should be yet, but I suspect it'll
require some more information passed back via GUIEventAdapter, and
make it easier to track unmodified key events.  Whatever solution we
go for it'll have to work identically across all platforms.

Robert.

On Thu, Jun 4, 2009 at 9:42 AM, Melchior FRANZ  wrote:
> Here's another illustration of what the patch does. The first part
> is what the added code in KeyPress does, the second part is what
> the code in KeyRelease does.
>
>
>
> press '3' (with autorepetition), press shift, release '3', release 'shift':
>
>  key: 51, shift: 0, pressed: 1
>  key: 51, shift: 0, pressed: 1
>  key: 51, shift: 0, pressed: 1
>  key: 51, shift: 1, pressed: 0     <<< this release event *added* by the
>  key: 35, shift: 1, pressed: 1         patch, otherwise 51=='3' would never
>  key: 35, shift: 1, pressed: 1         be released
>  key: 35, shift: 1, pressed: 1
>  key: 35, shift: 1, pressed: 0
>
>
>
>
> like above, but typing the sequence faster:
>
>  key: 51, shift: 0, pressed: 1
>  key: 51, shift: 1, pressed: 0     <<< this changed from 35 ('#') to 51 ('3')
>                                        by the patch, otherwise 51 would never
>                                        be released, but 35 (which wasn't even
>                                        reported pressed before)
>
> m.
> ___
> 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] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Melchior FRANZ

Here's another illustration of what the patch does. The first part
is what the added code in KeyPress does, the second part is what
the code in KeyRelease does. 



press '3' (with autorepetition), press shift, release '3', release 'shift':

  key: 51, shift: 0, pressed: 1
  key: 51, shift: 0, pressed: 1
  key: 51, shift: 0, pressed: 1
  key: 51, shift: 1, pressed: 0 <<< this release event *added* by the
  key: 35, shift: 1, pressed: 1 patch, otherwise 51=='3' would never
  key: 35, shift: 1, pressed: 1 be released
  key: 35, shift: 1, pressed: 1
  key: 35, shift: 1, pressed: 0




like above, but typing the sequence faster:

  key: 51, shift: 0, pressed: 1
  key: 51, shift: 1, pressed: 0 <<< this changed from 35 ('#') to 51 ('3')
by the patch, otherwise 51 would never
be released, but 35 (which wasn't even
reported pressed before)

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Melchior FRANZ

Hi,

> Added the unmapped/modified key to the GUIEventAdapter is something
> we've discussed in the past.

That would allow applications to work around that OSG *bug*. But IMHO
that's clearly a bug.



> The unmodifed would have to be assigned in addition to the existing
> modified key, as just dropping the mapping would break exisiting
> applications,

The patch would properly release keys, that would otherwise remain
in (logically) stuck position. I don't see how this could break an
application. One that assumed that OSG will not report all key releases
properly? Most applications probably don't care about key releases
at all, but those that do will probably work *better* if the releases
are reliable.  ;-)



> Reading your email I could pick out exactly what you were doing, but
> it sounded like you were duplicated events which doesn't does
> appropriate as again this would break applications.

No, I don't duplicate anything. I add what OSG occasionally fails to
do. I've sent another explanation just a few minutes ago.

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

Re: [osg-users] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Melchior FRANZ

Maybe I should have described the patch a little more, even though it's
rather short.


Initialization
--
Define an array _lastKey[] in which every physical key is mapped to a
keySym. All entries are initialized to -1, which means that the key
is not pressed. Array size is 256 on X11 (of which the first 8 entries
are unused).

On my US-keyboard key '3'/'#' key has hardware keycode 12. So, most
of the time  _lastKey[12] will be one of -1 (not pressed), '3', or '#'.



Key press event
---

  if (_lastKey[keycode] != -1)  // press event for an already 
pressed key?
// ... that means it's autorepeating

  if (_lastKey[keycode] != keySym)  // but the keySym suddenly changed, 
so a
// modifier must have changed 
(shift, ...)

  release(_lastKey[keycode]);   // then send an artificial release 
for the
// former keySym, before continuing 
with
// the new

  _lastKey[keycode] = keySym;   // store the new keySym for that key



Key release event
-

  if (_lastKey[keycode] != -1) {// release key that isn't pressed? 
Shouldn't
// happen, but just to be safe ...

  keySym = _lastKey[keycode];   // make sure to release the *right* 
keySym,
// the one for which the key press 
was reported

  _lastKey[keycode] = -1;   // and mark the physical key 
released
  }

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

Re: [osg-users] How to apply LISPSM shadows to a scene with differentshaders - Part 3

2009-06-04 Thread Wojciech Lewandowski


Miguel,

I am not sure whats the problem. Shadows on the ground look ok. So the 
matrices must be ok as well. All I can notice is improper self shadowing on 
soldier models. If this is the case then look at following thread:

http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26683.html

Cheers,
Wojtek


- Original Message - 
From: "Michael Guerrero" 

To: 
Sent: Wednesday, June 03, 2009 11:35 PM
Subject: [osg-users] How to apply LISPSM shadows to a scene with 
differentshaders - Part 3



Hi guys, I'm back to work on getting shadows in my scene only this time 
with
LISPSM.  For some history on integrating your own custom shaders with 
osgShadow

see the following threads:

http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/31360
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/33259/focus=33409

The technique used previously does not work correctly with LISPSM.  In my 
vert
shaders I use the eye planes to transform the view position into texture 
space

like so:

vec4 viewPosition = gl_ModelViewMatrix * gl_Vertex;

gl_TexCoord[3].s = dot(viewPosition, gl_EyePlaneS[1]);
gl_TexCoord[3].t = dot(viewPosition, gl_EyePlaneT[1]);
gl_TexCoord[3].p = dot(viewPosition, gl_EyePlaneR[1]);
gl_TexCoord[3].q = dot(viewPosition, gl_EyePlaneQ[1]);

Then I sample the shadow texture in the frag shader like this:

float shadow = shadow2DProj(osgShadow_shadowTexture, gl_TexCoord[3]).r;

Here's an image showing what I get as a result:
http://img269.imageshack.us/img269/5712/shadowerror.jpg

Has anyone gotten this to work?
Is there an extra step that I'm missing?

Thanks,
Michael Guerrero

___
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] transparency problem

2009-06-04 Thread Robert Osfield

Hi Su Hu,

On Thu, Jun 4, 2009 at 2:01 AM, su hu  wrote:
> There are lots of transparent objects/nodes in my scene.  I need to place
> them in the depth sorted bin. How can I find out these transparent nodes
> quickly?  Thanks a lot.

I'm afraid you don't provide enough context to your question so I
don't know how to answer.  When you do you need to track down all
transparent nodes?  In the whole scene graph, only those on screen?
For what purpose?

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

Re: [osg-users] master/slave camera question

2009-06-04 Thread Robert Osfield

HI Wyatt,

Have a look at the osgdistortion example as it doesn't exactly what
you are talking about.

Robert.

On Thu, Jun 4, 2009 at 12:36 AM, Wyatt Earp  wrote:
> I want to render my scene to a texture using an FBO, then I want to take
> that texture as input for another render pass, where I will do some magic in
> a shader, finally displaying the results on a quad occupying the entire
> fov.  How do I do this?  Does this involve slave cameras?
>
> In
> http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuide/ViewerVSCompositeViewer
> in the "Basic Explanation" section, it says that to do something like
> distortion correction you would have one View, then have multiple slave
> cameras along with the master.  Would my master render the scene to the
> texture, and a slave do the magic?
>
> Where can I find more on OSG master/slave?  I found the cluster example, but
> that isn't exactly what I am looking for.
>
>
> Wyatt
>
> "I ain't nobody's huckleberry"
>
>
> ___
> 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] [RFC] osgViewer: solution for omitted key release events

2009-06-04 Thread Robert Osfield

Hi Melchior,

Added the unmapped/modified key to the GUIEventAdapter is something
we've discussed in the past.  The unmodifed would have to be assigned
in addition to the existing modified key, as just dropping the mapping
would break exisiting applications, not doing the mapping would also
require 3rd party apps to add the mapping which in turn would require
knowledge of the windowing system that their apps would required.

Reading your email I could pick out exactly what you were doing, but
it sounded like you were duplicated events which doesn't does
appropriate as again this would break applications.

Robert.

On Wed, Jun 3, 2009 at 8:25 PM, Melchior FRANZ  wrote:
> At the moment there's no guarantee that for a key that triggered a key-press
> event before there will ever be the matching key-release event later. This
> is a problem for applications like FlightGear: here pressing the b-key, for
> example, applies the brakes on the landing gear until the key is reported
> released. If there's never a release, then the brakes remain stuck, until
> one pressed/released b again. But how could the release event possibly get
> lost? Consider this:
>
>  1.  b down       -> 'b' press event
>  2.  Shift down   -> shift modifier set
>  3.  b up         -> 'B' release event  (but 'B' was never reported pressed!)
>  4.  Shift up     -> shift modifier unset
>
>
> Well, letters aren't really a *big* problem. We hack around that by checking
> for an a-release if maybe 'A' or Ctrl-a was reported pressed before, or for
> an A-release if maybe 'a' or Ctrl-a ... etc.
>
>
> But what about this case:
>
>  1. \ down         -> '\' press event
>  2. Shift down
>  3. \ up           -> '|' release event --  '\' remains stuck!!
>  4. Shift up
>
> We can't hack around that, because it depends on the keyboard layout whether
> \ and | are on the same key. This information is lost for the OSG client and
> can't be retrieved in a cross-platform way. That's OSG's job.
>
>
> One way to fix that would be to store all reported symbols for press events 
> per
> physical key, and to make sure that the same symbol will be reported for the
> release, even if that means to inject an artificial release. This works here
> in my local build. (The attached patch is not meant to be applied -- I'd make
> some more cleanup before. All usage of _keyMap could then be removed, too.)
>
> Any comments on that? Windows and Mac maintainers would have to implement the
> same solution, which is the main reason for the RFC. Otherwise I would just
> have submitted the patch. And I can only remove the hack in FlightGear, once
> all platforms work correctly.
>
> (Should EventTime for the generated release event differ from the press event,
> e.g. by subtracting a very small time?)
>
> m.
>
> ___
> 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] memory leak in osg::StateSet::merge() ?

2009-06-04 Thread Robert Osfield

Hi John,

Since StateSet uses ref_ptr<> internally for all StateAttribute, and
merge doesn't create anything on the heap - it just copies then it's
pretty unlikely there is a memory leak.

Far more likely is that the tool you are using for tracking memory
leaks is faulty.  Could you please explain what makes you think you
have a memory leak?

Robert.

On Wed, Jun 3, 2009 at 7:44 PM, John Kelso  wrote:
> Hi,
>
> I have discovered that this line of code:
>
>    toNode->getOrCreateStateSet()->merge(*(fromNode->getOrCreateStateSet()))
> ;
>
> seems to cause a memory leak.  I busted it up:
>    osg::StateSet *fromNodeStateSet = fromNode->getOrCreateStateSet() ;
>    osg::StateSet *toNodeStateSet = toNode->getOrCreateStateSet() ;
>    toNodeStateSet->merge(*fromNodeStateSet) ;
>
> and it still leaks.  If I comment out the third line the leak goes away.  (I
> print the pointers, so hopefully the optimizer doesn't just toss all three
> lines.)
>
> Using either of these commands, although less than useful:
>    toNodeStateSet->merge(*toNodeStateSet) ;
>    fromNodeStateSet->merge(*fromNodeStateSet) ;
> doesn't cause the leak.
>
> Both nodes have StateSets, so this also works, and also leaks:
>    osg::StateSet *fromNodeStateSet = fromNode->getStateSet() ;
>    osg::StateSet *toNodeStateSet = toNode->getStateSet() ;
>    toNodeStateSet->merge(*fromNodeStateSet) ;
>
> I'm sort of stumped, and hoping the group might have some suggestions of
> what
> might be the source of the leak.
>
> I'm using OSG Version 2.6.1, Linux.
>
> Many thanks,
>
> John
>
> ___
> 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] Possible primitiveIndex inconsistency in osgUtil::LineSegmentIntersector

2009-06-04 Thread Peter Hrenka


Hi Andrew,

Andrew Cunningham schrieb:

I have noticed that the osgUtil::LineSegmentIntersector will record two 
possible primitiveIndex's for each QUAD.

For example, if you have a single QUAD you will get a primitiveIndex of 0 or 1 
depending on where you are picking ( i.e which triangle)


The LineSegmentIntersector uses the TriangleFunctor internally which (as 
the name suggests) produces triangles. This greatly simplifies the

code but messes up the primitiveIndex for Quads.


This is different from osgUtil::PolytopeIntersector which will only ever return 
a  primitiveIndex of 0 for this single  QUAD.


The PolytopeIntersector uses the TemplatePrimitiveFunctor which
counts differently, i.e. a Quad has only one primitiveIndex,
and it also counts lines and points.


Not a huge issue, but I don't think LineSegmentIntersector should be doing that.


I agree with you, but "fixing" this behaviour would probably break a lot
of code. In practice this not much of an issue as mixed-type drawables
are rare and for quad-only drawables you just have to divide by 2
to get the "right" primitiveIndex.


Andrew


Cheers,

Peter
--
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Roland Niemeier, 
Dr. Arno Steitz, Dr. Ingrid Zech

Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Michel Lepert
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196 



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

71 matches

Mail list logo