Re: [osg-users] [osgPlugins] OSGT does not read nodemask
Hi, ok, got it. Posting fix to osgSubmission. Actually only the std::showbase and std::noshowbase where missing in the osgDB::PropByValSerializer Code: if ( _useHex ) os std::hex std::showbase; os value; if ( _useHex ) os std::dec std::noshowbase; Thank you! Cheers, Johannes[/code] --- Johannes Scholz Software Engineer P3 Voith Aerospace GmbH, Bremen, Germany -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49487#49487 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trying to make Qt HUD inside OSG scene
I had a certain amount of bother messing about with this code last week. In the end, I found out that the OpenSceneGraph Cookbook example set up its InteractiveImageHandler for a 2D overlaid widget with just new osgViewer::InteractiveImageHandler(widgetImage.get()); rather than new osgViewer::InteractiveImageHandler(widgetImage.get(), texture, camera); as the bundled OSG example does. The latter was automatically resizing stuff and causing all manner of trouble. -Original Message- From: Robert Osfield Hi Max, Just place the OSG/Qt widget subgraph below an orthographic Camera to create the HUD effect you are after. See the osghud example. Robert. On 16 August 2012 09:26, Max Sergeev sergeev.m...@gmail.com wrote: Hello! I'm kind of newbie in both OSG and Qt, still I'm trying to make Qt HUD upon my OSG window, what I want is Qt interface elements fixed inside OSG scene, not spinning with the model. The thing is, I need Qt elements INSIDE osg scene, not OSG scene inside Qt window (like in OSGviewerQt example). What I've got yet is OSGQtWidgets example with --useWidgetImage --fullscreen arguments, which shows fixed Qt controls ontop of OSG Model. The thing is, it creates new (FIXED) camera for qt element ontop of OSG model -- because of that, user cannot spin and move OSG model because camera is not transparent. So the question is: is there a way to make transparent camera with useable Qt elements in it? Or is there some other way to achieve my goals? Thank you in advance! Cheers, Max ___ 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 culling with shader tranformed geometry?
Hello Sebastian. Sebastian Messerschmidt wrote: For this i used the setComputeBoundingBoxCallback on the geometry in question to set it to the correct bounding box. Maybe you could use this on your first-class Node? Hm, maybe. Unfortunately the documentation to Drawable::setComputeBoundingBoxCallback(..) does not say anything about how often this callback is called and what is the tirgger (if called on demand). I thought this callback is desired for dynamic geometry, which can change (nearly) per frame. I still think the idea of one or more independent cull-camera(s) and separate draw-camera is not that bad. Does anyone know: Is possible to realize that using build in OSG tools? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49490#49490 ___ 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 culling with shader tranformed geometry?
Am 24.08.2012 11:42, schrieb Alexej Fink: Hello Sebastian. Sebastian Messerschmidt wrote: For this i used the setComputeBoundingBoxCallback on the geometry in question to set it to the correct bounding box. Maybe you could use this on your first-class Node? Hm, maybe. Unfortunately the documentation to Drawable::setComputeBoundingBoxCallback(..) does not say anything about how often this callback is called and what is the tirgger (if called on demand). I thought this callback is desired for dynamic geometry, which can change (nearly) per frame. The callback will be called if the bounds are marked as dirty. (i.e. if a new PrimitiveSet is added). In my use case I simple set the callback, called getBounds once on the parent and then removed the callback after loading and before attaching the node to the scenegraph. I can do this safely as I know that the instanced geometry set is not changed in any way. cheers Sebastian I still think the idea of one or more independent cull-camera(s) and separate draw-camera is not that bad. Does anyone know: Is possible to realize that using build in OSG tools? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49490#49490 ___ 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] Last frames modelview matrix
Hello, I'm trying to implement per object motion blur in my deferred pipeline. In order to get this right, I need the modelview matrix from the previous frame per node. To get it I was thinking about using an updateCallback per node that should contribute to the motion blur. Unfortunately I think this will get too expensive, as I have to compute the local to world per call. Also is the updateCallback called if the camera moves? If not I have to install an callback that is called per frame .. Any suggestions how to get the last frames modelview matrix? cheers Sebastian ___ 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 culling with shader tranformed geometry?
Sebastian Messerschmidt wrote: The callback will be called if the bounds are marked as dirty. (i.e. if a new PrimitiveSet is added). In my use case I simple set the callback, called getBounds once on the parent and then removed the callback after loading and before attaching the node to the scenegraph. I can do this safely as I know that the instanced geometry set is not changed in any way. cheers Sebastian Thanks, this sounds reasonable. One more point. I really don't care about culling on the Drawable-instances level. Can I setup the bboxes just for the parent grouping nodes and have nothing at the drawable level, is it possible? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49492#49492 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Last frames modelview matrix
Hi, Sebastian you can get (already computed by cullvisitor) modelview matrix in cull callback. But i think you are overcomplicating things with this approach. Cheers, Sergey. 24.08.2012, 14:07, Sebastian Messerschmidt sebastian.messerschm...@gmx.de: Hello, I'm trying to implement per object motion blur in my deferred pipeline. In order to get this right, I need the modelview matrix from the previous frame per node. To get it I was thinking about using an updateCallback per node that should contribute to the motion blur. Unfortunately I think this will get too expensive, as I have to compute the local to world per call. Also is the updateCallback called if the camera moves? If not I have to install an callback that is called per frame .. Any suggestions how to get the last frames modelview matrix? cheers Sebastian ___ 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] [osgPlugins] osgShadow LiSPSM culling problem
Hi Garret, On 23 August 2012 19:28, Garrett Cope garrett.cope@simcen.usuhs.edu wrote: Attached are two screen shots. 'shadow_before' is the base state with a box casting a perfectly fine shadow. 'shadow_after' is where I have rotated the camera such that the box has moved out of view to the right. In this image you can see another clipping edge beginning at the bottom of the shadow that moves relatively vertically as the box continues to rotate to the right of the viewing window. Thanks for the screenshots, unfortunately it doesn't quite provide enough clues to know what might be amiss. Could you output a small model that using the osgshadow example can be used to recreate the issue? You can record a camera path with osgshadow by pressing 'z' to start and 'Z' to finish, this then writes out a file saved_animation.path, you can then replay this in osgviewer/osgshadow using the command line option -p saved_animation.path. As with the LiSPSM implementation, if I comment out the clipping section (here in adjustPerspectiveShadowMapCameraSettings(..) function), it looks fine but of course is then not clipped at all. It sounds like the light space extents isn't being fitted properly, or there is an error in the adjustment of the shadow map projection matrix for the light space extents. Debugging these issues requires models that can recreate the issue though, there isn't really anything I can do without being able to reproduce the problem. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Last frames modelview matrix
Hi Sergey, Hi, Sebastian you can get (already computed by cullvisitor) modelview matrix in cull callback. But i think you are overcomplicating things with this approach. Okay, I hadn't thought of this. So you propose adding a cull-callback to all the nodes that should contribute? And surely I felt that the approach was too complicated, thats why I was asking ;-) cheers Sebastian Cheers, Sergey. 24.08.2012, 14:07, Sebastian Messerschmidt sebastian.messerschm...@gmx.de: Hello, I'm trying to implement per object motion blur in my deferred pipeline. In order to get this right, I need the modelview matrix from the previous frame per node. To get it I was thinking about using an updateCallback per node that should contribute to the motion blur. Unfortunately I think this will get too expensive, as I have to compute the local to world per call. Also is the updateCallback called if the camera moves? If not I have to install an callback that is called per frame .. Any suggestions how to get the last frames modelview matrix? cheers Sebastian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to do culling with shader tranformed geometry?
Am 24.08.2012 12:09, schrieb Alexej Fink: Sebastian Messerschmidt wrote: The callback will be called if the bounds are marked as dirty. (i.e. if a new PrimitiveSet is added). In my use case I simple set the callback, called getBounds once on the parent and then removed the callback after loading and before attaching the node to the scenegraph. I can do this safely as I know that the instanced geometry set is not changed in any way. cheers Sebastian Thanks, this sounds reasonable. One more point. I really don't care about culling on the Drawable-instances level. Can I setup the bboxes just for the parent grouping nodes and have nothing at the drawable level, is it possible? I've tried this via setCullingActive(false) on the Node, but I'm not quite sure if this the correct way to do this. Following documentation it should disable small feature/frustum culling. Maybe Robert can give some insights here. Cheers Sebastian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49492#49492 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to do culling with shader tranformed geometry?
On Fri, Aug 24, 2012 at 6:09 AM, Alexej Fink dk...@gmx.net wrote: Sebastian Messerschmidt wrote: The callback will be called if the bounds are marked as dirty. (i.e. if a new PrimitiveSet is added). In my use case I simple set the callback, called getBounds once on the parent and then removed the callback after loading and before attaching the node to the scenegraph. I can do this safely as I know that the instanced geometry set is not changed in any way. cheers Sebastian Thanks, this sounds reasonable. One more point. I really don't care about culling on the Drawable-instances level. Can I setup the bboxes just for the parent grouping nodes and have nothing at the drawable level, is it possible? No, you need to apply it on the drawables, otherwise they will still get culled. I created some utilities to support DrawInstanced usage in osgEarth, including a visitor that will apply the static bounding box to drawables. Perhaps it would be useful to you: http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstancedhttps://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpphttps://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp Glenn Waldron / Pelican Mapping / @glennwaldron ___ 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 culling with shader tranformed geometry?
gwaldron wrote: No, you need to apply it on the drawables, otherwise they will still get culled. I created some utilities to support DrawInstanced usage in osgEarth, including a visitor that will apply the static bounding box to drawables. Perhaps it would be useful to you: http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced (https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp) http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp (https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp) Do I understand your approach right: That you set the same static bbox for each drawable by setting the same calcBBox callback for a group of Drawable instances? If so. Although this is an other interesting work around. It still does not reduce the culling effort visiting each Drawable instance, which I would like to avoid, since it is meaningless in my setup -- culling on the parent group node would be sufficient. Can I use some cull-callback to prevent the culling visitor to go deeper to the single Drawables and cull based only on the group node bbox? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49499#49499 ___ 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 culling with shader tranformed geometry?
Hi Can I use some cull-callback to prevent the culling visitor to go deeper to the single Drawables and cull based only on the group node bbox? there are problem: cullvisitor grabbing drawables for later drawing, and if you dont go deeper, nothing would be drawed Cheers. 24.08.2012, 17:24, Alexej Fink dk...@gmx.net: gwaldron wrote: No, you need to apply it on the drawables, otherwise they will still get culled. I created some utilities to support DrawInstanced usage in osgEarth, including a visitor that will apply the static bounding box to drawables. Perhaps it would be useful to you: http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced (https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp) http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp (https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp) Do I understand your approach right: That you set the same static bbox for each drawable by setting the same calcBBox callback for a group of Drawable instances? If so. Although this is an other interesting work around. It still does not reduce the culling effort visiting each Drawable instance, which I would like to avoid, since it is meaningless in my setup -- culling on the parent group node would be sufficient. Can I use some cull-callback to prevent the culling visitor to go deeper to the single Drawables and cull based only on the group node bbox? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49499#49499 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to do culling with shader tranformed geometry?
On Fri, Aug 24, 2012 at 9:24 AM, Alexej Fink dk...@gmx.net wrote: gwaldron wrote: No, you need to apply it on the drawables, otherwise they will still get culled. I created some utilities to support DrawInstanced usage in osgEarth, including a visitor that will apply the static bounding box to drawables. Perhaps it would be useful to you: http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced( https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp ) http://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp( https://github.com/gwaldron/osgearth/blob/master/src/osgEarth/DrawInstanced.cpp ) Do I understand your approach right: That you set the same static bbox for each drawable by setting the same calcBBox callback for a group of Drawable instances? If so. Although this is an other interesting work around. It still does not reduce the culling effort visiting each Drawable instance, which I would like to avoid, since it is meaningless in my setup -- culling on the parent group node would be sufficient. Can I use some cull-callback to prevent the culling visitor to go deeper to the single Drawables and cull based only on the group node bbox? Look at CullVisitor::apply(Geode) to see how it works. I believe your drawables have to return a valid bound since CV uses that to calculate near/far clipping planes, renderleaf depth, etc. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] osgShadow LiSPSM culling problem
Hi Robert, I haven't been able to reproduce my specific problem with the osgshadow example, but I have been able to reproduce all kinds of weird clipping planes. Just none that are resolved by commenting out the aforementioned section. For instance, if I set the default light direction in the example to pretty much anything other than 0,0,1 (for instance: 0,-1,1) and then rotate the model around with the manipulator, the shadows get clipped along strange lines. I will keep trying to reproduce my specific instance of the issue. Thanks again for the help, Garrett -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49501#49501 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture Questions
I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? 2) If it is enabled, how many levels are created by default? 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I have to make some empty node and apply the texture to it to do this? 5) Is there any way to send a texture down to the graphics card prior to applying it to geometry? 6) Any other efficiency things I should be looking at? Karl Cary SAIC Software Developer 301-227-5656 ___ 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 culling with shader tranformed geometry?
hybr wrote: there are problem: cullvisitor grabbing drawables for later drawing, and if you dont go deeper, nothing would be drawed Cheers. The point is: At the group node it can be already decided, if the underlying nodes are visible or not. Thus no need to compare against each single Drawable's bbox for refinement. So I would like to tell the cull-visitor: Take all underlying drawables, if the group-node bbox passes (or skip all, if not). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49503#49503 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Last frames modelview matrix
The main problem you'll have with the update callback approach is that it won't work in a multi-view mode (where one view is split across multiple displays/windows). In a multi-view mode, the view half of the modelview matrix is potentially different for each window. If this is an issue, then the CullVisitor approach (as Sergey suggests) is the right thing to do. You'll need to store the modelview matrix in an array indexed by the context ID. This gets a little complicated, but it's possible. If you have a simpler single-window rendering scenario, then using the update callback seems like it would be much simpler. The main problem is accessing the root Camera node; each update callback needs access to the Camera in order to get the view matrix. Assuming you can solve that small problem, then each update callback would have logic like this: Take last frame's modelview from member variable, and set as the value of a Uniform for use by your shader. Get current view matrix from Camera Get current model matrix (local to world) from NodeVisitor Multiply them together to get current frame's modelview matrix Store in member variable for use during next frame Hope that helps. -Paul On 8/24/2012 4:07 AM, Sebastian Messerschmidt wrote: Hello, I'm trying to implement per object motion blur in my deferred pipeline. In order to get this right, I need the modelview matrix from the previous frame per node. To get it I was thinking about using an updateCallback per node that should contribute to the motion blur. Unfortunately I think this will get too expensive, as I have to compute the local to world per call. Also is the updateCallback called if the camera moves? If not I have to install an callback that is called per frame .. Any suggestions how to get the last frames modelview matrix? cheers Sebastian ___ 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] Resetting OSG state when managing own context
Hi All, I've a question or two regarding rendering contexts. While the usage is OSX specific, the question is not. I'm rendering into a CAOpenGLLayer (I can't render directly to a NSOpenGLView because I'm also using CALayer objects within the view - and these conflict with the NSOpenGLView, at least in my experience). In essence this means I manage the OpenGL context, create an osg::Viewer and use the setupViewerAsEmbeddedInWindow method. I have no problem using the context created by CAOpenGLLayer (I'm basing my code on the existing CocoaViewer which essentially does the same thing), I do have problems when the context which OSG is now using needs to be reset. In CAOpenGLLayer, a context reset can be caused by (for example) a user moving the window to another screen. In this case the context might be recreated because CAOpenGLLayer wants to use either a different graphics card or a different pixel format. From what I can gather, while I'm managing the real OpenGL context myself, OSG is managing it's own texture ID's (and I presume other scene OpenGL resources). When the real OpenGL context is reset, OSG still believes all of it's existing resources to be valid, because I've not explicitly told it otherwise. From this I have two questions: a) How do I tell OSG to throw away it's managed resources (texture ID's, etc), such that they are recreated at the next render pass? Can I do this? Is it even wise? Or should I be looking to throw away the viewer and recreate it? b) Instead of the above, should I rather have OSG manage it's own context and then after each OSG render pass copy the rendered result to the layer? For (b) I was considering rendering to a texture backed FBO, then DMA'ing that texture to RAM. I'd then DMA that back into the CAOpenGLLayer context. Thus OSG wouldn't have to be concerned at all with what the layer is with it's context, nor context resets. This (to me) sounds like a reasonable idea. It'd keep the OSG engine separated from the CAOpenGLLayer side of things, and would allow OSG to manage everything about it's rendering pipeline. The only part I don't like is the additional texture-copy to get the result into another context. p.s: The scene being drawn is small, with only many hundreds of vertices and 100 textures. Thank you! Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49506#49506 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Resetting OSG state when managing own context
Hi All, I've a question or two regarding rendering contexts. While the usage is OSX specific, the question is not. I'm rendering into a CAOpenGLLayer (I can't render directly to a NSOpenGLView because I'm also using CALayer objects within the view - and these conflict with the NSOpenGLView, at least in my experience). In essence this means I manage the OpenGL context, create an osg::Viewer and use the setupViewerAsEmbeddedInWindow method. I have no problem using the context created by CAOpenGLLayer (I'm basing my code on the existing CocoaViewer which essentially does the same thing), I do have problems when the context which OSG is now using needs to be reset. In CAOpenGLLayer, a context reset can be caused by (for example) a user moving the window to another screen. In this case the context might be recreated because CAOpenGLLayer wants to use either a different graphics card or a different pixel format. From what I can gather, while I'm managing the real OpenGL context myself, OSG is managing it's own texture ID's (and I presume other scene OpenGL resources). When the real OpenGL context is reset, OSG still believes all of it's existing resources to be valid, because I've not explicitly told it otherwise. From this I have two questions: a) How do I tell OSG to throw away it's managed resources (texture ID's, etc), such that they are recreated at the next render pass? Can I do this? Is it even wise? Or should I be looking to throw away the viewer and recreate it? b) Instead of the above, should I rather have OSG manage it's own context and then after each OSG render pass copy the rendered result to the layer? For (b) I was considering rendering to a texture backed FBO, then DMA'ing that texture to RAM. I'd then DMA that back into the CAOpenGLLayer context. Thus OSG wouldn't have to be concerned at all with what the layer is with it's context, nor context resets. This (to me) sounds like a reasonable idea. It'd keep the OSG engine separated from the CAOpenGLLayer side of things, and would allow OSG to manage everything about it's rendering pipeline. The only part I don't like is the additional texture-copy to get the result into another context. p.s: The scene being drawn is small, with only many hundreds of vertices and 100 textures. Thank you! Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49508#49508 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Odd 1286 (GL_INVALID_FRAMEBUFFER_OPERATION_EXT) in my own context during a render update traversal
Thank you! It turns out that the reason was down to using an NSOpenGLView and CALayer at the same time. It. Just. Doesn't Work. That out the way, it works fine. I was only going ... slightly insane. Cheers, Neil -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49509#49509 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] OSGT does not read nodemask
Thanks Johannes, fix now merged and submitted to svn/trunk. On 24 August 2012 08:33, Johannes Scholz osg-supp...@vtxtech.net wrote: Hi, ok, got it. Posting fix to osgSubmission. Actually only the std::showbase and std::noshowbase where missing in the osgDB::PropByValSerializer Code: if ( _useHex ) os std::hex std::showbase; os value; if ( _useHex ) os std::dec std::noshowbase; Thank you! Cheers, Johannes[/code] --- Johannes Scholz Software Engineer P3 Voith Aerospace GmbH, Bremen, Germany -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49487#49487 ___ 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] [ANN] osgRecipes: Integrate OSG with almost everything, the second wave
Happy to see our stuff on the list! When you get to it, please be sure to grab the new 1.5 release of the Triton Ocean SDK and 2.5 of the SilverLining Sky, Cloud, and Weather SDK that came out this week. I overhauled the OSG integration samples on both to take advantage of separate update / cull / draw threads and to get rid of their reliance on an icky projection matrix callback. It's a lot cleaner now. Thanks, Frank Kane Founder, Sundog Software,LLC http://www.sundog-soft.com -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49512#49512 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Questions
Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I have to make some empty node and apply the texture to it to do this? To compress in a background thread you can use the OSG's now support for compressing textures using NVTT (there is plugin for this when you compile the OSG when the NVTT SDK is available). You'll need OSG-3.x for this. 5) Is there any way to send a texture down to the graphics card prior to applying it to geometry? You can pre-compile objects using the IncrementalCompileOperator, however, this is still done as part of the rendering thread so depending upon your requirements might not make a difference. 6) Any other efficiency things I should be looking at? Pre-processing data so that it's pre-mipmapped and using OpenGL compressed texture is the best way if you want to maximize performance throughput of textures as this reduces how much work the CPU and GPU need to do to download and use the data. OpenGL compression is less aggressive than compression supported by conventional image formats so the files on disk will be bigger. Robert. ___ 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 culling with shader tranformed geometry?
Hi Alexej, On 24 August 2012 14:41, Alexej Fink dk...@gmx.net wrote: The point is: At the group node it can be already decided, if the underlying nodes are visible or not. Thus no need to compare against each single Drawable's bbox for refinement. So I would like to tell the cull-visitor: Take all underlying drawables, if the group-node bbox passes (or skip all, if not). The OSG will automatically stop do the cull tests against the frustum sides once a frustum side totally encloses a subgraph, so there really isn't much to be gained by trying to be clever, it's already doing everything it can to be efficient w.r.t cull tests. Culling is import even down at the leaf level so there is still performance to be gained by leaving culling on right down to the leaf level. Not only does the OSG using the bounding box of the Drawable for culling it also uses to help compute the near/far ranges required to encompass the scene. So stop trying to be clever, you actually just outwitting yourself for no reason, you'll end up with crappy solution because you are over thinking things. JUST set the bounding box on the Drawable and let the OSG do it's stuff, it written this way for a reason. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trouble with LightSpacePerspectiveShadowMap artifacts.
Hi Dario, The issue looks like one of depth precision of the shadow map such that the depth test makes an erroneous judgment about whether the front surface is in shadow or not, this often is a surface self shadowing itself. The normal solution is to use a polygon offset in the shadow map generation so that the surface doesn't shadow itself, if this polygon offset is too small you still get the self shadowing artifact if the value is too large you no longer get shadows where you should see them. The better the depth precision of the shadow map the lower the polygon offset will be required, and in your case perhaps it's the ground layer that is very large and it part of the shadow casting scene to pushes out the depth range of the shadow map reducing it's precision. If this is the case then using the Cast/RecivesShadowMask functionality would be appropriate as this will you could use the mask to avoid the ground being used in the shadow map generation. Robert. On 24 August 2012 14:57, Dario Minieri para...@cheapnet.it wrote: Hi, I'm using a shadowed scene with LightSpacePerspectiveShadowMapCB technique with a single light. I've seen that in some positions of the camera, the shadows appear artifacts, while in other positions not. See snapshots. Moving the camera in a continuous manner, this results in an annoying shadows flickering on the objects. You have some kind of idea for that? GLSL Shadow shader issue? Graphix card issue? Other? Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49505#49505 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to do culling with shader tranformed geometry?
Hello Alexej, Robert I think the reason for Alexej to think that disabling the culling would improve render time in any way, is that he measuring the time of the cull traversal. Indeed the cull traversal time is culling + preparing the drawing of the geometries. I've fallen for this in the beginning. So maybe the problem lies with the number of drawables (i.e. there are too many too small batches). So being clever at this point would rather mean to make bigger yet fewer sets. cheers Sebastian Hi Alexej, On 24 August 2012 14:41, Alexej Fink dk...@gmx.net wrote: The point is: At the group node it can be already decided, if the underlying nodes are visible or not. Thus no need to compare against each single Drawable's bbox for refinement. So I would like to tell the cull-visitor: Take all underlying drawables, if the group-node bbox passes (or skip all, if not). The OSG will automatically stop do the cull tests against the frustum sides once a frustum side totally encloses a subgraph, so there really isn't much to be gained by trying to be clever, it's already doing everything it can to be efficient w.r.t cull tests. Culling is import even down at the leaf level so there is still performance to be gained by leaving culling on right down to the leaf level. Not only does the OSG using the bounding box of the Drawable for culling it also uses to help compute the near/far ranges required to encompass the scene. So stop trying to be clever, you actually just outwitting yourself for no reason, you'll end up with crappy solution because you are over thinking things. JUST set the bounding box on the Drawable and let the OSG do it's stuff, it written this way for a reason. 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] Using VBOs to provide data to vertex shader
Hi all,
As an experiment, I've created a heightfield whose tessellated geometry is
created on the CPU side (i.e. the (x, y) coordinates), but height is determined
by a vertex shader. I use a FloatArray to specify the height of each vertex,
and then call geom-setVertexAttribArray() to pass it to the shader.
Here's the code I'm using:
Code:
geom = new osg::Geometry;
// vertices and indices are pre-computed
geom-setVertexArray(vertices);
geom-setPrimitiveSet(indices);
osg::VertexBufferObject *heightMapVBO = new osg::VertexBufferObject;
heightMapVBO-setUsage(GL_DYNAMIC_DRAW);
heightMap = new osg::FloatArray(vertexCount);
heightMap-setVertexBufferObject(heightMapVBO);
// zero out heightMap
for (int i = 0; i vertexCount; i++) (*heightMap)[i] = 0;
// attach array to be used on a per-vertex manner
geom-setVertexAttribArray(1, heightMap);
geom-setVertexAttribBinding(1, osg::Geometry::BIND_PER_VERTEX);
// set vertex and fragment shaders
This code works perfectly when the heightmap remains static. However, if I try
changing the values of the heightmap, the rendered geometry doesn't reflect
those changes. Here is the code I use to alter the heightmap:
Code:
void addHeight(int x, int y, float inc) {
(*heightMap)[x + y*width] += inc;
heightMap-dirty();
}
Looking through the forums, I found osggpumorph, which uses the VBOs
automatically managed by geom instead. I altered my code accordingly:
Code:
geom = new osg::Geometry;
geom-setUseDisplayList(false);
geom-setUseVertexBufferObjects(true);
geom-setVertexArray(vertices);
geom-setPrimitiveSet(indices);
osg::VertexBufferObject *heightMapVBO = geom-getOrCreateVertexBufferObject();
heightMapVBO-setUsage(GL_DYNAMIC_DRAW);
heightMap = new osg::FloatArray(vertexCount);
heightMap-setDataVariance(osg::Object::DYNAMIC);
// ...
with the addHeight function changing to:
Code:
void addHeight(int x, int y, float inc) {
(*heightMap)[x + y*width] += inc;
// copy a new array over each time (this seems a little inefficient, but
maybe it's ok?)
geom-setVertexAttribArray(1, heightMap.get());
heightMap-dirty();
}
But I still don't see any changes in the heightmap. I can verify the shaders
are correct, because when I alter the heightmap the first time, everything is
drawn correctly. It just appears the updating the VBOs (CPU - GPU) isn't
working correctly.
Any suggestions on what I might be doing wrong would be greatly appreciated!
Thanks,
Abe[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49517#49517
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture Questions
I do have the ability to pre-process. The question is, what file formats support openGL compression and how do I take them from jpeg to these formats? As for mipmapping, you mentioned that it can be done CPU side. How do I initiate this? Since the texture load is happening in a separate thread, I can afford CPU time to do this rather than pushing more on to the GPU. I can test out to see if it is worthwhile. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Friday, August 24, 2012 11:40 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Texture Questions Hi Karl, On 24 August 2012 14:40, Cary, Karl A. karl.a.c...@saic.com wrote: I have an application that loads several 2048x2048 textures in a separate thread before passing off to the main to be applied to the geometry. I am trying to do anything and everything I can to improve performance on them as the number of textures will increase from several to quite a lot. So I am looking at every option I can and have run in to several questions that I was hoping to get some advice on. I am creating osg::Texture2D and loading them with an osg::Image read in from a jpg file. Excatly how many textures are you talking about? Will of the texture reside in memory and be rendered at the same time? Do you have an flexibility w.r.t pre-processing the image data into other file formats? What pixel format do the textures have? RGB? 1) Is mipmapping enabled by default? Or do I need to call allocateMipmapLevels? By default the osg::Texture* will use trilinear mipmapping, if the osg::Image doesn't contain the mipmaps then it'll either generate them on demand in the rendering thread either done by the GL driver or GPU using OpenGL extensions for generating mipmaps, or on the CPU using GLU functions when the driver doesn't support the generate mipmap extensions. You can switch the mipmapping off by just setting the texture-setFilter(Texture::MIN_FILTER, Texture::LINEAR); 2) If it is enabled, how many levels are created by default? osg::Texture* will automatically work out how many levels are required based on the dimensions of the texture. 3) Would changing the internal format mode to one of the compression formats actually perform the compression or does that need to be done manually? If the source imagery is not in an OpenGL compressed format then the driver will do the compression for you, however this is an expensive operation so generally not one you'd during rendering, rather OpenGL compression is something you'd want to do in pre-processing step. 4) If I do need to do the compression, how can I do it without applying it to geometry in my separate thread? I have only seen it done via the CompressTexturesVisitor applied to a node (as in osgconv), would I have to make some empty node and apply the texture to it to do this? To compress in a background thread you can use the OSG's now support for compressing textures using NVTT (there is plugin for this when you compile the OSG when the NVTT SDK is available). You'll need OSG-3.x for this. 5) Is there any way to send a texture down to the graphics card prior to applying it to geometry? You can pre-compile objects using the IncrementalCompileOperator, however, this is still done as part of the rendering thread so depending upon your requirements might not make a difference. 6) Any other efficiency things I should be looking at? Pre-processing data so that it's pre-mipmapped and using OpenGL compressed texture is the best way if you want to maximize performance throughput of textures as this reduces how much work the CPU and GPU need to do to download and use the data. OpenGL compression is less aggressive than compression supported by conventional image formats so the files on disk will be bigger. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using VBOs to provide data to vertex shader
It occurred to me that it's must simpler to simply use the vertices (since they
contain a z-component anyways) rather than involve another data structure for
the height.
After switching to the new method, and fixing a bug (I forgot to divide by the
space between the vertices), it now works properly.
Here's the relevant code:
Code:
// basic geometry setup
geom = new osg::Geometry;
geom-setUseDisplayList(false);
geom-setUseVertexBufferObjects(true);
// fill values of geometry
geom-setVertexArray(vertices);
geom-addPrimitiveSet(indices);
osg::VertexBufferObject *vbo = geomgetOrCreateVertexBufferObject();
vbo-setUsage(GL_DYNAMIC_DRAW);
with the new addHeight:
Code:
void addHeight(int x, int y, float inc) {
unsigned pos = x/xspace + (y/yspace)*width;
if (pos vertexCount) {
(*vertices)[pos].z() += inc;
vertices-dirty();
}
}
I still need to go back and check to see if I can get it work with using the
vertex attributes instead (with the possible overriding memory causing the
strange behavior I saw before).
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49520#49520
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possibility of an OSG bot
Just so nobody works wastes time on it (ha), I have solved how to draw bounding boxes around each (unique) drawable that is intersected. What I realize from doing this is that each object is a MatrixTransform of an external subgraph. By using Geode-containsNode(someNode), it excludes duplicate Nodes that have been MatrixTransformed somewhere else in the scene. So, for example, a chair that is MatrixTransformed multiple times to populate the scene, is only getting one bounding box. I'm going to try to compare worldcoordinates and see if that makes sense. Sterling -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49521#49521 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trouble with LightSpacePerspectiveShadowMap artifacts.
Hi Thanks robert for your suggestion, yes this seems the case, the terrain is very very large. I wiil try your suggestion soon. Thanks! Bye! robertosfield wrote: Hi Dario, The issue looks like one of depth precision of the shadow map such that the depth test makes an erroneous judgment about whether the front surface is in shadow or not, this often is a surface self shadowing itself. The normal solution is to use a polygon offset in the shadow map generation so that the surface doesn't shadow itself, if this polygon offset is too small you still get the self shadowing artifact if the value is too large you no longer get shadows where you should see them. The better the depth precision of the shadow map the lower the polygon offset will be required, and in your case perhaps it's the ground layer that is very large and it part of the shadow casting scene to pushes out the depth range of the shadow map reducing it's precision. If this is the case then using the Cast/RecivesShadowMask functionality would be appropriate as this will you could use the mask to avoid the ground being used in the shadow map generation. Robert. On 24 August 2012 14:57, Dario Minieri wrote: Hi, I'm using a shadowed scene with LightSpacePerspectiveShadowMapCB technique with a single light. I've seen that in some positions of the camera, the shadows appear artifacts, while in other positions not. See snapshots. Moving the camera in a continuous manner, this results in an annoying shadows flickering on the objects. You have some kind of idea for that? GLSL Shadow shader issue? Graphix card issue? Other? Thank you! Cheers, Dario -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49505#49505 ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=49522#49522 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maps DTED data
I downloaded osgEarth and build. It is working. Now I need to dig into it. Thanks, Michael On Tue, 2012-08-21 at 15:31 -0400, Glenn Waldron wrote: Michael, osgEarth is a C++ terrain rendering SDK. It is built on top of OSG. It renders 3D terrains from elevation, imagery, and vector data sources, and it provides a ton of other geospatial tools and functionality as well. Main site: http://osgearth.org Source code: http://github.com/gwaldron/osgearth Forums: http://forum.osgearth.org/ Glenn Waldron / Pelican Mapping / @glennwaldron On Tue, Aug 21, 2012 at 3:13 PM, Michael Hall hal...@att.net wrote: Yes, I have heard of it and have actually downloaded it. I don't think I have installed it on my new Laptop I am using. I am not sure exactly its purpose. I know it says something about terrains. Is it library like OSG? I will have to look at it this evening. Any more info would be great. Thanks, Michael __ From: Chris Hanson xe...@alphapixel.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Sat, August 18, 2012 7:25:56 PM Subject: Re: [osg-users] Maps DTED data On Fri, Aug 17, 2012 at 3:59 PM, Michael Hall hal...@att.net wrote: I have a little alpplication I am doing to learn OSG. I have also read the OSG 3.0 for Beginners book. It has been helpful in learning more about how OSG works. I have generated an earth.ive database from the BMNG east and west tifs. I can display this database in my application. I would like to now associate DTED data on that and then overlay maps. What is the best way to do this? Would also like to display the lat/long of where the mouse is in the status bar of my application. Any tips or suggestions are appreciated. You're getting into the realm (multiple data layers) where osgEarth significantly makes your life easier. Have you considered using it? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maps DTED data
My application uses Qt. Currently I have it just reading a .ive file when it starts. This .ive was generated from the BMNG. I would like to keep using this for the app, and apply my maps to it. I would like to have a menu option to allow users to import maps into the application. Importing the maps would be handled by a Map Data Manager. This would also allow the user to see the coverage they have imported by selecting that type and the Map Data Manager would highlight the maptiles in a specified color. That is my main goal for now. I am doing this as a way to learn maps and OSG and 3D programming. I have always been interested in maps and want to do this to create a program that maybe useful to people. I have downloaded some SRTM data that is in DTED format. I would like to get this on my .ive earth on the fly. If some people can point me in the right direction on how I can utilize osgEarth to help that would be great. I am looking at the osgEarth Documentation as I type. Looks like more research. Thanks, Michael On Tue, 2012-08-21 at u15:31 -0400, Glenn Waldron wrote: Michael, osgEarth is a C++ terrain rendering SDK. It is built on top of OSG. It renders 3D terrains from elevation, imagery, and vector data sources, and it provides a ton of other geospatial tools and functionality as well. Main site: http://osgearth.org Source code: http://github.com/gwaldron/osgearth Forums: http://forum.osgearth.org/ Glenn Waldron / Pelican Mapping / @glennwaldron On Tue, Aug 21, 2012 at 3:13 PM, Michael Hall hal...@att.net wrote: Yes, I have heard of it and have actually downloaded it. I don't think I have installed it on my new Laptop I am using. I am not sure exactly its purpose. I know it says something about terrains. Is it library like OSG? I will have to look at it this evening. Any more info would be great. Thanks, Michael __ From: Chris Hanson xe...@alphapixel.com To: OpenSceneGraph Users osg-users@lists.openscenegraph.org Sent: Sat, August 18, 2012 7:25:56 PM Subject: Re: [osg-users] Maps DTED data On Fri, Aug 17, 2012 at 3:59 PM, Michael Hall hal...@att.net wrote: I have a little alpplication I am doing to learn OSG. I have also read the OSG 3.0 for Beginners book. It has been helpful in learning more about how OSG works. I have generated an earth.ive database from the BMNG east and west tifs. I can display this database in my application. I would like to now associate DTED data on that and then overlay maps. What is the best way to do this? Would also like to display the lat/long of where the mouse is in the status bar of my application. Any tips or suggestions are appreciated. You're getting into the realm (multiple data layers) where osgEarth significantly makes your life easier. Have you considered using it? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maps DTED data
On Fri, Aug 24, 2012 at 6:56 PM, Michael W. Hall hal...@att.net wrote:
My application uses Qt. Currently I have it just reading a .ive file
when it starts. This .ive was generated from the BMNG. I would like to
keep using this for the app, and apply my maps to it.
If you still have the BMNG data around, osgEarth can consume it directly,
and not need your .IVE.
Alternately, you can feed it a VPB IVE as well. I don't know how well it
can merge terrain from a VPB IVE with additional SRTM data.
I would like to have a menu option to allow users to import maps into
the application. Importing the maps would be handled by a Map Data
Manager. This would also allow the user to see the coverage they have
imported by selecting that type and the Map Data Manager would highlight
the maptiles in a specified color.
That's all UI that's up to you.
I have downloaded some SRTM data that is in DTED format. I would like
to get this on my .ive earth on the fly. If some people can point me in
the right direction on how I can utilize osgEarth to help that would be
great. I am looking at the osgEarth Documentation as I type. Looks
like more research.
http://osgearth.org/wiki/DevelopersGuide
// Add an elevationlayer (SRTM from a local GeoTiff file)
{
GDALOptions gdal;
gdal.url() = c:/data/srtm.tif;
ElevationLayer* layer = new ElevationLayer( SRTM, gdal );
map-addElevationLayer( layer );
}
One of the sample .earth files provided with osgEarth might illustrate this
as well.
--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio •
LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Maps DTED data
The DTED data I have has the .dt2 extension. Can osgEarth load that or
do you have to modify it somehow?
On Fri, 2012-08-24 at 19:32 -0600, Chris Hanson wrote:
On Fri, Aug 24, 2012 at 6:56 PM, Michael W. Hall hal...@att.net
wrote:
My application uses Qt. Currently I have it just reading
a .ive file
when it starts. This .ive was generated from the BMNG. I
would like to
keep using this for the app, and apply my maps to it.
If you still have the BMNG data around, osgEarth can consume it
directly, and not need your .IVE.
Alternately, you can feed it a VPB IVE as well. I don't know how
well it can merge terrain from a VPB IVE with additional SRTM data.
I would like to have a menu option to allow users to import
maps into
the application. Importing the maps would be handled by a
Map Data
Manager. This would also allow the user to see the coverage
they have
imported by selecting that type and the Map Data Manager would
highlight
the maptiles in a specified color.
That's all UI that's up to you.
I have downloaded some SRTM data that is in DTED format. I
would like
to get this on my .ive earth on the fly. If some people can
point me in
the right direction on how I can utilize osgEarth to help that
would be
great. I am looking at the osgEarth Documentation as I type.
Looks
like more research.
http://osgearth.org/wiki/DevelopersGuide
// Add an elevationlayer (SRTM from a local GeoTiff file)
{
GDALOptions gdal;
gdal.url() = c:/data/srtm.tif;
ElevationLayer* layer = new ElevationLayer( SRTM, gdal );
map-addElevationLayer( layer );
}
One of the sample .earth files provided with osgEarth might illustrate
this as well.
--
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 •
OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio
• LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android
___
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] Maps DTED data
On Fri, Aug 24, 2012 at 8:27 PM, Michael W. Hall hal...@att.net wrote: The DTED data I have has the .dt2 extension. Can osgEarth load that or do you have to modify it somehow? This is DTED, level 2. According to GDAL, which osgEarth uses: http://www.gdal.org/frmt_dted.html it should work fine. But you'll just have to try to make sure. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
