[vtkusers] Volume rendering problem
Elvis Stansvik
elvis.stansvik at orexplore.com
Thu Aug 11 09:26:22 EDT 2016
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.
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/b6715792/attachment.html>
More information about the vtkusers
mailing list