Re: [osg-users] PolytopeIntersector, LineSegmentIntersector, and PagedLOD
Hi, Thanks for the tips. I know the planes' orientations need to be right. I assumed that by creating the Polytope from a BoundingBox that they would be, and when I inspect the values I think they're correct. I did try flipping them all in case I was wrong about the orientation, but that didn't help. I meant to say that I did set a read callback on my PagedLODs. The callback works just fine for rendering, but maybe there's something weird about it when it comes to intersection visitors. I'm generating traces now to see how the LineSegmentIntersector and PolytopeIntersector differ. Thanks again. Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58596#58596 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PolytopeIntersector, LineSegmentIntersector, and PagedLOD
Hi, I'm getting unexpected behavior from PolytopeIntersector and was wondering if it might have something to do with the PagedLODs in my scene graph. I want to find all polygons in a rectilinear volume in my model, in model coordinates (not related to any view on the screen) based on two corner vertices. The weird thing is that if I use the two corner points as the ends of a LineSegmentIntersector, I find intersections, but a PolytopeIntersector with Polytope made from a BoundingBox with those same corner points, over the same graph, finds no intersections. Shouldn't the PolytopeIntersector at least find the geometry that the LineSegmentIntersector does? I thought I might have the direction of the planes backwards for the Polytope, so I tried flip() but either way I get no intersections. I've read through the code and it looks like there might be issues related to the PagedLODs in my scene graph. Any idea if PolytopeIntersector and PagedLOD play together well or not? I've looked for examples and read code for PolytopeIntersector, but there doesn't seem to be much out there, and most of it uses View-based intersection, not model-based. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58575#58575 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in Qt thread integration
Hi, Thanks for the replies and suggestions. I think I might not have explained the issue as well as I thought, so I'll try again. QThread::currentThread does return a value with static type QThread*. However, it might not point to a QThread instance, but an instance of a subclass of QThread. The problem is that OpenThreads assumes that the return value can be cast to a pointer to a specific subclass of QThread that OpenThreads defines, QtThreadPrivateData, like this: Code: QtThreadPrivateData* pd = static_castQtThreadPrivateData*(QThread::currentThread()); This is a problem because if the current thread is a different subclass of QThread, this cast is invalid so when the new pointer (pd) is used, it causes a seg fault or random behavior. We have observed in our application that this does in fact sometimes occur. Specifically, QThread::currentThread can return a QAdoptedThread*, which is legal since QAdoptedThread is a subclass of QThread. I hope this clarifies things. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50392#50392 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in Qt thread integration
Hi, We have a large app that uses Qt for its 2D UI and OSG for 3D rendering and UI. So it seemed like a good idea to turn on the Qt-OpenThreads integration by enabling BUILD_OPENTHREADS_WITH_QT. However, I discovered that OpenThreads::Thread::CurrentThread() (in src/OpenThreads/qt/QtThread.cpp) does: Code: QtThreadPrivateData* pd = static_castQtThreadPrivateData*(QThread::currentThread()); If this is called when the current thread is a QThread that's not an OpenThreads Thread, the cast isn't valid and Bad Things(TM) will happen. This happens in our application (and when we're lucky we get a seg fault). We can disable BUILD_OPENTHREADS_WITH_QT without significant problem, but I wanted to report the bug and suggest that the documentation be changed to tell people not to enable this until it's fixed. BTW, we are using Qt 4.8.1 on RHEL5, but it looks like this problem could occur on any platform. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50335#50335 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in OverlayNode.cpp
Hi, I'd like to request that someone patch OverlayNode with this one-line fix. We are still having to work around it in our OSG application. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=47268#47268 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in OverlayNode.cpp
Hi, I have found a bug at OverlayNode.cpp:335: Code: for(unsigned int i=0; i baseVertices.size()-1; ++i) The problem is when baseVertices is empty, baseVertices.size() is 0 and (here's the surprising part) the compiler treats baseVertices.size()-1 as an unsigned int, which turns it into some huge positive number (18446744073709551615 on Linux on amd64). So the loop actually executes and seg faults. I have this case occurring in my application, I think because of an OverlayNode that has a valid overlay subgraph node with no children of its own. I'm sure there are other ways to fix this, but I would suggest fixing it by changing the above line to: Code: for(unsigned int i=0; i+1 baseVertices.size(); ++i) Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38233#38233 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] View-dependent OverlayNode w/o CoordinateSystemNode?
Hi, Thanks a lot for the quick reply. Yes, that's definitely an improvement. The demos now work better. VIEW_DEPENDENT_WITH_ORTHOGRAPHIC_OVERLAY looks good. But with VIEW_DEPENDENT_WITH_PERSPECTIVE_OVERLAY, the geometry that the overlay is pasted onto still turns all black in the osganimate and osgspheresegment demos. Changing the zfar doesn't seem to matter; using getPoints instead of computeSilhouette is what does it. Unfortunately, it doesn't solve my underlying problem (yet), which is needing to overlay geometry that's far apart. When I run my app with this modification, the overlaid geometry shows up in view-dependent mode (yay!), but it's still rendering all the overlaid geometry so the quality of the overlaid texture degrades as the bounding box of the overlayid geometry increases (boo!). I tried it both with perspective and orthographic rendering. I'm thinking now that maybe if I look more into computeSilhouette I might be able to get it to do what I want. But if you (or someone else) has any ideas about it or about other approaches, I'd love to hear it. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26302#26302 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] View-dependent OverlayNode w/o CoordinateSystemNode?
Hi, Has anyone gotten anything useful from OverlayNode in either view-dependent mode (VIEW_DEPENDENT_WITH_ORTHOGRAPHIC_OVERLAY or VIEW_DEPENDENT_WITH_PERSPECTIVE_OVERLAY) without using a CoordinateSystemNode? The examples osganimate and osgspheresegment produce strange results in either view-dependent mode. osgsimulation appears to work, however. My guess is that the significant difference is that osgsimulation uses a CoordinateSystemNode and the other two don't. But that's just a guess. OverlayNode is what I need, but I might have a lot of geometry to overlay, only a small fraction of which will be visible most of the time. So I need a view-dependent scheme. I've looked at osgearth and osggis, and they might do what I need, but integrating them into our codebase could be difficult. Thank you! Cheers, Chris -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=26277#26277 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
