Shape Dividing Algorithm: Converting 2D Polyloops into Separate Shapes and 3D Rendering - , Study Guides, Projects, Research of Computer Graphics

Download Shape Dividing Algorithm: Converting 2D Polyloops into Separate Shapes and 3D Rendering - and more Study Guides, Projects, Research Computer Graphics in PDF only on Docsity! 3D Sketching Trim and Bulge Dean Lewis Chris Morgan CS6491 Abstract This work studies the implementation of a free-form drawing program. It solves the problem of taking 2D polyloop(s), dividing them into shapes, and rendering them in 3D. The user draws any arbitrary curve, or set of curves, using the mouse or other input device. The program takes this curve, interprets it, and produces a clean, smooth version. If the user is happy with this, the program then calculates the inflation using the Bulge algorithm[2] and produces a water-tight triangulated hull. This hull can then be exported to MeshViewer[1], which includes a set of more advanced tools. In this way, the user can create a nice 3D model with just a minute’s work. Introduction The goal of this project was to design a simple tool for quickly generating 3D sketches. The user is provided a blank canvas in which they may draw any arbitrary shape using their mouse or other pointing device. When this sketch is complete, the program processes the polyloop to identify individual polygons and remove sketch artifacts such as fish tales. If the user is satisfied with the refined shapes, the program then inflates them into 3D models, which may be viewed internally or exported to a more full-featured viewer. Program Architecture Hierarchy: The topmost file is Project2b.pde to which all other files link. This file contains the required setup() and draw() functions, as well as program-wide objects such as display options and the “clear” and “quit” buttons. Within this file are the four key interactive functions: draw(), mouseClicked(), keyPressed(), and printHelpText(). Each of these functions contains program-wide code. It also contains calls to each program phase (discussed next). By organizing Project2b.pde in this manner, we can easily segment the code into logical partitions while still enabling simply coexistence of the components (true interactivity would require far more work than is possible in the allotted time). Program Phases: There are two phases in part A of this project. First is the hand drawing phase, wherein the user draws a rough sketch of the figure they want. Second is the polyloop phase, wherein the program interprets the figure to produce a clean, smooth version of the original sketch. Part B introduces a third phase, which allows for the production of a bulge and mesh. Handdraw: The hand drawing phase provides a simple interface to the user for producing the figure they want. The user simply clicks to where they want to place points in the figure. Alternatively, the user can click and drag to draw a string of points. A “New Curve” button is provided which allows a new shape to be drawn within the figure, disconnected from the original shape. When the user has completed the sketch, they can simply click “Interpret” to switch to the polyloop phase and produce the final result. Polyloops: In this phase, the program examines the figure the user has drawn and begins to subdivide it into individual polyloops. This process is described in detail later in this report. After the polyloops are identified, a process of six refinements, one resampling, and one more refinement is performed to clean up the curves. The steps in this process were chosen empirically to produce the best curves a large percentage of the time. Refinement is an implementation of Jarek’s Compromise (J4). This was chosen because it maintains the area of the original figure well, which seemed to be appropriate for this cartooning application. The resampling algorithm is of our own design without the help of prior work. We calculate the length of the loop, divide it into some number of equal length segments, and then place a new vertex at the end of each segment. This seemed to be reasonable implementation that would not require an excessive coding time. It does not handle cases with long edges and sharp corners very well. That is why refinements are performed first. After this process concludes, polyloops with area less than 1% of the largest area are removed, deleting fish tails and other such artifacts of the drawing process. With these polyloops gone, a clean and smooth figure is produced that is ready for Part B. Bulge and Mesh: In the final phase, the polyloops produced in the previous phase are inflated to form 3D hulls. Details are explained later in the report. This inflation process produces a set of quadrilaterals representing the inflation in one direction, positive z. These quadrilaterals are each split into two triangles to form a triangle mesh. Next, the mesh is mirrored in negative z, and the two meshes are connected along their borders to form a complete, closed hull. Finally, the hull is recolored for easy viewing. It may also be exported to MeshViewer[1], a more advanced 3D viewing program. After a number of other optimizations are preformed (described below), each shape is assigned unique points in memory corresponding to the values of existing points. This is so different shapes do not reference the same point object, which can cause problems with refinement. More Complicated Examples: One might anticipate some problems with the above approach. For example, one may wonder how this process deals with the examples shown below. The following captions illustrate a variety of potential problems that seem to be exceptions to the above algorithm, and the means taken to address them. Example 1: This example shows a string of polygons formed from a single polyloop that have at maximum two intersections, each with a different polygon. The successful shape division is shown on the right. However, according to the method mentioned above, such a decomposition should be impossible, as one may never circumnavigate one of the four polygons in the middle by jumping from intersection to intersection. Consider the green polygon. According to the method above, it should be two polygons, one consisting of roughly the top half of the hexagon, and the other the bottom. However, this is avoided by, after the steps above, combining into one shape two shapes that have endpoints at equal or close to equal vertices (ordering of endpoints is irrelevant). Indeed, without this feature, it may resemble the example below (which was generated with some code commented out). Example 2: Two items need to be addressed in this example. First, what happens to the “shapes” formed by the two consecutive intersection points. Say one is traversing the line from 1 to 2. Once one hits the first intersection point (with line 3-4), one will complete the shape that includes point 1 (in this case the red triangle) and start a new shape. However, one will immediately hit another intersection point (with line 0-4), and form a new shape with only two points. This shouldn’t really be considered a shape at all because it’s a 1D object. It may not be the ideal counterexample for this star, as theoretically this shape could merge with the yellow triangle, but if it couldn’t merge, then we are stuck with a superfluous one-dimensional shape. One might visualize an example of this case by seeing the next example’s captions, and pretending one of the almost 1-dimensional shapes therein is a 2-point shape. This is alleviated by not adding shapes that have less than three points to the ShapeList, as they are not three-dimensional. 2-point shapes are maintained temporarily to see if they join with any other shapes, but are subsequently deleted. 1-point shapes are excluded at the beginning. They are generated near the end of the shape traversal (the last intersection theoretically has its own shape). The second item concerns the middle pentagon that is not registered as a shape. While in this example the damage is mitigated because it is a “hole” between the star’s points, this failure is probably the greatest fault in the algorithm. If a shape has more than two intersections as vertices, it will not be generated. This, however, can be justified by the fact that if one wants such a shape, one can still draw it normally without > 2 intersections. Although one may lose some surrounding context, if one has 3+- intersection shapes that need to be trimmed down and refined, more care may need to be exercised. Example 3: Incorrect: Correct: Since shapes with 3 intersections are not counted, what then is done with them? As you can see from the incorrect example above, they do generate shapes of their own that do not correspond with any shape and need management. What this algorithm does is to remove shapes that, after the 2-intersection endpoint merging process has been completed, still have 2-intersections as their endpoints (many merged shapes should no longer do so). This removes the three superfluous shapes shown above. One bug of note was fixed from the last release that wasn’t mentioned in the last report. After combining shapes, if any shapes are left over with two intersections, they are deleted. There were a few exceptions mentioned last time, but these were found to cause invalid shapes not corresponding with any shape boundaries, among other errors. Another item to consider is the accuracy of the intersection function. If a predefined vertex is close to an intersection, then one needs to make sure that it doesn’t, through this closeness, generate two intersections when only one should be calculated (meaning it’s within the margin of error). Thus, for a point p, the lines from p-1 to p and p to p+1 might result in intersections with the line from point q to point q+1, when only one of those lines should give an intersection. This introduces a number of problems, as one might see from the ArrayLists below. Correct: p, @, p+1, …, q, @, q+1, … Incorrect, but what occurs: p-1, @1, p, @2, p+1, …, q, @1, @2, q+1, … Two problems result from this. The most minor is that an unnecessary shape is generated [@1, p, @2] when one shouldn’t be. However, the intersection points would be so close to p anyway that this shouldn’t impact the display heavily except for showing a miniscule tiny shape. It also shifts a vertex for the shape beginning with p, p+1, … over slightly. The current solution is to only add shapes with a total perimeter > 5, which should delete many such microscopic anomalies (this may cause problems if one really wishes to draw or does draw such a microscopic shape, which is not recommended). The low shape area removal process may also address this for any shapes with a greater perimeter. A far more serious problem is that polygons may be deleted that shouldn’t be. Say p and p+1 are part of opposite shapes with identical endpoints that eventually merge into one shape because they have identical endpoints. In the incorrect sequence, the shapes will never merge because @1 and @2 are not the same intersection, meaning they no longer have identical endpoints. This problem is resolved by redefining the meaning of equal points. Points are equal if the distance between their x values is < 1 and the distance between their y values is < 1. This theoretically allows @1 and @2 to be considered equal, and thus allows the merging to take place. Multiple Polyloops: Multiple polyloops can be created by pressing the “New Curve” button anytime while drawing the polyloops with the mouse. The “New Curve” button inserts a “breakpoint” in the master list of points, which is simply a dummy value signaling that a new polyloop has been created. This breakpoint should be ignored when calculating intersections, and serves as a divider between polyloops when subdividing them. All shapes are sorted by area, so that the largest area shapes are on the bottom. To remove any hole shapes, press the ‘o’ key in polyloop mode after subdividing into shapes. This will remove any shapes that are completely enclosed by another shape. Note that it will theoretically not remove a shape if it intersects with the enclosing shape, although automatic refinement may render this point moot (there may be some margin of error if it does not). The algorithm knows which ones to remove by checking to see whether each point of a shape is inside every point of another shape. If inside an odd number of shapes, the figure is removed. Note, however, that removing the holes currently just changes the shape into a gray figure. At present, the enclosing shape is not “aware” that a hole has been created, and the results are just visible on the screen. An Unfortunately, deleting vertices at height less than one does cause the positive- and negative-z meshes to have some very jagged edges. Once the edges are stitched into a complete hull, the shape needs to be smoothed to eliminate this jaggedness. This smoothing is left to MeshViewer[1] because reproducing this function in this project would have been an unnecessary expenditure of resources. Prior Art There are several cases of prior work. First is Bulge[2]. This work allows for the drawing of a curve and the production of the height field. However, it stops there and does not actually produce a usable mesh from this field. Teddy[3] takes a very different approach to generating 3D inflations. First, they do not handle the case where the original drawing has any self-intersections. The freeform drawing must be an open loop which they close prior to inflation. Next, the skeleton of the drawing is identified with a DeLaunay trianglulation. This skeleton is cleaned up using a pruning technique. This cleaning does not produce a proper triangulation, so the 2D shape is re-triangulated, connecting all polyloop vertices to the skeleton vertices. The skeleton is then raised proportional to it’s distance from the polyoop, and half-circles are formed from each skeleton vertex, polyloop vertex, and the negative of the skeleton vertex. Finally, these half circles are sewn together in a complete 3D triangulation. The focus of this work was on producing a very clean final hull, while our work focused more on allowing the user free-reign in the initial drawing. SmoothTeddy[4,5] is an extension to Teddy which enhances the tools available for editing the 3D model. The underlying inflation techniques have not changed from the original implementation already described. However, one clever programming idea employed in SmoothTeddy is maintaining multiple versions of the same data (skeleton mesh, skin mesh, and visible mesh) to satisfy various processing requirements. This is similar to the triangle and corner tables employed in this work, each of which serve the same general purpose but in differently-optimized ways. Tai et. al.[6] take a similar approach to Teddy, focusing on the final hull and accepting only simple, open freeform sketches as input. Conclusion This program renders user generated 2D polyloops into separate 2D shapes, and also renders these shapes into 3D. It finds intersections and traverses the polyloops to create initial shapes, and merges them into larger shapes or deletes them if necessary. It uses a ball transformation method to calculate the height of the new 3D bulge from the shapes, and creates a triangular mesh using these heights. Overall, this program empowers the user to do many things with simple 2D drawings, and uses them to build more complex figures. References [1] Jarek Rossignac. “Mesh Viewer”. http://www.gvu.gatech.edu/%7Ejarek/demos/view/. Accessed Oct 18, 2007. [2] Jarek Rossignac. “Bulge”. http://www.gvu.gatech.edu/%7Ejarek/demos/bulge/. Accessed Oct 18, 2007. [3] Takeo Igarashi, Satoshi Matsuoka, and Hidehiko Tanaka. “Teddy: A Sketching Interface for 3D Freeform Design.” In SIGGRAPH, 1999. [4] Takeo Igarashi and John F. Hughes. “Smooth Meshes for Sketch-based Freeform Modeling.” In I3DG, 2003. [5] Takeo Igarashi and Dennis Cosgrove. “Adaptive Unwrapping for Interactive Texture Painting.” In I3DG, 2001. [6] Chiew-Lan Tai, Hongxin Zhang, and Jacky Chun-Kin Fong. “Prototype Modeling from Sketched Silhouettes Based on Convolution Surfaces.” In Computer Graphics Forum, volume 23, issue 1, pp. 71-83. 2004.