1 / 22

A Tri-layer Framework for Volume Rendering

A Tri-layer Framework for Volume Rendering. Fei Yang. Overview. Reconsidering the coding framework of volume rendering Comply with the nature of volume rendering Meet the requirements of both algorithm research and application assemblage. The Nature of Volume Rendering.

temple
Download Presentation

A Tri-layer Framework for Volume Rendering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Tri-layer Framework for Volume Rendering Fei Yang

  2. Overview • Reconsidering the coding framework of volume rendering • Comply with the nature of volume rendering • Meet the requirements of both algorithm research and application assemblage.

  3. The Nature of Volume Rendering • Sample-level / Ray-level processing Data-level processing: Volume Rendering:

  4. Demand Driven • “Demand Driven Pipeline” used in VTK: • C++ Object-Oriented style • Advantage: Streaming for large data • Problems: • Hard to code • Inconsistent with GPU coding • Inefficient • Alternative: • C style function calls • Static assemblage of components ( compiling level ) • Problem: GUI integration

  5. Research & Application Requirements • Common requirements • Efficiency • Research requirements • Replaceable components • Timing for performance study • CPU/GPU comparison • Application requirements: • High-level interface for common application assemblage: • Interactive Volume Rendering, fixed data, variable view, render to screen, screen resolution • Low-level control for special applications • Time series data • Recording • Fine resolution rendering • Virtual endoscopy

  6. Replaceable components • Data source • Single scalar data • Multi-modal data • Segmented data • Analyzed result • Time series data • Storage: texture/global memory • Interpolation • Nearest Neighbor • Tri-linear • Spline • Ray traversal • Equal distance traversal • 3D-DDA traversal • Composition Styles • Alpha blending • MIP • Isosurface • X-ray • Property Mapping • 1D-TF • 2D-TF

  7. Tri-layer Framework • Module layer • Modules: low-level data structures and basic render-time functions • Frame layer • Assemble the modules statically into frame renderers • Providing low-level control • Scene layer • Providing high-level interfaces, including interaction interfaces.

  8. Tri-layer Framework

  9. Module Layer • Coding Style: C style • Low-level data structures • Basic render-time functions • Defined as static functions in render-time header files • Can be assembled by “include” • Content • Low-level data structures • Volume data • Image plane • Parameters during each processing step • Basic render-time functions • Data fetching • Property mapping • Ray-traversal and composition • Ray generation (start/end points of each ray) and image plane access • …

  10. Module Layer – Coding Style • Basic render-time functions defined as static in header files // SingleScalarVolume.core.h static CoherentVolume *Volume; static int vol_dims[3]; static float vol_spacings[3]; static float vol_size[3]; static inline float GetScalarValue(int x,int y,int z) { x=max(min(x,vol_dims[0]-1),0); y=max(min(y,vol_dims[1]-1),0); z=max(min(z,vol_dims[2]-1),0); return Volume->GetValue(x,y,z); } ……

  11. Module Layer – Coding Style • A “prepare” function in each render-time header for data-transfer before rendering • Optional: A “clear” function in a render-time hearer for data-release after rendering // SingleScalarVolume.core.h …… static bool SingleScalarVolumePrepare(CoherentVolume *volume) { if (!volume) return false; Volume=volume; volume->GetDimensions(vol_dims); volume->GetSpacings(vol_spacings); vol_size[0]=vol_dims[0]*vol_spacings[0]; vol_size[1]=vol_dims[1]*vol_spacings[1]; vol_size[2]=vol_dims[2]*vol_spacings[2]; return true; }

  12. Frame Layer • Data structure assemblage class MIPVR { public: CoherentVolume* m_Volume; MIPRayCasterParam *m_RayCasterParam; VRSceneParam *m_VRSceneParam; VRImage *m_VRImage; void Render (); }; • An assembled structure for each volume renderer • Low-level data structures can be shared between CPU and GPU frame renderers

  13. Frame Layer • Function assemblage: just “Include” and assemble the basic render-time functions #include "SingleScalarVolume.core.h" #include "MIP/MIPRayCaster.core.h" #include "TypicalRayProducer.core.h" void MIPVR::Render () { if (!m_Volume || !m_RayCasterParam || !m_VRSceneParam || !m_VRImage) return; if (!SingleScalarVolumePrepare(m_Volume)) return; if (!MIPRayCasterPrepare(m_RayCasterParam)) return; GenerateImage(m_VRImage,m_VRSceneParam); // Entrance in "TypicalRayProducer.core.h" }

  14. A Typical Calling-chain • MIP Volume Rendering

  15. Different Combinations

  16. Scene Layer • A standard object-oriented hierarchy • Abstract scene class: • Define a series of interfaces for event handling • Can be integrated in various GUI contexts • 3D scene class: • Implement event handling interfaces for basic 3D manipulation • Leave the “render” interface for sub-classes • Concrete scene classes: • Implement the “render” interface • Call one of the frame renderers to render each frame

  17. Meeting the Requirements • Common requirements • Efficiency: static function calls, establish at combining time, no pointers, can be inline. • Research requirements • Replaceable components: • replaceable components provided at module layer • Timing for performance study • Use the scene layer interface to time each frame • CPU/GPU comparison • One-one corresponding components of CPU and GPU can be built • Some low-level data-structures are shared

  18. Meeting the Requirements • Application requirements: • High-level interface for common application assemblage: Use the scene layer interface • Low-level control for special applications • Time series data: use the frame layer interface or replace the data fetching module • Recording: access the image plane • Fine resolution rendering: use the frame layer / module layer interfaces • Virtual endoscopy: modify the even handling in the scene layer

  19. Implementation and Availability • As a part of MITK • A synthetic medical imaging toolkit • Libraries available at www.mitk.net • Implemented mainly in • mitkVisualization2 • mitkCUDAVolumeRendering • VolTK • Open-source project at www.fei-yang.org

  20. Different Project Arrangements • VolTK: • MITK:

  21. The Philosophy • What is Object-Oriented-Programming • Binding data-structures with corresponding algorithms • Procedures as objects • Storing the parameters • Shared data-objects needs special treatment • A procedure related to multiple objects • Use procedure programming – more suited, easy to understand.

  22. Thanks

More Related