[vtkusers] Multiple volumes rendering with vtkGPUVolumeRayCastMapper or similar

Sat Aug 27 20:10:56 EDT 2016

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/ef83b3fb/attachment.html>