iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-06-02T01:22:31-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/430Shape Matching2022-06-02T01:22:31-04:00Andrew WilsonShape MatchingShape matching can be used globally, locally, or for plasticity.
Shape Matching and moreso Local Shape Matching (see [A Survey on Position Based Dynamics, 2017](http://mmacklin.com/2017-EG-CourseNotes.pdf))Shape matching can be used globally, locally, or for plasticity.
Shape Matching and moreso Local Shape Matching (see [A Survey on Position Based Dynamics, 2017](http://mmacklin.com/2017-EG-CourseNotes.pdf))https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/425Macro style cleanup2022-05-26T08:45:09-04:00Harald ScheirichMacro style cleanupiMSTK uses a variety of macros, only a some of them use a prefix `IMSTK` as macros are global this may cause clashes with software packages (e.g. `LOG` and `CHECK`), some macros are unused or rarely used and could be removed (`imstkGetMa...iMSTK uses a variety of macros, only a some of them use a prefix `IMSTK` as macros are global this may cause clashes with software packages (e.g. `LOG` and `CHECK`), some macros are unused or rarely used and could be removed (`imstkGetMacro`, `imstkSetMacro`)
- [ ] Remove Superflous macros
- [ ] prefix all macros with `IMSTK`https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/424More aggressive checking on nullptr parameters and incorrect types2022-05-26T08:40:54-04:00Harald ScheirichMore aggressive checking on nullptr parameters and incorrect typesiMSTK passes a lot of parameters as `std::shared_ptr` of the super type, in various places the (e.g. all geometry filter) subclasses these parameters need to be of specific types otherwise the filter will not run. In a lot of cases this ...iMSTK passes a lot of parameters as `std::shared_ptr` of the super type, in various places the (e.g. all geometry filter) subclasses these parameters need to be of specific types otherwise the filter will not run. In a lot of cases this is checked only on executing the filter and is the only reported with a warning on the console while the the rest of the software keeps running. This can make it hard to detect failures especially with new users.
In general we should `CHECK` for the correct type of input parameters whenever a polymorphic type is received in a function call (this will also automatically check for nullptr)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/423Add wording with regards to Openhaptics license2022-05-24T11:05:54-04:00Harald ScheirichAdd wording with regards to Openhaptics licensehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/422Examples Website2022-06-01T15:58:24-04:00Andrew WilsonExamples WebsiteThis tends to be the first point of contact for many with VTK https://kitware.github.io/vtk-examples/site/Cxx/ . https://kitware.github.io/vtk-examples/site/Cxx/
It would not be too hard to add a script that adds a description + a pictu...This tends to be the first point of contact for many with VTK https://kitware.github.io/vtk-examples/site/Cxx/ . https://kitware.github.io/vtk-examples/site/Cxx/
It would not be too hard to add a script that adds a description + a picture + code to an html webpage for iMSTK.
See https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/.gitlab-ci.yml . Simply call the script to generated html, then move it to the public/ directory and it will be hosted.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/416C++17 Support2022-06-18T01:03:38-04:00Andrew WilsonC++17 SupportNow that FTD2XX has been removed this should be easier. Running the build (without testing, examples, openhaptics, vrpn) I get errors only in:
- Assimp (ours is very out of date, latest assimp does support c++17)
- SFML (latest SFML do...Now that FTD2XX has been removed this should be easier. Running the build (without testing, examples, openhaptics, vrpn) I get errors only in:
- Assimp (ours is very out of date, latest assimp does support c++17)
- SFML (latest SFML does support, easy update since we don't wrap any of its API at the moment)
- VegaFEM (Would have to make our own commits to our fork to fix it)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/410Shared Libraries2022-05-12T22:24:02-04:00Andrew WilsonShared LibrariesA number of attempts over the years have been made to produce shared libraries for iMSTK. I'm adding this issue here moreso to document its difficulty from experience of trying it, not so much to suggest it should be done. If one wanted ...A number of attempts over the years have been made to produce shared libraries for iMSTK. I'm adding this issue here moreso to document its difficulty from experience of trying it, not so much to suggest it should be done. If one wanted to it would require huge changes.
1.) iMSTK exposes a significant amount of members from dependent libraries. Namely template ones such as the STL & Eigen. These libraries do not export classes as they are template libraries. You cannot export a class you do not even know the size of. So anywhere something like std::vector<int> appears in a public or protected interface we have a problem. Solutions:
- Export a specialization of the template class, ie: export std::vector<int>. This then locks in the ABI/binary interface (and things like size). Also presents dangers if you took it to another system whose ABI was different, for instance int was not the same size.
- Hide members that you can. By using pimpl where possible or make private and hide warning.
- Wrap the member class & export wrapped interface.
- Provide alternative method for passing if it just appears in a function (for ex: double* instead of a Vec2d).
2.) Singletons & statics. iMSTK has Logger as singleton & a few statics for ids. The concept of these get tricky when you think about a library that can be loaded at runtime, particular on windows for which the library can literally be shared. When should we create a second instance of the logger? When should we use the existing one?
- Conversely we have an issue if you try to link iMSTK (statically built) into two separate dll's. Then use both those dll's. You may experience issues regarding its singleton and statics.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/408Move Examples To Unit Tests2022-06-02T15:33:56-04:00Andrew WilsonMove Examples To Unit TestsA number of examples we have don't serve well as examples. As we gain more medically relevant examples, these are become less useful to have here. In particular, none of these are interactive.
- [x] RCM
- [x] FastMarch
- [ ] Geometry...A number of examples we have don't serve well as examples. As we gain more medically relevant examples, these are become less useful to have here. In particular, none of these are interactive.
- [x] RCM
- [x] FastMarch
- [ ] GeometryTransforms
- [ ] GeometryProcessing
- [ ] ObjectControllerDummyClient
- [ ] Audio
- [ ] ConvertVTKToVega
- [x] TaskGraph
- [ ] TaskGraphTiming
- [ ] TaskGraphConfigure
- [ ] CreateEnclosingMesh
- [ ] OctreeIntersection
- [x] PbdClothCollision
Additionally examples take the longest amount of time in the imstk build so cutting down on them is nice (note tests tend to share binaries resulting in slightly faster builds). It's also nice to provide a set of concise & convincing examples.Andinet enquobahrieAndinet enquobahriehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/405Unable to build from solution file: Visual Studio MSB8066 error2022-03-20T18:37:02-04:00sahilkamathUnable to build from solution file: Visual Studio MSB8066 errorI am trying to build the solution in a Windows system using cmake and Visual Studio 17.1.1. After following the instructions for cmake-gui, I tried to build the iMSTK.sln file (ALL_BUILD target) and got MSB8066 error. I have attached the...I am trying to build the solution in a Windows system using cmake and Visual Studio 17.1.1. After following the instructions for cmake-gui, I tried to build the iMSTK.sln file (ALL_BUILD target) and got MSB8066 error. I have attached the log files which I think are relevant. The Innerbuild folder is empty.
What am I doing wrong?
Thank you for your consideration.
[iMSTK.log](/uploads/47970effc2abdcee97726c5e174ba0a0/iMSTK.log)
[CMakeOutput.log](/uploads/0c3e3b757eb4b850de5f782794fbbb61/CMakeOutput.log)
[CMakeError.log](/uploads/6949e225e1ecd8f71615dcb8153c68ed/CMakeError.log)
[CMakeError__1_.log](/uploads/0627f4ee32a0edc2cc67c490b2061997/CMakeError__1_.log)
[CMakeOutput__1_.log](/uploads/d10d0bfd348ebf12e377d4787b419609/CMakeOutput__1_.log)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/391Assimp 5.1.4 Upgrade2022-06-01T17:28:30-04:00Andrew WilsonAssimp 5.1.4 UpgradeLooks like Assimp went through some bugfixes recently including support for the latest blender file type (big blend changes over 2.8-2.9) this could greatly improve workflow (at least for prototyping things quickly). Hopefully some other...Looks like Assimp went through some bugfixes recently including support for the latest blender file type (big blend changes over 2.8-2.9) this could greatly improve workflow (at least for prototyping things quickly). Hopefully some other things are ironed out now that v5.0 is more mature as there are many file type bugs. Especially when you get into the nitty gritty details of something like animation.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/390PbdTissueSurfaceNeedleExample Needs Custom Tangents or Split Faces2022-06-01T16:25:04-04:00Andrew WilsonPbdTissueSurfaceNeedleExample Needs Custom Tangents or Split FacesThe sharp edges & natural typical approach to computing tangents leads to bad tangents on the edges of the tissue block we use in these examples which causes the texture to lighten on the sides. Solution would be to just split the mesh u...The sharp edges & natural typical approach to computing tangents leads to bad tangents on the edges of the tissue block we use in these examples which causes the texture to lighten on the sides. Solution would be to just split the mesh up on those sharp edges.
![image](/uploads/9c3d29b220cb5bd28764c761a0ef4d90/image.png)https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/387SurfaceMeshToMeshCD2022-06-01T16:15:39-04:00Andrew WilsonSurfaceMeshToMeshCDWe currently have ClosedSurfaceMeshToMeshCD. This only works for closed surfaces. It is good for deep contacts.
We do not have the more traditional SurrfaceMeshtoMeshCD, which only locally gives resolution. IE: It checks intersection be...We currently have ClosedSurfaceMeshToMeshCD. This only works for closed surfaces. It is good for deep contacts.
We do not have the more traditional SurrfaceMeshtoMeshCD, which only locally gives resolution. IE: It checks intersection between all the elements (triangles or lines). Then computes resolutions of those elements. The hope being that only small overlaps occur at small dts and if deep contacts happen they would eventually resolve (objects could get stuck). The pro of this method is that it is easily spatially partitioned whereas ClosedSurfaceMeshToMeshCD is not as it tries to find global resolution.
This is usually done with a clipping method. Such method can be found in Bullet or ODE.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/385Uncrustify Linux Support2022-06-02T19:35:42-04:00Andrew WilsonUncrustify Linux SupportI believe linux users currently have to manually run uncrustify with the list file rather than using the target.
`./install/bin/uncrustify
--replace --no-backup -c
../iMSTK/Utilities/Uncrustify/iMSTKUncrustify.cfg -F
Innerbuild/uncrusti...I believe linux users currently have to manually run uncrustify with the list file rather than using the target.
`./install/bin/uncrustify
--replace --no-backup -c
../iMSTK/Utilities/Uncrustify/iMSTKUncrustify.cfg -F
Innerbuild/uncrustify.list`
Note: Uncrustify has an issue where it reports the incorrect file as failing in some cases with list files. A bat file is used on windows to recursively do it individually.Andinet enquobahrieAndinet enquobahriehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/377Consolidate CMake2022-04-10T20:01:27-04:00Andrew WilsonConsolidate CMake - [x] Consolidate usage of GLOB or no GLOB
- [ ] Consolidate tabs or 2 spaces
- [ ] Consolidate all uppercase options or not
- [ ] Consolidate usage of ${PROJECT_NAME} or not
There's mixed usage of these things in iMSTKs cmake which... - [x] Consolidate usage of GLOB or no GLOB
- [ ] Consolidate tabs or 2 spaces
- [ ] Consolidate all uppercase options or not
- [ ] Consolidate usage of ${PROJECT_NAME} or not
There's mixed usage of these things in iMSTKs cmake which makes it confusing to work with.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/376Move CreateEnclosingMesh To an imstkGeometryAlgorithm/filter2021-11-19T22:58:45-05:00Andrew WilsonMove CreateEnclosingMesh To an imstkGeometryAlgorithm/filterAs the title states, this somewhat large operation is sitting in a static function in GeometryUtilities. It's actually a set of functions in an attempt to make parts of it more re-useable. It would be nice if this could be moved to a Geo...As the title states, this somewhat large operation is sitting in a static function in GeometryUtilities. It's actually a set of functions in an attempt to make parts of it more re-useable. It would be nice if this could be moved to a GeometryAlgorithm to avoid its large size (also you can optionally link to Filtering in imstk so it slightly decreases library size in many examples as well).https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/375Fix DynamicalModel::validGeometryTypes2022-06-01T16:40:32-04:00Andrew WilsonFix DynamicalModel::validGeometryTypesDynamicalModel stores some string types for the valid geometry types. This prevents usage with geometry subclasses.DynamicalModel stores some string types for the valid geometry types. This prevents usage with geometry subclasses.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/371iMSTKData in Innerbuild2022-04-20T09:47:40-04:00Andrew WilsoniMSTKData in InnerbuildiMSTKData is now in the outer build requiring users to rebuild imstk superbuild to update data which can be a lengthy process. It also requires any MRs with new data to use "do: test --clean" instead. Luckily you don't have to update dat...iMSTKData is now in the outer build requiring users to rebuild imstk superbuild to update data which can be a lengthy process. It also requires any MRs with new data to use "do: test --clean" instead. Luckily you don't have to update data often. But moving it to the innerbuild would be preferred.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/370CDDebugObject Queue instead of Clear Rates2022-06-01T16:20:58-04:00Andrew WilsonCDDebugObject Queue instead of Clear RatesThe CDDebugObject is an object that quickly adds/removes geometry to represent collision data (contacting faces, edges, etc). This is for debug purposes.
Unfortunately when you have a simulation running at 1000 updates a second its hard...The CDDebugObject is an object that quickly adds/removes geometry to represent collision data (contacting faces, edges, etc). This is for debug purposes.
Unfortunately when you have a simulation running at 1000 updates a second its hard to see whats going on. One might slow it down, advance by key, or one of the solutions currently provided is a "clear rate". Which clears the collision data visual representations every N frames. So you can see the last say, 50 frames.
A more intuitive implementation would be a queue. Such that you can store the last 50 collision data representations. Unfortunately this is a bit tricky to implement efficiently.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/367Rename SurfaceMesh::flipNormals to SurfaceMesh::reverse, or SurfaceMesh::reve...2022-06-01T16:27:38-04:00Andrew WilsonRename SurfaceMesh::flipNormals to SurfaceMesh::reverse, or SurfaceMesh::reverseWindingSimple change, reminder for later. The issue with flip normals is that it doesn't actually flip normals. It reverses windings.
In fact if you have per vertex normals defined and call flipNormals, expecting the normals to flip. It does n...Simple change, reminder for later. The issue with flip normals is that it doesn't actually flip normals. It reverses windings.
In fact if you have per vertex normals defined and call flipNormals, expecting the normals to flip. It does nothing. Because again, it doesn't flip normals, it reverses windings. Two very different things.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/360Light Runtime Addition/Removal2022-06-01T16:27:05-04:00Andrew WilsonLight Runtime Addition/RemovalLights currently can't be added/removed during runtime.
Workaround: Just add all the lights you need beforehand. Toggle them off if they aren't in use.Lights currently can't be added/removed during runtime.
Workaround: Just add all the lights you need beforehand. Toggle them off if they aren't in use.