[osg-users] osgViewer::GraphicsWindowWin32 stack overflow crash
First off, for reference I am using osg 2.6.1, but I checked osg 2.8 and it does not appear to be substantially different. I am using osg to render into a window embedded into a larger Windows Forms application. The architecture is that Windows events/message are delivered into the main GUI thread and rendering occurs in a separate thread. Input events, changes to the scene graph etc and marshaled between threads as necessary. For the purposes of my application, osg should not know or care about the windows event loop (unless someone can give a really compelling reason why it needs to). So, osgViewer::GraphicsWindowWin32 permits initializing with an existing HWND. All well and good. However, where things start to go wrong is this part of initialization: GraphicsWindowWin32.cpp line 1155 if (!registerWindowProcedure()) This sets the window procedure for the window in question, even though osg does not own that window. This then creats a problem with the window procedure itself: GraphicsWindowWin32.cpp line 2050 LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam ) Specifically, at the bottom of the function is the following code: GraphicsWindowWin32.cpp line 2339 return _windowProcedure==0 ? ::DefWindowProc(hwnd, uMsg, wParam, lParam) : ::CallWindowProc(_windowProcedure, hwnd, uMsg, wParam, lParam); Notice that if _windowProcedure is not null, it will call _windowProcedure. The problem is, _windowProcedure is initialized by registerWindowProcedure, and indirectly calls handleNativeWindowingEvent, which calls _windowProcedure, which calls handleNativeWindowingEvent, which calls _windowProcedure, which calls handleNativeWindowingEvent... And so on until we get a stack overflow. Presumably the purpose here was to pass on unhandled events to some other window procedure up the chain, except for the fact that there's no way to actually provide a custom window procedure with the current GraphicsWindowWin32 API. Hmm. There also isn't a way to tell GraphicsWindowWin32 to not mess around with the WindowProcedure in the first place. Hmm. The best ideas I've been able to come up with are to either modify osgViewer::GraphicsWindowWin32 and comment out the call to registerWindowProcedure(), or possible subclass it in my application and make registerWindowProcedure() a no-op. While I appreciate that osgViewer is much better integrated into the overall library than Producer was integrated into osg 1.0, this seems to be one case where the Producer architecture of separating window initialization and event handling was actually more appropriate. Any thoughts, and should this be filed as a bug? Thanks, Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 01760 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowWin32 stack overflow crash
Well, the reason why I was ask if this is a bug is that I don't quite understand how it could possibly work correctly for the case that the native window is not owned by GraphicsWindowWin32. The code very deliberately sets up a situation the allows infinite recursion to occur as I described in my previous email, so either I'm missing the intention, there's something funny about the way I'm using it, or this is an actual problem. Perhaps using osg as a user control embedded in a larger application is not typical usage compared to single window or full screen? My desire for GraphicsWindowWin32 to work a bit differently (or at least be able to work around it) has more to do with not having the program crash than any strong opinion about what the right way it is. Thanks, Peter Robert Osfield wrote: Hi Peter, Something not working in the way you'd like it to work isn't what I'd class as a bug, rather it's a wish list item. In terms of making classes more flexible so it can be used in the way you want to use it, please feel free to suggest amendments so that others can review them and comment. FYI, hints about setup can be passed via the GraphicsContext::Traits class, this could be explanded to tell the window setup code in GraphicsWindowWin32 to do things differently. Another aspect to osgViewer is that you can inject custom events into the viewer by calling the windows osgGA::EventQueue directly, I don't know if this is relevant in this case though as I'm not familiar with the GraphicsWindowWin32.cpp. Hopefully others with experience of working with GraphicsWindowWin32.cpp window inheritance can chip in. Robert. On Wed, Mar 4, 2009 at 6:03 PM, Peter Amstutz peter.amst...@tseboston.com wrote: First off, for reference I am using osg 2.6.1, but I checked osg 2.8 and it does not appear to be substantially different. I am using osg to render into a window embedded into a larger Windows Forms application. The architecture is that Windows events/message are delivered into the main GUI thread and rendering occurs in a separate thread. Input events, changes to the scene graph etc and marshaled between threads as necessary. For the purposes of my application, osg should not know or care about the windows event loop (unless someone can give a really compelling reason why it needs to). So, osgViewer::GraphicsWindowWin32 permits initializing with an existing HWND. All well and good. However, where things start to go wrong is this part of initialization: GraphicsWindowWin32.cpp line 1155 if (!registerWindowProcedure()) This sets the window procedure for the window in question, even though osg does not own that window. This then creats a problem with the window procedure itself: GraphicsWindowWin32.cpp line 2050 LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam ) Specifically, at the bottom of the function is the following code: GraphicsWindowWin32.cpp line 2339 return _windowProcedure==0 ? ::DefWindowProc(hwnd, uMsg, wParam, lParam) : ::CallWindowProc(_windowProcedure, hwnd, uMsg, wParam, lParam); Notice that if _windowProcedure is not null, it will call _windowProcedure. The problem is, _windowProcedure is initialized by registerWindowProcedure, and indirectly calls handleNativeWindowingEvent, which calls _windowProcedure, which calls handleNativeWindowingEvent, which calls _windowProcedure, which calls handleNativeWindowingEvent... And so on until we get a stack overflow. Presumably the purpose here was to pass on unhandled events to some other window procedure up the chain, except for the fact that there's no way to actually provide a custom window procedure with the current GraphicsWindowWin32 API. Hmm. There also isn't a way to tell GraphicsWindowWin32 to not mess around with the WindowProcedure in the first place. Hmm. The best ideas I've been able to come up with are to either modify osgViewer::GraphicsWindowWin32 and comment out the call to registerWindowProcedure(), or possible subclass it in my application and make registerWindowProcedure() a no-op. While I appreciate that osgViewer is much better integrated into the overall library than Producer was integrated into osg 1.0, this seems to be one case where the Producer architecture of separating window initialization and event handling was actually more appropriate. Any thoughts, and should this be filed as a bug? Thanks, Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 01760 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowWin32 stack overflow crash
That sounds like the right thing to do. I'll give that a try. Stephan Huber wrote: Hi Peter, Another idea would be to extend GraphicsWindowWin32::WindowData to add a flag or something similar, so GraphicsWindowWin32 can query this flag an decide if it's allowed to call registerWindowProcedure. This is what we have done for the OS X carbon implementation, and it doesn't pollute the cross-plattform traits-structure. just my 2 cents, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgViewer::GraphicsWindowWin32 stack overflow crash
Yes, embedding osgViewer into a .NET control is exactly what I am doing, and I have been using it this way successfully for a long time. I just remembered another wrinkle -- for some reason, the code works fine when run with an NVIDIA GeForce chip, and it only crashes with the infinite recursion problem when running on a different computer with an ATI Radeon chip. Very peculiar (but not the only peculiar thing about osg and ATI, but that's the subject for another post.) It is a little bit tricky because the user control hierarchy in Windows Forms are all supposed to be owned/accessed by a single thread (and will raise exceptions on cross-thread access) but I want to render in a separate thread from the main application thread. This is a large part of the reason why having osg processing its own window messages is so problematic for me, because those events *must* be processed by the main application thread in order for event propagation, focus management, hotkeys and so forth to work properly. At any rate, I'm probably going to go with Stephan Huber's suggestion and add a flag to GraphicsWindowWin32::WindowData. Seeing that such a flag already exists for the OS X Carbon implementation, it is an easy case to make that the Windows implementation should have a similar option. Peter Jason Beverage wrote: Hi Peter, We've also used the GraphicsWindowWin32 successfully by creating a custom User Control in .NET. We're using the code from this FAQ entry with no problems: http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol Thanks! Jason On Wed, Mar 4, 2009 at 3:14 PM, Peter Amstutz peter.amst...@tseboston.com mailto:peter.amst...@tseboston.com wrote: That sounds like the right thing to do. I'll give that a try. Stephan Huber wrote: Hi Peter, Another idea would be to extend GraphicsWindowWin32::WindowData to add a flag or something similar, so GraphicsWindowWin32 can query this flag an decide if it's allowed to call registerWindowProcedure. This is what we have done for the OS X carbon implementation, and it doesn't pollute the cross-plattform traits-structure. just my 2 cents, Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] WPF and OpenGL popup window problem
I have a similar problem to the one described here, although with Windows Forms rather than WPF. Whenever my application renders a tooltip which overlaps the OSG window, the tooltip gets cut off on the next OSG frame. I've spent hours trying to find any information about how to work around the problem, but have drawn a blank. This seems to mainly be a problem on Windows XP; the systems with Vista I have tried do not exhibit this problem. I can't speak to whether different hardware/drivers have different behavior, though. Peter Brede Johansen wrote: Hi Brian, What you describe sounds like the WPF airspace limitation described here http://msdn.microsoft.com/en-us/library/aa970688.aspx. The short version is that each pixel can only belong to one render technology (WPF, DirectX, Win32 OpenGL). A workaround is to render your OSG scene off screen and give the bitmap to WPF. Brede On Wed, Mar 4, 2009 at 11:49 PM, Brian Stewart osgfo...@tevs.eu wrote: Hi, I have developed an application where I have an OSG window embedded in a windows application built with WPF. On certain Geforce cards there seems to be a bug where WPF popup windows (like menus) that have AllowTransparency set to true do not draw correctly over my OSG window. Basically whenever the OSG/OpenGL window updates, it overwrites all overlapping pixels, even if the popup is higher in the window manager's Z-order. I have isolated it to an issue with the OpenGL driver. It only occurs on Geforce cards, not Quadro cards (which is not surprising, since I've read the Geforce cards were optimized for DirectX). I'm not so much looking for a fix (though one would be welcome) - I'm just wondering if anyone else has encountered this. I have already filed a bug report with nvidia, and it might help if I could report that others are having issues with it too (or maybe I really am the only person out there foolish enough to try this). If anyone is interested, I can supply a small test project that uses WPF and OpenGL together to demonstrate the problem. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7967#7967 ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Separate sub-graphs of the same scene
I'm not sure I entirely understand what you're trying to accomplish, but perhaps you want to look into using a stencil buffer and/or pixel shader to control what gets rendered? Guy wrote: Hello, I'm trying to merge two sub-graphs to the same image. It doesn't work so well, so I'll try to explain what in general I'm trying to achieve, then my not working so well solutions, and then the questions J So, in general I want to replace an object (A) in the scene with another object (B) on some condition. The object (B) is some pixels which are lit up. The important thing is to keep the 3D scene distance from the camera for both objects, so if the object is obscured by another, then both (A) and (B) will be obscured, and if some other object (C) is obscured by (A), it will still be obscured by (B). Object (B) might be partially transparent. Not working so well solution 1: Have switch for (A)/(B). The position of (A) is multiplied by view-projection matrix, the result is pos'. (B) is a set of points which their vertices are pos' with (x,y) replaced by the pixels I want to lit, and the new positions are multiplied by the inverse-projection invers-view matrices. This solution had problems with setting the right pixels. Not working so well solution 2: Object (B) is a set of pixel under ABSOLUTE_REF orthographic projection with (x,y) of the pixels I want to lit and z is the negative distance between (A) and the camera. This solution has the correct pattern of the lit pixels, but the Z order doesn't seems to be correct. The implementation of solution 2 is to add camera with ABSOLUTE_RF and orthographic projection. View is identity. I set the clear mask to 0 since I don't want the Z-Buffer to be cleared. (opposed to huds and that kind of implementations). I used the osgviewer to put the cow at 0,0,-300 under absolute_rf, and a point at 0,0,0 under separate camera with orthographic projection, and the point was hidden by the cow (which is a mistake). I thought that I might need to set the zNear/zFar of both camera's to be the same, but in this simple example it shouldn't matter since the point Z is zero… So first, do I have to set the zNear/zFar of both camera's to be the same? Any ideas whats going wrong? Other solutions for the problem? Btw, I tried to replace the points by quads under orthographic projection. The results were the same. Thanks, Guy. *מאת**:* osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] *בשם** *Robert Osfield *נשלח**:* Monday, March 16, 2009 5:39 PM *אל**:* osg-users@lists.openscenegraph.org *נושא**:* Re: [osg-users] RecordCameraPathHandler where is the saved_animation.path file? On Mon, Mar 16, 2009 at 3:28 PM, Felix Ilbring osgfo...@tevs.eu wrote: Hi Robert I have done it. I put it to new osgViewer::RecordCameraPathHandler(C:\\ETC.path); but it was never there. The class has always worked for me, so can't suggest any gotcha's, you'll have to open up a debug and see what the ReecordCameraPathHandler is doing on your build/system. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] switch between two camera
Robert Osfield wrote: Hi Peter, Benoit et, On Mon, Mar 16, 2009 at 8:15 PM, Peter Amstutz peter.amst...@tseboston.com mailto:peter.amst...@tseboston.com wrote: The way I handled this in my application was to create multiple instances of osgViewer::Viewer with a separate camera for each view but all bound to the same output window. On each render iteration, draw just the active camera. I'm afraid I really wouldn't recommend this solution, having multiple viewers just to alternate between views is complicated implementation and conceptual wise and you'd be very lucky for it to work in anything other that very limited usage models. Using multiple viewers will cause problems with threading, timing codes, it'd be a right old mess. Well, I force it to use single threading since my render thread already runs independently of the main logic thread. This avoids most of the problems you mention, but in general I wouldn't recommend this solution either. I just thought I'd throw it out there because it has worked for me so far. I think I am doing it this way because I originally wrote my code for OSG 1.2, which didn't have any of the nice osgViewer infrastructure. The best solution depends on exactly what you need to display; I decided to switch between completely independent scenes because my 2D and 3D views looks actually render somewhat different geometry (the 2D ortho view is an abstracted version of the real 3D geometry). Having entirely separate scenes is also pretty straightforward although it imposes some overhead due to duplication of resources that could otherwise be shared between among views. In your case you are talking about multiple Views, and this is fine, but you don't use multiple Viewers for it, you'd use a single CompositeViewer with multiple Views. You can add and remove Views, or just toggle Camera's on/off using NodeMask's. I'll take a look at this. The (doxygen) documentation is a bit thin here, so I wasn't sure what exactly CompositeViewer was for -- I assumed it was for rendering multiple subwindows of a single main window. I'm still fuzzy on the relationship between Graphics Context, View, Viewer, Camera, Scene -- there's at least a couple layers of abstraction there. Especially when I see inheritance graphs like this (http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a01055.html) :-) - Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] distant nodes in orthographic projection turn black
I am having a puzzling problem that I hope someone might have some insight on what is happening: My application renders a terrain using a top-down, orthographic view, and places various icons (simple flat meshes mostly) to represent simulation agents (soldiers and vehicles). One of our testers noticed that when you zoom out to a certain distance where the icons are very small but still visible, sometimes some of the units (always the medium and small icons) turn black. Zooming in restores the proper color. It is very sensitive to the projection parameters, sometimes it is correctly rendered at moderate zoom, turns black after zooming out, and then is colored properly again after zooming out even more. Some details: The icons are ordinary geode nodes. They use flat color materials, no textures. The icons are composed of several submeshes, usually text on a background with a border. It's hard to say, but usually only one of the submeshes turns black. The camera is held at a fixed Z elevation, and zooming is accomplished by changing the orthographic projection parameters to have a wide view or a narrow view. Panning on the XY axis changes only the XY camera position. The scene is lit with a single downward-facing infinite light. It casts (.8, .8, .8) colored ambient light. I'm using the default setting for Near-Far culling plane. Icons are scaled based on a logarithm function of the zoom level (meaning that at high zoom levels the icons are scaled up a bit from their natural sizes, but not linearly with the zoom level). I scale the icons by updating the transform matrix and calling dirtyBounds(). This behavior is sensitive to the elevation of the camera. When the camera was located at an elevation of 1 units (meters) many of the icons would exhibit this problem, when the camera was lowered to 1000 units, fewer icons rendered improperly, and at 300 units everything rendered just fine. So, tentatively the solution is simply to ensure that the camera is placed as close to the action as possible, but if anyone has any ideas as to what is really going on here, I would be very curious. Perhaps I am running afoul of some small object optimization, that culls objects thought to be too small to show up on screen? - Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] where can i find the vertex positions?
If you're just interested in the vertices and not the mesh, you can look
at osg::Geode, get the list of osg::Drawables, cast to osg::Geometry,
then call osg::Geometry::getVertexArray().
Or you can use osg::TriangleFunctor to iterate over the triangles that
make up the mesh, this provides you with osg::Vec3 triples representing
each triangle.
There are likely other ways to get at this data as well, it depends on
what you want to do with it.
Christian Sam wrote:
Hi,
i' m looking for a way to get the vertex positions of my geometry. i know there
are methods, provided by osg, to access these vertex positions, but i wanted to
get some insight how they are handled by osg, so i debugged a simple scene.
i found the geometry object along with the _primitives data member, referencing my 5 DrawArrays with the correct indexes. the debugger also showed me a _vertexData member, but i couldn't find any reference to the actual vertex positions.
(i set my breakpoint in viewerbase.cpp in the ViewerBase::frame() at the
eventTraversal() function.)
here is my .osg scene file:
Code:
LOD {
nodeMask 0x
cullingActive TRUE
Radius -1
RangeMode DISTANCE_FROM_EYE_POINT
RangeList 1 {
0 1e+010
}
num_children 1
Group {
nodeMask 0x
cullingActive TRUE
num_children 1
MatrixTransform {
nodeMask 0x
cullingActive TRUE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE ON
GL_LIGHTING OFF
CullFace {
mode BACK
}
}
referenceFrame RELATIVE
Matrix {
1 0 0 0
0 1 0 0
0 0 1 0
682985 5.21326e+006 0 1
}
num_children 1
Geode {
nodeMask 0x
cullingActive TRUE
num_drawables 1
Geometry {
PrimitiveSets 5
{
DrawArrays LINE_STRIP 0 5
DrawArrays LINE_STRIP 5 5
DrawArrays LINE_STRIP 10 5
DrawArrays LINE_STRIP 15 5
DrawArrays LINE_STRIP 20 5
}
VertexArray Vec3Array 25
{
218.39 263.092 0
...
-19.3272 -195.515 0
}
ColorBinding PER_VERTEX
ColorArray Vec4Array 25
{
0.001251 0.563585 0.193304 1
...
0.808741 0.585009 0.479873 1
}
}
}
}
}
}
* where can i find them?
* and whats the prefered way to access them finally in my application?
i think it can be done both with a visitor (osg::Drawable::AttributeFunctor::apply() like in the osgprerender example), and with a getChild().getVertexArray()
Thanks in advance,
christian
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=8702#8702
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] distant nodes in orthographic projection turn black
It's not erratic, it's pretty strongly correlated to the projection
matrix settings (determining the zoom level), camera distance and size
of the icon.
I looked at the icon model, from inspecting the .osg file (converted
from .ive with osgconv) it appears that the relevant state settings are:
GL_CULL_FACE ON
GL_LIGHTING ON
GL_NORMALIZE ON
Material {
DataVariance STATIC
ColorMode OFF
ambientColor 1 0 0 1
diffuseColor 1 0 0 1
specularColor 0 0 0 1
emissionColor 0 0 0 1
shininess 0
}
From what I can tell from reading the OpenGL documentation and looking
at the OSG code, this means it should ignore any per-vertex colors and
just use the material settings, correct? Does it still need a color array?
The normals looks fine:
NormalBinding PER_VERTEX
NormalArray Vec3Array 6
{
0 0 1
0 0 1
0 0 1
0 0 1
0 0 1
0 0 1
}
The original .ive file was produced using OSGExp with 3D Studio Max 2008
(the plugin is still using OSG 1.2, though.)I don't have much
control over whether it outputs materials or per-vertex colors, unless I
go and noodle around with the nodes in code after loading them. I
suppose I could modify a file by hand to see if it makes a difference.
Another thing I noticed is that all the icons go black just before the
camera zooms far enough that the icons are too small to render --
although in that case, it isn't very noticeable because the icons are
already only a few pixels across on screen.
Also, I forgot to mention in my previous email but I'm using Open Scene
Graph 2.6.1.
Thanks,
- Peter
Robert Osfield wrote:
Hi Peter,
Irratic changes of lighting + colour of objects in the scene as your
move the camera is typically due missing normals or colour arrays on
the geometry in the scene that is behaving oddly, as these missing
arrays will mean that their settings will be inherited from geometries
that just happen to be rendered before them. Have a look at the
problem geometry to see if that it have any normal or colour arrays,
and if they don't add them in.
Robert.
_
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] support for kdtree in polytope intersector?
Has there been any work adding support for KdTrees to the PolytopeIntersector? A quick search of the mailing list came up with a discussion about a year and half ago but no indication if there has been any work since then. I know that the version of OSG I am presently using (2.9.5) doesn't support it. My application works with large point cloud data sets, on the order of hundreds of thousands of points in a single geode, and as a result doing a single mouse pick with the current naive polytope intersector takes on the order of 5-10 seconds to complete (in debug mode, fwiw). I would be motivated to add support for this to OSG if no one else has done so already. -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] support for kdtree in polytope intersector?
Peter Hrenka wrote: If you can split up your point cloud into multiple Geodes you should already see a speedup with PolytopeIntersector as it can take advantage of available bounding volume information. Well, in order to do that I would have to sort the points into some kind of reasonable bounding hierarchy. My application works with point scan data collected by a high resolution laser scanner and includes a surface reconstruction mesh, so to split up the data set would also require duplicating points to avoid creating seams in the mesh. Not insurmountable, but more work. Also in my application usually the entire data set is visible, so there are no culling/rendering benefits to splitting up the data (unless it is faster for some reason to have 'n' vertex buffers of size 'm' instead of one 'n*m' VBO?) Still, I'd also like to see Kd-Tree support for PolytopeIntersector. I do not have much time to do this myself but I could offer some hints and perform testing if you choose to implement it. Ok, I will take a look at it. -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] testing for multisampling capability
I'm trying to enable 4x multisampling in my application. When running on systems with decent video drivers this is a simple matter of setting traits-sampleBuffers when I create the graphics window and it just works. Unfortunately in testing I've run into a system with an integrated Intel graphics driver that appears to not support multisampling -- I get pixel format error when I try to create the graphics context. I need to fall back and disable multisampling in this case, but presently in our application this requires that the user edit an external xml configuration file. Ideally it should be able to probe the driver features to determine if multisampling is available. What is the best way to do this in Open Scene Graph? I tried creating the graphics window, testing for failure, and if so disabling multisampling and trying again. Unfortunately, in testing this approach on a different system I ran into a problem -- it seems that once you've requested a graphics context with one multisampling setting, you can't ask for a different setting? I created a multisample graphics context, forced the initialization to be considered to fail, deleted the context, then asked for a non-multisample context (with all the same settings), then reports an invalid pixel format on trying to change the multisample settings. It's very weird. I'm sort of out in the weeds, here. It would be nice if there was some way to use OSG to ask the driver what it supports rather than having to play guessing games with graphics context initialization. Does anyone have any ideas? Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] determine record type from OpenFlight files?
I am loading an OpenFlight file using osgDB and I need to do some additional processing based on the specific record types, specifically terrain and roads. From looking at the OpenFlight loader in osg 2.6, it seems that this information is read by OSG (there is a flag indicating terrain and roads have a special record type) but I cannot figure out how to access this information from the scene graph that is actually returned by osgDB::readNodeFile() -- it does not appear that this information is set in the node's UserData. Does anyone have any suggestions on how to get this information? Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] IntersectVisitor vs IntersectionVisitor
Something I just came across, trying to figure out why my line-of-sight tests were not using KdTrees: Would I be correct in thinking that osgUtil::IntersectVisitor is the old and deprecated way of doing intersection tests, and osgUtil::IntersectionVisitor is the new way to do it? Is there a reason (besides backwards compatibility) for IntersectVisitor to even still exist? Also, what's the difference between osgUtil::IntersectionVisitor and osgSim::LineOfSight? Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] line intersection performance
A couple of other questions related to intersection performance: 1) The current KdTree implementation is just for sorting triangle geometry at node leaves. Perhaps it would be useful to to have a KdTree organize the scene graph nodes themselves, based on bounding volumes? Or are bounding volume tests generally good enough (and it's up to the user to be clever about organizing the scene graph?) 2) I need to do line-of-sight tests where I am only interested in whether any intersection exists, and not what those intersections are. This allows for a trap door optimization where the search process terminates on the first positive intersection. Is there a way to do that with the current osgUtil::IntersectionVisitor, or do I need to modify it to serve this purpose? Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] line intersection performance
Hi Jean-Sébastien, Jean-Sébastien Guay wrote: So the answer IMHO would be that in any case, you will want to try and build a good scene graph (both for culling performance and intersection performance). Whether you want to make a global kd-tree for the whole scene will depend on how dynamic your scene is, and if you can take the time to implement it so that only parts that change need updating. In my case I am reading OpenFlight files produced by a third party, so I don't have much control over whether it was constructed efficiently or not. Since the terrain will be static, my thought was to build a mostly static KdTree of scene graph nodes separate from the normal rendering state graph and to be used for culling and intersection tests. I believe a number of other 3D engines use this approach. However my question was really whether something like this already existed in OSG, to which the answer is no. This is not implemented currently. It's another one of those little projects I'd like to do eventually. It's what some publications call test-intersection vs find-intersection. Test-intersection: If all you want to know is if something intersects (for example, for shadow tests in raytracing) some shortcuts can be taken. Find-intersection: If you really want to find all objects that intersect (and potentially then sort by distance so you can get the closest one) (for example, for the main rays in raytracing) then you'd do it more or less the way it's done right now. If you want to implement test-intersection, you could subclass IntersectionVisitor/LineSegmentIntersector, or you could do it directly in these classes as an option and then submit it to OSG. :-) I do need this feature, so I will look into implementing it in osgUtil::IntersectionVisitor. This should be as simple as setting a flag, I think, and modifying the traversal to return as soon as an intersection is found. I will let the list know how it goes. Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] IntersectVisitor vs IntersectionVisitor
Thanks Robert. For anyone on this list using Delta 3D: I actually ran into this because Delta 3D 2.2 dtCore::Isector wrapper still uses osg::IntersectVisitor instead of osgUtil::InteresctionVisitor. I've informed the Delta 3D team that this is obsolete and should be updated. Peter Robert Osfield wrote: HI Peter, On Fri, Apr 24, 2009 at 6:14 PM, Peter Amstutz peter.amst...@tseboston.com wrote: Would I be correct in thinking that osgUtil::IntersectVisitor is the old and deprecated way of doing intersection tests, and osgUtil::IntersectionVisitor is the new way to do it? Is there a reason (besides backwards compatibility) for IntersectVisitor to even still exist? OsgUtil::IntersectVisitor only exists for backwards compatibility. Reviewing the headers right now reveals that the deprecated status wasn't mention so I've just added this and checked it into svn/trunk and OSG-2.8 branch Also, what's the difference between osgUtil::IntersectionVisitor and osgSim::LineOfSight? osgSim::LineOfSight is a higher level classes that manages line of sight calculations and handling of paged databases automatically. IntersectionVisitor is used within the LineOfSight class. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenFlight, subsurfaces and PolygonOffset settings
Hi Robert, I have seen this problem (in my case manifested by having the road draw on top of buildings (!) next to the road) in OSG 2.6 so I am glad to know it is a bug in the OpenFlight loader. In my application, I have had success with osg::PolygonOffset(1.0f, 4.0f) to push the terrain below the roads (rather than the roads above the terrain; I thought I read somewhere that negative values in glPolygonOffset are not allowed but I guess I was mistaken). I presume that osg::PolygonOffset(-1.0f, -4.0f) applied to the roads would produce the same effect. I also have the roads in a separate render bin that renders after the terrain and set the depth test function on roads to be LEQUAL instead of LESS to ensure that z buffer ties are broken in the favor of the road surface. - Peter Robert Osfield wrote: Hi OpenFlight users, I had a support email this morning that led me to investigate problems with the way the OSG's present OpenFlight plugin handles subsurfaces. The particular problem observed was that a road that had been modelled in creator was clipping out vehicles on top of the road. I investigated and found out that the OpenFlight loaded was created used code from src/osgPlugins/OpenFlight/GeometryRecords.cpp: 386 static osg::ref_ptrosg::PolygonOffset polygonOffset = new osg::PolygonOffset(-10.0f, -40.0f); 387 stateset-setAttributeAndModes(polygonOffset.get(), osg::StateAttribute::ON); 388 389 static osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::LESS, 0.0, 1.0,false); 390 stateset-setAttribute(depth.get()); The use of static vars was a bit dodgy so I replaced these with variables stored in Document, but this is really just an side show to the real problem - the excessive PolygonOffset settings, a factor of -10, and units -40 is very aggressive a setting pushing out the subsurfaces way further than is either necessary or safe. Scaling these values back to -1, -1 resulted in my better results on the models I have without causing problems with the subsurfaces having z fighting. -1, -1 may be too conservative though. I'd like to get feedback from the community on what works for your OpenFlight models. I've checked in my changes into svn/trunk and the OSG-2.8 branch. It'd be useful to import OpenFlight models and convert to .osg or .ive and then update the OSG version + compile it, then redo the conversion, then compare the before and after results. As an another little aside, in testing on my ATI card I found that the original hack that was introduced into osg::PolygonOffset, to try and cope with implementations differences of glPolygonOffset between ATI and NVidia, now is doing more harm than good. Commenting out this hack so that glPolygonOffset values are passed identically produces the best results for me. I never got to try out the hack first hand before I got this ATI card, and I never got really definitive feedback on how the previous settings were working. It does seem appropriate to now revert this old hack though, looks like ATI cards/drivers are behaving much more similar to NVidia now which is a good thing. On all these counts I really like feedback. Was sub surfaces working OK for you prior to my changes today, or do todays changes improve things? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] line intersection performance
Robert Osfield wrote: If your data is stored in a flat group the osgUtil::Optimizer spatialize groups visitor will be able to build a quad tree for you. Oh excellent, just what I had in mind :-) Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] determine record type from OpenFlight files?
I haven't looked at how DescriptionList is used in other parts of OSG, but my thought was to use it with a key prefix, so the record type and other metadata would be stored like OpenFlight_Record=Geometry or OpenFlight_Record=Road or OpenFlight_isTerrain=True. To avoid the problem you describe, the OpenFlight exporter will need to be aware of the DescriptionList entries produced by the importer. More generally, is there a particular reason for DescriptionList to be an array of strings and not an associative array, like pairstring, string (or even a map, but that is a slightly heavier data structure)? As I mentioned I need to store custom attributes alongside scene graph nodes and presently I am using UserData for this -- which is actually rather problematic because UserData is not saved to the .ive file. Right now I merge the custom attributes from a separate XML file, but I frequently have problems getting the external attributes file and scene graph to line up (various things like to add container nodes at the top of the scene graph, so the attributes file will be off by a node or two). Thanks, - Peter Paul Martz wrote: I just realized... One issue with DescriptionList is that the OpenFlight plugin uses it for Comment record data. This is really only a problem if you load a FLT file, store the record type in the DescriptionList, and then export it back out. Your record type data would then be exported as comment records, which is probably not what you want. I don't really see this as a showstopper issue though. Go for it. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Peter Amstutz Sent: Friday, April 24, 2009 11:38 AM To: OpenSceneGraph Users Subject: Re: [osg-users] determine record type from OpenFlight files? Hmm, I never noticed the DescriptionList feature before -- I presume DescriptionList gets saved to and loaded from .osg and .ive files? That would simplify some other work I did to add custom attributes to nodes (which I acomplished using UserData, but it is a bit more complicated). I will take a look at the OpenFlight importer. Thanks, Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] using AABB instead of bounding sphere for intersection tests?
Is there a way to use an axis-aligned bounding box (AABB) for the coarse bounding volume rather bounding spheres, for line segment intersections? In my application my primary geometry is made up of terrain tiles which are naturally axis aligned and buildings which tend to be rectangular prisms. In both cases, my intuition is that even the worst-case AABB is still going to represent a much tighter bound than the best-case bounding sphere, leading to unnecessary and expensive tests against the actual geometry. It's not clear that simply reorganizing and optimizing the scene graph would help much in this case, since the buildings are clustered in a town such that bounding spheres will naturally tend to overlap, as well as extend out into the street. Any ideas on how to handle this situation more efficiently? Thanks, - Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] using AABB instead of bounding sphere for intersection tests?
Chris 'Xenon' Hanson wrote: I think the reason for the bounding spheres is that it is a very efficient-to-compute formula -- many times more efficient than AABB. Are you worried about intersection efficiency during cull phase, or during intersection testing, or where? Have you actually experienced a measurable problem or are you speculating that there will perhaps be one? I am specifically concerned with overall line segment intersection performance. What I am actually trying to accomplish is to use OSG as the backend terrain engine for my application. Presently we use OSG for the frontend visualization and a separate in-house library for backend terrain queries -- this consists of line-of-sight tests, getting elevation, and testing for collisions to support agents interacting with the simulated environment. For maintenance purposes (less duplicated code) we want to replace the in-house library with one based on OSG , but preliminary tests have OSG intersection query performance taking about twice as long as our in-house library on the same data set (source data is OpenFlight). I'm trying to dig into the reasons that OSG intersections might be slower, and one of the first things that I noticed was the fact that our in-house library uses only hierarchical AABBs at all levels, whereas OSG uses mostly bounding spheres until getting down to the drawable level. My goal is to optimize OSG to be on par or better with our in-house library. I am curious if anyone else is using OSG for a similar purpose? Thanks, - Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering a series of nodes in precise order...
Hi Robert, This is ironic (so much so I initially read your email as being sarcastic) since the original scene graph, SGI Inventor, was sensitive to the ordering of nodes in the scene graph, and I always assumed that rendering as depth first traversal was the default way to do it. Getting away from being order sensitive to reorganize rendering for performance is one of the innovations of later rendering engines like OSG :-) I agree that SceneGraphOrderRenderBin would be a useful tool, it gives the user a trap door to describe rendering in a way that's closer to how it would be done in straight OpenGL. - Peter Robert Osfield wrote: HI Mathias, Wow I haven't ever thought of SceneGraphOrderRenderBin before. I have just done a quick review of RenderBin and CullVisitor and while it won't be trivial to implement (it requires mods to CullVsitor/StateGraph/RenderBin and StateSet) it should be too difficult to implement, and it would certainly make certain types of techniques far simpler to create and fast at runtime too. Leave this with me, once I completed some other work I'll have a look at the implementation. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] crash on window resize with ATI, win32, multithreading
This is perhaps not a OSG bug specifically, but I thought I would ask the community on the chance that someone has run into this problem and has found a solution -- I have a multithreaded application where the OpenGL graphics window is embedded in Windows Forms application. The main thread creates the control and handles the window messages, while a second thread continuously renders the scene using OSG. The problem comes when resizing the window. On NVidia and Intel cards, resizing works as one would expect. On ATI cards (or at least the Radeon HD 3450 I have here), however, it immediately crashes the on the next iteration of the rendering loop. It crashes on an opengl drawing call, and the stack traces leads through atioglx2.dll. Some details: - The supportsResize window trait when creating the graphics context is true. - I am intercepting the WM_WINDOWPOSCHANGING event (which is ostensibly sent prior to the window changing for real) and acquiring a lock on the rendering loop, so presumably no rendering occurs while the window is being resized by the operating system. - I'm calling osgViewer::GraphicsWindow::setWindowRectangle() with the new size - I tried osg::GraphicsContext::clear() which sets glViewport and glScissors, but that didn't seem to help. - I'm creating the graphics context in the main thread -- creating the context in the rendering thread presented its own troubles. - I've tried making the graphics context current to the main thread just for the duration of the resize. No luck. - I have a different single-threaded OSG app which has gives no difficulties with resizing the rendering context on the same computer. The workaround I have developed is to completely re-create the graphics context when the window is resized. This works, but has a couple severe drawbacks: it is quite slow (so there is a big hiccup when resizing the window) and it causes all kinds of problems because the texture, display list and VBO handles are all invalidated, but osg still thinks they are valid, so I have to explicitly tell OSG to flush all GL objects (and even then I get stray reports from users of textures showing up on the wrong surfaces or 3D models all out of whack...) So does anyone have any idea how to appease the gremlins inside the ATI driver so that the OpenGL context can be safely resized? - Peter ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to do shadows in large scenes?
Thanks, I'll have to determine if upgrading to osg 2.9.10 is feasible for my project. Or perhaps osgShadow could be backported to osg 2.8.3? After writing that email, I also discovered osgShadow::StandardShadowMap and osgShadow::LightSpacePerspectiveShadowMap, both of which work quite a bit better than osgShadow::ShadowMap. On 1/3/2011 1:45 PM, David Callu wrote: I Peter, PSSM is probably the best choice for large scene. PSSM technique have been fixed in osg 2.9.9 or 2.9.10 for minor bug. If you didn't see shadow in your scene with this technique, this probably a bug in your code. Take a look to osgshadow example to know how use it. You have to run osgshadow --pssm to see pssm in action. HTH David Callu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgShadow clipping shadows cast from off-camera objects
Hello all, I am trying to add dynamic shadows to my scene and so far osgShadow::LightSpacePerspectiveShadowMapVB seems to produce the best results [*]. Unfortunately, one problem I am encountering is that shadows cast by geometry located to the side or behind the camera get clipped, leading to a number of artifacts. For example, standing outside a building with the sun to your back, the shadow map correctly projects the outline of a doorway onto the floor. However, once the camera enters the building, the wall is clipped and this causes the entire room to be illuminated. This is a very noticeable and undesirable effect. How can I mitigate this problem? [*] I had high hopes for PSSM based on reading about the technique but so far neither osg 2.8.3 nor 2.9.10 produce correct results for me. Thanks! -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow clipping shadows cast from off-camera objects
That parameter is exactly what I was looking for, thanks! On 1/5/2011 3:36 PM, Wojciech Lewandowski wrote: Hi Peter, Try using MinLightMargin parameter. May help somtimes. Look at the attached picture for its meaning. Cheers, Wojtek Lewandowski -Oryginalna wiadomość- From: Peter Amstutz Sent: Wednesday, January 05, 2011 7:37 PM To: OpenSceneGraph Users Subject: [osg-users] osgShadow clipping shadows cast from off-camera objects Hello all, I am trying to add dynamic shadows to my scene and so far osgShadow::LightSpacePerspectiveShadowMapVB seems to produce the best results [*]. Unfortunately, one problem I am encountering is that shadows cast by geometry located to the side or behind the camera get clipped, leading to a number of artifacts. For example, standing outside a building with the sun to your back, the shadow map correctly projects the outline of a doorway onto the floor. However, once the camera enters the building, the wall is clipped and this causes the entire room to be illuminated. This is a very noticeable and undesirable effect. How can I mitigate this problem? [*] I had high hopes for PSSM based on reading about the technique but so far neither osg 2.8.3 nor 2.9.10 produce correct results for me. Thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] different rendering states for different passes?
Hello all, I have a bit of a knotty problem and was hoping for some advice. I am using OSG 2.8.3. I am using osgShadow::LightSpacePerspectiveShadowMapVB, which renders the scene in two passes; the prerender stage renders the shadow map, the main state renders the scene. My understanding is that the behavior of the two passes is controlled by setting different shader programs at the scene root, which sets the default shader program for the whole scene. However, I am also using shader programs at some of my leaf nodes. I would like it to accept shadows, so it needs to read the shadowTexture uniform. However, this uniform is only available on the main drawing pass, not the prerender pass (since the purpose of the prerender pass is to generate the shadow texture). The problem I am encountering is the fact that my shader program does not have a way to distinguish between executing the prerender pass and the main pass, and attempts to read the (non-existent) shadowTexture uniform in the prerender pass, which causes a GL error and results in the node not showing up at all. I know the solution is to use different shaders for different passes, but I haven't figured out the right way to set up OSG to do this at the leaf. Can anyone point me in the right direction? -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Shadows in OSG
I suggest looking at StandardShadowMap, MinimalShadowMap and the various LiSPSM variations; based on my experience with osg 2.8.3 they offer the most robust implementation of shadows. There is also a debugging mode that you can enable that renders the depth map which is extremely useful. As Wojtek said, dynamic shadows are a pretty advanced topic, you will need a good theoretical understanding before diving into the particulars of how osg manages it. On 1/17/2011 8:42 AM, Linda Lee wrote: Hi, How about learning the way OSG structures the shadow code. I found it difficult understanding how OSG manage shadow. Could anyone briefly explain the shadow codes in OSG or is there any way I could learn more on them? Thank you! Cheers, Linda -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35694#35694 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PSSM cascaded shadow maps
So far I've tried osg 2.8.3 and 2.9.10 and have not been able to get any results using the parallel split shadow map technique. Is anyone using PSSM currently and have any suggestions? I am presently using LiSPSM, it works pretty well but I since I am rendering a large outdoor scene I find that need to set a far clip plane in order to get acceptable resolution for the shadowed volume, as a result shadows pop at the far plane. Cascaded shadow map techniques like PSSM are supposed to address this problem. Ideally, osg should have a generalized cascaded shadow map class which would allow specializations for the various methods of partitioning the shadowed scene. -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visitor concept. No finalize?
If it's so important it get called automatically, why can't you run your finalize code in the destructor? On 1/25/2011 3:36 PM, Sam Warns wrote: Hi, that is exactly the point. My RemoveXVisitor SHOULD remove nodes but since it is not possible to do that in apply and there is no finalize method that gets automatically called after accept has finished, it is only possible to remove nodes by providing a custom member which the user must call manually. That is what I am talking about, it is not possible for a Visitor to do certain things without having the user explicitly call members of it after the accept call. I did not demand a finalize method and I understand Robert's statement that flexibility is achieved by relying on the user. Never the less would a finalize method decrease any flexibility and power of it. (Btw: I have never experienced that handing over responsibility to the user (which is the developer at this point) produced any good results, but this is only my experience) Thanks, Sam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35965#35965 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
Some kind of user data hooks are necessary, since the user is always going to need a way to map the results of operations like IntersectVisitor back to the application domain. The benefit of adding a baseline metadata system as standard (as opposed to the current do-what-ever-you-want situation with UserData) is for it to be supported and interoperable by non-core but broadly used libraries and plugins such as osgDB reader/writers that have a narrow interface (e.g. osgDB::readNode()). On further consideration, I think that storing metadata separately from nodes may cause more problems than it solves unless there are additional management elements. Path-based methods are brittle under changes to the scene graph and approaches that refer to nodes by memory address fail in corner cases like clone operations. A more robust solution might be to have every osg::Node assigned a platform-independent unique id or turn that around and have each metadata entry have a unique id to which osg::Node can refer. Scene graph serialization already has to assign unique ids to support shared nodes. However the simplest solution I can think of would be to provide a standard osgUtil::Metadata object designed to go into the existing UserData field, which would provide a property-oriented data structure as I described in my earlier email. Serialization reader/writers would be enhanced to read/write osgUtil::Metadata from the UserData field if present. For applications that already use UserData for something else, or don't need metadata, there would be no change to existing behavior. On 2/1/2011 10:20 AM, Sukender wrote: Hi Gordon and Paul, Yes, you're right to say the a scene graph is not designed to handled something else than the scene. However, yes, this is a philosophical question... what is a scene, then? I belive a scene is not only what is displayed, but includes metadata too. Usages are many. For instane, you may compute an intersection using the scenegraph, and grab information on the elements you picked. Or you may dynamically change scene's properties (say LOD view distance) depending on some data somewhere... Of course, I certainly do not want to put something too intrusive, or (worse) something which would cause a performance loss. So what? Well I think OSG should provide some tools to ease the management of metadata. Not necessary something deeply tied with the graph, but maybe utilities. But even if I agree with the fact metadata should be handled in a separate structure to avoid polluting the main graph, I do not fint this solution satisfactory. What if I delete a node? References to the node are invalidated, and child-number indices are also invalidated. I would thus need a mechanism to make sure everything is coherent. Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Gordon Tomlinson gtomlin...@overwatch.textron.com a écrit : I have to agree with Paul, the Scene graph is just that. To renders data as fast and efficiently as possible OLD Performer handled some this by providing separate graphs for data and other information (while it was not close to perfect it did allow the clean separation that Paul is talking about and I agree with -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Discussion: metadata readerwriters output
I concur, in order to avoid disrupting existing users, metadata should only be read/written to if UserData is empty or already contains a metadata object. Possibly we could have an abstract metadata or de/serializable interface so that users could retroactively support their existing UserData objects without needing to use to the new classes for storage. I hear that osg 2.9/3.0 also has a new serialization framework for node files? (I'm using 2.8) With regards to implementation, I would be possibly be able to work on something as I do have a use for it, but I won't be able to get to it for several weeks at least. If someone has a more immediate need (Sukender?), they should step up. On 2/3/2011 11:21 AM, Sukender wrote: Hi Bob, Ulrich is right: you could move your data as a metadata. However I guess that we should not break existing code. (De)Serializers should NEVER overwrite existing userData, they should only be allowed to add metadata it userData points to a meta container. So if you already use userData, then you simply won't be able to add metadata. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Ulrich Hertlein u.hertl...@sandbox.de a écrit : On 3/02/11 3:47 , Bob Youmans wrote: What will the users do, who current utilize the userData in the node for their own specialized purposes? Is this going to break our models? I don't see a reason why user-data shouldn't be stored as another type of meta-data. So it should be fully compatible with user-data, both API-wise and serialization to/from disk. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] IFC to OSG converter
You probably still want to implement osgDB::ReaderWriter. You can still use a standalone import/export program that loads the IFC file using osgDB::readNode() and saves to IVE using osgDB::writeNode(), such as osgconv or your own specialized import and visualization tool. On 2/8/2011 8:17 AM, Peter Kilpatrick wrote: Hello Sukender, It is a standalone program that reads an IFC file, displays the spatial structure tree and creates an OSG scene graph which can be output. IFC files tend to be very large and take a long time to load so standalone is better. The resulting .ive files are much smaller and load much faster. Regards, Peter -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Can I increment the gl_FragData?
My understanding is no, in general in GLSL you cannot read from the same buffer you are writing to. The reasoning is that you can have multiple shader units potentially rendering the same pixel in parallel and/or rendering pixels that will never actually be drawn on screen due to z-buffering, so reading from the buffer would have undefined behavior (Z-buffer tests and blending are handled by dedicated hardware). You want to render your first pass to a pbuffer and use that as an input texture to the second pass. However I believe a simpler solution in your case would be to enable blending and set your blending equation to GL_FUNC_ADD so that results of subsequent passes are additively combined with pixels from the previous pass. On 2/21/2011 9:52 AM, Martin Großer wrote: Hello, Have everyone experience with the gl shading language? I would like to do something like that on my texture (I use render to texture): gl_FragData[0] += vec(0.01,0,0,1); Is that possible? I want to increment the color in my texture in every render pass (in this case the red channel). I don't want to copy back to the cpu memory. And I use the FRAME_BUFFER_OBJECT. I guess the gl_FragData[0] is in every render pass zero (black). Is it possible to change that? Cheers Martin -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG plugin for browsers
On 4/7/2011 5:30 AM, Thibault Genessay wrote: Other people have thought of alternatives to display 3D content: - osgjs - which re-implements the OSG in Javascript. Although the API is very close to the C++ one, it is not a way to embed an OSG app in a browser - webGL. If I am not mistaken, this leaves out the OSG entirely, and only aims at displaying 3D models. Kind of a new VRML thing. Just to clarify, WebGL consists of Javascript bindings for OpenGL, which are used by osgjs for rendering. So if you already have a C++ program, you would need to port it to javascript in order to use such libraries. Possibly you could emit opengl calls from the C++ server side and execute them in the client with WebGL, but that would be pretty bandwidth intensive and subject to lag. Broadly speaking, if the goal is to execute native code using OSG in the browser, you're going to run up against all the security, hardware architecture etc problems that plague all such efforts. My preference would be for a solution that transmits the scene graph to the browser to be rendered using something like osgjs and the server sends scene graph updates, but that is somewhat complex and difficult to do transparently as osg lacks the necessary value changed hooks to record the changes that occur in the scene graph from frame to frame. -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
My initial impression is that this seems pretty well thought out, but a little incomplete. Some comments: - The ComponentContainer interface is lacking a way to iterate over all values. - The add/find/delete methods on ComponentContainer should take the owner osg::Object as a parameter. This is necessary if you want to share a single ComponentContainer instance across many nodes, for the case where the ComponentContainer is actually a front end to a separate data store. - For serialization, storing simple value types is pretty straightforward. The harder part is dealing with compound types (structs/classes) and/or containers (map/vector). Perhaps there is a way to leverage osgIntrospection? On 4/15/2011 6:30 AM, Sukender wrote: [cross-post osg-users/osg-submissions] Hi Robert, hi all, We often discussed about handling name-value pairs in core OSG. Now it's time for action! Grégoire Tarizzo and I wrote a first specification document about a metadata system. We would like you (I mean all those interested in the subject) to review it and give your feeling and feedback. Please take this document as an advanced proposal. We *WILL* for sure code a first version of the meta-data system. But even if we tried to cover most aspects and most usages, wee need you to ensure this submission to be widely accepted. Thank you very much. Happy reading! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Put the dynamic_castT inside the method. On 4/15/2011 10:53 AM, Sukender wrote: Hi Peter, Well observed. We'll add methods to iterate and a pointer to object. But we just spotted a flaw in our design: we wrote some virtual templated methods (which is impossible of course)... Any idea on how to return a T* in ComponentContainer::findFirstMeta()? Sukender -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for large
arrays. C++ 2011 move constructors are intended to solve this problem
in general, but it's unlikely that OSG compatibility requirements will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this will force
you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
On 4/19/2011 5:49 AM, Sukender wrote:
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
You're right, that is confusing. Here's a better way to compare the
alternatives:
templateT void addMeta(const std::string, const ValueT v) {
// Supports v as a subclass of ValueT
ValueT* localcopy = v.clone();
}
templateT void addMeta(const std::string, const T v) {
// Can only customize ValueT through template specialization
ValueT* localcopy = new ValueT(v);
}
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Immutable means cannot be changed. So I mean that the Value class
should not have a set method and all get methods should be const. E.g.
templateT
class Value {
private:
T v;
public:
Value(const T _v) : v(_v) { }
const T get() { return v; }
// type conversion operator, so you can write
// Valueint a(5);
// int b = a;
const T operator T () { return v; }
};
On 4/19/2011 5:46 AM, Sukender wrote:
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant to be
derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you mean you
preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
I think the metadata system under discussion will be useful for associating scene graph nodes with their owner entities. This is necessary for various scene-graph oriented operations like picking, custom culling, etc that need to refer back to your application domain entities . You certainly could use it to store your entity components, but that should be up to the user. I think we need to be careful to avoid scope creep. This discussion does bring up one related issue, though. Regarding serialization, I had been thinking that the metadata system should only be allowed to contain data that can be safely serialized. I realize now that is wrong, for precisely this issue that the metadata system will be used to hold pointers to application domain entities that are opaque to the serialization system. Peter On 4/20/2011 8:30 AM, Sergey Kurdakov wrote: Hi Sukender, However I think the entity thing is far more high level than just metas. that is correct. still there is need to assemble metas as objects into something useful and also exchange info ( message system ). this functionality might be a separate addition, but it's presence ( or considering it's use with metas; I'm not sure, but it might add some additional fields, methods etc ) will greatly extend 'use' cases to jump start to apply your metas in projects. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Sorry about that, you sent out the previous email on the weekend and I didn't have a chance to look at it; when Monday rolled around I had forgotten about it. Regarding the Value class, I think I understand the difference of opinion a little better. Let me present both sides. // Option A. Value types are osg::Referenced and mutable osg::ref_ptrValueint v = container-getMetaint(foo); assert(v-get() == 3); v-set(5); assert(v-get() == 5); - A value object can be held by many nodes. Changing it in once places affects all nodes. - Similar to how other reference counted elements of the scene graph work, e.g. osg::Uniform - ValueT will probably need a parent list to track its owners - Awkward to map metadata values onto a database. In addition to getMeta() and setMeta(), must derive from ValueT or come up with a callback interface to tie to the data store. - Potential for race conditions if a thread changes the contents of value while another thread is using it // Option B. Value types are not refcounted and immutable Valueint v = container-getMetaint(foo); assert(v == 3); node-setMetaint(foo, 6); assert(v == 3); assert(node-getMetaint(foo) == 5); - A value object cannot be held by multiple nodes. If you want to logically share a value across nodes, must store a pointer or id into a separate table as the value. - Similar to non-reference counted elements of the scene graph. - ValueT can be very simple and doesn't need to track or backreference anything. - Straightforward to map to a database, only need to implement getMeta() and setMeta() - No race condition concerns. Laying it out like this, I could support a design going either way. However my instinct is to prefer immutable data structures as a general rule as they tend to reduce programming errors (especially when threads are involved). I also think the metadata facility should be simple and easy to extend by implementing a new MetadataContainer class rather than putting in complicated hook/callback/proxy mechanisms that try to handle everything. I think the next step should be to put together some header files / class definitions so that we can discuss the proposed API in specifics. - Peter On 4/27/2011 10:09 AM, Sukender wrote: Hi Peter, hi all, We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? Peter, when you told about immutability, it was with a database backend in mind, right? If so, I think it may be better not to have immutable Values. Indeed, DescriptionList and more generally user data may be mutable. So to get this database backend wokring properly, I think one should: - Define a ValueDB, derivate from ValueBase. - Define a DBProxy, derivate from ComponentContainer (well, we renamed it ValueContainer to avoid misinterpretation) - Make DBProxy give ValueDB when getting - Make ValueDB know DBProxy so that modifying a ValueDB will call appropriate method in DBProxy - Make DBProxy also accept ValueT as an input, and convert it to appropriate SQL/request/whatever Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ --- -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] OSG C#
If you're using standard Visual Studio, using C++/CLI interop to write managed (ref) classes that interop with OSG and are callable from C# is going to be the most powerful approach. In order to render into a Windows Forms control, you create an empty control, get the native HWND and provide it to osgViewer. If you are using Visual Studio Express or Mono, or hate C++, you need to deal with osgWrappers and P/Invoke and unsafe memory management, which is going to be considerably more brittle. On 4/27/2011 3:50 AM, Sander Lan wrote: Hi, Does anyone have experience with using OpenSceneGraph in a C# environment? Thank you! Cheers, Sander -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38802#38802 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert,
This looks pretty straightforward and I agree that less complexity is
good. However a would modify it slightly to support two related
features I have been lobbying for, which are the ability to share
UserDataContainers between osg::Objects, and the ability to subclass a
custom UserDataContainer implementation.
The idea is that there is generally not a 1:1 correlation between the
application entity model and the scene graph. Because of this, one
often wants to be able to share or inherit metadata information, or look
up metadata on the fly to avoid copying large amounts of application
data into the scene graph.
I think it feasible to add one level of indirection without adding too
much complexity. For example:
- Make osg::UserDataContainer a pure abstract class.
class OSG_EXPORT UserDataContainer : public osg::Referenced
{
public:
void addUserObject(Object* owner, Object* obj) = 0;
void setUserObject(Object* owner, unsigned int i, Object* obj) = 0;
void removeUserObject(Object* owner, unsigned int i);
unsigned int getUserObjectIndex(Object* owner, const osg::Object* obj)
const = 0;
unsigned int getUserObjectIndex(Object* owner, const std::string name)
const = 0;
Object* getUserObject(Object* owner, unsigned int i) = 0;
const Object* getUserObject(Object* owner, unsigned int i) const = 0;
Object* getUserObject(Object* owner, const std::string name) = 0;
const Object* getUserObject(Object* owner, const std::string name)
const = 0;
unsigned int getNumUserObjects(Object* owner) const = 0;
};
- Provide a default implementation which doesn't do anything with the owner
field
class OSG_EXPORT DefaultUserDataContainer : public UserDataContainer
{
ref_ptrReferenced _userData;
b DescriptionList _descriptionList;
ObjectList _objectList;
public:
void addUserObject(Object* owner, Object* obj) {
_objectList.push_back(obj);
}
/* etc */
};
- The methods implementated in osg::Object just forward to the container along
with the owner:
void osg::Object::addUserObject(Object* obj) {
if (!_container) {
_container = new osg::DefaultUserDataContainer();
}
_container-addUserObject(this, obj);
}
void osg::Object::setUserObject(Object* owner, unsigned int i, Object*
obj) {
if (!_container) {
_container = new osg::DefaultUserDataContainer();
}
_container-setUserObject(this, i, obj);
}
/* etc */
- osg::Object also gains a couple of new methods:
osg::UserDataContainer* osg::Object::getUserDataContainer();
osg::Object::setUserDataContainer(osg::UserDataContainer*);
Does this seem reasonable?
- Peter
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hello Robert,
Thank you for taking up this task. While not central to the mission of
graphics rendering, this feature will certainly make writing
applications around OSG a little bit easier for all of us.
My proposal for putting get/setUserValue convenience methods directly
osg::Object was based on the idea that the interface methods on
osg::UserDataContainer would accept the parent object as a parameter,
thus allowing a single container instance to be shared while providing
different data to different callers. Without that aspect, having
get/setUserValue on osg::Object still offers some convenience but also
introduces confusion and redundancy. Also, the ability to set any
osg::Object as the metadata container for any other osg::Object seems
like an invitation for chaos.
I think the pattern you describe as
object-getUserDataContainer()-get...() is acceptable, and is
perfectly consistent with the existing scene graph patterns in OSG
(setting up StateSets in particular comes to mind -- indeed recently
someone wanted to use StateSets as an ad-hoc metadata scheme).
My preference looks like:
class osg::Object {
// access _userDataContainer
osg::UserDataContainer* getUserDataContainer();
void setUserDataContainer(osg::UserDataContainer*);
osg::UserDataContainer* getOrCreateUserDataContainer();
// for backwards compatibility, defer to _userDataContainer
virtual get/setDescriptions();
virtual get/setUserData();
};
// abstract base class user data container
class osg::UserDataContainer : public osg::Object {
// returns self
osg::UserDataContainer* getUserDataContainer();
osg::UserDataContainer* getOrCreateUserDataContainer();
// throws exception/assertion or otherwise fails
void setUserDataContainer(osg::UserDataContainer*);
// return data on this object
virtual get/setDescriptions();
virtual get/setUserData();
// Abstract metadata interface
virtual get/setUserValue() = 0;
};
// Default implementation, used by
osg::Object::getOrCreateUserDataContainer()
class osg::StdUserDataContainer : public osg::UserDataContainer {
virtual get/setUserValue() { ... }
};
This seems very straightforward and avoids cluttering up osg::Object.
Is there a reason this approach was rejected, aside from a desire to
avoid the object-getUserDataContainer()-get...() pattern?
If a single user data container instance is referenced by multiple
nodes, will it be serialized once or multiple times?
Can a user data container contain references to osg::Objects in the same
scene graph? Can the serializers handle this?
Again, your work is very much appreciated!
Thanks,
Peter
On 6/7/2011 9:51 AM, Robert Osfield wrote:
Hi All,
After my first cut of the new osg::Object::UserData functionality I've
been pondering on how best to provide the ability to customize the
data storage container, if at all. Simplicity and performance are the
key reasons for not providing the ability to customize the data
storage container as it enevitablly requires use of virtual functions
for data access, extra classes and public methods for these.
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, once again, we all really appreciate your work on Open Scene Graph and on picking up this feature in particular. I've reviewed the new check in, comments below -- On 6/9/2011 9:33 AM, Robert Osfield wrote: With the C pointer trick in the bag it became a simple refactor of the osg::Object and osg::UserDataContainer interfaces and implementations, with the s/getUserObject(..) access methods moving from osg::Object into pure virtual UserDataContainer base class. The setUserData/getUserData() stay put in osg::Object but are virtual to allow the UserDataContainer to override them. The Description list access methods were then moved back into osg::Node, keeping the osg::Object cleaner and avoiding the conceptual overlap between osg::Object and UserDataContainer. Finally a DefaultUserDataContainer implementation is provided, and is almost identical to my original UserDataContainer. I noticed that DefaultUserDataContainer does not set the parent _userDataContainer field to this, nor does it override getUserDataContainer() / setUserDataContainer(). I suppose this allows meta-data about meta-data, but it means that calling getUserValue() / setUserValue() on a UserDataContainer will not work that way you would expect, because it will pass through to the underlying chained _userDataContainer field which is empty instead of setting data fields on the UserDataContainer itself. One suggestion of Peter's that I have gone with is passing in an osg::Object* to the UserDataContainer methods that would have enabled him to share a single custom UserDataContainer implementation between objects in the scene and have the custom container work the correct data for each object. I rejected this suggestion in my previous email and still feel it's inappropriate. If one does want centralized access to user data associated with objects then there is no reason to place this in the scene graph - if you are going to have a data structure that is mapping Object pointers to internal data objects then it's global operation already, it's not something that needs or should be distributed throughut the scene graph. Even if one did create such a global mapping I'm doubtful that a Object pointer would even be the appropriate key is to use to access it as pointers to Object change when being serialized in and out - so re-run your app and all your pointers are different for the same scene graph objects. For this type of task I would lean towards have a user manage unique ObjectID that is used as the key, and the natural place to put this would be... in a custom UserDataContainer. I have come to the same conclusion. I'm satisfied with the current design now (except for the comment above). -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131h ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
On 6/9/2011 11:54 AM, Robert Osfield wrote:
I debated setting the UserDataContainer's _userDataContainer to itself but it
woudl create a circular reference so ceratinly a no go.
Potentially you could override the Object::s/getUserDataContainer
methods to return self
but would in itself introduce an inconsistency between how objects and
containers behave.
I also have no objection to UserDataContainer's having their own User
data objects
nested within them.
I can't think of a use case for allowing a UserDataContainer to have its
own separate UserDataContainer (meta-meta-data?). If you need to chain
them together or be nested, you can just as easily have an entry in the
user data object list point to another UserDataContainer.
I understand the circular reference problem with setting
_userDataContainer to this, so overriding get/setUserDataContainer()
and ignoring _userDataContainer seems like a reasonable solution to me.
Making _userDataContainer a private (not protected) field of osg::Object
prevents end-runs around subclasses that overrides getUserDataContainer().
I have attached a patch which makes
osg::UserDataContainer::getUserDataContainer() and related methods
return this as I describe above.
In the patch, get/setUserValue() call getUserDataContainer() and use the
container that is returned, rather than accessing _userDataContainer
directly. This means the behavior will defer to the embeded
_userDataContainer by default except when the object is itself a
UserDataContainer, in which case get/setUserValue() operate on the
object itself.
Arguably this is slightly inconsistent, but I think it is much more
useful and desirable behavior than manipulating the _userDataContainer
itself embedded in _userDataContainer.
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
Index: include/osg/Object
===
--- include/osg/Object (revision 12513)
+++ include/osg/Object (working copy)
@@ -122,17 +122,17 @@
/** set the UserDataContainer object.*/
-void setUserDataContainer(osg::UserDataContainer* udc);
+virtual void setUserDataContainer(osg::UserDataContainer* udc);
/** get the UserDataContainer attached to this object.*/
-osg::UserDataContainer* getUserDataContainer() { return
_userDataContainer; }
+virtual osg::UserDataContainer* getUserDataContainer() { return
_userDataContainer; }
/** get the const UserDataContainer attached to this object.*/
-const osg::UserDataContainer* getUserDataContainer() const { return
_userDataContainer; }
+virtual const osg::UserDataContainer* getUserDataContainer() const {
return _userDataContainer; }
/** Convinience method that returns the UserDataContainer, and if one
doesn't already exist creates and assigns
* a DefaultUserDataContainer to the Object and then return this new
UserDataContainer.*/
-osg::UserDataContainer* getOrCreateUserDataContainer();
+virtual osg::UserDataContainer* getOrCreateUserDataContainer();
/**
@@ -186,10 +186,10 @@
std::string _name;
DataVariance _dataVariance;
+private:
+
osg::UserDataContainer* _userDataContainer;
-private:
-
/** disallow any copy operator.*/
Object operator = (const Object) { return *this; }
};
Index: include/osg/UserDataContainer
===
--- include/osg/UserDataContainer (revision 12513)
+++ include/osg/UserDataContainer (working copy)
@@ -158,9 +158,6 @@
/** Get the index position of first user data object that matches
specified name.*/
virtual unsigned int getUserObjectIndex(const std::string name,
unsigned int startPos=0) const;
-
-
-
/** Set the list of string descriptions.*/
virtual void setDescriptions(const DescriptionList descriptions);
@@ -175,6 +172,18 @@
/** Add a description string.*/
virtual void addDescription(const std::string desc);
+
+/** Not allowed to set user data on a user data. */
+virtual void setUserDataContainer(osg::UserDataContainer* udc) { }
+
+/** Return self */
+virtual osg::UserDataContainer* getUserDataContainer() { return this; }
+
+/** Return self */
+virtual const osg::UserDataContainer* getUserDataContainer() const {
return this; }
+
+ /** Return self */
+virtual osg::UserDataContainer* getOrCreateUserDataContainer() {
return this; }
protected:
Index: include/osg/ValueObject
===
--- include/osg/ValueObject (revision 12513)
+++ include/osg/ValueObject (working copy)
@@ -172,7 +172,9 @@
bool osg::Object::getUserValue(const std::string name, T value) const
{
typedef
Re: [osg-users] Basic Lighting Shaders
osgShadow::StandardShadowMap has a straightforward GLSL implementation of standard OpenGL lighting. On 6/23/2011 1:24 PM, Jeremy Moles wrote: I'm looking to collect some sample code from OSG users (if this code is shareable) for some basic lighting examples done purely in GLSL. If anyone is willing to share this (I can certainly adapt it, so there's no need to modify it), I'd be grateful. What I'm looking for mainly is how lighting code from source like the Orange Book are different/adapted to OSG. I've begun to compile OSG without support for the FFP, and I'm trying to work up a basic default set of shaders to emulate the FFP functionality. I'm very close, but I'm having trouble figuring out how exactly to caclulate the eye coordinate in my vertex shader when using osgViewer. Right now I'm using: eyePos = vec3(osg_ModelViewMatrix * gl_Vertex); ...but this starts to fall out of whack as I use the standard TracballManipulator. It works, of course, when in the home() position (and with a new ViewMatrix for the default camera with Y-up). Thanks! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] error building osga plugin in r12640
Visual Studio 2008, Windows 7 building svn revision 12640: 41OSGA_Archive.obj : error LNK2001: unresolved external symbol public: virtual class osgDB::ReaderWriter::WriteResult __thiscall OSGA_Archive::writeShader(class osg::Shader const ,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar const ,class osgDB::Options const *)const (?writeShader@OSGA_Archive@@UBE?AVWriteResult@ReaderWriter@osgDB@@ABVShader@osg@@ABV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PBVOptions@4@@Z) 41D:\OpenSceneGraph\build\bin\osgPlugins-3.1.0\osgdb_osga.dll : fatal error LNK1120: 1 unresolved externals -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Delighted to announce OpenSceneGraph-3.0.0!
Congratulations Robert and to everyone that contributed! On 6/28/2011 6:03 AM, Robert Osfield wrote: I'm chuffed to bit to be able to announce the OpenSceneGraph-3.0.0 release, a release long in incubation but well worth the wait - it's faster, more stable, extends portability to embedded and mobile platforms and has heaps of new features and refinements. To grab the source head over to the download page: http://www.openscenegraph.org/projects/osg/wiki/Downloads Or Zip file containing source code : http://www.openscenegraph.org/downloads/stable_releases/OpenSceneGraph-3.0/source/OpenSceneGraph-3.0.0.zip Subversion tag : svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.0 OpenSceneGraph The press release is rather muted really... considering just how big a step forward over 2.x series is, but he it is, feel free to suggest ways to sell the changes a little more flamboyantly: http://www.openscenegraph.org/projects/osg/wiki/News/Press/OSG3.0 What is amazing is how much 3.0.0 is a community effort, since the 2.8.0 release we've seen 91 new contributors provide new features, refinements, build and bug fixes, with a staggering total number of contributors standing at 464! I can't include thanks to them here, but all the contributors are listed up on our contributors page: http://www.openscenegraph.org/projects/osg/wiki/Support/Contributors/ThreePointZero If your are one of those contributors, or one of the unsung heroes that pitched in with testing you should feel proud to have been part of making 3.0.0 what it is today - the worlds most portable and feature rich scene graph technology. A big thank you to all that have helped, and to everyone have fun with the new release, I think it's pretty darn awesome :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg exporter, blender problems
Hi Dmitry, You want to download: https://github.com/cedricpinson/osgexport/blob/master/blender-2.5/build/osgexport-0.13.0.zip And use install addon on the .zip file. You will also need to enable it after you install it. By the way, I have a fork with some additional features related to armatures and animation, but you'll have to copy the scripts into your blender scripts folder yourself: https://github.com/tetron/osgexport On 10/21/2012 2:38 PM, Dmitry K. wrote: Hi, I have finally completed simple geometry and texture tutorial and now I try to load complex geometry like character. Everything works OK with .obj file but it is loaded extremely slow. But I have another question. I've tried both plugins by Cedric Pinson and from Blender Projects Page (http://projects.blender.org/frs/?group_id=19release_id=335#osgexport-2-42-title-content). In Blender 2.63 I go to the preferences window and choose addons tab, then click install addon and choose .py file. Then I look through the filter and exporters/importers section and can't find it. I tried to copy the file to scripts/addons folder of Blender but it doesn't appear. There were also such problems with OGRE exporter. What is wrong? Thank you! Cheers, Dmitry -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50702#50702 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi Robert, Would you consider changing BIND_PER_PRIMITIVE code to do some kind of internal conversion to fast path rendering, such as expanding the arrays by 3x (duplicating the color or normal for each vertex) so that it can use the per-vertex rendering path? I have certainly written code where I wanted per-face coloring or sharp edged shading (same normal across the face) and PER_PRIMITIVE captures my intent better than using PER_VERTEX and having to duplicate the colors/normals. It's not a big deal, but having the concept handled by osg::Geometry is more convenient than handling it in client code --- as you've noted, even in the examples PER_PRIMITIVE is used quite a bit. - Peter On 6/4/2013 5:14 AM, Robert Osfield wrote: On 4 June 2013 09:42, Robert Osfield robert.osfi...@gmail.com wrote: My current action plan is to get GeometryNew.cpp to build and run with the osggeometry example I have now got my quick clean up of Geometry as GeometryNew class with osgeometry compiling and running correctly. My GeometryNew class removes support for vertex indices. My next step is to look at BIND_PER_PRIMITIVE. While vertex indices aren't actually used in the core OSG BIND_PER_PRIMITIVE is quite widely used in the examples. They really shouldn't be though as it means that they are all forces slow paths in osg::Geometry. I don't know yet whether to check in GeometryNew, or whether to wait till I've done enough work to renamed the old Geometry to GeometryDeprecated and rename GeometryNew to Geometry. I'm currently inclined to do this work in stages and check in GeometryNew even if it's just a temporary class name. Again I welcome feedback from the community. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi Robert, This is totally reasonable and on balance I agree with your reasoning. I thought the feature deserved a little discussion before being sent quietly into the night :-) On 6/4/2013 9:44 AM, Robert Osfield wrote: I believe that a fast path only osg::Geometry is worthy enough goal to explicitly drop all slow path support, so it only supports what modern OpenGL can support with no clever emulation being hidden behind the scenes. This does mean the convenience of things like vertex indices and BIND_PER_PRIMITIVE have to be dropped, to deal with this I don't think new osg::Geometry should bend to accomodate, rather we should seek out ways of making it more convenient to create osg::Geometry - I call upon the community to make suggestions about help classes. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to detect scene changes?
Hi Ale, There is no such capability built-in. You need to build your own layer on top to manage changes to the scene graph. You should write your own manipulator (or modify an existing one) to route changes through your change management layer, rather than having it change the underlying transform node directly. I have found the best practice is to treat osg as just the display layer it is intended to be, and not to try and use it as your application's primary data model. Good luck, Peter On 11/4/2013 10:02 AM, Ale Maro wrote: Hi, I am trying to find a way to detect any changes of the scene graph automatically? I would like to implement an undo/redo mechanism and also I would like to know when my scene changes and needs to be saved. For example I would like a callback is called when a manipulator changes a transformation node (avoiding modification on manipulators) Is there something already implemented in OSG that can help me? Thank you! Cheers, Ale -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=57063#57063 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] 3.0.1 stutters on SwapBuffers
Hello all, I have a performance regression with 3.0.1. My application works fine with 2.8.3, but with 3.0.1 I am getting very severe framerate stutter. This seems to be linked to specific positions/orientations of the camera, when in a dead zone the framerate drops below 1 FPS, but slight adjustments in rotation, or moving forward or back causes framerate to jump back up to the expected performance. This does not seem to be linked to specific elements in the scene, and happens consistently across different scenes. The hang up seems to be in the call to SwapBuffers(). This occurs on both debug and release builds. I've used gDEBugger to try and diagnose the difference between rendering a slow frame and a fast frame, but in comparing the OpenGL function call logs, I haven't been able to discover any obvious differences expect for the matrices used (glLoadMatrixd). I'm using Visual Studio 2009 on Windows 7 x64 (however OSG and my app are compiled for x86) and with a Radeon HD 3400. Does anyone have any idea what could be going on? -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow PSSM light source issue
I noticed this problem as well. To fix this I modified PSSM to use the same code as the selectLight() method in StandardShadowMap. However osgShadow's PSSM implementation has a lot of other quirks as well... On 3/23/2012 5:47 AM, Daniel Schmid wrote: I have an issue with PSSM. The light source in my scene is not taken into account properly (sun). It calculates shadows like if sun as in perfect orbit. All other shadow implementations work correctly, and changes in light position are calculated correctly, but PSSM is stuck somehow. Does anybody know this problem ? Regards Daniel ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help! Particles in OSG 3.0.1 flip halfway through their lifetime...
I did encounter this, and I did track it down. The quick fix is that you probably have a line in your particle system .osg file that looks like this: textureTile 1 1 1 To fix the problem, you need to change it to this: textureTile 0 0 0 Slightly longer explanation: OSG is interpreting the file slightly differently than it did in 2.8. The textureTile parameter controls changing the texture over the life if the particle, and in OSG 2.8 the particle generator only lists textureTile 1 1 1 it was interpreted as a single texture for the life of the particle. In osg 3.0 it is interpreted as the *second* tile (tile index 1), the first being tile index 0. Since no tile 0 is actually specified, OSG creates a default tile 0. What is happening is that partway through the life of the particle, it switches from tile 0 to tile 1. Through some mechanism I don't now recall, this causes a transform to be applied to the texture coordinates, which is why the particle texture gets flipped. Hope this helps, - Pete On 6/8/2012 11:06 AM, Nick Jones wrote: Hi, My project has recently upgraded to OSG 3.0.1. We have a set of particle systems that we have been using for a while. After upgrading to OSG 3.0.1 from OSG 2.8.1, however, I noticed something strange with the way the particles are being updated. It seems that halfway through the particles' lifetimes, they flip vertically. In example, I created a simple particle with an image of an arrow pointing up. When I run this particle in OSG 2.8.1, the arrow remains pointing up throughout the end of its lifetime. When I run it in OSG 3.0.1, the arrow starts off pointing up but then suddenly points down at about the halfway mark in its lifetime. It remains pointing down until the particle is extinguished. Attached in the .zip file is the .osgx of the particle system. If you run it in OSG 3.0.1, you'll notice the flipping. If you convert it to an .osg file and run it in OSG 2.8.1, you'll notice that it does not flip. Has anyone run into this issue before? System Information: OSG 3.0.1, Ubuntu 10.04 Thank you! Nick -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=48141#48141 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
