Open GoogleCodeExporter opened 9 years ago
The plan for that (incomplete) rewrite was to keep non-triangle polygons,
rather than
feeding the triangulated output back into the CSG function as input.
The reasoning was this: the triangulated output has a lot of meaningless edges
which
create additional meaningless edges and require additional intersection checks
in
subsequent CSG operations.
How it would have worked:
0 (Preconditions). Input polygons are cut from some original input triangle.
Vertex
info for every vertex of the polygon can be linearly interpolated based on the
vertex
position. The vertex positions themselves may even be specified as linear
interpolations of the original triangle's vertices. References to user-side
vertex
info (integer indices or somesuch) are stored for each of the three verts of
the
original triangle.
1. Find polygon/polygon intersections (edge cuts)
2. Cut polygons which have intersections
3. Divide model into contiguous regions (cut edges form the boundaries between
regions)
4. Eliminate/flip regions of each mesh based on which side of the other mesh
they're
on
5. The remaining polygons may be used as the input for subsequent CSG operations
6. When a series of CSG operations is completed and a triangulated mesh is
required,
interpolate the vertex info referenced by the polygons' vertices to get the
vertex
info for the created vertices. Alternatively, it could be set up so that this
data
can be cached user-side, with some sort of conditional calculation (only
generating
new vertex info (uv coords, per-vertex normals, etc.) when a new vertex is
created).
Original comment by andrew.lubitz@gmail.com
on 24 May 2010 at 10:40
This is actually fairly similar to what's going on now, except that after the
triangulation is done, the output of that is what's being fed back into the CSG
function in subsequent operations.
Original comment by andrew.lubitz@gmail.com
on 29 May 2010 at 8:21
Original issue reported on code.google.com by
andrew.lubitz@gmail.com
on 24 May 2010 at 10:24