iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2021-05-26T13:39:25-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/285Analytical Geometries Orientation Axes2021-05-26T13:39:25-04:00Andrew WilsonAnalytical Geometries Orientation AxesMany of the analytical geometries use an orientation axes to represent rotations. Not all orientations can be represented with a single axes.
For instance, a analytical plane with normal (0, 1, 0) cannot be rotated around y.
This shoul...Many of the analytical geometries use an orientation axes to represent rotations. Not all orientations can be represented with a single axes.
For instance, a analytical plane with normal (0, 1, 0) cannot be rotated around y.
This should instead be an AngleAxes. dir + theta. It would be more intuitive to just use the base class geometry 4x4 transform. Most of the render delegates just do an expensive rotate vector to vector computation anyways, to produce this transform.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/281RbdObject2-CollidingObject Collision2021-03-16T18:53:14-04:00Andrew WilsonRbdObject2-CollidingObject CollisionCurrently for rigid object collision in RigidBodyModel2 both objects need to be of type RbdObject2. But one way collision should be supported through CollidingObject.Currently for rigid object collision in RigidBodyModel2 both objects need to be of type RbdObject2. But one way collision should be supported through CollidingObject.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/280PbdObject-CollidingObject Collision2021-08-05T21:02:51-04:00Andrew WilsonPbdObject-CollidingObject CollisionCurrently PbdObject only can collide with other PbdObjects whose masses are set to 0 for static collision. But it should be able to collide with CollidingObject.Currently PbdObject only can collide with other PbdObjects whose masses are set to 0 for static collision. But it should be able to collide with CollidingObject.Andrew WilsonAndrew Wilsonhttps://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/278Extend LevelSetModel to Other Geometries2021-01-08T21:42:52-05:00Andrew WilsonExtend LevelSetModel to Other GeometriesLevelSetModel is currently only designed for 3d images. It can further be generalized for any Geometry with generic function value and finite difference functions.
Namely it would be nice to have it working with 2d images and tetrahedra...LevelSetModel is currently only designed for 3d images. It can further be generalized for any Geometry with generic function value and finite difference functions.
Namely it would be nice to have it working with 2d images and tetrahedral meshes.
One step farther and you could generalize it for other differential equations. Such as heat or reaction diffusion.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/277Extend ImageData to 2d2021-04-05T12:37:46-04:00Andrew WilsonExtend ImageData to 2dJust as the title says, extend to 2d. We could also then look into utilizing it for texturing. Additionally the aptly named ImageDataRenderDelegate which does volume rendering of a 3d image should be renamed and a 2d RenderDelegate added.Just as the title says, extend to 2d. We could also then look into utilizing it for texturing. Additionally the aptly named ImageDataRenderDelegate which does volume rendering of a 3d image should be renamed and a 2d RenderDelegate added.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/276Geometry Init/Current Refactor2021-05-14T08:41:06-04:00Andrew WilsonGeometry Init/Current RefactorCurrently geometry composites post/pre (current/init) members. Such as in PointSet it has current and init positions. This has proven difficult. Instead an entirely separate geometry object should be used. This is especially helpful for ...Currently geometry composites post/pre (current/init) members. Such as in PointSet it has current and init positions. This has proven difficult. Instead an entirely separate geometry object should be used. This is especially helpful for post/pre velocities and other attributes. As well as every other member that has post/pre state, including those in primitive geometries.
Obvious failures of such thing are shown in PbdClothRemap. If one subdivides then resets, it will fail. Similarly for any attribute reset will fail.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/275Geometry Transform Refactor2021-01-21T18:45:12-05:00Andrew WilsonGeometry Transform RefactorGeometry currently uses a weird TRS (with uniform scaling) at its base class level. It should instead use a single 4x4 transform.Geometry currently uses a weird TRS (with uniform scaling) at its base class level. It should instead use a single 4x4 transform.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/270Remove DebugRenderGeometry and DebugDelegates2021-08-05T21:03:08-04:00Andrew WilsonRemove DebugRenderGeometry and DebugDelegatesThe DebugRenderGeometry and Delegate currently provide topology changing functionalities and buffering that the SurfaceMesh and LineMesh don't. Allowing one to easily insert a line/etc for a contact or whatever.
After we add topology ch...The DebugRenderGeometry and Delegate currently provide topology changing functionalities and buffering that the SurfaceMesh and LineMesh don't. Allowing one to easily insert a line/etc for a contact or whatever.
After we add topology change (both changing topology/buffer swap and buffering) support to SurfaceMesh and LineMesh the debug geometry should be removed/replaced with usage of SurfaceMesh and LineMesh as they would be redundant.
Additionally Geometry supports multi viewer/observers but DebugGeometry still uses flags which can only be used by one observer.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/268TextureDelegate Modifications2021-04-05T20:58:28-04:00Andrew WilsonTextureDelegate ModificationsTextureDelegates need to be updated with event system. Particularly in SurfaceMeshRenderDelegate.
- When a new texture is added, it should update the VTK one
- When parameters of a texture is changed, it should update the VTK one
These ...TextureDelegates need to be updated with event system. Particularly in SurfaceMeshRenderDelegate.
- When a new texture is added, it should update the VTK one
- When parameters of a texture is changed, it should update the VTK one
These should not be called every update of the delegate but only when the texture posts modified. A queueConnect should be used along with a message queue.https://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/255refactor VTKTextStatusManager to use vtkCornerAnnotation2022-09-26T12:07:45-04:00Sreekanth Arikatlarefactor VTKTextStatusManager to use vtkCornerAnnotationAndrew WilsonAndrew Wilsonhttps://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/249PBD collision simulation is sensitive to the timestep2021-08-05T21:02:00-04:00Sreekanth ArikatlaPBD collision simulation is sensitive to the timestephttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/238Remove cyclic dependencies2020-07-31T11:23:15-04:00Sreekanth ArikatlaRemove cyclic dependencies[click here to visualize](https://dreampuf.github.io/GraphvizOnline/#digraph%20imstkDependency%0A%7B%0Astyle%3Dfilled%3B%0Acolor%3Dlightgrey%3B%0Anode%20%5Bstyle%3Dfilled%2Ccolor%3Dcornflowerblue%5D%3B%0Aedge%5Barrowhead%3Dvee%2C%20arrow...[click here to visualize](https://dreampuf.github.io/GraphvizOnline/#digraph%20imstkDependency%0A%7B%0Astyle%3Dfilled%3B%0Acolor%3Dlightgrey%3B%0Anode%20%5Bstyle%3Dfilled%2Ccolor%3Dcornflowerblue%5D%3B%0Aedge%5Barrowhead%3Dvee%2C%20arrowtail%3Dinv%2C%20arrowsize%3D.7%2C%20color%3Dgrey20%5D%0ACollision%20-%3E%20Datastructures%20%20%20%20%0ACollision%20-%3E%20Geometry%0ACollision%20-%3E%20SceneElements%0ACollision%20-%3E%20DynamicalModels%0A%0AAnimation%20-%3E%20Core%0AAnimation%20-%3E%20Geometry%0AAnimation%20-%3E%20SceneElements%0A%0ASimulationManager%20-%3E%20Rendering%0A%0AMaterials%20-%3E%20Core%0A%0AGeometry%20-%3E%20Core%0AGeometry%20-%3E%20Materials%0A%0ADevices%20-%3E%20Core%0A%0AScene%20-%3E%20Core%0AScene%20-%3E%20SceneElements%0AScene%20-%3E%20DynamicalModels%0AScene%20-%3E%20Collision%0A%0AConstraints%20-%3E%20Core%0AConstraints%20-%3E%20Geometry%0A%0ADynamicalModels%20-%3E%20Core%0ADynamicalModels%20-%3E%20Datastructures%0ADynamicalModels%20-%3E%20Geometry%0ADynamicalModels%20-%3E%20Constraints%0ADynamicalModels%20-%3E%20Solvers%20%5Bcolor%3Dred%5D%0A%0ARendering%20-%3E%20Scene%0ARendering%20-%3E%20Animation%0A%0ASceneElements%20-%3E%20Core%0ASceneElements%20-%3E%20Geometry%0ASceneElements%20-%3E%20Constraints%0ASceneElements%20-%3E%20Devices%0ASceneElements%20-%3E%20DataStructures%0ASceneElements%20-%3E%20DynamicalModels%20%20%5Bcolor%3Dred%5D%20%20%20%0A%0ASolvers%20-%3E%20Core%0ASolvers%20-%3E%20Datastructures%0ASolvers%20-%3E%20Constraints%0ASolvers%20-%3E%20SceneElements%20%5Bcolor%3Dred%5D%0A%0ADatastructures%20-%3E%20Core%0ADatastructures%20-%3E%20Materials%0ADatastructures%20-%3E%20Geometry%0A%0AGUIOverlay%20-%3E%20Core%0A%0AapiUtilities%20-%3E%20Core%0AapiUtilities%20-%3E%20SimulationManager%0AapiUtilities%20-%3E%20Scene%0A%7D)
```
digraph imstkDependency
{
style=filled;
color=lightgrey;
node [style=filled,color=cornflowerblue];
edge[arrowhead=vee, arrowtail=inv, arrowsize=.7, color=grey20]
Collision -> Datastructures
Collision -> Geometry
Collision -> SceneElements
Collision -> DynamicalModels
Animation -> Core
Animation -> Geometry
Animation -> SceneElements
SimulationManager -> Rendering
Materials -> Core
Geometry -> Core
Geometry -> Materials
Devices -> Core
Scene -> Core
Scene -> SceneElements
Scene -> DynamicalModels
Scene -> Collision
Constraints -> Core
Constraints -> Geometry
DynamicalModels -> Core
DynamicalModels -> Datastructures
DynamicalModels -> Geometry
DynamicalModels -> Constraints
DynamicalModels -> Solvers [color=red]
Rendering -> Scene
Rendering -> Animation
SceneElements -> Core
SceneElements -> Geometry
SceneElements -> Constraints
SceneElements -> Devices
SceneElements -> DataStructures
SceneElements -> DynamicalModels [color=red]
Solvers -> Core
Solvers -> Datastructures
Solvers -> Constraints
Solvers -> SceneElements [color=red]
Datastructures -> Core
Datastructures -> Materials
Datastructures -> Geometry
GUIOverlay -> Core
apiUtilities -> Core
apiUtilities -> SimulationManager
apiUtilities -> Scene
}
```https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/183Remove scene class dependency for the renderer2021-01-08T17:26:17-05:00Sreekanth ArikatlaRemove scene class dependency for the rendererCurrently, the renderer (VTK and Vulkan) loop over scene objects to access geometry and other attributes to optimize rendering pipeline. This is however not desired. Additional API needs to be created in the renderer to accommodate optim...Currently, the renderer (VTK and Vulkan) loop over scene objects to access geometry and other attributes to optimize rendering pipeline. This is however not desired. Additional API needs to be created in the renderer to accommodate optimization flags, geometry specification etc.
CC: @NickMilefhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/179Invoking iMSTK api outside iMSTK with Vulkan option turned on2019-07-28T16:23:31-04:00Andinet enquobahrieInvoking iMSTK api outside iMSTK with Vulkan option turned onReported by @sjh26
"When I use that code to include imstk in my modue, none of the Vulkan related data is passed through. In order to get the module to compile with just a simple include of a core imstk file, I have to
- set the iMST...Reported by @sjh26
"When I use that code to include imstk in my modue, none of the Vulkan related data is passed through. In order to get the module to compile with just a simple include of a core imstk file, I have to
- set the iMSTK_USE_Vulkan define in my own code
- explicitly include Vulkan in my CmakeLists so that I can provide its include directories to my module".https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/174Move visibility functions from RenderMaterial class to Geometry class2018-11-12T11:37:51-05:00Nicholas MilefMove visibility functions from RenderMaterial class to Geometry classThe RenderMaterial can be shared with multiple geometries. This causes problems if the user wants to hide/show one geometry object.The RenderMaterial can be shared with multiple geometries. This causes problems if the user wants to hide/show one geometry object.Nicholas MilefNicholas Milefhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/173Remove Renderer and its subclass from the user API2021-01-08T17:24:27-05:00Sreekanth ArikatlaRemove Renderer and its subclass from the user APIRemove `Renderer` and its subclass from the user API. The user should only interact with the `Viewer` class.
A couple of options:
* Nest render class inside the viewer
* Make every member of `Render` and its subclasses private. Use `...Remove `Renderer` and its subclass from the user API. The user should only interact with the `Viewer` class.
A couple of options:
* Nest render class inside the viewer
* Make every member of `Render` and its subclasses private. Use `friend` to access `Renderer` inside the `Viewer` classeshttps://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 SFML