iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-09-27T20:45:41-04:00https://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/255refactor VTKTextStatusManager to use vtkCornerAnnotation2022-09-26T12:07:45-04:00Sreekanth Arikatlarefactor VTKTextStatusManager to use vtkCornerAnnotationAndrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/366VTKViewer::setDebugAxesLength Should not need an active VTKRenderer to set de...2022-09-26T12:07:41-04:00Andrew WilsonVTKViewer::setDebugAxesLength Should not need an active VTKRenderer to set debug axes lengthIf you call setDebugAxesLength before setting an active scene it will do nothing. This is because the renderer is lazy created. Not created until active scene is created (legacy reason of creating separate renderers for separate scenes, ...If you call setDebugAxesLength before setting an active scene it will do nothing. This is because the renderer is lazy created. Not created until active scene is created (legacy reason of creating separate renderers for separate scenes, which still work decently for scene switching).Andrew WilsonAndrew Wilsonhttps://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 Wilsonhttps://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/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/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/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/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/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/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/166Write audio interface classes2022-04-20T08:34:16-04:00Sreekanth ArikatlaWrite audio interface classesWrite audio interface classes for SFMLWrite audio interface classes for SFMLhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/265Download the data optionally at the build2022-04-20T08:26:25-04:00Sreekanth ArikatlaDownload the data optionally at the buildBuild should not be held for the downloadBuild should not be held for the downloadhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/254Extensible Object Factories2022-04-14T14:55:07-04:00Andrew WilsonExtensible Object FactoriesA number of base classes in imstk use enums for types and object factories. This looks like a giant if statement with a ton of includes. These are ok, but they aren't extensible. The better solution is to have each class register to the ...A number of base classes in imstk use enums for types and object factories. This looks like a giant if statement with a ton of includes. These are ok, but they aren't extensible. The better solution is to have each class register to the factory a function by its class name to create itself.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/279Remove RigidBodyWorld Singleton2022-04-12T17:00:07-04:00Andrew WilsonRemove RigidBodyWorld SingletonRigidBodyModel (PhysX) should not be using a singleton. It should follow a pattern similar to RigidBodyModel2 for a shared implicit DynamicalModel.RigidBodyModel (PhysX) should not be using a singleton. It should follow a pattern similar to RigidBodyModel2 for a shared implicit DynamicalModel.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/326Move Example-RCM to Unit Tests2022-04-12T16:59:08-04:00Andrew WilsonMove Example-RCM to Unit TestsAs the title says this would be more appropriate as a unit tests in GeometryTests.As the title says this would be more appropriate as a unit tests in GeometryTests.Jianfeng YanJianfeng Yanhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/372Build without OpenVR support2022-04-12T16:46:28-04:00Connor BowleyBuild without OpenVR supportFor projects that don't need OpenVR, it would be useful to have a build flag to turn off OpenVR support and not require OpenVR in the build process.For projects that don't need OpenVR, it would be useful to have a build flag to turn off OpenVR support and not require OpenVR in the build process.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/104Replace m_type by hardcoding type return in getType()2022-01-07T01:03:18-05:00Alexis GiraultReplace m_type by hardcoding type return in getType()Right now `m_type` is stored within each class with a lot of inheritance (geometryMap, sceneobject, geometry...) to help quickly accessing the type from the base class without dynamic casting the object in all possible variances in a `sw...Right now `m_type` is stored within each class with a lot of inheritance (geometryMap, sceneobject, geometry...) to help quickly accessing the type from the base class without dynamic casting the object in all possible variances in a `switch`.
A better way to do this to avoid redundancy in information (storing `m_type` while a dynamic cast would work) is to define `getType()` as a static pure virtual function in the base class and implement it in the inheriting classes by hardcoding the return value to the appropriate type.
Could also consider getting rid of `Type` and looking into `typeid(object).name()`
http://en.cppreference.com/w/cpp/language/typeidhttps://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/368PbdConstraintFunctors should be constructed in PbdModelConfig and used for pa...2021-12-15T17:29:07-05:00Andrew WilsonPbdConstraintFunctors should be constructed in PbdModelConfig and used for parametersOne of the issues with the PbdModelConfig is how it stores parameters. Each Functor could have any set of parameters. Generally:
- "Regular Constraints": Have one double stiffness value
- FEMConstraints: Have either possions ratio+you...One of the issues with the PbdModelConfig is how it stores parameters. Each Functor could have any set of parameters. Generally:
- "Regular Constraints": Have one double stiffness value
- FEMConstraints: Have either possions ratio+youngs modulus OR lame parameters
- BendConstraint: Has an extra parameter for strides
Really there's no telling (literally unable to tell) what parameters a user would want to use with a functor. While we should still maintain the pretty simple PbdModelConfig::enableConstraint function. It should immediately create and store the functor otherwise PbdModelConfig has to worry about how to store all these parameters and then later use them to setup functors which causes nasty code.
This should eliminate complexities in PbdModelConfig for FEM and Bend constraints. Specialized functions such as enableBendConstraint(stiffness, stride) and enableFEMConstraint(type, material) should still be present.