From: Pablo C. E. <pab...@gm...> - 2009-11-25 19:31:47
|
Hi Carsten, thanks for the effort, I'm trying to check what's wrong, it must be something I'm doing here. Well, I've realized that I'm not transforming vertices to camera space to check intersection. AFAICT it must be done if the intersecting line is placed in camera space. But looking at Geometry intesect() code, no vertice is transformed to camera space. At that point all vertices are already transformed to camera space, or the intersecting line is placed at object's local space? Thanks for all help! On Wed, Nov 25, 2009 at 3:12 PM, Carsten Neumann <car...@gm...>wrote: > Hello Pablo, > > Pablo Carneiro Elias wrote: > >> On Wed, Nov 18, 2009 at 11:01 PM, Carsten Neumann < >> car...@gm... <mailto:car...@gm...>> wrote: >> have you checked whether it actually gets to execute your >> IntersectAction callback in both cases (can you isolate the problem to >> be in the ia->getLine().intersect() call) or does it perhaps not even >> get there (because tests against the bounding volumes fail higher up >> the >> tree)? >> >> I've checked and actually all callbacks gets executed and also all >> getLine().intersect() calls get executed and return true. So, in all cases, >> when a pick is performed over my custom geometry, >> many triangles get hit (intersect() returns true), and the setHit() call >> is performed. The setHit() checks whether the t parameter (which is >> calculated by the intersect() method and represent the ray scale at which >> the intersection occurred) is greater then zero, to grant that the >> intersection occurred in front of the camera. The problem is that this 't' >> parameter is being calculated as < 0 by the intersect() method, even with >> the geometry being visible. >> > > hm, so the question has boiled down to: why is the distance negative? I've > just tried this with some models on linux and windows (r2175) and I could > not notice any irregularities. Also looking at the history of files that > seemed relevant (OSGIntersectAction, OSGLine, OSGMatrix, OSGTransform) did > not show anything that looked like it could be related. > > > So, even after many setHit() calls, the didHit() returns false because no >> hit was actually set. This problem happens now after we have upgraded to the >> latest osg version. I've downgraded to the old version and the problem >> stopped happening. >> > > Do you only see this with your own geometry type or does it also happen > with regular geometry? I've so far not been able to reproduce the problem > with regular geometry, which unfortunately makes it difficult to find its > cause - all the existing code I've looked at looks reasonable and most of it > has not changed in a long time. > Can you post more details/code about your custom geometry, otherwise I'm > not sure how to diagnose this further from here. > In any case, I'm attaching a patch that I've used to get some insight into > what is happening during the IntersectActions traversal, you probably have > something similar by now, but perhaps it is still useful to you. > > Cheers, > Carsten > > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus > on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Opensg-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensg-users > > |