Hi @utkarsh.ayachit ,
I’m attaching the pvx file we use in our cave system. It’ll show you the complexity of it.
yurt_pserver.pvx (25.8 KB)
I wouldnt know how to simplify it for a less robust system though.
The ScalablePol tag is related to the scalable software we use to blend the scene into our multi display cave. So far it works with surfaces, but no volumes.
Thanks
wow…68 tiles! that’s something :).
Next, can you tell your dataset extents and bounds. That way I can put together a mock dataset for testing.
BTW, not sure if you’re aware, but an easy way to test out a CAVE setup on a desktop machine is first to remove all the Environment items from the pvx file and then run the pvserver on the machine as follows:
> export PV_ICET_WINDOW_BORDERS=1
> mpirun -np <num ranks> pvserver my-config.pvx
That creates a collection of 400x400 windows for each of the ranks that show the rendering results for each.
68 actually 
Nice trick! That will be very helpful, although 69 400x400 windows will be too big for any monitor…
We have a couple of challenges we’re running up against. One is automating finding and setting the extents/bounds. The other is that transformations seem to mess things up.
I’m hoping that Camilo can update you on the extents/bounds.
D
One is automating finding and setting the extents/bounds.
I should be able to fix this, I think. At least I should be able to figure out if it really is needed fairly quickly.
The other is that transformations seem to mess things up.
This will be the tricky one since I am not too familiar with the volume mapper code, but once I can reproduce it, I know whom to seek help from (cc: thanks in advance, @martink ;)). Just to confirm, this issue is only with volume rendering, right? and not when rendering surfaces? That helps isolate the problem.
This is the link of the dataset we are currently testing with.
We kept the default bounds of the dataset applied by Paraview. The time changed the extensions in the source code, we followed the procedure described in the Mar 15 post along with the results obtained from the test.
Thanks
Thanks for the dataset. I can confirm that the reset clipping planes change is not needed (at least on master branch as of this morning). The issue is indeed that the vtkGPUVolumeRayCastMapper does not handle rendering correctly when vtkCamera::UseOffAxisProjection is true. ParaView does indeed set that to true when a pvx configuration is specified and hence the bug.
To confirm this issue with vtkGPUVolumeRayCastMapper, here’s what I did.
ctVolume.vti by subsampling it. Simply using Extract Subset filter in paraview with the Sample Rate I/J/K set to 5 and saving that dataset out did the trick. Then I used this dataset from my visualization.ProgrammableFilter of course, to fix the piece request issue), I applied the Tetrahedralize filter. Now, I volume rendered the unstructured grid produced. While unstructured grid volume rendering in slow (hence the use of subsampling), it showed the volume data where I expected it to see in my test.Thank for the heads up!!!
So, applying the programmed filter plus Tetrahedralize filter will help us displaying and transforming the volume data properly in the cave?
Just want to be sure before proceeding with tests.
Hi Camilo
I don’t think the recipe Utkarsh has will give good results in general, given the speed and resolution factors. It is a good test case for him to identify where the issue is in the VTK ray-casting volume renderer.
Utkarsh, is there a simpler 3D texture based volume renderer that might work for us, or is the one we’re using as simple as it gets?
Thanks for your bug finding!
-David
Camilo, @dhl is indeed correct that the steps I mentioned are not a solution but merely a way to isolate the issue.
@dhl, I tried with vtkFixedPointVolumeRayCastMapper instead of the default vtkGPUVolumeRayCastMapper but it too has the same issue.
@martink, do you have any insight into how much effort it would be to update these mappers to respect the off axes projection? That seems to be the issue, as far as I can tell.
Shouldn’t be too hard given a test case we can run locally (e.g. a single window that uses the off axis projections) so that we can make sure it is fixed.
I would think the issue is in code like vtkOpenGLGPUVolumeRayCastMapper::vtkInternal::RenderVolumeGeometry that makes assumptions about the view plane being orthogonal to the cam_pos -> focal_point direction.
@martink @utkarsh.ayachit that very well the case might be. We have not tested the code on the CAVE, although it does work (volume rendering) in the HMD (which uses a different code path). Off axis projection changes the camera matrix, is it possible that volume mapper might not be getting the correct matrix?
The reason why I believe that’s not the case is that vtkOpenGLProjectedTetrahedraMapper uses vtkOpenGLCamera::GetKeyMatrices too and doesn’t have the same issue.
Hi Ken – Any luck with this issue in off-axis volume rendering? Thanks!
@martink, any update? @utkarsh.ayachit, any further thoughts? Thanks!
I’m adding support for oriented images in the image mappers right now. After that I’ll be looking to add oriented image support to the volume mappers. If no one has hopped onto this issue by then, I’ll try fixing it up as I add the oriented image support as it is the same basic area of code.
Awesome! Thanks!
Any progress? Have @martink, have you finished your oriented-images support? I haven’t seen any news on this off-axis volume rendering bug since your post 3 weeks ago. Thanks!
The MR is here but needs to be rebased and retested. https://gitlab.kitware.com/vtk/vtk/merge_requests/5664 I had a critical customer issue pop up that pulled me off for a week or so but hope to get that MR finished up soon and then hit the volume mapper in between some other ongoing work. Maybe next week I’ll get a chance to start up on it.
This MR https://gitlab.kitware.com/vtk/vtk/merge_requests/5770 might fix your issue. Please give it a try.
Awesome! We will try it out! Thanks!