Re: [osg-users] How to change shape?
On Fri, May 9, 2008 at 1:12 PM, Ulrich Hertlein [EMAIL PROTECTED] wrote: Robert Osfield wrote: downside is that rendering once built into the display lists won't be updated automatically. To get ShapeDrawable to update the display list simple do drawable-dirtyDisplayList(false). Would it make sense to dirty the ShapeDrawable automatically when the shape is changed using 'setShape'? setShape would need to be changed to be a virtual method to achieve this as its currently only implemented in the Drawable base class, here setShape is just a handle for setting the shape used for collision detection algorithms. I actual regret writing ShapeDrawable now, it was only ever intended to be quite and dirty way to visual a shape, and never a general purpose tool for visualising shapes that users actual want so its always falling short of people expectations. It's design doesn't lend itself to becoming a general purpose shape visualization tool either, rather its a dead end design that's used far too widely for its own or its users good. An alternative might be to just have a createGeometry(osg::Shape) function that builds a geometry that given a shape. Or perhaps rewrite ShapeDrawable so it is a Geometry, or has a Geometry. Suggestions welcome. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Design flaw in ReaderWriter?
On Fri, May 9, 2008 at 1:29 PM, Schmidt, Richard, SDGE1 [EMAIL PROTECTED] wrote: Ok, got it. Registry caches nodes by name or by objectCacheHint. The formal answer is that plugins shouldn't cache scene graph elements locally, rather defer to Registry cache if they need to cache scene graph elements. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SpreadingTheNews about OSG2.4
Hi All, Normally we'd go send news of stable releases out to various news websites as soon as binaries are available, but this time around I headed away for a weeks training, and then since have been snowed under by support and catching up with submissions. I guess now its time to get out and spread the word about the release, I'd very much appreciate your assistance on contacting various news websites, and on the wiki we have a page for coordinating which sites have been done and which ones are left todo: http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/SpreadingTheNews Thanks in advance for your assistance, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.4, CMake 2.6 and Visual C++ 2008: Missing .lib extension for internal dependencies causes linker error
Hi J-S, On Fri, May 9, 2008 at 1:59 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: That's what I think we should do too. Asking on the list about why this was needed didn't elicit any response, so changing it might. grin Breaking a build for one user to fix a build another isn't really getting us anywhere, so I'd suggest we get to the bottom of why this script entries exists before making any further changes. With the aim of tracking down the introduction of this workaround I've gone through the svn logs for OsgMacroUtils.cmake and it looks like the revision of importance is 7865 - this just so happens to be the latest update to OsgmacroUtils so is a pretty recent change: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/CMakeModules/OsgMacroUtils.cmake?rev=7865 Revision 7865 (checked in by robert, 3 months ago) From Rene Molenaar, Using commandline build system nmake on windows does not work. This is caused by the OSG_MSVC_VERSIONED_DLL hack. there are hard-coded paths to place the dll's in the bin /dir that normally would go in the lib/config (release/debug) dirs. Nmake has different locations for the files (no config dir). fix: change the macro's in OsgMacroUtils?.cmake for the IF(NOT MSVC_IDE) situation. Libs go in lib/, and DLLs and executables go in bin/ To accopmplish this for MSVC_IDE the targets get a ../../bin prefix, for nmake this should be ../bin (because there are no config folders). This fix mimics the behaviour of the MSCV_IDE (visual studio) build system when building with nmake. Note: A change in the main CMakeLists.txt creates the needed plugin directory in the binary dir. see included files for the changes: r7885fix-v2/CMakeModules/OsgMacroUtils.cmake r7885fix-v2/osgWrappers/CMakeLists.txt r7885fix-v2/CMakeLists.txt The behaviour of visual studio projects (and other build systems) remain unchanged. Tested building and installing with nmake and visual studio 8 debug and release. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Camera not being called to draw?
Hi Jason, If each Camera triggers the creation of RenderStage then the pre/post draw callbacks will be called once per Camera. As Mathias mentioned a Nested Camera doesn't trigger a creation of its own RenderStage, rather just reuses the existing one and doesn't override anything about this RenderStage. Robert. On Fri, May 9, 2008 at 2:19 PM, Jason Ziglar [EMAIL PROTECTED] wrote: Does this imply that the PreDrawCallback is only called once per render stage? If I have multiple cameras, each with a separate callback, do they all get called at once, or do they get called just each one performs it's rendering? If they all get called at once, how would I go about having each one have a function call just before they draw? I'm trying to update a set of textures just before each camera performs a render pass, so they all use the same shader, but with different textures. Mathias Fröhlich wrote: Hi, On Thursday 08 May 2008 20:00, Jason Ziglar wrote: I've got a camera which is part of my scene graph, and for some reason it doesn't appear to be getting called to render part of the scene. The camera is set to be a NESTED_RENDER, and has a PreDrawCallback. The callback never gets called, nor does it appear to have any rendering output that I can see. I have tested to verify that the camera is a child of the root node, and the primary camera and a PRE_RENDER camera are both working as expected. Is there any subtleties to getting a NESTED_RENDER camera to activate? Well, the pre draw callcack only gets called when you get a new render stage through that camera. And this does *not* happen for nested cameras. To get a render stage you will need to set the camera type to pre render or post render. Then the callback gets called. There are much more properties in the camera that are a noop when the camera does not lead to a new render stage in the rendering backend. The clear mask and clear color for example. I do not know which ones exactly without looking into the code, but if you have a nested camera you must be extremely careful with the values you try to use in the camera. Many of them will only have an effect if the camera os *not* a nested one. So, if you know the internals of the rendering backend well, the camera works relatively intuitive. But if you don't, it's very hard ... Good luck Mathias ___ 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] OSG Node to Mesh
Hi Deepu, How long is a piece of string? This is a similar question to the one you have asked, its pretty extremely open ended. You really have to start by narrowing down to topic to make it possible to answer. In the OSG's case a Node could be anything, it could be Geode containing a single Drawable to a paged database containing a whole planet. Robert. On Fri, May 9, 2008 at 2:23 PM, deepu [EMAIL PROTECTED] wrote: Hello Everyone, I am working on a simulation project in which I have to define an OSG node in the physics world (Bullet Physics). Can any one guide me towards a method by which I can convert an OSG node to a mesh so that I can define it in the physics world. Regards Deepu.LR ___ 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] Complete garbage in OSG / XP / multi monitor / multi threaded / NVidia
Hi Wojciech, On Fri, May 9, 2008 at 2:16 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Problem could be relaxed when wglMakeCurrent gets called before each frame rendering. I noticed that artifacts appeared when wglMakeCurrent was called only once while worker rendering thread initialization . When wglMakeCurrent was called every frame artifacts did not appear. wglMakeCurrent shouldn't be required if one has a thread per context, one a thread does a wglMakeCurrent() it shouldn't release the context till this thread calls release context (done with wglMakeCurrent(_hdc, NULL)). As you are finding that the wglMakeCurrent() per frame is required, this either suggests that the OpenGL driver is playing fast and loose with the graphics context behind the scenes so the app looses the context being current, in which case this is very much a driver bug, or that the OSG itself is doing makeCurrent on the context from another thread or releasing the context when it shouldn't. Could you put some debug output into GraphicsWindowWin32.cpp's makeCurrentImplementation(..) and relaseContextImplementation(..) to see if there are being called when you wouldn't expect, printing out the pointer to the current thread would be useful as well. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Complete garbage in OSG / XP / multi monitor / multi threaded / NVidia
On Fri, May 9, 2008 at 4:09 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Thanks for testing Everyone. This shows that problem is wider and not limited to windows. It looks like GL objects visitor in Renderer thread started by Viewer:: Realize may ovelap with first updateTraversal. I guess its turn for Robert move ;-) I don't know yet the cause of this failure to block while the GLCompileObjects is running, the code certaininly looks like it should block to me. I wonder if perhaps the double buffering of SceneView and all its associated data is causing some issues. Personally I'm not yet at point where I throw lots of time into this topic - I've basically burned 4 days just getting on top of support and submissions that have accumulated since I left to do training, I do actually need to get on and do some paid work, right now support is mounting as quickly as I'm trying to clear it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SpreadingTheNews about OSG2.4
On Fri, May 9, 2008 at 2:07 PM, Cedric Pinson [EMAIL PROTECTED] wrote: Hi Robert, just a reminder about pkg files to updated on the archive 2.4 and openscenegraph-data archive not yet available on the website Thanks for the reminder, these are now updated. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] memory leak with streaming texture
Hi Alexandre, Doing a texture-setImage(image) will do unref the old image before assigning and ref'ing the new one, so memory management should work just fine. The memory leak you are percieving is almost certainly not down to the core OSG code like Texutre::setImage. I'd recommend that you double check you own code, and also how you are monitoring the memory leak, as sometime the memory tracking tools produce false positives. As a general comment, I'd also recommend use osg::ImageStream (as subclass from osg::Image) as a base for streamed images, the xine and quicktime plugins both have movie reading code that provide their own subclass from osg:::ImageStream so have a look at these for inspiration. Robert. On Fri, May 9, 2008 at 6:34 PM, alexandre amyot murray [EMAIL PROTECTED] wrote: Hi, please forgive my english... I'm developping an interractive application where people's movement affect the content of a 3D scene. Somewhere in the appication, when people move, planty of small insects appears and follow their hands. I modelized these insects by a small square plane on wich I apply a sequence of PNG image to give them life. I use texture rectangle to display the images. I made my own class that manage the sequence of PNG images. So when I make a call to MyOwnStreamingClass.getNextFrameToDisplay(), it returns me the next image to display. To change the image of the textureRectangle of each insect, I do the following : -- AInsectTextureRectangle.setImage( MyOwnStreamingClass.getNextFrameToDisplay() ); But this way, I got a memory leak. I tought that a call to texture.setImage would delete the last image and replace it by the new one., but it don't seems to. So I try another way to change the image : -- osg::Image* nextImage = MyOwnStreamingClass.getNextFrameToDisplay(); -- osg::Image* textureImage = AInsectTextureRectangle.getImage(); -- textureImage.setImage( ..., ..., nextImage .data(), ... ); But it doesn't work either, in fact I got a runtime error this way. So I would like too know how I should proceed ? The PNG images are of size 40x40 and a sequence is made of 100 images. I can have like 50 insects at the same time in the scene. Thanks in advance Alexandre ___ 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] Performing non-rendering actions between renderbins
Hi Jason, On Fri, May 9, 2008 at 10:27 PM, Jason Baurick [EMAIL PROTECTED] wrote: Hi Robert, I'll look at osgViewer::Viewer, the reason I used osgViewer::CompositeViewer is because the methods it provided made implementing something very easy. I'm curious, what methods made it easier with CompositeViewer? Just the availability of extra master Camera's? If so then slave camera's within a single View(er) should be sufficient. Right now I am targeting multiple GPU machines, I have looked at clusters in the past for this problem but that is not the direction I am working in right now. My inspiration for this project comes from my experience working in a startup that did transparent OpenGL sort-first and sort-last compositing, so I have lots of experience with the various compositing methods already. Scene graphs are certainly a good way to tackle complex rendering set ups efficiently, if the scene graph is flexible enough. I would like see compositing support integrated into osgViewer at some point in the not too distant future. A first step towards this would be to have an osgcompositor example that renders on multiple GPUs and composites the result. This example could be a bit of hack, doing stuff that might be a be dirty to make sure the viewer can be tricked into doing the right thing. The next step after this would be to refactor osgUtil/osgViewer to make support of compositing more streamlined. In terms of helping you out, it'd be much easier to discuss things if we had a code base that we could both review and test first hand, doing email support for complex stuff is really slow and costly time wise. So... any chance you could put together a basic osgcompositor app based on your current experiments? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting a SceneView's View Matrix
Hi Phishjam, Is it simply that you want the viewers camera to follow a child in the scene? If so then you can use either node-getWorldMatrices() to get the list of model matrices of the a node in the scene, inverting this then gives you the view matrix. Note, getWorldMatrices() may return 1 or many matrices - the later if you have a node with multiple parents. Robert. On Sat, May 10, 2008 at 1:30 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I am needing to set an osgUtil::SceneView's view matrix such that it is identical to that of an osg::Group. The scene structure is along the lines of: sceneRoot--osg::Switch--osg::PositionAttitudeTransform--osg::PositionAttitudeTransform--osg::Group I need my scene view to have all of the same transforms that the group has. Is there an easy way to do this or (even better) an example? Conceptually, I would like to simply make the scene view a child of the group, though that doesn't appear possible. Thanks! Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. ___ 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] SceneView error
On Thu, Apr 10, 2008 at 10:41 AM, [EMAIL PROTECTED] wrote: When I call sceneViewer-cull() first it works like a charm.. But should I have to? You always have to call cull() before draw(), even osgViewer::Viewer::renderingTraversals() does this internally. cull() is what culls the scene graph against the view frustum and builds up the rendering data that is traversed in draw(). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Complete garbage in OSG / XP / multi monitor /multithreaded / NVidia
Hi Wojtek, This morning I awoke and had an idea about why the compile bit be running currently with the update traversal, so I got up and reviewed the code and your test example. First up I can reproduce the problem of the red then green flag on my linux box so when I/we do come up with a solution I do have a chance of confirming the solution works at my end. The problem itself looks to be caused by the GLObjectOperation which does runs GLObjectVisitor is something that is added to the GraphicsContext's GraphicsThread prior to the RunOperaration which will intigate the rendering of the cameras. What this will mean is that compile will always occur before the rendering of the cameras - this is a good thing. The compile will also happen right away after the realize()/startThreading() and before any barriers/blocks have been joined, now normally this is a good thing i.e. to get the compile done before any serious rendering happens, but and this is this big but, it will run concurrently with the first frames update/event traversal in all non SingleThreaded models, and even concurrently to the first frames cull traversal. So... this is why we have the problem. The solution is either to add a block that prevents the first frame from commencing till all the CompileOperations have been complete, or to move the compile into the osgViewer::Renderer::draw() implementation, so the compile is done after cull, but before the first draw(). The first solution introduces greater internal complexity, the second solution will mean the first frame will be very slow. I'm not clear on what route to take. Doing a hack of the second would probably the first thing to try. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] What's the difference between member of osgUtil::Intersector::CoordinateFrame?
Hi Jeongsoeok,
The CoordinateFrame relates the standard OpenGL coordinate frames - the options:
enum CoordinateFrame
{
WINDOW,
PROJECTION,
VIEW,
MODEL
};
Which mean
WINDOW - the coordinates of your window,
PROJECTION - the non dimensional clip coordinates before
projection matrices has been applied,
VIEW - eye coordinates after the projection matrix has been
applied, but before the view matrix has been
MODEL - model/world coordinates, after the view matrix has been applied.
On Sat, May 10, 2008 at 9:10 AM, Jeongseok Lee [EMAIL PROTECTED] wrote:
Hello everyone,
I'm making PickHandler inherit from osgGA::GUIEnentHandler.
This class implememt Pick function. In this Pick func., there are
PolytopeIntersector.
And I use it as follows
osgUtil::PolytopeIntersector* pPicker
= new osgUtil::PolytopeIntersector( osgUtil::Intersector::WINDOW, dX - dW,
dY - dH, dX + dW, dY + dH );
Here, I wonder what is the difference between osgUtil::Intersector::WINDOW,
VIEW, and so on.
Jeongseok.
___
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] Robert, collada dae2 maybe?
HI Valery, On Sat, May 10, 2008 at 12:48 PM, Валерий Быков [EMAIL PROTECTED] wrote: For your information writer plugin for dae doesn't work at all: osgconv cessna.osg cessna.dae I/O error : Permission denied I/O error : Permission denied error : xmlNewTextWriterFilename : out of memory! Error: daeLIBXMLPlugin::write(file://cessna.dae) failed Warning: Error in writing to cessna.dae. Thanks for the notification, I've just tried this and got exactly the same error. Clearly something's broke with the migration to DOM 2.x. So little has changed in the dae plugin I kinda suprised, perhaps the dom itself is responsible. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Could someone removed the link to the hacked server from the downloads page?
Hi Michael, Thanks for reporting this. When I updated the link for 2.4 binaries openscenegraph.dachary.org was working, with Loic having just repaired it from being hacked. So depressing to see it hacked again within days ;-| Thanks to Jose for fixing this so quickly. Robert. On Sat, May 10, 2008 at 2:21 PM, Berg, Michael [EMAIL PROTECTED] wrote: On the OSG downloads page http://www.openscenegraph.org/projects/osg/wiki/Downloads there is a link to http://openscenegraph.dachary.org/ for Debian GNU/Linux binaries. Going to openscenegraph.dachary.org shows a hacked page that has been there for months now. This was previously reported to the mailing list, and since the server administrators for openscenegraph.dachary.org have not corrected this issue, someone should remove that link from the OSG site. Various versions of OpenSceneGraph for Debian GNU/Linux can be found in the official Debian repository at http://ftp.us.debian.org/debian/pool/main/o/openscenegraph/ - Michael Berg ___ 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] Complete garbage in OSG / XP / multi monitor/multithreaded / NVidia
Hi Wojciech, On Sat, May 10, 2008 at 4:23 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Realize in Producer::Viewer was usually explicitly called before entering update/event/cull/render loop. osgViewer::Viewer::Realize can still be called by user before main loop. I believe this makes first solution pretty tricky, one would need to sync return from Viewer::Realize with completion of GL compile operations. I don't know if this is simple task considering number of Threading modes. Actually osgViewer::Viewer::realize() is little different than the old Producer::CameraGroup::realize()/osgProducer::Viewer::realize() in terms of order of operations. osgViewer::Viewer::realize() will be called automatically on the first frame is it hasn't already been called by the user, so this is the only real difference in terms of order. osgProducer/Producer based apps did have a sync() at the begining of each frame, something that osgViewer doesn't have, rather then sync() of threads in done internally in renderingTraversals() at the end of the frame. This change makes it simpler to use osgViewer based apps as one doesn't need to worry about sync. One could still keep the external API simple by placing a barrier at the end of startThreading() in a similar way to renderinTraversals() does. However, while the API would not change, the internal implementation would be more complicated. Second solution does not differ so much from what we have now with this exception that lengthy compilation would be invoked after first update/event/cull traversal. Currently its done before these traversals. But from timing perspective it would not change much. Am I right ? The difference is the order of when the compile is done, and where the compile is instigated. The first frame which contains the compile does have a big hit - it's frame time will be higher than all subsequent frames, so we'll see a hesitation on first frame then the app will get going smoothly. I have gone ahead an implemented this approach, extending osgViewer::Renderer so it now has a compile() method that gets called automatically on the next draw, but once called won't get called again unless explicitly requested to do so. An svn update will get this change. In osgViewer::Renderer there is now a s/getCompileOnNextDraw() method to control when the compile is done, I've modified osgViewer::View::setSceneData() so that it now will reset the CompileOnNextDraw() so it'll now do a compile when you load new models, so this is nice little bonus from this change. In testing with your modified osgprerender things are now working smoothly. Could you let me know how you get on at your end. Robert. Wojtek ___ 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] FLT export, call for testing
Thanks Paul, changes are now all safely merged and submitted to SVN. On Sat, May 10, 2008 at 4:57 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi all -- With my recent osg-submission to add Billboard support to the FLT export plugin, I believe the plugin is now functionally complete. Consequently, I'd appreciate the community pitching in to test the exporter. I'd like to identify any remaining issues and prioritize them for resolution. If you'd like to assist with testing, please wait until my recent submission has been checked in by Robert, then test with latest SVN. Information on export options is available here: http://www.openscenegraph.org/projects/osg/wiki/Support/KnowledgeBase/OpenFlight I've also updated my regression test suite (see above URL for link) to include a \simple Billboard test, Thanks, Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ 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] Could someone removed the link to the hacked server from the downloads page?
On Sat, May 10, 2008 at 7:38 PM, Berg, Michael [EMAIL PROTECTED] wrote: Would it be worth while to link to the official Debian repository there? http://ftp.us.debian.org/debian/pool/main/o/openscenegraph/ Between the stable, testing, and unstable branches, there are packages for OSG 1.2, 2.2, and 2.4 on multiple platforms. These may always be the most up-to-date, but it's better than no link at all. Thanks, I've now added this link. It rather throws one in the deep end w.t.t so many packages, but it's certainly a useful link. 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 zoomming, in orthogonal projection view
Hi Joengseok, On Sat, May 10, 2008 at 7:23 PM, Jeongseok Lee [EMAIL PROTECTED] wrote: Should I change camera's Projection matrix (setProjectionMatrixAsOrtho(…)) my self? Or more smart way? Changing the projection matrix is a perfectly reasonable way to tackle zooming with an orthographic projection. View matrix changes won't help you. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Collision Detecting by Intersections
Hi Umit, The OSG doesn't directly support collision detection, just provides intersection between various types with the scene graph. The main intersector are the osgUtil::LineSegmentIntersection or PolytopeIntersector, the later could be used for testing a convex hull against the scene and is probably the best one to use in your case. Robert. On Sun, May 11, 2008 at 5:53 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi All; I am trying to detect intersections while flying on the earth database. I looked at the mail list to using intersecting operation and I find osg::BoundingBox. But can it help me to detect the collisions between aircraft and earth model? And Is there any simple example to find out collisions? If you know how can I do this control, all advices would be welcomed with glad :) Thanks so much. Yours Sincerely. ÜMİT UZUN _ Windows Live Spaces – hayatınız, Alanınız. Daha fazlasını öğrenmek için buraya tıklayın. http://get.live.com/spaces/overview ___ 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] osg-users community pass 1900 mark
Hi All, This morning the osg-users mailing list hit another milestone - we now have 1901 subscribers to the osg-users mailing list! Curious Spring (in the northern hemisphere ;-) each year seems to see a surge in the subscription rate, I have no explanation of this, its just an observaration. Do uni's do their graphics course/graphics project work in the spring? Do companies commission more new projects at this time of year? Next milestone is the big one - 2000, at current new subscription rates it might take 3 to 4 months, so I guess there is slim chance we might hit this for Siggraph this year, but more realistically some point Autumn. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.5.0 dev release tagged.
Hi All, I have just tagged the 2.5.0 developer release, the first step along the road to the next stable 2.6.0. There have been several bugs fixes that missed 2.4.0 just by a week or two so feel that perhaps a 2.4.1 stable release is due. Some of these fixes have broken binary compatibility with 2.4.0 though so even if we did roll these into 2.4 branch to make 2.4.1 we wouldn't be able to maintain binary compatibility. Is binary compatibility important for a 2.4.x series? Thougjts? Details on 2.5.0: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases * OpenSceneGraph-2.5.0, released on 12th May 2008. OpenSceneGraph-2.5.0 adds new svg image plugin (based on rsvg and cario), support for Philips WoW 3D TV's, new osgfilecache utility that can be used to populate local file caches of internet based paged databases, new osgviewerGTK example show how to intergrate OSG with GTK, dae plugin updated to work against COLLADA DOM 2.x and various typo and bug fixes. source package : OpenSceneGraph-2.5.0.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.5.0 OpenSceneGraph Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SpreadingTheNews about OSG2.4
Hi All, I've just notified opengl.org, modsim.org and freshmeat.net about the OpenSceneGraph-2.4 release. I'd appreciate if others can pitch in to complete notification of the rest of the sites. http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/SpreadingTheNews Thanks, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Workaround for the problems in OSG / XP / multi monitor/ multithreaded / NVidia
Hi Wojciech, I've just reviewed your change and it looks benign, and I don't foresee any problematic side effects on drivers that don't required this double wglMakeCurrent() calling. The cost of wall wglMakeCurrent() twice I don't see as something that is likely to cause particular performance problems as the OSG shouldn't be called makeCurrent too often anyway. Given all this I think it'd be better to do try and do automatically tests to check whether this double call is required or not, as this would just complicate the code and potentially lead to more bugs. However, what is clear that if calling wglMakeCurrent() twice fixes the problems, you are seeing, without any other changes to the OSG then this is a pretty clear pointer to a driver bug. Robert. On Mon, May 12, 2008 at 1:28 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Hi again, I have modified GraphicsWindowWin32::makeCurrentImplementation method. Code attached. This modification solves both garbage in TriangleStrip/TriangleFans and FBO problems. So a complete succes for me ;-) I am posting it on osg users forum instead of osg submissions because I expecty we want some discussion before submitting it. I don't know how this workaroud should be additionaly wrapped. In this form its alredy rather non aggressive - second wglMakeCurrent will be called fairly seldom. What additional conditions we would like to see tested before applying this worakoround. Any suggestions ? Should I check GL_VENDOR, GL_RENDERER, GL_VERSION strings ? Does OSG offer some methods to query OS, drivers version ? Maybe othe places in the code are more appriopriate for this call. Cheers, Wojtek Hi Everyone, Lets get back to the main topic of this thread ie garbage in Multicore CPU / NVidia / DualView / Window XP. I attached my OpenGL repro for those who are interested. I would be grateful if somoene could check if my threading code is OK (and maybe simplify it). If it is, I will try to submit the bug to NVidia. Check out what happens when repeatMakeCurrent variable gets changed to non zero value. This causes repetition of wglMakeCurrent and fixes the issue. I will try to check this method in OSG next week. I am heading back home for the weekend. I will stay online but I don't have multicore CPU there so I won't be able to check codes till monday. Cheers, Wojtek Lewandowski Hi Robert, Paul and J-S, I don't think I was clear enough. Its too early to say that wglMakeCurrent will be a good workaround for OSG. I only said that it relaxed the problem in my OpenGL repro. It looks like first wglMakeCurrent (when renderer thread is started) does not initialize properly some internal OpenGL context data. If I repeat it in second frame everything becomes correct. So if wglMakeCurrent was a solution it would be needed only once more on frame. But I learned all this using my open gl repro without Display Lists and to be honest I did not checked what will happen if DisplayLists are generated on a first frame (like OSG does). I suspect they might stay screwed even if second wglMAkeCurrent gets called. I am currently trying to check this out. I just need some more time to investigate. I got some questions regarding this issue so I decided to inform guys for whom this is relevant by posting on osg-users. I am certainly far from proposing fixes at this moment. Wojtek Hi Wojciech, On Fri, May 9, 2008 at 2:16 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: Problem could be relaxed when wglMakeCurrent gets called before each frame rendering. I noticed that artifacts appeared when wglMakeCurrent was called only once while worker rendering thread initialization . When wglMakeCurrent was called every frame artifacts did not appear. wglMakeCurrent shouldn't be required if one has a thread per context, one a thread does a wglMakeCurrent() it shouldn't release the context till this thread calls release context (done with wglMakeCurrent(_hdc, NULL)). As you are finding that the wglMakeCurrent() per frame is required, this either suggests that the OpenGL driver is playing fast and loose with the graphics context behind the scenes so the app looses the context being current, in which case this is very much a driver bug, or that the OSG itself is doing makeCurrent on the context from another thread or releasing the context when it shouldn't. Could you put some debug output into GraphicsWindowWin32.cpp's makeCurrentImplementation(..) and relaseContextImplementation(..) to see if there are being called when you wouldn't expect, printing out the pointer to the current thread would be useful as well. Robert. ___ osg-users mailing list
Re: [osg-users] memory leak about osgMFC example
Hi Heishuijing,
Please do a search through the archives on this topic, you'll find
lots of queries about it, and lots of response along the lines, MS's
memory tracker is broken and reports false positives - there is no
memory leak, just MS buggy code wasting your time.
Robert.
2008/5/12 heishuijing_2000 [EMAIL PROTECTED]:
hello,
My osg version is 2.4,and i use VS2005 in windowsXP. When i run the
osgMFC example in debug mode,i found that there are memory leak when the
window is closed,the message in the VS2005 is below:
Detected memory leaks!
Dumping objects -
{3078} normal block at 0x02054A28, 32 bytes long.
Data: WGL_EXT_framebuf 57 47 4C 5F 45 58 54 5F 66 72 61 6D 65 62 75 66
{3077} normal block at 0x020549B8, 48 bytes long.
Data: H hD A 18 48 05 02 68 44 05 02 F8 41 05 02 00 00 00 00
{3075} normal block at 0x02054958, 32 bytes long.
Data: WGL_ARB_buffer_r 57 47 4C 5F 41 52 42 5F 62 75 66 66 65 72 5F 72
...
There are so many memory leak. I just don't know how i can do with it.
Who can help me with it? Thank you!
Best regards!
2008.05.12
快来用音乐为奥运加油
得奥运会、演唱会门票
___
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] osgForge: what's the status?
On Mon, May 12, 2008 at 2:36 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Any progress? I notice osgforge.org still gives an error... I haven't had a chance to chase this up. I really have been over swamped by support work this past week, I *have* to give it break and get on with other work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Workaround for the problems in OSG / XP / multimonitor/ multithreaded / NVidia
Hi Wojtek, On Mon, May 12, 2008 at 3:06 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: I am not sure what you mean by automatic tests ? Do you want me to write some code to check if there are related issues before appling this workaround ? I simply mean a test against the driver version, one could come up with a who sets of tests that try to isolate when this double make current is applied. Automatic in as much as its a test that is done within GraphicsWindowWin32 methods rather than something manually invoked by the user. I agree, it now seems obvious this is a driver issue. I have sent a bug report to NVidia. Wonder what they do with it. But frankly I don't have good experience on this front and I don't expect quick solutions in the drivers. There are more important issues in many games ;-) Reporting the issue is important, NVidia need to keep on top of this type of problem, if it ain't reported then such a bug much just drift along from driver version to version never to be addressed. It's also a reminder to NVidia that just people do write multi-threaded, multi-context apps using modern OpenGL functionality - games aren't the only players in town. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multiple off-screen renders?
Hi Jason, There is way too little info to know what is going wrong. One thing you need to be careful of when managing multiple graphics contexts is that you manage the contextID appropriately for each context. However, you haven't specified if you have multiple graphics contexts. You haven't even mentioned whether you using the OSG multi-threaded... The most I know is that you've rolled your own viewer based on FLTK and SceneView. Now this integration could have lots of issues in itself. Why not try out your scene graph usage in a standard osgViewer viewer code, at least that why you'll be able to isolate one set of variables from the mix. Robert. On Mon, May 12, 2008 at 4:14 PM, Jason Ziglar [EMAIL PROTECTED] wrote: I've run into an issue in which it appears that having more than one off-screen rendering camera causes OpenSceneGraph to crash, and I was curious if I'm doing something wrong or if there's a workaround available. I've got four cameras in the scene graph. Two are fbo cameras for shadow mapping, two are projective texturing cameras. The two shadow mapping cameras have ref_ptr's to the same node in the scene, and the two main cameras have ref_ptr's to the same node (but different from the shadow mapping cameras.) The gdb output from attempting to debug the result, and what I get is: #0 0xb7be86ca in osg::GraphicsContext::releaseContext () from /home/jpz/code/sacr-git/external/linux/OpenSceneGraph_2.2/lib/libosg.so.25 #1 0xb79771ed in osgUtil::RenderStage::draw () from /home/jpz/code/sacr-git/external/linux/OpenSceneGraph_2.2/lib/libosgUtil.so.25 #2 0xb7970dbe in osgUtil::RenderStage::drawPreRenderStages () from /home/jpz/code/sacr-git/external/linux/OpenSceneGraph_2.2/lib/libosgUtil.so.25 #3 0xb79858b4 in osgUtil::SceneView::draw () from /home/jpz/code/sacr-git/external/linux/OpenSceneGraph_2.2/lib/libosgUtil.so.25 #4 0x080ae972 in sacr::OSGWindow::draw (this=0x83a0978) at libs/Display/OSGWindow.cpp:136 #5 0x081a2311 in fltk::GlWindow::flush () Any ideas? Thanks in advance, ___ 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] window
Hi Miriam,
I don't really understand exactly what you are after. The best I can
do is suggest you have
a look at the OSG examples to see how they set up windows.
If you need Producer specific support then you question is probably
best logged on the Producer
mailing list.
The other alternative is to use osgViewer library that replaces
osgProducer in the 2.x series of
the OpenSceneGraph. osgViewer has been written wholly within the OSG
community so its
easier for myself and others to support.
Robert.
On Mon, May 12, 2008 at 2:01 PM, Miriam D'Elia [EMAIL PROTECTED] wrote:
Hi,
I design my scene with osgProducer and I want to bring up the design inside
a window.
I design my scene with osgProducer and I want to bring up the design inside
a window.
With the code that I wrote, the window appears, the scene rather not see.
How can I do?
Miriam
int main()
{
Producer::CameraConfig* cameraC= buildWindow();
osgProducer::Viewer v(cameraC);
v.setSceneData(root);
v.realize();
while(!v.done())
{
v.sync();
v.update();
v.frame();
}
}
Producer::CameraConfig* viewLibAuToti::buildWindow()
{
Producer::RenderSurface* renderSurface= new
Producer::RenderSurface();
renderSurface-useBorder(true);
renderSurface-setWindowRectangle(0,0,800,600);
renderSurface-fullScreen(false);
renderSurface-setWindowName(View Simulation);
Producer::Camera* camera= new Producer::Camera();
camera-setRenderSurface(renderSurface);
Producer::CameraConfig* cameraConfig= new Producer::CameraConfig();
cameraConfig-addCamera(camera, camera);
return cameraConfig;
}
___
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] obtaining the display list ID from a geometry node
Hi Sebastien,
The Drawable method you are look for is:
/** Return OpenGL display list for specified contextID. */
inline GLuint getDisplayList(unsigned int contextID) const {
return _globjList[contextID]; }
However, your usage model so sounds rather outside the usage for the
OSG, users don't normally
ever need to access values such as display lists ID as this is all
managed behind the scenes for you.
I know almost nothing about your specific needs or app so can't say
whether what you are doing
is appropriate or not, but all I can say is its sounds atypical and as
such you may well hit lots of
gotchas, and using the OSG how its meant to be used might well be far
more productive.
Robert.
On Mon, May 12, 2008 at 4:30 PM, Sebastian Knödel [EMAIL PROTECTED] wrote:
Hi there,
I would like to obtain the display list ID of a geometry and use them
inside my own CSG tool.
Then I would like to render the result of the CSG process, which are also
display lists.
The main purpose of using OpenSceneGraph would be to manage my scene, like
to load data, manage the transformations, interaction, dispaly setups,
shader etc.
I had a look at the documentation to see if there is an interface that
allows me to obtain the generated dispalylist IDs from a geometry, but I
couldn't find anything similar.
I figured out that I can obtain a contextID from the current OpneGL state.
but I'm not sure if that is what I'm looking for.
Thanks for any comment.
Sebastian
--
Sebastian Knödel
|PhD. Student |[EMAIL PROTECTED] |
|Iparla Project | http://iparla.labri.fr|
|INRIA Bordeaux|Tel : (+33) 5 40 00 38 82 |
___
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] Workaround for the problems in OSG / XP /multimonitor/ multithreaded / NVidia
Hi Wojciech, On Mon, May 12, 2008 at 4:33 PM, Wojciech Lewandowski [EMAIL PROTECTED] wrote: I may test if GL_VENDOR string contains NVidia word (case insensitive). and GL_RENDERER contains GeForce and sometthing that fits 6??0, 7??0, 8??0 paterns. I don't know if there are extensions which would allow me to read drivers version. GL_VERSION doesn't seem appropriate - it reports OpenGL version. Of course I could try to look for NVOPENGL.dll and check its version but this sounds like a recipee for trouble in the future. I may also try to figure out if Windows is XP. If above is OK I will implement it and send a submission. GraphicsWindowWin32 only exists under Windows, and given that make current is so rarely called and calling it twice with the same value won't break anything I'd suggest we just integrate your hack without any extra checks. As I mentioned before the extra checks could well introduce bugs of their own so I'd be very cautious of doing it when the actual gain will be negligible in terms of performance. So I'd suggest merge your change as is. I was hoping for a bit more feedback from other Windows users before merging though... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sample TerraPage terrain?
Hi Brett, TerraPage terrains tend to have overly aggressive LOD settinngs that cause the scene to cull out at the default viewing position that the OSG uses. Try zooming into the scene and you should see the tiles pop in as you get within range of the LOD. Robert. On Mon, May 12, 2008 at 6:42 PM, Brett Wiesner [EMAIL PROTECTED] wrote: Hi, I've got 3 TerraPage terrains that don't show up when I load them in osgViewer.exe. Also no useful error messages show up. I'm using OSG 2.4.0. I was wondering if anyone knows I can get a sample TerraPage terrain that works with OSG 2.4.0 that I can use as a control for my tests. Thanks, Brett ___ 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 document osgShadow?
Hi Ben, Many thanks for offering to pitch in on the documentation side, not at all the easiest tasks but valued no less. A mixture of Programming Guide style articles and Doxygen Docs are good ways, going the tutorial route is another. Tweaking the osgshadow example so its more useful for educational purposes would also be useful. Cheers, Robert. On Tue, May 13, 2008 at 12:32 AM, Ben Discoe [EMAIL PROTECTED] wrote: I'd like to contribute back my new understanding to the OSG documentation. My question it, where and how? Here are some options.. 1. The wiki has a page: http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/osgShadow but that is an old page from before osgshadow joined the OSG source, it seems like not the place for documentation. 2. We could make a new Wiki page, perhaps linked from: http://www.openscenegraph.org/projects/osg/wiki/Support/ProgrammingGuides under 'Programming the NodeKit libraries' 3. The source-doxygen docs, which end up here: http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/a02211.html I could submit modifications to the osgshadow source code with appropriate comment paragraphs explaining how to use each class. But, that appears to not be OSG's design, source docs seem to be deliberately minimal, so perhaps extensive documentation with text formatting, charts etc. belongs outside the source. Or, perhaps there is: 4. Some existing osgShadow docs i didn't find yet, which i could extend? Thanks, Ben ___ 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] Building the SVG plugin
Hi Paul, As JS, Ulrich and Philip has mentioned at present the dependency checking code relies upon pkg-config, which isn't standard under Windows. For Windows we'll need write our won FindCario and FindRSVG.cmake files such as the ones we already have in OpenSceneGraph/CMakeModules. Robert. On Tue, May 13, 2008 at 1:43 AM, Paul Martz [EMAIL PROTECTED] wrote: I just updated OSG and would like to take the new SVG plugin for a test drive. Unfortunately, CMake doesn't appear to find the librsvg/cairo dependencies, and consequently, building OSG does not build the SVG plugin. The real odd part is that I don't see any CMake variables for controlling where CMake searches for librsvg/cairo.I'm trying this on Windows, but that shouldn't make a difference for CMake... Advice? Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ 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] updateTraversal and camera manipulator
Hi Christophe,
There is a reason why ViewerBase::updateTraversals() is a virtual function :-)
Basically different applications will have different requirements
w.r.t set up and use of
the view matrix, most apps they won't be dependant on each other,
other applications
will have a view matrix that tracks objects in the scene - such as
ones use NodeTrackerManipulator
for these you have to do update first, then update the camera
manipulator, then others like
yours want to obtain the view matrix after the camera's view matrix
has been set. There
is no way you to solve all of these usage models with one code path,
so osgViewer simply
implements the most common usage model.
For your own app you can override the updateTraversals() method, or
manually call the
camera manipulator before you call updateTraversals() in your frame loop - i,e,
while(!viewer.done())
{
// break frame down into its separate traversals
viewer.advance();
viewer.eventTraversal();
// your custom code for updating the view matrix
viewer.updateTraversal();
viewer.renderingTraversals();
}
One item to note, is the OSG is designed to allow one to have multiple
cameras viewing the
same scene graph, which in your instance you're callback will only be
called once, but you'll
have to track multiple view matrices. If you never use multiple
View(s) or multiple slave Camera(s)
then this won't be an issue, but it's something worth flagging.
Robert.
On Tue, May 13, 2008 at 7:33 AM, christophe loustaunau
[EMAIL PROTECTED] wrote:
Hi,
In our application, I need to get the cameraViewMatrix in the
updateTraversal. I have done that with an update callback.
But I think I have the ViewMatrix of the last frame, not the current frame,
because of some graphics problems.
I have look in Viewer::updateTraversal() and I have found that the
updateTraversal is done before the camera matrix is set by the manipulator,
see the code :
void Viewer::updateTraversal()
{
..
if (getSceneData())
{
getSceneData()-accept(*_updateVisitor);
}
...
if (_cameraManipulator.valid())
{
setFusionDistance( getCameraManipulator()-getFusionDistanceMode(),
getCameraManipulator()-getFusionDistanceValue() );
_camera-setViewMatrix(_cameraManipulator-getInverseMatrix());
}
..
}
Is this intend ?
I have try to set the camera matrix from the manipulator before the
traversalUpdate and everything works fine.
I wan't to know if there is resons for this specific order, or if we could
set the camera matrix from the manipulator before the traversalUpdate. If
so, I could submit this change to osg-submissions.
Regards.
--
Christophe Loustaunau.
___
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] window
On Tue, May 13, 2008 at 8:33 AM, Miriam D'Elia [EMAIL PROTECTED] wrote: Hi Robert, we apologise, but only yesterday I noticed that pressing the button f you switch from full-screen display to display in a window. osgProducer::Viewer is a everything and the kitchen sink viewer so does contain various event handlers by default. If you press 'h' you'll get onscreen help. Also try in the command line: osgviewer --help-all To get a listing of all options. osgViewer::Viewer in 2.x isn't a everything and the kitchen sink viewer so you won't get all these event handlers by default, this is a good thing as you don't get anything you don't want, but it's easy to add various event handlers so you can get all the functionality and more relative to osgProducer::Viewer. The --help* options in osgviewer still apply. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] pagedLOD question
HI Brett, What I have done VirtualPlanetBuilder is to have a quad tree scene graph structure like: Group PagedLOD child 0 - local tile geometry at low resolution child 1 - external file reference PagedLOD child 0 - local tile geometry at low resolution child 1 - external file reference PagedLOD child 0 - local tile geometry at low resolution child 1 - external file reference PagedLOD child 0 - local tile geometry at low resolution child 1 - external file reference Each externals file reference is .ive file that contains a Group at the root and four children in the same structure as above. The nice thing about this structure is that there are always tiles available as fallback so there is never any holes in your terrain while you are waiting of the high res tiles to page in. Robert. On Mon, May 12, 2008 at 11:58 PM, Brett Wiesner [EMAIL PROTECTED] wrote: Hi, I have a set of terrain files that represent LODs for a terrain that I'd like to have OSG load and page. It's a quad tree where the first tile is the low res LOD 0. The next LOD is four tiles of medium resolution and the LOD after is 16 tiles of high resolution terrain. My question is, how do I construct the scenegraph? Should I just put each tile under a osg::PagedLOD node and put all the pagedLOD nodes under a group node? Or should preserve the hierarchy so that the lowest level PagedLOD node has the the pagedLOD nodes of its children under it, and so on. Thanks, Brett ___ 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] Problem with osgviewerGTK example
Hi Martin,
I just tried your example and it works fine on my Kubuntu 7.10 system
pkg-config gtk+-2.0 --modversion
2.12.0
Perhaps your version of gtk is screwing up X11 in a way that the
osgViewer::Viewer's own creation of windows is going astray.
Robert.
On Tue, May 13, 2008 at 9:26 AM, Martin Großer [EMAIL PROTECTED] wrote:
Hello,
I checked the lighting and that is not the problem. But I tried to implement
a osgViewer::Viewer in the application (after the gtk main loop). Now I have
the same problem in the osgViewer. But the cessna.osg looks fine, when I
comment all GTK stuff out. Ergo, I think the problem is anywhere in gtk?!
Now a little example, at which the problem occurs. I create a gtk window and
after the main loop an osgViewer. Without the gtk stuff the cessna looks fine
and with the gtk window the cessna looks very rough and black.
int main( int argc, char *argv[] )
{
/* Pointer auf Struktur GtkWidget (wird für Fenster und Button benötigt)
*/
GtkWidget *window;
// Inits
gtk_init (argc, argv);
// Window erzeugen
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (G_OBJECT (window), delete_event, G_CALLBACK
(gtk_main_quit), NULL);
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
// automatsiches Aktualisieren, wenn sich was bei den Children ändert
gtk_container_set_reallocate_redraws (GTK_CONTAINER (window), TRUE);
// Widgets anzeigen
gtk_widget_show (window);
gtk_main ();
osgViewer::Viewer* viewer = new osgViewer::Viewer();
osg::Group* root = new osg::Group();
root-addChild(osgDB::readNodeFile(cessna.osg));
viewer-setSceneData(root);
viewer-realize();
viewer-run();
return 0;
}
Incidentally, I use the gtk 2.0.
Cheers,
Martin
It looks like a lighting issue. It looks like lighting is turned on for the
scene, but there are no lights. You might look for stateSet calls related to
lighting. Otherwise you could try and force lighting to be off.
Andy
-Original Message-
From: osg-users-bounces at lists.openscenegraph.org on behalf of Martin Großer
Sent: Fri 5/9/2008 3:01 PM
To: jeremy at emperorlinux.com; 'OpenSceneGraph Users'
Subject: Re: [osg-users] Problem with osgviewerGTK example
It happens only in the GTK and when I press the 60 FPS button than is the
same problem with the model, only the the mouse navigation has change. When
I use the osgViewer or the osgCompositeViewer the model looks normal.
I use OpenSceneGraph 2.4 and fedora 8, is this information helpful?
Cheers,
Martin
On Fri, 2008-05-09 at 13:30 +0200, Martin Großer wrote:
Hello,
when I use the osgviewerGTK, I see a very simplistic model and it is
black. For example I used the cessna.osg file and I made a picture. I have
attach the picture to this mail.
What could be the problem?
Does this happen on all viewers, or just the GTK one? Also, what happens
when you toggle on the 60 FPS button?
Cheers,
Martin
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
___
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] osgthirdpersonview example: anyone else with an ATI having problems?
Hi Paul, To see if it is thread related try : osgthirdpersonview cow.osg --SingleThreaded You could also see if its FSAA causing the problems by comment out the line: // Turn on FSAA, makes the lines look better. osg::DisplaySettings::instance()-setNumMultiSamples( 4 ); Robert. On Tue, May 13, 2008 at 12:29 PM, Paul Melis [EMAIL PROTECTED] wrote: On my new system, with a crappy ATI card, the osgthirdpersonview example in 2.4 is showing two black windows and doesn't respond to any inpu. stracing the process seems to suggest some threading-related problem. On the NVidia-systems I tried it on it works fine, so would this be an ATI-related problem? Paul ___ 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] Problem with osgviewerGTK example
On Tue, May 13, 2008 at 1:09 PM, Martin Großer [EMAIL PROTECTED] wrote: I set OSG_NOTIFY_LEVEL on DEBUG and compare the application with gtk and without gtk and I found the following differences. With GTK: glVersion=2, isGlslSupported=YES, glslLanguageVersion=1 Without GTK: glVersion=2.1, isGlslSupported=YES, glslLanguageVersion=1.2 This sounds like you are linking to different OpenGL libraries in each case. Add a check for the vendor string to find out which drivers you are getting in each case, I suspect this will be illuminating. Perhaps gtk is hardwired to mesa. I still use OSG 2.2, because the update to 2.5 is a little bit difficult in my case. Curious, what problem prevents you from updating OSG version? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GDAL plugin functionalities in OSG-2.4 ?
Hi Rahul, There isn't any extension aliasing from .dem to .gdal built into osgDB::Registry so there is no way for the OSG to know that you intend to use the gdal plugin. You add these yourself if you wish. You can get the OSG to use the gdal plugin by preloading the plugin, then it'll be called automatically as part of the Chain Of Responsibility Pattern, or add a .gdal to the end of the filename so that its osgDB will automatically load the plugin and then the GDAL plugin will strip the .gdal extension and then it'll load the file. Robert. On Tue, May 13, 2008 at 12:42 PM, Rahul Jain [EMAIL PROTECTED] wrote: Thanks Robert, I tried reading sample.dem file in my sample program using osgDB::readImageFile(), but not able to open it (with the warning could not find plugin ), did my assumption of reading the .dem file as image is correct or do i need to read the gdal supported files differently. RJ Robert Osfield wrote: On Tue, May 13, 2008 at 11:42 AM, Rahul Jain [EMAIL PROTECTED] wrote: Hi All, What are the functionalities does new gdal plugin in OSG2.4 provides ? Can i read all the files which are supported through gdal. Yes you can read all GDAL supported files. The new plugin doesn't really offer anything too different than the previous rev of the GDAL plugin though. If you want the full power of GDAL you are sill best using GDAL directly as VirtualPlanetBuilder. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake debug extension d CMAKE_DEBUG_POSTFIX
Hi Cedric, I'm open to make the d suffix optional. It exits on all platforms purely to keep things consistent, and in the case with Windows one can't mix debug and release libs so one is really forced into this nonsense so this is where the convention was dictated from. Robert. On Tue, May 13, 2008 at 4:06 PM, Cedric Pinson [EMAIL PROTECTED] wrote: Hi Robert, I would like to build debug version of osg without d extension everywhere, here my case: I build osg in release and debug in two separate directory, then when i want to debug my application i change my library path, and then i rebuild the application. So it works when i have no other lib that depends of osg. But when you link with 2/3 library that depends on osg you have to rebuild each lib in debug and release version (because of d and ) or i just would like to build with release or debug and then select with a env variable wich version i want to use (and same thing with each lib if needed). Maybe for windows you are forced to do that because of runtime difference, but not on gnu/linux. Could we just add a way to configure this in cmake and we can use the d by default, then there is no change for people who dont care. What do you think ? Cedric -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:[EMAIL PROTECTED] http://www.plopbyte.net ___ 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] DelaunayTriangulator's Input Point Array
On Tue, May 13, 2008 at 5:28 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Once the Delaunay triangulator has been run on the Vec3Array that I set at its input array, the array can't be deleted. The Delaunay triangulator must be putting something bad into that array. Any ideas? I can't even call clear() on the array in VS8 debugger. I have no ideas. I'm not the original author of osgUtil::DelaunayTriangulator so am in little better position than yourself w.r.t debugging it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview example: anyone else with an ATIhaving problems?
Hi Paul, On Tue, May 13, 2008 at 6:33 PM, Paul Martz [EMAIL PROTECTED] wrote: Hm. The code deletes one of the root node's children, and recreates it, each frame. Try making this change: osg::ref_ptr osg::Group root = new osg::Group; root-setDataVariance( osg::Object::DYNAMIC ); (The first line is already in the code; please add the second line). DataVariance of Nodes is only critical during the osgUtil::Optimizer run, but right now doesn't effect anything else - so the above change is not required, and shouldn't affect things. DataVariance on StateSet and Drawables is important at during the frame loop though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] spot_gold_cylinder silliness
Hi Mike,
On Wed, May 14, 2008 at 3:44 AM, Mike Weiblen [EMAIL PROTECTED] wrote:
(ab)using the curl plugin for up-to-the-minute gold quotes, see attached :-)
I download the file and loaded it, and couldn't work out where the
image came from as you
just provided the .osg, then... it dawned on me what you meant :-)
For those who don't have a clue what we are on this morning, here's an
extra from Mike's
spot_gold_cylinder.osg :
Texture2D {
DataVariance STATIC
file http://www.kitconet.com/images/live/s_gold.gif;
...
}
Which trigger osgDB to load the curl (or .net if the curl plugin isn't
built) plugin to load the image,
then it just uses this as the texture for the cylinder
So I guess the next step is to write a little osg example that polls
the above an similar files every twenty seconds to
give you a virtual stock market room...
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview example: anyone else with an ATIhaving problems?
Hi Paul, On Wed, May 14, 2008 at 8:21 AM, Paul Melis [EMAIL PROTECTED] wrote: I didn't manage to find out what is going on. The only different between osgthirdpersonview (not working) and osgcompositeviewer (working) is that the former uses separate windows to render its output. Could you try the osgwindows example? The has two windows, it uses osgViewer::Viewer but this shouldn't make a difference - it's mult-threaded multi-context that is more likely pushes the drivers hard, and the underlying code driving the cameras and context is the same between Viewer and CompositeViewer. 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 convert DDB bitmap to osg::Image?
Hi Forest, There isn't any OSG code in your example, so it is that you have a stumbling block before you even start trying to pass data to the osg::Image? As for examples of setting up osg::Image have a look through the various image plugins such as src/osgPlusgins/rgb, png, tga etc. Robert. 2008/5/14 forest37 [EMAIL PROTECTED]: hello everyone, I want to draw something in memory dc ,then convert the drawing to osg::Image. I tried it like this: CDC dc; dc.CreateCompatibleDC(NULL); CBitmap bitmap; bitmap.CreateCompatibleBitmap (dc, 100, 100); CBitmap* pOldBitmap=dc.SelectObject(bitmap); dc.FillRect(CRect(0,0,200,200),CBrush(RGB(255,0,0))); BITMAP bmp; bitmap.GetBitmap(bmp); here,the bmp.bmBits is NULL because of DDB. thanks for any advice forest 中 国 最 强 网 游 --- 网 易 梦 幻 西 游 ，166 万 玩 家 同 时 在 线 ___ 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] ShadowTexture::setTextureSize?
Hi Ben, On Wed, May 14, 2008 at 8:28 AM, Ben Discoe [EMAIL PROTECTED] wrote: But no setTextureSize method. So it seems like it would be very easy to add it. Is there some technical reason it's not there, or just an oversight? If oversight, may i implement and submit it? The various ShadowTechniques have been developed independently by different authors, and have been subject to different contribution since their inception so differences have grown up between them - some a natural part of their differing implementation details, others simply down to features being added to some but not others that could be equally served by it - ShadowTexture::setTextureSize being one of them. If you spot these inconsistencies please just highlight them, and even better if you can do it implement the missing feature ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with osgviewerGTK example
On Wed, May 14, 2008 at 8:31 AM, Martin Großer [EMAIL PROTECTED] wrote: Hi Jeremy, Which osg version had you used? Now I have 2.4 and it doesn't work. I have SVN version of the OSG, but its very very close to 2.4 so that fact that you still get the problem eradicates the OSG version from the mix as a possible cause of us see different results. Right now it looks like GTK itself is different across our systems, and it'd look like a bug on your version of GTK. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] some questions about Virtual Planet Builder
Hi David, In VPB SVN archive support is temporarily disabled, I do plan to re-enable it this month. BTW, what platform are you using? I haven't seen a performance delta between archive and non archived forms - I work under Linux. FYI, In OSG-2.4 and VPB SVN there is support for build with --terrain in osgdem, that build an osgTerrain::TerrainTile database, these tiles are basically regular grids, that osgTerrain can render how it wants. There a couple of advantages in using --terrain: 1) osgdem --terrain databases are much faster to build as no simplification is done beyond that introduced by sampling the source data, so you'll end up with more triangles, but modern hardware is faster so this less of an issue. 2) osgdem --terrain option also builds more compact databases, which will get even more compact once I introduce height field compression/decompression into .ive. 3) Finally if you place an osgTerrain::Terrain object above a paged database that contains TerrainTiles you can control the sample resolution that the TerrainTechnique that does the rendering of TerrainTiles uses when set up its geometry to render. This allows you to balance the load for different hardware, so a 8800+ series could cope with full resolution, and low end card you sample to half or quarter the density. Robert. On Wed, May 14, 2008 at 10:29 AM, David _ [EMAIL PROTECTED] wrote: Hi we´re using osgdem to generate islands in our project and we´re considering moving to OSG 2.4. We´re currently in 2.2 the last osgdem in SVN generates the island meshes with some kind of optimization so the meshes are not so high density but still have high res textures we´re really interested in having high resolution textures with light density meshes so this optimization is really good for us, the problem is that the -a option is currently disabled in the last SVN VPB and we´ve noticed some performance drop in loading time if the ive´s are not all together in one osga file (our islands are more than 1GB each, so this is important) A) which is the last VPB release having this mesh optimization and the -a option?? it must work with OSG 2.4 too B) also, is it possible to tell osgdem to limit the triangle number but not the texture detail??? We have a lot of things to do right now, and generating all the islands again is something that can wait at the moment. So if you´re planning to update the VPB any time soon, please tell me and i´ll wait for the -a option to be back again, otherwise, please answer the A) question we´ve got some nice screenshots of the islands rendered by OSG 2.2, i´ll ask my boss this evening if i can make them public, so you all can take a look if you find it interesting cheers sorry for my english Sigue los principales acontecimientos deportivos en directo. MSN Motor ___ 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] some questions about Virtual Planet Builder
On Wed, May 14, 2008 at 11:12 AM, David _ [EMAIL PROTECTED] wrote: We´re currently running both Windows XP and Windows Vista the performance drop is not very huge but it´s there. The Windows files system is pretty crappy, and is known to have problems with finding files in directories with large numbers of similarly named files in it. This is probably why you are seeing a performance delta. We saw this drop while making some stress tests, with 16 islands and 20.000 to 40.000 ive´s each one. The test did not represent any real situation, we just wanted to see how far we could go and i must admit that OSG did pretty well. The OSG's database paging system and now VPB both scale to terabyte sized database quite comfortably so are very likely well within what the OSG can handle, even under Windows. Don´t know what caused the problem, maybe having so many small files makes disk fragmentation go worse having so many opened files causes some kind of delay??? Maybe the test was a little to extreme??? no idea really, just guessing. You have to ask Microsoft this question... Or just move to an OS with a better file system(s). Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer inside a GLUT window?
Hi Björn, On Wed, May 14, 2008 at 11:41 AM, Björn Blissing [EMAIL PROTECTED] wrote: Is it possible (and appropriate) to use compositeViewer inside a GLUT window? Both osgViewer::Viewer and CompositeViewer can work with GraphicsWindowEmbedded, and therefore will work with GLUT. However, I wouldn't ever recommend using GLUT to anyone, the osgviewerGLUT example is really just their for those familiar with GLUT based OpenGL examples to see how the OSG can play nice with GLUT. GLUT is still a incredible limited though, and deliberately so as it was never intended to do more than support a few simple OpenGL examples. Using the OSG's inbuilt window capabilities will provide you with a far more flexible and scalable viewer, so there is no real technical need for GLUT, it only adds limitations to OSG applications, rather any additional functionality. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer inside a GLUT window?
Hi Björn, The reason for us thinking of using GLUT and not just sticking with pure OSG is that we want to use the built-in menu capabillities of GLUT. But perhaps there is a simple OSG way of doing that as well? osgViewer itself doesn't provide menu support, its literally focused on the graphics side, you can add menus by integrating it conventional windowing toolkits, or use osgWidget NodeKit that is planned for integration this month. osgWidget is entirely native implementation, so theGUI elements are actually done in the 3D window itself, and so will integrate with any Windowing toolkit, yep even GLUT! I'd recommend against using GLUT as it'll throw away all the threading and multiple windowing support that OSG is capable of. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] pagedLOD question
On Wed, May 14, 2008 at 1:54 PM, Brett Wiesner [EMAIL PROTECTED] wrote: Thanks Robert. By external file reference you mean a proxyNode correct? No, I mean the files referenced from the PagedLOD ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with multiple windows and GLcontext I think
Hi Ralf,
Perhaps the HardwareSubmeshDrawable isn't thread safe, beyond this I
can't really help, its not OSG code.
Robert.
On Wed, May 14, 2008 at 1:56 PM, Ralf Stokholm [EMAIL PROTECTED] wrote:
Hi All
Im getting a chrash when using a hardwaremesh defined in the open source
engine delta3d, I have postet this question on thir forum as well but so far
no one has answered and since this might be relatet to osg or opengl ill try
posting it here.
My application makes use of two windows window a shows a head down view of a
cockpit and window b shows a view of the outside. In the cockpit view I have
a MFD (multi function display) that are linked to a targeting pod camera.
This camera also renders the outside as seen through the targeting pod.
I resently started experimenting with AI and characters and my problem
showed up the first time the character was shown in both views at the same
time, it chrashes with an exception that (as far as I can see) originates in
the graphics driver. The problem is shown both on nvidia and ati graphics
cards.
The last point in the call stack that i have code for is this function.
void HardwareSubmeshDrawable::drawImplementation(osg::RenderInfo
renderInfo) const
{
//select the appropriate mesh
mHardwareModel-selectHardwareMesh(mMeshID);
osg::State state = *renderInfo.getState();
//bind the VBO's
state.disableAllVertexArrays();
const Extensions* glExt = getExtensions(state.getContextID(),true);
glExt-glBindBuffer(GL_ARRAY_BUFFER_ARB, mVertexVBO);
unsigned stride = 18 * sizeof(float);
#define BUFFER_OFFSET(x)((GLvoid*) (0 + ((x) * sizeof(float
state.setVertexPointer(3, GL_FLOAT, stride, BUFFER_OFFSET(0));
state.setNormalPointer(GL_FLOAT, stride, BUFFER_OFFSET(3));
state.setTexCoordPointer(0, 2, GL_FLOAT, stride, BUFFER_OFFSET(6));
state.setTexCoordPointer(1, 2, GL_FLOAT, stride, BUFFER_OFFSET(8));
state.setTexCoordPointer(2, 4, GL_FLOAT, stride, BUFFER_OFFSET(10));
state.setTexCoordPointer(3, 4, GL_FLOAT, stride, BUFFER_OFFSET(14));
//make the call to render
glExt-glBindBuffer(GL_ELEMENT_ARRAY_BUFFER_ARB, mIndexVBO);
glDrawElements(GL_TRIANGLES, mHardwareModel-getFaceCount() * 3,
(sizeof(CalIndex) 4) ?
GL_UNSIGNED_SHORT: GL_UNSIGNED_INT, (void*)(sizeof(CalIndex) *
mHardwareModel-getStartIndex()));
glExt-glBindBuffer(GL_ARRAY_BUFFER_ARB, 0);
glExt-glBindBuffer(GL_ELEMENT_ARRAY_BUFFER_ARB, 0);
// This data could potential cause problems
// so we clear it out here (i.e CEGUI incompatible)
state.setVertexPointer(NULL);
state.setNormalPointer(NULL);
state.setTexCoordPointer(0, NULL);
state.setTexCoordPointer(1, NULL);
state.setTexCoordPointer(2, NULL);
state.setTexCoordPointer(3, NULL);
}
From chat i can see the function is calle 3 times for each window to draw
the character and the only difference is in the GLContextId and other
context related members of state.
The chrash comes from this line.
glDrawElements(GL_TRIANGLES, mHardwareModel-getFaceCount() * 3,
(sizeof(CalIndex) 4) ?
GL_UNSIGNED_SHORT: GL_UNSIGNED_INT, (void*)(sizeof(CalIndex) *
mHardwareModel-getStartIndex()));
Can any of you see anything wrong with this code or give me a hint where to
look, there is no problem as long as im only rendering the character in one
window, I teste the behavior in a delta3d sample and if the character is
rendered in 2 windows at the same time it chrashes, if it is rendered in two
view's in the same window it works fine.
Brgs.
Ralf Stokholm
___
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] VRML Normals
Hi Ben, The answer to the question Has this bug been fixed in version 2.4 can be found by browsing the SVN repository online: http://www.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/vrml/ReaderWriterVRML2.cpp From this: 3) Smoothed normals are computed if no normal field is provided. So I'd guess that it is now fixed. Robert. On Wed, May 14, 2008 at 3:21 PM, Ben Axelrod [EMAIL PROTECTED] wrote: I noticed that OSG 2.2 does not properly calculate the normals of VRML files. It seems like it points all the normals at (0, -1, 0). This is only when the normals are not explicitly specified in the file. If you open a VRML file like this in osgviewer, you can see that the coloration of the mesh is only accurate when looking at the top of the object. If the normals are specified in the VRML file, then the mesh coloration looks correct in osgviewer. I can supply an example VRML files that demonstrate this bug, and also how to fix it. Has this bug been fixed in version 2.4? Thanks, -Ben ___ 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] osgWidget 0.1.8 (pre-merge)
Hi Thibault,
On Wed, May 14, 2008 at 4:02 PM, Thibault Genessay [EMAIL PROTECTED] wrote:
I really don't know why it is this way - I had actually never noticed
that ref_ptr had this feature. It makes more sense to me how the
observer_ptr is implemented because ref_ptr and observer_ptr are
just proxies that should IMHO behave like ordinary references or
pointers when we call operator*() or operator-(). (I'm sure a C++
guru could slap me for what I've said, but I'd enjoy it if it came
with an explanation :)
Which version of the OSG are you using? In 2.4 the observer_ptr is
consistent with
ref_ptr i.e.
inline T operator*() const { return *_ptr; }
inline T* operator-() const { return _ptr; }
inline T* get() const { return _ptr; }
The next question is this wacky world is why does ref_ptr and
observer_ptr do this trick?
Try:
typedef std::set osg::ref_ptrNode MySet;
Then try to access members of it, and you'll find out they are in fact
now a const ref_ptr and you
can't access any non const methods of Node. What the const method
here is const of the ref_ptr
not const of what its pointing to. If you meant this then you'd have
osg::ref_ptrconst Node.
However, it all can get a bit sticky, as sometimes you intend const
osg::ref_ptrNode to be const osg::ref_ptrconst Node in which case
the relaxation of the the above accessors misses this.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering to a image file (taking a screenshot)
Hi Galen and Arne, On Wed, May 14, 2008 at 7:32 PM, Arne Kreutzmann [EMAIL PROTECTED] wrote: osg::ref_ptrosg::Image image = new osg::Image; image-readPixels(_x,_y,_width,_height, GL_RGB,GL_UNSIGNED_BYTE); osgDB::writeImageFile(*image,_filename); you could add that piece to a osgGA::GUIEventHandler so that it take the snapshot on a key press. This will only work when you've viewer is SingleThreaded, all other threading models it'll crash as you can only do glReadPixels when you have a valid graphics context. The proper way to capture the screen image is to use a Camera post draw callback, in fact in 2.4, you also have a final draw callback which is best one to use as it'll capture any post rendering that you do as well (i.e. HUD). My plan is to add an EventHandler to do screen snapshots and provide this along with the osgViewer::ViewEventHandlers family of handlers, its just time and a overflowing todo list has prevented me from tackling it. Others are welcome to dive in and add it :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeoTIFF dem coordinate system?
Hi Linh, On Wed, May 14, 2008 at 8:20 PM, Linh Phan [EMAIL PROTECTED] wrote: In VPB there isn't any support for substituting a custom value for NoDataValue elements, this could be added though. That would be great if you can added to VPB. Please let me know when you have it in so I can test it. :) Thanks Robert. When I say this could be added it means just that, I didn't say specially who would be added it... VPB being open source is open to end users adding features that they require, now these features might be added later by someone else so you could wait and hope that the feature will be added when you need it, or just roll your sleeves and code it. For this particular feature the next time I'm working around this code I'll have a look at adding an option to specify the default elevation to use, it shouldn't take more than a couple of hours. However, I can't say when I'll get around to this. Yes, I have spent the last few weeks to migrate over to OSG-2.4 using osgViewer now, which I think is easier to use than osgProducer::Viewer. Great this will make utilisiation of latest VPB features much easier. It's good to hear that you find osgViewer easier to use than osgProducer, as this was the one of the goals for the work. And then pass the .vrt file to VPB instead of your .tif I have tried this but VPB didn't support the NoDataValue elements and still inserted 0's for where there were no data. VPB does support GDAL NoDataValue, it just substitues 0's in for them, or alpha's them out in the case of textures. What is missing is the ability to define the default elevation to use when a NoDataValue occurs. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rendering to a image file (taking a screenshot)
Hi J-S, On Wed, May 14, 2008 at 8:27 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: I'll do it, I'll do it! :-) ;-) (seriously, it's one of the things I have to do in the next few days for our own software, and I was planning on making it generic enough to factor out) A few questions before I embark on this. a) What should the strategy be for multiple windows, multiple screens, multiple graphics contexts? I was thinking of making the same handler be bindable to multiple cameras, so that with one key press you can (potentially) capture all cameras, or at least multiple cameras. Maybe also have it be bindable to a CompositeViewer, so it will automatically capture all its views' cameras. What do you think? Ideally it'd be configurable - so you can capture particular camera's, through to all cameras. There is also the aspect of capturing the window contents rather than just individual cameras. Now managing this through one API might be a little tricky, I'm open to suggestiong. Implementing a window capture is also something that isn't best done via a Camera FinalDrawCallback, and would be better tackled via a GraphicsOperation that is done just before the SwapBuffersOperation. GraphicsContext's doesn't yet make this very straight forward to manage though so we might need to tweak the API in Graphics Context/GraphicsThread a little to make things more controllable. b) What should the filename strategy be? Say I capture twice (two different frames), the second time, should I just check if the file exists and if so, tack on an incrementing integer at the end of the filename? The filename is something that should be set by the application developer. One could also write the EventHandler so that its straight forward to subclass/reuse components from so that developers can implement the exact controls they want. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG-QT4 integration
Hi Venugopol, I only have knowledge of the core OSG's osgviewerQT example, so can't answer anything about Gazhihan's example. What problems do you have? What platform are you working on? Robert. On Thu, May 15, 2008 at 4:14 AM, venugopal gudimetla [EMAIL PROTECTED] wrote: Hi, I am a newbie. I tried Gazihan Alankus's Qt4 based OSG widget QOsgWidget example, but the example seg-faults. Could anyone please help me with a simple example? your help is greatly appreciated. I am not making any headway. I also tried osgViewerQT example, but couldn't make it work either. So even if someone guides me through compiling this example too would be fine. Thanks, Venu. Windows Live SkyDrive lets you share files with faraway friends. Start sharing. ___ 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] osgthirdpersonview example: anyone else with an ATIhaving problems?
HI Paul, On Thu, May 15, 2008 at 8:56 AM, Paul Melis [EMAIL PROTECTED] wrote: gcc 4.1.2, I believe (pretty sure it's one from the 4.1 series). Why, are there known defects regarding threading? I'm using gcc-4.1.3 under Kubuntu with NVidia drivers, and certainly don't see any threading problems. I have used lots of versions of gcc and Nvidia drivers and haven't seen problems like the ones you are experiencing. I think it probably pretty safe to assume that gcc is just fine. I suspect the OSG is just fine as well. The most likely candidate for a problem is the ATI driver, something under OpenGL, especially under Linux has a poor track record. So I'd suggest checking ATI support forums, and filing a big report with ATI. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] reg:material properties
On Thu, May 15, 2008 at 11:05 AM, [EMAIL PROTECTED] wrote: how do we give emmisive property to an object in osg...in opengl it can be done via material properties is there something similar to that in osg. glMaterial - osg::Material ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stack of actions todo
Hi Vincent, How much threading have you done before, i.e. how confident are you about using threads, blocks and barriers? I asks this as I doubt no how much to assume. Robert. On Thu, May 15, 2008 at 11:25 AM, Vincent Bourdier [EMAIL PROTECTED] wrote: Hi Robert, You said then you'll need to place a barrier in frame loop to half the frame loop thread I'm not sure to understand how I can do it, and what do you mean by half the frame loop ?? Moreover, I need a stack, that will be re-used for an other way, so I think I'll keep this idea. I suppose the STL is the best way to do it and OSG not implement something more useful for my problem. Thanks, Regards, Vincent. 2008/5/15 Robert Osfield [EMAIL PROTECTED]: Hi Vincent, The OSG designed around the model of single threaded update, multi-thread cull-draw. If you have others threads beyond the main frame loop thread that is want to do updates then you'll need to place a barrier in frame loop to half the frame loop thread while you operations run, then release the barrier when you operations are complete for that frame. Robert. On Thu, May 15, 2008 at 10:39 AM, Vincent Bourdier [EMAIL PROTECTED] wrote: Hi Alberto I just need to control when I flush the stack, to synchonise with the threads. A Callback would flush the stack (and so modify the graph) at the same time of the callbacks which traverse the graph... It is dangerous. I would stop the threads, flush my stack, and notify the threads to continue... 2008/5/15 Alberto Luaces [EMAIL PROTECTED]: El Jueves 15 Mayo 2008ES 11:00:41 Vincent Bourdier escribió: Hi all, After a look on the net and in the archive, I think nobody did it before, but I prefer ask to earn time : I need to do something like a stack or a list of actions to apply on the scenegraph (FIFO stack if possible). I've a thread which will create the actions to make, and I need to do theses actions on the render loop, stopping the thread during the flush of the stack. Do OSG implement something like this ? Thanks, Regards, Vincent. Hi Vicent, how would it be different from an update callback? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org 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] Hang on cooperativeWait in atexit
Hi Anders, When managing threads one has to be very careful about destruction order. The key is to make sure the the threads are stopped before any objects they are operating on are deleted. Since you are off in your own code that isn't much specifically that I and others can do to help. Robert. On Thu, May 15, 2008 at 10:11 AM, Anders Backman [EMAIL PROTECTED] wrote: Long time no see :-) Using Osg 2.2.0. WinXP, VisualStudio 2008. I have a slight problem that I cant seem to get around. We have a thread with a few OpenThread::Block, and in the destructor of the thread we call block.release(). The thing is that the thread is still running when scope of main goes out. So we have a atexit() function that does the deallocation, and tries to delete the threads. The problem is that one of the Blocks (we have two in the thread) causes a hang in the call to: Condition::cooperativeWait(). This was mentioned as a problem here: http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2008-March/009081.html With no result as far as I can see... Its a problem only under win32. I have seen it before, but at that time we found a way around it (by shutting down the threads in main), this time we don't. Callstack: ot9-OpenThreadsd.dll!OpenThreads::Win32ConditionPrivateData::broadcast() Line 71C++ ot9-OpenThreadsd.dll!OpenThreads::Condition::broadcast() Line 100 C++ agxd.dll!OpenThreads::Block::release() Line 69 + 0x13 bytesC++ agxd.dll!agx::Block::release() Line 540C++ agxd.dll!agx::WorkThread::~WorkThread() Line 33C++ agxd.dll!agx::WorkThread::`vector deleting destructor'() + 0x54 bytes C++ agxd.dll!agx::ThreadPool::shutdown() Line 106 + 0x2c bytes C++ So anyone seen this (and solved it) or any ideas of what might be behind this issue? -- Anders Backman Email: [EMAIL PROTECTED] HPC2N/VRlab Phone: +46 (0)90-786 9936 Umea university Cellular: +46 (0)70-392 64 67 S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 http://www.cs.umu.se/~andersb ___ 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] osgthirdpersonview example: anyone else with an ATIhaving problems?
Hi Zoltan, On Thu, May 15, 2008 at 10:59 AM, Zoltán [EMAIL PROTECTED] wrote: osgwindows works, see attached screenshot (It's quite funny to see the same cow turn in 2 different windows, if that is what it's supposed to do). osgwindows is written to allow you to move the windows about, whilst still having the two windows render different bits of the same view. This is an example when a viewer has a master camera which controls the overall view, and two slave cameras that track the masters view matrix, with offsets of the projection matrix to give the offset view. This type of set up is used when rendering to powerwalls composed of several displays. The fact the OSG can do this so seamlessly is one of strongest features (for those who need it..) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgthirdpersonview example: anyone else with an ATIhaving problems?
On Thu, May 15, 2008 at 11:28 AM, Zoltán [EMAIL PROTECTED] wrote: I'm writing a flight simulator, and one of the things I have been thinking about is, one day, having multiple screens to have a larger FOV. So yes, this is a very interresting feature. Not sure yet how much overhead that brings. The overheads are pretty low if you have a multi-core, multi-GPU system, this can be achieved thanks the OSG support for threading cull and draw across the various displays so it scales well as you up the number of displays. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Stack of actions todo
Hi Vincent, The OSG designed around the model of single threaded update, multi-thread cull-draw. If you have others threads beyond the main frame loop thread that is want to do updates then you'll need to place a barrier in frame loop to half the frame loop thread while you operations run, then release the barrier when you operations are complete for that frame. Robert. On Thu, May 15, 2008 at 10:39 AM, Vincent Bourdier [EMAIL PROTECTED] wrote: Hi Alberto I just need to control when I flush the stack, to synchonise with the threads. A Callback would flush the stack (and so modify the graph) at the same time of the callbacks which traverse the graph... It is dangerous. I would stop the threads, flush my stack, and notify the threads to continue... 2008/5/15 Alberto Luaces [EMAIL PROTECTED]: El Jueves 15 Mayo 2008ES 11:00:41 Vincent Bourdier escribió: Hi all, After a look on the net and in the archive, I think nobody did it before, but I prefer ask to earn time : I need to do something like a stack or a list of actions to apply on the scenegraph (FIFO stack if possible). I've a thread which will create the actions to make, and I need to do theses actions on the render loop, stopping the thread during the flush of the stack. Do OSG implement something like this ? Thanks, Regards, Vincent. Hi Vicent, how would it be different from an update callback? ___ 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] Stack of actions todo
On Thu, May 15, 2008 at 11:43 AM, Vincent Bourdier [EMAIL PROTECTED] wrote: I'm not very familiar with threads, and no more with OpenThreads... but I learn quickly if I understand. But if I need to spend a week to understant and set it, I'd better make my stack I think... Have a read through docs on pthreads as OpenThreads is maps pthreads functionality quite well, basically providing a C++ wrapper for the underlying thread implementation and a few help classes on top. The core OSG has a few further higher level help classes like osg::Operation and osg::OperationThread that you could use. A basic grounding with threading in general will help you understand the issues. Also do searches through the OSG itself to see how it uses various OpenThreads classes. Don't expect threading to come easy though, it's can be a hard topic the first time you start working on it, so invest the time now you'll benefit from this for the rest of your career. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB: Call to GDALRasterBand::RasterIO returns wrong no data values for gtopo30
Hi John, This sounds like a GDAL bug. Would it be possible for you to provide links to the problematic data. I'd guess the GDAL team might like to look at it as well. Robert. Robert. On Thu, May 15, 2008 at 12:22 PM, John Vidar Larring [EMAIL PROTECTED] wrote: Hi, Problem Summary: The calls to GDALRasterBand::RasterIO() in vpd::SourceData::getInterpolatedValue() and vpd::SourceData::readHeightField() returns no-data-values as 55537 instead of the correct - for gtopo30 data. VPB: revision 911 OSG: revision 8321 GDAL version 1.5.1 The following command line is used to create a simple globe (all DEM files from gtopo30 are used): ./osgdemd -d in/gtopo30/E020N40.DEM [...snip...] -d in/gtopo30/W180S60.DEM --bluemarble-east -t in/bluemarble/land_shallow_topo_east.tif --bluemarble-west -t in/bluemarble/land_shallow_topo_west.tif --geocentric --radius-equator 6378000 --radius-polar 6378000 -v 1.4 -l 6 -o out/simple_globe.ive -a out/simple_globe.osga gdalinfo reports that the no-data-value for the DEM files are -: dhcp6(bin)% /usr/local/bin/gdalinfo -stats in/gtopo30/E020N40.DEM [...snip...] Min=-.000 Max=5825.000 Minimum=-.000, Maximum=5825.000, Mean=-2347.600, StdDev=4873.500 NoData Value=- ... however, in the globe created by the command line above, the sea level is high above ground. After some debugging, I made the following observations: * SourceData.cpp - vpd::ValidValueOperator::ValidValueOperator() obtains the correct no-data-value (-9990) though GDALRasterBand::GetNoDataValue() * In vpd::SourceData::getInterpolatedValue() no-data-values are not clamped to 0.0f (zero) because GDALRasterBand::RasterIO() returns no-data-values as 55537.0f (the same happens in vpd::SourceData::readHeightField()) I highly temporary work-around hack was to alter the initialization of vpb::ValidValueOperator::maxValue in line 38 in SourceData.cpp from maxValue(FLT_MAX) to maxValue(55000.0f). Hence, the faulty no-data-values are clamped to zero. I am totally new to OSG/VPB. Does anyone have an idea of how to make a permanent fix for this problem? Is it just an incompatibility problem with GDAL 1.5.1? or... Any advice would be greatly appreciated. Best regards, John Larring -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] OSG-QT4 Integration
Hi Venugopal, I have already replied to you on this topic asking specifically what problems you are having with the osgviewerQT example. I run Kubuntu 7.10 and am able to compile and run the osgviewerQT example without problems. Howewever, I and no one else can do anything to help you unless you tell us what problems you are seeing. Robert. On Thu, May 15, 2008 at 1:42 PM, venugopal gudimetla [EMAIL PROTECTED] wrote: Hi, Could anyone please help me? I tried examples on the OSG website and link example but nothing semms to work. I am on Ubuntu Linux. Could anyone please direct me/email me a working example to integrate QT4 with OSG? please help. I just started using OSG. _ Get Free (PRODUCT) RED™ Emoticons, Winks and Display Pics. http://joinred.spaces.live.com?ocid=TXT_HMTG_prodredemoticons_052008 ___ 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] VPB: texture banding at all tile levels
Hi John, This is a new one for me, never seen banding reported before. Could you try running a release build of osgdem to see if the problem persists. Also try out the database on other computers with different hardware as there is chance that you are seeing a OpenGL driver problem. Robert. On Thu, May 15, 2008 at 2:30 PM, John Vidar Larring [EMAIL PROTECTED] wrote: Hi, VPB: revision 911 OSG: revision 8323 The following command line is used to create a simple globe (all DEM files from gtopo30 are used): ./osgdemd -d in/gtopo30/E020N40.DEM [...snip...] -d in/gtopo30/W180S60.DEM --bluemarble-east -t in/bluemarble/land_shallow_topo_east.tif --bluemarble-west -t in/bluemarble/land_shallow_topo_west.tif --geocentric --radius-equator 6378000 --radius-polar 6378000 -v 1.4 -l 6 -o out/simple_globe.ive -a out/simple_globe.osga It does not matter what kind of Globe I try to create, I get black bands in the texture on all tile levels. Please see the screen shots below: ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_1.png ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_2.png ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_3.png ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_4.png I successfully generated the globe with an earlier OSG revision on a different computer. However, my memory fails me an I cannot recall the revision number. Is anyone else experiencing this problem? Best regards, John -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] VPB: texture banding at all tile levels
HI Umit, The issue you are seeing is totally unrelated to the one John has seen. The problem you see looks like an issue with the elevation data, most likely related to the problems with the NoDataValue. However, without the data I can't do any tests to look at it.At your end try: gdalinfo E020N90.DEM -mm Robert. On Thu, May 15, 2008 at 5:46 PM, ümit uzun [EMAIL PROTECTED] wrote: Hi Robert; I have try to create the earth database like John's; osgdem --bluemarble-west -t land_shallow_topo_west.tif --bluemarble-east -t land_shallow_topo_east.tif --geocentric -o earth/earth.ive --so build.source osgdem -s build.source -d E020N90.DEM -d /E020N40.DEM -v 1.4 -l 6 And the result is http://img127.imageshack.us/my.php?image=earthto6.png Land height relief didn't created, only Sea height relief could be seen. I don't understand why its command created this dirty database. Any thinking about it? Thanks so much.. ÜMİT UZUN Date: Thu, 15 May 2008 14:39:13 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] VPB: texture banding at all tile levels Hi John, This is a new one for me, never seen banding reported before. Could you try running a release build of osgdem to see if the problem persists. Also try out the database on other computers with different hardware as there is chance that you are seeing a OpenGL driver problem. Robert. On Thu, May 15, 2008 at 2:30 PM, John Vidar Larring wrote: Hi, VPB: revision 911 OSG: revision 8323 The following command line is used to create a simple globe (all DEM files from gtopo30 are used): ./osgdemd -d in/gtopo30/E020N40.DEM [...snip...] -d in/gtopo30/W180S60.DEM --bluemarble-east -t in/bluemarble/land_shallow_topo_east.tif --bluemarble-west -t in/bluemarble/land_shallow_topo_west.tif --geocentric --radius-equator 6378000 --radius-polar 6378000 -v 1.4 -l 6 -o out/simple_globe.ive -a out/simple_globe.osga It does not matter what kind of Globe I try to create, I get black bands in the texture on all tile levels. Please see the screen shots below: ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_1.png ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_2.png ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_3.png ftp://ftp.weatherone.tv/private/jvl/vpb_texture_banding_4.png I successfully generated the globe with an earlier OSG revision on a different computer. However, my memory fails me an I cannot recall the revision number. Is anyone else experiencing this problem? Best regards, John -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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 _ Windows Live Spaces – hayatınız, Alanınız. Daha fazlasını öğrenmek için buraya tıklayın. http://get.live.com/spaces/overview ___ 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 instead of osgProducer::Viewer
Hi Eric, On Thu, May 15, 2008 at 9:43 PM, Eric Sokolowsky [EMAIL PROTECTED] wrote: I'm porting my application from OSG 1.2 using osgProducer::Viewer to OSG svn. Most of the port was straightforward, though I'm encountering some strangeness. My questions: 1. Is there a page on the wiki that covers porting OSG 1.2 to current OSG? I'd like to add some of my notes to that page if it exists. Link to from the Document main page: http://www.openscenegraph.org/projects/osg/wiki/Support/Porting 2. I am running under Linux (Centos 5.1) with Nvidia dual-head graphics. When I run my application without any --screen or --window, it fills up the left monitor but the viewport reports the size of both monitors. Is there a way to retrieve only the part of the X screen that is used by the OSG rendering? This sounds like X11 is reporting sizes in an odd way, what should happen is the viewer should open up full screen on each of the available screens. I guess this could be a window manage bug. FYI, you are the first to report such a problem under X11 so I'd guess that there is something unusually about your setup. Could explain more about it. On my system right now I have two X11 screens set up on a single NVidia graphics card. Previously I've also used a single X11 screen spanning both mointors, the Xinerama extension can be used for controlling where the windows opens up, but typically in this setup I switch it off as I want a single screen for performance. 3. There is also something weird going on when using Producer camera config files with borderless windows, but I haven't pinned down the problem yet. Is anyone else using these successfully? Could you provide the problem .cfg files? When you say weird what do you mean? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QT4-OSG integration on Ubuntu Linux
Hi Venugopal, Boy you like to make it difficutl to reply to your posts... Pleas e in further *do not* piggy back your reply off the back off digest posts, because it makes what should be 10 line posts to a 1000 line one. As for your errors, does it compile with CMake build that comes with the OSG? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VirtualPlanetBuilder and pagedLOD chalenges my Targeting pod camera
Hi Ralf, VPB couples terrain with imagery storing them in exactly the same .ive tiles. Normarily one shouldn't have to tweak --radius-to-max-visible-distance-ratio, performance should be good without any tweaks, and should scale to terabyte databases. I found it pretty hard parsing your email thanks to all the acronyms so am not entirely clear on what your hardware set up. It may be that Delta3D is part of the problem, try building the VPB database and viewing using osgviewer to see if there is performance delta. Use of Windows for a visual simulator is not something I would recommend, the file system performance sucks big time, memory management and threading support is not great either. Install a modern Linux and you'll probably find many of your issues gone. I'd also recommend an upgrade to OSG-2.4 as the DatabasePager has been improved w.r.t load balancing, keeping memory consumption much more even. OSG-2.4 also offers improvement to osgTerrain, such that one can now control the sample density of elevation data via the osgTerrain::Terrain class, to generate such databases you'll need to build using SVN version of VPB and use the --terrain option. Robert. On Fri, May 16, 2008 at 8:44 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: Hi Im working on a flight simulator project and have been using VTP to generate a terrain for visualisation, The input data is 30m landsat orthofoto and 90 m nasa elevation data. In addition there are som higher resolution orthofoto for specifik target areaes dovn to 25 cm resolution. My application has a Targeting POD displaying in the cockpit in adition to the standart otw view, the problem is that I have a hard time getting it to run smothly. To keep good quality in the TGP view I had to increase the --radius-to-max-visible-distance-ratio from default 7 to 25 in order to get the orthophoto to load early enough in my zoomed targeting pod view. I I generate the terrain without height date it almost runs smooth at that setting, but with elevation data it studders all the time. Especially when turning my head. Im using the delta 3d engine and the allocate 4ms for paging opperations each frame. This is tested on a brand new system Core2 duo 3.0 Ghz 4 Gb RAM and a geforce 9800 GTX, it has a raid0 hard drive etc so I cant emagine this it the limiting factor. Oh its running windowsXP sry :( OSG is verison 2.2.0 and VTP is version 0.9.1 The aplication is rendered on 2 displays a 1920x1200 display for the cockpit TGP view is roughly 512x512 ans a 1920x1080 display for external view. The following is the command line used for generating the terrain archive. osgdem -d height -t texture -l 20 --radius-to-max-visible-distance-ratio 25 -v 1.1 --cs +proj=laea +lat_0=55.5 +lon_0=9.5 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs -o denmark.ive -a denmark.osga Is there any way of making the terrain load later in the OTW view? Or any other hints on what parameters to play around with to improve the performace of this? Brgs Ralf Stokholm ___ 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] VirtualPlanetBuilder and pagedLOD chalenges my Targeting pod camera
Hi Ralf, On Fri, May 16, 2008 at 10:06 AM, Ralf Stokholm [EMAIL PROTECTED] wrote: It sounds like I should defenatly try running it on a linux box, it will be quite a challenge though, havent spend much time with linux :( These days Linux is pretty slick as a development platform. It takes me just half another to install Linux, and all the development tools and sources required to build the OSG, this is from a blank disk to a work dev environment. Immediately I just use nedit as an editor, cmake/gmake for build, and gdb for occasional debug session so I have no IDE to install, but there are IDE's available, and it'll just be another item to click to install on modern installers. If you aren't familiar with Linux then it'll take you while to get up to speed, but once you are I'd expect you'd find it pretty productive. For a vis-sim runtime it's certainly one of the best platforms available. With cross platform tools like Delta3D and OSG you can even dev on one platform and reploy on another. The reason I have to tweak the --radius-to-max-visible-distance-ratio variable is that one of my cameras are rendering for a Targeting Pod (One of those aiming devices for laser guided bombs that you see on Discovery) This camera has the ability to zoom in on the target arear vith i.e. a 1.5 degree field of view, this results in visual artifacts ( texture popping) because a given lod is simply visible from farther away. What you you use is LODScale instead, this way you can adjust things according the display you use without needing to tweak the database. viewer.getCamera()-setLODScale(scale); // 1.0 is default Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VirtualPlanetBuilder and pagedLOD chalenges myTargeting pod camera
On Fri, May 16, 2008 at 3:01 PM, Thrall, Bryan [EMAIL PROTECTED] wrote: Robert Osfield wrote on Friday, May 16, 2008 3:04 AM: Use of Windows for a visual simulator is not something I would recommend, the file system performance sucks big time, memory management and threading support is not great either. Install a modern Linux and you'll probably find many of your issues gone. Not that I'm a big Windows fan, but I feel obliged to say an industry-grade flight simulator can run just fine on Windows, once Windows has been tweaked properly. My own company has several such simulators certified level D by the FAA :) But it would very likely run better under Linux, with less special care to avoid all the pitfalls of the Windows platform. There was a time when the best hardware for the job only ran properly under Windows, now this is no longer the case, Linux and OSX have caught up. Windows XP is at end of life, and Windows Vista performance is poor for OpenGL apps. While Linux just goes from strength to strength. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Computing intersections via an RTT camera - how?
Hi Glenn, Vieewer::computeIntersections() won't work when you start using funky stuff like RTT Cameras, you'll need to implement your of IntersectVisitor/LineSegmentIntersector/PolytopeIntersector codes to the do the scene intersections and use the RTT Camera's view and projection matrix as a guide. The osgpick and osgintersection examples should be able to help guide you. Robert. On Fri, May 16, 2008 at 3:09 PM, Glenn Waldron [EMAIL PROTECTED] wrote: Hello all, I could please use some guidance with the following problem. I have a typical scene graph and a simple viewer setup. I can run Viewer::computeIntersections() on the scene and it works fine. Then I insert an RTT camera in order to render the graph to a texture. I then map the texture to a simple quad and then display this quad alone (using another Camera with an ABSOLUTE_RF reference frame and an ortho projection). I would to be able to run computeIntersections() on the original scene graph (which is now under the RTT camera) and have it work just as before. But I have not been able to figure out how to make it work. The RTT camera does not have a View, so I cannot call View::computeIntersections. I've tried going through the code in View but still have not been able to figure it out. I would welcome any pointers in getting this working. Hopefully I've explained it adequately. -- Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : 703-652-4791 ___ 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] VirtualPlanetBuilder and pagedLODchalengesmyTargeting pod camera
Hi Bryan, On Fri, May 16, 2008 at 5:33 PM, Thrall, Bryan [EMAIL PROTECTED] wrote: I am also curious about the factors that hold developers back from deploying sims on Linux, i.e. even if Linux is superior at all the above, what prevents one from move to the platform? One of the primary reasons I've heard is that graphics card driver support is not as good as on Windows (i.e. lacking features, less responsive to bug reports, etc.). On the NVidia driver side I don't know of any features that are available under Windows but not Linux so I think this side of things is probably a non issue, except perhaps for the misconception that there might be differences. Responsiveness to bug reports is something I can't directly comment on as I've stood back from chasing driver developers about OpenGL bugs, rather just providing moral support for users who do go through this. In terms of bug reports about drivers under Windows vs Linux I'd say that if anything Windows users have reported more problems such as with mulit-threading issues. NVidia drivers do tend to be pretty good on both platforms. Alas I can't say the same for ATI drivers, especially under Linux. Overall I'd say worries about Nvidia OpeNGL driver features and support are most likely misplaced. Elements are far less unequivocal is that the file systems available perform far better than the Windows file system, so database paging performs better.Threading issues also occur far less often under Linux than under Windows, X11 has long been geared up for multi-threaded usage. Memory management under Linux is also far better than Windows - it's been quite common over the past couple of years for clients of mine have been struggling to get Windows apps for perform well when under high loads, with stalls quite and memory issues plaging development, while linux versions of the apps just chug along without dropping a frame. The compilers under Linux are also now better than the equivalents under Windows - update, cull and draws are typically faster under Linux than Windows on the same hardware. So when I hear people on the mailing list struggling to get things working smoothly under Windows I know one of the easiest remedies is try the apps under Linux. This isn't because the OSG is optimized for Linux, the OSG is about as platform agnostic as an project could be in this sector, its down to the underlying system being more efficient and better balanced which is why things work better. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Operating Systems + Applications - Application Systems
Hi All, Over the last few years I have seen a few trends in hardware and software that made me curious about the possibility that soon it might be quite easily to put together an operating system and our own applications together as one physical piece of media, and distribute this as a self contained turn key system. I'm not on my own in considering this as there are now a few Linux Live CD's that are dedicated to running just a signal application - Myth TV + Linux distributions are probably the most obvious one today, but there even items like CAD apps now being distributed this way. What makes this area of particular intererst to me is that some applications which can be treated as a turn key systems are games and simulators, these are of course bread and butter apps for scene graphs. For the turn key application developer I see and advantage in that you can control the whole software enviornment, taking you a step closer to the type of fixed system that a Console developer can work to. Or course PC hardware is far more varied than Console is, but thankfully OpenGL and a decent OS can hide much of these variants for causing us too much concern. What strikes me as madness right now is that you get games written with DirectX 9.0 implementation for Windows XP, DirectX 10.0 implementation for Windows Vistsa, and an OpenGL implementation for Linux and OSX is such ports are done - the madness is that all these versions of the software, all these different binary distribution that have to be created and tested all just target the same PC hardware, the only thing causing all this extra work is that there are just so many OS variants around. Alas its so much hardware to maintain all of these distributions that often games developers just target a single OS, so all the other OS users that have the same hardware are out of luck. Now if one bundles the OS + application together, placing it on a USB flash disk and boot from this disk then the actual OS installed on a PC becomes irrelevant, just take your key with you plugin it, boot the machine and there you have a PC hardware acting like a Console. With the cost of USB flash disks coming down it won't be too long before the cost of it won't be significant chunk of the cost of software. The same can be done for CD's and DVD's, performance isn't so stellar of course. If you do have a full blown turn key system then there is nothing stopping you from installing the Application System directly on the hard disk. There are technical hurdles with going for such approach, and is only really appropriate for certain classes of apps, but I'd guess that there are number of OSG users that might just fit this category quite nicely, or perhaps find it advantageous to have the ability to deliver their software in this way. Perhaps OSG users are already doing this, or are considering. The purpose of this email is to throw this possibility out there, and to get feedback from OSG users who might find such an means of distribution useful. There are members of the community far better placed to actual go ahead and implement such a system too so I'd be nice to hear from guys with more knowledge on the OS side. There are already tools for creating Live CD's, I haven't played with them yet, but perhaps in a few years I'll have time to... Perhaps even one day we'll been able to have a few pages on the OSG wiki about how to create your own OSG app Live CD/USB distribution ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Capsule Picking not working
Hi Alejandro, On Fri, May 16, 2008 at 8:33 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: I'm using LineSegmentIntersector to implement picking in my application. LineSegmentIntersetor works great and I've noticed it's really accurate when picking osg primitives like spheres, boxes and such, except for the Capsule. For some reason picking does not work on the Capsule primitive, it's just as if it wasn't there, but in that case, I shouldn't be able to see it either. Is there some thing I could have done to make picking stop working on the capsule? Does it have to be dealt with as a special case? I have just checked ShapeDrawable.cpp and it looks like code is there (it's the PrimitiveShapeVisitor inside ShapeDrawable.cpp that does the work), so I can't see any obvious reason why this might not work. I haven't personally tried picking and Capsules before so I can't real provide much wisdom on the topic, the best I can recommend is that you puts some debugging code into ShapeDrawable.cpp's PrimtiveShapeVisitor to see if you can pick up on anything that is being done wrong. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] glClearDepth
On Thu, May 8, 2008 at 1:24 PM, hesicong2006 [EMAIL PROTECTED] wrote: Please use the latest SVN version of OSG. Robert has added setClearDepth function to Camera. osg::Camera::setClearDepth is part 2.4, 2.5.x and SVN. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Check support for multi sampling
Hi Per, If the visual isn't supported then osg::createGraphicsContext(Traits*) will return NULL, so if get a null back then you can relax the Traits and try to create the context again. Robert. On Sat, May 17, 2008 at 12:50 AM, Per Rosengren [EMAIL PROTECTED] wrote: I set multi sampling with the following code: ref_ptr DisplaySettings displaySettings = new DisplaySettings; displaySettings-setNumMultiSamples(16); displaySettings-setMinimumNumAlphaBits(8); modelView-setDisplaySettings( displaySettings.get() ); If the graphics card does not support multi sampling, The program exits with this error message: Error: Not able to create requested visual. How can I make the program skip multi sampling and run without it if it is not supported? /Per ___ 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] Moving to Unix: WAS Re: VirtualPlanetBuilder and pagedLOD chalengesmyTargeting pod camera
Hi Brett, On Sat, May 17, 2008 at 3:51 AM, Brett [EMAIL PROTECTED] wrote: I am ready to move to Linux and have been for a long time, but am unsure which version to use, etc. I have Unix experience from back before, but still unsure of the curve to choose the right version / tools. Are Linuxes all the same, is there one better suited for developers. What are the nice development tools for 3d, ie. image editing, model creation / editing and visual development environment with debugging? Thanks. Justin's reply was pretty full, I don't really have much to add. I use Kubuntu on all my machines here. I used to use Suse, now I've moved over to Kubuntu I'venot really looked back - the key for me is the Ubuntu repositories, they make it really easy to grab practically any development tool you need for you work, all with a couple clicks in GUI, or a single line of command line. The proprietary NVidia drivers can also be enabled just with a GUI click on first install. All my Kids use Kununtu and love it, they range from 4 to 8 year olds. So its certainly not difficult to use, just takes a little getting used to different ways of doing things. I'll add to Justin's mention about file system performance, if you do VPB work then you'll find Linux several times faster to build than under Windows on the same hardware. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with multitexturing in latest svn?
HI Luigi, I've just tried under Kununtu with OSG SVN and marmol4.ive loads just fine and I get the snap_ok.jpg result. I haven't checked in anything that I'd expect to cause problems with multi-texturing, kinda odd to see you have problems with. Best I can recommend is try a clean build. Perhaps also try another machine. Robert. On Sat, May 17, 2008 at 10:50 AM, Luigi Calori [EMAIL PROTECTED] wrote: I' m experiencing a problem with multitexture on latest svn under winxp VC 7.1 it seem not working On the same pc, same cmake (2.6), same dependencies,same compiler, osg 2.4 is working well. Could someone with latest svn give some feedback on issuing osgviewer http://3d.cineca.it/storage/osg_test/multitexture/marmol4_jpg_net.osg (osg with external jpg texture) or osgviewer http://3d.cineca.it/storage/osg_test/multitexture/marmol4.ive (ive with internal dds) under osg svn the result is completely black (see snapshot attached) Thanks in advance Luigi ___ 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] Operating Systems + Applications - Application Systems
Hi Mike, On Sat, May 17, 2008 at 3:45 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Yes, the live bootable CD is a very interesting concept. I made something like that based on Knoppix years ago, that proof of concept used Mesa IIRC. It was like October 2002 and primarily a demo of VTP w/ my Eldorado Springs database. Have to find the .iso, rediscover what I actually did back then. Ahh so OSG has already been on bootable/live CD :-) More recently, a interesting project making progress in exactly this direction is myOS http://www.geocities.com/ze_aks/myos.html It's a bootable GL demo system that can fit on a 180MB miniCD. The versions I find most interesting are v1.1.9 or v1.0.3, which run X-less GL for a super low-overhead environment. Those versions of myOS use the SciTech SNAP/MGL drivers http://www.scitechsoft.com/products/dev/mgl_home.html I've been seeing occasional low key news items about myOS, and have browsed the web pages too but as yet haven't dived in to try it out. Alas haven't had much time to go play over the last few years... It'd be interesting to get osgViewer ported over to running without X. Do you know what API is being used to set up the graphics context? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Operating Systems + Applications - Application Systems
Hi Zoltan, On Fri, May 16, 2008 at 9:46 PM, Zoltán [EMAIL PROTECTED] wrote: you forget one particular piece of open-source stuff, or more specifically Linux stuff: proprietary drivers and GPL !!! I believe I left lots of details out even choice of OS :-) Linux is the one I'm most familiar with though... so if one did go with Linux one would have to look at the OpenGL driver situation. I've also read about a LiveCD distribution that provided 3D proprietary drivers out of the box for most hardware and that the GNU people attacked, and obliged to retract. That was because a distribution doesn't have the right to provide closed-source drivers in a GNU environment, and it is only possible if it is the user's *OWN PERSONAL* choice outside the GNU framework to do so. (I hope you understand what I try to explain, I'm no specialist in the area) I suspect the mixing of binary drivers with the linux kernel needs to be taken to court to get sorted out for once and for all. I find it pretty odd that its claimed by some not to be legal to distribute non GPL'd drivers together with a GPL'd kernel, yet after installing a GPL'd kernel then patching it with non GPL'd drivers is OK. I guess perhaps an interpretation of this situtation is that the copying/distribution of binary of the patched kernel that is not permitted, but if its compiled and ran locally then its not copying. I wouldn't have thought personal choice has anything to do with it being legal or not, its the act of distribution that part that will be covered by Copyright/GPL. Automating this kernel module recompile is some thing one could do on install I guess... as this would avoid the strict binary distribution of a patched kernel. However, the ideal is that open source drivers will match the quality of the proprietary drivers in the near future, this will clear up any ambiguities, it'll also give use middleware/app developers a chance to fix bugs that creep into drivers. I'd guess there are plenty of people on this list capable of digging into an OpenGL driver and groking how it worked, I already know that some did just this in a previous life... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Operating Systems + Applications - Application Systems
Hi Jan, On Sat, May 17, 2008 at 9:12 PM, Jan Ciger [EMAIL PROTECTED] wrote: Ahh so OSG has already been on bootable/live CD :-) I have one somewhere too, originally intended for my students :-p This is something I've been think about too - just giving training classes a USB disk with the OS, dev tools, data, the OSG and the rest of the training materials required for the course. My theory is that it'd avoid the need to help users jump through all the platform specific hurdles required to get the OSG built and running... It would of course introduce other issues... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VPB-0.9.7 paged-LOD hangs
Hi Renzil,
The VirtualPlanetBuilder is not written to be used for both viewer and
building at the same time, if it hangs or crashes then so be it, it's
not something it's been designed for, if it worked with VPB-0.9.1 most
likely it was a fluke, and not something you could have relied upon as
VPB/osgdem has never been designed to be used in the way you are
trying to use it.
Robert.
On Sat, May 17, 2008 at 11:05 PM, renzil d'souza [EMAIL PROTECTED] wrote:
My application uses osgdem code to ouput paged LOD files which I then proceed
to view using osgviewer. The app. was developed with vpb-0.9.1 and is based
on the osgdem code that came with vpb-0.9.1. After switching to vpb-0.9.7
libs, the app. had no problems generating paged-LOD terrains using the older
osgdem based code. But now, I've modified that code slightly to output
paged-LOD fles in a new thread, and the parent thread will proceed to render
using osgViewer libs as soon as the top-most node (root node) of the
paged-LOD has been written to the filesystem. I load the root node using
osgDB::readNodeFile(output.ive) once I know the file exists (again using
osgDB). Can this be done without any issues ? My system hangs with this
implementation. The strangest thing though, is if I run the stand-alone
application osgviewer with input as output.ive(which is the root node)
while the osgdem module is still working, i.e the paged-LOD files have not
yet been written to the di
sk
yet, it works. The scene automatically updates as the paged-LOD files are
written, which is exactly what I want. Here's the function that creates
terrain:
osg::ref_ptr
createTerrain(osg::ref_ptr dataset, unsigned int numLevels)
{
MyGraphicsContext context;
if (!context.valid())
{
osg::notify(osg::NOTICE)Error: Unable to create graphics context -
cannot run osgdemsetDataSet(dataset);
terrainThread-setNumLevels(numLevels);
// set the stack size for the new thread ... how big should this be ?
terrainThread-setStackSize(1024);
terrainThread-start();
//terrainThread-join();
// loop until the destination root is created ... is this safe ?
while(terrainThread-isRunning())
{
if (osgDB::fileExists(output_L0_X0_Y0_subtile.ive))
break;
else
OpenThreads::Thread::YieldCurrentThread();
}
//OpenThreads::Thread::microSleep( 10 );
osg::ref_ptr terrain = osgDB::readNodeFile(output.ive);
printf(\n\n\nHEREEE\n\n\n);
fflush(0);
// return the root node of the terrain
return terrain.get();
}
The run() function of CreateTerrainThread basically does this:
_dataset-loadSources();
_dataset-createDestination(_numLevels);
_dataset-writeDestination();
Both 'dataset' and 'numLevels' were setup first.
Thanks for your time.
Renzil D'Souza
_
Catch the latest fashion shows, get beauty tips and learn more on fashion and
lifestyle.
http://video.msn.com/?mkt=en-in
___
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] traverse
HI Valary,
The update and event traversals both have use a mechanism that stops
traversal when no children of a node contain
any nodes that requiring traversing. This feature is key to maintain
good performance on very large databases, without
it the update/event traversals would take dozens of milliseconds for
big databases and totally kill performance.
To enable traversal of only subgraphs that actually need it the scene
graph keeps an index of number of children requiring traversal - as
you've already spotted. In the case of setting a update callback this
index will be automatically updated, along with all the parents in the
parent path - making sure that the node with the callback will be
called. If you have a node that implements its own custom traverse
method then you'll need to set the index directly in the constructor.
For an example of this have a look at the implementation of the Switch
node - src/osg/Switch.cpp.
Robert.
On Mon, May 19, 2008 at 10:00 AM, Валерий Быков [EMAIL PROTECTED] wrote:
Hi all.
I have a question why Node::traverse(NodeVisitor) doesn't called with
NodeVisitor of type UPDATE_VISITOR?
I have a class derived from Geode and I remoulded function
traverse(NodeVisitor) for some update operations:
void MyClass::traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::UPDATE_VISITOR)
{
// Do smth
}
Geode::traverse(nv);
}
And I use osgViewer::Viewer for showing scene. But this function traverse is
never called with updateVisitor, because in
osgUtil::UpdateVisitor::apply(Geode) only callbacks is proceeded, but not
traverse.
And what about deriving from other classes and using traverse for update
operations then we can see that in osgUtil::UpdateVisitor::apply(Node)
calls function void handle_callbacks_and_traverse(osg::Node node) which
calls callback if presented and check
node.getNumChildrenRequiringUpdateTraversal()0 and calls traverse(node) in
this case. But as I can see in osg/src/Node.cpp,
_numChildrenRequiringUpdateTraversal changes in two cases: when update
callback is attached and when void
Node::setNumChildrenRequiringUpdateTraversal(unsigned int num) is called.
But I want to not use update callback, so, I must call
setNumChildrenRequiringUpdateTraversal for it. I would like to remould
function addParent for it, but this function is not virtual, so, I really
confused how to use traverse for update operations.
Best regards,
Valery
___
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] traverse
Opps... 2008/5/19 Robert Osfield [EMAIL PROTECTED]: For an example of this have a look at the implementation of the Switch node - src/osg/Switch.cpp. I'm meant to write osg::Sequence, rather than Switch, so you'll want to look at src/osg/Sequence.cpp. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] traverse
Hi Valery,
Geode's are meant to be leaf nodes, so are no intended to have
children other than drawables - which is why traverse() isn't
appropriate in this case.
If you do want to customize behaviour then could implement override
the Geode::accept() method, this is called before the
NodeVisitor::apply() as it's the actual accept than does the call to
the NodeVisitor. You'll still need to set the number of children
containing children to make sure the traversal gets down to your leaf
node.
Robert.
On Mon, May 19, 2008 at 11:27 AM, Валерий Быков [EMAIL PROTECTED] wrote:
Thanks a lot for explanation to you and Артём, but my class is derived from
Geode, therefore osgUtil::UpdateVisitor::apply(Geode) calls
handle_geode_callbacks(osg::Geode geode), which doesn't call traverse
anyway:
// should we traverse just in case a subclass of Geode adds children?? Won't
for now as
// Geode's aren't designed to have children.
// traverse(geode);
As I see Geode hasn't chance to update itself without callback?
P.S. Of cource, simple class can resolve this problem:
class CallTraverseCallback : public osg::NodeCallback
{
public:
void operator() (Node* node, NodeVisitor* nv)
{
node-traverse(*nv);
}
};
But is there way without callbacks?
___
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] FBO and AntiAliasing
Hi Paul, On Mon, May 19, 2008 at 12:51 PM, [EMAIL PROTECTED] wrote: The OSG's FBO implementation doesn't yet support anti-aliasing, but it shouldn't be difficult extension to add support for. I do have this on my TODO list, just unfortunately quite within grasp as I've been so swamped with other work. Robert. Has this been implemented yet in the latest version of OSG? Note yet. There is a submission for adding anti-aliasing to FBO, but it's written against OSG-1.2. I have done a review, but didn't port the work to 2.3.x at the time as it was non trivial and I was just swamped with other work. It's still on my TODO list. Feel free to tackle this yourself if I don't get on to tackling it soon enough. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Strategy for implementing dynamic vertical exaggeration of VPB models.
Hi John, VPB builds purely static databases that are stored on disk to be later loaded by the runtime that visualizes it. Since you want to vary the vertical exaggeration at runtime then the solution will have to be entirely on the OSG side, VPB actually has little to do with the actual implementation. In terms of implementation the route to take is write a Registry::ReadFileCallback that is called on the load of each new subgraph, see include/osgDB/Registry. Your callback will need to runs a custom NodeVisitor that modifies the underlying geometries height. Things that will complicate things are that the osg::Geometry leaves will be local coordinate frame undernearth an osg::MatrixTransform that places them in their final geocentric position, so you'll need to transform the local vertices into world coords, then compute the height about the ellipsoid, then compute the new position at the same lat/long but at the new height, then finally transform the point back into local coords. If you are building with the VPB --terrain option rather than the default then you get osgTerrain based tiles, then you'll probably want a feature that hasn't been written yet... Robert. On Mon, May 19, 2008 at 2:14 PM, John Vidar Larring [EMAIL PROTECTED] wrote: Hi, When creating globes with VPB one can use the option -v (vertical multiplier) to set permanent vertical exaggeration for the generated model. However, in our software solution the user must be able to set vertical exaggeration from the GUI (i.e. dynamically alter vertical exaggeration). What I'd like to know is: What would be a good strategy for implementing dynamic vertical exaggeration of VPB models? I am pretty new to OSG, so I would greatly appreciate any suggestions that could help to start me of in the right direction. My preliminary gut feeling is that the following strategy could possibly work: - Implement a node visitor to find all geode's in model. - For each geode, traverse each child drawable with an ArrayVisitor. - In the ArrayVisitor recalculate each vertex based on earth radius from CoordinateSystemNode/EllipsoidModel, distance from vertex to earth center, and vertical multiplier. Is this feasible? Are there any better strategies to follow? Performance issues/considerations when operation on ~50GB PagedLOD databases. Any hint and suggestions are very much appreciated. If anyone has example code that solves similar problems, I would kiss his/her feet in gratitude:) (not literally though;) Best regards, John -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] FBO and AntiAliasing
On Mon, May 19, 2008 at 3:01 PM, hesicong2006 [EMAIL PROTECTED] wrote: Hi, Robert, As you know, I'm current doing volume rendering work. Currently I've done a GPU voxelization using FBO but the sawtooth of the images greatly affects the result. So I'm very expecting FBO with anti-aliasing and please let know where the code with OSG1.2? I can have a reference. Thanks. Have a look at the osg-submissions archives. However, for volume rendering I wouldn't have thought using anti-aliasing would be the right approach - rather change the sampling of the 3D texture you use in rendering. 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 make the camera rotation not spin when it is dragged quickly with the mouse
Hi Matthew, If you release the mouse button while moving the mouse then the Trackball and TerrainManipulators will interpret this as a throw. So users find this really natural, others find it awkward to get used to. Right now there isn't any options built into the these manipulators for switching off the the throw support, but you are welcome to add a bool member and a set/get method to switch on/off this feature. You do this by subclassing, or just modifying the core classes and then sending me the changes for inclusion into the core OSG. Robert. On Mon, May 19, 2008 at 4:21 PM, [EMAIL PROTECTED] wrote: Hi, using the default camera mouse controls. Left click and drag rotates the camera, but you can kinda throw the camera if you drag and release quickly. Can I get some advice on how to prevent that? I guess can anyone tell me which GUIEventHandler does the viewer default to…is it Trackball? Finally to enhance camera mouse control I would expect to subclass from one of the MatrixManipulator classes and override the controls…sound right? ___ 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] NodeTrackedManipulator constantly segfaulting
Hi Alejandro, I haven't heard of NodeTrackManipulator sef faulting before, so this is a new one, I'd guess it would most likely be a usage issue, but perhaps you have uncovered a bug in the manipulator. First thing to test would be to run the osgsimulation example to see if that runs stable. Next up provide a stack trace, without there is nothing anybody else can help you with. Robert. On Mon, May 19, 2008 at 5:27 PM, Alejandro Segovia [EMAIL PROTECTED] wrote: Hello all, I'm trying to use osgGA::NodeTrackerManipulator to try to get a camera to follow a node as it moves around the scene, with very little success. After setting up the manipulator and setting the node it has to track, I get a segmentation fault when I call the getInverseMatrix method on it in order to adjust the camera. The crash is inside the computeNodeCenterAndRotation method in getInverseMatrix. Aside from setting the node to be tracked, I'm using all default values for the NodeTrackerManipulator. Has anybody experienced the same problem or know what I could possibly be doing wrong? I'm running OSG 2.2 on Debian Linux. Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.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
