iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-12-05T16:31:27-05:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/487Redundant classes / files between Examples2022-12-05T16:31:27-05:00Shreeraj JadhavRedundant classes / files between ExamplesThere are certain classes and files that are duplicates of each other in the Examples (particularly related to Needles).
For e.g.:
1. NeedleInteraction.cpp
1. NeedleInteraction.h
1. NeedlePbdCH.h
1. NeedleRigidBodyCH.cpp
1. NeedleRigidBo...There are certain classes and files that are duplicates of each other in the Examples (particularly related to Needles).
For e.g.:
1. NeedleInteraction.cpp
1. NeedleInteraction.h
1. NeedlePbdCH.h
1. NeedleRigidBodyCH.cpp
1. NeedleRigidBodyCH.h
There maybe small differences between them. These files/classes should be refactored to remove duplication.
![image](/uploads/b34c9ed0a48caf1f14144b6141ece38f/image.png)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/482shared_from_this and Capture Lists2022-10-20T17:49:01-04:00Andrew Wilsonshared_from_this and Capture ListsIn many locations lambdas are used that capture `this`
```
MyClass::MyClass()
{
auto func = [&]()
{
this->doSomething();
};
}
```
The above is fine but if this function ptr is to be passed around it could exist longer th...In many locations lambdas are used that capture `this`
```
MyClass::MyClass()
{
auto func = [&]()
{
this->doSomething();
};
}
```
The above is fine but if this function ptr is to be passed around it could exist longer then the duration of the class, for which any reference to anything to `this` in that function would fail, likely a read access violation.
With shared_from_this in Components we can make this safer.
```
MyClass::MyClass()
{
auto strongThis = shared_from_this();
auto func = [strongThis]()
{
strongThis->doSomething();
};
}
```
This however, won't work because we cannot use shared_from_this in a constructor. For this reason it may be appropriate in Behaviours to have a separate function to initialize internal state. Particularly in a Behaviour that uses TaskNode's which rely on function ptrs.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/476Get ImplicitGeometryToPointSetCCD subclassing CCDAlgorithm2022-10-10T00:00:05-04:00Andrew WilsonGet ImplicitGeometryToPointSetCCD subclassing CCDAlgorithmCurrently this class does not subclass CCDAglorithm as it existed before. ImplicitGeoemtryToPointSetCCD uses displacements instead of pre/post vertices at the moment.Currently this class does not subclass CCDAglorithm as it existed before. ImplicitGeoemtryToPointSetCCD uses displacements instead of pre/post vertices at the moment.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/475Componentize ScreenCaptureUtility2022-10-13T09:12:55-04:00Andrew WilsonComponentize ScreenCaptureUtilityScreenCaptureUtility could move to a Behaviour. It is currently integrated into VTKViewer itself. Can help debloat VTKViewer and the VTKRenderer a bit more.ScreenCaptureUtility could move to a Behaviour. It is currently integrated into VTKViewer itself. Can help debloat VTKViewer and the VTKRenderer a bit more.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/474Join DeviceClient buttons2022-10-10T00:00:42-04:00Andrew WilsonJoin DeviceClient buttonsDeviceClient stores button states in the base class.
MouseDeviceClient and HapticDeviceClient each have a separate events for it. buttonStateChanged, mousePress, mouseRelease. It would be nice if buttonStateChanged was reusable with Mou...DeviceClient stores button states in the base class.
MouseDeviceClient and HapticDeviceClient each have a separate events for it. buttonStateChanged, mousePress, mouseRelease. It would be nice if buttonStateChanged was reusable with MouseDeviceClient.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/469Misleading RigidBodyModel22022-10-10T00:00:58-04:00Andrew WilsonMisleading RigidBodyModel2Currently we have RigidBodyModel2, I don't think about it much. But taking a step back, its very misleading, especially as Pbd Rigids continue to see support.Currently we have RigidBodyModel2, I don't think about it much. But taking a step back, its very misleading, especially as Pbd Rigids continue to see support.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/455Needle Component2022-09-26T12:07:27-04:00Andrew WilsonNeedle ComponentWith the component MR we are able to add a needle component. Which can be carried around in a SceneObject without subclassing. This would be a good next step towards a general needle architecture.
ie:
```
class NeedleComponent : public ...With the component MR we are able to add a needle component. Which can be carried around in a SceneObject without subclassing. This would be a good next step towards a general needle architecture.
ie:
```
class NeedleComponent : public Component
{
public:
// Could be stored in component as well
virtual Vec3d getNeedleDirection() { return Vec3d::Zero(); }
virtual Vec3d getNeedleTip() { return Vec3d::Zero(); }
PunctureState punctureState;
};
int main()
{
SceneObject obj0;
auto needleComp0 = obj0.addComponent<NeedleComponent>();
PbdObject obj1;
auto needleComp1 = obj1.addComponent<NeedleComponent>();
RigidObject obj2;
auto needleComp2 = obj2.addComponent<NeedleComponent>();
}
```
This dissolves the need for NeedleObject in every example which is especially annoying when different subclasses are used. One can refactor the examples and leave NeedleObjects in but just have the NeedleObjects add a NeedleComponent. Additionnally interaction will need to use the component now to get things like tip, direction, etc.Andrew WilsonAndrew Wilsonhttps://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/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/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/416C++17 Support2022-06-18T01:03:38-04:00Andrew WilsonC++17 SupportNow that FTD2XX has been removed this should be easier. Running the build (without testing, examples, openhaptics, vrpn) I get errors only in:
- Assimp (ours is very out of date, latest assimp does support c++17)
- SFML (latest SFML do...Now that FTD2XX has been removed this should be easier. Running the build (without testing, examples, openhaptics, vrpn) I get errors only in:
- Assimp (ours is very out of date, latest assimp does support c++17)
- SFML (latest SFML does support, easy update since we don't wrap any of its API at the moment)
- VegaFEM (Would have to make our own commits to our fork to fix it)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/407Upgrade Examples That use Mouse Virtual Coupling to use DummyClient2022-08-22T03:17:53-04:00Andrew WilsonUpgrade Examples That use Mouse Virtual Coupling to use DummyClientRight now many examples implement a dumbed down virtual coupling in their post update with mouse controls. These should be ported to use DummyClient so that we can reuse the virtual coupling implemented in RigidObjectController.Right now many examples implement a dumbed down virtual coupling in their post update with mouse controls. These should be ported to use DummyClient so that we can reuse the virtual coupling implemented in RigidObjectController.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/406Consolidate RbdConstraint & PbdConstraint2022-09-27T20:45:41-04:00Andrew WilsonConsolidate RbdConstraint & PbdConstraintThe RbdConstraint & PbdConstraint could become more similar in implementation.
- [ ] Use a flag or some other interface to indicate that a constraint, be it PbdConstraint or RbdConstraint. Should be clearable. IE: Put into a separate c...The RbdConstraint & PbdConstraint could become more similar in implementation.
- [ ] Use a flag or some other interface to indicate that a constraint, be it PbdConstraint or RbdConstraint. Should be clearable. IE: Put into a separate container that is cleared every simulation frame.
- [ ] This would require introduction of a container of constraints in RigidBodyModel that does not clear. New feature.
- [ ] Rename RbdConstraint::compute to computeValueAndGradient, to match Pbd.
- [ ] Pass in the required constraint values by reference like computeValueAndGradient. J & vu.
- [ ] Explore why computeValueGradient is not called in a loop before RigidBodyModel::Solve.
- [ ] The signs might be backwards in one of the constraint gradients (I think RbdConstraint has backward sign).
- [ ] Consider renaming PbdConstraint::initConstraint to PbdConstraint::init. Then introducing RbdConstraint::init & removing constructor initialization.
- [ ] Remove PbdCollisionConstraint. Rework all PbdConstraints to stem from the same base PbdConstraint (may not be possible performantly without templates, was attempted at numerous points, difficult).
This should make it much easier to work with the two models.
I suspect as we approach a proper solution of compliance between the two models we will arrive at something similar to PBD rigid bodies described in the paper "Detailed Rigid Body Simulation with Extended Position Based Dynamics"https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/395ViewerVTK & RenderingVTK Module Toggles2022-05-12T22:25:15-04:00Andrew WilsonViewerVTK & RenderingVTK Module TogglesNow that the libraries have been separated we may add a toggle for ViewerVTK & RenderingVTK which will allow one to build without these modules. Ultimately for using iMSTK as a physics backend only (a VTK without vtk rendering or differe...Now that the libraries have been separated we may add a toggle for ViewerVTK & RenderingVTK which will allow one to build without these modules. Ultimately for using iMSTK as a physics backend only (a VTK without vtk rendering or different rendering libs can be provided).https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/392TBB Upgrade2021-12-20T15:57:18-05:00Andrew WilsonTBB UpgradeTBB should be upgraded, at least soon after the VTK9.1 goes in so they can be on the same version. It hasn't appeared to cause any issues.TBB should be upgraded, at least soon after the VTK9.1 goes in so they can be on the same version. It hasn't appeared to cause any issues.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/391Assimp 5.1.4 Upgrade2022-06-01T17:28:30-04:00Andrew WilsonAssimp 5.1.4 UpgradeLooks like Assimp went through some bugfixes recently including support for the latest blender file type (big blend changes over 2.8-2.9) this could greatly improve workflow (at least for prototyping things quickly). Hopefully some other...Looks like Assimp went through some bugfixes recently including support for the latest blender file type (big blend changes over 2.8-2.9) this could greatly improve workflow (at least for prototyping things quickly). Hopefully some other things are ironed out now that v5.0 is more mature as there are many file type bugs. Especially when you get into the nitty gritty details of something like animation.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/387SurfaceMeshToMeshCD2022-06-01T16:15:39-04:00Andrew WilsonSurfaceMeshToMeshCDWe currently have ClosedSurfaceMeshToMeshCD. This only works for closed surfaces. It is good for deep contacts.
We do not have the more traditional SurrfaceMeshtoMeshCD, which only locally gives resolution. IE: It checks intersection be...We currently have ClosedSurfaceMeshToMeshCD. This only works for closed surfaces. It is good for deep contacts.
We do not have the more traditional SurrfaceMeshtoMeshCD, which only locally gives resolution. IE: It checks intersection between all the elements (triangles or lines). Then computes resolutions of those elements. The hope being that only small overlaps occur at small dts and if deep contacts happen they would eventually resolve (objects could get stuck). The pro of this method is that it is easily spatially partitioned whereas ClosedSurfaceMeshToMeshCD is not as it tries to find global resolution.
This is usually done with a clipping method. Such method can be found in Bullet or ODE.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/384Entity-Component (ECS) for Scene Object Interface2022-09-26T12:07:35-04:00Andrew WilsonEntity-Component (ECS) for Scene Object InterfaceIntroduction
---
The entity-component architecture is a well known architecture used in many game engines (ECS is more widely used). The motivation behind it is the desire for modularity and extensibility of a scene object interface. The...Introduction
---
The entity-component architecture is a well known architecture used in many game engines (ECS is more widely used). The motivation behind it is the desire for modularity and extensibility of a scene object interface. The idea is to prefer composition over inheritance for the scene object interface. This allows one to add/remove functionality (components) to an object easily. This also allows things like object morphing as you are not tied to a subclass (ex: a PbdObject can become a FemObject by addition of PbdModel and removal of FemModel).
A quick simple psuedo-example for the very unfamiliar (note many ECSs are data oriented and may not have an update, or hybrid and have a subclass that then adds the update):
```
class Component
{
virtual void update() = 0;
}
class Object
{
Component[] components;
void update()
{
for (every comp i in components) { comp.update(); }
}
}
// One should subclass Component to add functionality to Object
```
iMSTK is well suited for this type of architecture due to the large amount of "intra-object customization" required by users. This has been on iMSTK's plate for awhile and it's been lightly moving towards/prepping for it for quite some time now (moving functionality out of the Objects).
Example Use Case
---
Here's an idea of something that could be possible depending on design:
- Ex1: One could construct a ThreadObject which contains PbdModel & AnimatedModel components. Which simulates a line mesh and skins it to a thread geometry.
- Ex2: One could construct a SkinObject which contains multiple PbdModel's, VisualModels, & GeometryMap components.
- Ex3: One could construct a SkinObject which contains one PbdModel but multiple VisualModels + GeometryMap components.
- Ex4: One could construct a all-in-one tool (say arthoscope head) which contains a Camera, Light, RbdModel, & GeometryMap. Possibly even multiple RbdModel's for each piece.
Continued details in documents:
Documents
---
[Notion UML Diagram + Notes](https://www.notion.so/Imstk-ECS-8a00a245e9214ea187d29976e2f02784)Andrew WilsonAndrew Wilson