[vtkusers] Multiple volumes rendering with vtkGPUVolumeRayCastMapper or similar

Sat Aug 27 20:12:44 EDT 2016

... with the proper test :)

On Aug 27, 2016 8:10 PM, "Alvaro Sanchez" <alvaro.sanchez at kitware.com>
wrote:

> Sounds good, let us know if you still encounter the same issue with your
> proper
>
> On Aug 26, 2016 12:59 PM, "Elvis Stansvik" <elvis.stansvik at orexplore.com>
> wrote:
>
>> 2016-08-26 14:15 GMT+02:00 Alvaro Sanchez <alvaro.sanchez at kitware.com>:
>>
>>> Indeed Elvis, to clarify the confusion, I was referring to overlapping
>>> volumes in my last email. As mentioned in (http://public.kitware.com/pip
>>> ermail/vtkusers/2016-February/094333.html),  it is possible to add
>>> multiple vtkVolumes to a single vtkRenderer, this would work if they are
>>> not overlapping.
>>>
>>> >Would the obstructed voxels of the >furthest volume not be visible at
>>> all, or >would I be able to see them "through" >the nearest volume?
>>>
>>> You should see through (alpha blending is on during volume rendering).
>>>
>> Thanks for clarifying Alvaro, that's reassuring. I did make a quick test
>> with two volumes before I left work today and couldn't get the second one
>> to show up, but it's quite likely I made something wrong since I was in a
>> rush. I'll make a proper test when I'm back at work on Monday.
>>
>> Elvis
>>
>>
>>> On Aug 26, 2016 3:04 AM, "Elvis Stansvik" <elvis.stansvik at orexplore.com>
>>> wrote:
>>>
>>>> 2016-08-26 8:38 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>
>>>> :
>>>>
>>>>> Den 26 aug. 2016 5:06 fm skrev "Alvaro Sanchez" <
>>>>> alvaro.sanchez at kitware.com>:
>>>>> >
>>>>> > Hi Alberto,
>>>>> >
>>>>> > as you have noticed, multi-volume rendering is currently not
>>>>> supported in the vtkGPUVolumeRayCastMapper.  If you are building VTK with
>>>>> OpenGL2 however, it supports independent components so (depending on your
>>>>> use case) you might be able to render up to 4 volumes (one per component),
>>>>> provided you can arrange them in a four component array (this has the
>>>>> limitation that each component will need to have the same dimensions).
>>>>> That said, we are working on giving support for multiple volumes in the
>>>>> next VTK release.
>>>>>
>>>>> I have to jump in and ask: I was under the impression that multiple
>>>>> volumes was supported, as long as they don't intersect eachother in 3D
>>>>> space? But you're saying it's not possible at all?
>>>>>
>>>> I found the mail by Aashish which led me to believe this was possible:
>>>>
>>>>     http://public.kitware.com/pipermail/vtkusers/2016-February/0
>>>> 94333.html
>>>>
>>>> If it is actually possible, I have a question about the result I would
>>>> get: If I had multiple volumes in the same view (non-intersecting) and the
>>>> camera was positioned such that one of the volumes is in front of the other
>>>> relative to the camera. Would the obstructed voxels of the furthest volume
>>>> not be visible at all, or would I be able to see them "through" the nearest
>>>> volume?
>>>>
>>>> Elvis
>>>>
>>>>
>>>>> If so I'm in a bit of trouble myself, as I was planning on doing that
>>>>> soon :(
>>>>>
>>>>> In my case I have multiple volumes (coming from different readers)
>>>>> that I want to render next to eachother (but not overlapping anywhere).
>>>>>
>>>>> If that's really not possible, I'll have to rethink my pipeline and
>>>>> redesign my custom reader to work with multiple files instead (and output a
>>>>> single volume). The problem with this is that I might want to show a volume
>>>>> that is larger than 2048 voxels in one dimension, which is not possible, at
>>>>> least not on intel, due to GPU texture size limitations (see my semi-recent
>>>>> thread about this). I had hoped that using multiple volumes would be a way
>>>>> to get around this.
>>>>>
>>>>> Thanks in advance,
>>>>> Elvis
>>>>>
>>>>> >
>>>>> > With regards to the solution you mentioned (
>>>>> https://github.com/bozorgi/VTKMultiVolumeRayCaster), you could use it
>>>>> temporarily if it would solve your problem better than fitting the volumes
>>>>> as independent components.  It seems to implement a similar approach as we
>>>>> would do (connecting various inputs/ properties to the mapper) so it should
>>>>> not be extremely difficult to migrate to the official implementation in the
>>>>> future.  I have not tried it myself but please do let us know if you have
>>>>> any remarks once you try it.  As far as I know, if the python bindings are
>>>>> not explicitly disabled for these new classes then they should be also
>>>>> wrapped.
>>>>> >
>>>>> > Regads,
>>>>> > Álvaro
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >>
>>>>> >> ---------- Forwarded message ----------
>>>>> >> From: amdelaossa <adelaossa at gmail.com>
>>>>> >> Date: Thu, Aug 25, 2016 at 10:00 AM
>>>>> >> Subject: [vtkusers] Multiple volumes rendering with
>>>>> vtkGPUVolumeRayCastMapper or similar
>>>>> >> To: vtkusers at vtk.org
>>>>> >>
>>>>> >>
>>>>> >> Dear all,
>>>>> >> we (a research team in DESY, Germany) are strongly interested in
>>>>> rendering multiple data volumes in the same view with VTK.
>>>>> >> We chose VTK for our 3D visualisation project on beam-plasma
>>>>> interactions due to its extended functionality and features,
>>>>> >> its open source character and because it is written in C++ with
>>>>> bindings for python.
>>>>> >> However, we will require to show multiple volumes in the same view
>>>>> (representing the data of different particle species in our simulations).
>>>>> >> We are currently using a vtkGPUVolumeRayCastMapper object for each
>>>>> data set, which is then connected to a vtkVolume.
>>>>> >> The different vtkVolume objects are then added to the vtkRenderer.
>>>>> >> We have tried to use different vtkRenderer objects for the
>>>>> different vtkVolumes,
>>>>> >> but still only the first volume on the first vtkRenderer is
>>>>> displayed.
>>>>> >>
>>>>> >> Searching in the web, we have found the following (potential)
>>>>> solution:
>>>>> >> https://github.com/bozorgi/VTKMultiVolumeRayCaster
>>>>> >> which is published here:
>>>>> >> http://www.ncbi.nlm.nih.gov/pubmed/24841148
>>>>> >>
>>>>> >> It consists on new vtk classes to handle multiple volumes rendering.
>>>>> >> As it might work well for our purposes, we would like to ask your
>>>>> opinion about this new classes.
>>>>> >> Are you planning to incorporate something like this in the official
>>>>> VTK distribution soon?
>>>>> >> If not, we will be interested in incorporating this new class into
>>>>> our personal VTK installation.
>>>>> >> Then the question is: Will be the python bindings automatically
>>>>> generated for these new classes?
>>>>> >>
>>>>> >> Thanks a lot for your support!
>>>>> >>
>>>>> >> Best regards,
>>>>> >> Alberto
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> 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
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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/20160827/d6604d22/attachment.html>