Difference between revisions of "GeometryProcessing/Spring2009/Schedule/Surface Generation Extraction1"

From VistrailsWiki
Jump to navigation Jump to search
(New page: *John Meier I liked the structure of Tuesday's lecture: 1) the build-up to the topic of marching cubes from marching tets, and 2) examination of the aspects of marching cubes that have bee...)
 
Line 1: Line 1:
*John Meier
*John Meier
I liked the structure of Tuesday's lecture: 1) the build-up to the topic of marching cubes from marching tets, and 2) examination of the aspects of marching cubes that have been "solved", like how to prevent ambiguous surface extraction by automatically generating the intersection lookup table, and optimizing runtime with structures likes octrees or span spaces. The biggest mental hurdle for me among the lecture topics was the reason for building an octree of an implicit surface from the bottom up as a preprocessing step, which Carlos cleared up well (once the structure is built, it can be queried for any constant). The analogy to sorting an array before searching for elements was intuitive and appreciated. I have a remaining question due to my lack of experience: What steps would take place when using marching cubes to extract a surface from an implicit representation? (i.e., when would the ability to quickly query an octree for multiple values be useful?).
I liked the structure of Tuesday's lecture: 1) the build-up to the topic of marching cubes from marching tets, and 2) examination of the aspects of marching cubes that have been "solved", like how to prevent ambiguous surface extraction by automatically generating the intersection lookup table, and optimizing runtime with structures likes octrees or span spaces. The biggest mental hurdle for me among the lecture topics was the reason for building an octree of an implicit surface from the bottom up as a preprocessing step, which Carlos cleared up well (once the structure is built, it can be queried for any constant). The analogy to sorting an array before searching for elements was intuitive and appreciated.  
 
 
=== Questions ===
 
What steps would take place when using Marching Cubes to extract a surface from an implicit representation?
 
(I'm not sure I understood the question, so feel free to tell me I didn't get it) If you already have a volumetric dataset stored as a 3D set of voxels in space, then you can just run Marching Cubes directly on that representation, one voxel being one cube. If what you have is an evaluation formula for each point in space, then you can first evaluate the function in a fixed volumetric grid, giving you the voxels and then running Marching Cubes.

Revision as of 20:16, 21 January 2009

  • John Meier

I liked the structure of Tuesday's lecture: 1) the build-up to the topic of marching cubes from marching tets, and 2) examination of the aspects of marching cubes that have been "solved", like how to prevent ambiguous surface extraction by automatically generating the intersection lookup table, and optimizing runtime with structures likes octrees or span spaces. The biggest mental hurdle for me among the lecture topics was the reason for building an octree of an implicit surface from the bottom up as a preprocessing step, which Carlos cleared up well (once the structure is built, it can be queried for any constant). The analogy to sorting an array before searching for elements was intuitive and appreciated.


Questions

What steps would take place when using Marching Cubes to extract a surface from an implicit representation?

(I'm not sure I understood the question, so feel free to tell me I didn't get it) If you already have a volumetric dataset stored as a 3D set of voxels in space, then you can just run Marching Cubes directly on that representation, one voxel being one cube. If what you have is an evaluation formula for each point in space, then you can first evaluate the function in a fixed volumetric grid, giving you the voxels and then running Marching Cubes.