Re: [osg-users] Exception invalid lock sequence thrown from OSG App

2008-11-11 Thread Robert Osfield
Hi Brian,

I haven't heard of reports of problems of this description before. Do
the OSG examples fail?

What hardware and drivers are you using?  It is most likely a driver
bug, so try different hardware/drivers.

Robert.

On Mon, Nov 10, 2008 at 10:26 PM, Brian Stewart
[EMAIL PROTECTED] wrote:
 I have an application that is built against OpenSceneGraph (2.6.1). The
 application initializes and begins to run, but then I get the following
 exception attempt was made to execute an invalid lock sequence in
 OpenGL32.dll. When I re-run it, I sometimes get this exception, and
 sometimes an exception about a privileged instruction. The call stack
 looks like it is corrupted, so I can't really tell exactly where the
 exception is being thrown from. I ran the app quite a bit a couple of days
 ago and never saw this behavior. Since then I have added an else clause to a
 couple of ifs, and that is all. My app is a console application, is built
 with Visual Studio 2008, and it sets OpenScenGraph to SingleThreaded mode.
 Anybody seen this before? Any debugging tips?

 Thanks
 Brian Stewart
 ___
 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] Controlling swap (Not the question about View vs. Composite View)

2008-11-11 Thread Ed

Are there examples for doing these techniques?
Ed

Robert Osfield wrote:

You can add your own sync code
if you want into camera initial/pre,post and final callbacks, and no
matter what threading model these will be called.  



You can also add
Rendering operations into the GraphicsContext's operations list, or
override the osgViewer::Renderer which does the actual cull and draw
traversals.

Robert.
  

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


Re: [osg-users] Controlling swap (Not the question about View vs. Composite View)

2008-11-11 Thread Robert Osfield
On Tue, Nov 11, 2008 at 2:42 PM, Ed [EMAIL PROTECTED] wrote:
 Are there examples for doing these techniques?

Search tools are your friend, the sooner you get used to use them on
the OSG the sooner I can get on with useful stuff.  Just search for
setPostDraw or setFinalDraw in the OpenSceneGraph distribution it'll
come up with all the examples.

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


[osg-users] example osg + bullet + collada

2008-11-11 Thread Adonai S . Canêz
Hi,

I'm need example with osg, bullet physics and file collada, someone have some 
example?

Thanks
Adonai


  Novos endereços, o Yahoo! que você conhece. Crie um email novo com a sua 
cara @ymail.com ou @rocketmail.com.
http://br.new.mail.yahoo.com/addresses___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-11 Thread Jean-Sébastien Guay

Hi Robert,


This very much looks like a driver bug so we'll need to contact NVidia
and get them on to.  Anyone with a hotline to NVidia?


The driver devs I met at Siggraph said that sending to

[EMAIL PROTECTED]

was our best bet when we found bugs in their OpenGL implementations. 
They also added that including a simple example (OpenGL only of course) 
that reproduces the bug helps a lot (of course).


Wojtek also had some contact with NVidia devs for the double-makecurrent 
bug, and apparently got some response from them, so perhaps he can advise.


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] PagedLOD traversal problem after switch to 2.6.1

2008-11-11 Thread Linus Hilding
We have a scene graph in which we want to make changes to every node's state 
set (switching textures). The scene graph consists of several nested PagedLOD 
objects(quad structure). After updating to OSG 2.6.1 from 2.2.0, not every LOD 
level gets visited by our NodeVisitor, when applied to the tree. Does anyone 
have any idea of what might be the problem?

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


[osg-users] RTT - texture is not what I expected

2008-11-11 Thread Engvall Åsa
Recently, I tried to render the scene to a texture, and after some help I got 
something in the texture. 
Now, I've found that the texture doesn't show the scene but the previous frame. 
With shading and everything. How is that possible?

My scene graph looks like this:

root
/   \
RTTcamera worldParent
\  /
world

The shader is applied to the worldParent and the RTTcamera is pre render. 
I want the RTT camera to see the world as it is, with no shading, and render 
the scene to a texture. This texture should then be used in the shader.

What am I doing wrong this time??? I would be thankful for any help.

Regards,
Åsa Engvall

-Code---

int main()
{
// Create group nodes.
osg::Group* root = new osg::Group;
osg::Group* worldParent = new osg::Group;
osg::Group* world = new osg::Group;
root-addChild(worldParent);
worldParent-addChild(world);

// Create a sphere object.
osg::Sphere* sphere = new osg::Sphere(osg::Vec3(0, 0, 0), 10);  
osg::ShapeDrawable* sphereDrawable = new osg::ShapeDrawable(sphere);
sphereDrawable-setColor(osg::Vec4(0, 0, 0, 1));

osg::Geode* object = new osg::Geode();
object-addDrawable(sphereDrawable);

// Declare transform nodes for dynamic objects.
osg::PositionAttitudeTransform* objectTransform = new 
osg::PositionAttitudeTransform;
objectTransform-addChild(object);  
world-addChild(objectTransform);

// Create a viewer that looks at the world.
osgViewer::Viewer viewer;
viewer.setThreadingModel(osgViewer::Viewer::SingleThreaded);
viewer.setSceneData(root);

// Create a graphics window.
osg::ref_ptrosg::GraphicsContext::Traits traits = new 
osg::GraphicsContext::Traits;
traits-x = 100;
traits-y = 100;
traits-width = 640;
traits-height = 480;
traits-windowDecoration = true;
traits-doubleBuffer = true;
traits-sharedContext = 0;

// Attach a camera to the graphics window.
osg::ref_ptrosg::GraphicsContext gc = 
osg::GraphicsContext::createGraphicsContext(traits.get());
osg::ref_ptrosg::Camera camera = viewer.getCamera();
camera-setGraphicsContext(gc.get());
camera-setViewport(new osg::Viewport(0, 0, traits-width, 
traits-height));
GLenum buffer = traits-doubleBuffer ? GL_BACK : GL_FRONT;
camera-setDrawBuffer(buffer);
camera-setReadBuffer(buffer);
camera-setClearColor(osg::Vec4(1,1,1,1));

// Camera callback for capturing the image. 
osg::Image* image = new osg::Image; 
camera-setPostDrawCallback(new ScreenShotCallback(traits-width, 
traits-height, *image, GL_RGBA, GL_UNSIGNED_BYTE));

  // Create shader objects.
osg::Shader* motionBlurVertexShader = new 
osg::Shader(osg::Shader::VERTEX);
osg::Shader* motionBlurFragmentShader = new 
osg::Shader(osg::Shader::FRAGMENT);
motionBlurVertexShader-loadShaderSourceFromFile
(H:/My Documents/Visual Studio 
2008/Projects/osg_sfunction/osg_sfunction/motionblur.vert);
motionBlurFragmentShader-loadShaderSourceFromFile
(H:/My Documents/Visual Studio 
2008/Projects/osg_sfunction/osg_sfunction/motionblur.frag);

// Add shader objects to a program.
osg::Program* motionBlurProgram = new osg::Program;
motionBlurProgram-addShader(motionBlurVertexShader);
motionBlurProgram-addShader(motionBlurFragmentShader);

// Define uniforms that will be passed to the shader.
osg::Uniform* numberOfTimeStepsU = new 
osg::Uniform(numberOfTimeSteps, int(10));
osg::Uniform* timeConstantU = new osg::Uniform(timeConstant, 
float(0.01));
osg::Uniform* frameTimeU = new osg::Uniform(frameTime, float(0.02));
osg::Uniform* sceneTextureU = new osg::Uniform(sceneTexture, 0);
osg::Uniform* prevModelViewMatrixU = new 
osg::Uniform(osg::Uniform::FLOAT_MAT4, prevModelViewMatrix);
osg::Uniform* prevModelViewProjectionMatrixU = new 
osg::Uniform(osg::Uniform::FLOAT_MAT4, prevModelViewProjectionMatrix);

// Create a scene texture.
osg::Texture2D* texture = new osg::Texture2D;
texture-setResizeNonPowerOfTwoHint(false);
texture-setTextureSize(traits-width, traits-height);
texture-setInternalFormat(GL_RGBA);
texture-setFilter(osg::Texture2D::MIN_FILTER, osg::Texture2D::NEAREST);
texture-setFilter(osg::Texture2D::MAG_FILTER, osg::Texture2D::NEAREST);
osg::Image* textureImage = new osg::Image;
  textureImage-allocateImage(traits-width, traits-height, 1, GL_RGBA, 

Re: [osg-users] Some small osgPPU modifications

2008-11-11 Thread Jean-Sébastien Guay

Hi Art,


thank you for the patch. Currently I have submitted only the CMake part, 
because the SSAO example is in progress.


OK, that's what I figured. Thanks for applying.


As to the installation path for the examples, you are probably right. We need 
something kind of same mechanism as for the osg examples. I will try to make 
some nice solution soon for it.


It's pretty easy, just add something like this to each example's 
CMakeLists.txt :


INSTALL(TARGETS ${TARGET_TARGETNAME}
DESTINATION ${CMAKE_INSTALL_PREFIX}/share/osgPPU/bin)

(or use a variable for the example installation path)

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Some small osgPPU modifications

2008-11-11 Thread Art Tevs
Hi Jean,

thank you for the patch. Currently I have submitted only the CMake part, 
because the SSAO example is in progress. Unfortunately I do not have enough 
time to work on it now, therefor I just deactivated it, so that it doesn't get 
compiled for now. I hope I will get free time for it soon, to acomplish it.

As to the installation path for the examples, you are probably right. We need 
something kind of same mechanism as for the osg examples. I will try to make 
some nice solution soon for it.

Thank you again.

Best regards,
art




--- Jean-Sébastien Guay [EMAIL PROTECTED] schrieb am Di, 11.11.2008:

 Von: Jean-Sébastien Guay [EMAIL PROTECTED]
 Betreff: [osg-users] Some small osgPPU modifications
 An: OpenSceneGraph Users osg-users@lists.openscenegraph.org
 Datum: Dienstag, 11. November 2008, 16:10
 Hi Art,
 
 Updating the osgPPU SVN and compiling today, I found I
 needed some small changes:
 
 1. In the new SSAO example, the setupCamera function does
 not return a value but has osg::Camera* return type. It
 should be void, since it operates on the camera passed as
 argument and the main() does not store its return value (if
 there was one) anyways.
 
 Side note: I'm pretty apalled that gcc lets this kind
 of error pass... It's pretty basic IMHO. What would
 happen if you had taken the return value? Would it be
 uninitialized, or would gcc flag the error then?
 
 2. On Windows, we need to have the 'd' suffix on
 the plugin DLL too, and the code in
 CMakeModules/OsgPPUMacroUtils.cmake (SETUP_PLUGIN) just
 removed the suffix in the NOT MSVC case, but never added it
 in the else... so I added that.
 
 3. The ssao_fp.glsl shader had some errors. I'm still
 not sure it gives the right result (looks like just a
 visualization of the depth buffer to me - perhaps it's
 not complete yet?), but at least it compiles.
 
 It would be nice to install the examples to some directory
 for out-of-source builds, for example
 $CMAKE_INSTALL_PREFIX/share/osgPPU/bin like OSG does. But I
 didn't do that yet, if you want I can do it.
 
 I've tested the examples I could (i.e. all except
 texture3D and video) and they seem to work (except as noted
 above for the SSAO example).
 
 Changes attached.
 
 J-S
 -- __
 Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


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


Re: [osg-users] osgCairo and osgPango on Windows : some progress

2008-11-11 Thread Jean-Sébastien Guay

Hi Jeremy,

I just noticed something: osgpangoanimation is the only example in 
osgCairo and osgPango that sets a fixed window size/position. Why is that?



As far as getting the OSG viewer
resolution is concerned, I'm probably more prone to just fixing the bug
outright rather than working around it. To be honest, I don't really
even know of any way to get this data--it's abstracted somewhere deep in
OSG. If you know of an example bit of code that does it, please let me
know.


The width and height are in the traits for a graphics context. To get 
them, the viewer needs to be realized. You can call viewer.realize() 
early, and do the scene setup afterwards, I don't see a problem with that.


You will of course need some special cases if there are two graphics 
contexts (for example, one view spanning across two or more video cards) 
but that should be pretty easy, as 
osgViewer::View::setUpViewAcrossAllScreens() just assumes a horizontal 
span layout. In all other cases, it will be a single context and the 
width and height will be in the traits.


Check out those methods (osgViewer::View::setUpViewAcrossAllScreens(), 
setUpViewInWindow() and setUpViewOnSingleScreen()) - it's pretty easy to 
figure out what's going on. And see osgViewer::Viewer::realize() to see 
how it chooses which one to call.


Thanks,

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] Introducing osgmemorytest

2008-11-11 Thread Robert Osfield
Hi All,

Today I've been coding up a new example that is written with the
intent of testing out the capabilities of our hardware/drivers/OS's to
allocate lots of windows/pbuffers on the window manage side, and lots
of FBO's, texture and geometries on the OpenGL object side.   The new
example is called osgmemorytest and is now checked into svn/trunk.

This new example has a couple of specific uses - first up it's
educational - we can quickly test just how many objects we can throw
at our systems and expect them to run, secondly its a diagnostic tool
- so when things go wrong we can use it too recreate the problems we
see in our own apps but with a small focused code set, finally it's a
way of comparing capabilities across platforms/drivers - which in turn
might lead back to diagnostics on problem platforms.

In the thread about RTT/FBO memory problems under Linux I discuss a
few of the tests I've done with this new example.  These all related
to stress testing FBO's allocations.  There are other areas that are
worthy of stress testing too and I would love to get feedback from
other platforms just to get a feel about what different platforms are
capable of.   Here's a couple of tests that I'd appreciate it if users
could run and report back results (along with platform/hardware info).
 Be warned that push things too far and you can start stalling the
machine or even crashing it in extreme cases where the OpenGL driver
is misbehaving.

1) How many windows can I open?  Try to open 1000 windows:

   osgmemorytest --window -c 1000

2) How many pbuffers can I open? Try to open 1000 pbuffers:

   osgmemorytest --pbuffer -c 1000

3) How many texture objects can I open? Try to open 1 256x256 RGB textures:

 osgmemorytest --texture 256 256 -g 1

4) How many display listed based geometry objects can I open? Try to
open 1 32x32 geometry tile:

 osgmemorytest --geometry 32 32 -g 1

5) How many vertex buffer object based geometry objects can I open?
Try to open 1 32x32 geometry tile:

 osgmemorytest --geometry-vbo 32 32 -g 1

6) How many vertex array geometry objects can I open? Try to open
1 32x32 geometry tile:

 osgmemorytest --geometry-va 32 32 -g 1

7) How many display listed geometry objects can I open? Try to open
1000 256x256 fbo's

 osgmemorytest --fbo 256 256 -g 1000

8) How many display listed geometry objects can I open? Try to open
1000 1024x1024 fbo's

 osgmemorytest --fbo 1024 1024 -g 1000

9) How many display listed geometry objects can I open? Try to open
1000 2048x2048  fbo's

 osgmemorytest --fbo 2048 2048 -g 1000

--

To get things kicked off here's my results:

Machine: Kubuntu 7.10, Intel Quad core, 4GB, Gefore 640Mb 8800GTS
From glxinfo: OpenGL version string: 2.1.1 NVIDIA 100.14.19

1) window test: get 108 windows opened before failure.
2) pbuffer test:  215 pbuffers opened before failure.
3) texture test: alll 10,000 texture allocated and download to OpenGL
in 6.9 seconds
4) geometry test: all 10,000 geometries allocated and download to
OpenGL in 4.3 seconds
5) geometry test: all 10,000 geometries allocated and download to
OpenGL in 1.0 seconds
6) geometry test: all 10,000 geometries allocated and download to
OpenGL in 0.7 seconds
7) fbo test: 145 fbo's created before failure.
8) fbo test: 157 fbo's created before failure.
9) fbo test: 166 fbo's created before failure.

Note 7 to 9 results are the exact opposite of what we would expect,
clearly there is a very silly bug in the OpenGL driver.

I look forward to what results others get.  I will later push up the
geometry and texture tests to see how far they can go...

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


Re: [osg-users] FLT Writer Duplicate Node Names?

2008-11-11 Thread Argentieri, John-P63223
Guys,
 
Has anyone used the ProxyNode in this way, in OpenFlight files? My
primary file and my externally referenced file are both OpenFlight
files. The externally referenced file gets loaded, but the texture is
incorrect. The texture applied to the model, in my case, is the only one
that is used internally in the primary OpenFlight file. For example, my
terrain surface is internal and textured as grass. My externally
reference tree models are shaped like trees, but also textured in grass.
I've tried moving the tree's texture files around to be sure that it
wasn't a path issue. It didn't work.
 
Is there anyone that can help me to resolve the issues I am having? All
I want to do is write an OpenFlight file that contains several clones of
another OpenFlight file. The straightforward approach breaks -- not for
the current OSG loader, but for other loaders that expect node names to
be unique.
 
Your friend,
John Argentieri
 


From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: Friday, November 07, 2008 1:51 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] FLT Writer Duplicate Node Names?


The exporter writes an external reference record when it encounters a
ProxyNode. The importer should do the inverse operation.
 
I searched for the error text you mentioned, but could not find any code
in OSG that displays that error, so I can't really help you with that.
   -Paul
 




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Argentieri, John-P63223
Sent: Friday, November 07, 2008 11:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [osg-users] FLT Writer Duplicate Node Names?


Paul,
 
Is there a way that I can place multiple instances of an
external .flt file into another .flt file? I'm trying to use ProxyNode,
but still getting these errors:
 
Non primary record found as child. op=19
Non primary record found as child. op=19
Non primary record found as child. op=20
Non primary record found as child. op=20
 
Thanks,
John
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul
Martz
Sent: Friday, November 07, 2008 12:51 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] FLT Writer Duplicate Node Names?


The exporter dumps the Node name to the FLT record name, just as
the importer does the inverse operation. I don't believe there is any
code to check for and avoid duplicate node names.
 
I'd think it would be up to the application to specify unique
Node names, as the exporter has no other way to know what text should be
written to the FLT record name. I can see how it might be useful to have
a I don't care what you name it, just make sure it's unique mode.
Currently, this doesn't exist. You are welcome to add it.
   -Paul
 




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Argentieri, John-P63223
Sent: Friday, November 07, 2008 8:41 AM
To: [EMAIL PROTECTED]
Subject: [osg-users] FLT Writer Duplicate Node Names?


Hello all.
 
Does the FLT writer create duplicate node names for
nodes with multiple transforms as parents? We're having trouble sharing
a single model inside of multiple transforms scattered about. Some older
OpenFlight software we are interfacing to does not like this. Any
thoughts guys?
 
Thank you,
John Argentieri 
Software Engineer 
GENERAL DYNAMICS 
C4 Systems 
[EMAIL PROTECTED] 

This email message is for the sole use of the intended
recipient(s) and may contain GDC4S confidential or privileged
information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not an intended recipient, please contact the
sender by reply email and destroy all copies of the original message.

 

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


Re: [osg-users] Introducing osgmemorytest

2008-11-11 Thread Jeremy Moles
On Tue, 2008-11-11 at 17:55 +, Robert Osfield wrote:
 Hi All,
 
 Today I've been coding up a new example that is written with the
 intent of testing out the capabilities of our hardware/drivers/OS's to
 allocate lots of windows/pbuffers on the window manage side, and lots
 of FBO's, texture and geometries on the OpenGL object side.   The new
 example is called osgmemorytest and is now checked into svn/trunk.
 
 This new example has a couple of specific uses - first up it's
 educational - we can quickly test just how many objects we can throw
 at our systems and expect them to run, secondly its a diagnostic tool
 - so when things go wrong we can use it too recreate the problems we
 see in our own apps but with a small focused code set, finally it's a
 way of comparing capabilities across platforms/drivers - which in turn
 might lead back to diagnostics on problem platforms.
 
 In the thread about RTT/FBO memory problems under Linux I discuss a
 few of the tests I've done with this new example.  These all related
 to stress testing FBO's allocations.  There are other areas that are
 worthy of stress testing too and I would love to get feedback from
 other platforms just to get a feel about what different platforms are
 capable of.   Here's a couple of tests that I'd appreciate it if users
 could run and report back results (along with platform/hardware info).
  Be warned that push things too far and you can start stalling the
 machine or even crashing it in extreme cases where the OpenGL driver
 is misbehaving.
 
 1) How many windows can I open?  Try to open 1000 windows:
 
osgmemorytest --window -c 1000
 
 2) How many pbuffers can I open? Try to open 1000 pbuffers:
 
osgmemorytest --pbuffer -c 1000
 
 3) How many texture objects can I open? Try to open 1 256x256 RGB 
 textures:
 
  osgmemorytest --texture 256 256 -g 1
 
 4) How many display listed based geometry objects can I open? Try to
 open 1 32x32 geometry tile:
 
  osgmemorytest --geometry 32 32 -g 1
 
 5) How many vertex buffer object based geometry objects can I open?
 Try to open 1 32x32 geometry tile:
 
  osgmemorytest --geometry-vbo 32 32 -g 1
 
 6) How many vertex array geometry objects can I open? Try to open
 1 32x32 geometry tile:
 
  osgmemorytest --geometry-va 32 32 -g 1
 
 7) How many display listed geometry objects can I open? Try to open
 1000 256x256 fbo's
 
  osgmemorytest --fbo 256 256 -g 1000
 
 8) How many display listed geometry objects can I open? Try to open
 1000 1024x1024 fbo's
 
  osgmemorytest --fbo 1024 1024 -g 1000
 
 9) How many display listed geometry objects can I open? Try to open
 1000 2048x2048  fbo's
 
  osgmemorytest --fbo 2048 2048 -g 1000

I probably won't be the only one to say it but...

This is wicked awesome. :) We may even put the results of something like
this up on our website for the various machines we sell (since we sell a
great deal of high-end machines to government, etc. that do simulations
or something similar--they can't tell us or they have to kill us, you
know.)

 --
 
 To get things kicked off here's my results:
 
 Machine: Kubuntu 7.10, Intel Quad core, 4GB, Gefore 640Mb 8800GTS
 From glxinfo: OpenGL version string: 2.1.1 NVIDIA 100.14.19
 
 1) window test: get 108 windows opened before failure.
 2) pbuffer test:  215 pbuffers opened before failure.
 3) texture test: alll 10,000 texture allocated and download to OpenGL
 in 6.9 seconds
 4) geometry test: all 10,000 geometries allocated and download to
 OpenGL in 4.3 seconds
 5) geometry test: all 10,000 geometries allocated and download to
 OpenGL in 1.0 seconds
 6) geometry test: all 10,000 geometries allocated and download to
 OpenGL in 0.7 seconds
 7) fbo test: 145 fbo's created before failure.
 8) fbo test: 157 fbo's created before failure.
 9) fbo test: 166 fbo's created before failure.
 
 Note 7 to 9 results are the exact opposite of what we would expect,
 clearly there is a very silly bug in the OpenGL driver.
 
 I look forward to what results others get.  I will later push up the
 geometry and texture tests to see how far they can go...
 
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 

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


Re: [osg-users] Introducing osgmemorytest

2008-11-11 Thread Jean-Sébastien Guay

Hi Robert,


Here's a couple of tests that I'd appreciate it if users
could run and report back results (along with platform/hardware info).


I think there's something wonky on the Windows side for your example, 
because here are the results I get:

___

osgmemorytest --window -c 1000
iteration 0
Exception caught, contexts completed = 0, gl objects successfully 
applied =0, error = Failed to create GraphicsWindow


osgmemorytest --pbuffer -c 1000
iteration 0
Exception caught, contexts completed = 0, gl objects successfully 
applied =0, error = Failed to create PixelBuffer


osgmemorytest --texture 256 256 -g 1
Exception caught, contexts completed = 0, gl objects successfully applied =0

osgmemorytest --geometry 32 32 -g 1
iteration 0
Successful completion, contexts created = 1, gl objects applied =0

osgmemorytest --geometry-vbo 32 32 -g 1
iteration 0
Successful completion, contexts created = 1, gl objects applied =0

osgmemorytest --geometry-va 32 32 -g 1
iteration 0
Successful completion, contexts created = 1, gl objects applied =0

osgmemorytest --fbo 256 256 -g 1000
iteration 0
Successful completion, contexts created = 1, gl objects applied =0

osgmemorytest --fbo 1024 1024 -g 1000
iteration 0
Successful completion, contexts created = 1, gl objects applied =0

osgmemorytest --fbo 2048 2048 -g 1000
iteration 0
Successful completion, contexts created = 1, gl objects applied =0
___

Those first three are weird, seems it can't create a GraphicsWindowWin32 
and PixelBufferWin32, and the third without an error... I've seen 
problems creating GraphicsWindowWin32 objects programmatically before, 
the window classes are not registered so you need to create one window 
at startup with default traits using 
GraphicsContext::createGraphicsContext(traits) and then doing new 
GraphicsWindowWin32 will work. Perhaps this is the problem here.


Then the others are also weird, they all report success but gl objects 
applied =0...


I don't have time to debug at this moment, I'll see if I can check into 
it in the next few days. It's an interesting example to be sure, but 
only if we can get it to behave consistently across platforms.


J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
   http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


[osg-users] reusing VBOs

2008-11-11 Thread Ed
I am working on porting my raw/native/whatever-you-want-to-call-it 
OpenGL application to OSG.  In my application, if I load multiple 
objects of the same type, I reuse the VBO created for the original 
object.  Is this something I can do in OSG?


Ed

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


Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-11 Thread Wojciech Lewandowski
Hi, I wish I had some friends at NVidia. But unfortunately they not seem to
treat me specially. I went through standard Bug report form on developer
NVidia website. At least last time they let me know they repeated the bug
and did something about it. 2 former cases when I sent reports were ignored.
But former cases were not accompanied by the source code. So if I was to
suggest something it would be creation of OpenGL repro and uploading this
example along on the bug report form. I believe last time I added
OpenSceneGraph to the list of projects requiring fixes. So you may add this
bug under this project.

Cheers,
Wojtek

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Jean-Sebastien Guay
Sent: Tuesday, November 11, 2008 3:41 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Many RTT cameras, strange out of memory errors on
Linux


Hi Robert,

 This very much looks like a driver bug so we'll need to contact NVidia
 and get them on to.  Anyone with a hotline to NVidia?

The driver devs I met at Siggraph said that sending to

[EMAIL PROTECTED]

was our best bet when we found bugs in their OpenGL implementations.
They also added that including a simple example (OpenGL only of course)
that reproduces the bug helps a lot (of course).

Wojtek also had some contact with NVidia devs for the double-makecurrent
bug, and apparently got some response from them, so perhaps he can advise.

J-S
--
__
Jean-Sebastien Guay[EMAIL PROTECTED]
http://www.cm-labs.com/
 http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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


Re: [osg-users] PagedLOD traversal problem after switch to 2.6.1

2008-11-11 Thread Linus Hilding
Sorry for the shorthanded info. Since we changed nothing other than osg 
version, we where curious to know if we made som known mistake. A switch back 
to version 2.2.0 will make it work again. When we draw the scene, the draw 
traversal has no trouble finding the different PagedLOD children, but prior to 
that a scene-traverse(visitor) on the root with a visitor derived from 
NodeVisitor with _TraversalMode set to osg::NodeVisitor::TRAVERSE_ALL_CHILDREN, 
and apply() functions that continue the traversal, will not reach all the 
children that keeps the different LOD levels. But we will continue debugging 
and get back if we have a more specific question of relevance.

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


Re: [osg-users] reusing VBOs

2008-11-11 Thread Robert Osfield
Hi Ed,

You can share whole subgraphs as well as individual components.  I'd
recommend sharing StateSet/StateAttributes as much as possible to help
out with start sorting and lazy state updating.  Sharing Geometry is
next most important, then if you can share Geometry you could share
vertex arrays or the VBO's attached to them.

Robert.

On Tue, Nov 11, 2008 at 6:50 PM, Ed [EMAIL PROTECTED] wrote:
 I am working on porting my raw/native/whatever-you-want-to-call-it OpenGL
 application to OSG.  In my application, if I load multiple objects of the
 same type, I reuse the VBO created for the original object.  Is this
 something I can do in OSG?

 Ed

 ___
 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] Introducing osgmemorytest

2008-11-11 Thread Robert Osfield
Hi J-S,

 Those first three are weird, seems it can't create a GraphicsWindowWin32 and
 PixelBufferWin32, and the third without an error... I've seen problems
 creating GraphicsWindowWin32 objects programmatically before, the window
 classes are not registered so you need to create one window at startup with
 default traits using GraphicsContext::createGraphicsContext(traits) and then
 doing new GraphicsWindowWin32 will work. Perhaps this is the problem here.

 Then the others are also weird, they all report success but gl objects
 applied =0...

All the runs suffer from exactly the same problem - for some reason the

static RegisterWindowingSystemInterfaceProxy
createWindowingSystemInterfaceProxy;

In src/osgViewer/GraphicsWindowWin32.cpp is not constructing and
registering the Win32WindowingSystem as it should.  This problem does
seem vaguely familiar, problems in pbufffe/window construction in
osgconv and osgdem being things that ring a bell.

As a real hack you try manually registering the Win32WindingSystem
object via the C function call (this is there to help out with apps
doing static linking):

extern C void graphicswindow_Win32(void);

main(..)
{
...
   graphicswindow_Win32(void);

}

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


Re: [osg-users] Introducing osgmemorytest

2008-11-11 Thread Jeremy Moles
On Tue, 2008-11-11 at 17:55 +, Robert Osfield wrote:
 Hi All,
 
 Today I've been coding up a new example that is written with the
 intent of testing out the capabilities of our hardware/drivers/OS's to
 allocate lots of windows/pbuffers on the window manage side, and lots
 of FBO's, texture and geometries on the OpenGL object side.   The new
 example is called osgmemorytest and is now checked into svn/trunk.
 
 This new example has a couple of specific uses - first up it's
 educational - we can quickly test just how many objects we can throw
 at our systems and expect them to run, secondly its a diagnostic tool
 - so when things go wrong we can use it too recreate the problems we
 see in our own apps but with a small focused code set, finally it's a
 way of comparing capabilities across platforms/drivers - which in turn
 might lead back to diagnostics on problem platforms.
 
 In the thread about RTT/FBO memory problems under Linux I discuss a
 few of the tests I've done with this new example.  These all related
 to stress testing FBO's allocations.  There are other areas that are
 worthy of stress testing too and I would love to get feedback from
 other platforms just to get a feel about what different platforms are
 capable of.   Here's a couple of tests that I'd appreciate it if users
 could run and report back results (along with platform/hardware info).
  Be warned that push things too far and you can start stalling the
 machine or even crashing it in extreme cases where the OpenGL driver
 is misbehaving.
 
 1) How many windows can I open?  Try to open 1000 windows:
 
osgmemorytest --window -c 1000
 
 2) How many pbuffers can I open? Try to open 1000 pbuffers:
 
osgmemorytest --pbuffer -c 1000
 
 3) How many texture objects can I open? Try to open 1 256x256 RGB 
 textures:
 
  osgmemorytest --texture 256 256 -g 1
 
 4) How many display listed based geometry objects can I open? Try to
 open 1 32x32 geometry tile:
 
  osgmemorytest --geometry 32 32 -g 1
 
 5) How many vertex buffer object based geometry objects can I open?
 Try to open 1 32x32 geometry tile:
 
  osgmemorytest --geometry-vbo 32 32 -g 1
 
 6) How many vertex array geometry objects can I open? Try to open
 1 32x32 geometry tile:
 
  osgmemorytest --geometry-va 32 32 -g 1
 
 7) How many display listed geometry objects can I open? Try to open
 1000 256x256 fbo's
 
  osgmemorytest --fbo 256 256 -g 1000
 
 8) How many display listed geometry objects can I open? Try to open
 1000 1024x1024 fbo's
 
  osgmemorytest --fbo 1024 1024 -g 1000
 
 9) How many display listed geometry objects can I open? Try to open
 1000 2048x2048  fbo's
 
  osgmemorytest --fbo 2048 2048 -g 1000
 
 --
 
 To get things kicked off here's my results:
 
 Machine: Kubuntu 7.10, Intel Quad core, 4GB, Gefore 640Mb 8800GTS
 From glxinfo: OpenGL version string: 2.1.1 NVIDIA 100.14.19
 
 1) window test: get 108 windows opened before failure.
 2) pbuffer test:  215 pbuffers opened before failure.
 3) texture test: alll 10,000 texture allocated and download to OpenGL
 in 6.9 seconds
 4) geometry test: all 10,000 geometries allocated and download to
 OpenGL in 4.3 seconds
 5) geometry test: all 10,000 geometries allocated and download to
 OpenGL in 1.0 seconds
 6) geometry test: all 10,000 geometries allocated and download to
 OpenGL in 0.7 seconds
 7) fbo test: 145 fbo's created before failure.
 8) fbo test: 157 fbo's created before failure.
 9) fbo test: 166 fbo's created before failure.

1) window test: get 94 windows opened before failure.
2) pbuffer test:  188 pbuffers opened before failure.

I got these two first tests done and then test 3 reported 1500 textures and
crashed. Now I can't run it or any other GL app, I'll probably need to reboot.
INTERESTING. :)

 Note 7 to 9 results are the exact opposite of what we would expect,
 clearly there is a very silly bug in the OpenGL driver.
 
 I look forward to what results others get.  I will later push up the
 geometry and texture tests to see how far they can go...
 
 Robert.
 ___
 osg-users mailing list
 osg-users@lists.openscenegraph.org
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 

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


Re: [osg-users] PagedLOD traversal problem after switch to 2.6.1

2008-11-11 Thread Robert Osfield
Hi Linus,

We have approximately 0 chance of guess what might be wrong. We
knowing absolutely nothing about your visitor, we know absolutely
knowing about when and where you call your visitor, we know
practically nothing about the scene graph.

Might I suggest you use a debugger to step through to see what is
happening in your application, with your code, with your data.

Robert.

On Tue, Nov 11, 2008 at 3:44 PM, Linus Hilding [EMAIL PROTECTED] wrote:
 We have a scene graph in which we want to make changes to every node's state 
 set (switching textures). The scene graph consists of several nested PagedLOD 
 objects(quad structure). After updating to OSG 2.6.1 from 2.2.0, not every 
 LOD level gets visited by our NodeVisitor, when applied to the tree. Does 
 anyone have any idea of what might be the problem?

 Regards Ragnar and Linus
 ___
 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] compositeViewer newbie question

2008-11-11 Thread Dan Small
Thanks Robert,

We used the second approach you mentioned, threw all the views in one
window,   not surprisingly the memory utilization went way down.
Thanks for correcting our GL naivete.

It seems tho that the 2nd approach also limits us to single-threaded only;
would you concur?  We have an 8-core Dell we are running this on, and it
would be nice to avail ourselves of the multithreading features if we can.

btw, I wasn't my intent to imply there was a bug in the OSG, only in that
way that we were using it :)

cheers,

Dan


On Tue, Nov 11, 2008 at 9:27 AM, Robert Osfield [EMAIL PROTECTED]wrote:

 Hi Dan,

 Creating 9 separate windows without any of them sharing OpenGL objects
 will cause the OSG to create 9 sets of OpenGL objects per object in
 the scene graph.  This is just a fact of life if you use the OSG they
 way you are doing, it isn't a bug.

 Thankfully OpenGL/OSG provide the ability to share OpenGL objects
 between contexts, see the sharedContext variable in the
 osg::GraphicsContext::Traits object - use this to pass in the
 previously created context.  The downside of this approach is
 threading issues relating to creation and distruction order of the
 shared OpenGL objects.  The best way to avoid issues is to run the OSG
 single threaded.

 The other alternatively, and by far the best solution is to use a
 single Window with 9 viewports - which boils down to all the Camera's
 sharing the same GraphicsWindow.  This will give you the best alround
 performance and memory utilisation.

 Robert.

 On Tue, Nov 11, 2008 at 4:07 PM, Dan Small [EMAIL PROTECTED] wrote:
  Hello OSGers,
 
  I'm trying to create a security system simulator with 9 cameras visible
 to
  the user at all times.
 
  Eight of these will be static, fixed views of the same terrain.
 
  The last one will be a pan tilt zoom view.
 
  We are currently using a 150mb 3-D terrain model (IVE format, 5-LOD's,
  exported from terrex).  The vast majority of this data is texture.
 
  In general, we lockdown the LOD to the highest level for each window.
 
  There are two things happening that we would like to get more information
  on.
 
  1) each window view seems to create a full copy of the scenegraph in
  memory.  with eight Windows on the screen, we take up about 1.5 gigs of
  RAM.  This number goes down by about 150 MB if we create one less window
  each time.
 
  2) We seem to be running out of memory on the graphics card.  we get an
  OpenGL out of memory error, and in some of the windows created toward the
  end,  the terrain textures go white.  the graphics card has 768
 megabytes,
  and handles several windows just fine. Our thought was that by using
  compositeViewer, we could save on the memory necessary to render all of
  these different views.
 
  We are using independently allocated trait and graphicsContext objects.
  I
  do notice that the osgcompositeviewer example uses shared graphics
 context
  and traits.  I suspect that this may be the source of our problem.
 
  My question is why do we get such a major increase in memory when
 ostensibly
  we're using the same model?
 
  I will include some of the code implementation at the end for those who
  would like to see some specifics.
 
 
  Thanks,
 
  Dan Small
 
 
 
  major components of the Window Object:
 
  boost::shared_ptrusg::Scene getScene() const;
  void setScene( boost::shared_ptrusg::Scene x );
  void setLighting( bool lighting );
  bool getLighting() const;
  double getNear() const;
  void setNear(double x);
  double getFar() const;
  void setFar(double x);
 
  virtual umb::Vec4d getClearColor() const;
  void setClearColor( const umb::Vec4d color );
 
  void setFOVY( double fovy );
  double getFOVY() const;
 
  void setFOVX( double fovx );
  double getFOVX() const;
 
  void setFullScreen( bool fs );
  bool getFullScreen() const;
 
  void setUseMouseInteractions( bool is_use );
  bool getUseMouseInteractions() const;
 
  void toggleFullScreen();
 
  void setPosrot( const umb::PosRotd );
  umb::PosRotd getPosrot() const;
 
  void setLODScale( double x );
  double getLODScale() const;
 
  void setAutoNearFar( bool x );
  bool getAutoNearFar() const;
 
  void setWindowPos( const umb::Vec2i windowPos );
  umb::Vec2i getWindowPos() const;
 
  void setWindowSize( const umb::Vec2ui windowSize );
  umb::Vec2ui getWindowSize() const;
 
  ViewerManipulatorControl* getManipulatorControl() const;
 
  void hideMouseCursor( bool hideCursor );
 
  void addCameraNode( osg::Node* node );
 
  void setCenterPoint( const umb::Vec3d pr );
 
  umb::Vec3d getCenterPoint();
 
  osgViewer::View* getView()
  {
  return mView.get();
  }
 
  using 

Re: [osg-users] osgCairo and osgPango on Windows : some progress

2008-11-11 Thread Jeremy Moles
On Tue, 2008-11-11 at 11:14 -0500, Jean-Sébastien Guay wrote:
 Hi Jeremy,
 
  Merging now!
 
 I haven't updated from your SVN yet to see if anything has changed, but 
 compiling osgPango with the osgWidget branch of OSG has revealed a few 
 more changes needed for the osgpangoguiviewer and osgpangoanimation 
 examples. I've attached the patch file (without the other changes, so 
 they're separate). Both examples were missing some libraries in the 
 CMakeLists.txt files, and I had to make some small changes to 
 osgpangoanimation.cpp :

These will be in shortly; osgCairo is done, the osgPango patch was
harder because I had an ungodly amount of changes in the works. :)

 1. to use osg::round instead of round()
 2. for random(), I think using the more standard rand() defined in 
 stdlib.h would be better.
 
 Also, osgpangoguiviewer tries to load osgWidget/frame-theme.png which it 
 can't find, and instead of printing an error and exiting as it should, 
 it crashes when it tries to do image-s() in 
 osgWidget::Frame::createSimpleFrameWithSingleTexture(). The 
 osgDB::readImageFile should be taken out of the 
 createSimpleFrameWithSingleTexture() call at osgpangoguiviewer.cpp line 
 23 and its return value tested, and 
 osgWidget::Frame::createSimpleFrameWithSingleTexture() should test that 
 image is not NULL/0.
 
 Because I don't have this image, I can't tell if osgpangoguiviewer's 
 result is correct... I replaced it with osgWidget/theme.png (which is in 
 OSG-Data) but the result looks bad, so it's probably not the right image :-)

A lot of this is already fixed and just uncommitted; the guiviewer isn't
complete yet, though--it's purpose is to get a list of every available
font and provide a drop-down box to chose from them. It'll be a few more
days before this is finished.

 I will again make the comment that your screen settings in 
 osgpangoanimation.cpp are pretty bad. For one, not everyone has a screen 
 of 1920x1200 (I'm at 1280x1024 myself), and also, you position the 
 window at 0,0 (again!) which puts the title bar outside the screen on 
 Windows. Please let osgViewer position the window how the user wants 
 it... Your arguments from last week make sense, but there are ways of 
 getting the window size and then passing it wherever it's needed instead 
 of locking the example to a set resolution and window placement.

I just set it to 1920x1200 (my res on my laptop) for a test and forgot
to change it to something sensible. As far as getting the OSG viewer
resolution is concerned, I'm probably more prone to just fixing the bug
outright rather than working around it. To be honest, I don't really
even know of any way to get this data--it's abstracted somewhere deep in
OSG. If you know of an example bit of code that does it, please let me
know.

 Other than that, osgpangoanimation's result looks good (looks like the 
 video on the osgPango site, to be specific) so osgPango's grade goes up 
 from 3/5 to 4/5. :-)
 
 Thanks for your hard work, and please excuse my ranting...

Haha, it's all good. :) Thanks for everything so far!

 J-S
 plain text document attachment (osgPango-2.patch)
 Index: examples/osgpangoanimation/CMakeLists.txt
 ===
 --- examples/osgpangoanimation/CMakeLists.txt (revision 23)
 +++ examples/osgpangoanimation/CMakeLists.txt (working copy)
 @@ -1,7 +1,14 @@
  PROJECT(osgpangoanimation)
  
 -LINK_LIBRARIES(osgPango)
 +# osgPango gets the proper debug postfix automatically since it's part of the
 +# current project, but we need to add the postfix for the other libs.
 +LINK_LIBRARIES(osgPango
 +   debug OpenThreads${CMAKE_DEBUG_POSTFIX}
 +   optimized OpenThreads
 +   debug osgGA${CMAKE_DEBUG_POSTFIX}
 +   optimized osgGA)
  
  ADD_EXECUTABLE(osgpangoanimation osgpangoanimation.cpp)
  
  INSTALL(TARGETS osgpangoanimation DESTINATION ${CMAKE_INSTALL_PREFIX}/bin)
 +SET_TARGET_PROPERTIES(osgpangoanimation PROPERTIES DEBUG_POSTFIX 
 ${CMAKE_DEBUG_POSTFIX})
 Index: examples/osgpangoanimation/osgpangoanimation.cpp
 ===
 --- examples/osgpangoanimation/osgpangoanimation.cpp  (revision 23)
 +++ examples/osgpangoanimation/osgpangoanimation.cpp  (working copy)
 @@ -9,6 +9,8 @@
  #include osgAnimation/EaseMotion
  #include osgPango/Text
  
 +#include stdlib.h
 +
  // const unsigned int WINDOW_WIDTH  = 720;
  // const unsigned int WINDOW_HEIGHT = 480;
  
 @@ -56,7 +58,7 @@
   
   _motions[i] = MyMotion(0, duration, 3.14, 
 osgAnimation::Motion::LOOP);
   
 - float offset = (random() * 1.0 / (1.0 * 
 RAND_MAX)) * duration;
 + float offset = (rand() * 1.0 / (1.0 * 
 RAND_MAX)) * duration;
   
   _motions[i].setTime(offset);
   

Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-11 Thread J.P. Delport

Hi Robert,

thanks for looking into this.

Just ran it on Core2 Duo 2GB machine, GeForce 8800GT 256MB driver 
177.67, Debian Sid.


I had to add a bit more fbo's before a crash, but maybe it's cos the 
machine is slower.


With some smaller (32x32) sizes I even managed a X crash and restart.

osgmemorytest --window --fbo 512 512 -g 300
iteration 0
Got an X11ErrorHandling call display=0x80c3418 event=0xbfe574d0
BadAlloc (insufficient resources for operation)
Major opcode: 143
Minor opcode: 27
Error code: 11
Request serial: 2848
Current serial: 2849
  ResourceID: 48234499
Got an X11ErrorHandling call display=0x80c3418 event=0xbfe57530
BadDrawable (invalid Pixmap or Window parameter)
Major opcode: 145
Minor opcode: 4
Error code: 9
Request serial: 2849
Current serial: 2849
  ResourceID: 48234499
Warning: detected OpenGL error 'out of memory' after applying attribute 
FrameBufferObject 0x80aa470


jp

Robert Osfield wrote:

Hi Guys,

I've now got an osgmemorytest example checked into svn/trunk, it
currently supports allocating windows, pbuffers and textures/fbo for
each of the windows/pbuffers created.   I get some wierd results...

The follow test run:

   osgmemorytest --window --fbo 1024 1024 -g 150

Succeeds.  While using a smaller fbo it fails at the 145'th fbo:

osgmemorytest --window --fbo 512 512 -g 150

With the command line output:

iteration 0
Got an X11ErrorHandling call display=0x653c50 event=0x7fff31e452c0
BadAlloc (insufficient resources for operation)
Major opcode: 128
Minor opcode: 27
Error code: 11
Request serial: 1071
Current serial: 1072
  ResourceID: 27262979
Got an X11ErrorHandling call display=0x653c50 event=0x7fff31e452c0
BadWindow (invalid Window parameter)
Major opcode: 145
Minor opcode: 4
Error code: 3
Request serial: 1072
Current serial: 1072
  ResourceID: 27262979
Warning: detected OpenGL error 'out of memory' after applying
attribute FrameBufferObject 0x6513c0

Exception caught, contexts completed = 0, gl objects successfully
applied =145, error = OpenGL error

So I get an out of memory error when I use smaller FBO's. I've tried
smaller sizes like 128x128 and also get the exactly same error.  When
I run multiple contexts I get the error when the exactly the same
total number of small FBO's are allocated.  By using -c 2 to set the
number of contexts to allocate to 2, and -g 100 to limit the number of
GL objects (FBO's in this instance) to 100 per context I get the
result:

osgmemorytest --window --fbo 512 512 -g 100 -c 2
iteration 0
iteration 1
Got an X11ErrorHandling call display=0x990bd0 event=0x7fff3824f6b0
BadAlloc (insufficient resources for operation)
Major opcode: 128
Minor opcode: 27
Error code: 11
Request serial: 363
Current serial: 364
  ResourceID: 54525955
Got an X11ErrorHandling call display=0x990bd0 event=0x7fff3824f6b0
BadWindow (invalid Window parameter)
Major opcode: 145
Minor opcode: 4
Error code: 3
Request serial: 364
Current serial: 364
  ResourceID: 54525955
Warning: detected OpenGL error 'out of memory' after applying
attribute FrameBufferObject 0x625180

Exception caught, contexts completed = 1, gl objects successfully
applied =145, error = OpenGL error


The lines iteration 0 and iteration 1, show that the first context was
created with all 100 FBO's just fine. Even stranger when I up the fbo
size to 1024x1024 it's able to allocate 156 FBO's, and when higher
still it gets even further to the point of exhausting all memory on
the machine and grinding it to nearly to a halt due to pushing swap
space too hard.

All these tests are being run single threaded on my Kubuntu 7.10,
Geforce 8800GTS 640Mb, 4GB machine. From glxinfo: OpenGL version
string: 2.1.1 NVIDIA 100.14.19.

So what does this all point to?  My best guess is that the driver is
multi-threaded and if we allocate smaller FBO's they get created more
quickly and hit a threading issue in the driver.  It's pretty clearly
a driver bug.  I'm currently compiling on one of my other machines
with Kubuntu 8.10 installed.

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



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


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


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


Re: [osg-users] crash with multimonitor multithread nVIDIAworkaround enabled

2008-11-11 Thread Wojciech Lewandowski
Hi Marco,

Its really weird. I am pretty much sure we have tested this with Vista x64,
but maybe not the latest drivers. May I send you simpified OpenGL only repro
I have sent to NVidia as a bug report ? I am curious if the crash will
happen with it as well ?

Cheers,
Wojtek


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Robert
Osfield
Sent: Tuesday, November 11, 2008 11:20 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] crash with multimonitor multithread
nVIDIAworkaround enabled


Hi Marco,

This screams drive bug to me - calling make current twice in
succession on the same thread should do nothing as the second call
should be a non op.  It is of course pretty dumb calling make current
twice in quick succession on the same thread, but this were required
due to an earlier bug on NVidia Windows drivers which thankfully has
now been fixed in recent drivers.

Kinda bizarre that a workaround for an NVidia driver bug breaks other
version of NVidia drivers...  Are they deliberately trying to break
the OSG in any which way they can?

This does suggest that it's time to set this workaround to off by
default.  Perhaps a better approach for this workaround would be to
have a bool in GraphicsWindowWin32 that can be set at runtime, rather
than something that is compiled in.  This would allow driver version
detection in clients apps that feel they need this workaround.  An env
var could also enable it too.

Robert.



On Tue, Nov 11, 2008 at 10:00 AM, Marco Jez [EMAIL PROTECTED] wrote:
 Hi,

 on a fresh build of latest OSG with default configuration options, all
 examples and applications based on osgViewer crash if any of the
 multi-threading modes are enabled (including the default one). This
happens
 on Vista x64 with an nVIDIA GeForce 8800 GT card and latest drivers
 (178.24). I've also tested on another Vista system with a GeForce 6800 and
 less recent video drivers.

 The crash takes place in GraphicsWindowWin32.cpp at line 1701, when
 wglMakeCurrent() is called, but only if
 OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND is defined (which is
 the default). The reason seems obscure to me, and I wouldn't classify it
as
 a bug, since the workaround code is just that: a workaround for a driver
 bug. I just wanted to report that applications built with this workaround
 enabled will probably work fine on XP (and maybe Vista 32) but will crash
on
 Vista x64, at least under conditions similar to those of my two systems.

 Cheers,
 Marco

 ___
 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] BUG FOUND: FLT Writer Duplicate Node Names?

2008-11-11 Thread Paul Martz
Thanks, John. If you fix this, please post the fix to osg-submissions.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Argentieri,
John-P63223
Sent: Tuesday, November 11, 2008 11:35 AM
To: [EMAIL PROTECTED]
Subject: Re: [osg-users] BUG FOUND: FLT Writer Duplicate Node Names?


Paul,
 
Attached is an example of a bug I found in the FLT writer. If the
GL_POLYGON_OFFSET remains inside of extref.osg, then converting it to FLT
using osgconv will cause the texture of the external reference to disappear.
If the GL_POLYGON_OFFSET is removed from extref.osg, then extref.osg is
converted to FLT using osgconv, the texture on the external reference
remains.
 
Thanks,
John Argentieri

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Argentieri,
John-P63223
Sent: Tuesday, November 11, 2008 12:29 PM
To: [EMAIL PROTECTED]
Subject: Re: [osg-users] FLT Writer Duplicate Node Names?


Guys,
 
Has anyone used the ProxyNode in this way, in OpenFlight files? My primary
file and my externally referenced file are both OpenFlight files. The
externally referenced file gets loaded, but the texture is incorrect. The
texture applied to the model, in my case, is the only one that is used
internally in the primary OpenFlight file. For example, my terrain surface
is internal and textured as grass. My externally reference tree models are
shaped like trees, but also textured in grass. I've tried moving the tree's
texture files around to be sure that it wasn't a path issue. It didn't work.
 
Is there anyone that can help me to resolve the issues I am having? All I
want to do is write an OpenFlight file that contains several clones of
another OpenFlight file. The straightforward approach breaks -- not for the
current OSG loader, but for other loaders that expect node names to be
unique.
 
Your friend,
John Argentieri
 
  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz
Sent: Friday, November 07, 2008 1:51 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] FLT Writer Duplicate Node Names?


The exporter writes an external reference record when it encounters a
ProxyNode. The importer should do the inverse operation.
 
I searched for the error text you mentioned, but could not find any code in
OSG that displays that error, so I can't really help you with that.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Argentieri,
John-P63223
Sent: Friday, November 07, 2008 11:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [osg-users] FLT Writer Duplicate Node Names?


Paul,
 
Is there a way that I can place multiple instances of an external .flt file
into another .flt file? I'm trying to use ProxyNode, but still getting these
errors:
 
Non primary record found as child. op=19
Non primary record found as child. op=19
Non primary record found as child. op=20
Non primary record found as child. op=20
 
Thanks,
John
 

  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Paul Martz
Sent: Friday, November 07, 2008 12:51 PM
To: 'OpenSceneGraph Users'
Subject: Re: [osg-users] FLT Writer Duplicate Node Names?


The exporter dumps the Node name to the FLT record name, just as the
importer does the inverse operation. I don't believe there is any code to
check for and avoid duplicate node names.
 
I'd think it would be up to the application to specify unique Node names, as
the exporter has no other way to know what text should be written to the FLT
record name. I can see how it might be useful to have a I don't care what
you name it, just make sure it's unique mode. Currently, this doesn't
exist. You are welcome to add it.
   -Paul
 


  _  

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Argentieri,
John-P63223
Sent: Friday, November 07, 2008 8:41 AM
To: [EMAIL PROTECTED]
Subject: [osg-users] FLT Writer Duplicate Node Names?


Hello all.
 
Does the FLT writer create duplicate node names for nodes with multiple
transforms as parents? We're having trouble sharing a single model inside of
multiple transforms scattered about. Some older OpenFlight software we are
interfacing to does not like this. Any thoughts guys?
 
Thank you,
John Argentieri 
Software Engineer 
GENERAL DYNAMICS 
C4 Systems 
[EMAIL PROTECTED] 

This email message is for the sole use of the intended recipient(s) and may
contain GDC4S confidential or privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not an
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.

 

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


Re: [osg-users] crash with multimonitor multithreadnVIDIAworkaround enabled

2008-11-11 Thread Marco Jez

Hi Wojtek,

Its really weird. I am pretty much sure we have tested this with Vista 
x64,
but maybe not the latest drivers. May I send you simpified OpenGL only 
repro

I have sent to NVidia as a bug report ? I am curious if the crash will
happen with it as well ?


Sure, I'm glad to help.

Marco


No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.9.1/1781 - Release Date: 11/11/2008 859
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Introducing osgmemorytest

2008-11-11 Thread Csaba Halász
On Tue, Nov 11, 2008 at 7:01 PM, Jeremy Moles [EMAIL PROTECTED] wrote:

 I probably won't be the only one to say it but...

 This is wicked awesome. :)

It is *wicked* all right ...

Notebook, Intel c2d 2.2Ghz, 3GB ram + 4GB swap, nVidia 8600M-GT 256MB,
driver 177.80

1) 103
2) 207
3) 154 seconds, 6GB (!) memory
4) 6.79 seconds
5) 2.58 seconds
6) 2.16 seconds
7) 215
8) lockup, second try: 237
9) 239, used up all 7GB memory, lockup

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


Re: [osg-users] crash with multimonitor multithreadnVIDIAworkaround enabled

2008-11-11 Thread Wojciech Lewandowski
Thanks, Marco. 

I will send this code tomorrow from my office. I don't have it at home. 

Cheers,
Wojtek

Hi Wojtek,

 Its really weird. I am pretty much sure we have tested this with Vista 
 x64,
 but maybe not the latest drivers. May I send you simpified OpenGL only 
 repro
 I have sent to NVidia as a bug report ? I am curious if the crash will
 happen with it as well ?

Sure, I'm glad to help.

Marco
 

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


Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-11 Thread Robert Osfield
Hi Guys,

I've now got an osgmemorytest example checked into svn/trunk, it
currently supports allocating windows, pbuffers and textures/fbo for
each of the windows/pbuffers created.   I get some wierd results...

The follow test run:

   osgmemorytest --window --fbo 1024 1024 -g 150

Succeeds.  While using a smaller fbo it fails at the 145'th fbo:

osgmemorytest --window --fbo 512 512 -g 150

With the command line output:

iteration 0
Got an X11ErrorHandling call display=0x653c50 event=0x7fff31e452c0
BadAlloc (insufficient resources for operation)
Major opcode: 128
Minor opcode: 27
Error code: 11
Request serial: 1071
Current serial: 1072
  ResourceID: 27262979
Got an X11ErrorHandling call display=0x653c50 event=0x7fff31e452c0
BadWindow (invalid Window parameter)
Major opcode: 145
Minor opcode: 4
Error code: 3
Request serial: 1072
Current serial: 1072
  ResourceID: 27262979
Warning: detected OpenGL error 'out of memory' after applying
attribute FrameBufferObject 0x6513c0

Exception caught, contexts completed = 0, gl objects successfully
applied =145, error = OpenGL error

So I get an out of memory error when I use smaller FBO's. I've tried
smaller sizes like 128x128 and also get the exactly same error.  When
I run multiple contexts I get the error when the exactly the same
total number of small FBO's are allocated.  By using -c 2 to set the
number of contexts to allocate to 2, and -g 100 to limit the number of
GL objects (FBO's in this instance) to 100 per context I get the
result:

osgmemorytest --window --fbo 512 512 -g 100 -c 2
iteration 0
iteration 1
Got an X11ErrorHandling call display=0x990bd0 event=0x7fff3824f6b0
BadAlloc (insufficient resources for operation)
Major opcode: 128
Minor opcode: 27
Error code: 11
Request serial: 363
Current serial: 364
  ResourceID: 54525955
Got an X11ErrorHandling call display=0x990bd0 event=0x7fff3824f6b0
BadWindow (invalid Window parameter)
Major opcode: 145
Minor opcode: 4
Error code: 3
Request serial: 364
Current serial: 364
  ResourceID: 54525955
Warning: detected OpenGL error 'out of memory' after applying
attribute FrameBufferObject 0x625180

Exception caught, contexts completed = 1, gl objects successfully
applied =145, error = OpenGL error


The lines iteration 0 and iteration 1, show that the first context was
created with all 100 FBO's just fine. Even stranger when I up the fbo
size to 1024x1024 it's able to allocate 156 FBO's, and when higher
still it gets even further to the point of exhausting all memory on
the machine and grinding it to nearly to a halt due to pushing swap
space too hard.

All these tests are being run single threaded on my Kubuntu 7.10,
Geforce 8800GTS 640Mb, 4GB machine. From glxinfo: OpenGL version
string: 2.1.1 NVIDIA 100.14.19.

So what does this all point to?  My best guess is that the driver is
multi-threaded and if we allocate smaller FBO's they get created more
quickly and hit a threading issue in the driver.  It's pretty clearly
a driver bug.  I'm currently compiling on one of my other machines
with Kubuntu 8.10 installed.

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


Re: [osg-users] osgCairo and osgPango on Windows : some progress

2008-11-11 Thread Jeremy Moles
On Mon, 2008-11-10 at 21:58 -0500, Jean-Sébastien Guay wrote:
 Hi Jeremy,
 
  So, are you able to notice any difference in font quality under Windows?
  Each glyph should be sharp and crisp, with absolutely not visual
  anomalies of any sort. This is harder to do than you might think, so it
  was always the most important (and the reason for writing the kit in the
  first place!)
 
 Yep, looks great, much better than normal osgText output (which has 
 blurry characters at some sizes and characters that seem clipped one or 
 two columns sometimes).
 
  Also, add:
  
  --cache outline 2
  
  ...as an arg, or:
  
  --cache shadowOffset 1
  
  ...or something like that. :)
 
 Heh, looks great too!
 
 So, when are you going to merge my changes? :-)

Sorry! Got my hands on a Wii last night and didn't do anything else. :)
Merging now!

 J-S

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


Re: [osg-users] crash with multimonitor multithread nVIDIA workaround enabled

2008-11-11 Thread Robert Osfield
Hi Marco,

This screams drive bug to me - calling make current twice in
succession on the same thread should do nothing as the second call
should be a non op.  It is of course pretty dumb calling make current
twice in quick succession on the same thread, but this were required
due to an earlier bug on NVidia Windows drivers which thankfully has
now been fixed in recent drivers.

Kinda bizarre that a workaround for an NVidia driver bug breaks other
version of NVidia drivers...  Are they deliberately trying to break
the OSG in any which way they can?

This does suggest that it's time to set this workaround to off by
default.  Perhaps a better approach for this workaround would be to
have a bool in GraphicsWindowWin32 that can be set at runtime, rather
than something that is compiled in.  This would allow driver version
detection in clients apps that feel they need this workaround.  An env
var could also enable it too.

Robert.



On Tue, Nov 11, 2008 at 10:00 AM, Marco Jez [EMAIL PROTECTED] wrote:
 Hi,

 on a fresh build of latest OSG with default configuration options, all
 examples and applications based on osgViewer crash if any of the
 multi-threading modes are enabled (including the default one). This happens
 on Vista x64 with an nVIDIA GeForce 8800 GT card and latest drivers
 (178.24). I've also tested on another Vista system with a GeForce 6800 and
 less recent video drivers.

 The crash takes place in GraphicsWindowWin32.cpp at line 1701, when
 wglMakeCurrent() is called, but only if
 OSG_MULTIMONITOR_MULTITHREAD_WIN32_NVIDIA_WORKAROUND is defined (which is
 the default). The reason seems obscure to me, and I wouldn't classify it as
 a bug, since the workaround code is just that: a workaround for a driver
 bug. I just wanted to report that applications built with this workaround
 enabled will probably work fine on XP (and maybe Vista 32) but will crash on
 Vista x64, at least under conditions similar to those of my two systems.

 Cheers,
 Marco

 ___
 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] compositeViewer newbie question

2008-11-11 Thread Dan Small
Hello OSGers,

I'm trying to create a security system simulator with 9 cameras visible to
the user at all times.

Eight of these will be static, fixed views of the same terrain.

The last one will be a pan tilt zoom view.

We are currently using a 150mb 3-D terrain model (IVE format, 5-LOD's,
exported from terrex).  The vast majority of this data is texture.

In general, we lockdown the LOD to the highest level for each window.

There are two things happening that we would like to get more information
on.

1) each window view seems to create a full copy of the scenegraph in
memory.  with eight Windows on the screen, we take up about 1.5 gigs of
RAM.  This number goes down by about 150 MB if we create one less window
each time.

2) We seem to be running out of memory on the graphics card.  we get an
OpenGL out of memory error, and in some of the windows created toward the
end,  the terrain textures go white.  the graphics card has 768 megabytes,
and handles several windows just fine. Our thought was that by using
compositeViewer, we could save on the memory necessary to render all of
these different views.

We are using independently allocated trait and graphicsContext objects.  I
do notice that the osgcompositeviewer example uses shared graphics context
and traits.  I suspect that this may be the source of our problem.

My question is why do we get such a major increase in memory when ostensibly
we're using the same model?

I will include some of the code implementation at the end for those who
would like to see some specifics.


Thanks,

Dan Small



*major components of the Window Object:
*
boost::shared_ptrusg::Scene getScene() const;
void setScene( boost::shared_ptrusg::Scene x );
void setLighting( bool lighting );
bool getLighting() const;
double getNear() const;
void setNear(double x);
double getFar() const;
void setFar(double x);

virtual umb::Vec4d getClearColor() const;
void setClearColor( const umb::Vec4d color );

void setFOVY( double fovy );
double getFOVY() const;

void setFOVX( double fovx );
double getFOVX() const;

void setFullScreen( bool fs );
bool getFullScreen() const;

void setUseMouseInteractions( bool is_use );
bool getUseMouseInteractions() const;

void toggleFullScreen();

void setPosrot( const umb::PosRotd );
umb::PosRotd getPosrot() const;

void setLODScale( double x );
double getLODScale() const;

void setAutoNearFar( bool x );
bool getAutoNearFar() const;

void setWindowPos( const umb::Vec2i windowPos );
umb::Vec2i getWindowPos() const;

void setWindowSize( const umb::Vec2ui windowSize );
umb::Vec2ui getWindowSize() const;

ViewerManipulatorControl* getManipulatorControl() const;

void hideMouseCursor( bool hideCursor );

void addCameraNode( osg::Node* node );

void setCenterPoint( const umb::Vec3d pr );

umb::Vec3d getCenterPoint();

osgViewer::View* getView()
{
return mView.get();
}

using umb::Interpreter::Object::getName;
using umb::Interpreter::Object::setName;

private:

int mViewNumber;
bool mLighting;

osg::ref_ptrosgViewer::View mView;
boost::shared_ptrusg::Scene mScene;
umb::Vec4d mClearColor;
boost::shared_ptrusg::SceneLight mSceneLight;

osg::ref_ptrosg::Group mGroup;


size_t mToken;
double mLODScaleCache;

bool mIsFullScreen;
bool mUseMouseInteractions;

uviewer::ViewerManipulatorControl* mManipulatorControl;
usg::ShapeIntersections mPickInformation;

umb::Vec2i mWindowPos;
umb::Vec2ui mWindowSize;

std::vectorstd::string mReservedKeys;
std::vectorstd::string mReservedKeysFirst;

std::mapstd::string, umb::PosRotd mViewpoints;

osg::ref_ptrosg::Image mColorImage;
osg::ref_ptrosg::Image mDepthImage;

WindowCapturePostDrawCallback* mCameraPostRenderCB;




*// Constructor

*
uviewer::Window::Window() :
mViewNumber( 0 ),
mLighting( true ),
mView( new osgViewer::View ),
mClearColor( 0, 0, 0, 1 ),
mGroup( new osg::Group() ),
mToken( 0 ),
mLODScaleCache( 1.0 ),
mIsFullScreen( false ),
mUseMouseInteractions( false ),
mManipulatorControl( 0 ),
mPickInformation(),
mWindowPos( umb::Vec2i( 100, 100 ) ),
mWindowSize( umb::Vec2ui( 800, 450 ) )
{
float characterSize = 20.0f;
osg::Vec3 pos( 0.0f, 0.0f, 0.0f );

osg::Geode* textGeode = new osg::Geode;
textGeode-addDrawable( infoText );
mGroup-addChild( textGeode );

mView-setSceneData( mGroup.get() );

mColorImage = oc_color.get();
mDepthImage = oc_depth.get();

mCameraPostRenderCB = new WindowCapturePostDrawCallback( mView.get(),
mColorImage.get(), 

Re: [osg-users] Runtime error in ODE tutorial

2008-11-11 Thread Janusz

Filip:

I would guess you are missing this line in your code:

// 9.3. Call collision detection.
dSpaceCollide (Space, 0, NearCallback);

Try to review your code for any missing ODE function calls.
The example runs just fine (w/o osgviewer).
Regards, Janusz


Filip R. Andersson pisze:

Hi all,

I downloaded the ODE tutorial from the following page:
http://www.openscenegraph.org/projects/osg/attachment/wiki/Support/Tutorials/LMBs_ODE_Demo.zip

The code uses OSGProducer and since I don't have Producer or 
OSGProducer installed on my machine I made some minor changes in the 
code to use osgViewer instead.



The code compiles fine but I get the following run-time error:

---
ODE Message 2: zero length vector in dRFrom2Axes() File rotation.cpp 
Line 113


ODE Message 2: zero length vector in dRFrom2Axes() File rotation.cpp Line

ODE INTERNAL ERROR 2: colliders array not initialized in dCollide()
Aborted


Has anyone encountered this and how did you solve it?

I downloaded the ode-0.10.1 source code and built it  with default 
settings on my Linux Machine.



Filip



___
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] camera postion problem

2008-11-11 Thread Wiebe Hoekstra
Hi

Thanks for the help, I found the problem this morning. There where some
matrices mixed up. 

Grtz Wiebe

On Mon, 2008-11-10 at 13:52 +, Robert Osfield wrote:
 Hi Wiebe,
 
 Only you know what the right position is for your app.  This is once
 you have the model matrix that the codes provide is all boils down
 basic a vector maths question, it's not my role to teach you this,
 there are plenty of books that do this.
 
 Robert.
 
 On Mon, Nov 10, 2008 at 1:43 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
  hi,
 
  I have tried to use the NodeTrackerManipulator as well but i can't get
  it in the right place. If you could tell me how to rotate the camera to
  the right position maybe this could be a solution.
  For the trackball manipulator it is possible to set the rotation. I
  haven't found a way to do this with the NodeTrackerManipulator.
 
  Grtz Wiebe
 
 
 
  On Mon, 2008-11-10 at 13:37 +, Robert Osfield wrote:
  Hi Wiebe,
 
  I'm afraid I'm not familiar with this particular tutorial code so
  answer a question on it would have learn it first, which puts me one
  step behind where you are already.
 
  The osgGA library has a similar class call NodeTrackerManipulator
  which might not server your purpose exactly might be a better base.
  I wrote NodeTrackerManipulator so am a little better on off
  understanding what on earth it's supposed to do front.
 
  Robert.
 
  On Mon, Nov 10, 2008 at 1:19 PM, Wiebe Hoekstra [EMAIL PROTECTED] wrote:
   I have used the follow node tutorial to get the track the node.
  
   http://www.openscenegraph.org/projects/osg/wiki/Support/Tutorials/CameraControlNodeFollowing
  
   This seems to be working fine. But a look at the wrong site off the
   ship. Therefore i have changed the getInverseMatrix() to the following:
  
   m = m_matrix *
   osg::Matrixd::rotate(osg::DegreesToRadians(180.0),osg::Vec3(1,0,0));
  
   I was expecting to look at the top of the ship, but it is the bottom and
   it looks like the area is mirrored.
  
   I thing the wrong movements off the mouse is a side affect off the wrong
   orientation off the camera.
  
   Wiebe
  
  
   On Mon, 2008-11-10 at 13:03 +, Robert Osfield wrote:
   Hi Wiebe,
  
   I'm afraid your email lacks enough information to be able to comment.
   You have to start by explaining how you are trying to track the node
   in the scene, and how this relates to how you are managing mouse
   movements.
  
   Robert.
  
   On Mon, Nov 10, 2008 at 12:53 PM, Wiebe Hoekstra [EMAIL PROTECTED] 
   wrote:
Hi users,
   
I try to track a node in a scene. This scene is a area with a ship. 
The
node i try to follow is the ship. All seems oke but the complete scene
seems to be mirrored.
Even the mousse movents in x direction are inverse.
   
Wiebe
   
   
   
ing. Wiebe Hoekstra
Software Engineer
Maritime Simulation Group
mailto:[EMAIL PROTECTED]
T +31 317 49 35 19
   
MARIN
2, Haagsteeg, P.O. Box 28, 6700 AA Wageningen, The Netherlands
T +31 317 49 39 11, F +31 317 49 32 45, I http://www.marin.nl/
   
   
   
   
   
MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, 
Bilbao
   
   
This e-mail may be confidential, privileged and/or protected by 
copyright. If you are not the intended recipient, you should return 
it to the sender immediately and delete your copy from your system.
   
   
   MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, 
   Bilbao
   This e-mail may be confidential, privileged and/or protected by 
   copyright. If you are not the intended recipient, you should return it 
   to the sender immediately and delete your copy from your system.
  
  MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
  This e-mail may be confidential, privileged and/or protected by copyright. 
  If you are not the intended recipient, you should return it to the sender 
  immediately and delete your copy from your system.
  
MARIN webnews: FPSO JIP Week  FPSO Research Forum, November 10-14, Bilbao
This e-mail may be confidential, privileged and/or protected by copyright. If 
you are not the intended recipient, you should return it to the sender 
immediately and delete your copy from your system.
___


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

Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-11 Thread Robert Osfield
Hi JP et al.

On Tue, Nov 11, 2008 at 2:21 PM, Robert Osfield
[EMAIL PROTECTED] wrote:
 I'm going to add an optional sleep into the each gl object apply to
 see if this make any difference.

I've added an osgmemorytest command line option --delay microseconds
that invokes an OpenThread::Thread::microSleep(microsecons) before
each OpenGL object apply.

I've tried a range of sleeps and none have any effect on the number of
FBO's that the driver is able to create.  So this discounts the theory
that we're push OpenGL fifo so quickly that it's invoke threading
issues.

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


Re: [osg-users] Many RTT cameras, strange out of memory errors on Linux

2008-11-11 Thread Robert Osfield
Hi JP,

I've got some odd X server crashes and restart as well.  On my little
shuttle with Kubuntu 8.10 on it it gets to 215 fbo's at 512x512.  This
is with a  lowe end128Mb Geforce 7 card + only 1Gb memory rather 4GB
on my main machine.  The Kubuntu 8.10 machine has OpenGL version
string 2.1.2 NVIDIA 177.80.  So it looks like later drivers, or
perhaps just slower machines are better off w.r.t the memory errors.

I'm going to add an optional sleep into the each gl object apply to
see if this make any difference.

This very much looks like a driver bug so we'll need to contact NVidia
and get them on to.  Anyone with a hotline to NVidia?

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


Re: [osg-users] Particle system setInitialRotationalSpeedRange()

2008-11-11 Thread Jolley, Thomas P
Hi Robert,
 
I've looked into this a little further.  It appears the changes you made
to ParticleSystem.cpp on March 17th is the reason for the behavior
change.  I don't have a solution yet other than backing out the changes.
I'm still trying to understand what you're doing in the
single_pass_render function before coming up with a solution.
 
I think this problem was mentioned in an earlier thread around May.  See
http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2
008-May/011595.html.
 
To see the problem look at SmokeBox.osg with osgviewer (I'm using osg
2.6.0).  The particles are rotating about the wrong axis (or at least a
different axis).
 

Tom Jolley
 




From: Jolley, Thomas P 
Sent: Thursday, August 21, 2008 2:11 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Particle system
setInitialRotationalSpeedRange()


Hi Erik,
 
I noticed the same thing about a week ago while upgrading an
application from osg 1.0 to 2.4.  It was on my list of things to look
into.




From: Erik Johnson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 21, 2008 10:30 AM
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Particle system
setInitialRotationalSpeedRange()


There is certainly a change in behavior, although I
can't pinpoint the change in code yet.

Setting the rotational speed with (0, 0, 1):
OSG 2.2.0 - particles rotate like fans (pinwheels) 
OSG 2.4.0 - particles rotate like a margarita blender
(cork-screw)
OSG 2.6.0 - particles rotate like a margarita blender
(cork-screw)

I guess I'm just wondering if this is the expected
behavior?  And I'm surprised nobody has a problem with this.

Thanks,
Erik




Date: Thu, 21 Aug 2008 09:26:52 +0100
From: Robert Osfield
[EMAIL PROTECTED]
Subject: Re: [osg-users] Particle system
   setInitialRotationalSpeedRange()
To: OpenSceneGraph Users
osg-users@lists.openscenegraph.org
Message-ID:

[EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1

Hi Erik,

osgParticle has hardly been touched between
OSG-2.2 and 2.6.   Use svn
log to check which files have changed.

Robert.

On Thu, Aug 21, 2008 at 1:07 AM, Erik Johnson
[EMAIL PROTECTED] wrote:
 Hi all,

 It seems to me, back in the OSG 2.2.x time
frame, that I could set the
 initial rotational velocity of the
RadialShooter and have the particles
 pinwheel around their center point, while
maintaining their billboard
 orientation and face the Camera.  Perhaps it
was a rotation on the Y
 axis.

 Nowadays with OSG 2.4/2.6, setting the
rotational speed will cause the
 particles to rotate relative to the world axis
and not in the
 camera-relative axis.

 Is this a bug? A feature?  Is it still posible
to pinwheel a particle
 around?  Does anyone use
setInitialRotationalSpeedRange()?

 This was a cool effect which added a nice
dimension to smoke plumes and
 such.

 Thanks for any info!
 -Erik Johnson



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

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






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


Re: [osg-users] A patch to enable making hardware extensions disabled in Texture.cpp

2008-11-11 Thread Tatsuhiro Nishioka
Sure, no problem at all.

However, I'm now doing further investigation for simpler code to do
the same thing. I'm wondering if version check is actually needed for
each extension availability check. Since OpenGL must be upward
compatible, you can call only isGLExtensionEnabled for that purpose.
The extensions can be accessible as extensions even these were
promoted to be OpenGL core functionalities in a certain version.

So, I'll try cutting all the version comparisons in checking extension
availability from entire osg classes for doing what I mentioned in the
last post. Plus, I'll also add a workaround to avoid crash on
Macs/GeForce 7300GT.

Only one thing I'm worried is that I don't know if there are some
exceptional OpenGL drivers that don't have the compatibility written
in OpenGL specification. In that case, we need to think about another
way to achieve this issue.

Anyway, I'll post the files to the submission list when it's done.

Tat

p.s.
If you want me to post the workaround for GeForce separately from the
ones with extension disable/enable thing, I'll do so (since these are
for different purposes).


On 11/10/08, Robert Osfield [EMAIL PROTECTED] wrote:
 HI Tat,

 Could you post the whole modified file to osg-submissions I can then
 review it their alongside the rest of the code submissions.

 Thanks,
 Robert.

 On Sun, Nov 9, 2008 at 5:38 PM, Tatsuhiro Nishioka
 [EMAIL PROTECTED] wrote:
 Hi there,

 I received some crash reports on FlightGear/OSG from a user who uses
 nVidia 7300GT on Macs.
 Debugging on an iMac gave me that hardware mipmapping on its driver caused
 the crash.
 so I once made a fix-it-only-for-this-issue kinda patch that simply
 disable hardware mipmapping when
 the renderer is NVIDIA GeForce 7300GT OpenGL Engine,  and that actually
 fixed the problem.
 (see
 http://www.mail-archive.com/[EMAIL PROTECTED]/msg18674.html
 for more detail on this problem and the patch.)

 However, I'm wondering if users can disable hardware extensions to avoid
 such problems.
 I tried
 OSG_GL_EXTENSION_DISABLE=GL_SGIS_generate_mipmap;GL_EXT_framebuffer_object
 but nothing happened.
 Taking a look at Texture.cpp tells me you can never disable hardware
 extensions if your OpenGL driver version = 1.4 (or 2.0)
 It calls isGLExtensionSupported to check if an extension is supported but
 these will never called.
 For example, the following code is for checking hardware mipmapping
 extension:

_isGenerateMipMapSupported = (strncmp((const
 char*)glGetString(GL_VERSION),1.4,3)=0) ||

 isGLExtensionSupported(contextID,GL_SGIS_generate_mipmap);

 This means that isGLExtensionSupported will never be called when
 GL_VERSION = 1.4, resulting that you cannot disable it
 since environment variable is evaluated in isGLExtensionSupported.

 Attached is the patch to make hardware extensions disabled using the
 environment variable.
 I'm not so sure on the real purpose of the OR logic in the if statement
 above, but it is good to give users a choice.
 Can anyone test this and check if this is a right solution?

 Best,

 Tat

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


[osg-users] Coupling luabind with OSG + Bullet

2008-11-11 Thread Dusten Sobotta
Hello,

I've been working on an engine that combines sdl, osg, bullet, open al, and
now lua for roughly 6 weeks.  Static and dynamic entity creation works well
on the fly if handled with C++ code, however if I attempt to off-load this
logic to lua, I run into problems.  Below is an example of code that is
relevant to the problem:


void entityManager::loadStaticEntityList( const std::string filename ) {

lua_State *L = lua_open();
luabind::open(L);

luabind::module( L ) [

luabind::class_osg::Vec3f(Vec3f)
.def( luabind::constructor float, float, float () )
];

luabind::module( L ) [

luabind::class_entityManager(entityManager)
.def( luabind::constructor () )
.def( createStaticEntity, entityManager::createStaticEntity )
.def(destroyAllEntities, entityManager::destroyAllEntities )
];


if( luaL_loadfile( L, filename.c_str() ) || lua_pcall( L, 0, 0, 0 ) )
throw could not load entity list;


createStaticEntity( ball, osg::Vec3f( 0, 0, 0 ), false ); //direct C++
call; works!

luaL_dofile( L, filename.c_str() );

}
///

///
void entityManager::createStaticEntity( const std::string type, const
osg::Vec3f position, const bool dimension ) {

entity * newEntity = createEntityP( type, position, dimension );
_physicsManager-defineRigidBody( newEntity, type, false, dimension );

entities[ newEntity-getRigidBody() ] = newEntity;
staticEntities[ dimension ]-addChild( newEntity-getPAT().get() );
staticEntityList.push_back( newEntity );
}
///

And here is the lua script I'm trying to run:

--
entMan = entityManager()
a = Vec3f( 0, 0, 0 )

--same call from within lua; crashes the engine if uncommented!
entMan:createStaticEntity( ball, Vec3f( 2, 0, 0 ), false )
--


As you can see, a declaration of type Vec3f works from within lua, so I
don't think that using Vec3f as a parameter is an issue.
Might anyone know what's going on here?  I'm not very familiar with luabind,
and even less familiar with getting it to play nicely with OSG.  Any help
would be greatly appreciated.



Thanks for your time,

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