CAMP issueshttps://gitlab.lrz.de/groups/CAMP/-/issues2017-12-03T17:14:26+01:00https://gitlab.lrz.de/CAMP/campvis-public/-/issues/9GPU memory leak when multiple OpenGL contexts are active2017-12-03T17:14:26+01:00Ghost UserGPU memory leak when multiple OpenGL contexts are activeAs soon as they are multiple OpenGL contexts active at the same time, GPU memory leaks occur because some textures are not deleted correctly anymore.
According to early debugging sessions, `glDeleteTextures()` is called correctly. How...As soon as they are multiple OpenGL contexts active at the same time, GPU memory leaks occur because some textures are not deleted correctly anymore.
According to early debugging sessions, `glDeleteTextures()` is called correctly. However, the GPU memory is not freed as the memory monitor of GPU-Z suggests (as well as the general performance). As soon, as I manually make that call exclusive/synchronized, the memory leak seems to not occur again.
[This article](https://www.opengl.org/wiki/Memory_Model) is not too specific how OpenGL handles concurrent deletion of textures/buffers. However, we definitely take care of correct thread-context management. It might be a nVidia driver bug as well... :/https://gitlab.lrz.de/CAMP/campvis-public/-/issues/8Tabbed View Inspector resize issue2017-12-03T17:14:26+01:00Ghost UserTabbed View Inspector resize issueWhile using the tabbed display option, there are weird issues with the render result sizes.
At least one bug occurs: the DataContainerInspector still shows the old RenderData size of the window prior to switching to tabbed mode.
While using the tabbed display option, there are weird issues with the render result sizes.
At least one bug occurs: the DataContainerInspector still shows the old RenderData size of the window prior to switching to tabbed mode.
https://gitlab.lrz.de/CAMP/campvis-public/-/issues/7Sharing render output between two canvases is broken2017-12-03T17:14:26+01:00Ghost UserSharing render output between two canvases is brokenWhen creating two pipelines sharing the same dataContainer having the same `_renderTargetID`, the sharing of the render output is broken.
1. When interacting with one pipeline, the output of the other does not get updated (setPipelineDi...When creating two pipelines sharing the same dataContainer having the same `_renderTargetID`, the sharing of the render output is broken.
1. When interacting with one pipeline, the output of the other does not get updated (setPipelineDirty() is not called, missing onDataContainerAdded overload in AbstractPipeline)
2. Even if that is added, the other canvas often just shows a black screen.https://gitlab.lrz.de/CAMP/campvis-public/-/issues/6Add progress monitor support to processors2017-12-03T17:14:26+01:00Ghost UserAdd progress monitor support to processorsIt should be possible to observe a processors inner state, i.e. when it is beginning processing data, when it finishes and the progress in between. This would allow to add a progress bar to the GUI that displays it. This would also nicel...It should be possible to observe a processors inner state, i.e. when it is beginning processing data, when it finishes and the progress in between. This would allow to add a progress bar to the GUI that displays it. This would also nicely be integrated with ITK filters that can be monitored via observed->AddObserver(observer, itk::ProgressEvent). Another consideration is if one processors calls other processeors internally, then their progress should be added to the parent's progress.
https://gitlab.lrz.de/CAMP/campvis-public/-/issues/5Allow DataNameProperty for filtering of specific data types2017-12-03T17:14:26+01:00Ghost UserAllow DataNameProperty for filtering of specific data typesIt would be cool if the DataNameProperty (in READ mode) could automatically filter the shown DataHandles in the UI for the needed type (i.e. image data/geometry data/etc.). This could be done for instance by exploiting the CRTP-based reg...It would be cool if the DataNameProperty (in READ mode) could automatically filter the shown DataHandles in the UI for the needed type (i.e. image data/geometry data/etc.). This could be done for instance by exploiting the CRTP-based registration pattern once more to let data types generically register themselves during static initialization and receive an index that could be used for bit field-based filtering.
https://gitlab.lrz.de/CAMP/campvis-public/-/issues/4Improve line rendering of GeometryRenderer2017-12-03T17:14:26+01:00Ghost UserImprove line rendering of GeometryRendererThe `GeometryRenderer` is the bread-and-butter processor for rendering geometry. However, its implementation of rendering lines is still a hack:
- setting wireframe flag, sometimes it uses the wireframe color.
- the shading is done on ...The `GeometryRenderer` is the bread-and-butter processor for rendering geometry. However, its implementation of rendering lines is still a hack:
- setting wireframe flag, sometimes it uses the wireframe color.
- the shading is done on non-existent normal vectors
- linewidth is not set
Fix and clean the implementation and perhaps even merge with the fiber renderer (supporting on-the-fly creation of tubes or fake-tubes)https://gitlab.lrz.de/CAMP/campvis-public/-/issues/3Move to Qt52017-12-03T17:14:26+01:00Ghost UserMove to Qt5Qt4 is sooo 2011 and Q5 is quite flawlessly nowadays. We should move CAMPVis to Qt5. However, this requires various adjustments in the CMake scripts.Qt4 is sooo 2011 and Q5 is quite flawlessly nowadays. We should move CAMPVis to Qt5. However, this requires various adjustments in the CMake scripts.https://gitlab.lrz.de/CAMP/campvis-public/-/issues/2Move closer towards an Entity-Component model2017-12-03T17:14:26+01:00Ghost UserMove closer towards an Entity-Component modelMove the framework design closer to entity-component-system model/design pattern. The original idea was that current AbstractData types (i.e. ImageData, GeometryData, ...) become Entities, that could get glued together to components. Tra...Move the framework design closer to entity-component-system model/design pattern. The original idea was that current AbstractData types (i.e. ImageData, GeometryData, ...) become Entities, that could get glued together to components. Transformation matrices, camera setup, lighting setup, and probably other stuff would also become entities, that would then define how to visualize the component.
Hence, the DataHandles in the DataContainer would store components.
Possible steps (besides others):
- Rename XyzData to XyzEntity
- Develop a component class that can nicely glue several entities together
- Get rid of complicated (non-primitive) properties: Use Entities (DataHandles) instead, which would make sharing much easier and further contribute to the Entitiy/Component concept
However, directly realizing a entity system like this would lead to quite complex code. This is the reason I did not implement it. Nevertheless, one should check whether it is possible to move closer towards this central game engine concept.
https://gitlab.lrz.de/CAMP/campvis-public/-/issues/1Fix colorspace GLSL shader2017-12-03T17:14:26+01:00Ghost UserFix colorspace GLSL shaderThe `colorspace.frag` utility shader has some broken implementations of the color space conversions. The exact problem is not yet determined, however RGB->XYZ->Lab->XYZ->RGB is no perferct roundtrip if you change for instance the a-compo...The `colorspace.frag` utility shader has some broken implementations of the color space conversions. The exact problem is not yet determined, however RGB->XYZ->Lab->XYZ->RGB is no perferct roundtrip if you change for instance the a-component in Lab space.
This needs to be evaluated in detail - perhaps we need additional gamma adjustment - I saw that in some demo code snippets.