[vtkusers] Multiple volumes rendering with vtkGPUVolumeRayCastMapper or similar

Elvis Stansvik elvis.stansvik at orexplore.com
Fri Aug 26 12:59:52 EDT 2016


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/
> pipermail/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/
>> 094333.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/20160826/df2d095e/attachment.html>


More information about the vtkusers mailing list