Welcome to iMSTK documentation!

image0

Interactive Medical Simulation Toolkit (iMSTK)

User Documentation

Introduction

iMSTK is an open-source C++-based software toolkit that aids rapid prototyping of interactive multi-modal medical simulations. It provides a highly modular and easy-to-use framework that can be extended and interfaced with third-party libraries for the development of medical simulators without restrictive licenses.

iMSTK supports all three major platforms-macOS, Linux, Windows and comes with a CMake-based automatic build system. This documentation is designed to provide an overview of iMSTK, introductory concepts needed to comprehend the framework, its component modules, and how they interact to help build simulations. For a detailed insight into the usage of various modules, you may refer to an extensive set of examples that are built by default. For implementational level details of the modules and their classes, please refer to the code documentation. The chapters that follow will describe details of how to build iMSTK, elements of the simulation scenario, and how these elements are connected using iMSTK’s modular architecture followed by a detailed description of each of the major modules. The final chapter includes a walk-through of the code of an all-inclusive example to help the readers quickly build their application.

Setup for Development

iMSTK and its external dependencies can be configured and built from scratch using iMSTK’s CMake super-build (build project dependencies and then the project) on UNIX (MAC, Linux) and Windows platforms.

Configuration and Build

CMake should be used to configure the project on every platform. Please refer to CMake’s official page to read about how to configure using CMake.

Linux/MacOSx

Type the following commands from the same location you cloned the

>> mkdir iMSTK_build
>> cd iMSTK_build
>> cmake ../iMSTK    # path to source directory
>> make -j4 #to build using *4* cores

This will configure the build in a directory adjacent to the source directory. To easily change some configuration variables such as CMAKE_BUILD_TYPE, use ccmake instead of cmake.

One can also use Ninja for a faster build instead of Unix Makefiles. To do so, configure the cmake project with -GNinja

>> cmake -GNinja
>> ../iMSTK
>> ninja

This will checkout, build and link all iMSTK dependencies. When making changes to iMSTK base source code, you can then build from the Innerbuild directory.

Windows

Run CMake-GUI and follow the directions described on CMake’s official page. You need to choose which version of Visual Studio that you would like to use when configuring the project. Make sure to select Microsoft Visual Studio C++ 12 2015 or later. CMake will generate a iMSTK.sln solution file for Visual Studio inside the build directory. Open this file and issue build on ALL_BUILD target, which will perform the superbuild.

The above procedures will configure and build iMSTK in the build directory (iMSTK_build). To easily change some configuration variables such as CMAKE_BUILD_TYPE, use ccmake instead of cmake. When using the CMake-GUI, one can edit the configuration directly.

Once the superbuild is complete, you may notice that (a) all of iMSTK’s dependencies are cloned and built inside their respective folders inside <iMSTK_build_dir>/External (b) iMSTK itself is built inside the <iMSTK_build_dir>/Innerbuild. Beyond this point, when making changes to iMSTK base source code, one can then build from the “innerbuild” target.

Note that one can create and maintain multiple builds from the same source. For example, as is typical to interactive applications testing typically is performed with the Release build while debugging using the Debug build. Additionally, it is usually recommended to separate the build and source directories for cleaner development and maintenance esp. with git-based workflows.

Running Examples

The default CMake configuration builds the examples as part of the inner build. The executables including other targets required to run the executables are placed in the <imstk build dir>/install/bin directory. The execurables can either be run through command line or double clicking.

Options at Configure Time

Phantom Omni Support (haptics)

To support the Geomagic Touch (formerly Sensable Phantom Omni) haptic device, follow the steps below:

  1. Install the OpenHaptics SDK as well as the device drivers:

    1. for Windows

    2. for Linux

  2. Reboot your system.

  3. Configure your CMake project with the variable iMSTK_USE_OpenHaptics set to ON.

  4. After configuration, the CMake variable OPENHAPTICS_ROOT_DIR should be set to the OpenHaptics path on your system.

Note

The examples that depend on this option being on at configure time will not build automatically if this option is not selected.

Building Examples

The examples that demonstrate the features and the usage of iMSTK API can be optionally build. Set BUILD_EXAMPLES to ON the examples needs to be built.

Offscreen Rendering

Offscreen OSMesa/CPU rendering is supported for Linux/MacOSx. This allows one to build iMSTK without a screen or GPU. Useful for servers. This can be enabled in the build by using the iMSTK_USE_VTK_OSMESA flag to ON.

Audio Support

iMSTK has the ability to play audio streams at runtime. In order to enable Audio, set iMSTK_ENABLE_AUDIO to ON.

Uncrustify Support

iMSTK follows specific code formatting rules. This is enforced through Uncrustify. For convenience, iMSTK provides the option to build uncrustify as a target. To enable this set iMSTK_USE_UNCRUSTIFY to ON.

Multithreaded build

The build will be configured to be multi-threaded with 8 threads. This can be changed by modifying the iMSTK_NUM_BUILD_PROCESSES to a positive integer.

Overview of iMSTK

iMSTK is structured similar to many game engines with a focus on real time scene level rendering and simulating. However, iMSTK is aimed at surgical simulation. With this we can assume:

  • Surgical scenes are being rendered. These are generally small, confined to an operating room at most.

  • Surgical simulation software’s are often used for training. This requires a balance between how it feels and looks. Having both is difficult.

    • Haptics often impose >1000 Hz performance requirements which limits rendering and other things one might do in their software.

  • Interactions are fewer but far more complex in surgeries. Often requiring a wide variety of expensive dynamical models and collision detection + response to govern the physics of objects such as deformable, fluid, or rigid bodies.

The following diagram gives a high level view of iMSTK architecture. Most of the components shown in this high level view correspond to the APIs libraries. Here we will give a brief overview of every part with detailed pages for each should you choose to learn more.

iMSTK architecture

Geometry

Geometries are used throughout iMSTK. The geometries themselves can be used standalone though. We have analytical, implicit, surface, volumetric, and image geometries.

Dynamical Models

Geometries are great. But you’re likely going to want to do something with it. The primary use case is to advance it in time via some dynamical model. In iMSTK we provide models for dynamic and static deformable/soft bodies, fluids, & rigid bodies. We include PBD, SPH, FEM, and Rigid Bodies.

Geometric Filtering

What else can you do with geometries? Filtering! Our filtering library provides a set of geometry algorithms we have found useful for surgical simulations.

Devices

Devices are an important part to iMSTK. This is an the interactive surgical simulation toolkit after all.

  • OpenVR: iMSTK, by default, builds with OpenVR. With a headset on, you may use OpenVR controllers for tools. See examples.

  • Mouse & Keyboard: These are provided under the same API as our other devices for convenience.

  • OpenHaptics: Allows one to use haptic tracking devices such as the Phantom Omni, these provide force feedback, under the right models we can stop your hand from moving when touching something, or give slight resistance.

  • Coming Soon: VRPN, Bluetooth, Arduino …

Controllers.

Controllers implement the controls of a device. We provide a couple of abstract base classes such as MouseControl, KeyboardControl, TrackingDeviceControl. As well as a few subclasses such as KeyboardSceneControl and MouseSceneControl which have some default behaviors such as stopping, starting, pausing a scene. But it’s heavily encouraged you to subclass your own. You may also use lambdas on the devices for fast prototyping.

Collision Detection

Collision detection can be standalone in iMSTK but often finds it use through Interactions, later described in Scene. Put simply, its the act of computing “CollisionData” from two geometries. Most of the time these are “contacts” such as point normal contacts which give a point, a normal, and penetration depth. Often these are then later given to constraints to be added to a dynamical model.

Collision Handling

Collision handling implements how to consume collision data. For this reason it takes input CollisionData which is generally shared with CollisionDetection. iMSTK provides a number of handling methods, generally these call upon the functions of a DynamicalModel to immediately respond (explicit solve) or add something (such as a constraint) to later implicitly solve.

Scene

A scene contains a flat collection of SceneObjects and can fully represent the virtual environment. These SceneObjects may be something like an OR table, a tissue, a leg, a light, or even non-visual objects. Additionally a scene contains a set of interactions via it’s InteractionGraph. A number of predefined InteractionPairs are available for iMSTK physics.

Mesh IO

Geometries are great. But to fully leverage them you need to be able to import from other tools which are much better at creating them. Read more about the files types supported by iMSTK. Additionally about Scene and SceneObject at the link above.

SimulationManager & Modules

Whilst scene’s define the virtual environment and how to update it. They don’t define how to drive it. You can certainly just call advance on the scene in a loop. That will get you decently far, but there’s a bit more too it than that.

Modules in iMSTK define something that can be init’d, update’d, and uninit’d and added to a ModuleDriver. In every iMSTK example you can simply add modules to our concrete ModuleDriver called the SimulationManager to run them. It defines a special way of updating them.

Rendering

Rendering in iMSTK is done through delegation to support multiple backends. This means we setup delegate classes for each thing we want to render. And map what we want to render to what the backend allows us to render. Primarily we use VTK.

Miscellaneous Topics

Parallelism

Goes over loop, task, and module parallelism in iMSTK.

Events

Goes over events. Direct and message queues.

Computational Flow

Goes over the flow/advancement of a scene.

Releases

Release 6.0.0

Announcement: iMSTK 6.0.0

On behalf of the iMSTK community, we are pleased to announce the release of iMSTK version 6.0. The Interactive Medical Simulation Toolkit (iMSTK) is an open-source toolkit that allows faster prototyping of surgical simulators and skill trainers. iMSTK features advanced high-performance libraries for physics simulation, haptics, advanced rendering/visualization, user hardware interfacing, geometric processing, collision detection, contact modeling, and numerical solvers.

Here is a comprehensive list of changes made for this release.

Andrew Wilson

Enhancements

Testing

Bugs

Documentation

Ben Boeckel

Enhancements

Harald Scheirich

Enhancements

Testing

Bugs

Documentation

Hong Li

Enhancements

Bugs

Jacob Moore

Enhancements

Testing

Jean-Christophe Fillion-Robin

Enhancements

Shreeraj Jadhav

Enhancements

Testing

Documentation

Api Changes

  • PbdModel::getParameters → PbdModel::getConfig

  • PbdModelConfig::enableConstraint now takes PbdModelConfig::ConstraintGenType uncoupling constraint generation schemes from constraint types.

    • ex: enableConstraint(PbdConstraint::Type::Distance, 1.0e2); -> enableConstraint(PbdModelConfig::ConstraintGenType::Distance, 1.0e2);

  • SimulationManager library split into SimulationManager, ViewerCore, & ViewerVTK. Linkage to ViewerVTK may be required in dependent projects should you require that library.

  • Rendering library split into RenderingCore & RenderingVTK.

  • GeometryMap`s, now extend `GeometryAlgorithm

    • OneToOneMap → PointwiseMap

    • TetraToTriangleMap → TetraToPointSetMap

    • OneToOneMap::getIdx → OneToOneMap::getParentId

    • GeometryMap::apply → GeometryMap::update

    • Geometry constructor inputs → GeometryMap::setParentGeometry & GeometryMap::setChildGeometry

    • GeometryMap::Type enum removed.

  • Many acronym’d names now Upper case first letter only. ie: PBD → Pbd. FEM → Fem. Previously had mixed usage.

  • PbdPickingCH removed/refactored into PbdObjectGrasping.

  • All barycentric functions moved to imstkMath.h

  • DataLogger removed

  • MeshToMeshBruteForceCD renamed to ClosedSurfaceMeshToMeshCD

  • All VTKOpenVR classes now VTKVR. ex: VTKOpenVRViewer → VTKVRViewer. Backend is unspecified in name. OpenXR by default.

  • IdentityMap removed.

  • Collision detection algorithm factory refactored. Get collision detection class by name with CDObjectFactory::makeCollisionDetection(“SurfaceMeshToCapsuleCD”);

  • VisualModel constructor input removed. Use VisualModel::setGeometry instead.

  • CollisionPair`s & `CollisionGraph removed. Use SceneObject’s added to the scene with Scene::addInteraction

  • A few occurrences of getTranslation & getRotation changed to getPosition & getOrientation when referring to a pose, not a transformation.

  • PhysX deprecated backend removed completely.

  • Only utilized VTK libraries are linked to, not every built VTK library. Any user facing VTK code may need to link to required libraries.

  • Update to C++14

  • Update to VTK 9.1

  • Update to TBB 2021.1.1

  • Update Eigen to 3.4

  • Update VRPN

Contributors: Andrew Wilson, Harald Scheirich, Shreeraj Jadhav, Jacob Moore, Jean-Christophe Fillion-Robin, Hong Li, Ben Boeckel

Release 5.0.0

Announcement: iMSTK 5.0.0

This release features major improvements to the collision detection and response capabilities, rendering, and hardware interface modules. Numerous refactors and bug fixes were made across the board to improve extensibility. The testing infrastructure and coverage was improved substantially. Numerous medically relevant examples were added. Most notably, v5.0 comes with a beta version of the C and C# wrappers for iMSTK along with documentation and examples.

Here is a comprehensive list of changes made for this release.

Andrew Wilson

Enhancements

  • Extended PBD model to allow needle-tissue interactions (07819c60)

    • PBDTissueSurfaceNeedleContact: Simple approach to needle insertion of deformable 2d triangle mesh tissue with rigid body haptics.

    • RbdSDFNeedle: Simple approach to needle insertion of static tissue for which a rigid body needle may rotate/pivot before being fully inserted.

    • PBDTissueVolumeNeedleContact: More involved approach to needle insertion of deformable tetrahedral mesh tissues with rigid body haptics. Uses two-way embedded coupling.

    • PBDStaticSuture: Suture thread and needle vs static geometry. Uses custom arc to point constraint. Suture thread non functional yet. Only surface constrained.

  • The collision detection architecture was comprehensively refactored and updated (ed212e8f)

    • PbdObject vs CollidingObject possible: PbdObject vs Rigid, SPH, FEM, any CollidingObject are now possible.

    • Pbd vs Primitives Collision: PbdCollisionConstraint’s and PbdCollisionHandler now use pointers and values instead of DataArray’s allowing collision between something that doesn’t have a vertex buffer.

    • PbdPointToEdgeConstraint: Allows mesh to curved surface collision when used together with point-to-point and point-to-triangle.

    • MeshToMeshBruteForceCD New Implementation: Able to resolve deep contacts in manifold shapes. Stable and accurate method, not performant for large meshes.

    • Virtual constraint addition for Pbd and Rbd models: Allows redefinition of contact response models. Used for needles, drills, thread holes, cutting, etc.

    • PbdRigidCollision interaction: Two-way collision between RigidObject2 and PbdObject. Gives response between both objects. (useful for haptics, no reaction force on the RigidObject2 is felt without it). See PBDTissueContactExample.

    • CollisionDebugObject: Can be added to the scene to display CollisionData as faces, edges, points, or directions/arrows.

    • SurfaceMeshToSphereCD: Triangle mesh to sphere collision. Demonstrated in PbdClothCollisionExample & RbdSurfaceMeshToSphereCDExample.

    • Restitution and friction added to PbdModel

  • Light properties can be changed at runtime, attenuation exposed (2d9a78c1)

  • Textures can now be setup via ImageData instead of filenames, swapped at runtime, & pixels modified at runtime (6e79fb81)

  • VisualModels can be added/remove from the scene at runtime. (f1e55106)

  • Camera now provides projection matrix and eye rays (bdbffbb8)

  • Added OrientedBox to geometry (replaces Cube) (845dd6c5)

  • PbdConstraintFunctor was added that allows customization of constraints generated for a PbdModel. (e3a9753f)

  • Added strides to PBD bending model. Bend constraints can now be generated for differing strides allowing stiffer threads/strings at lower iterations. (350adc5f)

  • Added RenderMaterial::ShadingModel::None allowing shading to be turned off where necessary (e7811080)

  • Added RenderMaterial::DisplayMode::Normals that displays normal directions using arrows (614e296e)

  • Added Texture Projection filter that projects attributes (eg: uv coords) via closest point projection (17fb7679)

  • Cell attributes were added to LineMesh (08b08212)

  • LineMeshes can be read in via VTK file type (6e20e88b)

  • SceneObject::visualUpdate virtual function is now called before every render for every SceneObject in the scene (fa95ff5f)

  • Added disposable syringe, orthopedic drill, c6 needle 3d models to the imstk data

  • Performance improvements to SPH (6a2bb089)

  • Performance improvements to Dense LSM (d2a2b88f)

  • Remove nonfunctional Pulse (3b41b3e1)

  • Remove nonfunctional Vulkan (5e7eddbc)

Documentation Updates

  • PbdModel documentation updated (6eb4a04a)

  • CollisionDetection documentation updated (2d9a78c1)

Testing

Harald Scheirich

Enhancements

  • VRPN Analog, Button and Tracker devices. No limit to VRPN in iMSTK anymore (co-authored by Khalil Oumimoun) (0f02a666)

  • Improved testing capabilities. Reduced overhead in testing infrastructure removing auto generated classes. (3059ffbe)

  • Added Git LFS-based external data management for data required by tests and examples. (7eb3d176)

  • Update gtest (a4d30ec5)

Documentation Updates

  • Improve C# Wrapper Documentation (28050bd3)

  • Added documentation for external Data and dependency update process (a4051249)

  • Added coding style guidelines (1f450dcf)

Testing

Sreekanth Arikatla

Enhancements

  • Remove plotter utils (5508d197)

  • Remove APIUtils (554cde05)

  • Cleanup Vulkan references and remove related external dependencies imgui, glm (d6cea42b)

  • Scene bounding box computation (458fa955)

Testing

Infrastructure

  • Enabled nightly readTheDocs build.

Jianfeng Yen

Enhancements

  • SWIG-based generation of C and C# wrappers along with C# examples and tests (See Source/Wrappers/csharp) (c11d712c)

  • Performance Improvements to FEM (c9f002ec)

Ye Han

Enhancements

  • Triangular mesh cutting via local remeshing (e7c01ead)

  • Added SurfaceMeshToCapsuleCD static collision method (42a321fb)

Khalil Oumimoun

Enhancements

  • VRPN Analog, Button and Tracker devices (0f02a666)

Aron Bray

Testing

  • Integration tests for rendering and geometry modules (96f084a1)

Hong Li

Enhancements

  • Extension of PBD Constraints to inflate tissue (3bf08161)

Furkan Dinc

Enhancements

  • Screen space ambient occlusion support (ab38797d)

Ben Boeckel

Infrastructure

  • Added Linux to the merge request builds

  • Fixed issue on the MSVC 2017 merge request build

Api Changes

  • PbdPointDirectionConstraint replaced with PbdPointToPointConstraint.

  • PbdCollisionConstraint::initConstraint now use VertexMassPair structs for initialization.

 PbdPointPointConstraint constraint;
 constraint.initConstraint(
     { vertexA, invMassA, vertexVelocityA },
     { vertexB, invMassB, vertexVelocityB },
     stiffnessA, stiffnessB);

- `PbdCollisionConstraint::projectConstraint` updated, accepts no parameters anymore as it uses pointer values provided during `PbdCollisionConstraint::initConstraint`.
- `PbdCollisionSolver::addConstraint` now only accepts a constraint, no buffers.

 std::vector<PbdCollisionConstraint*>* constraints;
 // ...Fill out constraints...
 myPbdCollisionSolver->addCollisionConstraints(constraints);

- `CollisionDetection` replaced with `CollisionDetectionAlgorithm`. Now subclasses `GeometryAlgorithm` with inputs given via `GeometryAlgorithm::setInput`.

 // Either order is ok (mesh, sphere) or (sphere, mesh)
 imstkNew<SurfaceMeshToSphereCD> collisionDetect;
 collisionDetect->setInput(mySurfMesh, 0);
 collisionDetect->setInput(mySphere, 1);
 collisionDetect->update();

 // Output order dependent on input order
 collisionDetect->getCollisionData()->elementsA; // CD elements for the mesh
 collisionDetect->getCollisionData()->elementsB; // CD elements for the sphere

- Collision interactions renamed, more consistent naming, removal of "Pair".
  - `PbdObjectCollisionPair` renamed to `PbdObjectCollision`.
  - `SphObjectCollisionPair` renamed to `SphObjectCollision`.
  - `RigidObjectLevelSetCollisionPair` renamed to `RigidObjectLevelSetCollision`.
  - `RigidObjectCollisionPair` renamed to `RigidObjectCollision`.
- `PbdObjectCollision` can now be constructed with both PbdObject+PbdObject or PbdObject+CollidingObject

imstkNew<PbdObjectCollision> interaction1(myPbdObjectA, myPbdObjectB);
imstkNew<PbdObjectCollision> interaction(myPbdObjectA, myCollidingObjectB);

- `RigidObjectCollision` can now be constructed with both RigidObject2+RigidObject2 or RigidObject2+CollidingObject

 imstkNew<RigidObjectCollision> interaction1(myRbdObjectA, myRbdObjectB);
 imstkNew<RigidObjectCollision> interaction(myRbdObjectA, myCollidingObjectB);

- `OrientedBox` should be used in place of `Cube`.

 Vec3d center = Vec3d(0.0, 0.0, 0.0);
 Vec3d extents = Vec3d(0.5, 0.5, 0.5); // Does not have to be a cube
 imstkNew<OrientedBox> box(center, extents);

- `RenderMaterial` now uses doubles, not floats.
- Removed Octree collision in `SurfaceMeshToSurfaceMeshCD`. The octree is still present but pending touch ups.
- `RigidBodyModel2` and corresponding classes moved from expiremental to main imstk namespace.
- `DebugRenderGeometry` replaced with `DebugGeometryObject`. Usage as follows:

 imstkNew<DebugGeometryObject> debugGeometryObj;
 scene->addSceneObject(debugGeometryObj);

 // Can be called anytime, normally during runtime
 debugTriangles->appendVertex(Vec3d(0.0, 1.0, 5.0), Color::Red);
 debugTriangles->appendLine(p1, p2, Color::Green);
 debugTriangles->appendArrow(p1, p2, Color::Orange);
 debugTriangles->appendTriangle(p1, p2, p3, Color::Blue);

- `DebugRenderDelegate`'s replaced with the already existing `RenderDelegate`'s.
- Removed Vulkan, Pulse, apiUtilities, imgui
- `NarrowPhaseCD` namespace functions moved and refactored into more general static intersection functions in `CollisionUtils`.
- Name was removed from the light class, light names are managed by the Scene

 imstkNew<DirectionalLight> light;
 light1->setFocalPoint(Vec3d(-1.0, -1.0, -1.0));
 light1->setIntensity(1.0);
 scene->addLight("light", light);

- Removed `Real`'s, use `double`'s instead.
- `RigidBodyModel` now optionally built, being deprecated in place of `RigidBodyModel2` as it's more extensible.
- `PBDModelConfig::m_defaultDt` removed, use `PBDModelConfig::m_dt` instead.
- `PBDModelConfig::m_collisionIterations` removed. Iterations can be set per collision solver, given per interaction.

 auto pbdHandler = std::dynamic_pointer_cast<PBDCollisionHandling >(interaction->getHandlerA());
 pbdHandler->getCollisionSolver().setCollisionIterations(5);

- `PbdModelConfig::enableBendConstraint` should be preferred when using bend constraints with varying strides. If `PbdModelConfig::enableConstraint(PbdConstraint::Type::Bend)` is used, stride will always be 1.
- `PbdModel::initializeConstraints` functions removed. Replaced with extensible `PbdConstraintFunctor`.
- `Texture` may also be constructed with an `ImageData`

 std::shared_ptr<ImageData> diffuseImage = MeshIO::read<ImageData>(iMSTK_DATA_ROOT "/textures/fleshDiffuse.jpg");
 material->addTexture(std::make_shared<Texture>(diffuseImage, Texture::Type::Diffuse));

- Enums removed in places were extensibility desired.
  - `Geometry::Type` removed. Use `Geometry::getTypeName()` instead.
  - `CollisionDetection::Type` removed. Use `CollisionDetectionAlgorithm::getTypeName()` instead.
  - `CollisionHandling::Type` removed. Use `CollisionHandling::getTypeName()` instead.

Contributors

Andrew Wilson Harald Scheirich Sreekanth Arikatla Jianfeng Yen Ye Han Khalil Oumimoun Aron Bray Hong Li Furkan Dinc Ben Boeckel Andinet Enquobahrie

Release 4.0.0

Announcement: iMSTK 4.0.0

This release features major improvements to the simulation execution pipeline, geometry module, virtual reality support, and haptics. Extensive refactoring and numerous bug fixes were also made across the codebase to allow extensibility of certain classes, improve clarity, separate roles for different iMSTK libraries, and enforce consistent design and conventions across the toolkit.

Here is a comprehensive list of changes made for this release.

New Features

  • Addition of Implicit Geometry

    • SignedDistanceField

    • CompositeImplicitGeometry

    • All existing analytical geometries

  • Addition of LevelSetModel (regular grids only)

  • Addition of ImplicitGeometryCD & ImplicitGeometryCCD

  • Addition of RigidBodyModel2

  • Addition of Event system (addition of EventObject)

  • Addition Imstk Data Arrays. DataArray+VecDataArray. Replacement throughout code.

  • Addition of per cell and vertex mesh attributes. DynamicalModels use them.

  • Addition of PBDPickingCH, for picking PBD vertices.

  • New Geometry Filters. Including LocalMarchingCubes.

  • Offscreen rendering support through VTK OSMesa

  • New substepping and sequential execution mode for SimulationManager

Improvements or Refactoring

  • SimulationManager and Module Refactor

  • Refactor VTKRenderDelegates

  • Topology changes supported

  • New examples. Many fixed haptics and OpenVR examples.

    • FemurCut

    • PBDPicking

    • SDFHaptics

    • FastMarch

    • RigidBodyDynamics2

    • PBDCloth-Remap

    • SPH-Obj-SDFInteraction

    • Vessel

  • imstkNew

  • Refactor geometry base class transforms

  • OpenVR, Keyboard, and Mouse Device Refactoring

  • Control refactoring

  • virtual update and visualUpdate functions for SceneObject

  • virtual init and advance functions for Scene

  • VRPN build toggle

  • Geometry enums replaced with getTypeName polymorphic function

  • DynamicalModel enums replaced with getTypeName polymorphic function

  • Module unit tests

  • VecDataArray + DataArray unit tests

  • NRRD, MHD, & NII image file support through VTK

  • Debug camera initializes to bounding box of initial scene

  • Bounding box computation of many primitives added

  • Laprascopic Tool Controller fixed + improved

  • VisualObjectImporter can now read and flatten scene hierarchies.

  • PBD performance improvements

  • HapticDeviceClient accepts no name for default device

  • ColorFunctions added to RenderMaterial for mapping scalars

  • imstkCamera refactor, view matrix can now be set independently of focal point and position.

  • VTKViewer split into VTKViewer and VTKOpenVRViewer, common base VTKAbstractViewer added.

  • Mute, log, or display VTK logger options added to VTKAbstractViewer

  • Shared RenderMaterials

Bug Fixes

  • Capsule CD fixes

  • OpenVR fixes

  • Missing bounding box functions for some analytical shapes added

  • Rigid body reset fixes

  • Many virtual destructors added

API Changes

  • OpenVR, Keyboard, and Mouse device refactoring: Mouse and Keyboard now provided under the same DeviceClient API as our haptic devices. You may acquire these from the viewer. They emit events, you can also just ask them about their state.

std::shared_ptr<KeyboardDeviceClient> keyboardDevice = viewer->getKeyboardDevice();
std::shared_ptr<MouseDeviceClient> mouseDevice = viewer->getMouseDevice();

std::shared_ptr<OpenVRDeviceClient> leftVRController = vrViewer->getVRDevice

  • Controls: Our controls are now abstracted. Any control simply implements a device. You may subclass KeyboardControl or MouseControl. We also provide our own default controls:

// Add mouse and keyboard controls to the viewer
imstkNew<MouseSceneControl> mouseControl(viewer->getMouseDevice());
mouseControl->setSceneManager(sceneManager);
viewer->addControl(mouseControl);

imstkNew<KeyboardSceneControl> keyControl(viewer->getKeyboardDevice());
keyControl->setSceneManager(sceneManager);
keyControl->setModuleDriver(driver);
viewer->addControl(keyControl);

connect<KeyEvent>(viewer->getKeyboardDevice(), &KeyboardDeviceClient::keyPress,
  sceneManager, [&](KeyEvent* e)
  {
    std::cout << e->m_key << " was pressed" << std::endl;
  });

  • Imstk Data Arrays: Data arrays and multi-component data arrays provided. They are still compatible with Eigen vector math.

VecDataArray<double, 3> myVertices(3);
myVertices[0] = Vec3d(0.0, 1.0, 0.0);
myVertices[1] = Vec3d(0.0, 1.0, 1.0);
myVertices[2] = myVertices[0] + myVertices[1];

std::cout << myVertices[2] << std::endl;

  • SimulationManager may now be setup and launched as follows:

// Setup a Viewer to render the scene
imstkNew<VTKViewer> viewer("Viewer");
viewer->setActiveScene(scene);

// Setup a SceneManager to advance the scene
imstkNew<SceneManager> sceneManager("Scene Manager");
sceneManager->setActiveScene(scene);
sceneManager->pause(); // Start simulation paused

imstkNew<SimulationManager> driver;
driver->addModule(viewer);
driver->addModule(sceneManager);
driver->start();

  • VisualObject typedef removed. Just use SceneObject.

  • HDAPIDeviceServer renamed to HapticDeviceManager

  • HDAPIDeviceClient renamed to HapticDeviceClient

Contributors

Andrew Wilson, Venkata Sreekanth Arikatla, Ye Han, Harald Scheirich, Bradley Feiger, Jianfeng Yan, Johan Andruejol, Sankhesh Jhaveri

Release 3.0.0

Announcement: iMSTK 3.0.0

This release features major improvements to the computational workflow, physics, and rendering aspects of the toolkit. Major refactoring and bug fixes were made across the board to allow easy extension of classes, improve clarity and separation of roles of different imstk libraries and enforce consistency of design across the toolkit.

Here is a comprehensive list of changes made for this release.

New Features

  • Introduction of configurable task-graph and task-based parallelism.

  • Major upgrade to the rendering module (VTK backend)

    • Upgrade to VTK 9.0

    • Realistic fluid rendering using screen space fluids

    • Faster particular rendering of fluids

    • Addition of physically based rendering

  • Addition of 3D image support and volume rendering

  • Improved physics models for particle based dynamics: Addition of extended position based dynamics (xPBD)

  • Addition of support for modeling 1D elastic structures with bending stiffness

  • Addition of faster reduced order deformation models (Linux only)

  • Addition of Reverse Cuthill–McKee algorithm (RCM) for mesh renumbering

  • Major refactoring simulation manager: Improved time stepping policies, multiple scene management and scene controls, addition of async simulation mode

  • Improved capabilities of the geometric utility module: addition of geometric processing filters, New tetrahedral mesh cover generation (based on ray-casting)

Improvements or Refactoring

  • Upgrade external dependency from Vega 2.0 to 4.0 (finite element library backend)

  • Clear majority of the warnings in imstk libraries

  • Refactored examples: consistent naming, factoring out object addition into separate functions, use heart dataset, remove redundant mapping, Removed line mesh example

  • New examples for scene management, volume rendering, task graph

  • Renamed files to be consistent with class names

  • Vulkan shader project removed for VTK backend

  • Remove imstkVolumetricMesh dependency on vega volumetric mesh

  • Easy configuration of finite element deformable object, viewer, renderer and simulation manager

  • Concrete dynamcal models now derive from AbstractDynamicalModel

  • Solvers are moved to models from scene

  • Added default solvers for models

  • SPHSolver is removed

  • SceneObject class now has update calls

  • DynamicalObject de-templatized

  • Fix render window default title to imstk

  • Replace external project download links with .zip versions

  • Uses CHECK() instead of LOF(FATAL)/LOG_IF(FATAL) for simplicity

  • imstkLogger is now a singleton

  • Allow exclusion of files while building library targets

  • Refactoring to use forward declarations where possible

  • Templated solvers with matrix type

  • Faster TetraToTriangle map

  • Interactions are now specified explicitly

  • PbdConstraints moved to Constraints library, PbdConstraints and PbdModel decoupled

  • PbdModel performance improvements

  • SPHModel performance improvements (using TaskGraph)

Bug Fixes

  • Fix PhysX backend build issues on Ubuntu

  • Fix imstkFind.cmake issues

  • Fix imstkConfig.cmake issues

  • PbdModel reset fix

  • All Scene, SceneObjects reset correctly now

API Changes

  • simulationManager::startSimulation() to simulationManager::start()

  • CollisionGraph::addInteraction(std::shared_ptr<CollidingObject>, std::shared_ptr<CollidingObject>, CollisionDetection::Type, CollisionHandling::Type, CollisionHandling::Type) to CollisionGraph::addInteraction(std::shared_ptr<SceneObjectInteraction>())

  • DynamicalModels now have default solvers

Contributors Venkata Sreekanth Arikatla, Andrew Wilson, Jianfeng Yan, Aaron Bray, Sankhesh Jhaveri, Johan Andruejol

Release 2.0.0

Announcement: iMSTK 2.0.0

This release adds major features for the physics and rendering modules. Parallel support is also added. Major improvements to the CMake build and install steps have been implemented. Many modules have been refactored for clarity and to reduce reducdency.

For more information, visit our website: http://www.imstk.org/

New Features

  • Rigid body dynamics with Physx backend

  • Debug rendering support

  • Octree-based collision detection

  • Multithreading support (using Intel TBB)

  • Smoothed Particle Dynamics for fluids

  • Customizable on-screen text

  • New simulation modes for simulation manager to allow flexibility

  • VR support for Vulkan backend

  • Particle systems for visual effects

  • Lens distortion for use in VR (Vulkan backend)

  • Vulkan renderer compressed texture support

Improvements or Refactoring

  • Improved CMake build and install

  • Enable compiler flags to report W4-level warnings

  • Remove cyclic dependencies between modules

  • Add color to stdout on windows

  • Refactored Position based dynamics classes

  • Refactor rendering specification using visual model

  • Modifications to the code formatting rules

  • Refactor geometry mapping classes

  • Remove unused files and classes

  • Disable building tests for external dependencies

  • Update the vrpn to the latest to fix linux build

  • Update VTK backend to 8.2.0

  • Remove ODE external library

Bug Fixes

  • Fix undefined behaviour of PBDModelConfig

  • Use vtkPolyData instead of vtkPolyLine for VTKdbgLinesRenderDelegate

  • Fix compilation with BUILD_EXAMPLES Off

Contributors for this release

Venkata Sreekanth Arikatla, Nghia Truong, Nicholas Boris Milef, Aaron Bray, Ruiliang Gao, Johan Andruejol

Release 1.0.0

Announcement: iMSTK 1.0.0

We are introducing Interactive Medical Simulation Toolkit (iMSTK)-a free & open source software toolkit written in C++ that aids rapid prototyping of interactive multi-modal surgical simulations.

For more information, visit our website: http://www.imstk.org/

Features

  • Cross-platform build

  • CMake automated superbuild

  • Test infrastructure (via google test)

  • Continuous Integration

  • Scene and simulation management

  • Vulkan and VTK rendering backends

  • Advanced rendering: Physically based rendering, Subsurface scattering, Decals, Shadows,

  • Graphical overlays (Vulkan backend only)

  • Standard user controls (pause, run, exit, pan-zoom-rotate)

  • SteamVR support including (Oculus, HTC Vive (VTK backend only)

  • Finite elements (linear, co-rotational, non-linear formulations)

  • Position based dynamics

  • Penalty and constraint-based collision handling

  • Linear solvers: Direct and Iterative matrix solvers

  • Non-linear Newton solver

  • Collision detection (CCD, Spatial hash based collision, narrow phase queries)

  • External device support (VRPN)

  • Support for standard mesh input formats (.obj, .dae, .fbx., .stl, .vtk, .vtu, etc.)

  • Asynchronous logging (using g3log)

  • Audio support

  • Haptic rendering (OpenHaptics)

Contributors for this release

Venkata Sreekanth Arikatla, Alexis Girault, Nicholas Boris Milef, Ricardo Ortiz, Thien Nguyen, Rachel Clipp, Mohit Tyagi, Samantha Horvath, Jean-Baptiste Vimort, Sean Radigan, David Thompson, Dženan Zukić, Mayeul Chassagnard, Tansel Halic, Hina Shah, Andinet Enquobahrie, Hong Li, Shusil Dangi

Apache License

Version

2.0

Date

January 2004

URL

http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

“License” shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

“Licensor” shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

“Legal Entity” shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, “control” means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

“You” (or “Your”) shall mean an individual or Legal Entity exercising permissions granted by this License.

“Source” form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

“Object” form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

“Work” shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

“Derivative Works” shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

“Contribution” shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, “submitted” means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as “Not a Contribution.”

“Contributor” shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

3. Grant of Patent License.

Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution.

You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

  • You must give any other recipients of the Work or Derivative Works a copy of this License; and

  • You must cause any modified files to carry prominent notices stating that You changed the files; and

  • You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

  • If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions.

Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks.

This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty.

Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability.

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability.

While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets “[]” replaced with your own identifying information. (Don’t include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same “printed page” as the copyright notice for easier identification within third-party archives.

Copyright 2018 iMSTK

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.