iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2021-08-20T10:59:26-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/354CD/CH Example issues2021-08-20T10:59:26-04:00Harald ScheirichCD/CH Example issues- [x] ConvertVTKToVega crashes
- [x] PBDInjection the Haptic device doesn't move the controller (this might be user error)
- [x] SPH examples run out of memory in the middle, this looks major- [x] ConvertVTKToVega crashes
- [x] PBDInjection the Haptic device doesn't move the controller (this might be user error)
- [x] SPH examples run out of memory in the middle, this looks majorAndrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/353CDHRefactor Backlog2022-06-02T01:27:13-04:00Andrew WilsonCDHRefactor Backlog- [x] OctreeIntersection OctreeDebugObject Bug
- [x] Fix warnings introduced in MR
- [x] Sign Issues in SphereToCylinderCD (need to make a manual example to check the contacts)
- [ ] GeometryDebugObject as a VisualModel instead of a Scen...- [x] OctreeIntersection OctreeDebugObject Bug
- [x] Fix warnings introduced in MR
- [x] Sign Issues in SphereToCylinderCD (need to make a manual example to check the contacts)
- [ ] GeometryDebugObject as a VisualModel instead of a SceneObject
- [x] CDElementVector was more or less untouched from previous imstk. Some of it's functions need some locks. Also we've experienced a few instances were the locks didn't appear to work when adding data in parallel. (I would do more investigation in the future)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/352Remaining Rendering Visual Test2022-04-20T09:39:36-04:00Aaron Brayaaron.bray@kitware.comRemaining Rendering Visual TestAdd methods/classes to create the following geometries to the RenderingVisualTest unit test
- [ ] Fluid Geometry
- [ ] Hexahedral
- [ ] Image Data
- [ ] Line Mesh
- [ ] Point Set
- [ ] Poly Data
- [ ] Surface Normal
- [ ] Volume Geometr...Add methods/classes to create the following geometries to the RenderingVisualTest unit test
- [ ] Fluid Geometry
- [ ] Hexahedral
- [ ] Image Data
- [ ] Line Mesh
- [ ] Point Set
- [ ] Poly Data
- [ ] Surface Normal
- [ ] Volume Geometry
- [ ] Tetrahedral Mesh
The goal is to test all geometries found here
https://imstk.gitlab.io/a02838.html
as well as Gemometry Algorithms found here
https://imstk.gitlab.io/a02730.htmlhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/351PBDFluids Doesn't use XPBD2022-08-05T10:42:41-04:00Andrew WilsonPBDFluids Doesn't use XPBDPBDFluids constraint is basically a global constraint for efficiency it reimplements the base class API for computeValueAndGradient and projectConstraint and was never upgraded to use XPBD.PBDFluids constraint is basically a global constraint for efficiency it reimplements the base class API for computeValueAndGradient and projectConstraint and was never upgraded to use XPBD.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/350PolyMesh/CellMesh2022-07-20T17:43:58-04:00Andrew WilsonPolyMesh/CellMeshAn abstract base class for SurfaceMesh, LineMesh, TetrahedralMesh, and HexahedralMesh would be nice. Something we've discussed for awhile. Something to provide cells abstractly.
One simple use case is the abstract class "getCellWeights"...An abstract base class for SurfaceMesh, LineMesh, TetrahedralMesh, and HexahedralMesh would be nice. Something we've discussed for awhile. Something to provide cells abstractly.
One simple use case is the abstract class "getCellWeights". Whose signature would look like: getCellWeights(int cellId, const Vec3d& ptInCell);
Which would barycentric interpolate for a cell (triangle, tet, line, hexahedron, ...). Someone can then easily write a template function that works for any cell.
Also consider renaming indices to cells. getCells()
Functions for the base class:
```
getCellWeights(int cellId, const Vec3d& ptInCell): Computes interpolation weights (usually barycentric)
getCellBounds(int cellId, Vec3d& min, Vec3d& max): Computes bounding box of a single cell
getCellVolume(int cellId): Computes the signed volume of a cell
getCell(): Gets single cells indices
getIndices(): Gets the cell indices
setIndices(std::shared_ptr<AbstractDataArray> indices): Set the cell indices, could also require int type here
```Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/349Remove imstkDecal from Geometry2021-07-31T22:31:40-04:00Andrew WilsonRemove imstkDecal from GeometryWe removed it from Rendering awhile back with Vulkan but missed the one in geometry.We removed it from Rendering awhile back with Vulkan but missed the one in geometry.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/348TetrahedralMesh::computeBaryCentricCoordinates Doesn't Handle Coplanar Case2021-07-27T23:51:29-04:00Andrew WilsonTetrahedralMesh::computeBaryCentricCoordinates Doesn't Handle Coplanar CaseWhile this is a valid configuration during simulation it produces 0 volumes when divided produce nan weights. It should instead produce 0 weight for the "inside" vertex and area weights for the other 3. Would be great task for a unit test.While this is a valid configuration during simulation it produces 0 volumes when divided produce nan weights. It should instead produce 0 weight for the "inside" vertex and area weights for the other 3. Would be great task for a unit test.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/347Remaining Collision Detection Unit Tests2022-06-02T19:38:53-04:00Andrew WilsonRemaining Collision Detection Unit TestsThe following CD methods could use unit tests:
- [x] BidirectionalPlaneToSphereCD
- [ ] ImplicitGeometryToPointSetCCD
- [ ] ImplicitGeometryToPointSetCD
- [x] MeshToMeshBruteForceCD (Manual tests exist in examples BoxBoxTest)
- [x] Point...The following CD methods could use unit tests:
- [x] BidirectionalPlaneToSphereCD
- [ ] ImplicitGeometryToPointSetCCD
- [ ] ImplicitGeometryToPointSetCD
- [x] MeshToMeshBruteForceCD (Manual tests exist in examples BoxBoxTest)
- [x] PointSetToCapsuleCD
- [x] PointSetToPlaneCD
- [x] SphereToCylinderCD
- [x] SurfaceMeshToSphereCD (Manual tests exist in examples TriangleVsSphereTest)
- [ ] SurfaceMeshToSurfaceMeshCD (Manual test exists in examples TriangleVsTriangleTest)
- [x] TetraToLineMeshCD
- [x] TetraToPointSetCD
- [x] UnidirectionalPlaneToSphereCD
One can use/copy the structure of the existing CD unit tests to implement.
Use the following branch: https://gitlab.kitware.com/andrew.wilson/iMSTK/-/tree/CDHRefactorhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/346Analytical gradient of SDF2021-07-27T13:41:03-04:00Jianfeng YanAnalytical gradient of SDFCurrently we use finite difference to compute the gradient of signed distance field. Alternatively, it can be computed directly based on the coordinates, by taking the gradient of the basis functions. The benefits include
- subject to n...Currently we use finite difference to compute the gradient of signed distance field. Alternatively, it can be computed directly based on the coordinates, by taking the gradient of the basis functions. The benefits include
- subject to no round-off errors
- efficiency. The gradient is just an explicit linear function of the coordinates.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/345Odd crashes when using `CalculateDistanceField` together with `CleanPolyData`2022-04-20T09:50:58-04:00Harald ScheirichOdd crashes when using `CalculateDistanceField` together with `CleanPolyData`I've seen crashes when applying CleanPolyData to a mesh created by calculate distance field, when there are triangles parallel to the main coordinate planes (e.g. xy) that cut off by the boundary of the Distancefield calculationI've seen crashes when applying CleanPolyData to a mesh created by calculate distance field, when there are triangles parallel to the main coordinate planes (e.g. xy) that cut off by the boundary of the Distancefield calculationhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/344Ability to Add Custom RenderDelegates2022-03-08T14:29:20-05:00Andrew WilsonAbility to Add Custom RenderDelegatesUsers should be able to write their own RenderDelegate's and add them to the renderer. Generally users shouldn't have to use this. But if they need some niche rendering capabilities this is how they would do it.Users should be able to write their own RenderDelegate's and add them to the renderer. Generally users shouldn't have to use this. But if they need some niche rendering capabilities this is how they would do it.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/343Inverse SDF Collision Detection2021-07-26T11:52:50-04:00Andrew WilsonInverse SDF Collision DetectionWhilst we have static SDF collision detection rigid SDF collision detection is also relatively easy. Supply the CD with a rigid transform and we can inverse transform back into the SDF for CD. This should be as simple as applying the cur...Whilst we have static SDF collision detection rigid SDF collision detection is also relatively easy. Supply the CD with a rigid transform and we can inverse transform back into the SDF for CD. This should be as simple as applying the currently set geometries transform inverse to every point before sampling in the SDF for ImplicitGeometryToPointSetCD.
We can also do it for tetrahedral meshes by inversing the deformation of the tetrahedron.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/342Voronoi Based Static Collision Detection2021-07-25T22:22:58-04:00Andrew WilsonVoronoi Based Static Collision DetectionVoronoi's can be computed for static geometry, inversely mapped for rigid, or inverse transformed via tetrahedron deformation.
These can quickly give closest features during collision detection.Voronoi's can be computed for static geometry, inversely mapped for rigid, or inverse transformed via tetrahedron deformation.
These can quickly give closest features during collision detection.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/341Add Primitive Static Collision Detections2022-09-29T13:09:44-04:00Andrew WilsonAdd Primitive Static Collision Detections - Some of the less useful ones are not listed.
- This only details primitive (cylinder, capsule, sphere, oriented box, plane) collisions.
SurfaceMesh (most useful and difficult):
- [x] SurfaceMeshToSphereCD
- [x] SurfaceMeshToCapsuleC... - Some of the less useful ones are not listed.
- This only details primitive (cylinder, capsule, sphere, oriented box, plane) collisions.
SurfaceMesh (most useful and difficult):
- [x] SurfaceMeshToSphereCD
- [x] SurfaceMeshToCapsuleCD
- Easiest of the surface mesh ones.
- [ ] SurfaceMeshToCylinderCD (involves both curved surface and sharp edges)
- [ ] SurfaceMeshToOrientedBoxCD
LineMesh:
- [x] LineMeshToSphereCD (easy) (do this before capsule)
- [x] LineMeshToCapsuleCD (easy) (useful)
- [ ] LineMeshToCylinderCD
- [ ] LineMeshToOrientedBoxCD
PointSet:
- [x] PointSetToCapsuleCD
- [x] PointSetToOrientedBoxCD
- [x] PointSetToPlaneCD
- [x] PointSetToSphereCD
- [x] PointSetToCylinderCD
- [x] ImplicitGeometryToPointSetCD
- [x] ImplicitGeometryToPointSetCCD
Primitive v Primitive (these tend to be less common in medical scenarios):
- [x] SphereToSphereCD
- [x] SphereToCylinderCD
- [x] BidirectionalPlaneToSphereCD
- [x] UnidirectionalPlaneToSphereCD
- [x] CapsuleToCapsuleCD
- [x] CapsuleToSphereCD (easy, closest point on capsule edge to sphere center)
- [x] CapsuleToPlaneCD (easy, closest point on capsule edge to plane)
- [ ] CylinderToPlaneCD
- [ ] CylinderToOrientedBoxCD
- [ ] CylinderToCylinderCD
... Other Permutations ...
... BidirectionalPlane Permutations ...
These can be added via unit tests (see existing CD unit tests). You don't need to implement them in some fancy simulation or verify against models, just check the CollisionData output. An accompanying example or interactive visual test for those complex ones might be useful. CollisionDataDebugObject may be used to draw contact, see BoxToBoxTest in Examples/CollisionDetection.
Do not add any spatial acceleration. That will be patterned out later for all CDs.
See CollisionUtils.h for a place to put all your collision/intersection functions. There are a number of existing basic ones provided: closest point on two lines. Closest point on triangle.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/340Sphere getDistanceFunction returns the incorrect value after constructor2022-08-05T10:37:22-04:00Harald ScheirichSphere getDistanceFunction returns the incorrect value after constructorWhen constructing a sphere with a radius, unless postTransformUpdate is called the distance function returns an incorrect value. After getRadius is called (e.g. from graphics) the distance function is correct
We need to talk about what ...When constructing a sphere with a radius, unless postTransformUpdate is called the distance function returns an incorrect value. After getRadius is called (e.g. from graphics) the distance function is correct
We need to talk about what the invariants for all the shapes are when `postTransfromUpdate` needs to be called and when not ... and fully test the analytical geometryJacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/339Add a light controller2021-11-23T17:05:01-05:00Sreekanth ArikatlaAdd a light controllerAdd a light controller similar to the scene object controller where the user can attach a device tracker to the light to update its poseAdd a light controller similar to the scene object controller where the user can attach a device tracker to the light to update its posehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/338Unit tests don't correctly print error messages on failure2021-07-28T12:21:12-04:00Harald ScheirichUnit tests don't correctly print error messages on failureThe logger is not initialized, we need to write our own test main to correctly initialize the loggerThe logger is not initialized, we need to write our own test main to correctly initialize the loggerHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/337Lights Properties Can't Change2021-08-19T11:25:37-04:00Andrew WilsonLights Properties Can't ChangevtkLights aren't fully exposed in iMSTK yet. The properties of the lights ara set during construction but can't change during runtime. If we change an imstkLight's properties the corresponding vtkLight does not change. These properties d...vtkLights aren't fully exposed in iMSTK yet. The properties of the lights ara set during construction but can't change during runtime. If we change an imstkLight's properties the corresponding vtkLight does not change. These properties depends on the light type, but to give an idea these includes:
- Position (perhaps a light is moving with a tool)
- Orientation
- Angles
- Intensities
- On/Off
Typically there are few lights. Most often just 1.
Looping through all of the scene's lights and updating the corresponding vtkLight every render is fine. Lights are generally few in medical scenarios and their data members are small.
See updateRenderDelegates call: https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/Rendering/VTKRenderer/imstkVTKRenderer.cpp#L424https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/336iMSTKConfig Should be Appending CMAKE_MODULE_PATH2021-07-03T18:32:18-04:00Andrew WilsoniMSTKConfig Should be Appending CMAKE_MODULE_PATHDon't have time to test right now but leaving this here for later.
I'm pretty sure the iMSTKConfig.cmake file should be appending or only temporarily setting the CMAKE_MODULE_PATH, not overwriting it. It causes problems when users set i...Don't have time to test right now but leaving this here for later.
I'm pretty sure the iMSTKConfig.cmake file should be appending or only temporarily setting the CMAKE_MODULE_PATH, not overwriting it. It causes problems when users set it in their external project. This variable is a cmake one used as a search path by cmake "include". By setting it in the config it overwrites the user's CMAKE_MODULE_PATH when find_package(iMSTK) is called. Whatever the user then had is erased and all their include's break.
(The reason the iMSTKConfig.cmake sets the module path to begin with is because certain cmake includes are used in iMSTK's cmake code)
The solution would be:
Appending: https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/CMake/iMSTKConfig.cmake.in#L19 should be list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/modules").
Temporarily Set: Save the current CMAKE_MODULE_PATH, set it for iMSTKConfig.cmake, then at the end, set it back to the one before config ran.
I'm thinking it should be temp set. The difference is whether iMSTK's cmake code should be on the user's module path, accessible by the external project or not. Names could conflict in user cmake files vs iMSTK's (or even finds). It would make more sense to just provide iMSTK's cmake code via another variable that the user could then optionally include on their cmake path.
Example of failure in external project (of course one could reorder these calls as a temp fix):
```
list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake)
find_package(iMSTK REQUIRED)
include(ClangFormat) # Can't be found!
...
```https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/335Light not found warning thrown in every example that adds a light2021-06-28T09:32:43-04:00Andrew WilsonLight not found warning thrown in every example that adds a lightIssues because of https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/615
This is because getLight throws it when it can't find a light, yet many spots in code use it to check if a light is present.
For instance, addLight uses getL...Issues because of https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/615
This is because getLight throws it when it can't find a light, yet many spots in code use it to check if a light is present.
For instance, addLight uses getLight to check if light is present, if not, adds it. So every example that adds a light will throw it because obviously a light will not be present initially.
Suggestion: Remove check and throw warning in getLight if we intend to use it to check ourselves. Or just use a vector without names for lights. Add the names later when they're actually needed.Harald ScheirichHarald Scheirich