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

[Philippe C . D . Robert]

Hi,

On Friday, October 18, 2002, at 05:42  Uhr, Brent Gulanowski wrote:
> [[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.

I agree.

> 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.

More primitives are on the list, indeed! The idea is that the design 
should facilitate adding such classes w/o much effort by subclassing 
the G3DGeometry base class, which in turn is used by shapes to manage 
geometric data.

> 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.

Well, primitives such as spheres, cones etc. should IMHO be part of a 
utility kit... I'd like to have the core RK layer as thin but powerful 
as possible. It should not provide everything but let others implement 
everything on top of it!

> 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).

Well, I guess this depends on what level you are, the geometry (GK), 
visualisation (RK) or custom logic.

> Sub-goals
> - add further primitive classes to GeometryKit

Or a special utility kit!

> - stabilize the class designs for leaf nodes

I removed the G3DLeaf node because actually we do not need it ...:-) No 
there are group nodes, lights and shapes which are all subclasses of 
G3DNode.

> - 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

Volunteers are welcome...:-)

> 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:.

Again, volunteers are welcome...:-)

> - 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).

Why not use the group node for this? Esp. since you can transform 
geometry in an upper branch, so how would a mesh know about such 
information ... (think of geometry sharing!)

> - 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.

Why would you want this? Do you have a real world scenario in mind?

-Phil
--
Philippe C.D. Robert
http://www.nice.ch/~phip