iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-08-30T13:25:25-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/420SurfaceMesh deepCopy parameter2022-08-30T13:25:25-04:00Connor BowleySurfaceMesh deepCopy parameterNot necessarily a big deal, but it was unexpected to me that I can only deep copy SurfaceMesh's if the one I want to copy is stored in a `shared_ptr`. I would expect the signature to instead be `void deepCopy(const SurfaceMesh& srcMesh)`...Not necessarily a big deal, but it was unexpected to me that I can only deep copy SurfaceMesh's if the one I want to copy is stored in a `shared_ptr`. I would expect the signature to instead be `void deepCopy(const SurfaceMesh& srcMesh)`, as there is no true requirement that one can only copy 1) surface meshes that are specifically stored in shared pointer, and 2) non-const surface meshes (as the current parameter is `shared_ptr<SurfaceMesh>` and not `shared_ptr<const SurfaceMesh>`.
As an aside regarding a comment in the code for deepCopy, `\todo: generalize base classes and implement for every geometry`, please consider using a clone approach rather than a deep copy approach so it will work nicely with class hierarchies. You wouldn't really be able to implement `void PointSet::deepCopy(const PointSet& src)` because I could do something like `surfaceMesh.deepCopy(lineMesh)` and that can't happen (yes, you could detect this at runtime and throw and exception (or do the VTK method and silently ignore it), but ensuring the type safe clone can always happen is better). However, doing `surfaceMesh.clone()` or even `pointSetThatCouldBeASurfaceMesh.clone()` is always well defined.
Also, should you go the clone route, I found this a neat way to fake covariant return types with smart pointers.
https://www.fluentcpp.com/2017/09/12/how-to-return-a-smart-pointer-and-use-covariance/
For reference:
- https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c130-for-making-deep-copies-of-polymorphic-classes-prefer-a-virtual-clone-function-instead-of-public-copy-constructionassignmenthttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/419Real Time timestep/dt is not passed into PbdSolver continuously2022-07-06T13:51:30-04:00Andrew WilsonReal Time timestep/dt is not passed into PbdSolver continuouslyIt is only passed in on initialization, if the timestep is changed, PbdSolver never see's this change.
Given a fixed timestep this is a non issue, (ours is "semi fixed" as its called so it could cause a slight drift in time).
The PbdSo...It is only passed in on initialization, if the timestep is changed, PbdSolver never see's this change.
Given a fixed timestep this is a non issue, (ours is "semi fixed" as its called so it could cause a slight drift in time).
The PbdSolver only uses timestep in the case of XPBD.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/418Barycentric calculation for Line is flipped2022-06-16T23:34:24-04:00Andrew WilsonBarycentric calculation for Line is flippedBasically u is v and v is u. They still sum to 1.
This function is not internally used anywhere.
If a user had flipped their usage of them as well then they would have gotten correct results.Basically u is v and v is u. They still sum to 1.
This function is not internally used anywhere.
If a user had flipped their usage of them as well then they would have gotten correct results.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/417imstk::DataArray const begin/end methods2022-05-16T08:43:14-04:00Connor Bowleyimstk::DataArray const begin/end methodsIt would be useful to have const versions of `imstk::DataArray::begin` and `imstk::DataArray::end`. Yes, the existence of `cbegin` and `cend` are helpful, but I believe const `begin` and `end` would allow use of a `const DataArray` in a ...It would be useful to have const versions of `imstk::DataArray::begin` and `imstk::DataArray::end`. Yes, the existence of `cbegin` and `cend` are helpful, but I believe const `begin` and `end` would allow use of a `const DataArray` in a range based for loop.
Similarly it would be useful to have these for `imstk::VecDataArray`.
For reference `std::vector` has both const `begin`, non-const `begin`, and const `cbegin`
https://en.cppreference.com/w/cpp/container/vector/begin
https://en.cppreference.com/w/cpp/language/range-for#:~:text=If%20range%2Dexpression%20is%20an%20expression%20of%20a,%3BHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/415Visual Tests break under Linux2022-04-24T01:02:26-04:00Harald ScheirichVisual Tests break under LinuxWhen running the visual tests as a suit there is a spurious failure on test shutdown that implies that we are accessing the window after it has been closedWhen running the visual tests as a suit there is a spurious failure on test shutdown that implies that we are accessing the window after it has been closedhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/414Can't build TBB 2019 with gcc112022-06-29T09:38:53-04:00Harald ScheirichCan't build TBB 2019 with gcc11The TBB version that iMSKT currently uses `2019` can't be built with gcc 11 due to https://github.com/oneapi-src/oneTBB/issues/370
- we could try and apply the fix to our local version
- we could try and update TBBThe TBB version that iMSKT currently uses `2019` can't be built with gcc 11 due to https://github.com/oneapi-src/oneTBB/issues/370
- we could try and apply the fix to our local version
- we could try and update TBBhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/413FetchContent_Populate failed to get HEAD2022-04-21T19:51:33-04:00Andrew WilsonFetchContent_Populate failed to get HEADFetchContent_Populate only pulls from HEAD & won't update when the head moves.
```
Performing update step for 'imstkexternalprojecttemplate-populate'
1> CMake Error at C:/Repos/iMSTK/buildMsvc17/Innerbuild/Testing/imstkexternalprojectt...FetchContent_Populate only pulls from HEAD & won't update when the head moves.
```
Performing update step for 'imstkexternalprojecttemplate-populate'
1> CMake Error at C:/Repos/iMSTK/buildMsvc17/Innerbuild/Testing/imstkexternalprojecttemplate-subbuild/imstkexternalprojecttemplate-populate-prefix/tmp/imstkexternalprojecttemplate-populate-gitupdate.cmake:25 (message):
1> Failed to get the hash for HEAD:
1>
1> fatal: unsafe repository
1> ('C:/Repos/iMSTK/buildMsvc17/Innerbuild/Testing/iMSTKExternalProjectTemplate'
1> is owned by someone else)
1>
1> To add an exception for this directory, call:
1>
1>
1>
1> git config --global --add safe.directory
1> C:/Repos/iMSTK/buildMsvc17/Innerbuild/Testing/iMSTKExternalProjectTemplate
```
Nothing in the repository changed but iMSTKExternalProjectTemplate was updated.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/412In imstkPbdCollisionHandling, getEdge() with cell ID causes a crash.2022-07-12T02:17:41-04:00Shreeraj JadhavIn imstkPbdCollisionHandling, getEdge() with cell ID causes a crash.Inside imstkPbdCollisionHandling.cpp, the [`getEdge()`](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L81) function is called when constructing Edge related constraints. The f...Inside imstkPbdCollisionHandling.cpp, the [`getEdge()`](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L81) function is called when constructing Edge related constraints. The function `getEdge()` expects a cell ID if `idCount == 1` and tries to access `side.m_indicesPtr` which is explicitly assigned as nullptr [here](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L417) and [here](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/Source/CollisionHandling/imstkPbdCollisionHandling.cpp#L423).https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/411How to attempt to develop a surgical simulators ?2022-04-13T02:22:10-04:00JackCao003How to attempt to develop a surgical simulators ?Dear sir and madam, as we all know The Interactive Medical Simulation Toolkit (iMSTK) is an open-source toolkit that allows faster prototyping of surgical simulators and skill trainers, but how can I start to learning to build the surgic...Dear sir and madam, as we all know The Interactive Medical Simulation Toolkit (iMSTK) is an open-source toolkit that allows faster prototyping of surgical simulators and skill trainers, but how can I start to learning to build the surgical simulator?(the configuriton had been done) What tools or skills or knowledge should I to master? Especially,the ways to invoking iMSTK which I don't have any clues. So would you are willing to give me some advices? Thanks very much.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/409Errors in build solution of SFML project2022-04-10T19:46:06-04:00JackCao003Errors in build solution of SFML project![20220409_042603](/uploads/7e97c4448d14980c692a266f99ff9fc4/20220409_042603.png)
Dear ladies and gentlemen,a problem is showed above when build solution of SFML project.It's my first time to use opensource code,how can I solve it? Thank...![20220409_042603](/uploads/7e97c4448d14980c692a266f99ff9fc4/20220409_042603.png)
Dear ladies and gentlemen,a problem is showed above when build solution of SFML project.It's my first time to use opensource code,how can I solve it? Thanks for your help.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/407Upgrade Examples That use Mouse Virtual Coupling to use DummyClient2022-08-22T03:17:53-04:00Andrew WilsonUpgrade Examples That use Mouse Virtual Coupling to use DummyClientRight now many examples implement a dumbed down virtual coupling in their post update with mouse controls. These should be ported to use DummyClient so that we can reuse the virtual coupling implemented in RigidObjectController.Right now many examples implement a dumbed down virtual coupling in their post update with mouse controls. These should be ported to use DummyClient so that we can reuse the virtual coupling implemented in RigidObjectController.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/406Consolidate RbdConstraint & PbdConstraint2022-09-27T20:45:41-04:00Andrew WilsonConsolidate RbdConstraint & PbdConstraintThe RbdConstraint & PbdConstraint could become more similar in implementation.
- [ ] Use a flag or some other interface to indicate that a constraint, be it PbdConstraint or RbdConstraint. Should be clearable. IE: Put into a separate c...The RbdConstraint & PbdConstraint could become more similar in implementation.
- [ ] Use a flag or some other interface to indicate that a constraint, be it PbdConstraint or RbdConstraint. Should be clearable. IE: Put into a separate container that is cleared every simulation frame.
- [ ] This would require introduction of a container of constraints in RigidBodyModel that does not clear. New feature.
- [ ] Rename RbdConstraint::compute to computeValueAndGradient, to match Pbd.
- [ ] Pass in the required constraint values by reference like computeValueAndGradient. J & vu.
- [ ] Explore why computeValueGradient is not called in a loop before RigidBodyModel::Solve.
- [ ] The signs might be backwards in one of the constraint gradients (I think RbdConstraint has backward sign).
- [ ] Consider renaming PbdConstraint::initConstraint to PbdConstraint::init. Then introducing RbdConstraint::init & removing constructor initialization.
- [ ] Remove PbdCollisionConstraint. Rework all PbdConstraints to stem from the same base PbdConstraint (may not be possible performantly without templates, was attempted at numerous points, difficult).
This should make it much easier to work with the two models.
I suspect as we approach a proper solution of compliance between the two models we will arrive at something similar to PBD rigid bodies described in the paper "Detailed Rigid Body Simulation with Extended Position Based Dynamics"https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/404PbdPickingExample Indeterministic Cyclic2022-03-15T15:39:38-04:00Andrew WilsonPbdPickingExample Indeterministic CyclicThe PbdPickingExample appears to indeterministically conclude the graph is cyclic.
There are 4 interactions. 2 PbdObjectCollisions & 2 PbdPicking. If both picking's are removed the error still occurs. If 1 PbdObjectCollision is left the...The PbdPickingExample appears to indeterministically conclude the graph is cyclic.
There are 4 interactions. 2 PbdObjectCollisions & 2 PbdPicking. If both picking's are removed the error still occurs. If 1 PbdObjectCollision is left the error does not occur.Andrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/403Case sensitivity not handled in WSL build environment2022-06-29T09:39:38-04:00Harald ScheirichCase sensitivity not handled in WSL build environmentOur CI server is currently configured to be case-insensitive
https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity
documents how to change thisOur CI server is currently configured to be case-insensitive
https://docs.microsoft.com/en-us/windows/wsl/case-sensitivity
documents how to change thisAndrew WilsonAndrew Wilsonhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/402Improve 'Overview of iMSTK' section of the documentation2022-07-06T18:20:44-04:00Sreekanth ArikatlaImprove 'Overview of iMSTK' section of the documentationExpand the 'Overview of iMSTK' section of readthedocs documentation to give users a more detailed introduction to key components of imstk. Add a walk through example.Expand the 'Overview of iMSTK' section of readthedocs documentation to give users a more detailed introduction to key components of imstk. Add a walk through example.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/401ApplyToData Should Transform Mesh Normals & Tangents2022-08-25T10:04:36-04:00Andrew WilsonApplyToData Should Transform Mesh Normals & TangentsIf you load a mesh where the normals are provided in the file, have meaning, and aren't just overriden later. Then ApplyToData transform that mesh. You will mess up the normals & tangents causing weird lighting issues.If you load a mesh where the normals are provided in the file, have meaning, and aren't just overriden later. Then ApplyToData transform that mesh. You will mess up the normals & tangents causing weird lighting issues.Jacob MooreJacob Moorehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/400C# Wrapper Build Without Haptics Fails2022-03-15T15:39:44-04:00Andrew WilsonC# Wrapper Build Without Haptics FailsWhen haptics is not built with the wrapper fails to compile. Needs fixing.When haptics is not built with the wrapper fails to compile. Needs fixing.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/399BUG: EnforceCodeStyle Namings2022-02-09T16:53:56-05:00Andrew WilsonBUG: EnforceCodeStyle NamingsMany classes changed from all caps acronyms to first letter uppercase.
- [x] Many classes still using all uppercase.
- [x] Many doxygen class title's not updated, breaking doxygen linkage.
- [x] SWIG wrappings broken. Not on testing ...Many classes changed from all caps acronyms to first letter uppercase.
- [x] Many classes still using all uppercase.
- [x] Many doxygen class title's not updated, breaking doxygen linkage.
- [x] SWIG wrappings broken. Not on testing machine.
- [ ] VRPN example broken. Not on testing machine.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/398Get/Set Comment Formatting2022-01-23T02:46:10-05:00Andrew WilsonGet/Set Comment FormattingIn many places across imstk the following is used:
```
///
/// \brief Get/Set name
///
const std::string& getName() { return m_name; }
void setName(std::string name) { m_name = name; }
```
Where
```
///
/// \brief Get/Set name
///@{
c...In many places across imstk the following is used:
```
///
/// \brief Get/Set name
///
const std::string& getName() { return m_name; }
void setName(std::string name) { m_name = name; }
```
Where
```
///
/// \brief Get/Set name
///@{
const std::string& getName() { return m_name; }
void setName(std::string name) { m_name = name; }
///@}
```
Should be preferred, as it will show the description for both functions in doxygen.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/396C# Wrapper Test2022-03-14T22:57:08-04:00Andrew WilsonC# Wrapper TestIt would be nice to have a way to know when the C# wrapper is broke but not have it fail the entire build. Which would prevent us from continuing to run iMSTK tests & validate MRs. Recently JC showed a way to make builds tests which seem...It would be nice to have a way to know when the C# wrapper is broke but not have it fail the entire build. Which would prevent us from continuing to run iMSTK tests & validate MRs. Recently JC showed a way to make builds tests which seems like something we could do here.
The issue is we would need iMSTK_WRAP_CSHARP to cause an iMSTK build fail when it's on. But only when testing on our automated machines would we want to report as a failed test.