[vtkusers] Volume rendering problem

Thu Aug 11 09:32:59 EDT 2016

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

> 2016-08-11 15:20 GMT+02:00 Ken Martin <ken.martin at kitware.com>:
>
>> Some systems only support up to 4096 as a 3D texture dimension, maybe try
>> 300x300x4096 -Ken
>>
>
> Ah, but in the test case, the working volume is 2000x300x300, while the
> non-working one is 2500x300x300. So both volumes in the test case are well
> below 4096 (though in the end, I want to render a 5000x300x300 volume).
>
> I just had a collegue try the test case. He's on a pretty similar (but
> probably slightly beefier) intel graphics chipset, and he could reproduce
> the problem.
>
> It would be very interesting if someone could try the test case on a
> machine with more powerful graphics.
>

An interesting this is that, if I change

        opacity->AddPoint(0.0, 0.00);

in my test case to

        opacity->AddPoint(0.0, 0.01);

i.e. raising the left endpoint of my opacity transfer function just a
little bit, I get _some_ rendering. But from the looks of it, the rendering
I get is as if all the scalars of the vtkImageData is 0.0, even if they
evidently are not.

Elvis

> Elvis
>
>
>>
>> On Thu, Aug 11, 2016 at 8: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
>>>
>>>
>>
>>
>> --
>> Ken Martin PhD
>> Chairman & CFO
>> Kitware Inc.
>> 28 Corporate Drive
>> Clifton Park NY 12065
>> 518 371 3971
>>
>> This communication, including all attachments, contains confidential and
>> legally privileged information, and it is intended only for the use of the
>> addressee.  Access to this email by anyone else is unauthorized. If you are
>> not the intended recipient, any disclosure, copying, distribution or any
>> action taken in reliance on it is prohibited and may be unlawful. If you
>> received this communication in error please notify us immediately and
>> destroy the original message.  Thank you.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160811/aadcff50/attachment.html>