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