[Gnu3dkit-dev] Proposed Goal: Procedural Generation of 3D objects

[Brent Gulanowski]

[[I've CC:ed you both on this since the mail sysem seems to be 
non-functional.]]

Discussion and Strategy

Consider this a long-term goal, perhaps, but I think it would make 
3DKit incredibly more useful out of the box for creative applications. 
I'm not really sure how anyone else feels about the creative side of 
it. It's one thing for 3DKit to display data, but another thing to use 
it in applications meant to produce data.

One possibility is to add more geometric objects to GK and to provide 
G3D<Primitive>Additions for <Primitive> = Sphere, Line, Box, Bezier, 
Vector2*, and Vector3*. We could also extend the set of Primitives with 
Polygon, Ellipsoid, Cone, ConicSection, and BezierSurface.

The G3D<Primitive>Additions is a Category on each Primitive provided in 
RK. This would add a method or methods to generate vertices, edges and 
(if applicable) triangles -- ideally they would produce an object which 
was suitable as a leaf node -- ie, which could render itself 
appropriately. Thus we would provide a conceptual relationship between 
geometric descriptions and rendered primitives, but they would not be 
mixed up in the same class. Ideally the object-vending method would 
enable us to select a level of detail.

In this way, geometric primitives become similar to the interface to a 
class cluster.

Perhaps none of this functionality needs to be added to G3D proper; it 
can be done independently. But it would be good to keep it in mind. Oh, 
except it would be nice if primitives were a bit smarter, and knew 
things about themselves (especially two things I mention as sub-goals: 
knowing if they are 3d or not, and, knowing if they define a fully 
enclosed 2d area or 3d volume).

Sub-goals
- add further primitive classes to GeometryKit
- stabilize the class designs for leaf nodes
- create a G3DPrimitive shared super-class (or category) in GK
- enable easy identification of primitives with co-planar points
- enable easy identification of primitives providing a closed surface
- create G3D<primitive>Additions category for each <primitive> in GK

also (more far-out, perhaps part of a G3DKit Extension pack or G3D 
Utilility Toolkit ;-) ):
- a new Extrusion class which, given two paths and a detail setting, 
can produce a mesh which is an extrusion of first (surface) path along 
the second (extrusion) path. Given a parabola or hyperbola for the 
surface path would mean having to set some kind of maximum size and 
closing it by joining the endpoints. This is a great way to generate 
tori. The class would have to know how to close the surface given a 
closed extrusion path.
- methods (probably in a new aggregate class, maybe a PrimitiveGroup 
class) to enable boolean operations with geometric primitives: 
unionWith:, intersectionWith:, exclusionWith: (aka: 
booleanExclusiveOrWith: ), and subtract:.
- a method on leaf nodes (meshes) to join or merge a second leaf node. 
This wouldn't have to be complex as a boolean operation. It could have 
a yesno flag for whether to cull triangles from the added node if they 
are inside the volume of the initial mesh. It could be up to the 
implementation how carefully the culling was done, if it was done at 
all. Options (from easiest to hardest): cull nothing; cull added 
triangles enclosed in bounding box of starting mesh; cull only within 
closed mesh volume(s); cull only full triangles; cull and clip 
triangles partially contained in any closed mesh volume(s).
- a method on leaf nodes which reverses the front and back faces. 
Simplest approach is to switch OpenGL vertex ordering from CW to CCW, 
but state changes are expensive in other ways. For an indexed array of 
verts, indexes are changed. For a non-indexed array, have to swap 
values for two triangle vertices in every triangle.

--
Brent Gulanowski                                address@hidden

http://inkubator.idevgames.com/
Working together to make great software.