Hi Nil,
you are completely right. The fiber bundle mapper is updated way too
often. I hope I could fix this issue. Now the mappers (2D and 3D) are
only called if the data has changed. This reduces the number of
rendering updates dramatically, e.g. upon loading a fiber bundle from
~99 times to 4 times (one time for each render window). I already pushed
the fix, so you can check if this helped with your performance issues.
However, the issue with the 2D slices is still present. I'm not the
rendering/shader expert, but I think Christoph is already supporting you
there, right?
Cheers,
Peter
On 19.08.2014 21:33, Nil Goyette wrote:
Hi Peter,
Thanks for your answer. I work with the main author of the
FiberNavigator. (In fact, we all met in Sherbrooke last year) We
decided to create FNav 2.0 because the first project has become really
hard to manage. It's fast, but it's coded using old technologies,
direct opengl calls and thousands lines of code. We tested MITK as a
framework to recreate FNav and we had huge performance problems. The
more I test, the more I think that modifying the mappers and avoiding
update is the key.
I have a question for you. We add a boundingbox with an interactor in
the scene. Each time we move it, it calls Update(). This is quite slow
when you use a big dataset. We replaced the 2D mapper with a mock
mapper (doing nothing) and everything was ok. I guess this Update is
important. Redrawing only the bounding box is probably not enough,
because we also need to redraw what was behind? Would it be possible
to refresh only the bounding box and stop the Update() process? What
would happen if I do that?
Also, I'm not really a OpenGL/MITK connoisseur, so I don't know if
it's possible to do that... With the 2D and 3D views, we are in fact
looking at the same data, in a different perspective. When we
visualize a FiberBundleX, the 3D mapper draws everything (glVertex3f,
etc.) then each 2D mapper takes a polydata slice and draws it. We are
sending the complete dataset + 3 slices of it. Would it be possible to
send the complete dataset one time, then ask each 2D views to apply a
geometry shader on the data that's already there? The shader would
keep only the vertices from zMin to zMax for Axial, xMin to xMax for
Sagittal and yMin, yMax for Coronal.
Thanks for your time.
Le 2014-08-11 03:37, Peter Neher a écrit :
Hi Nil,
sorry for the late reply! Indeed you are right. Handling such big
fiber bundles is an issue in MITK. In the last month I started to
feel these issues myself since the fiber files I am handling seem to
grow constantly :) I guess we will have to rework the whole fiber
representation in MITK to tackle this issue. The MITK fiber format is
basically an vtkPolyData and we are using the corresponding
vtkPolyDataMapper to get everything on screen but it seems this is
not the way to go for such big files. It would be interesting to see
how the FiberNav guys approached this task.
Regarding the unnecessary rendering refreshs of MITK, I will look
into that. Maybe we can tweak something there.
Again, sorry for the late reply. In general if you have issues
regarding fibers and tracking in MITK you can also include me
directly when sending an email to the users list. Then it's harder
for me to miss it.
Cheers
Peter
On 18.07.2014 22:43, Nil Goyette wrote:
Hi all, I tested loading a .trk file in MITK. My first test was a
500k fibers file and I got a allocation error. My second test was
with a 150k fibers files. I saw the Axial slice appear, waiting 5
minutes and it was still searching. I then tested a vtp file with
150k fibers (around 12 millions points). It loads fast enough (about
6 seconds), but each time I move the crosshair, it takes 5 seconds
or more to refresh. When I move in the 3D view, it's sometime really
fast (more than the FiberNav), sometime absolutely slow. I also had
problem with the window refresh. When I open the TaskManager, MITK
constantly try to refresh the 4view,.
I know I don't have the best computer around, but it was working
using the Fiber Navigator (a well known tool in the field). I tried
with a better computer and I had mixed results, it was ok 1 time out
of 3, randomly.
Is MITK built to handle such a big load? Can a user hopes to achieve
performance on par with the Fiber Navigator?
Thanks for your time.
--
Logo Imeka <http://imeka.ca/> Nil Goyette, M.Sc.
www.imeka.ca <http://imeka.ca/>
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
