iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2021-06-28T09:32:43-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/335Light not found warning thrown in every example that adds a light2021-06-28T09:32:43-04:00Andrew WilsonLight not found warning thrown in every example that adds a lightIssues because of https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/615
This is because getLight throws it when it can't find a light, yet many spots in code use it to check if a light is present.
For instance, addLight uses getL...Issues because of https://gitlab.kitware.com/iMSTK/iMSTK/-/merge_requests/615
This is because getLight throws it when it can't find a light, yet many spots in code use it to check if a light is present.
For instance, addLight uses getLight to check if light is present, if not, adds it. So every example that adds a light will throw it because obviously a light will not be present initially.
Suggestion: Remove check and throw warning in getLight if we intend to use it to check ourselves. Or just use a vector without names for lights. Add the names later when they're actually needed.Harald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/334SSL connect error2021-06-29T08:22:42-04:00mmanfredSSL connect error[build] C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): error MSB8066: “F:\iMSTK\iMSTK\build\CMakeFiles\6afa5dc88e75608c3e0b52444b6b460e\tbb-download.rule;F:\iMS...[build] C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(241,5): error MSB8066: “F:\iMSTK\iMSTK\build\CMakeFiles\6afa5dc88e75608c3e0b52444b6b460e\tbb-download.rule;F:\iMSTK\iMSTK\build\CMakeFiles\6afa5dc88e75608c3e0b52444b6b460e\tbb-update.rule;F:\iMSTK\iMSTK\build\CMakeFiles\6afa5dc88e75608c3e0b52444b6b460e\tbb-patch.rule;F:\iMSTK\iMSTK\build\CMakeFiles\6afa5dc88e75608c3e0b52444b6b460e\tbb-configure.rule;F:\iMSTK\iMSTK\build\CMakeFiles\6afa5dc88e75608c3e0b52444b6b460e\tbb-build.rule;F:\iMSTK\iMSTK\build\CMakeFiles\6afa5dc88e75608c3e0b52444b6b460e\tbb-install.rule;F:\iMSTK\iMSTK\build\CMakeFiles\38ab047f09196ed0c60ef5e7f6af02bc\tbb-complete.rule;F:\iMSTK\iMSTK\build\CMakeFiles\0d4958253ac9bc6ccfe83fb41ea0c8c3\tbb.rule” [F:\iMSTK\iMSTK\build\CMake\External\tbb.vcxproj]
[build] Performing download step (download, verify and extract) for 'LibNiFalcon'
[build] -- verifying file...
[build] file='F:/iMSTK/iMSTK/build/External/LibNiFalcon/src/libnifalcon-libusb1-windows.zip'
[build] -- MD5 hash of
[build] F:/iMSTK/iMSTK/build/External/LibNiFalcon/src/libnifalcon-libusb1-windows.zip
[build] does not match expected value
[build] expected: '6d5d68c92837388bfcd27f99a48b921d'
[build] actual: 'd41d8cd98f00b204e9800998ecf8427e'
[build] -- File already exists but hash mismatch. Removing...
[build] -- Downloading...
[build] dst='F:/iMSTK/iMSTK/build/External/LibNiFalcon/src/libnifalcon-libusb1-windows.zip'
[build] timeout='none'
[build] inactivity timeout='none'
[build] -- Using src='https://gitlab.kitware.com/iMSTK/libnifalcon/-/archive/libusb1-windows/libnifalcon-libusb1-windows.zip'
[build] CMake Error at stamp/download-LibNiFalcon.cmake:170 (message):
[build] Each download failed!
[build]
[build] CUSTOMBUILD : error : downloading 'https://gitlab.kitware.com/iMSTK/libnifalcon/-/archive/libusb1-windows/libnifalcon-libusb1-windows.zip' failed [F:\iMSTK\iMSTK\build\CMake\External\LibNiFalcon.vcxproj]
[build] status_code: 35
[build] status_string: "SSL connect error"
[build] log:
[build] --- LOG BEGIN ---
[build] timeout on name lookup is not supported
[build] Trying 66.162.65.214:443...
[build]
[build] Connected to gitlab.kitware.com (66.162.65.214) port 443 (#0)
[build]
[build] schannel: disabled automatic use of client certificate
[build]
[build] schannel: ALPN, offering h2
[build]
[build] schannel: ALPN, offering http/1.1
[build]
[build] schannel: initial InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
[build] (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
[build] received (e.g. handshake failed). More detail may be available in the
[build] Windows System event log.
[build]
[build] Closing connection 0
[build]
[build]
[build]
[build] --- LOG END ---
The above is one of the errors, can you give me some help?https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/333PhysX Build Toggle in CMake2021-06-29T22:36:42-04:00Andrew WilsonPhysX Build Toggle in CMakePut PhysX on a toggle to optionally not build with it.Put PhysX on a toggle to optionally not build with it.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/332Linux Build Issues2021-07-06T09:10:10-04:00Harald ScheirichLinux Build IssuesStill working on improving the linux dashboard builds
- [x] Debug build compile error
- [x] Debug build link error (!612)
- [x] Dashboard test issuesStill working on improving the linux dashboard builds
- [x] Debug build compile error
- [x] Debug build link error (!612)
- [x] Dashboard test issuesHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/331Library/Target Modularization2021-10-23T17:15:58-04:00Andrew WilsonLibrary/Target ModularizationThis has been discussed for awhile, but it would be nice to split up iMSTKs libraries in a way that doesn't involve us linking to the entirety of all of them in every example. Usually
`target_link_libraries(myProject PUBLIC SimulationM...This has been discussed for awhile, but it would be nice to split up iMSTKs libraries in a way that doesn't involve us linking to the entirety of all of them in every example. Usually
`target_link_libraries(myProject PUBLIC SimulationManager)`
is done which transiently gives all other libraries. To reduce program bloat it's nicer if you can split things up such as done with Filtering. Filtering exists independent of the rest of imstk. As such you either link to it or not.
`target_link_libraries(myProject PUBLIC SimulationManager Filtering)`
This not only reduces program sizes but also encourages developers to keep their code modular. It should also allow us to keep iMSTK more modular to support things like extensions/modules (maybe even remote ones). There are many ways to do such a thing but it generally involves splitting up abstract base classes in separate libraries from the implementations.
- For example, SPH could be entirely wrapped in its own module (or modules), providing SPHObject, SPHModel, various SPH related interactions.
- Another example is how FilterCore exists separately from Filtering allowing linkage to the base abstract class without all the rest of the filters. Allowing parallel builds.
Lastly this should also aid the build. For example right now we build these targets in this order:
`DynamicalModels -> SceneEntities -> Scene`
Where DynamicalModels builds SPH, PBD, FEM, etc code. Which is funny because the Scene doesn't know anything about PBD or SPH, and shouldn't. So why make it depend on it? You could instead have
```
DynamicalModels -> SPH
DynamicalModels -> PBD
DynamicalModels -> FEM
DynamicalModels -> SceneEntities -> Scene
```
Where DynamicalModels only builds the base abstract class for dynamical models. SPH, PBD, FEM can then all build in parallel. Similar things can be applied all over iMSTK.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/330Add shadows when vtk fix is ready2022-06-02T01:43:07-04:00Sreekanth ArikatlaAdd shadows when vtk fix is readyWhen vtk fixes its shadows feature, add back shadows in imstk.
The shadows appear to be broken but not for static/single renders.When vtk fixes its shadows feature, add back shadows in imstk.
The shadows appear to be broken but not for static/single renders.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/329Add test for modified TetrahedralRenderDelegate2022-04-20T09:39:35-04:00Sreekanth ArikatlaAdd test for modified TetrahedralRenderDelegateUnittest backlog from !592Unittest backlog from !592https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/328Add unit test for vertex neighbor calculations2021-06-10T16:02:48-04:00Sreekanth ArikatlaAdd unit test for vertex neighbor calculationsUnittest backlog from !591Unittest backlog from !591https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/326Move Example-RCM to Unit Tests2022-04-12T16:59:08-04:00Andrew WilsonMove Example-RCM to Unit TestsAs the title says this would be more appropriate as a unit tests in GeometryTests.As the title says this would be more appropriate as a unit tests in GeometryTests.Jianfeng YanJianfeng Yanhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/325Make Sequential Execution Default2021-09-02T18:56:56-04:00Andrew WilsonMake Sequential Execution DefaultCurrently there are two execution modes in iMSTK.
One that renders and simulates in parallel:
```
// Setup a viewer to render
imstkNew<VTKViewer> viewer("Viewer");
viewer->setActiveScene(scene);
// Setup a scene manager to advance the ...Currently there are two execution modes in iMSTK.
One that renders and simulates in parallel:
```
// Setup a viewer to render
imstkNew<VTKViewer> viewer("Viewer");
viewer->setActiveScene(scene);
// Setup a scene manager to advance the scene
imstkNew<SceneManager> sceneManager("Scene Manager");
sceneManager->setActiveScene(scene);
imstkNew<SimulationManager> driver;
driver->addModule(viewer);
driver->addModule(sceneManager);
driver->start();
```
One that renders and simulates sequentially. Calling simulate N times per render:
```
// Setup a viewer to render
imstkNew<VTKViewer> viewer("Viewer");
viewer->setActiveScene(scene);
// Setup a scene manager to advance the scene
imstkNew<SceneManager> sceneManager("Scene Manager");
sceneManager->setActiveScene(scene);
sceneManager->setExecutionType(Module::ExecutionType::ADAPTIVE);
imstkNew<SimulationManager> driver;
driver->addModule(viewer);
driver->addModule(sceneManager);
driver->setDesiredDt(0.005); // Governs N/how many steps per render
driver->start();
```
The parallel one is hard to support but may have some niche use cases with respect to medical simulation. But I do believe sequential should be default. ie: get rid of line `sceneManager->setExecutionType(Module::ExecutionType::ADAPTIVE);`
For this to happen all examples need to be tuned for the sequential mode. Ideally tuned for lowest common denominator (ie: worst machine). So others can start imstk examples without problems. Some take no effort to tune and have large ranges of valid timesteps even on bad machines. Others have a small ranges of valid timesteps, making it harder to tune. Some need their other parameters changed to account for new timesteps.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/324Investigate Removal of GLM2021-06-04T14:55:01-04:00Andrew WilsonInvestigate Removal of GLMI don't believe GLM is being used for anything significant at this point. Or at least, nothing that can't be replaced with Eigen. It is just a vector math library (it is faster though). Especially with the recent removal of Vulkan.I don't believe GLM is being used for anything significant at this point. Or at least, nothing that can't be replaced with Eigen. It is just a vector math library (it is faster though). Especially with the recent removal of Vulkan.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/323Add developer guide to documentation folder2021-06-10T12:45:32-04:00Sreekanth ArikatlaAdd developer guide to documentation folderHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/322CMake Config Failure2021-05-29T16:28:24-04:00Andrew WilsonCMake Config Failure@HongLi Is reporting that one cannot use iMSTK externally if there are spaces in the path name.@HongLi Is reporting that one cannot use iMSTK externally if there are spaces in the path name.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/321msvc2017 Continuous Integration Failure2022-01-07T01:12:21-05:00Andrew Wilsonmsvc2017 Continuous Integration FailureWhen doing an MR and testing, msvc2017 will often fail despite it actually working.
This is known because I've gone in and built it myself manually, and it worked.
I've also merged code that passed 2019 but not 2017, it then tested mas...When doing an MR and testing, msvc2017 will often fail despite it actually working.
This is known because I've gone in and built it myself manually, and it worked.
I've also merged code that passed 2019 but not 2017, it then tested master and passed. Also passed on nightly. So it's clear there wasn't actually an error with the msvc2017.
I believe it to be building out of date code, or reporting out of date (previous) results.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/320Map Refactor (Ability to have N Geometry Maps)2021-11-23T17:05:05-05:00Andrew WilsonMap Refactor (Ability to have N Geometry Maps)Currently DynamicObjects have a physicsToVisualMap, physicsToCollidingMap, ...
It would be much better if we just generically had N maps under a SceneObject (maybe even move them if we later get to an entity component architecture).
Th...Currently DynamicObjects have a physicsToVisualMap, physicsToCollidingMap, ...
It would be much better if we just generically had N maps under a SceneObject (maybe even move them if we later get to an entity component architecture).
There is then also contextual information of the maps. ie: The physicsToCollidingMap must be updated before fetching the latest colliding geometry (which could be done at any point, or even multiple times are differing states). With N maps, if you have the collision geometry, you should be able to quickly deduce which map corresponds to it. ie: For all geometry maps { update map that produces said geometry }
Frequently I have a tool with multiple parts where I need N mappings. These then become useless. What I normally do is subclass and implement update of the object, or even place it elsewhere in the objects pipeline using the task graph.
```
update() override
{
for all maps
update maps
}
```
Or even for a simple isometric one:
```
update() override
{
// Transform A, B, and C along with D
geometryA->setTransform(geometryD->getTransform());
geometryB->setTransform(geometryD->getTransform());
geometryC->setTransform(geometryD->getTransform());
}
```
This works and is nice but then physicsToVisualMap, physicsToCollidingMap, etc start to really serve no purpose.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/319Remove Vulkan2021-06-01T23:24:26-04:00Andrew WilsonRemove VulkanAs it stands Vulkan in iMSTK doesn't work. It really doesn't seem like we'll be able to realistically support this. We'd sooner support Unity or Unreal which can be used for more graphical performance/fidelity. If this is the case, some ...As it stands Vulkan in iMSTK doesn't work. It really doesn't seem like we'll be able to realistically support this. We'd sooner support Unity or Unreal which can be used for more graphical performance/fidelity. If this is the case, some other 3rd party module of iMSTK should be used if anyone wants to develop this.
Not to mention VTK has been making progress in rendering fidelity. I'm confident we'll be able to write some custom shaders for it in the future. But there are a few hard limits to what VTK can do currently. These things can be done in Unity and Unreal though. Also worth mentioning there are few things that VTK can do that Unity/Unreal can't (without 3rd party or other bad solutions), namely Volume Rendering which would be particularly difficult to support on Vulkan.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/318Remove apiUtilities2021-07-04T01:31:54-04:00Andrew WilsonRemove apiUtilitiesapiUtilities is redundant and just creates more interface to support, only a few examples use their "utility-like" functions as shorthands to create objects. They are also not used in any of our projects and I would highly caution using ...apiUtilities is redundant and just creates more interface to support, only a few examples use their "utility-like" functions as shorthands to create objects. They are also not used in any of our projects and I would highly caution using them anywhere.
The plotter utils aren't significant. If anything they should be absolved into a greater IO module. For now, we could move them to an example which could be referred to later if one wanted to write these files.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/317Capsule's and Cylinder's Do Not Respond To Transforms in a Natural Way2021-05-26T15:46:48-04:00Andrew WilsonCapsule's and Cylinder's Do Not Respond To Transforms in a Natural WayScaling capsules and cylinders is not correct. Or at least unintuitive.
What I would intuitively expect:
Scaled Locally, Oriented Locally, Translated Locally, then global transform applied.
When scaled locally it would apply Y scaling ...Scaling capsules and cylinders is not correct. Or at least unintuitive.
What I would intuitively expect:
Scaled Locally, Oriented Locally, Translated Locally, then global transform applied.
When scaled locally it would apply Y scaling to length and max(X,Z) to radius.
The global transform will never scale correctly though.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/316Add merge request template to gitlab2021-05-26T16:15:49-04:00Harald ScheirichAdd merge request template to gitlabCreate a template to be filled in during merge requestsCreate a template to be filled in during merge requestsHarald ScheirichHarald Scheirichhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/315TetrahedralMesh::getVolume() throws negative-volume warning on valid elements.2021-07-12T12:03:39-04:00Jianfeng YanTetrahedralMesh::getVolume() throws negative-volume warning on valid elements.
The `if (det < 0)` should be changed to `if (det > 0)` otherwise it throws negative-volume warning on valid elements.
The `if (det < 0)` should be changed to `if (det > 0)` otherwise it throws negative-volume warning on valid elements.