iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-08-01T17:09:12-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/433Pbd Boundary Condition Collisions2022-08-01T17:09:12-04:00Jacob MoorePbd Boundary Condition CollisionsThe PBD solver occasionally "explodes" when a rigid body contacts a boundary point of a PBD object. This can come from some possible issues.
1. There is some point in the PBD collision solve where the inverse mass of zero is causing poi...The PBD solver occasionally "explodes" when a rigid body contacts a boundary point of a PBD object. This can come from some possible issues.
1. There is some point in the PBD collision solve where the inverse mass of zero is causing points adjacent to it to fly off into oblivion.
2. There is an issue with the order of operations in which the constraints are solved.
3. ???Jacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/453Boundary Condition Handling Using Constraints2022-08-01T17:08:45-04:00Jacob MooreBoundary Condition Handling Using ConstraintsThe way rigid boundary conditions are handled normally in PBD is to set the inverse mass of a node to zero, making the mass infinite and therefore immoveable. While this works, it has negative side effects on collision, namely the solut...The way rigid boundary conditions are handled normally in PBD is to set the inverse mass of a node to zero, making the mass infinite and therefore immoveable. While this works, it has negative side effects on collision, namely the solution explodes if a user contacts near to or at a boundary point that is fixed. This is because collision constraints are expected to be solved exactly, and a small deformation near a fixed point causes a large deformation far from the fixed point along a constraint axis. This is a feature of the method, not a bug. There is currently a MR for a patch that will allow the solution to stay mostly stable under these conditions by ignoring collision constraints at and near fixed points.
A better long term solution would be to replace the current handling of boundary conditions with (zero inverse mass) with stiff constraints between boundary points and corresponding virtual points. That way the points are allowed to move slightly which *should* alleviate the explosion issue and still allow for contact constraints near a boundary.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/458Text Status Position Not Updated on Scene Pause2022-07-28T17:21:58-04:00Andrew WilsonText Status Position Not Updated on Scene PauseThe status text position is not updated when the scene is paused, it should always update on render. So if a user resizes a window while simulation is paused it will not move.The status text position is not updated when the scene is paused, it should always update on render. So if a user resizes a window while simulation is paused it will not move.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/457CCD On Scene Reset2022-07-28T17:21:31-04:00Andrew WilsonCCD On Scene ResetOn scene reset CCD does not invalidate the previous geometry/clear it/set to nullptr. So if the geometry moves it will see it as a large jump.On scene reset CCD does not invalidate the previous geometry/clear it/set to nullptr. So if the geometry moves it will see it as a large jump.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/451Simplify License in Header2022-07-28T11:11:17-04:00Harald ScheirichSimplify License in HeaderRemove copyright statement from the and add it to separate file, replace all license statements in sources with plain appache licenseRemove copyright statement from the and add it to separate file, replace all license statements in sources with plain appache licenseHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/421SurfaceMeshToCapsuleCD Uncovered Cases2022-07-26T20:03:04-04:00Andrew WilsonSurfaceMeshToCapsuleCD Uncovered CasesTwo cases I know of aren't covered with triangle to capsule. Documenting that issue here.
1. When the capsule is completely inside the triangle. It does *sometimes* generate data, but it's not the correct/expected manifold that would gi...Two cases I know of aren't covered with triangle to capsule. Documenting that issue here.
1. When the capsule is completely inside the triangle. It does *sometimes* generate data, but it's not the correct/expected manifold that would give good behavior.
2. When the triangles edge is in contact along the lengthwise portion of a capsule, a point contact is produced instead of an edge. This one isn't as critical as a point contact here gives ok behaviour.Jacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/446Geometry To Collision Map2022-07-26T11:10:10-04:00Andrew WilsonGeometry To Collision MapNow that geometry inputs for CD is reversible, out of the constructor, you can create CD methods by name with the factory, and a number of more cases added, tested, and fixed. I think it would be a good time to introduce a map for geomet...Now that geometry inputs for CD is reversible, out of the constructor, you can create CD methods by name with the factory, and a number of more cases added, tested, and fixed. I think it would be a good time to introduce a map for geometry to CollisionDetectionAlgorithms applied in PbdObjectCollision such that users need to provide it and get a decent default.
We just need to provide a map of geometry types (ideally not geometry strings) to CD strings. But make sure to provide it as a default parameter such that it can still be replaced since a number of geometries map to multiple CollisionDetection strategies.Jacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/438Array DataStructure Refactoring2022-07-26T10:44:40-04:00Harald ScheirichArray DataStructure RefactoringMeta item for tracking issues with `DataArray` and `VecDataArray`
- [x] Add `at(size_t index)` function to enable better usages from `ptr`
- [x] Evaluate if adding `using `Parent = DataArray<T>` would increase readibility in the class...Meta item for tracking issues with `DataArray` and `VecDataArray`
- [x] Add `at(size_t index)` function to enable better usages from `ptr`
- [x] Evaluate if adding `using `Parent = DataArray<T>` would increase readibility in the class
- [ ] Evaluate if the ability for the array structure to use foreign data is useful, possibly refactor (split into separate class) or remove
- [ ] Currently `reserve` uses `resize` check if that is the correct order maybe introduce a private function that both use
- [x] Add `clone` to start supporting #420
- [ ] Check special operation (Copy, Move, Assignment, etc) protection level with regards to the abstract class see https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/860#note_1221300Harald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/442Screen Text Instructions on Examples2022-07-26T08:42:50-04:00Andrew WilsonScreen Text Instructions on ExamplesI've had at least 2 people now ask me if the program they just started was frozen when in reality the program just started paused and they need to press space to start (often nice for haptics). It could be useful and easy to add some tex...I've had at least 2 people now ask me if the program they just started was frozen when in reality the program just started paused and they need to press space to start (often nice for haptics). It could be useful and easy to add some textual info on screen for some examples to avoid this.Jacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/452Create a base class for common example functionality2022-07-22T08:26:24-04:00Harald ScheirichCreate a base class for common example functionalityThere are some basic functionalities that every example needs to to, it would be good if we can encapsulate them in a class or a set of functions, amongst others
- create viewer
- create sim manager
- create haptics interface etc
- sh...There are some basic functionalities that every example needs to to, it would be good if we can encapsulate them in a class or a set of functions, amongst others
- create viewer
- create sim manager
- create haptics interface etc
- show information text #442
and others
the Simulation Class from `osteotomy` can server as basis for thisJacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/394Pbd Tet Inversion2022-07-20T17:50:52-04:00Andrew WilsonPbd Tet InversionCurrently none of FEM Pbd models work well with tet inversion which happens often at large timesteps for real time simulations. Only pbd volume+distance constraints can deal with it but those suffer other physical inaccuracies.
![Untitl...Currently none of FEM Pbd models work well with tet inversion which happens often at large timesteps for real time simulations. Only pbd volume+distance constraints can deal with it but those suffer other physical inaccuracies.
![Untitled](/uploads/b011e061c88f3e882807818c747edfe4/Untitled.png)
- Neo hookean becomes unstable as it approaches 0 in & inverts.
- StVK is the most stable but tets become stuck after inverted.
We'd either need a modified neo hookean or modified StVk (not shown above).
Fixed: MR #872Jacob MooreJacob Moorehttps://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/441Change PointSet::getCellIndices() function to return share_ptr in place of ra...2022-07-20T17:43:58-04:00Shreeraj JadhavChange PointSet::getCellIndices() function to return share_ptr in place of raw pointerUpdate `PointSet::getCellIndices()` function and in `PointSet` and derived classes to return a shared pointer in place of a raw pointer.
Related to https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/824.
See discussion: https://git...Update `PointSet::getCellIndices()` function and in `PointSet` and derived classes to return a shared pointer in place of a raw pointer.
Related to https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/824.
See discussion: https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/824#note_1203524Shreeraj JadhavShreeraj Jadhavhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/283PBD Constraint Sleeping2022-07-20T13:01:46-04:00Andrew WilsonPBD Constraint SleepingSome method to sleep constraints would be useful for large tissues. Most parts of tissue don't simulate until touched. Even then, only a localized area of constraints are active. This would avoid expensive math done in some constraints.
...Some method to sleep constraints would be useful for large tissues. Most parts of tissue don't simulate until touched. Even then, only a localized area of constraints are active. This would avoid expensive math done in some constraints.
This may still require a loop to test if the constraints are alive.
Additionally some sort of partitioning could aid sleeping and culling work.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/412In imstkPbdCollisionHandling, getEdge() with cell ID causes a crash.2022-07-12T02:17:41-04:00Shreeraj JadhavIn imstkPbdCollisionHandling, getEdge() with cell ID causes a crash.Inside imstkPbdCollisionHandling.cpp, the [`getEdge()`](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L81) function is called when constructing Edge related constraints. The f...Inside imstkPbdCollisionHandling.cpp, the [`getEdge()`](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L81) function is called when constructing Edge related constraints. The function `getEdge()` expects a cell ID if `idCount == 1` and tries to access `side.m_indicesPtr` which is explicitly assigned as nullptr [here](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L417) and [here](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L423).https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/448DeviceControl's as SceneObject2022-07-08T18:14:52-04:00Andrew WilsonDeviceControl's as SceneObjectSimilar to interactions. These should be become SceneObjects which represent function, and later components in an ECS. As of right now it allows intermediate/ordered functions from the controller to be defined in the SceneObject.Similar to interactions. These should be become SceneObjects which represent function, and later components in an ECS. As of right now it allows intermediate/ordered functions from the controller to be defined in the SceneObject.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/450CMake option to build dependency graph (and maybe put it on nightly)2022-07-06T23:37:05-04:00Andrew WilsonCMake option to build dependency graph (and maybe put it on nightly)I find this graph occasionally useful. It is not too difficult to generate automatically with commands. I am documenting that here and suggesting adding it to the nightly CI.
On existing built repo in the build directory run:
```
cmake ...I find this graph occasionally useful. It is not too difficult to generate automatically with commands. I am documenting that here and suggesting adding it to the nightly CI.
On existing built repo in the build directory run:
```
cmake . --graphviz=graph.dot
```
On new build just append the graphviz bit.
Then on machine (ideally linux with graphviz installed, ) run:
```
dot -Tpng -o graph.png graph.dot
```
In the build directory it is useful to have a CMakeGraphVizOptions.cmake file with the following (else its too messy):
```
set(GRAPHVIZ_EXECUTABLES FALSE)
set(GRAPHVIZ_INTERFACE_LIBS FALSE)
set(GRAPHVIZ_MODULE_LIBS FALSE)
set(GRAPHVIZ_OBJECT_LIBS FALSE)
set(GRAPHVIZ_UNKNOWN_LIBS FALSE)
set(GRAPHVIZ_EXTERNAL_LIBS FALSE)
```https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/402Improve 'Overview of iMSTK' section of the documentation2022-07-06T18:20:44-04:00Sreekanth ArikatlaImprove 'Overview of iMSTK' section of the documentationExpand the 'Overview of iMSTK' section of readthedocs documentation to give users a more detailed introduction to key components of imstk. Add a walk through example.Expand the 'Overview of iMSTK' section of readthedocs documentation to give users a more detailed introduction to key components of imstk. Add a walk through example.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/419Real Time timestep/dt is not passed into PbdSolver continuously2022-07-06T13:51:30-04:00Andrew WilsonReal Time timestep/dt is not passed into PbdSolver continuouslyIt is only passed in on initialization, if the timestep is changed, PbdSolver never see's this change.
Given a fixed timestep this is a non issue, (ours is "semi fixed" as its called so it could cause a slight drift in time).
The PbdSo...It is only passed in on initialization, if the timestep is changed, PbdSolver never see's this change.
Given a fixed timestep this is a non issue, (ours is "semi fixed" as its called so it could cause a slight drift in time).
The PbdSolver only uses timestep in the case of XPBD.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/447CI Tasks2022-07-01T13:39:36-04:00Harald ScheirichCI TasksIn Order of importance
- [ ] Enable `IMSTK_WRAP_CSHARP` Windows (Linux optional)
- [ ] Enable Coverage Calc and Posting Linux Only
- [ ] Enable `IMSTK_USE_OpenHaptics` Windows Only
- [ ] Enable `IMSTK_USE_VRPN`In Order of importance
- [ ] Enable `IMSTK_WRAP_CSHARP` Windows (Linux optional)
- [ ] Enable Coverage Calc and Posting Linux Only
- [ ] Enable `IMSTK_USE_OpenHaptics` Windows Only
- [ ] Enable `IMSTK_USE_VRPN`