iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2017-10-20T12:01:17-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/153Add audio support2017-10-20T12:01:17-04:00Sreekanth ArikatlaAdd audio supportNeeded for bone drilling simulation
Some options:
- http://www.openal-soft.org/ (LGPL)
- http://audiere.sourceforge.net/home.php (LGPL)
- https://www.sfml-dev.org/index.php (zlib license)
- http://www.portaudio.com/ (GNU)
- https:...Needed for bone drilling simulation
Some options:
- http://www.openal-soft.org/ (LGPL)
- http://audiere.sourceforge.net/home.php (LGPL)
- https://www.sfml-dev.org/index.php (zlib license)
- http://www.portaudio.com/ (GNU)
- https://github.com/google/pindrop (Apache License v2.0)
- https://www.libsdl.org/ (zlib license) [*Nick: we can possibly separate out the audio from SDL. I think VTK uses SDL for VR, but AFAIK it uses GLUT for non-VR*]https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/152Add nearest neighbor search for a point set2019-07-04T16:21:46-04:00Sreekanth ArikatlaAdd nearest neighbor search for a point set**Where is it needed?**
particle-based fluid simulations
**Status-quo**
Brute force neighbor search is used
**References**:
1. https://drive.google.com/file/d/0B27NWVZbNDyGa214ejRZejhjcDA/view
2. Thesis: http://www.mit.edu/~andoni/thes...**Where is it needed?**
particle-based fluid simulations
**Status-quo**
Brute force neighbor search is used
**References**:
1. https://drive.google.com/file/d/0B27NWVZbNDyGa214ejRZejhjcDA/view
2. Thesis: http://www.mit.edu/~andoni/thesis/main.pdf
3. Using k-d trees: http://www.alglib.net/other/nearestneighbors.phphttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/151Create utilities for mesh sanity checks2019-07-28T16:20:25-04:00Sreekanth ArikatlaCreate utilities for mesh sanity checksMesh related checks such as cell ordering consistency and watertightness etc. should be done
within the utility functions of Mesh or Rendering module. For now the user
is expected to supply correct meshes.Mesh related checks such as cell ordering consistency and watertightness etc. should be done
within the utility functions of Mesh or Rendering module. For now the user
is expected to supply correct meshes.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/150Checking for cell consistency takes time2017-07-03T11:48:44-04:00Sreekanth ArikatlaChecking for cell consistency takes timeChecking for cell consistency takes time. Can the check be done optionally while creating the `VTKSurfaceMeshRenderDelegate`?
Some numbers: For a mesh with 364820 cells, its ~23 vs ~2.5 sec in releaseChecking for cell consistency takes time. Can the check be done optionally while creating the `VTKSurfaceMeshRenderDelegate`?
Some numbers: For a mesh with 364820 cells, its ~23 vs ~2.5 sec in releasehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/149Add option to silence verbose2019-07-28T16:19:29-04:00Sreekanth ArikatlaAdd option to silence verboseThe output stream is now cluttered with output from various classes. An option to silence them will be usefulThe output stream is now cluttered with output from various classes. An option to silence them will be usefulhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/148Motion blur2019-07-28T15:58:26-04:00Nicholas MilefMotion blur# Overview
Motion blur is a very helpful form of visual feedback to show an object moving at very fast speeds. The current way it's implemented is through VTK is by using accumulating multiple renders. Instead, we need to use a velocity...# Overview
Motion blur is a very helpful form of visual feedback to show an object moving at very fast speeds. The current way it's implemented is through VTK is by using accumulating multiple renders. Instead, we need to use a velocity buffer.
Example on the difference between the two techniques:
http://john-chapman-graphics.blogspot.com/2013/01/what-is-motion-blur-motion-pictures-are.html
Here's an example of an advanced implementation (also compared different approaches):
http://www.iryoku.com/next-generation-post-processing-in-call-of-duty-advanced-warfare
Note that the second set of renders show the teapot having realistic motion blur compared to the first render (what VTK currently uses). One problem with VTK's approach particularly for our use case is the wagon-wheel effect (https://en.wikipedia.org/wiki/Wagon-wheel_effect).
According to the VTK documentation, the motion blur is also expensive to compute (requires rendering the scene multiple times, unless I'm reading this incorrectly):
http://www.vtk.org/doc/nightly/html/classvtkRenderWindow.html#a816914890cd363a6ebdbb1d024f89198
# Requirements
One of the requirements is that we have velocity (derivative) transformation matrices for each mesh that gets passed to the shaders. It would be great if this is added to the geometry or mesh class.
# Implementation
* Compute velocity matrix
* Vertex shader: transform velocity into screen-space
* Fragment shader: write velocity to render-target (HW rasterizer will interpolate velocity)
* Post process fragment shader: do a Gaussian blur according to the velocity vector
@sreekanth-arikatlaNicholas MilefNicholas Milefhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/147Make start, pause, debug-mode keys obvious to the user2017-08-30T14:27:02-04:00Sreekanth ArikatlaMake start, pause, debug-mode keys obvious to the userMultiple new users have had the question of how to start the simulation. It doesn't seem obvious for a new user at this time. One option is to print those instruction at after initializing the scene and before launching the render windowMultiple new users have had the question of how to start the simulation. It doesn't seem obvious for a new user at this time. One option is to print those instruction at after initializing the scene and before launching the render windowhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/146Efficient rigid offset transformation for deformable meshes2021-06-01T14:55:42-04:00Sreekanth ArikatlaEfficient rigid offset transformation for deformable meshesFrom @unihui,
When we set each position for deformable object, this function will be called, m_transformApplied would be set to false, then updatePostTransformData will be called for one time for each getVertexPosion, which leads to much...From @unihui,
When we set each position for deformable object, this function will be called, m_transformApplied would be set to false, then updatePostTransformData will be called for one time for each getVertexPosion, which leads to much unnecessary calculation and reduces the performance.
I think it is very powerful with this transformation matrix, but there might be no need for deformable object, just for rigid body.
I can solve it in my branch, but it would make no sense to iMSTK platform, so could you help me to check and fix this issue?
void
```
Mesh::setVertexPosition(const size_t& vertNum, const Vec3d& pos)
{
m_vertexPositions.at(vertNum) = pos;
m_dataModified = true;
m_transformApplied = false;
}
```https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/145Add ability to add custom force filter2019-07-28T15:58:22-04:00Sreekanth ArikatlaAdd ability to add custom force filterAdd ability to add custom force filter like moving average filter for smooth force renderingAdd ability to add custom force filter like moving average filter for smooth force renderinghttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/144Add api for line to mesh CCD2019-07-28T15:58:19-04:00Sreekanth ArikatlaAdd api for line to mesh CCDat present the CCD api supports only mesh-mesh collisionsat present the CCD api supports only mesh-mesh collisionshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/143Support point set for fluids2017-08-01T23:43:27-04:00Sreekanth ArikatlaSupport point set for fluidsAbility to load and used a collection of points using the imstkMesh related mechanisms without the need to provide connectivityAbility to load and used a collection of points using the imstkMesh related mechanisms without the need to provide connectivityhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/142Add proper way to incorporate flat shading2018-11-12T11:49:05-05:00Sreekanth ArikatlaAdd proper way to incorporate flat shadingHi Sreekanth,
I didn't add it for multiple reasons:
This is purely an artistic effect
The implementation of this in the fragment shader is poorly defined (due to the GLSL functions used)
It is expensive to do on the GPU with normal mapp...Hi Sreekanth,
I didn't add it for multiple reasons:
This is purely an artistic effect
The implementation of this in the fragment shader is poorly defined (due to the GLSL functions used)
It is expensive to do on the GPU with normal mapping
If you want to do it by code, do this instead:
Generate 3 vertices per triangle
Do not share vertices
Then, you'll get flat shading this way. I don't think it should even be an option to turn on. The problem is that you're going to get users who just turn in on for an OR room or something, and this will heavily affect the fillrate. Here's another thing to keep in mind as well, what if you want half flat shading and half smooth shading? There's no common way to do this except by generating the art correctly:
https://blender.stackexchange.com/questions/23596/smooth-shaded-model-has-odd-shading
You will also be able to use normal maps in the future to correct for harsh edges if you want to.
--------
Hi Nick,
Got it! But for now we will add it as an option and turned off by default. We need to do this because Andinet wants the standalone demo application code to work directly on master (not on any branch). I'll create an issue with the explanation you provided. Thanks.Nicholas MilefNicholas Milefhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/141Moving normal/tangents calculations out of the render thread2022-09-09T16:23:03-04:00Nicholas MilefMoving normal/tangents calculations out of the render threadI discussed this a little with Alexis on Tuesday, but I've been encountering performance issues with normal recalculation. Right now, when a deformable mesh gets rendered, it must meet recalculate the normals (and soon, the tangents as w...I discussed this a little with Alexis on Tuesday, but I've been encountering performance issues with normal recalculation. Right now, when a deformable mesh gets rendered, it must meet recalculate the normals (and soon, the tangents as well) as part of the render loop. IMO, this shouldn't happen in the render loop since the render loop should only be issuing draw commands and doing culling related things.
I was thinking that it might not be bad to move that command to the physics module since recalculation could be done under a certain threshold. Or, we could move it to another module that solely does mesh preparation. What do you all think?
@sreekanth-arikatla @MohitTyagi @alexis-giraulthttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/140`addModule()` can cause crash when scene name is the same as a module name2021-01-08T17:23:47-05:00Nicholas Milef`addModule()` can cause crash when scene name is the same as a module nameIf you call `addModule` with a module that has the same name as the scene that already is added to the SimulationManager, there's a crash. I think we should just print out an error message detailing the issue (because we can't control wh...If you call `addModule` with a module that has the same name as the scene that already is added to the SimulationManager, there's a crash. I think we should just print out an error message detailing the issue (because we can't control when a scene gets added vs. when a module gets added).Release 2.0.0Nicholas MilefNicholas Milefhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/139VTK VBO update in debug mode is too slow2021-01-08T18:14:48-05:00Nicholas MilefVTK VBO update in debug mode is too slowWhen testing the heart mesh on Girder (about 4k triangles), using just two of them causes the framerate to tank to 32 FPS. With flat shading this is increased to about 45 FPS because of less updates. It seems that the iterator function f...When testing the heart mesh on Girder (about 4k triangles), using just two of them causes the framerate to tank to 32 FPS. With flat shading this is increased to about 45 FPS because of less updates. It seems that the iterator function for the vector class is very slow from profiling. I'll try to do some testing later to figure out what to do. But if anyone encounters others issues related to this, please post down here.
@alexis-giraulthttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/138Create a light controller2019-07-28T15:58:15-04:00Sreekanth ArikatlaCreate a light controllerMost laparoscopic surgery scenarios have light source at the end of the scope. It would be great to have a light controller just like the camera controller.Most laparoscopic surgery scenarios have light source at the end of the scope. It would be great to have a light controller just like the camera controller.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/137Improve/standardize light class2017-07-18T12:24:12-04:00Nicholas MilefImprove/standardize light classThe current light class is missing feature such as setting light intensity. The light types don't have standard names, which could be confusing for new users.The current light class is missing feature such as setting light intensity. The light types don't have standard names, which could be confusing for new users.Nicholas MilefNicholas Milefhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/136BUG: Incorrect winding of the vertices for computeAttachedSurfaceMesh()2017-07-21T16:49:09-04:00Nicholas MilefBUG: Incorrect winding of the vertices for computeAttachedSurfaceMesh()The winding of the vertices for computeAttachedSurfaceMesh() is incorrect. When you enable backface culling, the triangles are built with the wrong direction. This doesn't happen with OBJ files that are loaded.
![BackfaceCulling](/upl...The winding of the vertices for computeAttachedSurfaceMesh() is incorrect. When you enable backface culling, the triangles are built with the wrong direction. This doesn't happen with OBJ files that are loaded.
![BackfaceCulling](/uploads/2ce54598d3824ba3ce4d5b1e88245c3e/BackfaceCulling.PNG)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/135simplify the PBD pipeline in sceneManager2019-07-04T16:23:15-04:00Sreekanth Arikatlasimplify the PBD pipeline in sceneManagerMake sure there is no special treatment of the pbd objects as sceneManager should be object type *agnostic*!Make sure there is no special treatment of the pbd objects as sceneManager should be object type *agnostic*!https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/134Split the sandbox examples into separate files that are arranged into folders...2018-07-10T11:41:34-04:00Sreekanth ArikatlaSplit the sandbox examples into separate files that are arranged into folders by moduleNow all the examples are in the sandbox example, all in one file.Now all the examples are in the sandbox example, all in one file.Nicholas MilefNicholas Milef