[vtkusers] Requirements for multiple volumes in one render window

Wed Apr 20 09:02:10 EDT 2016

2016-03-04 19:37 GMT+01:00 Jaime Campos <jaimefbc at gmail.com>:

> Hi David,
>
> Thanks for the answer. I read the publication you proposed but it seems
> the solution does not entirely
> fulfill our needs. As far as I understood, the authors claim to have
> created a concrete volume mapper class that handles multiple dataset inputs
> instead of one - which they called vtkOpenGLGPUMultiVolumeMapper. However,
> they are limited to only two datasets, meaning it is not a generalized
> approach to have 2 or more volumes in the scene.
>
> " (...) the generalization to any number of input datasets would require
> sending several arrays of 3D and 2D textures to the graphic card for the
> input datasets and their associated transfer functions (...)"
>
> Moreover, since each mapper only maps to one vtkVolume, we also lose the
> possiblity to have several vtkVolume props in the scene (corresponding to
> the different datasets), thus rendering impossible the individual
> interaction for each prop (pick, move, etc...).
>

I'd just like to add that I don't think this solution will quite fulfill
our needs either, much for the same reasons Jaime brings up.

Elvis

>
> Best Regards,
> Jaime Campos
>
> 2016-03-04 13:41 GMT+00:00 David Gobbi <david.gobbi at gmail.com>:
>
>> There is a VTK journal publication that claims to render multiple volumes:
>> http://www.vtkjournal.org/browse/publication/856
>> Is there anything of significance there?
>>
>>  - David
>>
>>
>> On Fri, Mar 4, 2016 at 6:27 AM, Jaime Campos <jaimefbc at gmail.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I'm a new subscriber to this mailing list and I was reading this thread,
>>> and I'm also interested in this functionality.
>>> Currently I am using vtkOpenGLVolumeTextureMapper3D for two different
>>> volumes that intersect in 3D space, and it happens to render the volumes
>>> correctly by blending opacities and doing the correct compositioning
>>> (because of the slicing it does internally, I believe, though not being
>>> perfect). This also allows me to pick and interact with the vtkVolume props
>>> independently, which is a must have for the functionality I am developing.
>>>
>>> The problem, as far as I know, is that with VTK 7.0 new rendering
>>> backend (OpenGL 2), this mapper is no longer supported and the new GPU
>>> mappers available, unfortunately, are not solving this issue yet. This
>>> feature could also be applied to the iOS GPU volume mapper example. I wish
>>> I could help you adding this functionality, but unfortunately I'm not
>>> familiar with the internals of VTK in these modules, but I'm eager to
>>> learn. I hope I can bump up the priority of this request !
>>>
>>> Thank you,
>>>
>>> Best Regards,
>>>
>>> Jaime Campos
>>>
>>> 2016-03-04 11:00 GMT+00:00 Elvis Stansvik <elvis.stansvik at orexplore.com>
>>> :
>>>
>>>> 2016-03-02 21:16 GMT+01:00 Aashish Chaudhary <
>>>> aashish.chaudhary at kitware.com>:
>>>>
>>>>> Elvis,
>>>>>
>>>>> thanks for the detailed information. I thought about a way of doing
>>>>> this. Basically, I think the mapper has to take multiple inputs and if
>>>>> multiple inputs are present, then we will construct a BBox around it
>>>>> and used that for traversing. Now, internally, we would have to
>>>>> transform the data position to each volume so that we can perform the
>>>>> lookup and set some rules on how to perform compositing (replace,
>>>>> modulate etc.). I will talk to the team here and will add in our todo
>>>>> but we would have check on the priority of it.
>>>>>
>>>>
>>>> Thanks a lot for looking into this and bringing it up with the team. It
>>>> would be a very welcome addition for us, and surely to some others as well.
>>>>
>>>> The approach you outline seems sound to me, but I am a layman in
>>>> visualization :)
>>>>
>>>>
>>>>>
>>>>> If you want to help us with this then I am more happy to guide you
>>>>> with the process. It won't be very difficult but will require some
>>>>> careful changes to the existing mapper.
>>>>>
>>>>
>>>> I'm afraid we're in the middle of a product launch here at work, so I'm
>>>> quite swamped. This is only a small part of the application I'm building.
>>>> I'm also completely new to VTK and visualization in general, so I'm also
>>>> afraid it would be more difficult and time consuming for me than you might
>>>> think (as opposed to a seasoned VTK dev).
>>>>
>>>> I'm of course prepared to try out any changes you do on our data sets,
>>>> should you decide to work on this.
>>>>
>>>> Thanks again,
>>>> Elvis
>>>>
>>>>
>>>>> Thanks,
>>>>>
>>>>>
>>>>> On Mon, Feb 29, 2016 at 11:46 AM, Elvis Stansvik
>>>>> <elvis.stansvik at orexplore.com> wrote:
>>>>> > 2016-02-29 16:32 GMT+01:00 Aashish Chaudhary
>>>>> > <aashish.chaudhary at kitware.com>:
>>>>> >>
>>>>> >> Hi Elvis,
>>>>> >>
>>>>> >> On Sat, Feb 27, 2016 at 12:06 PM, Elvis Stansvik
>>>>> >> <elvis.stansvik at orexplore.com> wrote:
>>>>> >> > 2016-02-25 17:10 GMT+01:00 Elvis Stansvik
>>>>> >> > <elvis.stansvik at orexplore.com>:
>>>>> >> >>
>>>>> >> >> Hi,
>>>>> >> >>
>>>>> >> >> From searching around, I think I've gathered that to render
>>>>> multiple
>>>>> >> >> volumes in a single window, each volume must have its own mapper
>>>>> and
>>>>> >> >> volume
>>>>> >> >> property. They can't share mapper or property.
>>>>> >> >>
>>>>> >> >> My question is whether I must use separate renderers for each
>>>>> volume as
>>>>> >> >> well, or if I can use the same renderer for them all?
>>>>> >> >>
>>>>> >> >> Also, I did read something in an old post about problems with
>>>>> rendering
>>>>> >> >> multiple volumes that intersect (share a voxel). Is this still a
>>>>> >> >> problem?
>>>>> >> >> I'm using VTK 6.2 and the vtkVolumeRayCastMapper.
>>>>> >> >>
>>>>> >> >> Thanks in advance!
>>>>> >> >
>>>>> >> >
>>>>> >> > Including Donny's answer here, to keep the thread intact:
>>>>> >> >
>>>>> >> >> See this thread:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> http://vtk.1045678.n5.nabble.com/Rendering-multiple-volumes-td5734685.html#a5734971
>>>>> >> >
>>>>> >> > Thanks, that clears some things up, and brings up some
>>>>> workarounds. That
>>>>> >> > thread was from oct/nov last year, so I guess it is still the
>>>>> case that
>>>>> >> > proper rendering of multiple volumes that share voxels in 3D
>>>>> space is
>>>>> >> > not
>>>>> >> > possible? (even with 7.0?).
>>>>> >>
>>>>> >> It depends what you define proper. If you have two volumes and they
>>>>> >> share the exact same space, you can combine them into one volume.
>>>>> When
>>>>> >> they share the same space but do not overlap that's when things get
>>>>> >> tricky since then the outcome depends on how do you want to handle
>>>>> >> this disparity. There could be some other ways such as you combine
>>>>> the
>>>>> >> volume into one. At the rendering level it could get tricky.
>>>>> >>
>>>>> >> What exactly you are trying to do.
>>>>> >
>>>>> >
>>>>> > I see, what I would expect I think is composite rendering of the
>>>>> voxels
>>>>> > using some composite rendering function / blending mode (perhaps
>>>>> > configurable?).
>>>>> >
>>>>> > Sorry if my use case wasn't clear, I'm attaching a rough sketch I
>>>>> did just
>>>>> > now which should explain it better.
>>>>> >
>>>>> > Each of our volumes is a piece of a drill core (see my photo
>>>>> previously in
>>>>> > this thread). The pieces were scanned stacked on top of each other
>>>>> in a
>>>>> > plastic tube inside our machine. During scanning, they are not
>>>>> necessarily
>>>>> > aligned properly (as shown in the sketch, and also in the photo).
>>>>> >
>>>>> > We will do some algorithmic alignment of the volumes, but we must
>>>>> also allow
>>>>> > the user to override / supplement the automatic alignment when it
>>>>> fails.
>>>>> > This means the user should be able to rotate and move (along Z axis)
>>>>> the
>>>>> > pieces until they align. It's like a pussle with pieces of a drill
>>>>> core :)
>>>>> >
>>>>> > While the user is doing this, the volumes may intersect (noone is
>>>>> perfect on
>>>>> > the first try). This is why I'm asking about rendering multiple
>>>>> volumes that
>>>>> > partially intersect in 3D space.
>>>>> >
>>>>> > It's very desirable that the user can see inside the volumes while
>>>>> doing
>>>>> > this manual alignment, since the features (cracks, density
>>>>> variations, ...)
>>>>> > inside the rocks may be what guides the user in aligning the pieces
>>>>> > properly. That's why I don't like the idea of letting the user work
>>>>> with
>>>>> > extracted isosurfaces or similar instead.
>>>>> >
>>>>> > Hope this clears things up a little!
>>>>> >
>>>>> > Elvis
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160420/1527d21b/attachment.html>