iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2021-06-01T15:01:19-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/219Using file types besides .veg in virtually coupled collisions2021-06-01T15:01:19-04:00Jonathon ScheningUsing file types besides .veg in virtually coupled collisionsWe have been unable to use .obj or .3ds files in the bone drilling example (by directly redefining the mesh) or in the virtual coupling example ( by bringing in our mesh by the same method and attempting point set to sphere collisions. P...We have been unable to use .obj or .3ds files in the bone drilling example (by directly redefining the mesh) or in the virtual coupling example ( by bringing in our mesh by the same method and attempting point set to sphere collisions. Please advise
auto heartMesh = MeshIO::read(iMSTK_DATA_ROOT"/baby/red_heart.3ds");
auto heartObject = std::make_shared<CollidingObject>("meshObject");
heartObject->setVisualGeometry(heartMesh);
heartObject->setCollidingGeometry(heartMesh);https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/253Add data visualizer for the collision data2021-01-08T18:15:11-05:00Sreekanth ArikatlaAdd data visualizer for the collision datahttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/110Optionally run controllers in a separate thread2020-11-19T03:15:46-05:00Sreekanth ArikatlaOptionally run controllers in a separate threadAt present the simulationManager runs controllers (including virtual coupling objects), collision detection, collision handling and solvers in a sequential fashion. For a scene where the solvers take more time the object controllers are ...At present the simulationManager runs controllers (including virtual coupling objects), collision detection, collision handling and solvers in a sequential fashion. For a scene where the solvers take more time the object controllers are called at a low frame rate leading to objects not responsive to the user movements. One option is to run the each controller in a separate module.
Whether the controllers are run in a separate thread within scene manager or a separate module they need to be synchronized for collision detection, handling and computation of forces.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/31Integrate SMTK2020-11-14T02:25:46-05:00Ricardo OrtizIntegrate SMTKI foresee a tight integration between simmedtk and smtk. SMTK will be used for setting all parameter in the simulator (including Vega parameters)I foresee a tight integration between simmedtk and smtk. SMTK will be used for setting all parameter in the simulator (including Vega parameters)Ricardo OrtizRicardo Ortizhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/30Integrate CCD2020-11-14T02:25:46-05:00Ricardo OrtizIntegrate CCDIntegrate SCCD from UNC into the framework.
This first decoupled implememtation will build the CCD library in the superbuild and link against it.
A more tight implementation will follow.
https://gitlab.kitware.com/SimMedTK/SCCDIntegrate SCCD from UNC into the framework.
This first decoupled implememtation will build the CCD library in the superbuild and link against it.
A more tight implementation will follow.
https://gitlab.kitware.com/SimMedTK/SCCDRicardo OrtizRicardo Ortizhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/29LCP Solver for Contact Response2020-11-14T02:25:46-05:00Ricardo OrtizLCP Solver for Contact ResponseLinear Complementarity Problem (LCP) based solver for collision response.
1. Projected Gauss Seidel
2. Newton-Raphson Method
3. Non-linear Conjugate Gradient
http://image.diku.dk/kenny/download/vriphys10_course/lcp.pdfLinear Complementarity Problem (LCP) based solver for collision response.
1. Projected Gauss Seidel
2. Newton-Raphson Method
3. Non-linear Conjugate Gradient
http://image.diku.dk/kenny/download/vriphys10_course/lcp.pdfhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/28Separate Assembler and Solvers form Scene Objects2020-11-14T02:25:46-05:00Ricardo OrtizSeparate Assembler and Solvers form Scene ObjectsAt present the scene object class handles (a) internal force computation (b) assembly (c) solver. According to the design, assembly and solver part of the code should be separate modules in the framework.
The assembler should be able...At present the scene object class handles (a) internal force computation (b) assembly (c) solver. According to the design, assembly and solver part of the code should be separate modules in the framework.
The assembler should be able to:
+ determine the type of assembly that is required based on the type of objects
+ Number of sub-systems that has to be formed based on the collision contexthttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/26Haptic Rendering2020-11-14T02:25:46-05:00Ricardo OrtizHaptic RenderingTool coupler should take care of implementing haptic response and rendering according to the type of tools it is attached to.
[Basic introduction](http://jks-folks.stanford.edu/papers/Haptic-Rendering.pdf)
[Virtual Tool Coupler](ht...Tool coupler should take care of implementing haptic response and rendering according to the type of tools it is attached to.
[Basic introduction](http://jks-folks.stanford.edu/papers/Haptic-Rendering.pdf)
[Virtual Tool Coupler](https://books.google.com/books?id=TlfMBQAAQBAJ&pg=SA23-PA8&lpg=SA23-PA8&dq=virtual+tool+coupler&source=bl&ots=oO7aO3OInv&sig=EOD9nD4x0uSpU60U4YEm4PXRXFg&hl=en&sa=X&ved=0CB8Q6AEwAGoVChMI7fCK8d7YxgIVhFeSCh3fnQTQ#v=onepage&q=virtual%20tool%20coupler&f=false)
[God object method for point haptic interaction](http://web.engr.illinois.edu/~zilles/papers/iros.pdf)
[God object method for 6-dof haptic](http://cs.uccs.edu/~ssemwal/CS677/Haptic_01667644.pdf)Ricardo OrtizRicardo Ortizhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/25Implement New Rendering Interfaces2020-11-14T02:25:45-05:00Ricardo OrtizImplement New Rendering InterfacesImplement rendering interface to connect SimMedTK to the new rendering engine.
Implementation will depend on the rendering engine chosen but these are requirements on the design:
1. The design should abstract the interface so that m...Implement rendering interface to connect SimMedTK to the new rendering engine.
Implementation will depend on the rendering engine chosen but these are requirements on the design:
1. The design should abstract the interface so that most communication occurs at a higher levels in the hierarchy.
2. Should allow for external renderers to be plug in to the library.
Issues #4 and #12 come under this
Sprint IRicardo OrtizRicardo Ortizhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/24Refactor Haptic Interfaces2020-11-14T02:25:45-05:00Ricardo OrtizRefactor Haptic InterfacesRefactor the haptic interface by creating a hierarchy can can be reused by other devices.
Device->OmniDevice
The implementation of the omni device will use a pimpl idiom to contain the actual implementation of the communication lay...Refactor the haptic interface by creating a hierarchy can can be reused by other devices.
Device->OmniDevice
The implementation of the omni device will use a pimpl idiom to contain the actual implementation of the communication layer. All implementations go in the cpp file.
```c++
class PhantomDevice : public Device
{
public:
// Constructor
OmniDevice();
// Destructor
~OmniDevice();
// Initialize device
void init();
// Shutdown device
void shutdown();
...
private:
class PhantomOmni;
std::unique_ptr<PhantomOmni> phantomOmni;
};
```
The Device base class will be inherited by all devices and will manage the actual input/output data coming in and out of the device, something like this:
```c++
class Device
{
public:
// Constructor
Device(const std::string &deviceName);
// Destructor
~Device();
private:
// Vectors
std::vector<smVec3d> vectors;
...
};
```
+ Related to issue #20 Ricardo OrtizRicardo Ortizhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/22Standardize error handling across the framework2020-11-14T02:25:45-05:00Sreekanth ArikatlaStandardize error handling across the frameworkRelease 1.0.0https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/21standardize and enable user controlled articulated objects2020-11-14T02:25:45-05:00Sreekanth Arikatlastandardize and enable user controlled articulated objectsex. laparoscopic toolsex. laparoscopic toolshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/20Standardize and enable phantom omni interface2020-11-14T02:25:45-05:00Sreekanth ArikatlaStandardize and enable phantom omni interfaceSprint ISean RadiganSean Radiganhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/19Create a macro to export symbols when building library in windows.2020-11-14T02:25:45-05:00Sreekanth ArikatlaCreate a macro to export symbols when building library in windows.Release 1.0.0Ricardo OrtizRicardo Ortizhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/18Create generic Controller interfaces2020-11-14T02:25:45-05:00Sreekanth ArikatlaCreate generic Controller interfacesCreate interfaces so that is "easy" to add future *Controllers* to the library.
Some exmaples of external FE libraries:
+ [Feel++](http://www.feelpp.org/)
+ [GetDP](http://www.geuz.org/getdp/)(good [intro](http://www.ankitsrivastava....Create interfaces so that is "easy" to add future *Controllers* to the library.
Some exmaples of external FE libraries:
+ [Feel++](http://www.feelpp.org/)
+ [GetDP](http://www.geuz.org/getdp/)(good [intro](http://www.ankitsrivastava.net/2013/09/gmsh-and-getdp/) to getDP)
+ MBD
+ Fluids solversRicardo OrtizRicardo Ortizhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/17Add asyncronous event sending into the framework2020-11-14T02:25:45-05:00Sreekanth ArikatlaAdd asyncronous event sending into the frameworkIt looks like when we transitioned from the internal SoFMIS code, the asynchronous event mechanism was not transferred. It simply needs to be added back into the framework.
It looks like when we transitioned from the internal SoFMIS code, the asynchronous event mechanism was not transferred. It simply needs to be added back into the framework.
https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/14Standardize shader and texture management!2020-11-14T02:25:44-05:00Sreekanth ArikatlaStandardize shader and texture management!tanseltanselhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/12Update rendering to use the latest OpenGL standard2020-11-14T02:25:44-05:00Sreekanth ArikatlaUpdate rendering to use the latest OpenGL standardThe code has many legacy OpenGL calls, this costs the framework rendering speed, causes confusion for users, and causes incompatibility with other libraries like Oculus (Oculus' SDK rendering changed, so no longer an issue)
1. This ta...The code has many legacy OpenGL calls, this costs the framework rendering speed, causes confusion for users, and causes incompatibility with other libraries like Oculus (Oculus' SDK rendering changed, so no longer an issue)
1. This task would greatly improve performance: Implement a VBO for storage of vertex data on the GPU for any rendered meshes (this might be just smSurfaceMeshes, not sure though).
2. Create default pass-through vertex and fragment shaders for objects that won't require custom shaders for rendering
3. Remove all fixed pipeline OpenGL code, and force a shader style rendering that takes MVP matricesRelease 1.0.0Sean RadiganSean Radiganhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/9SimMedTK Configuration file(s)2020-11-14T02:25:44-05:00Sreekanth ArikatlaSimMedTK Configuration file(s)Discuss and finalize the items for config files for SMTK.
Implement the finalized planDiscuss and finalize the items for config files for SMTK.
Implement the finalized planRelease 2.0.0https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/5Enable the rest of the examples2020-11-14T02:25:44-05:00Sreekanth ArikatlaEnable the rest of the examplesRelease 1.0.0