[vtkusers] Requirements for multiple volumes in one render window

Fri Mar 17 10:39:52 EDT 2017

Hi Elvis,

I don't think it would make it to 8.0 but it is one of the next things on
the list to add to
the mapper, so most likely 8.x.  I will ping you once there is a branch for
testing.

Álvaro

On Tue, Mar 14, 2017 at 12:09 PM, Elvis Stansvik <
elvis.stansvik at orexplore.com> wrote:

> 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
> >>
> >>
> >
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20170317/4a48e098/attachment.html>