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

[Brent Gulanowski]

On Friday, October 18, 2002, at 05:19  PM, Philippe C.D. Robert wrote:

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

Is G3DGeometry a GK base class (yet to be addede), or an RK base class 
for collections of vertices? It seems that geometry (mathematical 
objects in GK) should have predictable behaviour, and then vertex 
collections a different set of behaviour, but then there should be 
vertical correspondence too.

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

A think RK is fine by me, then, but I was hoping to distinguish a 
mathematical description of a cone from a collection of vertices made 
based on the description. So, put the "pure" cone in GK, and the vert 
approximation in the utility kit?
> > 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.

If you have a conic section (say, an ellipse) and a sphere, and a 
bezier, they are all geometries, but one has endpoints, and the other 
two don't. I just thought it would be nice, if GK had all of these in 
it, that they would "know" some things about themselves that outside 
inspection wouldn't reveal. This could certainly be added in the 
application, though, sure.
> > Sub-goals
> > - add further primitive classes to GeometryKit
>
> Or a special utility kit!

Consider me working on this.
> > - 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.

OK, read "G3DShape" for "leaf node" then. I'll trust you're all over 
this issue -- I'm just getting, erm, impatient 8^).
> > - 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...:-)

Consider me working on this, too.
> > 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...:-)

Consider me _researching_ the relevant math and algorithms for this. 
(URLs welcome if you know any.)
> > - 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!)

Yes, absolutely -- I didn't want to presume. Anyway, you don't have 
leaves now. So A is some node with a bunch of children, and you send 
the message [A merge], which returns a new shape. Then you can release 
that entire sub-tree... yeah, that's exactly the kind of cool thing I'm 
looking for. If you don't release the subtree you can cache it for 
later editing, but meanwhile, it should be faster to draw a merged set. 
Maybe need to make explicit "this is a good idea in such a such a 
situation" and a bad idea in others, depending on how it affects 
performance.
> > - 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?

For outdoor type scenes it isn't much use, but indoor worlds might be 
able to use this. You define rooms as inside-out shapes. However if you 
use the Quake approach--pre-processing between modeling and rendering 
(make bsp/VIS/cull)--yeah, it's not very useful then, either. But I 
thought it would be useful if you weren't pre-processing the geometry 
and wanted to manually define the shell between inside and inaccessible 
outside, or the "grey void".  Perhaps its a solution without a problem 
:\.

--
Brent Gulanowski                                address@hidden

Ce n'est pas une signature.     -Magritte