petereichinger / modelthulhu

Automatically exported from code.google.com/p/modelthulhu
0 stars 0 forks source link

Code Redundancy #2

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
There's a bunch of redundant code. The code for converting to instances of 
the BasicModelData class is a particularly bad case.

There's also the beginnings of a partial rewrite of a large portion of it 
(just about all of the files with names starting with "CSG" (but not 
CSG.cs)), but that's incomplete.

Original issue reported on code.google.com by andrew.lubitz@gmail.com on 24 May 2010 at 10:24

GoogleCodeExporter commented 8 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

GoogleCodeExporter commented 8 years ago
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