iMSTK issueshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues2022-06-29T09:48:49-04:00https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/161Enable audio support for Linux and OS X2022-06-29T09:48:49-04:00Sreekanth ArikatlaEnable audio support for Linux and OS XCurrently, audio support is built by default on windows only. This could be extended to Linux and OS XCurrently, audio support is built by default on windows only. This could be extended to Linux and OS Xhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/162Linux issues2018-04-27T10:57:23-04:00Nicholas MilefLinux issuesI'm making an issue for various Linux issues as I compile it on Linux. Once I get some time, I'll make an MR.
* Assimp issue with "-fPIC" flag:
* https://github.com/assimp/assimp/issues/746
* VTK can't find OpenGL (must use `sudo a...I'm making an issue for various Linux issues as I compile it on Linux. Once I get some time, I'll make an MR.
* Assimp issue with "-fPIC" flag:
* https://github.com/assimp/assimp/issues/746
* VTK can't find OpenGL (must use `sudo apt-get install freeglutv3-dev`)
* https://stackoverflow.com/questions/31170869/cmake-could-not-find-opengl-in-ubuntu
* Libusb 1.0 can't be found (must use `sudo apt-get install libusb-1.0-0-dev`)
* https://stackoverflow.com/questions/4853389/how-to-install-libusb-in-ubuntu
@sreekanth-arikatla @alexis-girault https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/169Assimp build issue with 3.3.12022-04-20T09:33:17-04:00Alexis GiraultAssimp build issue with 3.3.1Issue introduced here when using Assimp 3.3.1: https://gitlab.kitware.com/iMSTK/iMSTK/commit/34170af1540b9d7a16d296636bf62016eff8d99c#note_350649
On mac, I now can't build with the following error:
```
/Users/agirault/Projects/imstk/re...Issue introduced here when using Assimp 3.3.1: https://gitlab.kitware.com/iMSTK/iMSTK/commit/34170af1540b9d7a16d296636bf62016eff8d99c#note_350649
On mac, I now can't build with the following error:
```
/Users/agirault/Projects/imstk/rel/External/Assimp/src/code/D3MFImporter.cpp:230:29: error: invalid operands to binary expression ('float (*)(const char *, const char *)' and 'nullptr_t')
vertex.z = ai_strtof>(xmlReader->getAttributeValue(D3MF::XmlTag::z.c_str()), nullptr);
~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
Bug is here: https://github.com/assimp/assimp/blob/v3.3.1/code/D3MFImporter.cpp#L230
Not sure why dashboard are fine, for any platform.
@NickMilef @sreekanth-arikatla @jbvimort I remember talking about upgrading to [Assimp 4.0.1](https://github.com/assimp/assimp/tree/v4.0.1) at some point. Do you remember the reason why we didn't?https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/178Add an option to build imstk without rendering module2018-09-15T12:15:58-04:00Sreekanth ArikatlaAdd an option to build imstk without rendering module1. Add cmake options to not build any rendering backend at configure time
2. Even if the rendering is configured at build time, the user should let simulation manager know that no rendering is needed and the simulation manager should dis...1. Add cmake options to not build any rendering backend at configure time
2. Even if the rendering is configured at build time, the user should let simulation manager know that no rendering is needed and the simulation manager should disable render context.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/182Add multithreaded compilation2018-10-17T13:33:17-04:00Nicholas MilefAdd multithreaded compilationThe build process is very slow, particularly for VTK. To improve the performance, we should add the /MP compiler option via CMake.The build process is very slow, particularly for VTK. To improve the performance, we should add the /MP compiler option via CMake.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/217Asian Dragon example mesh is not updating properly2019-04-28T17:03:04-04:00Nicholas MilefAsian Dragon example mesh is not updating properlyThe config SHA file seems to be invalid. The keys don't match :(.The config SHA file seems to be invalid. The keys don't match :(.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/221CMake 3.14x build issue2019-12-20T16:18:02-05:00Sreekanth ArikatlaCMake 3.14x build issueCMake 3.14X has an issue with mismatching x86 and x64 build config for dependenciesCMake 3.14X has an issue with mismatching x86 and x64 build config for dependenciesRelease 2.0.0https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/232Group multiple projects into folders in msvc2019-08-03T18:26:15-04:00Sreekanth ArikatlaGroup multiple projects into folders in msvchttps://stackoverflow.com/questions/41078807/cmake-and-visualstudio-group-files-in-solution-explorerhttps://stackoverflow.com/questions/41078807/cmake-and-visualstudio-group-files-in-solution-explorerhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/239Using system builds of dependencies fails2020-07-31T13:04:54-04:00Sreekanth ArikatlaUsing system builds of dependencies failshttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/240Timeout in external data download2020-02-24T14:29:34-05:00Sreekanth ArikatlaTimeout in external data downloadThe volume rendering data set fails to download as it times out even after setting no limits on timeThe volume rendering data set fails to download as it times out even after setting no limits on timehttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/241superbuild fails at physx external project2020-03-13T09:43:39-04:00Sreekanth Arikatlasuperbuild fails at physx external projecthttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/248External Use Shader Location Invalid2021-06-01T13:13:15-04:00Andrew WilsonExternal Use Shader Location InvalidShaders are not found when using imstk externally. Simulation runs fine, but nothing is displayed and VTK shader errors are thrown.Shaders are not found when using imstk externally. Simulation runs fine, but nothing is displayed and VTK shader errors are thrown.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/265Download the data optionally at the build2022-04-20T08:26:25-04:00Sreekanth ArikatlaDownload the data optionally at the buildBuild should not be held for the downloadBuild should not be held for the downloadhttps://gitlab.kitware.com/iMSTK/iMSTK/-/issues/273iMSTK Uncrustify stealth dependency on PythonInterp2022-01-07T01:15:13-05:00Johan AndruejoliMSTK Uncrustify stealth dependency on PythonInterpUncrustify requires [PythonInterp](https://github.com/uncrustify/uncrustify/blob/23184091f66c5ba8434da08639cb2cdde77dfeb1/CMakeLists.txt#L20) though it's never prescribed by iMSTK itself anywhere.
This creates a confusing build failure...Uncrustify requires [PythonInterp](https://github.com/uncrustify/uncrustify/blob/23184091f66c5ba8434da08639cb2cdde77dfeb1/CMakeLists.txt#L20) though it's never prescribed by iMSTK itself anywhere.
This creates a confusing build failure in the superbuild if you system doesn't have python.
Worse, this may work against you by linking to whatever python you have on your system without you knowing **which** one.
Possible fix:
iMSTK should probably add a ```find_package(PythonInterp REQUIRED)``` to [External_Uncrustify.cmake](https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/CMake/External/External_Uncrustify.cmake) and make sure to pass the proper vars to Uncrustify if possible.
That would at least ensure that the missing python libraries get caught at configure time.https://gitlab.kitware.com/iMSTK/iMSTK/-/issues/293Superbuild seems to only utilize 1 core for vtk build2021-05-25T17:32:31-04:00Harald ScheirichSuperbuild seems to only utilize 1 core for vtk buildLooks like the superbuild doesn't set `\MP` for the vtk build, (and maybe others) its particularily visible with vtk as its the only thing that is building for a while.Looks like the superbuild doesn't set `\MP` for the vtk build, (and maybe others) its particularily visible with vtk as its the only thing that is building for a while.https://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/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/336iMSTKConfig Should be Appending CMAKE_MODULE_PATH2021-07-03T18:32:18-04:00Andrew WilsoniMSTKConfig Should be Appending CMAKE_MODULE_PATHDon't have time to test right now but leaving this here for later.
I'm pretty sure the iMSTKConfig.cmake file should be appending or only temporarily setting the CMAKE_MODULE_PATH, not overwriting it. It causes problems when users set i...Don't have time to test right now but leaving this here for later.
I'm pretty sure the iMSTKConfig.cmake file should be appending or only temporarily setting the CMAKE_MODULE_PATH, not overwriting it. It causes problems when users set it in their external project. This variable is a cmake one used as a search path by cmake "include". By setting it in the config it overwrites the user's CMAKE_MODULE_PATH when find_package(iMSTK) is called. Whatever the user then had is erased and all their include's break.
(The reason the iMSTKConfig.cmake sets the module path to begin with is because certain cmake includes are used in iMSTK's cmake code)
The solution would be:
Appending: https://gitlab.kitware.com/iMSTK/iMSTK/-/blob/master/CMake/iMSTKConfig.cmake.in#L19 should be list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/modules").
Temporarily Set: Save the current CMAKE_MODULE_PATH, set it for iMSTKConfig.cmake, then at the end, set it back to the one before config ran.
I'm thinking it should be temp set. The difference is whether iMSTK's cmake code should be on the user's module path, accessible by the external project or not. Names could conflict in user cmake files vs iMSTK's (or even finds). It would make more sense to just provide iMSTK's cmake code via another variable that the user could then optionally include on their cmake path.
Example of failure in external project (of course one could reorder these calls as a temp fix):
```
list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake)
find_package(iMSTK REQUIRED)
include(ClangFormat) # Can't be found!
...
```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.