One question regarding the testing process though. Basically I have
implemented the SurfaceCutterFactory service as a part of mitkCoreServices.
Is it possible from within a test to replace this service with the one
that is useful for testing purposes? I mean, is it possible to access
some us::ModuleContext from the test code?
Rostislav.
On 09/08/2014 17:23, Rostislav Khlebnikov wrote:
Hi,
I don't know about licensing either, but it made me think that perhaps
something else can be done :)
I made an experiment - take the vtkCellLocator (which is the
implementation of an octree) and implement a visitor pattern for it's
recursive traversal (this includes making a bunch of terrible code -
because, you know, VTK) and then feed this to a subclass of vtkCutter
(even more copy-pasted ugly barely readable code with small change for
the usage of our vtkCellLocator subclass). However, I made this work!
Results for 500k triangles:
* vtkCutter: 88ms
* CutterWithLocator (our vtkCutterSubclass): 14ms
* CGAL: 2ms (yep, 45 times faster)
Interestingly enough though, the first cut request takes 1s for CGAL -
probably it has some kind of lazy evaluation there. So basically, the
AABB_tree raises to 1.5 seconds. However, I feel this is acceptable
given that it is a mesh with 500k faces.
So, if anyone is interested - I can give you the VTK code, however for
now I would say that I don't have time to clean up that code, it is
provided "as is" :)
Regarding the test - I think I can do this. This will also give me a
chance to familiarize with MITK test system.
Cheers,
Rostislav.
On 09/08/2014 11:20, Kilgus, Thomas wrote:
Hi there,
I know that we have done previous work regarding CGAL integration. I am not
sure about the licensing, but I am confident that someone knows it.
@Rostislav: The performance improvement sounds great. I know that the current
Mapper is very slow, especially when updating surfaces a lot. Could you maybe
add a rendering test for your class? You can find an example for the current
mapper in [1] and general documentation about rendering tests in [2]. That
should be very little work load (10-20 LoC) and would show differences between
the cutting implementations, if there are any. You can find surface data in the
data repository. This would ease the integration a lot for us.
Regards,
Thomas
[1]:http://mitk.org/git/?p=MITK.git;a=blob;f=Core/Code/Testing/mitkSurfaceGLMapper2DColorTest.cpp;h=174a5e98ace3b7da53c4bd629d6c499bdf70ec90;hb=HEAD
[2]:http://docs.mitk.org/nightly-qt4/RenderingTests.html
________________________________________
Von: Clarkson, Matt [[email protected]]
Gesendet: Freitag, 8. August 2014 21:12
An: Rostislav Khlebnikov
Cc: MITK
Betreff: Re: [mitk-users] Slicing surfaces with CGAL
Hi there,
I just thought I would ask: Is there going to be a problem with mixing LGPL/GPL
with BSD?
Matt
On 8 Aug 2014, at 20:05, Rostislav Khlebnikov
<[email protected]<mailto:[email protected]>> wrote:
Hi guys,
I have created a version of CGAL-based surface-plane intersection.
Things yet to be done:
* Integration of CGAL into superbuild process (also to things like
startVS_release.bat etc.)
* Actual performance-based cutter selection (in my pull request -
CGAL-based one is used)
Otherwise it works quite well for me.
The pull request could be found here:https://github.com/MITK/MITK/pull/73
The bug was filed back in 2012 :)http://bugs.mitk.org/show_bug.cgi?id=13948
Cheers,
Rostislav.
On 07/08/2014 16:12, Félix C. Morency wrote:
Rostislav,
I am also interested in this.
Thanks,
-F
On Thu, Aug 7, 2014 at 10:43 AM, Rostislav Khlebnikov
<[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/mitk-users
--
Félix C. Morency, M.Sc.
Plateforme d'analyse et de visualisation d'images
Centre Hospitalier Universitaire de Sherbrooke
Centre de recherche clinique Étienne-Le Bel
Local Z5-3031 | 819.346.1110 ext 16634
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
------------------------------------------------------------------------------
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users