[vtkusers] Multiple volumes rendering with vtkGPUVolumeRayCastMapper or similar
alvaro.sanchez at kitware.com
Fri Aug 26 08:15:14 EDT 2016
Indeed Elvis, to clarify the confusion, I was referring to overlapping
volumes in my last email. As mentioned in (
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).
On Aug 26, 2016 3:04 AM, "Elvis Stansvik" <elvis.stansvik at orexplore.com>
> 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:
> 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
>> 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,
>> > 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
>> > 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
>> >> 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
>> >> Please keep messages on-topic and check the VTK FAQ at:
>> >> 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
>> > Please keep messages on-topic and check the VTK FAQ at:
>> > 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...
More information about the vtkusers