[vtkusers] Volume rendering problem

Thu Aug 11 10:19:17 EDT 2016

2016-08-11 16:07 GMT+02:00 Mike Chinander <chinander at gmail.com>:

> I was going to suggest something along this line. What happens if you use
> vtkVolumeRayCastMapper instead of vtkGPUVolumeRayCastMapper (not as a
> solution to your problem but to narrow down what is causing your problem).
>

I was going to try that, but since vtkVolumeRayCastMapper does not support
rendering float data directly, I'd have to convert my two test files to
unsigned short instead, and also store it in a different format, since my
HDF5 reader is pretty basic and only works with float input and output so
far.

I might do that actually, since I'm suspecting more and more that this
might be the issue.

volumeMapper->GetMaxMemoryInBytes() reports 128 MB, of which I think it'll
use 75% by default, so 96 MB. Anyone know off-hand if this would be too
little GPU memory to render a 2500x300x300 volume?

In any case, shouldn't VTK print some error if it can't allocate enough GPU
memory? In fact, I seem to remember getting some error like that in the
past. With my problematic volume in this case, VTK is not printing anything.

I'll try to find a machine with more powerful graphics and try my test case
there. If someone has the time to try it on their machine though, I'd
appreciate it a lot. It only requires VTK7 with OpenGL2 rendering backend
and the HDF5 library (C++ interface) to compile.

Elvis

> --Mike Chinander
>
> On Thu, Aug 11, 2016 at 7:44 AM, Elvis Stansvik <
> elvis.stansvik at orexplore.com> wrote:
>
>> 2016-08-11 13:26 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>
>>> 2016-08-11 11:37 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>
>>> :
>>>
>>>> 2016-08-11 11:18 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com
>>>> >:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm wrestling with a volume rendering problem.
>>>>>
>>>>> I've set up a very basic pipeline that just renders a volume.
>>>>>
>>>>> As source it uses a custom reader I wrote that loads a volume from a
>>>>> HDF5 dataset (float).
>>>>>
>>>>> It seemed to be working fine with the volume I had been testing with
>>>>> (see attached works_fine.png), which was a 120x120x2000. In addition to the
>>>>> the rendering itself, the screenshot shows a histogram plot I was using for
>>>>> debugging, as well as some editor controls I use to modify the
>>>>> color/opacity transfer function.
>>>>>
>>>>> I then tested with another volume which is larger (300x300x5000), but
>>>>> apart from that has pretty much the same characteristic for its scalar
>>>>> values as the first one, and all of a sudden I don't see anything. See the
>>>>> attached not_working.png, which shows the setup using the problematic
>>>>> volume.
>>>>>
>>>>> As you can in the histogram, there's a lot of voxel values roughly
>>>>> around 1, much like in the first volume, so I would expect that with the
>>>>> same transfer functions (black color, and an opacity ramp from 0.0,0.0 up
>>>>> to 5.0,1.0), I should see _something_.
>>>>>
>>>>> I'm pretty sure I'm missing something basic here, but does anyone have
>>>>> an idea why I get the expected rendering with my smaller volume, but not
>>>>> with the bigger one?
>>>>>
>>>>> Thanks a lot for any advice!
>>>>>
>>>>
>>>> Sorry, shortly after sending this I think I got one step closer to an
>>>> explanation. The file from which I load this second, larger, volume is
>>>> actually a concatenation of several files, and I just tried loading one of
>>>> the files separately and it worked fine (the rendering looks as expected).
>>>> So something is probably wrong in the script I use for concatenating HDF5
>>>> files. I'll do some digging there.
>>>>
>>>
>>> There seems to be nothing wrong with the concatenation script I'm using.
>>> I've now tried creating smaller volumes by not concatenating the full set
>>> of files, and up until a resulting volume of around ~2500x300x300 it works
>>> okay, but if I extend the volume more than that, the rendering fails like
>>> described previously. It's quite strange :/ And I don't think I'm hitting
>>> some out-of-memory condition inside VTK, since it normally prints nice
>>> errors and crashes if that happens.
>>>
>>
>> I'm beginning to think that maybe I'm running out of graphics memory?
>> Could this be a symptom of that?
>>
>> I've now created a minimal test case, and would very much appreciate if
>> someone could try it out to see if they get the same problem:
>>
>> Download
>>
>>    https://drive.google.com/open?id=0B1a2u6qVxaL7M1B6bFhreE1RQW8
>>
>> and extract the .tar archive (162 MB since it includes two volumes). Then
>>
>>    cmake .
>>    make
>>    ./voltest working.hdf5
>>    ./voltest not_working.hdf5
>>
>> For me, rendering of working.hdf5 works, but not rendering of
>> not_working.hdf5. Is that the case also for you?
>>
>> The only difference between the two volumes is that not_working.hdf5 is
>> slightly larger than working.hdf5 (2500 voxels high vs 2000). Apart from
>> that they were both created in the same way.
>>
>> Thanks a lot in advance,
>> Elvis
>>
>>
>>> Elvis
>>>
>>>
>>>> Elvis
>>>>
>>>>
>>>>>
>>>>> Elvis
>>>>>
>>>>> PS. If you're confused by the range of the vtkAxisActor that you see
>>>>> in the screenshots, when comparing to the the volume sizes I stated above,
>>>>> it's because my custom render currently hardcodes the spacing to 0.2. DS.
>>>>>
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160811/c8616d1f/attachment.html>