Hi Sascha, yes, I think I can make such an implementation. I'm working on it right now and I will make a pull request in the near future.
All best, Rostislav. On 06/08/2014 17:04, Sascha Zelzer wrote: > Hi Rostislav, > > your numbers look very promising. We are using CGAL internally for > some projects and could move the build-system related stuff to MITK to > able to build CGAL with the MITK superbuild. > > I would be interested in a general interface for surface cutting > algorithms, so that we could use different implementations within the > mapper, based on their availability. Is that something you could come > up with, based on your previous experience? We could then modify the > mapper to get the highest ranked implementation and test various > approaches. > > Thanks, > > Sascha > > On 07/19/2014 05:10 PM, Rostislav Khlebnikov wrote: >> Just as a followup - with my relatively small reslice window geometry >> (50x50mm for full abdominal scan) - the triangle query takes 0.38ms >> which is 20(!) times faster than vtkCutter. And additionally it doesnt >> output almost any line segments that wouldn't be rendered anyway (almost >> being because I make one triangle that covers the quadrangular >> Geometry2D to avoid two queries). >> >> Rostislav. >> >> >> On 19/07/2014 15:57, Rostislav Khlebnikov wrote: >>> Hi guys, >>> >>> I noticed that with many polygonal surfaces in the scene, the rendering >>> process might become quite slow. I believe (haven't really tested it >>> thoroughly yet) that one of the most time consuming operations is >>> cutting the surface with 2D renderer window geometries to obtain the >>> contour for display. I made up a test where I compared vtkCutter with >>> CGAL's AABB_tree-based implementation. For model with ca 50000 faces, >>> the it takes 1.7ms to slice for CGAL and 7.8ms for vtk, so basically >>> 4.5 >>> times faster. Even more importantly, if I use the renderer's geometry >>> quad (as opposed to infinite plane) the intersection time is almost nil >>> when the surface doesn't intersect the geometry. Tree building itself >>> took 220ms but obviously it's one-time operation. >>> >>> I might implement the CGAL-based 2D surface mapper. Obviously it will >>> probably more than double the storage required for surfaces, but I >>> would >>> make this trade. I was wondering if any other users or developers of >>> MITK would be interested in this or have any thoughts on this? >>> >>> Rostislav. >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> Want fast and easy access to all the code in your enterprise? Index and >>> search up to 200,000 lines of code with a free copy of Black Duck >>> Code Sight - the same software that powers the world's largest code >>> search on Ohloh, the Black Duck Open Hub! Try it now. >>> http://p.sf.net/sfu/bds >>> _______________________________________________ >>> mitk-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/mitk-users >> >> ------------------------------------------------------------------------------ >> >> >> Want fast and easy access to all the code in your enterprise? Index and >> search up to 200,000 lines of code with a free copy of Black Duck >> Code Sight - the same software that powers the world's largest code >> search on Ohloh, the Black Duck Open Hub! Try it now. >> http://p.sf.net/sfu/bds >> _______________________________________________ >> mitk-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/mitk-users > ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ mitk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mitk-users
