[vtkusers] Requirements for multiple volumes in one render window

[Jaime Campos]

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...).

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/20160304/42f2ab12/attachment.html>