[vtkusers] Volume rendering problem

Mon Aug 29 14:47:33 EDT 2016

2016-08-29 20:02 GMT+02:00 Alvaro Sanchez <alvaro.sanchez at kitware.com>:

> Alvaro is looking into this issue. Hopefully soon we will have few
>>>>> answers. The bottom line is that in a pure opengl application, we were able
>>>>> to render texture larger than 4GB but it is too early to say where the
>>>>> bottleneck is.
>>>>>
>>>>
>>>> Alright, good to know. Thanks for the info and looking forward to hear
>>>> what your findings are.
>>>>
>>>
>>>
> The problem we were running into back then was an overflow in
> ComputeScalarRange in vtkDataArray.  The patch for this is already in
> master.
>
>
>> Hi again Aashish, did you or Alvaro make any findings regarding this?
>>>
>>> I have to ask: Since you called it an "issue", do you mean that it
>>> should be possible to render volumes larger than 2048 voxels in one
>>> dimension (despite the graphics card texture size limit)?
>>>
>>
> It will definitely depend on the GPU's limit.  A single dimension of 2048
> would only work for graphics cards supporting  GL_MAX_TEXTURE_SIZE >= 2048.
>
>
>> I can also confirm that on an older system (SandyBridge, HD 3000
>> graphics), I hit the limit at 1024, I guess because of the older graphics
>> chip.
>>
>> So my question is really: Should VTK be able to render volumes that are
>> larger (in some dimension) than the maximum texture size of the GPU? Or do
>> I have to split/juggle multiple volumes to work around this myself?
>>
>
> That said, the mapper will soon support bricking (streaming the volume
> texture in blocks, and rendering those blocks in separate passes), which
> might be useful in this case.  There is an initial implementation available
> in this branch:
>
>  https://gitlab.kitware.com/vtk/vtk/merge_requests/1887 .
>

Ah thanks, that's good news and exactly the info I was looking (and hoping)
for. As I have to use VTK 7.0 currently, I'll have to work around it in my
own code, and make sure volumes are of a manageable size, but it's very
good to see that bricking in VTK is on the horizon.

Do you know if that feature could possible make it into 7.1? Or is it too
recent?

Elvis

>
> cheers,
> Álvaro
>
>
> On Mon, Aug 29, 2016 at 1:40 PM, Elvis Stansvik <
> elvis.stansvik at orexplore.com> wrote:
>
>> 2016-08-29 10:37 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>>
>>> 2016-08-11 21:30 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>
>>> :
>>>
>>>> 2016-08-11 20:38 GMT+02:00 Aashish Chaudhary <
>>>> aashish.chaudhary at kitware.com>:
>>>>
>>>>> Elvis, Robert,
>>>>>
>>>>> Alvaro is looking into this issue. Hopefully soon we will have few
>>>>> answers. The bottom line is that in a pure opengl application, we were able
>>>>> to render texture larger than 4GB but it is too early to say where the
>>>>> bottleneck is.
>>>>>
>>>>
>>>> Alright, good to know. Thanks for the info and looking forward to hear
>>>> what your findings are.
>>>>
>>>
>>> Hi again Aashish, did you or Alvaro make any findings regarding this?
>>>
>>> I have to ask: Since you called it an "issue", do you mean that it
>>> should be possible to render volumes larger than 2048 voxels in one
>>> dimension (despite the graphics card texture size limit)?
>>>
>>
>> I can also confirm that on an older system (SandyBridge, HD 3000
>> graphics), I hit the limit at 1024, I guess because of the older graphics
>> chip.
>>
>> So my question is really: Should VTK be able to render volumes that are
>> larger (in some dimension) than the maximum texture size of the GPU? Or do
>> I have to split/juggle multiple volumes to work around this myself?
>>
>> Elvis
>>
>>
>>>
>>> Because at the moment I'm working under the assumption that it should
>>> not be possible, and I'm trying to work around it in our application by
>>> trying to work with multiple smaller volumes instead. But if it turns out
>>> it's a bug/unintended limitation in VTK, I might not have to do that (if
>>> it's fixed/can be worked around).
>>>
>>> Thanks in advance,
>>> Elvis
>>>
>>>
>>>>
>>>> Elvis
>>>>
>>>>
>>>>>
>>>>> - Aashish
>>>>>
>>>>> On Thu, Aug 11, 2016 at 11:14 AM RobertS <spir.robert at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> it's also 2048. According to this
>>>>>> https://developer.apple.com/opengl/capabilities/ AMD graphics should
>>>>>> have
>>>>>> the limit at 8192-16348, but right now I don't have any to test it.
>>>>>> (MAX_3D_TEXTURE_SIZE attribute)
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context: http://vtk.1045678.n5.nabble.c
>>>>>> om/Volume-rendering-problem-tp5739662p5739683.html
>>>>>> Sent from the VTK - Users mailing list archive at Nabble.com.
>>>>>> _______________________________________________
>>>>>> 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
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> 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
>>
>>
>
>
> --
> Alvaro Sanchez
> Kitware, Inc.
> Senior R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4901
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160829/9d0e9164/attachment-0001.html>