iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-01-07T01:07:53-05:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/298DataArray and VecDataArray are doing too many heap allocations2022-01-07T01:07:53-05:00Harald ScheirichDataArray and VecDataArray are doing too many heap allocationsBoth DataArray and VecDataArray are doing allocations/deletions in cases where its not necessary.
- `clear()` is implemented as `resize(0)` which not only deletes the current memory but additionally also allocates new memory of size 1
...Both DataArray and VecDataArray are doing allocations/deletions in cases where its not necessary.
- `clear()` is implemented as `resize(0)` which not only deletes the current memory but additionally also allocates new memory of size 1
This should probably be implemented as a constant time `m_size=0` without allocations
- `resize()` for any case where the new capacity is smaller than the existing capacity also allocates new memory, this should probably be implemented as just a simple change to `m_size`
A change here though would impact #297 maybe other systems that rely on the internal data pointer.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/209.dll copy issue when system build of a dependency is used2022-01-07T01:04:43-05:00Sreekanth Arikatla.dll copy issue when system build of a dependency is usedAt CMake configure time, if an existing build of the imstk dependent library is used, the .dll files are not copied to the bin folder where the executables reside post-build.At CMake configure time, if an existing build of the imstk dependent library is used, the .dll files are not copied to the bin folder where the executables reside post-build.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/389Archive Extraneous things from iMSTK Group2022-01-05T22:54:49-05:00Andrew WilsonArchive Extraneous things from iMSTK GroupThis is for discussion/reminder of things that should be removed.
Archive:
- [x] [libpthread](https://gitlab.kitware.com/iMSTK/libpthread): Unused as of JCs latest MR (https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/702)
- [x] [...This is for discussion/reminder of things that should be removed.
Archive:
- [x] [libpthread](https://gitlab.kitware.com/iMSTK/libpthread): Unused as of JCs latest MR (https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/702)
- [x] [gli](https://gitlab.kitware.com/iMSTK/gli): Unused, for reading images in Vulkan.
- [x] [ODE](https://gitlab.kitware.com/iMSTK/ODE): Unused
- [x] [imgui](https://gitlab.kitware.com/iMSTK/imgui): Unused
- [x] [VegaFEM-CMake4.0](https://gitlab.kitware.com/iMSTK/vegafemv4.0): There are two Vegas this one is not used as of (https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/702).
- [x] [SCCD](https://gitlab.kitware.com/iMSTK/SCCD): May be used in the future, but we could always just archive, unarchive later.
Achive (Not apart of iMSTK):
- [x] NeurosurgeryApp
- [x] [OMFSurgeryApp](https://gitlab.kitware.com/iMSTK/OMFSurgeryApp)
Unsure (potentially archive):
- [x] [MaterialEditor](https://gitlab.kitware.com/iMSTK/MaterialEditor)
- [ ] [imstk-feature-requests](https://gitlab.kitware.com/iMSTK/imstk-feature-requests)
- [x] [imstkCodeDoc](https://gitlab.kitware.com/iMSTK/imstk.gitlab.io)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/383Uncrustify Issues with Lambda's2021-12-24T12:30:51-05:00Andrew WilsonUncrustify Issues with Lambda'sUncrustify always formats lambda's like this:
```
connect<Event>(scene, &Scene::configureTaskGraph,
[&](Event*)
{
// Add a manual constraint after the pbd solve
scene->getTaskGraph()->...Uncrustify always formats lambda's like this:
```
connect<Event>(scene, &Scene::configureTaskGraph,
[&](Event*)
{
// Add a manual constraint after the pbd solve
scene->getTaskGraph()->insertAfter(pbdObject->getPbdModel()->getSolveNode(),
std::make_shared<TaskNode>([&]()
{
// Constrain the position of the 3 vertices of the triangle
// too their original locations
// Completely rigid, if there is jitter it will be very noticable
// We prented it fully converged as a distance constraint
(*pbdVerticesPtr)[0] = initPos[0];
(*pbdVerticesPtr)[1] = initPos[1];
(*pbdVerticesPtr)[2] = initPos[2];
}));
});
```
At the least I would hope it could align the braces of the lambda.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/388Add/Fix VR Controller Input2021-12-20T15:57:20-05:00Andrew WilsonAdd/Fix VR Controller InputVR controller input doesn't work astoundingly well through older versions of VTK. It reports some buttons with ids but not all work. Mostly just the triggers. With VTK 9.1 comes the introduction of json input files for mapping actions wh...VR controller input doesn't work astoundingly well through older versions of VTK. It reports some buttons with ids but not all work. Mostly just the triggers. With VTK 9.1 comes the introduction of json input files for mapping actions which is useful here. Eventually it'd be nice to have a more generic interface. But for now, this issue is just about getting the other buttons and thumbstick/trackpad of the controllers working.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/392TBB Upgrade2021-12-20T15:57:18-05:00Andrew WilsonTBB UpgradeTBB should be upgraded, at least soon after the VTK9.1 goes in so they can be on the same version. It hasn't appeared to cause any issues.TBB should be upgraded, at least soon after the VTK9.1 goes in so they can be on the same version. It hasn't appeared to cause any issues.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/382Upgrade VTK 9.12021-12-20T15:57:17-05:00Andrew WilsonUpgrade VTK 9.1Shouldn't be difficult to upgrade.
Ideally also expose the PBR clear coat material parameters in RenderMaterial. If used correctly could give a nice sheen to some tissues and make them look "wet" (specifically the ability to use fresnel...Shouldn't be difficult to upgrade.
Ideally also expose the PBR clear coat material parameters in RenderMaterial. If used correctly could give a nice sheen to some tissues and make them look "wet" (specifically the ability to use fresnel).
Also check:
- If the vtkXRenderWindowInteractor fixed (can we remove our patched implementation?).
- If shadows fixedhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/1Rename and create a namespace for iMSTK2021-12-17T02:13:51-05:00Sreekanth ArikatlaRename and create a namespace for iMSTKRicardo OrtizRicardo Ortizhttps://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.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/312Forthcoming list of TaskGraph Changes2021-12-13T16:17:50-05:00Andrew WilsonForthcoming list of TaskGraph ChangesAgglomerating a list of minor TaskGraph changes we should make. Whilst it fits extremely well into imstk there's some changes needed.
- CollisionDetection should not have a TaskNode, it should be decoupled from this. Rather the "interac...Agglomerating a list of minor TaskGraph changes we should make. Whilst it fits extremely well into imstk there's some changes needed.
- CollisionDetection should not have a TaskNode, it should be decoupled from this. Rather the "interaction" that defines the permutation on the pipeline should provide this node.
- CollisionHandling should also not have a TaskNode for the same reason.
- Interactions should just be SceneObjects and should have a separable TaskGraph. Because all SceneObject TaskGraphs are summed. Currently the interaction nodes are inserted into each SceneObjects subgraph separately, then summed into the final scene task graph. If interactions defined their own graphs, as long as nodes from both objects interacting exist in this graph, they will join when summed into the final graph. This nicely decouples the interactions and SceneObjects.
- CollisionPair might be able to be removed
- A more atomic expression for permuting the task graph should be provided. Like a graph functor or something. Interactions could use these. For instance, I could technically make an "InsertableNode" which defines a preceding node->inserted node->succeeding node, just 3 nodes. Everything can be broken down sets of insertables. When summed they form a final graph.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/381CodeFormatEnforcer Failing2021-11-19T22:58:28-05:00Andrew WilsonCodeFormatEnforcer FailingAgain uncrustify is reporting fail, but not actually correcting anything when run.Again uncrustify is reporting fail, but not actually correcting anything when run.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/356Inconsistent Nomenclature with regards to position and orientation2021-11-18T08:35:56-05:00Harald ScheirichInconsistent Nomenclature with regards to position and orientationGeometry:
`translation`, `rotation`
RigidBody:
`position`, `orientation`
Controller:
`position`, `rotation`
Can we agree on a set of these ?Geometry:
`translation`, `rotation`
RigidBody:
`position`, `orientation`
Controller:
`position`, `rotation`
Can we agree on a set of these ?https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/380Invert Rotation Issues2021-11-17T18:41:01-05:00Andrew WilsonInvert Rotation IssuesIn Unity we have LHS instead of RHS used in imstk & opengl. Requiring inverting of the positions and orientations of a controller.
Currently inverting orientations does not work in imstk.
While invert Y is on take a tool (such as sciss...In Unity we have LHS instead of RHS used in imstk & opengl. Requiring inverting of the positions and orientations of a controller.
Currently inverting orientations does not work in imstk.
While invert Y is on take a tool (such as scissors, syringe, or needle) pointing down z. Rotate 90deg around global y. Then rotate 90deg around global x. You will see the incorrect orientation.
![_output001_2021-11-11_22-08-00__2_](/uploads/b66e796326739b6279e32fc3e75ab95c/_output001_2021-11-11_22-08-00__2_.gif)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/378ReadTheDocs build Failing2021-11-10T16:20:38-05:00Harald ScheirichReadTheDocs build Failinghttps://readthedocs.org/projects/imstk-unity/builds/15156193/
See also
https://github.com/readthedocs/readthedocs.org/issues/8616https://readthedocs.org/projects/imstk-unity/builds/15156193/
See also
https://github.com/readthedocs/readthedocs.org/issues/8616Harald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/374compile error, openhaptics2021-11-04T10:42:19-04:00xianger-qicompile error, openhapticsi want to run the example: FemurCut , so i install the openhaptics and geomagic_touch_device_driver, in the “/opt/openhaptics” and “opt/geomagic_touch_device_driver”, then i change cmake variable “iMSTK_USE_OpenHaptics” to “ON” and run c...i want to run the example: FemurCut , so i install the openhaptics and geomagic_touch_device_driver, in the “/opt/openhaptics” and “opt/geomagic_touch_device_driver”, then i change cmake variable “iMSTK_USE_OpenHaptics” to “ON” and run cmake …/iMSTK. The terminal print error “cant find openHaptics”
![Screenshot_from_2021-10-08_23-40-57](/uploads/91afb698c5966f377cea9363f8c0ae93/Screenshot_from_2021-10-08_23-40-57.png)![Screenshot_from_2021-10-08_23-41-22](/uploads/63b73a9eb963ab9cbf8412a101848753/Screenshot_from_2021-10-08_23-41-22.png)
how can i fix that?https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/365Some VTK Models can't be converted2021-10-27T09:42:40-04:00Harald ScheirichSome VTK Models can't be converted`copyToPolyData(mesh)` fails with
```
2021/09/01 09:36:59 10949845 CONTRACT [imstkGeometryUtilities.cpp->copyToVtkDataArray:139]
******* EXIT trigger caused by broken Contract: CHECK(imstkArray != nullptr)
"AbstractDataArray provid...`copyToPolyData(mesh)` fails with
```
2021/09/01 09:36:59 10949845 CONTRACT [imstkGeometryUtilities.cpp->copyToVtkDataArray:139]
******* EXIT trigger caused by broken Contract: CHECK(imstkArray != nullptr)
"AbstractDataArray provided is not valid!
******* STACKDUMP *******
```
on some `.vtk` filesHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/369Khronos ML summit2021-10-22T21:18:45-04:00pierre boudierKhronos ML summitHello,
I am the chair of a working group at Khronos developing standards for graphics and compute hardware accelerators (as well as a representative for Nvidia in those groups).
We are organizing a summit to gather feedback from the ec...Hello,
I am the chair of a working group at Khronos developing standards for graphics and compute hardware accelerators (as well as a representative for Nvidia in those groups).
We are organizing a summit to gather feedback from the ecosystem, and influence the design of the next round of improvements, and I thought that you may be interested in being represented:
https://www.khronos.org/events/2021-invitation-to-the-khronos-machine-learning-summit
This summit is IP free, and will let you present your project and your needs for improvements in the ML ecosystem, as well as hearing from other companies.
regards,
Pierre Boudier
Software architect at Nvidia
chair of the Machine Learning TSG at Khronoshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/362Transition to Default Adaptive Stepping2021-10-11T15:36:51-04:00Andrew WilsonTransition to Default Adaptive SteppingBy default we use parallel rendering and scene updates. So if you just setup a SceneManager and Viewer this is the behavior you get. The good majority of newer examples use adaptive and have the extra line: `sceneManager->setExecutionTyp...By default we use parallel rendering and scene updates. So if you just setup a SceneManager and Viewer this is the behavior you get. The good majority of newer examples use adaptive and have the extra line: `sceneManager->setExecutionType(Module::ExecutionType::ADAPTIVE);`.
Ideally adaptive is default and the user doesn't have to add this extra line (worse they forget). The reason adaptive should be default is that many things "just work" when using the sequential nature of the adaptive mode. Because:
- It's very easy to make mistakes, especially if you didn't know you were running them in parallel and you caused a race condition or something.
- The adaptive mode has more consistency across machines. Generally running on anything faster than what the simulation was tuned for will result in roughly the same simulation. This has been very helpful.
Transitioning every example to parallel is tricky as many physics parameters need reparameterization. What we can do though is make ADAPTIVE default and then go through every example and use sceneManager->setExecutionType(Module::ExecutionType::PARALLEL); And then eventually try to transition the parallel ones to adaptive.
Side Note: I am not prepared to completely removed parallel due to the high performance requirements of some simulators. It really depends on the program. If the scene itself is well parallelized, then running rendering and scene updates in parallel makes little difference. But in a number of programs it can make a decent difference.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/373CMake Tells Project Files May be Invalid2021-10-07T18:28:26-04:00Zhiqi MaoCMake Tells Project Files May be InvalidI am trying to install iMSTK to my computer, and CMake tells me that Error in configuration process, project files may be invalid.
I have used Visual Studio 15 2017 and Visual Studio 16 2019 as generator.
I also tried use Visual Studi...I am trying to install iMSTK to my computer, and CMake tells me that Error in configuration process, project files may be invalid.
I have used Visual Studio 15 2017 and Visual Studio 16 2019 as generator.
I also tried use Visual Studio Enterprise 2019 to direct build the iMSTK.sln, however, it tells me the following error message
Severity Code Description Project File Line Suppression State
Error CMake Error:
Running
'C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/Common7/IDE/CommonExtensions/Microsoft/CMake/Ninja/ninja.exe' '-C' 'H:/iMSTK/out/build/x64-Debug' '-t' 'recompact'
failed with:
ninja: error: build.ninja:958: bad $-escape (literal $ must be written as $$) H:\iMSTK\ ninja
I currently have CMake version 3.20.5, git version2.33.0.windows.2, and git lfs/2.13.3
Can someone help me resolve this problem?