It may be tricky, but folks on the VTK forum would I’m sure be very interested to see a pure-VTK example of this issue to help debugging (that is, to remove Slicer-related complexities). E.g. maybe one could start with an example like this one and add some depth peeling and transparent objects.
If I could bring up a VTK-only example, it would greatly facilitate me debugging the issue myself. Alas, I have tried to bring up a few of them without success. The main issue is that all of the examples I have found require newer versions of VTK, but the only machine I have that supports EGL/DRI is still running CentOS 7, which is too old to build those newer versions of VTK. I will examine the source code, as advised above.
If you can diagnose from the source code that’s great.
But just FYI if you are able to run Slicer on the machine you can run vtk examples too. If you download the example linked above to /tmp/SampleRayCast.py, and then give it a .vtk volume file as an argument it should work for you like this example:
~/Downloads/Slicer-4.11.20210226-linux-amd64/bin/PythonSlicer /tmp/SampleRayCast.py ~/Documents/MRHead.vtk
(here I made MRHead.vtk by downloading the MRHead from the SampleData module and saving it as .vtk format.)
Thanks for the tip about running VTK examples. I guess I would just need an example that demonstrates the same type of rendering that Slicer performs when depth peeling and Display ROI are both enabled. Unfortunately, such an example is beyond my ability to produce.
After examining the code and the apitrace logs more closely, I am still clueless as to what the problem is. I may be wrong, but I don’t think it’s FBO-related. VirtualGL’s EGL back end only interferes with FBO functions when the default framebuffer is being used, and since VTK creates and uses its own FBOs, there should be no interference. It seems to me that if Z buffer initialization or resolution were the problem, then we should see the same rendering bug with the GLX back end, but we don’t. (And it’s really telling that playing back the apitrace capture-- which, to be clear, was captured on the local display without VirtualGL-- through VirtualGL’s EGL back end also fails to reproduce the bug. That’s the part that is really confusing me.) Also, VirtualGL’s own unit tests are fairly comprehensive and include quite a few conformance checks to ensure that we are properly emulating double buffering for the default framebuffer without interfering with application-generated FBOs. Also, although the EGL back end still lacks a few of the GLX and OpenGL features that the GLX back end supports, the apitrace logs don’t indicate that the application is using any of those features.
I’m afraid that, without a more stripped-down program that demonstrates the problem, there isn’t much more I can do about it. I don’t have the resources to continue focusing on this. I will note also that I have tried this example: VTK/Tutorials/TranslucentGeometry - KitwarePublic, but it doesn’t reproduce the issue.
GitHub issue filed against VirtualGL: EGL back end: incorrect rendering with 3D Slicer when depth peeling and "Display ROI" are both enabled · Issue #168 · VirtualGL/virtualgl · GitHub
without a more stripped-down program
Note that I didn’t have a chance to check if it was different from the one from the wiki.
Last, the version of VTK 9 we use in Slicer is Slicer/VTK@slicer-v9.0.20201111-733234c785, could you try to build the example against this specific version to check if you can reproduce the problem ?
@DRC will you be able to build and test the example?
If not @muratmaga and I have been discussing the option of creating a python test script to see if we can replicate the issue in pure VTK without Slicer.
@pieper I was finally able to get that exact version of VTK to build on my machine, but unfortunately, the issue does not reproduce with the CorrectlyRenderTranslucentGeometry example.
You could try adding depth peeling to the example code @alireza added here: Incorrect volume rendering bounds - first and last slice - #5 by alireza
@pieper I have no experience whatsoever with that and would not even know how to begin.
I would make the example for you but I’m tied up at least the next week. If you nobody else can help you ping me again and I can give it a shot.
I’ll be gone for the next week anyhow and working on documentation after that, so there’s no huge rush.
@muratmaga tells me this issue is bottleneck for SlicerMorph, so it would be great to get to the bottom of it. Unfortunately depth peeling seems to be touching low level in OpenGL driver code that is rarely used and different across platforms.
Here’s a script that uses pure vtk python to do volume rendering with cropping and depth peeling that should be very similar to what Slicer does. This renders script fine for me on mac and one linux machine but has some artifacts on a different linux machine (no VirtualGL involved). It would be good to know if this can be used to track down the VirtualGL issue at the VTK level.
I believe that EGLBE: Test/Fix issues with draw buffer state · VirtualGL/virtualgl@adabbd9 · GitHub accidentally fixed this. I can no longer reproduce the issue after that commit.
That’s great news, thanks for reporting back
This is great. What would we need to change in this Slicer docker image for Jupyter/Lab to get this fix?
@lassoan Unless you are using VirtualGL (and it doesn’t appear that you are), this issue is not relevant to you.
Could you help with for switching to using VirtualGL? The dockerfile was created by someone else several years ago and I’m not sure what and how would need to be changed.
@lassoan Using VirtualGL isn’t just a matter of changing the Dockerfile. You would need additional configuration on the host machine. I do such work as a paid consultant, and if you are interested in hiring me, contact me off-list: VirtualGL | About / Contact.
11 posts were split to a new topic: Volume rendering appearance changes if ROI box is shown