[vtk-developers] Volume rendering very large StructuredGrids

[David Gobbi]

Hi Jim,

The FixedPointVolumeMapper is known to produce different results
depending on the number of threads that are used:

http://www.vtk.org/Bug/view.php?id=12115

Try setting the number of threads to one to see if that changes your results:
vtkMultiThreader::SetGlobalDefaultNumberOfThreads(1);

 - David


On Wed, Apr 11, 2012 at 5:42 AM, Jim Geach <jimgeach at physics.mcgill.ca> wrote:
>
> thanks, i can certainly test this pretty soon and i'll let you know how i get on.
>
> another issue i've been noticing is jagged/pixelated edges in some parts of the image (again, using FixedPoint). these are much larger than the voxel size, and are not uniform across the image. it happens on grids where that 32bit overflow issue shouldn't have been a problem.
>
> there is an example here: http://dl.dropbox.com/u/59256622/JaggedExample.png
> with the issue highlighted.
>
> i thought it might be something to do with the way image compression, or sample lengths, or space leaping, but i can't seem to get this to go away. this effect is quite undesirable in our application, so i'd like to try to get to the bottom of it if possible.
>
> thanks, jim
>
> On 2012-04-10, at 11:13 PM, David Gobbi wrote:
>
>> Yes, both the mapper and the space-leaper filter had 32-bit overflow bugs.
>> These bugs were reported a couple months ago, and the fix was merged
>> a few days ago, just before the VTK tree was modularized.
>>
>> To update your tree to the merge commit, which will bring in all the
>> VTK 6 pipeline changes but none of the modularization changes, do
>> the following:
>>
>> git fetch origin master
>> git merge fc4c570a
>>
>> To avoid all the VTK 6 pipeline changes, you can try cherry-picking
>> the fix (it's commit a3feef0d) but no guarantees.
>>
>> If you get a chance to test the fix, please report your findings.  The
>> more testing that this code gets, the better.
>>
>> - David
>>
>>
>> On Tue, Apr 10, 2012 at 8:03 PM, Jim Geach <jimgeach at physics.mcgill.ca> wrote:
>>>
>>> Dear developers,
>>>
>>> I am using vtkFixedPointVolumeRayCastMapper to render very large (1536^3) volumes with two data components. So far, I have been unsuccessful in properly rendering volumes when the number of elements >MAX_INT. I'm using v5.11.0.
>>>
>>> Independent checks (e.g. simple 2D projections of the data) show that the problem is not with the data, but in the rendering itself.
>>>
>>> I have built VTK with USE_64BIT indexing ON, and the volume rending actually completes and dumps an image without complaint. However, but the image is garbled: it looks broadly correct, but some chunks are missing, there are large discontinuities, etc.
>>>
>>> Is this a bug? e.g. is there some int casting within a function of vtkFixedPointVolumeRayCastMapper (space leaping?) or associated volume rendering code that prevents VTK from properly volume rendering of 64-bit class data arrays?
>>>
>>> Any help on this issue would be very gratefully received!
>>>
>>> Thanks, Jim
>