Posted: Sat Jul 12, 2008 1:45 pm
Kattle you are right about tris not have to be connected, so that won't be a problem.
The current zge-implementation is not so bad I think, but it does a number of things differently than the one you've found:
1. caching of return values of the implicit function, this is important because it can be a very costly function when you have several nested combines with zexpressions and blendning.
2. caching of vertices to avoid generating redundant geometry
3. it only computes the cubes of the area around the found surface instead of computing the whole rectangular area (which saves massively on computations and reduce the need for the user to manually bound the area)
4. it decompose every cube into tetrahedron before computing vertices, this avoids the large look-up table (and supposedly also improves polygonization quality).
These are the reasons there are quite a lot of code in there but I don't think they are unnecessary steps, instead they provide good runtime speed and less geometry
Nr 3 is also why only one surface is computed, but unless I'm mistaken I think that the algorithm can be changed so that this behavior can be controlled with a property. Switch between the current automatic single surface behavior, or a new "computeWholeArea" behavior where the user also needs to set bounds of the area to avoid cpu-overload.
The current zge-implementation is not so bad I think, but it does a number of things differently than the one you've found:
1. caching of return values of the implicit function, this is important because it can be a very costly function when you have several nested combines with zexpressions and blendning.
2. caching of vertices to avoid generating redundant geometry
3. it only computes the cubes of the area around the found surface instead of computing the whole rectangular area (which saves massively on computations and reduce the need for the user to manually bound the area)
4. it decompose every cube into tetrahedron before computing vertices, this avoids the large look-up table (and supposedly also improves polygonization quality).
These are the reasons there are quite a lot of code in there but I don't think they are unnecessary steps, instead they provide good runtime speed and less geometry
Nr 3 is also why only one surface is computed, but unless I'm mistaken I think that the algorithm can be changed so that this behavior can be controlled with a property. Switch between the current automatic single surface behavior, or a new "computeWholeArea" behavior where the user also needs to set bounds of the area to avoid cpu-overload.