All: Thank you for your responses on this thread. I just started re-teaching a Modeling & Simulation
class using Max/Msp, and am now delving back into this subject. I have some questions related to a patch
which I am including at the end. If you have a moment, launch this patch to see something that looks a bit
like Saturn as approximated by a sphere and surrounding torus. The group of these 2 objects can be manipulated
in jit.window.
(1) This may seem minor, but is a source of frustration: when I edit an object to add or change an attribute (consider
the [jit.gl.gridshape] and [jit.gl.mesh] objects, Max automatically ignores my extents of the rectangle and creates one
(very long and hard to edit) text line in the object. I have to manually drag the right-side of the box after each edit. I
wish Max would leave the object box 4 corner points alone while I am editing, and after I have edited. Is there a
setting for this? The issue is problematic for jit objects where many attributes are set. I could not see anything obvious
in Preferences.
(2) I looked on the web for a detailed description of (a) the format of the matrix that comes out of [jit.gl.gridshape] and
that goes in (and out of) [jit.gl.mesh]. Is there a written example with snapshots of what the matrices look like? I understand
in theory that one must capture two lists (the node/vector list of points and the face list that defines polygons), but what
exactly do these lists look like? This should ideally be written in the reference manual.
(3) @Andrew: I like [jit.gen] also but until I know what the matrices look like coming in and out of [jit] objects, it is hard to
write. Also, it would appear that to create a data-flow geometry graph, one would need to create nodes such as [translate],
[rotate], [scale], [group], etc with [group] being a joint of incoming matrices/meshes. Do you know if anyone has written
these meta-objects? For instance, a [rotate] would take a mesh, apply a rotation to each point, and then output the new
matrix. Right now, transformations are handled as attribute values to [jit.*] which is quite convenient except when one
wants to demonstrate transformation as a chained, data flow process.