iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-08-09T11:23:22-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/439Pbd Collision Benchmark2022-08-09T11:23:22-04:00Andrew WilsonPbd Collision BenchmarkA pbd collision benchmark could be really useful. I have, at many points, wanted to know if changes to code effected performance. But not all of our examples are representation of full usage as they don't produce many contacts.A pbd collision benchmark could be really useful. I have, at many points, wanted to know if changes to code effected performance. But not all of our examples are representation of full usage as they don't produce many contacts.https://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/437Examples Dependencies2022-06-16T00:28:04-04:00Andrew WilsonExamples DependenciesVarious if statements are required to only build examples when certain dependencies are present. It would be nice if we had a general function to just check if the libraries listed in the target_link_libraries are present, and if not, do...Various if statements are required to only build examples when certain dependencies are present. It would be nice if we had a general function to just check if the libraries listed in the target_link_libraries are present, and if not, don't build it.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/436CollisionUtils Move2022-06-16T00:21:02-04:00Andrew WilsonCollisionUtils MoveSome of the math functions in CollisionUtils find use in other places of code (such as Constraints and the recent dependency introduced there). Filtering also has high potential to use them.
By linking this we also link all of Geometry ...Some of the math functions in CollisionUtils find use in other places of code (such as Constraints and the recent dependency introduced there). Filtering also has high potential to use them.
By linking this we also link all of Geometry in there and some other things/functions that just generally should not be used in Constraints. In an effort to speed build, reduce mistakes, and allow other modules to use it without pulling in much unneeded things we should split it off.
Generally these are various intersection and geometric functions. Various possibilities:
- Its own library with just CollisionUtils
- In commonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/435Update logic inside `EdgeEdgeCCDState` with function call to `edgeToEdgeClose...2022-08-17T10:27:26-04:00Shreeraj JadhavUpdate logic inside `EdgeEdgeCCDState` with function call to `edgeToEdgeClosestPoints`Remove duplicate implementation and simplify `CollisionDetection/EdgeEdgeCCDState` by calling `CollisionUtils::edgeToEdgeClosestPoints` inside `EdgeEdgeCCDState`.
See: https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/36664de0e276828c6b61e4...Remove duplicate implementation and simplify `CollisionDetection/EdgeEdgeCCDState` by calling `CollisionUtils::edgeToEdgeClosestPoints` inside `EdgeEdgeCCDState`.
See: https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/36664de0e276828c6b61e4436e7899c9f6294119/Source/CollisionDetection/imstkCollisionUtils.h#L1038Jacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/434Fixed Iteration For Visual Tests2022-08-06T03:52:01-04:00Andrew WilsonFixed Iteration For Visual TestsThey should not use the SimulationManager, be replaced with something more simple:
```
while (sceneTime < maxTime)
{
sceneManager->setDt(fixedDt);
sceneManager->update();
viewer->update(); // The rate you do this may need som...They should not use the SimulationManager, be replaced with something more simple:
```
while (sceneTime < maxTime)
{
sceneManager->setDt(fixedDt);
sceneManager->update();
viewer->update(); // The rate you do this may need some more thought
}
```
There's a couple other bits that make this a tad trickier to do.https://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/432Remove dependency of OpenVR from ViewerVTK2022-06-16T00:32:53-04:00Jean-Christophe Fillion-RobinRemove dependency of OpenVR from ViewerVTKBuilding the ViewerVTK library should not require `OpenVR` (or even OpenXR being added in https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/767)
To maintain the naming convention, `ViewerVTK` could be split into `ViewerVTK` and `V...Building the ViewerVTK library should not require `OpenVR` (or even OpenXR being added in https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/767)
To maintain the naming convention, `ViewerVTK` could be split into `ViewerVTK` and `ViewerVTKOpenVR`https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/431Multi Channel Texturing2022-06-02T01:39:01-04:00Andrew WilsonMulti Channel TexturingIt appears as though VTK **might** support multi channel texturing, given some googling history. Especially given this commented out line of code in our code: https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/RenderingVTK/Rende...It appears as though VTK **might** support multi channel texturing, given some googling history. Especially given this commented out line of code in our code: https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/RenderingVTK/RenderDelegate/imstkVTKSurfaceMeshRenderDelegate.cpp#L571
Multi channel texturing is useful as it allows multiple sets of texture coordinates on an object with different textures that are then blended together. This is particular useful for cutting where cut faces almost always have another texture. But also other effects & general texture changes.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/430Shape Matching2022-06-02T01:22:31-04:00Andrew WilsonShape MatchingShape matching can be used globally, locally, or for plasticity.
Shape Matching and moreso Local Shape Matching (see [A Survey on Position Based Dynamics, 2017](http://mmacklin.com/2017-EG-CourseNotes.pdf))Shape matching can be used globally, locally, or for plasticity.
Shape Matching and moreso Local Shape Matching (see [A Survey on Position Based Dynamics, 2017](http://mmacklin.com/2017-EG-CourseNotes.pdf))https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/429Pbd Constraint Feature List2022-06-02T01:22:44-04:00Andrew WilsonPbd Constraint Feature ListThis is a list of constraints that could be useful to imstk:
- [ ] Shape Matching and moreso Local Shape Matching (see [A Survey on Position Based Dynamics, 2017](http://mmacklin.com/2017-EG-CourseNotes.pdf))
- [ ] Plasticity with Shap...This is a list of constraints that could be useful to imstk:
- [ ] Shape Matching and moreso Local Shape Matching (see [A Survey on Position Based Dynamics, 2017](http://mmacklin.com/2017-EG-CourseNotes.pdf))
- [ ] Plasticity with Shape Matching
- [ ] Our Pbd Fluids still uses PBD, not XPBD.
- [ ] Inverted Green Strain for FEM Tet constraint using SVD as described [Position-Based Simulation of Continuous Materials](https://animation.rwth-aachen.de/media/papers/2014-CAG-PBER.pdf)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/427DataArray and VecDataArray Compile Time Access to # of Component and Scalar Type2022-06-20T04:22:01-04:00Andrew WilsonDataArray and VecDataArray Compile Time Access to # of Component and Scalar TypeMany template classes provide using statements for types that are template arguments such that they can be used at compile time (forwarded into another template function, static assertion, constexpr if statement, other compile time uses)...Many template classes provide using statements for types that are template arguments such that they can be used at compile time (forwarded into another template function, static assertion, constexpr if statement, other compile time uses). Atm there is no way to do this with VecDataArray # of components and scalar type. Which ARE known at compile time, but cannot be used.
Example of such a function:
```
template<int N>
static void whatWhatWhatttt()
{
for (int i = 0; i < N; i++)
{
printf("woof\n");
}
}
template<typename T>
static void fill(T& myDataArray,
typename T::ValueType initValue)
{
myDataArray.fill(initValue);
if constexpr(T::NumComponents == 5)
{
printf("blah\n");
}
whatWhatWhatttt<T::NumComponents>();
}
```Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/426Cmake Settings for Imstk-Unity2022-06-24T08:19:57-04:00Harald ScheirichCmake Settings for Imstk-UnityWhen building for imstk Unity VTK and maybe some other dependencies should be turned offWhen building for imstk Unity VTK and maybe some other dependencies should be turned offHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/425Macro style cleanup2022-05-26T08:45:09-04:00Harald ScheirichMacro style cleanupiMSTK uses a variety of macros, only a some of them use a prefix `IMSTK` as macros are global this may cause clashes with software packages (e.g. `LOG` and `CHECK`), some macros are unused or rarely used and could be removed (`imstkGetMa...iMSTK uses a variety of macros, only a some of them use a prefix `IMSTK` as macros are global this may cause clashes with software packages (e.g. `LOG` and `CHECK`), some macros are unused or rarely used and could be removed (`imstkGetMacro`, `imstkSetMacro`)
- [ ] Remove Superflous macros
- [ ] prefix all macros with `IMSTK`https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/424More aggressive checking on nullptr parameters and incorrect types2022-05-26T08:40:54-04:00Harald ScheirichMore aggressive checking on nullptr parameters and incorrect typesiMSTK passes a lot of parameters as `std::shared_ptr` of the super type, in various places the (e.g. all geometry filter) subclasses these parameters need to be of specific types otherwise the filter will not run. In a lot of cases this ...iMSTK passes a lot of parameters as `std::shared_ptr` of the super type, in various places the (e.g. all geometry filter) subclasses these parameters need to be of specific types otherwise the filter will not run. In a lot of cases this is checked only on executing the filter and is the only reported with a warning on the console while the the rest of the software keeps running. This can make it hard to detect failures especially with new users.
In general we should `CHECK` for the correct type of input parameters whenever a polymorphic type is received in a function call (this will also automatically check for nullptr)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/423Add wording with regards to Openhaptics license2022-05-24T11:05:54-04:00Harald ScheirichAdd wording with regards to Openhaptics licensehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/422Examples Website2022-06-01T15:58:24-04:00Andrew WilsonExamples WebsiteThis tends to be the first point of contact for many with VTK https://kitware.github.io/vtk-examples/site/Cxx/ . https://kitware.github.io/vtk-examples/site/Cxx/
It would not be too hard to add a script that adds a description + a pictu...This tends to be the first point of contact for many with VTK https://kitware.github.io/vtk-examples/site/Cxx/ . https://kitware.github.io/vtk-examples/site/Cxx/
It would not be too hard to add a script that adds a description + a picture + code to an html webpage for iMSTK.
See https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/.gitlab-ci.yml . Simply call the script to generated html, then move it to the public/ directory and it will be hosted.https://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/420SurfaceMesh deepCopy parameter2022-08-30T13:25:25-04:00Connor BowleySurfaceMesh deepCopy parameterNot necessarily a big deal, but it was unexpected to me that I can only deep copy SurfaceMesh's if the one I want to copy is stored in a `shared_ptr`. I would expect the signature to instead be `void deepCopy(const SurfaceMesh& srcMesh)`...Not necessarily a big deal, but it was unexpected to me that I can only deep copy SurfaceMesh's if the one I want to copy is stored in a `shared_ptr`. I would expect the signature to instead be `void deepCopy(const SurfaceMesh& srcMesh)`, as there is no true requirement that one can only copy 1) surface meshes that are specifically stored in shared pointer, and 2) non-const surface meshes (as the current parameter is `shared_ptr<SurfaceMesh>` and not `shared_ptr<const SurfaceMesh>`.
As an aside regarding a comment in the code for deepCopy, `\todo: generalize base classes and implement for every geometry`, please consider using a clone approach rather than a deep copy approach so it will work nicely with class hierarchies. You wouldn't really be able to implement `void PointSet::deepCopy(const PointSet& src)` because I could do something like `surfaceMesh.deepCopy(lineMesh)` and that can't happen (yes, you could detect this at runtime and throw and exception (or do the VTK method and silently ignore it), but ensuring the type safe clone can always happen is better). However, doing `surfaceMesh.clone()` or even `pointSetThatCouldBeASurfaceMesh.clone()` is always well defined.
Also, should you go the clone route, I found this a neat way to fake covariant return types with smart pointers.
https://www.fluentcpp.com/2017/09/12/how-to-return-a-smart-pointer-and-use-covariance/
For reference:
- https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c130-for-making-deep-copies-of-polymorphic-classes-prefer-a-virtual-clone-function-instead-of-public-copy-constructionassignmenthttps://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 Wilson