Re: [osg-users] [osgPlugins] bus error when reading PNG data from stream for new plugin
Hi Stephan, Thomas, To preload the png-plugin: osgDB::Registry::instance()-loadLibrary(png); // or osgdb_png, not sure right now. Or I find it easier to do: osgDB::Registry::instance()-loadPluginForExtension(png); J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Real-Time geometry editing - changing positions
Hello Simon, Calling the setVertexArray every frame, however, brings the frame rate down dramatically, which isn't very acceptable. Is there a way to change vertices' positions in real time more effectively? This is an FAQ. Searching the list archives would have turned up many threads where this same question was asked. The OSG by default assumes that your vertex array is static, and generates display lists for your Drawables. If you update vertex data each frame, without disabling display lists on that Drawable, then OSG still thinks that your geometry is static and regenerates the display list every time you modify the vertex data. This is what is slowing you down. Effectively, OSG is generating display lists which are being used for only one frame and then discarded. Display lists are efficient only when they can be used for many frames, to offset the time required to generate them. Just call geometry-setUseDisplayList(false) when you create the geometry and you should be fine. Optionally you can enable Vertex Buffer Objects using geometry-setUseVertexBufferObjects(true). Search the list or OpenGL documentation to know when this is appropriate. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How Camera Manipulators Work
Hi Matt, So why are the manipulators currently set up the way they are? and would the community benefit from a new idiom and class structure in this particular area? If you guys agree with my point, I may try to develop such a structure. I totally agree with the principle. The reason is probably just the classic historical reasons and we've never needed that before ones that are part of open source, incremental, evolving development. Now that the camera manipulator API is already different between OSG 2.8.x and SVN, now might be the right time to do what you suggest. What would be the idea specifically? Would the camera manipulators expose a series of input connections, say pitch up/down, throttle up/down, and then have an InputDevice class that would expose outputs that you could connect to the camera manipulator's inputs? I would suggest that axes be mappable to either an analog axis (say mouse up/down or joystick y axis) or a pair of buttons (one for incrementing and one for decrementing the value). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How Camera Manipulators Work
Hi Matt, Your view of how the system would work is probably very similar to what I had in mind. Thanks for the explanation, and yes it's very similar to what I was thinking too. How would you map the input (gotten by the GUIEventHandler) to calls to the manipulator's functions in a general way? Because you wouldn't want one handler per manipulator (that would be almost the same as what we have now, just more code and more spread out), or even to have if (flightmanip) flightmanip-pitch(val) else if (trackballmanip) trackballmanip-rotateY(val) else ... in the event handler (even worse than what we have now). I was talking about connections before, that kind of thing is a bit hard to design so that it's minimally intrusive and as general as possible at the same time... The interfaces I've seen that attempted to implement connections in a very general way had an extremely verbose API, and then you would get google-eyed when you'd look at the setup code and might miss typos and small bugs... I'm just asking by curiosity... You could just code up your solution and send it, and stop wasting time replying to my questions :-) . I have no authority over what gets committed in OSG. I just wanted to know what you have in mind. Also, J-S, I didn't really understand the point you were trying to make in your final paragraph: I would suggest that axes be mappable to either an analog axis (say mouse up/down or joystick y axis) or a pair of buttons (one for incrementing and one for decrementing the value). Well, sometimes you run out of axes but have buttons to spare, and you could map two buttons to do (digitally) what an analog axis would normally do. I know I could just subclass and do what I want, but I think it would be a cool feature. For example, you said pitch(force) would accept magnitudes [-1,1]. Then you'd map an axis on an analog stick on your joystick to send, say, pitch(X) where X would map [-1,1] to the [down,up] range. But say you had two buttons and wanted to do the same thing, you could have button A send pitch(0.5) and button B send pitch(-0.5) for example. I'm just saying that if you can connect some value to an analog input that takes a range, you should also be able to connect that value to two digital inputs that go up and down as well. That's classic in games, where say the left/right steering of a car can either map to a joystick axis, or to the left/right arrow keys on your keyboard. Geez, a long explanation for what's basically a detail that could have been added later... That's me. Sorry about that. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] createContext Traits issue
Hi Christian, Has anyone ever seen this before? Did I set up my debug/release project settings incorrectly, or is this something on the osg end? Sounds like the release build of your app is using a debug compiled OSG. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] createContext Traits issue
Hi Christian, You were totally correct. Thank you for your help... It's a classic mistake that we're starting to be really good at spotting :-) Glad you got it fixed. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How Camera Manipulators Work
Hi Eduardo,
Ops, it's actually called CameraManipulator... but I've been thinking of
it as a matrix manipulator. Anyway the suggestion is still valid.
It was called MatrixManipulator until recently. That may be why you were
thinking of that.
But the point is that the thing that makes it all work is that the
osgViewer::View calls the CameraManipulator's getInverseMatrix() once
per frame to get the new view matrix and gives that to the camera. In
order for what you suggest to work, the View would have to call another
manipulator's getMatrix() once per frame and give that to the camera as
projection matrix? Why not just change CameraManipulator to have both
get{Inverse}ViewMatrix() and get{Inverse}ProjectionMatrix()? Seems to me
like you would want the same entity (CameraManipulator) to be
calculating both matrices anyways.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How Camera Manipulators Work
Hi Tom, although I'd hope that anyone writing a CameraManipulator would implement both appropriately, otherwise an interface method is messed up! :) Well yes obviously. But generally getMatrix() can just be written as return osg::Matrix::inverse(getInverseMatrix()); and you're done. Since it's not called by the system it's not that important if it isn't very optimal... And actually the base class CameraManipulator::getMatrix() could do this by default, and then subclasses would only need to implement it if they knew they had to do better. But we're talking details here. Am I correct in thinking you are advocating an approach that blends these two concepts? Yes, well, advocating might be a strong word. I'm saying that conceptually, it would make sense that a CameraManipulator would be able to manipulate a camera in all ways necessary. But I'm not saying I want to do anything about it! :-) In our software, we do something like what you describe, blending camera manipulators and an update callback on the camera. We have a data class that contains all settings we would want to be able to change on a camera. Our software can store multiple instances of this, which will represent different cameras we can switch to, but only one will be active for a given view at a time. Both the update callback and the manipulator have a pointer to the active camera data object, and they both apply the settings in this class when either we switch cameras or change the data inside this object at runtime, and make sure the data is up to date inside the object when the user alters the view using the camera manipulator. The whole thing involves more classes than I think should be necessary, and it's a bit invasive, but it works well enough. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How Camera Manipulators Work
Hi Tom, [...] so that next time getMatrix() is called, the updated matrix reflects the changes that were made. That's almost right - getInverseMatrix() is the method that's called by the view(er) each frame. ;-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How Camera Manipulators Work
Hi Eduardo,
I think the function the original poster is looking for is, e.g.: bool
DriveManipulator::calcMovement().
Well, that method and the equivalents in other manipulators do calculate
some parts of the final camera view matrix, but the final calculations
are done directly inside the get{Inverse}Matrix() methods. And I think
the OP was specifically asking how the manipulator affected the camera,
since no part of the camera manipulator code actually ever touches any
part of the view or camera...
So the answer is that the view calls getInverseMatrix() at each frame to
get an updated view matrix which it will then give to the camera.
That also has another implication. If you're making a camera manipulator
that needs to modify the projection matrix, then you need to put in some
other mechanism in your own code to get the projection matrix that the
manipulator would calculate to the camera. Because the only thing that
will happen automatically when using a camera manipulator is that
getInverseMatrix() will be called to get an updated view matrix each
frame, nothing will be done about the projection matrix at all. I've
always found that weird... A more general camera manipulator should have
a mechanism to alter any relevant property of the camera, not just the
view matrix... It could even have a pointer to the camera, which IMHO
would have been a more straightforward and clear design, at the cost of
higher coupling.
One example of this would be implementing a camera manipulator for
otho2D views which would implement zooming by altering the
left,right,top,bottom values of the frustum (or even the same principle
for perspective views which would zoom by altering the FOV). This alters
the projection matrix, and you'll have to get that projection matrix
from your manipulator to the camera each frame yourself.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::frame() CPU cost
Hi Werner, Alberto said: This is the common scenario for realtime applications. On the other side for GUI applications, usually the scene is static until the user does something. In that case, you only call frame() after keyboard, mouse, redraw events... and you save all that redundant computations. This is not specific to OSG or OpenGL, but it is a typical difference between realtime and GUI applications. Note though that osgViewer has a setting called run_frame_scheme which you can set using the environment variable OSG_RUN_FRAME_SCHEME to ON_DEMAND or CONTINUOUS, as well as a max frame rate that you can set using the environment variable OSG_RUN_MAX_FRAME_RATE to a frame rate or 0.0 for no capping. There are also functions in OSG's API to set these two things programmatically. More details here: http://blog.openscenegraph.org/?p=134 and here: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/43693 In theory, for realtime applications, you want the frame rate to be 60hz solid, i.e. no frame drops and no spikes over 60hz. This will keep all movement and user input fluid. Generally the best way to ensure this is to enable vsync either in your app or in your video card's driver settings. In effect, as long as your scene is relatively light, capping the frame rate to 60hz using vsync will leave CPU time to spare for other apps. Only if you uncap the frame rate (disable vsync AND set OSG_RUN_MAX_FRAME_RATE=0.0) will your frame rate run loose, drawing many redundant frames and driving your CPU usage to 100% In your case if you're making a modeling app or something where you don't need to render new frames continuously, you could set OSG_RUN_FRAME_SCHEME=ON_DEMAND (or the same setting through the API). When doing this, event handlers (the trackball manipulator for example) should call requestRedraw() when needed, which will make a new frame be rendered. If you have other things that happen which need the scene to be redrawn, I suggest you call requestRedraw() (on your osgViewer::View, osgViewer::Viewer or osgGA::GUIActionAdapter if inside an event handler) as well, so you're doing things in the standard way. That way, you can simply use the viewer in the normal way calling frame() all the time, and it will just do nothing if no requestRedraw() was called since the last frame. I think this is what you were looking for. It's just not the default way OSG works since most of the time it's used for realtime apps (games, simulators, etc.). But it's flexible enough to give you the option to use it the way you want. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple camera 'layers'
Hello Mike, I would like to create a 2D background (can this be done using the main camera? If so how?) I would then like to have other multiple cameras each rendering their own 3D sub scene with a transparent background (how does each camera have a transparent background?) but be able to position the output of the 3D cameras on the 2D background. I was thinking adding all the 3D cameras as slaves to the parent but then I wondered how can I translate the output of each camera on the 2D background. Would I need to put a MatrixTransform above the cameras? If I am adding the 3D cameras as slaves how can I put a MatrixTransform above them? I would do each background by creating a textured quad that fills the view and rendered before everything else with depth write off. Then your idea of slave cameras is good, and for each of your slave cameras you can specify an osg::Viewport that will give, in pixel coordinates, where you want the camera to render inside the main window (the view's master camera will have its viewport set to fill the window). Using RTT for this is overkill IMHO. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG , Qt and osgsimplifier
Hello Sajjad, Any hint ? With only this information, the only hint we can give you is to use the debugger. Running in debug, and enabling exception reporting, the debugger should break exactly where the crash occurs, and you should be able to go up the stack to see the source of the crash and see if you can fix it. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG , Qt and osgsimplifier
Hello Sajjad, Just ran the debugger. and crashes in the following line * viewer.frame(); Are you running a debug build in the debugger? Do you have the debugging symbols for OSG? That specific line is not the site of the crash, it's something that function is doing, so to get to the real source of the crash you need to have debugging symbols and walk down the stack. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please help, linking errors with OpenSceneGraph
Hi Renesis, [...] but now when the program runs I get this runtime error: Code: Windows has triggered a breakpoint in test.exe. This may be due to a corruption of the heap, which indicates a bug in test.exe or any of the DLLs it has loaded. This may also be due to the user pressing F12 while test.exe has focus. The output window may have more diagnostic information. And then it takes me to malloc.c. This is typically because you have compiled your program in debug but have linked to release libraries, or the opposite. If you're compiling your project in debug you need to link to debug libraries (the OSG libraries have a 'd' at the end when they're debug versions) and vice versa. Check that your project matches what you're linking to. This always something to check when compiling with Visual C++. You can search the net or even this mailing list if you want more information on this, it's been discussed at length in the past. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hello Erin, Can you confirm that the 2 examples you mention in your post made it into the 2.9.9 developer release? In the previous post on this thread I mentioned more than 2 examples... Do you mean the osgQtWidgets and osgQtBrowser examples, or the osgViewerQtContext and osgViewerQtWidget examples? In any case, all four are in 2.9.9 (since it is made off the trunk). You just need to configure with Qt in CMake and they should be included in your build. CMake should find your Qt automatically, but if it doesn't or it finds the wrong one, I find putting the right path in the QT_QMAKE_EXECUTABLE variable and pressing Configure again makes it use that path for all other components it needs. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shadows and custom shaders
Hi Michael, So I have been reworking to support the shadows. Does the tex gen coords get stored in the texture matrix? Am I wrong to assume I can still use the fixed-function tex gen coords with a shader? Texture coordinate generation is done by the Vertex stage, so as soon as you start using a vertex shader you need to do tex coord generation for your shadow texture unit too. Check the vertex shaders in src/osgShadow/StandardShadowMap.cpp for guidance. I noticed you said you replaced the OSG shader with your own. Do you happen to know what happens when you stop using an uber-shader to render everything in your scene. My scene has many shaders in the graph. To me it seems like some data might be getting overridden down the traversal of the scene. If you use different shaders on different nodes, you need to do shadow texgen computation (vertex shader) and shadow application (fragment shader) in all of them. You can easily factor out those functions into small shader files that you will include everywhere you use your own shaders. That's what the shaders in StandardShadowMap.cpp do - the main shader declares a DynamicShadow() function and calls it, and the shadow shader defines that function. You can do the same, just write your own main shader, declaring the DynamicShadow() function and calling it, and include the same shadow shader (with the code of DynamicShadow()) in all of them. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shadows and custom shaders
Hi Michael,
Thanks J-S. Yea I finally got it working. I did it by taking over the cull step
of the shadow maps and getting rid of the fixed function tex gen and then
pushing the matrices for the shadow projection into my vertex shaders and doing
the math there.
I think you may have overcomplicated things for yourself a bit... You
dind't have to remove any fixed function state at all, since when you
use shaders it's implicitly replaced by your shader. Also, in the shader
you have everything you need to be able to calculate the texgen already
(care of the TexGen and some other calculations). This is all spelled
out in the shaders at the top of src/osgShadow/StandardShadowMap.cpp, as
I mentioned before.
You have a function called DynamicShadow:
void DynamicShadow( in vec4 ecPosition )
{
// generate coords for shadow mapping
gl_TexCoord[1].s = dot( ecPosition, gl_EyePlaneS[1] );
gl_TexCoord[1].t = dot( ecPosition, gl_EyePlaneT[1] );
gl_TexCoord[1].p = dot( ecPosition, gl_EyePlaneR[1] );
gl_TexCoord[1].q = dot( ecPosition, gl_EyePlaneQ[1] );
}
(the gl_EyePlane* are set up by the TexGen) and you call it like this:
vec4 ecPos = gl_ModelViewMatrix * gl_Vertex;
DynamicShadow( ecPos );
And as I said, you can put the first part in a file that you will add to
every osg::Program you have, in addition to your own shader that will
have the second set of lines in it. Same for the fragment shader,, where
you would do the shadowmap lookup using the texcoords that were
calculated above in the vertex shader. That way you're not duplicating
much code, you're reusing the same file in many places. And you're
working within the system instead of replacing big parts of it, which I
find preferable since it's less prone to break later on if OSG changes.
Anyways, good to know you have something that works, but I just wanted
to point out that there may be a better way.
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget
Hello Lucie, I use VRJuggler and OSG to create an application on a VR system and I want to use osgWidget. But VRJuggler uses osgUtil::SceneView instead of osgViewer, I wanted to know if it is possible to use osgWidget with osgUtil::SceneView? I don't think anyone has done it yet. osgWidget::WindowManager does its setup using an osgViewer::View, but I guess you should be able to derive a class that would do the same thing given an osgUtil::SceneView instead. Have a look at what osgWidget::WindowManager does in its code. Once you have osgWidget::WindowManager working with osgUtil::SceneView, everything else should work, since from there Widgets and Windows are just scene graph classes (Group, Transform, Geode) specialized to do things in 2D and in a widget-toolkit-like way. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget
Hello Lucie, In fact, I succeed to display widgets with osgUtil::SceneView replacing the first parameter osgViewer::View by 0 in osgWidget::WindowManager. I use my application in an immersive system (two screens) but my problem is that the widgets appears in each window representing each screen of my immersive system. I want to display widgets in a particular window but not all windows. I don't know how to do this. Do you have an idea? There are a few ways to do this. I assume you are currently adding the WindowManager's ortho camera under the root of your scene graph? 1. You could add the WindowManager's ortho camera directly under one camera (the one for the view you want to see your widgets in). Since it's not under your scene root, other cameras won't see it. 2. You could still add the ortho camera where you do now, and use node and traversal masks so that only one camera will see the widgets. 3. You could add a cull callback to the ortho camera, in which you would check the current camera (in the osgUtil::CullVisitor that is passed to the callback) and only call the traverse() method if it's the camera you want (by name, by pointer, or whatever test you want). There may be other ways. I would generally either do 1 or 3, I wouldn't use node masks, because you only have 32 bits in a node mask and if you use them for other things you may run out of bits quickly. But whenever you want to see some things in one view (screen, window, camera) but not the other one(s), it's the same thing. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget
Hi Jeremy, In fact, I had always lamented the WindowManager's need for a View pointer, but I needed to use it for picking and so it developed thusly. I can look at replacing this dependency with manually running an intersector from the camera. If this is the only need for a View, it should be easy to overcome. I'll put this on my Todo list :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget
Hello Lucie, Indeed, I put the WindowManager's ortho camera under the root of my scene graph. With VRJuggler, I can't access to the cameras because the cameras aren't included in the scene graph. So I don't know how to do this. Would you have other suggestions? The SceneView has a getCamera() method. That's what I meant. In OSG rendering, the rendering always starts at a camera. If you do viewer-setSceneData(root) or sceneView-setSceneData(root), your root node is being added as child of that camera, which is thus called the viewer's main camera. You may have other cameras in the scene graph (like osgWidget's ortho camera, or HUD cameras, etc.). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Light effect in osgOcean
Hello Adrien, So why using an OceanScene disable my lighting effects ?? osgOcean uses shaders for most of its effects, and these shaders assume directional lights. You will have to customize the shaders to do the right calculations for all types of light source. This is not a trivial topic and will require you to get acquainted with writing GLSL shaders and also to modify the code of osgOcean and recompile it. To make osgOcean use your customized shaders you have two options. 1. Modify the shaders embedded in the osgOcean source code and recompile osgOcean. 2. Modify the shaders in osgOcean's resource directory and disable the USE_LOCAL_SHADERS define in the osgOcean source code and recompile osgOcean. I've been thinking of removing the USE_LOCAL_SHADERS define in osgOcean. Currently osgOcean will use shaders embedded in its source code if USE_LOCAL_SHADERS==1, and will load shaders from files if it's ==0. I think a more useful way would be to just make it try to load shaders from files (from the current directory, then OSG's data file path list, as is OSG standard) and if they're not found, use the shaders embedded in the source. This will allow apps to easily customize shaders without recompiling by just distributing the shaders with the app, and if they just need the default shaders they can not distribute them and the default ones from the source code will be used, all without recompiling. I'll try to get around to doing this soon. Also I haven't heard from Kim Bale in a very long time, so I may try to make a release of osgOcean soon with the modifications I've made since the last release. It's been a while now. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] error loading an ive file with OSG 2.8.3
Hi Gianni, FindFileInPath() : USING X:\blablabla\osgplugins-2.8.3\osgdb_ived.dll DynamicLibrary::failed loading osgPlugins-2.8.3\osgdb_ived.dll Yeah, when it gets to that point OSG doesn't give you much information as to WHY it failed loading the plugin... Did you try doing a profile run in Dependency Walker? It might be able to give you more information as to why that plugin cannot be loaded correctly. Perhaps it's a manifest problem, or something obscure like that... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgOcean] Light effect in osgOcean
Hello Adrien, Thank for your reply, but that is exacly what I would'nt want to read ! I am affraid about learning gl Shading Language. Hehe, sorry about that! But you'll see you can do lots of great things pretty easily once you've learned GLSL. It opens up a great new world. :-) Do you know some cool resources to learn it ? I have got the OpenGL Super Bible 4th edition, is it enough ? I would recommend the OpenGL Shading Language (orange book) by Randi Rost, it has a chapter about replicating OpenGL fixed pipeline in shaders which will be useful to you. Also this site is well done, though some parts are obsolete. http://www.lighthouse3d.com/opengl/glsl/ And you can get ShaderGen (which was made by 3DLabs but is not distributed anymore, but can be downloaded from http://www.mew.cx/glsl/) which can generate shaders that replicate the fixed pipeline. It has a GUI where you select which features you need and then it gives you the corresponding GLSL shader. Though you'll have to be careful to keep the parts that are specific to osgOcean in place when you edit its shaders. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] shadows and custom shaders
Hello Michael, If I am implementing custom vertex shaders should I be overriding the ShadowMap and not allowing that TexGen to be created and then generate the proper texture coordinates in my vertex shader? At this point I think all that is missing is the proper texture coordinates for shadows to be working for me. Your intuition is correct, but you just need to calculate the shadow texture coordinates for the shadow texture unit. No need to disable the osg::TexGen because since it's fixed-function state, it will just be ignored when using a vertex shader. As has been said before, once you start using shaders for a given stage you need to do everything the fixed pipeline would have done for you in your shader for that stage yourself (at least, what you need). That includes fog, texgen, etc. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Postbuild error with ot11-OpenThreads??
Hi Frank, My problem is a bit different. I'm running VS2010 as Administrator, but it still doesn't work. When I look at the above folder path, all it has are PDBs. In my case, that is not the correct path. The correct path is: C:/Development/OpenSceneGraph-2.8.3/VS2010/bin/Release/ All of my DLLs, etc., are in that path. They are not in the folder that the cmake install step is looking in. I don't know how to get them to build into the path that the cmake install step is looking for them in (aside from manually editing each project file by hand). Does anyone have any advice? IIRC, this was caused by a bug in CMake when generating VS2010 projects. People on the list found two possible solutions: 1. Upgrade to a more recent version of CMake, I think the bug is resolved now. 2. Generate for VS2008 instead of VS2010. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] StateSet setAttribute(Material) question
Hi Tom, Anybody out there have suggestions of a Windows process memory usage tracker that would be good to use? Try Process Explorer. In the process list, right-click on your app and select Properties, and you'll be able to see detailed CPU and memory usage graphs and stats specific to that process (so it isn't drowned in info from all processes on your machine). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] error loading an ive file with OSG 2.8.3
Hi Gianni, I can't understand that since I put the required osg dll, including the ive.dll, in the same dir of the exe file and moreover I added that dir to the PATH env. variable. What else should I do to make my app find the ive plugin dll? set OSG_NOTIFY_LEVEL=DEBUG and then run your app. You will see lots of debugging messages, and OSG will tell you where it looked for the ive plugin... In general, either putting the plugin in your app's directory or a directory in the PATH is enough. But make sure if you're running the app in debug, that the debug plugin is in the right place... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?
Hi all, A bit of a general question, does anyone know how to run an OpenGL program with mesa instead of the platform's OpenGL driver? Is it supposed to require a recompile? I want to run osgviewer using mesa to compare this with my machine's OpenGL drivers. I'm doing this on MacOS X, BTW, compiled by configuring in CMake to build with makefiles. I tried two things, without recompiling (i.e. compiling with the platform's OpenGL but using mesa at runtime) and recompiling (i.e. using mesa both at compilation and at runtime), and I'm getting the same results for both... I set: $LD_LIBRARY_PATH=(mesa lib path):$LD_LIBRARY_PATH $DYLD_LIBRARY_PATH=(mesa lib path):$DYLD_LIBRARY_PATH so that osgviewer finds the mesa .so's first before the platform-installed ones, but then I get this message: $ osgversion dyld: Symbol not found: _gll_noop Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Expected in: /sw/lib/mesa/libGL.1.dylib in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Trace/BPT trap $ osgviewer --window 50 50 800 600 cow.osg dyld: Symbol not found: _gll_noop Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Expected in: /sw/lib/mesa/libGL.1.dylib in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Trace/BPT trap It looks like the binary is still looking for OpenGL in /System/Library/Frameworks/OpenGL.framework (in both cases), which I would have thought wouldn't happen if I compile with mesa... And it also looks like the mesa lib is missing a symbol... In the CMake window, I can't see any reference to /System/Library/Frameworks/OpenGL.framework (I've replaced all of them with the equivalent mesa libs/include paths). I'm pretty novice at Linux/Unix development, I'm sure there's a way to check which shared libraries an executable will look for at runtime? Another detail, the mesa I'm using was downloaded with fink, it's version 7.0.2-2. It's from November 2007. Perhaps I should uninstall that and build mesa 7.8.2 (June 2010) from source? I think I'll do this while I wait for a reply on this thread. Nov 2007 seems a really long time ago :-) Has anyone done this? Could anyone offer some guidance? Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Composite Viewer in WxWidgets
Hello Micha, is there a way to integrate only one view of a CompositeViewer within the WxWidgets-Application (Canvas), but let the other views standalone? The thing is, that the other views should be fullscreen. Yes, just create a standard graphics context (not GraphicsWindowEmbedded or setting inherited window on the traits) however you want (windowed, fullscreen, whatever) and set it to the camera of your additional views which you want standalone. You can look at the code for osgViewer::View::setUpViewOnSingleScreen(), setUpViewAcrossAllScreens(), setUpViewInWindow() etc. for inspiration. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?
Hi Alberto, I don't know why is it different on Mac, but on Linux just setting the LD_LIBRARY_PATH as you did is the way to go, since both libraries must have the same ABI. For example, when one installs the nVidia libraries on Linux, the installer just substitutes the old ones (e.g. Mesa) by the new accelerated .so's. Interesting, good to know. It seemed to work except for the missing symbol, so I'm now just trying to compile a more recent Mesa myself to see if that will work. I will rebuild OSG with the platform-default OpenGL and try changing the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH to use Mesa since that's supposed to work. Thanks for the pointers. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Keypress broken since rev 11749
Hi Brad, Robert- One issue with including both the translated and untranslated keys in the event is that there is not a one to one mapping. In windows sometimes 3 key presses will translate to one WM_CHAR (translated key) message and they don’t even need to be pressed at the same time (in the case of dead keys). Whereas I believe there is a one-to-one between WM_KEYDOWN and key presses… I don't think that's a problem, in that case there will be 3 keydown events: - the first two would have an untranslated key code but the translated code would be invalid (say -1 so the app can recognize it and just do nothing if it only wants translated codes) - and the third event would have both a translated and untranslated codes (both would be valid). Thus apps that want raw keypresses could get them, and apps (or osgWidget::Input) that need translated keys could just ignore keypresses where the translated code is invalid. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Keypress broken since rev 11749
Hi Brad, JS- However I am wary of the issue where the WM_KEYDOWN is received and WM_CHAR is not (as in my case). In this case how do you handle what you are proposing? I didn't think at all of implementation issues, I was just thinking high level - modifying the existing events to try and make them flexible enough to express both user needs. I'll leave implementation issues to whoever implements it :-) Another option would be to make separate keydown and char events (like windows has). It sounds like this would be a lot of work. Also I’m not sure how other OSs handle this… I think Robert clearly stated he would like to avoid introducing a new event type for translated keys. Though if the arguments are good enough I'm sure he'd change his mind. :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Running an OpenGL program with mesa instead of the platform's OpenGL driver?
Hi Jordi, Did you try LD_PRELOAD? Something like 'export LD_PRELOAD=/usr/lib/mesa/libGL.so' May be it can do the trick.. Seems like the MacOSX version of LD_PRELOAD is DYLD_INSERT_LIBRARIES. So having built a recent mesa now, I tried: DYLD_INSERT_LIBRARIES=...path/to/libGL.dylib osgversion and I get the same message: dyld: Symbol not found: _gll_noop Referenced from: /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Expected in: /sw/lib/mesa/libGL.1.dylib in /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL Trace/BPT trap I can run with DYLD_PRINT_LIBRARIES=YES and I see each library that's loaded. The problem seems to come from the fact that the QuartzCore library (and others) depends on other libraries that are in the OpenGL.framework, so it loads that all the time, even if I want to use Mesa in its place. Seems to me there's too much magic going on behind the scenes for Mesa to be usable under MacOS X. Other libraries (including the window system) depend on OpenGL and shared libraries are being loaded from other places on the system... Unless someone with more knowledge than me in this area could help, I'm stuck. :-( J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developer release, please test :-)
Hi guys, There is still a bad flicker when, in osgViewer, I drag with the mouse in one screen, stop the drag, and restart in the other screen. No flicker as long as drags occur in the same screen. Well, it's a step in the right direction at least, and bodes well for upcoming versions of the drivers. Thanks for continuing to report your experiences with the recent driver versions. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Keypress broken since rev 11749
Hi Robert, I'm not clear on what solution should be used going forward. The GraphicsWindowWin32.cpp code had been in play for a few years without problems being reported on this topic and to get a report or new problem after merging Vivien's changes make me concerned that we may have broken more apps usage than might have fixed. Could this be the case? Or is Brad's experience unique? I think Nick's message shows that it may be Brad's app's message passing that's the cause of his problem. If the osgViewerMFC example works, and it demonstrates proper integration between OSG and MFC, and furthermore, the other OSG examples and apps that come with it work fine on Windows (when GraphicsWindowWin32 is used) then I think the changes to GraphicsWindowWin32 are OK. I'm inclined for the 2.9.9 dev release to revert the changes, and then let us discuss possible solutions. I don't think that's necessary at this point. As I said above, the changes seem fine. There may be other changes going forward, for sure, but I think the code is safe as it is. In the past we've talked about the idea of having raw key codes as well as translated keycodes in the GUIEventAdapter, would this help here? Perhaps, the raw key codes would be the keyup and keydown messages from the OS, and the translated code would be the accented character in the case dead keys were being used. Brad gave an example of a game that wants to check a given key directly, it would use the raw key codes, and a text editor/e-mail app (or osgWidget::Input) would use the translated key code. It would be a flexible solution. Now, where will we find a developer to implement this? :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Keypress broken since rev 11749
Hello Brad, A different question, is why is the code written this way? I mean as I understand in windows you get a WM_KEYDOWN msg for all keys and then if it is a character you later get a WM_CHAR (possible multiple depending on key repeat?) and then when the user releases the key you get a WM_KEYUP. That's my understanding anyway. The current osg implementation seems more convoluted..? You're right, it seems a bit weird. I'm not that familiar with Windows programming though, and since with the change keys still work in osgviewer, I can't wrap my head around what's so different that your app no longer works as before. There is another oddity: the change was not committed on its own, but was committed as part of another submission as you can see from the totally unrelated svn log message: From Torben Dannhauer, I extended the attached CMAKE module to search for the collada libraries of my VS2008 3rdParty package if no other library is found. No CMAKE should recognize all libraries of the VS2008 3rdParty Package. That is probably just a result of Robert juggling too many tasks at once, and doesn't matter much, but of course committing each submission separately makes it easier to back out a change that proves to be problematic... I went chasing the change on the mailing list, and it was from this thread: http://www.mail-archive.com/osg-submissi...@lists.openscenegraph.org/msg05940.html You'll notice that Robert said that he can't test changes to Win32 code and asks Windows devs to make sure they work correctly, which I guess is what we're doing now although a bit late :-) So I guess the first step should be to ask the original author of the change (Vivien Delage) what he was trying to fix with his change (I can't quite understand from quick reading the messages and the code, and don't have time to go into detail right now), and then figure out why it fixes something for him but breaks something for you. Then you could agree on a fix that resolves the issue for both - be it to amend the submission in the OSG code or do things differently in your own app, as long as you agree and it's reasonably certain that other users won't trip on the same issue in the future. Since the problem doesn't seem to affect osgviewer I think it's safe to keep it committed for now until you and Vivien can figure out which way to go. I'll be monitoring the thread, hoping it will be resolved soon. Send any change to osg-submissions once you're done. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Replacing a node on the fly (same issue, new thread)
Hi Werner,
The changes are to complex to be visualized by using the old Geode and doing
transforms and vertex manipulations.
I don't think the changes are too complex... Why can't you just resize
the vertex/normal/... arrays, and fill them with the new data? To be
precise: all you would change in your code is not create new
Geode/Geometry, and not replace any scene graph nodes - the filling of
vertex/normal/... arrays would be left the same as it is now.
For example:
//... constructor
m_geode = new osg::Geode;
m_geometry = new osg::Geometry;
m_geode-addDrawable(m_geometry.get());
m_vertexArray = new osg::Vec3Array; // initially empty
m_geometry-setVertexArray(m_vertexArray.get());
// same for other arrays
// set up render state etc.
m_geometry-setUseDisplayList(false);
m_geometry-setDataVariance(osg::Object::DYNAMIC);
//... per-frame update (update callback for example)
if (m_vertexArray-size() number_of_vertices_we_need)
{
m_vertexArray-resize(number_of_vertices_we_need);
}
// same for other arrays
// copy vertex, normal and other data
// add/modify primitive sets if needed
We do this for other things (dynamic terrain, cable display) and it
works well as long as you flag your osg::Geometry object as DYNAMIC.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Preparing for OpenSceneGraph-2.9.9 developer release, please test :-)
Hi Torben, Dženan, Robert, please read this thread: http://forum.openscenegraph.org/viewtopic.php?t=6526highlight= more people including me have the black screen problem, it seems to be a driver issue. Indeed, and without any solution yet. It's not annoying enough to me that I would go out of my way to find a solution, someone with the inclination could work on finding a solution and I'd be happy though. I just set OSG_WINDOW=x y w h or use --window x y w h. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Keypress broken since rev 11749
Hi Vivien, Thanks for replying, it's good to know why the change was needed. I did it in order to fix an issue with dead keys that were not handled correctly. Dead keys are used for key combination. For example in French keyboard pressing '^' key then after that 'u' key should result in the character 'û'. This was not working properly with osg. I didn't know that, I'm a native French speaker but I rarely use French when I use my computer (just how I've always done it) and I've never tried to use accented characters in an OSG app. I guess with osgWidget::Input now it becomes possible and desirable for some apps, so I understand the need for your change. If you were to make an OSG-based e-mail or IM client I would probably need to use accented characters in it too :-) Now the real question is why you do not receive the event WM_CHAR on your application. Any idea on that? Brad, how are you using the osgViewer::GraphicsWindowWin32? Is it in a normal osgViewer window? Is it in a Qt or other GUI toolkit window? If that's the case then perhaps the GUI toolkit is not redirecting all its Windows messages to the GraphicsWindow correctly? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] error loading an ive file with OSG 2.8.3
Hello Gianni, is there any known issue related to the ive plug-in in OSG 2.8.3? I tried to load the same ive with OSG 2.8.2 and it works fine. I can load correctly obj files with 2.8.3 but the ive does not work. Any idea? We have been using 2.8.3 since it came out and have had no problems loading ive files with it. I'm afraid you'll have to run in a debugger and see what's going on more in-depth. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Keypress broken since rev 11749
Hi Brad, It appears that with the changes to GraphicsWindowWin32.cpp at rev 11749 that keypress does not get called when one hits a “non special” key (eg one of the letter keys). If I understand correctly, non-special keys are no longer totally handled from WM_KEYDOWN and they are supposed to use WM_CHAR or something. This does not appear to work. I’ll keep looking, but perhaps someone else has already noticed the bug/fix? From your description above, it makes me think that in osgviewer, the normal keys shouldn't work, for example pressing 's' shouldn't show the onscreen stats (since the StatsHandler does its work on osgGA::GUIEventAdapter::KEYDOWN events). But it still does, with an OSG compiled last night (Windows 7 64-bit, Visual C++ 2008 sp1 32-bit build). Can you be more specific on what I would need to do to see this problem? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Don, I'm using TortoiseSVN on a Windows system. This has a right-click menu entry for SVN Checkout. The GUI can only handle the URL and was confused by the spaceOpenSceneGraph after trunk. Heh, that's the destination directory when using the command-line SVN... So you're right, in Tortoise you just need the URL, which was http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Digital Learning Foundation?
Hi Robert, The DLF secured funding for the development of osgVolume, this work I was commissioned to undertake. The DLF continue to seek a further round of funding for further development of osgVolume and Present3D, if we can achieve this then I'll be again commissioned to put the requirements into code ;-) Ok, thanks for clearing this up. There seems to be a large number of startups these days that are set up only to sell products entirely based on open source code without giving proper credit or distributing their modifications, hoping no one ever picks up on their GPL/LGPL/other license violations. Good to see this wasn't such a case. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Digital Learning Foundation?
Hi Robert, all, Searching for osgVolume info yesterday, I found this site: http://dlfresources.pbworks.com/donations%20Open%20Source Seems they ask for donations for supporting osgVolume, Present3D and other OSG related things. I was wondering, did they actually do any work on these projects? Or are they sending their donation money to you, Robert? It seems to me like they're solliciting donations for work that they didn't do (and that's open source). But I may be mistaken. Thoughts? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgVolume
Hi all, See screenshot for the result in osgVolume. Pretty darn cool. :-) Oops, sorry, I hadn't realized that my screenshot was so big. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] BIND_PER_PRIMITIVE broken?
Hi Don, I bailed on my svn import. TortoiseSVN wouldn't work with the checkout command as documented. I got the checkout going, but I seemed to be getting way more than I wanted. After more time than I had to spend I still didn't have the OSG source. What command did you try? This page gives you the command you should have been using: http://www.openscenegraph.org/projects/osg/wiki/Downloads/SVN which is: svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph That gets you only the trunk source tree, i.e. what you need. It should be a pretty speedy checkout, at least it is whenever I do it on a new machine (which I've done a few times in the past month or two). I would understand it taking a lot of time if you had removed one or especially two levels from the path, i.e. if you did svn checkout http://www.openscenegraph.org/svn/osg/OpenSceneGraph/ That would checkout all the branches, tags and trunk, i.e. it would take an eternity and a half, in addition to taking more disk space than you probably have... SVN branches and tags are shallow copies unless something changes, so they're lightweight on the server, but as soon as you download them on your machine they take the full size of all files. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] can't find plugins at runtime
Hi Davide, running the profiling on my system shows more missing dlls than running it on the system where the app doesn't work... so i can't supply those dlls, and anyway i expect it to run also without them, because that's what happens on my system. dependency walker sometimes reports false positives, so dlls missing where they don't make any difference. But you can't just say it's missing more dlls on my dev machine than on my deployment machine, so it must be ok... You have to look at which dlls are missing, and see which are needed. For example, if the plugin that's not loading is the png plugin. This plugin also requires the libpng*.dll to be found, in addition to the plugin itself (osgdb_png.dll). That's what others meant by a missing third party dependency. And that's the kind of thing dependency walker will tell you if you run it in profile mode and try to open a model that has a png texture, when the png plugin fails to load. ironically, osgwhich doesn't come in binary, and compiling it myself and copying it on the target system results in another missing dll problem... You really need to start being more critical about the errors you get. Just saying it doesn't work or a dll is missing isn't going to get you anywhere. On Linux, if an app says can't find libpng.so.1.3 then what do you do? Do you just say to hell with it, it doesn't work? Or do you look at your LD_LIBRARY_PATH, try to find the .so it needs, and if you don't have it on your system go compile and install it? Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgQt error
Hello Lucie, When I compile osgQt, I have this error : 1moc_QGraphicsViewAdapter.cxx 1.\__\__\include\osgQt\moc_QGraphicsViewAdapter.cxx(11) : fatal error C1189: #error : The header file 'QGraphicsViewAdapter' doesn't includeQObject. How do I solve it? Is this on trunk updated today? Which OS/compiler? (seems Visual Studio but which version?) Try adding the required header, though I didn't need it and I'm also on Windows... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Red FPS indicator
Hello Frank, Sorry to bother you with such a simple question, but somehow I ended up with a red FPS indicator in the lower-left portion of my screen, and I have no idea how it got there! Does anyone know how to remove it? Is it possible you installed an OpenGL performance monitoring tool like Fraps for example? I know Fraps, if it is set to load at startup, will put an fps indicator in any OpenGL window (unless you configure it not to, but it defaults to on). Check your startup programs, things like that... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX Outline Patch
Hello Todd, While we are on the topic of the Outline class, I'm experiencing something strange: My application crashes on exit with an unknown exception if an osgFX::Outline node is in the scenegraph, but it doesn't crash otherwise. I haven't been able to trace this, so I was wondering if anyone else had a similar experience. This is on Windows. Does osgoutline cow.osg work for you? If so, then you'll have to run your code in debug and in the debugger, in order to find the source of the crash. Crashes are actually pretty much the simplest bugs to find the source of, since the debugger will immediately point the place where it crashed... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX Outline Patch
Hi Todd, So far, this crash seems to be an odd one because the debugger doesn't seem to catch it. All I get is this friendly message: The exception unknown software exception (0xc0020001) occurred in the application at location 0x7c812afb In Visual Studio, enable all exceptions by going to Debug - Exceptions... and checking all the boxes. Then the debugger should catch the exception and break at the point where it was thrown. You can then go a few levels up the stack to pinpoint the cause. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX Outline Patch
Hi Todd, Thanks for the suggestions. I just tried that, and unfortunately this particular exception seems to occur *after* exit. It seems to be this error: http://social.msdn.microsoft.com/Forums/en-US/vblanguage/thread/afebacc2-65e6-43f8-b7aa-73bfd5ade11d Anyway, thanks again. I'm pretty sure this isn't an OSG problem, but I'll post an update if it turns out to be one. Well that post relates to VB garbage collection and Crystal Reports, so I'm pretty sure it's not related :-) A crash on exit is generally a double-delete... Are you using ref_ptrs for all your OSG variables? Or are you doing weird things with memory allocation? Small anecdote on that subject: A while ago we had a class in our code base that derived from an OSG class (so from osg::Referenced indirectly) but declared its destructor public. So users of that class could delete it while it was still in the scene graph, and when OSG (through ref counts falling to 0 and cascading deletes of ref_ptrs) came to delete it, it had already been deleted, thus the app crashed on exit. So making the destructor of an osg::Referenced-derived class public is a no-no, unless you can make sure to remove it from all OSG structures before you delete it (which is a lot of work for not much gain, IMHO, so just keep that destructor protected and all will be fine). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] can't find plugins at runtime
Hi Davide, as for dependency walker, i've found some missing dlls and i copied them over. dependency walker doesn't complain anymore, but the application doesn't work... so i'm blind again here too... Since plugins are loaded at runtime and not when the application initially starts (so-called delay-loaded dynamic libraries), dependency walker won't show errors related to them initially, but you have to start a Profiling run within dependency walker. If you do that, your app will start and dependency walker will be able to tell you if the plugins can be loaded correctly. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issue with osgOcean on MacOSX GeForce 7300 GT
Bonjour Jean-Claude, I have been able to run osgOcean by modifying the shaders, but the frame rate was not acceptable (15 FPS). I have also applied the patch to Texture.cpp, but it didn't resolve the FBO errors. Given the framerate is too low, I stop trying to run the software on that graphics card. I have used osgOcean on a 7900GTX in the past, and performance was acceptable, but not great. The 7900GTX is the high-end card of the 7000 line, whereas the 7300GT is on the low end, so your results don't surprise me. You could probably get better results if you're willing to lower the resolution of the mesh osgOcean generates. Have a look at the parameters to the constructor of FFTOceanSurface. Plus, you'll probably want to disable all effects (reflection, refraction, silt, god rays, depth of field, etc.) and remove the shaders altogether. Doing this, I have been able to get acceptable performance even on laptop integrated chipsets... Of course then it doesn't look so great, but the client required any ocean representation, and it's better than a blue flat plane. ;-) So if you're willing to do some testing, disabling things and re-enabling them to find your sweet spot, you should be able to use osgOcean on most graphics hardware. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgFX Outline Patch
Hello Florian, Note the attached image. The first chair has no effect, the second chair has the outline effect, and the third chair has the scribe effect. As you can see with the middle chair, the legs seem to be working but then the seats polygon lines get exposed? May this be an issue due to using 2.8.3 ? You need to enable the stencil buffer when you create your graphics context in order for the outline effect to work correctly. If this is not done you'll get the problem you have (sometimes internal polygons are shown, sometimes not, depending on order of drawing). You should be able to use osg::DisplaySettings::instance()-setMinimumNumStencilBits(8); before creating your viewer/window/context to do this, or modify the traits you pass to createGraphicsContext() if you're creating it yourself. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi Wojtek, Going back to the subject, I just tested Catalyst 10.8 today and was pleasantly surprised that some bugs were not present anymore. So driven by this small succes, I went further and also installed newest non-WHQL NVidia 259.31 drivers (Windows 7 64 bit). They are available through NVidia OpenGL DeveloperRelations portal. And these drivers also seem to work correctly as pre 256 driver series. At least my pixel lighting shaders compile again. So it looks like NVidia guys fixed the bug while we were complaining ; - ). You may check if theses drivers work for You. Great, thanks for the update! That's good news on both fronts. I actually had a co-worker who asked about problems with ATI drivers and shadows lately and also replied that 10.8 fixed it for him too. But the workaround I have for the nvidia issue I think I'll keep, as unrolling the loop and using the preprocessor instead of a for loop can potentially be faster on older cards... Even if it's ugly and harder to read... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi Wojtek, In the meantime I changed the code to use my own (non gl_) uniforms and this also seems to work. However, instead of array of LightStructs I rather use a set of arrays each containing single light attribute (for example diffuse) for all lights. I did it because it allows for better use of uniform memory. Yes, that strategy was also suggested on one of the forum threads I read about the problem. http://www.gamedev.net/community/forums/topic.asp?topic_id=578784whichpage=1#3688129 Actually someone on that thread said that bugs in deprecated functionality were likely to appear often, which to me suggests that nVidia might never fix this bug because it relates to built-in uniforms which are deprecated, and just using your own uniforms instead of gl_LightSource[] works fine, so why should they fix a deprecated feature? I actually wonder how true that is, based on this text that can be found on nVidia's site (http://developer.nvidia.com/object/opengl_driver.html) : - 4) Is NVIDIA going to remove functionality from OpenGL in the future? NVIDIA has no interest in removing any feature from OpenGL that our ISVs rely on. NVIDIA believes in providing maximum functionality with minimal churn to developers. Hence, NVIDIA fully supports the ARB_compatibility extension and Compatibility profile, and is shipping OpenGL drivers without any functionality removed, including any functionality that is marked deprecated. 5) Will existing applications still work on current and future shipping hardware? NVIDIA has no plans for dropping support for any version of OpenGL on our existing and future shipping hardware. As a result, all currently shipping applications will continue to work on NVIDIA's existing and future hardware. - But then again, that text might just be PR speak and wishful thinking. If some feature is deprecated (OpenGL 2.x, built-in uniforms, etc.), and less developers are using it over time, how many resources are they likely to devote to fixing bugs that appear in that feature? Of course, from the version number jump, we might assume that nVidia did some big work on their drivers lately, maybe even a rewrite of some or all of them. If that's the case, then they might have had to rewrite the deprecated parts too, and since they most likely tested these parts less than the others, it could explain why we see some bugs in it at this point. This is all conjecture on my part of course, but this kind of thing happens pretty often in development projects... What do you think? I don't know what to think at this point, but since we have an acceptable workaround I'm not too concerned. I just hope the situation doesn't go downhill from here (at least not before OSG has a good transition path to OpenGL 3+ that we can use). In any case, let us know if you ever get news from the bug report you sent. In the past when I've reported bugs they've been rather quick to respond, but maybe that has changed too... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hi Andrew, I've used Qt under Windows and it appears to be quite stable with the OSG environment; I'm concerned with Qt + OSG stability under Mac. Has anyone successfully used this combination out there? I've been working on osgQtBrowser and osgQtWidgets (and the classes they demonstrate - QGraphicsViewAdapter, QWidgetImage and QWebViewImage) lately, but haven't used them on a Mac (or used a Mac at all, really :-) ). They're still work in progress even on Windows, so there may be stability issues I haven't found yet (and actually I've recently fixed a threading issue in their use that I'll submit back soon). So I'm afraid I can't help much. If you can build them in debug, and try running them in the debugger, you should be able to find the source of the crash pretty easily (crash bugs are generally easy to find and fix). Sorry I can't help more, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi Wojtek, I think that breaking gl_LightSource usage in fragment shaders is actually a major problem. On this forum there are three of us who admitted it affected them. Probably few more did not mention it. How many OpenGL developers outside OSG community do pixel lighting ? I bet there thousands if not tens of thousands who were or can be affected in the future. I agree, and in fact in my case the error happened in a vertex shader when doing a loop over light sources to do per-vertex lighting, so it's not just limited to per-pixel lighting shaders. I bet any code that loops over gl_LightSource[] in any shader will cause this error. I also agree with your other points. Hopefully soon OSG will allow us to choose which path we use, OpenGL 2.x or OpenGL 3.x+/4.x, and will help ease our transition. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.9.9 compile issues on Mac with Qt 4.6.3, other Qt issues
Hello Andrew, The Qt integration with Delta3D 2.3.0 under Windows is incredibly stable, so perhaps this should be something to have a look at (I speak from experience on using this package with Qt). Delta3D uses OpenSceneGraph for its rendering (see the particle editor example). However, I don't want to use Delta3D anymore as it is much larger than OSG itself and it isn't support on Mac. Well, it depends on what you mean by Qt integration - there are two angles: 1. Integrate an OSG window in a Qt window (i.e. have an OSG window inside your widget, and let it do its thing) 2. Integrate Qt widgets inside an OSG window (i.e. have Qt widgets as part of your scene). The osgQtWidgets and osgQtBrowser examples (and their component classes) implement number 2, and the osgViewerQT* examples implement number 1. Last I checked, Delta3D only implemented number 1, but some users were trying to implement number 2. What I'm working to improve is performance. The way Delta3D does its window integration (number 1) makes Qt drive the OSG rendering, so you lose all parallelism between OSG and Qt. Note that the osgViewerQtContext and osgViewerQtWidget also have this problem - anytime you have a Qt widget's repaint or a Qt timer calling viewer.frame(), that's bad IMHO. And the way the user I saw on a forum was proposing to implement number 2 was along the same lines. I currently have an implementation of number 1 which lets OSG run loose (completely parallel to Qt) which I have yet to submit, and our implementation of number 2 also lets OSG and Qt run in parallel (minus some locking that needs to occur at the right times, and threading issues that we fix as we find them as I mentioned in my previous post). So I think the stability issues you mention are just part of the evolution of these classes, they need more users to look at them to help make them better. But their low-level approach is better than what I've seen in other places (including what I've seen in Delta3D, but that might have changed). J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hi Nick, nice reading ... :) .. I agree about the DirectX part .. Let start talking to Robert to make OSG DirectX compatible :) -Nick Haven't you been here for a while now? You should know by now that's not going to happen :-) Search the archives if you're interested, this has been discussed in the past. But let's not let this thread go into API wars, please. We're using one API, and this thread just discussed bugs in parts of that API which are deprecated but should still be supported by the vendor in question. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash when GLObjectsVisitor gets to the same texture in several threads at the same time
Hello Robert, It will initialize with the with the DisplaySettings::instance()-getMaxNumberOfGraphicsContexts() value. Exactly, and at that point the max number of graphics contexts is smaller than what it will be since the viewer and contexts haven't been created yet. So it will have to resize eventually. osgViewer should be doing the resizeGLObjectBuffers once it knows how manage contexts it has. But this doesn't solve the issue as you've seen, since not all per context data is resized by resizeGLObjectBuffers(). (it now does with your fix, at least for osg::Texture) This looks like a bug then, resizeGLObjectBuffers should resize all buffers than hold per context data. Thanks for the quick turn-around and review on this. Your conclusion makes sense. But I hope osg::Texture is the only place where this kind of bug was present. It may be that it was just the first one my example tripped upon, and the (heavy-handed) workaround fixed them all... I'm updating and building now. I'll let you know how it goes. Anytime you want to try my code example though, you may see what my usage model is and it may point out other things... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash when GLObjectsVisitor gets to the same texture in several threads at the same time
Hi Robert, Thanks for the quick turn-around and review on this. Your conclusion makes sense. But I hope osg::Texture is the only place where this kind of bug was present. It may be that it was just the first one my example tripped upon, and the (heavy-handed) workaround fixed them all... I've now updated and built, and I think what I said above was right. I'm still getting a crash in the same conditions, but now it's the buffered_object called s_glExtensionSetList (in GLExtensions.cpp) that is being resized in two threads at the same time. Both threads are in osg::isGLExtensionOrVersionSupported() at the same time (first line): ExtensionSet extensionSet = s_glExtensionSetList[contextID]; One thread has contextID = 34 and the other contextID = 35. So the first is trying to resize to 35 and the other to 36 at the same time. This is again as a result of the GLObjectsVisitor being run in multiple threads as a result of osgViewer::Renderer::compile(). So my workaround still works. This is not high priority for me. Even if you fixed this now, we would continue using my workaround until we could update to a stable version of OSG that contains the fix. I know you're busy, so let me suggest something: when you have some time, when you're done with other pressing matters, please run my example code. It shows this quite clearly, and then you could fix things as problems arise instead of going back and forth (it would mean less time spend for both you and I, in the long run). Right now I don't think it's really useful for you to fix one issue, have me test it, fix another one, etc. Thanks a lot, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] latest NVIDIA drivers
Hello Wojtek, I have noticed issues with Shader compilation on 256 (and above) series on Windows 7. Some fragment shaders using gl_LightSource fields were generating internal compiler errors. In fact I also posted a bug report to NVidia. These errors were normally reported by OSG with compilation log showing assembly cg output that was causing trouble for compiler. You don't see any compilation errors even with OSG_NOTIFY_LEVEL=DEBUG_INFO ? I have attached the bug report I posted to NVidia you can check if it could related. We have put back updating our simulators' drivers for this reason. Our lighting shaders did not compile with that same error (binding in multiple relative-addressedarrays). I looked it up last night to try and find a workaround, and found one. If you simply unroll the loop that iterates over lights, it compiles fine. So what you can do is: // Don't forget the backslash at the end of each line except // the last in the define... #define APPLY_LIGHT(i) \ // the code that you had in your loop before \ // that uses gl_LightSource[i]\ // for example: \ // ...\ ambient += attenuation * gl_LightSource[i].ambient; \ // ... APPLY_LIGHT(0) APPLY_LIGHT(1) APPLY_LIGHT(2) APPLY_LIGHT(3) // Up to however many lights you want to support Sure it's just a workaround, I think the behavior you reported to nVidia is still a bug they should fix, but at least this allows us to keep on working even if some clients or users update their drivers. I always hate telling people don't update your drivers to a version newer than x.y, because that shows some incompatibility in our own software and also I may forget to tell them that it's ok to update once the driver bug is fixed, and then they may run into other issues in the future because they have old drivers. Also, I don't have any other loops currently in my code, so I can't say if this same compiler error might affect looping over other variables. See this thread on OpenGL.org for some discussion of this issue. I got the inspiration for the #define above there. http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflatNumber=281429 Someone mentioned in that thread: In the GLSL spec, if you use some of the built in array types (like gl_ClipDistance) you need to either declare the size of the array or make the source code so that the GLSL compiler can figure out the maximum index you access. It might be possible to remove the above workaround if we did what he suggests. But I haven't yet found out how to do that. What I've tried (uniform gl_LightSourceParameters gl_LightSource[gl_MaxLights]; or uniform gl_LightSourceParameters gl_LightSource[8]; at the top of the shader) didn't change anything. I really hope nVidia fixes the bug... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] so big different performance in debug and release?
Hi John, thanks for your reply. yes, I should debug my programm in release mode. No, you should debug in debug, and measure performance in release. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Crash when GLObjectsVisitor gets to the same texture in several threads at the same time
Hi Robert,
If the buffer_value is being resize multi-threaded then this in an
indication that the the buffer isn't a large enough value before
threading started.
Yes, indeed, and this is the case for most uses of OSG. Generally,
you'll load the scene data first (so the buffered_value will be set to
size 0 as you don't have any contexts yet) and only then will you create
your viewer and contexts.
Even if you create your viewer first, you generally won't call realize()
(which creates the contexts) until after all your scene data is loaded,
because otherwise it would show an empty window for the time you're
loading the scene data, which users don't like.
In the mean time have using
DisplaySettings::setMaxNumberOfGraphicsContexts(uint) to make sure
enough contexts are set up are the begging.
I don't think this is feasible, since the number of windows I need is
driven by config files, and I load these with the scene data. So even if
I would call this once I know the value to pass to it, it would already
be too late as the scene data would have been created and the
buffered_values would have been constructed with the old value of
maxNumberOfGraphicsContexts.
But I'll look into it, as it's still a workaround, but a less hacky one.
On try calling
viewer.getSceneData()-resizeGLObjectsBuffers(uint) prior to
restarting the viewer threads.
osg::Texture::resizeGLObjectBuffers() does this:
void Texture::resizeGLObjectBuffers(unsigned int maxSize)
{
_textureObjectBuffer.resize(maxSize);
}
but the value that's being resized by the GLObjectsVisitor is
_texParametersDirtyList, so calling resizeGLObjectBuffers() won't help.
Whenever you have time, please have a look at the code I sent and
(especially) run it. First of all, it will be interesting to see if the
issue is reproduced on Linux, and second if it is, you'll see what I
mean more clearly than trying to explain it by e-mail.
For now I have a workaround, but it's an issue that might affect others.
Though as I understand it not many people do what we do, i.e. run many
scenarios in one run of the same program, so it might not affect many
others, but still...
Thanks in advance,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Getting the List of Triangles from an osg model
Hello Sanat, I was not able to understand this behavior: When I had a vec3Array and I queried it using vec3 = vec3Array-at(0) I would get an exception. Why does it give that exception ? Check the C++ standard, osg::Vec3Array::at() eventually calls std::vector::at() which throws an exception when you try to access something that's past the end of the vector (i.e. not a valid index). You would have seen this if you'd tried to debug the program. When debugging, when you get an exception, you can get the stack trace of where the exception was thrown and thus learn why you got an exception yourself. I needed to use (*Vec3Array)[i] to get each Vec3. But then at i = 14113, I got an Unhandled exception: at 0x00402207 in OSG_examples.exe: 0xC005: Access violation reading location 0x00ba9000. And size has a value much higher = 4176061468 when I query the vec3Array for size I get a very large number and much large than Vec3Array-numElements() size = 4176061468 numElements = 7772 Which of these represents the number of vertices in the model ? I strongly suspect you're acting on a variable that you've casted to Vec3Array without first checking whether it was really a Vec3Array. As I said above, at() checks if the index you pass is valid or not. operator[] does not check, so you can do it even if it's not a valid index... Also the size you get is a value that I would question, seems to me that it's an invalid size as no one would ever make a model for real-time use that has 4 billion vertices. Again, you have your data, so this is something you could have checked by loading the same model in osgviewer, pressing 's' 4 times and looking at the number of vertices, I bet it's lower than 4 billion. The number of vertices in the model is array-size(). And array-at() should always work if the index you pass is under array-size(). So if that's not the case, then you're using an area of memory that isn't the type you think it is, and you better check things better before you cast. Again, please look at previous discussions, someone else was doing very unsafe things lately... You're not doing yourself a favor by casting things without checking and then wondering why you get errors... Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Crash when GLObjectsVisitor gets to the same texture in several threads at the same time
Hello Robert, all,
I'm seeing a crash in our simulator after many scenario loads. The stack
trace differs, but it's always similar to this:
a) Thread A is calling osg::Texture2D::getModifiedCount() for a new
contextID, causing the _modifiedCount variable (which is an
osg::buffered_value) to be resized.
b) At the same time, Thread B is calling
osg::Texture::getTextureParameterDirty() for a new contextID (different
from the one in a), causing the _texParametersDirtyList variable (also
an osg::buffered_value) to be resized.
The osg::Texture and osg::Texture2D in threads A and B are the same
object. But the graphics context for which these operations happen is
different. Both threads are running the osgUtil::GLObjectsVisitor
(starting from osgViewer::Renderer::compile()) when this happens.
The stack trace can differ in the sense that instead of
getModifiedCount(), thread A could be calling applyTexImage2D_load() or
some other method on that same Texture. But getTextureParameterDirty()
is always involved in the other thread from what I've seen. The crash
happens in operator delete in thread B, while trying to resize the
_texParametersDirtyList variable. The crash can happen at the second
scenario load, or at the fifth, or at the 15th. And only if there are
two or more GraphicsContexts running at the same time, so using a single
window doesn't reproduce the problem.
I don't see why doing different things in different threads causes a
problem here, but apparently it does. And in general, running the
GLObjectsVisitor from two different threads, one per context, even if
it's on the same scene, should not cause problems, right?
A workaround I have found is to do the following before the viewer
starts rendering, but after the scene data has been loaded and the
viewer has been realized (so all GraphicsContexts are created):
a) stop the viewer's threads
b) for each graphics context
b.1) make the context current
b.2) run the GLObjectsVisitor on the scene
b.3) release the context
c) start the viewer's threads
This basically forces the GLObjectsVisitor to be run for each context
sequentially instead of in parallel, so any resizes that need to happen
will happen single-threaded. After this, the viewer will re-run the
GLObjectsVisitor, but all resizes will already have been done, so there
is no crash. But I shouldn't have to do this. I feel dirty even having
this kind of workaround in the code :-)
The code example I've included demonstrates this. You'll notice we use
osg::GraphicsContext::incrementContextIDUsageCount() to ensure OSG
doesn't reuse old graphics contexts. This is actually required to
reproduce this crash. Also you'll notice the example creates 8 windows,
but the problem is also present when you have 2 screens and use
setUpViewAcrossAllScreens() on a single view, since then 2 contexts are
created. This is what happens in our app. I've just made it create 8
windows so the crash happens quicker.
In my case, I just run the example and press esc each time the viewer
windows appear, and after a few times (generally less than 5 x 8
windows) I get a crash with the symptoms I gave above. If you uncomment
the ENABLE_WORKAROUND define, and do the same thing, it shouldn't crash
(I've gone to over 30 x 8 windows a few times with no crash).
Note that I have no idea how OS/compiler dependent this is, perhaps it
only happens on Windows when OSG is compiled with Visual Studio, or
something like that. That's actually something I hope others can help me
find out.
Has anyone encountered something similar to this?
Thanks in advance,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
#include osgDB/ReadFile
#include osgViewer/CompositeViewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include iostream
//#define ENABLE_WORKAROUND
void main_func(int argc, char** argv)
{
// load the data
osg::ref_ptrosg::Group root = new osg::Group;
root-addChild(osgDB::readNodeFile(cow.osg));
root-addChild(osgDB::readNodeFile(cessnafire.osg));
root-addChild(osgDB::readNodeFile(lz.osg));
root-addChild(osgDB::readNodeFile(skydome.osg));
osgViewer::CompositeViewer viewer;
for (unsigned int i = 0; i 8; ++i)
{
osgViewer::View* view = new osgViewer::View;
view-setCameraManipulator( new osgGA::TrackballManipulator );
// add the stats handler
view-addEventHandler(new osgViewer::StatsHandler);
view-setSceneData( root.get() );
view-setUpViewInWindow(50+i*10, 50+i*10, 800, 600);
viewer.addView(view);
}
viewer.realize();
#ifdef ENABLE_WORKAROUND
viewer.stopThreading();
#endif
osgViewer::CompositeViewer::Cameras cameras;
viewer.getCameras(cameras, false);
for
Re: [osg-users] Getting the List of Triangles from an osg model
Hello Sanat, num1 = cow-asGroup()-getChild(0)-asGeode()-getNumDrawables(); num2 = cow-asGroup()-getNumChildren(); num3 = cow-asGeode()-getNumDrawables(); This line makes no sense. You have confirmed in the line before that cow is a Group, why do you then try to cast cow as a Geode? It can't be a Geode and a Group at the same time... (unless it were an instance of a weird class that multiply-inherits from Group and Geode, but that's a slippery slope indeed...) num1 already gives you the number of drawables under the Geode that is under the cow (root node of the loaded file). Also note that this is not a safe way to traverse a graph (either loaded from file or not). It's safer to write a visitor that will traverse down to the Geodes and then check the drawables. That way you don't write code that assumes a graph structure. Get used to writing visitors, they are simple and powerful. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg-users Digest, Vol 38, Issue 33
Hello, Just below your message there was this: To subscribe or unsubscribe via the World Wide Web, visit http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Just do as it says, go to that web address and unsubscribe. Hope this helps, J-S On 8/28/2010 6:55 PM, qinglun1983 wrote: Thank you for this.I dont need this message anymore.But i dont know how to stop this .please help me . At 2010-08-24 01:52:59，osg-users-requ...@lists.openscenegraph.org wrote: Send osg-users mailing list submissions to osg-users@lists.openscenegraph.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org or, via email, send a message with subject or body 'help' to osg-users-requ...@lists.openscenegraph.org You can reach the person managing the list at osg-users-ow...@lists.openscenegraph.org When replying, please edit your Subject line so it is more specific than Re: Contents of osg-users digest... Today's Topics: 1. Re: cross axes (Jonathan Richard) 2. Object transparency (Aitor Ardanza) 3. [osgCompute] : Sample CuFFT (Adrian Egli OpenSceneGraph (3D)) 4. Re: Lines and only the lines are getting cliped some how! (David Glenn) 5. Re: Texture2D subload callback gone (Thomas Hogarth) -- Message: 1 Date: Sun, 22 Aug 2010 23:32:02 -0400 From: Jonathan Richardjonathan.richa...@gmail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] cross axes Message-ID: aanlktinbhnzoys=8dvuvayuzn-hb3e-ppas3vkxjw...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Gianni Thank you for your reply. It's ok I finally got it working. Jonathan On Wed, Aug 11, 2010 at 9:34 AM, Gianni Ambrosioga...@vi-grade.com wrote: Sorry Jonathan for the delay. Unfortunately I don't remember exactly which modifications I did but if you need I can give you my actual piece of code. Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30691#30691 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Message: 2 Date: Mon, 23 Aug 2010 12:14:17 +0200 From: Aitor Ardanzaaitoralt...@terra.es To: osg-users@lists.openscenegraph.org Subject: [osg-users] Object transparency Message-ID:1282558457.m2f.30...@forum.openscenegraph.org Content-Type: text/plain; charset=UTF-8 Hi, When you set the transparency on the body, the result is this ... Any solution to the following problems? [Image: http://img828.imageshack.us/img828/8516/trans0.jpg ][Image: http://img412.imageshack.us/img412/2969/trans1w.jpg ] Thank you! Cheers, Aitor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30989#30989 -- Message: 3 Date: Mon, 23 Aug 2010 14:05:16 +0200 From: Adrian Egli OpenSceneGraph (3D)3dh...@gmail.com To: osg-users@lists.openscenegraph.org Subject: [osg-users] [osgCompute] : Sample CuFFT Message-ID: aanlktin47fbhugz1jph9fxdp9hkaffbcyzfabcqrq...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi all, did some one still implemented a filter for osgCompute taking an rgba image (ex. osgTexDemo texture - fft - do some work in frequency space - inverse fft - render target image on the textured quad) regards adrian -- Adrian Egli -- Message: 4 Date: Mon, 23 Aug 2010 19:14:58 +0200 From: David Glenndavid.e.glenn@navy.mil To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Lines and only the lines are getting cliped somehow! Message-ID:1282583698.m2f.30...@forum.openscenegraph.org Content-Type: text/plain; charset=UTF-8 O.K. Paul! Just for clarification: When you ask setting the depth test to GL_ALWAYS on the lines I assume that you want me to go line stateset and do Code: stateset-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF); to all the lines in my grid? ... D Glenn D Glenn (a.k.a David Glenn) - Join the Navy and See the World ... from your Desk! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30992#30992 -- Message: 5 Date: Mon, 23 Aug 2010 18:51:03 +0100 From: Thomas Hogarththomas.hoga...@googlemail.com To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Texture2D subload callback gone Message-ID: aanlktimomrudcj4rwvw64-xyp=2wjawltwkrcfwdh...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi Robert With the latest OSG in svn/trunk and the 2.9.x series there is support for texture object pool that is able to reuse
Re: [osg-users] Textures problems in FLTK Viewer utility with LOD model and Viewer.
Hello Dario, Yes, I've made a Visitor to setUnRefImageDataAfterApply(false) for all textures properties and now works like charm. If you want to have less code to maintain, you could just use the osgUtil::Optimizer::TextureVisitor like this: osgUtil::Optimizer::TextureVisitor visitor(true, false, false, false, false, 0.0); (check the names of the arguments in the header to see what they mean... But it works well, we've used it before) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CmakeLists issue
Hello Ting, I have a problem about the CmakeLists.txt in OpenSceneGraph.sln or other OSG projects like osgEarth. The solution can be generated at the first time, and the CmakeLists.txt works well. But after some time, the whole solution have some problems about the path of CmakeLists, and report errors like this: Building Custom Rule E:/osg root/osgearth/src/osgEarth/CMakeLists.txt 1cannot find the right path 1 project : error PRJ0019: Tools from Building Custom Rule E:/osg root/osgearth/src/osgEarth/CMakeLists.txt 1Log is saved at file://e:\osg root\osgearth\src\osgEarth\osgEarth.dir\Debug\BuildLog.htm Then I unload the CmakeLists.txt from each single project in the solution, then the problem is solved; or I unload the CmakeLists.txt and then reload it again, the problem is gone, too. It seems that the solution has forgotten where the CmakeLists.txt is. Does any one else has such problem? How to fix it then? Thank you. I've been using CMake since OSG started using it a few years ago, and I've never seen that kind of problem. Perhaps reporting it on the CMake mailing list would be a better course of action - they will probably be able to help you more than we will. As for your workarounds of unloading / reloading the CMakeLists.txt files from each project, perhaps a quicker way (less manual labor) would be to restart CMake and regenerate the solution? Let us know what you find out, in any case. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proximity Queries between objects
Hello Sanat, Yes, I have the local bounding spheres of each of the child nodes. But I'm still not clear what I need to do to join all the bounding spheres of the child nodes for the entire model ? Please search the archives, this has been discussed before. Actually, if you have a hierarchy of nodes, the bounding sphere of the root of the subgraph contains the bounding spheres of all child nodes (thus the scene graph can test a single bounding sphere and discard a whole subgraph from rendering if it's outside the view frustum, and if it's inside or intersecting then it will descend and test the children, recursively). So you could just use the bounding sphere of your Backhoe Group if you've added the other models as children of it. But what you're missing is the transformation of a bounding sphere in the model's local space into world space. If you have two models that are loaded from the same file, of course their local bounding spheres will be identical. It's their parents that will transform them to their final places in the scene. So when I talk about transforming the bounding sphere from local space to world space, I mean taking in account the models' parent transforms up to the root of the graph. Also, a minor note, in the code you posted you're allocating a Node to each element, and then loading the models from the file. That's one unnecessary allocation for each node. For example, this: Stick = new osg::Node(); // 1 // ... Stick = osgDB::readNodeFile(_BHStic_.lwo); // 2 could be replaced by only the last line: Stick = osgDB::readNodeFile(_BHStic_.lwo); with the same result, because in your code, a new Node will be allocated at line 1 above, and then in the assignment at line 2 above that Node will be deleted. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proximity Queries between objects
Hello Sanat, However, both the spheres (1 and 2) have the same centre coordinates. When I try the same thing using spheres that are bounds for the top-most PATNodes, I again get the same result (i.e. centre coordinates are the same). I find this confusing as both the nodes have different positions. Is this a sensible approach to take though ? getBound() returns the local bounding sphere. You need to transform it by the matrices (transforms) from the root to each of your models respectively, then you'll get the world-space bounding sphere for each model. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Displaying OSG data in MFC window
Hello Snehal, I am new to both MFC and OSG. I am displaying the 3D point cloud in OSG. I want to display this osg data in the window provided by the MFC. Is there any way to do it? Please reply... You can look in the OSG sources, there is an example called osgViewerMFC. In general, if you want to learn OSG, the examples are a good place to start, and their names even sometimes tell you what the example covers. :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Array
Hello Igor, Ok. There are some unobvious things with indices array. I'll have to defer to someone else on the list for the behavior of index arrays. I don't use them generally, as they are not optimal on today's real-time pipelines and force OSG to use OpenGL slow paths. But obviously, if you are reading data that has index arrays then you need to be able to handle them, but I can't help you, sorry. Someone else on the list might be able to. Another way to go might be to convert the indexed geometry to non-indexed, I think there may be a class in the osgUtil::Optimizer that does this. Sorry I can't help you further, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proximity Queries between objects
Hello Sanat, So, I wanted to know if there is some way in OSG I can compute the shortest distance between the boundaries of two objects. Well, in OSG you have access to an approximated bounding sphere and bounding box of your geometry (these may be very approximate though, i.e. they may not closely match the actual geometry). You can easily calculate the distance between two boxes or even more easily between two spheres. But I would look into using some physics engine for this anyways, even if it offers more than what you need at present, because it's likely you'll need what it offers eventually... It's really a matter of using the best tool for the job, and physics/collision detection engines are specialized at that sort of stuff. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Array
Hello Igor, Oh, your example seems very helpful, as it gave me a way to get rid of long blah-blah-blah, but is it ok to use osg::Vec3Array with * ? I thought it might cause memory leaks. Memory leaks come from allocating memory which you fail to deallocate later when it's not needed anymore. Or even worse, allocating memory repeatedly and losing any reference to the old allocated memory. This can cause the program to continue allocating memory for nothing, eventually using up all available memory in the system. Here, the objects have been loaded for you by OSG, and you're accessing their vertex array directly (casting the osg::Array* that comes from Geometry::getVertexArray() to an osg::Vec3Array*). You're not allocating anything, just accessing the data that's there using its concrete type instead of its base class type. So no, that won't cause a memory leak. I suggest you review the concepts of memory allocation and pointers, as well as classes, inheritance and casting (dynamic_cast in particular) if this is not clear to you. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersection and threading problem
Hello Markus, Yes, this does make sense. I am using the delta3d game engine as well so maybe what I'm asking is if there is any general way the check if osg is currently in a state where it is unsafe to act upon the scene? For instance, Is there any mutex that belongs to osg that I can wait on ? Not in OSG itself, but I don't know about Delta3D. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Array
Hi Igor, The reason why i wrote my test line like that: it's just simple for me. And i surely know, what loader will return. Even if you know what it will return for that model, will you only use your code for one model? Ever? It makes sense to make reusable and robust code that you can use with many many models... Hope my post is readable, cause i'm experiencing some difficulties making complex sentences. This one was fine :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fag and Shadows
Hello Martin, What can I do to use fog and shadows? As is always the case with shaders, once you start using them you need to replace anything that was previously being done by the fixed pipeline by shaders. The shadow shaders don't do fog so you won't get fog in your scene under the ShadowedScene unless you replace the shaders (which are being set by the ShadowTechnique, in your case StandardShadowMap) by shaders that do both shadows and fog (and any other effects you need). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] intersection and threading problem
Hello Markus, Thanks for addressing this Skylark. Yes, the application crashes due to what I think you described (accessing the scene graph while it is being modified) I am using osgEarth and running threads concurrently that need to intersect with the surface of the earth model. Is there any thread-safe way to achieve this without running everything on the main thread? More generally, is there a way to ensure that you only traverse the scene graph's nodes when you're supposed to? You're in control of your application's main loop, so you can synchronize things the way you want. You can set a mutex that will make it safe to run intersections at given times, and then unlock the mutex to let the viewer run its update and cull phases safely. That's just an example. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Array
Hello Igor,
You're coming across as pretty aggressive. No one is forcing you to use
OSG, it's a tool, if you choose to use it then you'll have to learn how
to use it, like any other tool...
Ok, i'm still trying just to get data from object...
For the beginning i'm trying to copy only vertex array's.
For example - only first mesh:
vertices[s][v] =
temp-asGroup()-getChild(0)-asGroup()-getChild(0)-asGeode()-getDrawable(0)-asGeometry()-getVertexArray()[v];
Stringing things like this is the best way to get incomprehensible code,
in addition to getting crashes. What happens if temp is not a Group? if
it has no children? if its child is not a group? if its child has no
children? if its child's child is not a geode? if its child's child has
no drawables? if the drawable is not a Geometry? if the Geometry has no
vertex array? And you have a bug above, getVertexArray() returns a
pointer to an osg::Array, not the array itself, so you need to
dereference the pointer before getting the value at index v, but still
you don't know the type of the data so you need to cast it...
The safe way to code this is to use a NodeVisitor to get to the
osg::Geodes in the subgraph. Then iterate through the Geode's drawables,
casting them to Geometry if possible, then getting the vertex array and
casting that to an osg::Vec3Array, then if that returns a valid pointer
iterate through the vertices and get them.
Perhaps I'm being too kind by giving you code which you could have just
looked through the OSG examples to get, but perhaps this will help get
you started on the right path.
class GetVerticesVisitor : public osg::NodeVisitor
{
public:
GetVerticesVisitor()
: osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN)
{
}
virtual void apply(osg::Geode geode)
{
// Iterate through the drawables.
for (unsigned int i = 0; i geode.getNumDrawables(); ++i)
{
osg::Geometry* geometry =
geode.getDrawlabe(i)-asGeometry();
if (geometry)// Make sure the object is a Geometry
{
osg::Vec3Array* vertices =
dynamic_castosg::Vec3Array*(
geometry-getVertexArray());
if (vertices)// Make sure it was a Vec3Array
{
// Use vertices as an std::vector, for example:
for (unsigned int j = 0; j vertices-size(); ++j)
{
osg::Vec3 vertex_at_j = (*vertices)[j];
}
}
}
}
osg::NodeVisitor::apply(geode);
}
};
This is just off the top of my head, hope it compiles cleanly but there
may be a typo or two. But this demonstrates the safe and general way to
get to vertex data given any loaded file. You don't have to know
anything about the structure of the loaded file, and it will work, as
opposed to the horrid series of calls you were stringing together above
that would have worked on one model but not on the next.
If you want to be even more general, you should look into the
PrimitiveFunctor and PrimitiveIndexFunctor interfaces. The above class
will give you the vertex data, but will not tell you how these are
arranged to form triangles. This is stored in the PrimitiveSet, also a
member of the Geometry (like the vertex array). And the general way to
get triangles or primitives from a Geometry is using PrimitiveFunctor
and PrimitiveIndexFunctor.
And WTF? WTF is osg::Array?
WTF are you taking that tone with us? We're supposed to be civilized
human beings here, and you're asking us for help. Please be polite at least.
It's a class. It helps OSG bridge the gap between data that OpenGL can
understand and data that the user can understand (in a structure like an
std::vector).
Why it is returned when index is set?
I don't understand this question.
Why it even exists?
Err, well you could assume it exists because it's useful... Just an idea.
How should i get data?
See above (GetVerticesVisitor).
getDataPointer() returns GLvoid pointer. Shame on me, but i dont know, how to
use it.
You can cast GLvoid* into something else with static_cast or
reinterpret_cast. But this is not what you need. It's not a safe way to
get at the data. The above visitor is the safe way.
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] Shift of coordinates
Hello Maxim, Пожалуйста счените имя Александр Бобков на английский аналог... Please keep discussion on the mailing list in English so it can profit all users. This is a community, and all questions and the subsequent answers can help both present and future users who might have the same question. The OP had even posted in English, so there was no reason to answer in another language, except if it was a personal reply in which case it should not have gone to the list. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Sanat, I decided to take the approach that displays graphics in a window. I am able to get 2 windows. But right now, both monitors are displaying 2 windows. I am not able to separate window 1 to screen 1 and window 2 to screen 2 only. This is not an OSG issue... You have probably set up your video card to mirror instead of dual view. Check your control panel / video card config (I don't know what operating system you're using, or what video card) and make sure you can see different images on both monitors even for normal applications (like you can drag your e-mail program's window across to the second screen, or even overlapping both screens). Once you've got that working, you can put the screen number in the traits structure so that each window appears on the screen you want it to initially. See osgViewer::View::setUpViewInWindow() for inspiration. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hello Sanat, From the code you posted, you're creating 3 graphics contexts using the same traits for all 3. This will obviously put all 3 on the same screen. traits-displayNum and screenNum need to be set to the screen you want, a different one for each context. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hello Sanat, Also, I wanted to know if trial and error is the way one can pick up the intricacies of osg, as there is so much in the api, its very difficult to know how it all works. Well, trial and error can only bring you so far. If you compile OSG yourself you can place breakpoints in your code, trace into OSG code and see what happens behind the scenes. Also just reading the code to see what a function does is very helpful. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Repeating and Bumpmapping a texture
Hello Mike, So I've been prodding around a bit in the osgFX::BumpMapping code and noticed that vertex and fragment shader programs are embedded in BumpMapping.cpp. I'm guessing the TexMat ceases to do anything because the shader programs ignore it? Is there any way to bypass that without writing my own shaders? The texture matrix still applies when using shaders, it's just that some shaders ignore it. In short, if you have a line like this in the vertex shader: gl_TexCoord[0] = gl_MultiTexCoord0; then you have to replace it by: gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0; So what you could do is copy the whole shaders from the source files of osgFX::BumpMapping, just fix those lines and apply it to the same nodes. Hopefully once Robert is done with shader composition, we'll have less non-overridable shader code lying around everywhere. It should be easier for users to override just parts of the shaders to fix things like this. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mixin Shadow Technique
Hi Martin, is it possible to mix two different osg shadow techniques. I would like use the parallel split shadow map for my terrain and the standard shadow map for my vehicle. No, that won't work. At least not easily. The shadows from your vehicle needs to be cast on your terrain, and if your terrain has mountains or other large features then its shadows need to be cast on your vehicle. The problem is that shadows are only calculated AND applied to objects in the subgraph under the ShadowedScene. So if you have two ShadowedScenes each with its own shadow technique, but each with a different subgraph (one with the terrain, the other with the vehicle under it) each will only calculate and apply shadows to its own subgraph. I said not easily because you could probably do some intricate setup with the CastShadow node mask and shaders, so that both ShadowedScenes have the whole scene, but one of them calculates shadows from the vehicle and applies them to the terrain, and the other calculates shadows from the rest. But I've never tried this, it may not work, and you may be doing all the work twice, so it might not be practical. You'll have to try it and see. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Sanat, But using a set up such as that, I am basically transmitting the entire video feed to the remote screen. I am interested in sending the rendering of only 1 of those 3 viewports(1 view from the compositeViewer), not all 3. (as seen in the attachment below). With that being the case, does it make more sense to use the image based approach ? the rendering the image on the master pc and transfering the final image Or can it still be achieved using the method in the earlier post ? If your master PC has two VGA/DVI/... outputs (as most graphics cards now do) you could easily have a first monitor that would have the three viewports for the local viewer, and only render the bottom left viewport on the second monitor (which would be transmitted to a remote monitor). Essentially, the box Torben linked to takes a VGA output and sends it to the remote box, so anything you can do with a separate video output will work the same with that. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Transfer osgViewer stream wirelessly to a remote monitor
Hi Sanat, Are there any examples in the source that show how to only render the bottom left viewport on the second monitor (basically a generic example for selective rendering) or any suggested reading ? See the osgcompositeviewer example. In general, a CompositeViewer has a list of Views, each View has a master Camera, and each camera (can) have a GraphicsContext. In your current case, your three views have the same GraphicsContext, so they render to the same window. You can do what you want a few different ways. If you want your master monitor and the remote monitor to always render the views in fullscreen mode (not windowed), then you could simply set up a single GraphicsContext across both screens (see osgViewer::View::setUpViewAcrossAllScreens()), set up your three current views' Viewports to map to the part of the GraphicsContext that's visible on the first monitor, and map a new, fourth View's viewport to map to the part of the GraphicsContext that's visible on the second (remote) monitor. If it's possible that you will want either the local or the remote monitors to display the graphics in a window, then you can keep the local part the same way you have now (a GraphicsContext that has the renders three Views you have now), and set up a separate GraphicsContext on the other monitor (see osgViewer::View::setUpViewOnSingleScreen()). Then you would have a fourth View, whose Camera would have this GraphicsConext. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using keys to control track ball manipulator?
Hello Werner, I'm new to openSceneGraph and I tell you, dear developers, it is hard to learn due to extreme poor class and method documentation. Look at the doxygen doc and you will see what I mean. We all know what you mean, but improving it is a large task that is being done incrementally when people have time. This has been discussed a lot in the past. In the mean time, learn to read the source, you'll learn much faster that way. Is there any method to manipulate the manipulator accordingly? Look at the code for osgGA::TrackballManipulator, you'll see that it only responds to mouse events. You can subclass it and override its handle() method, respond to keyboard events there and call the base class version of osgGA::TrackballManipulator::handle() afterwards so the mouse events will continue to work. Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using keys to control track ball manipulator?
Hi Werner, I guessed that already ;-) But things will not really improve if developers don't comment at creation time. Sure. Most developers who submit to OSG these days document their code better than in the past, and some even look at the whole file that they're changing and see if there's any documentation they can add to existing methods (even if they didn't modify them). That should improve things gradually... No one is going to sit down and comment the whole of OSG at once... :-) Since I'm using Adapterwidget to QGLWidget I have to handle any events anyway myself. So what about using TrackballManipulator::setRotation(...) or TrackballManipulator::setDistance(...) Do they work incrementally? (No comments on doc :-( Err, try it? If it doesn't work, check out the code and see why... Or can I use TB-setByMatrix(TB-getMatrix() * myRotationMatrix) Same answer. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Tool to inspect instance of Referenced/Object
Hi Cedric, I have work on a small tool to detect how a program evolve during time, It tracks the numer of instance of each object inherited from osg::Referenced. I use this to detect 'leak' but release when quitting the program so not really a leak but to detect consumption of too much memory during runtime. The tool to works need modification in osg::Referenced. because there is already a mecanism to set a custom DeleteHandler, I thought we could do the same to intercept instanciation of osg::Referenced with a custom InstanceHandler ? A while ago I suggested a similar modification to osg::Referenced to be able to register all instances of osg::Referenced created, and dump the current state at a given time. http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/37589/focus=38000 http://thread.gmane.org/gmane.comp.graphics.openscenegraph.cvs/4682 I used this to find a runtime memory leak caused by a circular reference in osgShadow::StandardShadowMap and related classes. The ShadowTechnique had a ref_ptr to the scene camera, and indirectly (through the scene's children eventually going to the ShadowedScene) the camera also had a ref_ptr to the ShadowTechnique, so both their ref counts always stayed = 1 and the whole scene was never deleted. This was a big memory leak for us since our software needs to be able to load many scenarios during its runtime, and we expected the whole scene to be deleted when a new scenario was loaded. However, Robert asked that I wire in support to enable/disable my modifications in CMake, which made sense, but I never got around to doing it. :-( Perhaps if your modifications get accepted I'd be able to adapt what I had done and we'd get the best of both worlds. Do your changes also intercept calls to ref(), unref() and unref_nodelete()? That was useful to me in order to find out who was keeping refs to my objects and not releasing them. Good work, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows, clouds...
Hi Jose, Thank you for your pieces of advices Jean-Sébastian, but how coud I make it if the variable that makes cloud effect is an Environment variable and this variable is the father of the terrain? I don't quite get what you're saying about environment variables... You can structure your graph in any way you want. But if your clouds are under the ShadowedScene, they will be affected by shadows. You can set a null osg::Program or put a different shader on your clouds to prevent this (the first suggestion in my previous message) or you can move your clouds to not be under your ShadowedScene (the second suggestion). The clouds cannot be a parent of the terrain, because they're both geometry, therefore both leaf nodes. Please look at your scene graph structure again and figure out how to make it work (writing your whole scene to a .osg file is useful in cases like this, use osgDB::writeNodeFile(*sceneRoot, filename.osg); ). Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgWidget/osgQt
Hi Jeremy, I'll just echo Robert's comments: And also: I was officially declared in remission about a month ago, so my short (but interesting!) bout with blood cancer at 29 is over. Yay. :) Congrats! That's great news! As more work goes into osgQt towards OSG3 (and as we get closer to having full, fist class 2D widgets), I think that osgWidget (in it's current form) should be removed. It was designed with the very futile goal of trying to be a 2D UI kit, when it should have been far smaller and far more generic from the very beginning. osgQt is far from being ready to do general UIs in the 3D view (as a HUD). It has serious shortcomings (one of them being the requirement of Qt, which is a problem for some projects and not others), some things plain don't work (draggable sub-windows, input fields in some situations, etc.), and it's slower than doing native drawing like osgWidget does. Check out the osgQtWidgets example in current svn to see what I mean. osgWidget works well for what it does, and I still don't understand what you mean when you say it should have been smaller and more generic... If you're redesigning osgWidget to be smaller, perhaps we could find a way to retrofit the current osgWidget to use your new architecture as a base, or something like that... Because I think current users will want to keep using it like they do now (me included). Anyways, let us know what your plans are and we'll help. :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows, clouds...
Hi Jose, When I use shadowedscene with shadowmap and clouds, clouds are a little black! How can I delete this effect? Please search the archives in the future, this is a frequently asked question. There are two ways to make it so that shadows are not applied to the clouds: 1. Customize the shader applied to them so it doesn't do the shadow test (or remove the shader altogether). If you don't put a shader on that object, it inherits the one from higher in the graph (probably the one ShadowMap uses). See src/osgShadow/ShadowMap.cpp in the OSG source code. If you just want to remove this shader, you can do: node-getOrCreateStateSet()-setAttributeAndModes( new osg::Program, osg::StateAttribute::OFF); because a program with no shaders means the fixed pipeline. 2. Put your objects outside the shadowed scene. I.e. have a root osg::Group which has as children the osgShadow::ShadowedScene, and put your clouds under that root and not under the shadowed scene. root /\ shadowedSceneother non-shadowed objects | shadowed objects Hope this helps, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] event traversal: camera manipulator executed before or after eventCallback?
Hi Torben, You said, the view matrix based on the camera manipulator is calculated during the cull traversal, so the viewmatrix I send during the camera-eventCallback is the viewmatrix of the last frame. No, I said the viewer gets the view matrix from the manipulator during the cull traversal. See the slight difference? The manipulator's view matrix is calculated any time someone calls its getMatrix() or getInverseMatrix() method, and it's calculated from the data it has at that precise moment. The viewer happens to call this method during the cull traversal. But you could call it during the event traversal. You just need to make sure the camera manipulator has all the data it needs to calculate the right view matrix for the current frame when you call its getMatrix() or getInverseMatrix() method. i.e. you want it to have the same information as it will have later during the cull traversal, so that the result you get is the same as the result the viewer will get when it calls the same method. Depending on your manipulator the information it needs will be different. It processes events during the event traversal, and if it's a node tracker manipulator it depends on the position of the node it's tracking being updated too, which might happen in the update traversal (only you know your whole app so you should know). Again, placing breakpoints will tell you what's going on. Place one breakpoint where you call manipulator-getMatrix() or getInverseMatrix(), one breakpoint in the manipulator's handle() method (which is called in the event traversal), and another where the viewer calls getInveseMatrix() on it. Depending on when each of these breakpoints hits (i.e. 1 then 2 then 3, or 2 then 1 then 3, etc.) you'll know what state each one is getting. If everything is updated, and then you call getInverseMatrix() and the viewer calls it right after, you know both got the same information so you're getting the view matrix for the right frame. Hope this clears things up, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
