[vtkusers] Multiple volumes rendering with vtkGPUVolumeRayCastMapper or similar

Elvis Stansvik elvis.stansvik at orexplore.com
Mon Aug 29 07:53:56 EDT 2016 

2016-08-29 13:36 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:

> 2016-08-29 13:17 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
>
>> 2016-08-28 2:10 GMT+02:00 Alvaro Sanchez <alvaro.sanchez at kitware.com>:
>>
>>> Sounds good, let us know if you still encounter the same issue with your
>>> proper
>>>
>> I just made another test, and indeed rendering of two volumes seems to
>> work.
>>
>> However, if you look at the attached short screencast (two_volumes.ogv),
>> where I move the camera around such that one volume is in front of the
>> other, the volume that is in the back is not visible, instead the
>> background color (white) is shown in this area.
>>
>> Any idea what is going on here? I would have expected to be able to see
>> the other volume through the first one. (The volumes in this screencast are
>> not intersecting eachother).
>>
>
> To give more details: In this example, it's two vtkVolumes, each have
> their own vtkGPUVolumeRayCastMapper and vtkVolumeProperty, but they're
> added to the same vtkRenderer. I've also tried having them share the same
> mapper and property, but the result is the same.
>
> Must I do something with layers on the vtkRenderer? Or is there some
> setting to activate alpha channel on the volumes?
>

It seems I just had to set the sorting order of the frustum culler to
back-to-front with:

        auto frustumCoverageCuller =
vtkFrustumCoverageCuller::SafeDownCast(renderer()->GetCullers()->GetLastItem());
        frustumCoverageCuller->SetSortingStyleToBackToFront();

With that, it works (see attached screencast).

Does that make sense? I found that tip at

    http://marc.info/?l=vtkusers&m=131843232022152&w=2

Elvis


> Elvis
>
>
>> Thanks in advance,
>> Elvis
>>
>>
>>>
>>> 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/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/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/20160829/b6d06bd6/attachment.html>

More information about the vtkusers mailing list