[vtkusers] Requirements for multiple volumes in one render window

Tue Mar 14 12:09:08 EDT 2017

2016-04-20 15:04 GMT+02:00 Elvis Stansvik <elvis.stansvik at orexplore.com>:
> 2016-03-04 12:00 GMT+01: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.
>
>
> Any news on how you chose to prioritize this? Is it possible there will be
> something in a 7.x point release, or is it further off?

I'm still interested in how/if you prioritized this, or if there's
even some work going on in some branch?

Elvis

>
> Elvis
>
>>
>>
>> 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
>>> >
>>> >>
>>> >> - Aashish
>>> >>
>>> >> >
>>> >> > Elvis
>>> >> >
>>> >> >>
>>> >> >> Elvis
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > 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
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> | Aashish Chaudhary
>>> >> | Technical Leader
>>> >> | Kitware Inc.
>>> >> | http://www.kitware.com/company/team/chaudhary.html
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> | Aashish Chaudhary
>>> | Technical Leader
>>> | Kitware Inc.
>>> | http://www.kitware.com/company/team/chaudhary.html
>>
>>
>