[vtkusers] From vtkFixedPointVolumeRayCastMapper to vtkKWEGPUVolumeRayCastMapper

Wed Feb 3 14:51:43 EST 2010

Hi Fauze,

I'm not sure why you are addressing this to me, since I'm not involved
in vtkEdge development.  My guess, though, is that Kitware is only
going to support the methods that are in the vtkVolumeMapper base
class.

   David

On Wed, Feb 3, 2010 at 12:38 PM, Fauze Polpeta <fauze.polpeta at gmail.com> wrote:
> Dear David;
> In our lab, we started to evaluate the vtkKWEGPUVolumeRayCastMapper but the
> sample application we consider for that purpose was originally implemented
> using the vtkFixedPointVolumeRayCastMapper. Consequently, we are facing
> some difficulties to switch to vtkKWEGPUVolumeRayCastMapper since these two
> classes of  mappers do not share the same interface. Methods like...
> 'GetRayCastImage'
> 'GetScalarOpacityTable'
> 'PerVolumeInitialization'
> 'PerSubVolumeInitialization'
> 'PerImageInitialization'
> 'DisplayRenderedImage'
> 'RenderSubVolume'
> 'OldSampleDistance'
> 'AbortRender'
> ...are NOT common among the other volume mappers.
> Any tips or advices?
> Best Regards
> Fauze
>
> PS.: Have Kitware considered the possibility of having a new mapper like the
> vtkFixedPointVolumeRayCastMapper but implemented on top of the GPU Ray
> Casting support provided by VTKEdge?
>
>> > On Fri, Jan 22, 2010 at 5:33 PM, David Gobbi <david.gobbi at gmail.com>
>> > wrote:
>> >>
>> >> I just starting working with VTKEdge myself... but I'm pretty sure
>> >> that you wouldn't have to re-write much code.  The interface to the
>> >> VTKEdge volume rendering classes is pretty much identical to the VTK
>> >> ones.  Also, all they require is OpenGL 2.0, so you don't have to
>> >> install any third-party GPU packages (when you compile VTKEdge it will
>> >> ask for CUDA, but CUDA is not required for volume rendering so just
>> >> turn CUDA off).
>> >>
>> >> So it's not quite "just" a new backend, but your application should
>> >> only need minimal modifications.
>> >>
>> >>   David
>> >>
>> >>
>> >> On Fri, Jan 22, 2010 at 3:08 PM, Fauze Polpeta
>> >> <fauze.polpeta at gmail.com>
>> >> wrote:
>> >> > Right David...I will try the two alternatives you mentioned:
>> >> > 1) Texture volume rendering
>> >> > 2) VTKEdge
>> >> > One last question: In order to achieve GPU-based ray casting I just
>> >> > have
>> >> > to
>> >> > configure and "embed" VTKEdge into my project or have to re-write my
>> >> > volume
>> >> > rendering application? In orther words, for GPU-based ray casting
>> >> > VTKEdge is
>> >> > saw as a GPU backend interface library, or/and as a new set of
>> >> > abstractions/filters to be deployed by the programmer?
>> >> > Thank you so much
>> >> > My Best Regards
>> >> > Fauze
>> >> >
>> >> > On Fri, Jan 22, 2010 at 7:47 PM, David Gobbi <david.gobbi at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> Hi Fauze,
>> >> >>
>> >> >> I've written surgical tracking application with volume rendering,
>> >> >> and
>> >> >> I've always used texture volume rendering in preference to ray
>> >> >> casting
>> >> >> in order to avoid the issues that you describe, since the LOD
>> >> >> approach
>> >> >> doesn't work very well when the tools are in constant motion.  For
>> >> >> our
>> >> >> next generation of surgical applications, we intend to use VTKEdge
>> >> >> for
>> >> >> doing GPU-based ray casting.
>> >> >>
>> >> >> Mixing pure OpenGL with VTK isn't a good idea, since you can't
>> >> >> really
>> >> >> know what the OpenGL state will be.  Also, if you're instruments
>> >> >> ever
>> >> >> intersect the volume (as I'm sure they would) you will get an
>> >> >> incorrect rendering unless you allow VTK to properly intermix the
>> >> >> polygon rendering with the the volume.
>> >> >>
>> >> >> In short: if you really need to use ray casting, try out VTKEdge.  I
>> >> >> don't think it's a good idea to try to write your own
>> >> >> polydata/volume
>> >> >> intermixing code.
>> >> >>
>> >> >>    David
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Fri, Jan 22, 2010 at 2:32 PM, Fauze Polpeta
>> >> >> <fauze.polpeta at gmail.com>
>> >> >> wrote:
>> >> >> > Thanks for your support David and sorry for the cross-post...I was
>> >> >> > wondering
>> >> >> > if one could image some core-based solution.
>> >> >> > In our case a medical application is being prototyped and the
>> >> >> > ray-cast
>> >> >> > volume was preferred for volumetric reconstruction. The point is
>> >> >> > that
>> >> >> > our
>> >> >> > application is connected to a device that tracks surgical
>> >> >> > instruments
>> >> >> > that
>> >> >> > are represented by polydata. So, theoretically, we can't abdicate
>> >> >> > of
>> >> >> > the
>> >> >> > ray-casting while moving these tools during a given surgical
>> >> >> > procedure.
>> >> >> > This
>> >> >> > is the reason I mentioned if it is possible to bypass the pipeline
>> >> >> > processing in order to render this polydata using pure OpenGL
>> >> >> > commands.
>> >> >> > Thanks again
>> >> >> > Regards
>> >> >> > Fauze
>> >> >> >
>> >> >> >
>> >> >> > On Fri, Jan 22, 2010 at 7:04 PM, David Gobbi
>> >> >> > <david.gobbi at gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi Fauze,
>> >> >> >>
>> >> >> >> Please don't cross-post to the vtk-developers list, since that
>> >> >> >> list
>> >> >> >> is
>> >> >> >> only for developer issues.
>> >> >> >>
>> >> >> >> Mixing polygonal objects with software ray-cast volume rendering
>> >> >> >> is
>> >> >> >> an
>> >> >> >> expensive process, it involves reading a partially rendered scene
>> >> >> >> from
>> >> >> >> the video card back to main memory and re-doing the volume
>> >> >> >> rendering
>> >> >> >> using the information in the depth buffer.  Every time the object
>> >> >> >> moves, the ray-cast has to be redone.
>> >> >> >>
>> >> >> >> If you need fast volume rendering intermixed with polydata, you
>> >> >> >> should
>> >> >> >> use vtkVolumeTextureMapper3D or vtkVolumeTextureMapper2D.  These
>> >> >> >> volume mappers do all of the polydata/volume intermixing right on
>> >> >> >> the
>> >> >> >> graphics cards.
>> >> >> >>
>> >> >> >> What I often do is use a vtkLODProp3D so that I can use the
>> >> >> >> texture
>> >> >> >> volume rendering when I'm dragging things, but have it
>> >> >> >> automatically
>> >> >> >> switch to ray-casting when I stop dragging the mouse.
>> >> >> >>
>> >> >> >>  David
>> >> >> >>
>> >> >> >>
>> >> >> >> On Fri, Jan 22, 2010 at 1:33 PM, Fauze Polpeta
>> >> >> >> <fauze.polpeta at gmail.com>
>> >> >> >> wrote:
>> >> >> >> > Dear VTK Users;
>> >> >> >> > I have worked on a project that requires a Polygonal Object (
>> >> >> >> > or
>> >> >> >> > at
>> >> >> >> > least a
>> >> >> >> > simple Line ) to be moved on the fly on a volume rendered scene
>> >> >> >> > built
>> >> >> >> > on
>> >> >> >> > top
>> >> >> >> > of a vtkVolumeRayCastMapper abstraction.
>> >> >> >> > This goal was successfully reached but we have faced a drastic
>> >> >> >> > performance
>> >> >> >> > degradation when moving the polygonal object into/across the
>> >> >> >> > volume
>> >> >> >> > scene.
>> >> >> >> > We have assumed this is a consequence of the VTK's pipeline
>> >> >> >> >  processing
>> >> >> >> > model. If anyone confirm that, we would like to ask any help in
>> >> >> >> > the
>> >> >> >> > sense of
>> >> >> >> > pointing any strategy for achieving any (minimal) performance
>> >> >> >> > improvement.
>> >> >> >> > Perhaps, getting the OpenGL Context and rendering our polygonal
>> >> >> >> > object
>> >> >> >> > using
>> >> >> >> > OpenGL commands; thus skipping the VTK's pipeline processing.
>> >> >> >> > Is
>> >> >> >> > this
>> >> >> >> > feasible?
>> >> >> >> > Thanks in advance for any help.
>> >> >> >> > Regards,
>> >> >> >> > Fauze
>> >> >> >> > _______________________________________________
>> >> >> >> > 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
>> >> >> >> >
>> >> >> >> > Follow this link to subscribe/unsubscribe:
>> >> >> >> > http://www.vtk.org/mailman/listinfo/vtkusers
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> _______________________________________________
>> >> 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
>> >>
>> >> Follow this link to subscribe/unsubscribe:
>> >> http://www.vtk.org/mailman/listinfo/vtkusers
>> >
>> >
>> >
>> > --
>> > William J. Schroeder, PhD
>> > Kitware, Inc.
>> > 28 Corporate Drive
>> > Clifton Park, NY 12065
>> > will.schroeder at kitware.com
>> > http://www.kitware.com
>> > (518) 881-4902
>> >
>
>