I am aware that my problem description might be hard to follow without actual
screenshots to demonstrate the behaviour, that's why I uploaded a few screens
to my google-photo:
- https://photos.app.goo.gl/JZRosxicQS8u38K72
A short explanation:
1. Visualization of an imported grid (VTU file) after Global Reinit.
2. Visualization of the same grid after a Reinit on the associated Data
Node.
3. 2. From a different angle
4. 2. From a different angle, demonstrating the "getting to close"-
effect: note how the front part of the mesh gets cropped.
I also notices that some of the files won't even load if there is not already a
working mesh/image/... loaded. Loading those files will cause an access
violation in mitkSliceNavigationController.cpp in
mitk::SliceNavigationController::Update(...) at m_Time->SetRange.
Kind regards,
Bertram
From: Bertram Sabrowsky-Hirsch
Sent: 15 March 2018 10:23
To: [email protected]
Subject: [mitk-users] Reinit Problem with Meshes and Unstructured Grids
Hi,
I am experiencing problems with the visualization of Meshes and Unstructured
Grids (from VTU files).
The Meshes are rendered fine as long as there is another object (e.g. an Image)
loaded and the other one was used for a Reinit. A global Reinit also works fine.
However, when I try to reinit on the mesh/grid the 3D visualization behaves
very strange.
I tested it for multiple mesh/grid files and identified two different strange
behaviours:
1.) The top/right/back corner is centered.
2.) For others the bottom/left/corner is centered and there is a strange effect
where they disappear/get cropped when the camera gets to close. I figured they
might be mirrored/negative scale but I can't find any sign of that in the
properties panel.
I was searching for hints in the Geometry related properties but those appear
to be just fine to me:
---------------
UnstructuredGrid (000001E9B900D710)
TimeGeometry: ProportionalTimeGeometry (000001E9B9D7EE00)
TimeSteps: 1
FirstTimePoint: 0
StepDuration: 1 ms
Time Bounds: 0 - 1
GetGeometryForTimeStep(0): Geometry3D (000001E995581FA0)
IndexToWorldTransform:
Matrix:
1 0 0
0 1 0
0 0 1
Offset: [0, 0, 0]
Center: [0, 0, 0]
Translation: [0, 0, 0]
Inverse:
1 0 0
0 1 0
0 0 1
Scale : 1 1 1
BoundingBox: ( 2.69612,12.1395 9.37272,15.2237 6.24618,12.6495
)
Origin: [0, 0, 0]
ImageGeometry: 0
Spacing: [1, 1, 1]
-----------------
This is bothering me because at some point I use an external tool for my plugin
and import the mesh/grid files into my application and I do want to focus them
after importing them. While the positioning works just fine (I just set the
Origin of the associated Geometry) there is still this issue.
The 2D views also behave rather weird, not showing objects with behaviour 2.)
at all.
Just using Global Reinit and setting the camera manually would be an
alternative for me, but I haven't figured out how to actually change the camera.
Thank you in advance!
Kind regards,
Bertram
From: Bertram Sabrowsky-Hirsch
[mailto:[email protected]]
Sent: 15 March 2018 09:21
To: Dinkelacker, Stefan
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: Re: [mitk-users] Volume Rendering Plugin initialization very slow in
Debug configuration
Hi,
As Stefan suggested I tried to change the compiler settings for building MITK
and was able to greatly reduce the initialization lag time of the Volume
Rendering Plugin in my debug configuration.
With the new debug build, the lag time dropped from over 90 seconds to less
than 6 seconds what makes debugging so much more usable for me. Not only that,
the overall performance is way better than before.
For those of you working with Visual Studio and experiencing the same lags try
setting:
CMAKE_CXX_FLAGS_DEBUG
to
"/MDd /Zi /Ob2 /Zo" (should be "/MDd /Zi /Ob0 /Od /RTC1" by default)
in your MITK cmake configuration.
I don't know too much about those compiler flags, I more or less stumbled over
them on the web. I figure that it might have some downsides for debugging MITK
related modules as the build now contains optimized code, but I really don't
care too much about that as long as I can debug my own code (I left the CXX
flags for my project unchanged).
So what I changed was:
/Ob0 to /Ob2: enable expand functions and auto in-lining.
Set /Zo: enhance optimized debugging
Unset /Od: disables optimization, speeding compilation and simplifying debugging
Unset /RTC1: enables runtime error checks
In case someone has more in-depth knowledge about choosing compiler flags for
debug configurations, please let me know your suggestions.
Thank you!
Kind regards,
Bertram
From: Dinkelacker, Stefan [mailto:[email protected]]
Sent: 14 March 2018 16:25
To: Bertram Sabrowsky-Hirsch
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: RE: [mitk-users] Volume Rendering Plugin initialization very slow in
Debug configuration
Hi,
I just can point you to my last email. It's like I predicted: the random memory
access (iterators) take magnitudes of order more time in debug mode because of
all the checks that are made in each and every memory access. There might be a
setting somewhere to disable or minimize those checks, but I didn't look into
that any further.
Best,
Stefan
From: Bertram Sabrowsky-Hirsch
[mailto:[email protected]]
Sent: Mittwoch, 14. März 2018 13:00
To: Dinkelacker, Stefan;
[email protected]<mailto:[email protected]>
Subject: RE: [mitk-users] Volume Rendering Plugin initialization very slow in
Debug configuration
Hi Stefan,
That's right I'm working with Windows and Visual Studio 2017. Thanks for the
advice, I tried that yesterday but eventually gave up on using the Profiling
Tools as I had multiple issues with it. Instead I used the Visual Studio
Debugger to step and identify the parts of the code that slow down the app.
There seem to be two major bottlenecks after enabling Volume Rendering for a
selected Image:
1. (54 seconds)
In QmitkTransferFunctionGeneratorWidget::SetDataNode there is a call to
ImageStatistcsHolder::GetScalarValueMin(). The time is spent in
mitk::_ComputeExtremaInItkImage when the
itk::ImageRegionConstIterator<ItkImageType> iterates over each pixel.
2. (6 seconds)
In vtkVolumeTexture::LoadTexture the call to
vtkVolumeTexture::SelectTextureFormat. The time is spent in the calls to
vtkDataArray::GetFiniteRange.
3. (22 seconds)
In vtkVolumeTexture::LoadTexture when tupPtr is filled in a 3D loop.
I can't figure out why those operations are so slow in debug mode when they
perform well in release mode. Do you have any suggestions?
Thank you very much in advance.
Kind regards,
Bertram
From: Dinkelacker, Stefan [mailto:[email protected]]
Sent: 12 March 2018 12:37
To: Bertram Sabrowsky-Hirsch
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
Subject: AW: [mitk-users] Volume Rendering Plugin initialization very slow in
Debug configuration
Hi,
I guess you are working on Windows to have such big differences between Debug
and Release configurations? With Visual Studio 2017 you can use the profiling
tools to easily get an idea of where the time is spent. Such huge differences
between debug and release configurations usually means that there is a lot of
random memory access going which is encapsualated in debug configuration by
expensive checks. There might be a compiler setting to disable these checks and
gain some speed.
Best,
Stefan
________________________________
Von: Bertram Sabrowsky-Hirsch
<[email protected]<mailto:[email protected]>>
Gesendet: Montag, 12. März 2018 12:00
An: [email protected]<mailto:[email protected]>
Betreff: [mitk-users] Volume Rendering Plugin initialization very slow in Debug
configuration
Hi,
I am working on an Aneurysm Simulation Plugin relying on the Volume Rendering
Plugin for 3D Rendering of some steps. For that I just set the volume rendering
property of my Image data node.
It is working both in the Release and the Debug Configuration, however the
Debug configuration has an awful initialization lag/freeze (I suppose from the
Mapper Initialization) of more than 90 seconds after I set the flag. Its
independent of the size of the Image data and will only occur the first time in
one execution run, subsequently setting the property for different nodes runs
smoothly. In the release configuration there is a lag but that lasts only for
less than 2 seconds. I'm working with MITK 2016.11.99-974bf5ad.
Does anyone experience the same issue? I thought about using RelWithDebInfo but
failed to build MITK for that configuration. The lag is quite frustrating and I
now tend to avoid using the Debug configuration. Any advice would be much
appreciated.
Thank you very much in advance.
Kind regards,
Bertram
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mitk-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mitk-users
