Re: [osg-users] Exception invalid lock sequence thrown from OSG App
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)
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)
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
Re: [osg-users] Runtime error in ODE tutorial
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
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
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] Particle system setInitialRotationalSpeedRange()
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
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
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
