1 / 30

PMR: Point to Mesh Rendering, A Feature-Based Approach

PMR: Point to Mesh Rendering, A Feature-Based Approach. Tamal K. Dey and James Hudson {tamaldey,jhudson}@cis.ohio-state.edu http://www.cis.ohio-state.edu/~tamaldey October 30, 2002 Department of Computer and Information Science The Ohio State University. Overview. Introduction

morley
Download Presentation

PMR: Point to Mesh Rendering, A Feature-Based Approach

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. PMR: Point to Mesh Rendering, A Feature-Based Approach Tamal K. Dey and James Hudson {tamaldey,jhudson}@cis.ohio-state.edu http://www.cis.ohio-state.edu/~tamaldey October 30, 2002 Department of Computer and Information Science The Ohio State University

  2. Overview • Introduction • Algorithm: Two Stages • Preprocessing • Viewing • Results • Conclusion

  3. Hierarchy Construction • Points and triangles displayed • Feature-dependent, not screen-space • Advantageous for large, flat areas • Goals: • Quality at all viewing distances • Adaptive display • Adjustable speed vs. quality setting • No input mesh needed

  4. Motivation • Triangles good for quality; points for speed • Difference is subtle when far away Point-based splatting PMR Zoom in on the nose...

  5. Splatting vs. PMR PMR Point Splatting When zoomed-in, differences are more noticeable, especially at upper left edge of nose.

  6. Our Approach • Utilizes hierarchy • Contains Points and Triangles • Hierarchy: scale independent • Depends on model's features • No surface mesh required • More flexibility • Simpler data structure

  7. Preprocessing • Decimate input where "redundant" points exist • Use features to determine this • Threshold guides levels of hierarchy • No new points added; only removal t = 0.2 t = 0.3 t = 0.4

  8. Feature Detection • We use Voronoi diagram to detect features • Can be costly: time + memory • Solution: Use octree decomposition of space • Maximum of 12000 points per node useful

  9. Feature Detection • Dense point set: long, skinny Voronoi cells • Capture this via height and radius values • Pole vector = estimated normal (AB98) • Height estimates distance to medial axis • Radius estimates distance between neighbors

  10. Feature Detection • Decimation is based on ratio • Remove all points with ratio <  (threshold) • Point with small ratio must have close neighbors • Repeat for several values of  to give hierarchy • We use values from =0.1 to =1.0 • Each leaf node N is processed individually radius height

  11. Point Hierarchy • The final point hierarchy contains progressively fewer points t = 0.2 t = 0.3 t = 0.4

  12. Triangle Hierarchy • For point p: We define umbrella of p • Umbrella = set of triangles incident on p and are dual to Voronoi edges intersecting tangent polygon

  13. Triangle Hierarchy • Result: progressively sparser triangle sets t = 0.2 t = 0.3 t = 0.4

  14. Disk File • For each leaf, store to disk: • Points, estimated normals, hierarchy levels • Umbrella triangles per vertex • Umbrella radii per vertex • Average umbrella radius for all points • Map file to memory when viewing

  15. Viewing • Must determine pixel size • Done once per leaf node only • Closest corner point = the one to use • Project two world space points to screen • Gives ratio of world space to screen space • Conservative estimate

  16. Choice of Hierarchy • Choice of hierarchy level made once per leaf • Metric: Use average umbrella size • Try to match umbrella size to pixel size • If too dense: more points to process • If too sparse: detail lost • User can trade speed for quality via scale factor Too dense Just right Too sparse

  17. Pixel vs. Umbrella • For each point: choose: Pixel vs. Umbrella • Compare umbrella radius to (pixel size)  (scale factor) • scale factor allows trade-off of quality vs. speed • Choose umbrella only if size too big; else choose pixel • Conservative estimation performed Can draw as pixel Must draw as triangles

  18. Scale Factor • Scale factor allows modification of calculation • If scale factor larger, calculations treat pixels as larger • Selects sparser hierarchy level • Can modify scale factor to selectively slow transition between levels, especially at high levels of decimation

  19. Scale Factor Transition • Need to slow transition between sparser levels • Differences invisible when far away t=0.1 t=0.3 t=0.8 t=1.0

  20. Results • System used: • Pentium 4, 1.7 Ghz, 2 GB RAM • Matrox Millenium G450 graphics card • Software-only OpenGL rendering

  21. Results • We varied  from 0.1 to 1.0, steps of 0.1 • If  is large (1.0), features are lost • Varying the scale factor • If pixel size is 2 world space units, begin altering • Reduce factor linearly until pixel is 4 world space units • If pixel is 4 or more units: factor is equal to 1 • Net effect: as decimation becomes sparser, slow the transition between levels.

  22. Results Varying distances; Blue=triangles, Red=points 0.11 FPS, 4.5M tris, 0 points (Full detail) 0.65 FPS, 650K tris, 377K points (PMR) 0.77 FPS, 670K tris,48K points (PMR) 1.65 FPS, 215K tris, 204K points (PMR)

  23. Results Sparse level Dense level

  24. Results • Comparison of full-detail (t=0) vs PMR Full detail, 0.54 FPS PMR, 3.85 FPS

  25. Results • Comparison of full-detail vs PMR Full detail, 0.25 FPS PMR, 0.71 FPS

  26. Results • Comparison of full-detail vs PMR Full detail, 0.11 FPS PMR, 0.61 FPS

  27. Results Sparse level Dense level Factor=1 0.16 FPS Factor=3 0.74 FPS Factor=5 0.96 FPS

  28. Results Vertices Full PMR Object Dragon Happy Blade DavidHead StMatthew 437645 542557 882954 2000646 3382855 0.54 0.43 0.25 0.11 0.072 3.85 3.44 0.71 0.78 0.67 Frames per second. Full denotes the full (t=0) mesh; PMR denotes the adaptive hierarchy scheme with a factor of 5.

  29. Vertices Time Size (MB) Object Dragon Happy Blade DavidHead StMatthew 437645 542557 882954 2000646 3382855 03:53 04:36 09:02 06:36 26:38 97 150 238 512 479 Preprocessing Times Note: Times are in Hours:Minutes.

  30. Conclusions • A hybrid rendering scheme • Points and triangles employed • User-adjustable error tolerance • No input surface required • Future work • Applications to volume rendering

More Related