[vtkusers] Volume rendering problem

Thu Aug 11 10:35:06 EDT 2016

2016-08-11 16:19 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:

> 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.
>

By inserting a vtkExtractVOI between my reader and mapper, and then loading
my problematic 300x300x2500 volume, I was able to debug some more:

With

    extract->SetVOI(0, 299, 0, 299, 0, 2047);

it works, while with:

    extract->SetVOI(0, 299, 0, 299, 0, 2048);

it does not.

2048 is such a special number that I don't think it's a coincidence that
this is the breaking point. It is probably a texture size limitation of my
graphics card then? :( (it's a Intel HD 4400 on a Haswell laptop).

Elvis

> 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/8d12f646/attachment.html>