[vtkusers] Requirements for multiple volumes in one render window

Fri Mar 17 18:33:36 EDT 2017

Den 17 mars 2017 3:39 em skrev "Alvaro Sanchez" <alvaro.sanchez at kitware.com
>:
>
> 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.

Wow, that's great news!

Elvis

>
> Á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/22e95a9f/attachment.html>