Add VTK rendering improvements
ENH: Use vtkTriangleMeshPointNormals
The main bottleneck with real-time VTK rendering so far
appeared to be the normals computation. This commit addresses
that issue by making use of the latest normals computation
filter in VTK: vtkTriangleMeshPointNormals.
While this filter is much (5 to 16 times) faster than
vtkPolyDataNormals, it does not check for consistency in the
cell orientations that could cause inverted normals, which
is why the vtkPolyDataNormals is called once in the surfacemesh
renderdelegate to retrieve consistent cells for the input mesh.
See VTK merge request for more information : vtk/vtk!2271 (merged)
PS: That MR requires the latest commits from VTK master, which does not include work made on texture wrap mode nor on multi texture attributes yet:
BUG: fix VTK rendering when framerate not fixed
When the framerate was not fixed, the next render pass
would be called using CreateOneShotTimer(0) while its
parameter minimum value is 1 (in milliseconds). 0 would
set it up for the default value of 10 ms.
ENH: Display framerate in window
Press the P key (for "Print text", since f should be for
fullscreen) to display the rendering framerate in the left
bottom corner.
Needed to override SetCurrentRenderer to add the textActor.
Only update the displayed framerate value every second, which
requires the variables m_lastFpsUpdate (last time since the
value was updated), and m_nbrOfFrames (number of frames that
were rendered since the last update).
ENH: Allow debug rendering while simulation runs
Addresses suggestions made here: a63f98b5 (comment 212643)
It would be great to have the option of using pan-zoom-rotate when simulation is running for certain applications. I keep pressing 'S' and 'E' in succession to see if everything is good for an example i was working on. It need not be a default run mode option. - @sreekanth-arikatla
- Rename VTKRenderer::setup into VTKRenderer::setMode
- Add VTKRenderer::getMode
- Add VTKViewer::getRenderingMode wrapping the one above
- Consider Rendering Mode in Mouse event callbacks instead of simulation status
- Allow to switch to Debug rendering and back with the
dkey
ENH: Triangulate polydata in VTK reader
Ensure the surface mesh read will only have triangles and no triangle strips or other cells. Fixes #115 (closed).
Merge request reports
Activity
@MohitTyagi @hina @NickMilef would appreciate your reviews! I'd advise looking at it commit by commit for clarity.
55 87 // Reset camera clipping range 56 88 this->CurrentRenderer->ResetCameraClippingRange(); 57 89 58 // Retrieve actual framerate 59 auto t = std::chrono::duration_cast<std::chrono::milliseconds>(std::chrono::high_resolution_clock::now()-m_pre).count(); 60 auto fps = 1000.0/(double)t; 61 auto fpsStr = std::to_string((int)fps)+ " fps"; 90 // Update framerate value display Sorry, misread the code for the now deleted comment. Should we use a moving average instead? It's pretty easy to implement, and it's a common practice. The problem with a second average is that it's kind of coarse, so if an interaction takes place for a small amount of time and causes the frame to take 2-3 times as long this could be a problem but wouldn't be obvious with a second-level framerate counter. I'm mostly concerned about VR because you have maximum frame times (so an average of 90 FPS is not the same as each frame taking a maximum of 11 ms), otherwise this could cause nausea, but this is also important for non-VR as well to prevent inconsistent graphics jumps.
Edited by Nicholas Milef-
Sorry, misread the code for the now deleted comment.
Ah, did you delete the comment or can you not find it anymore? If you didn't delete it, it could have been deleted if it was made on a previous version of a commit, I added a couple things so the commit isn't the same after interactive rebase.
Should we use a moving average instead? It's pretty easy to implement, and it's a common practice.
Sounds good to me! I'm moving around this weekend, could you offer an implementation ? Could be in the comments.
I actually deleted it because I read the code incorrectly the first time.
Sure! Here's an implementation. Wikipedia also good article on this (and StackExchange has several posts on this too).
weight = 0.2; // arbitrary, we may need to try out different values fps = currentFrameFPS * weight + lastFPS * (1.0 - weight); lastFPS = fps; if (t > 100) // we can reduce the time so it updates sooner { display, etc. }-
In this stackoverflow comment, he seems to say that the fps calculation you make should be within our
ifcondition (since he only updates it every second in this case): http://stackoverflow.com/a/4687507Should we keep the fps calculation done for each frame like you did, or do it every second like he suggests?
Edited by Alexis Girault -
@NickMilef thanks for all the comments, let me know if this looks good now. I hardcoded the
alphafor now. I figure we can make this and the delay for display customizable in the future if there is a need for it.
mentioned in issue #115 (closed)
-
@buildbot test
added 11 commits
-
6cb4c574...39cddd34 - 4 commits from branch
iMSTK:master - 969659fd - ENH: Use vtkTriangleMeshPointNormals
- 70d57b87 - BUG: fix VTK rendering when framerate not fixed
- 2094e396 - ENH: Display framerate in window
- f1a8342d - ENH: Allow debug rendering while simulation runs
- 40a00b93 - COMP: Correct some size_t related warnings
- f5715893 - ENH: default DATA_ROOT_PATH and alert if not set
- a8959a29 - ENH: Triangulate polydata in VTK reader
Toggle commit list-
6cb4c574...39cddd34 - 4 commits from branch
mentioned in commit 93e84fe1
mentioned in commit 3af00a31
mentioned in merge request !160 (merged)
