SymbolicObj

[Christopher Olah]

Hey All,

I've been thinking a lot about SymbolicObj2 and SymbolicObj3, the
types for our first representation of objects in ImplicitCAD.

One thing that has occurred to me is that we might merge them together
into one GADT parametrized by a domain, d:

data SymbolicObj :: * -> * where
Union :: [SymbolicObj d] -> SymbolicObj d
Translate :: d -> SymbolicObj d -> SymbolicObj d
Implicit :: (d,d) -> (d -> ℝ) -> SymbolicObj d

And so on. However, this doesn't really allow us to describe matrix
multiplication, extrudes, and slices as we might like. If we switch to
parametrizing over the natural numbers for dimension, and use some
type families, we can accomplish this in a very elegant way:

http://hpaste.org/79473

That said, the types become more complicated. It's a bit of a trade off.

We also want to have a type parameter for material/color. We probably
want it to be an instance of a function to allow us to take weighed
averages between two values -- eg. average (0.2, "red") (0.8, "blue")
-- and in discrete cases just jump. Then we'll produce a
color/material function that describes the color/material at any
point. We can discuss what the exact semantics should be elsewhere.

How we should embed meta data is another question again. Perhaps a
type parameter gives the type of meta data?

Thoughts please!

Chris

[Will Knop]

On Tuesday, December 18, 2012 1:14:40 PM UTC-5, Christopher Olah wrote:

Hey All,

I've been thinking a lot about SymbolicObj2 and SymbolicObj3, the
types for our first representation of objects in ImplicitCAD.

One thing that has occurred to me is that we might merge them together
into one GADT parametrized by a domain, d:

data SymbolicObj :: * -> * where
    Union :: [SymbolicObj d] -> SymbolicObj d
    Translate :: d -> SymbolicObj d -> SymbolicObj d
    Implicit :: (d,d) -> (d -> ℝ) -> SymbolicObj d

And so on. However, this doesn't really allow us to describe matrix
multiplication, extrudes, and slices as we might like. If we switch to
parametrizing over the natural numbers for dimension, and use some
type families, we can accomplish this in a very elegant way:

http://hpaste.org/79473

That said, the types become more complicated. It's a bit of a trade off. 

Nice, I like the generalization! Perhaps also add the following to SymbolicObj below extrude:

Revolve :: SymbolicObj n -> SymbolicObj (Succ n)

I don't see the types getting unnecessarily complicated, though I'm probably missing the big picture. I just see the dimensional attribute of each transform being abstracted. It works, too, since each of those transforms does something useful (and sensible) in any dimension (though I'm not considering hyperspace). Maybe there's a better abstraction, but I can't come up with one right now.

We also want to have a type parameter for material/color. We probably
want it to be an instance of a function to allow us to take weighed
averages between two values -- eg. average (0.2, "red") (0.8, "blue")
-- and in discrete cases just jump. Then we'll produce a
color/material function that describes the color/material at any
point. We can discuss what the exact semantics should be elsewhere.

How we should embed meta data is another question again. Perhaps a
type parameter gives the type of meta data?

I don't think metadata (even color) should be added to the core types. Every application of ImplicitCAD is going to need specialty metadata, and most likely not use other applications' metadata. For instance, even the ubiquitous color attribute goes unused in case of advanced rendering with materials, textures, lighting, etc. And then "material" has entirely different meaning in the context of FEA and other simulations. In other applications an attribute may be dynamically defined. It can really turn into a mess!

Cheers,

Will

[Christopher Olah]

> Nice, I like the generalization! Perhaps also add the following to
> SymbolicObj below extrude:
>
> Revolve :: SymbolicObj n -> SymbolicObj (Succ n)

How is this different from rotate_extrude, if a little bit less general?

> I don't think metadata (even color) should be added to the core types. Every
> application of ImplicitCAD is going to need specialty metadata, and most
> likely not use other applications' metadata. For instance, even the
> ubiquitous color attribute goes unused in case of advanced rendering with
> materials, textures, lighting, etc. And then "material" has entirely
> different meaning in the context of FEA and other simulations. In other
> applications an attribute may be dynamically defined. It can really turn
> into a mess!

It can't stay completely separate, since we need to interweave it into
the object tree. As I see it, there are two ways to do this in a
manner that abstracts the actual meta data. The first one is the
approach I mentioned earlier where we paramaterize against a meta data
type variable. For example:

data SymbolicObj3 meta = ... | Meta meta (SymbolicObj3)

Then SymbolicObj3 () is equivalent to what we presently use.
Alternatively, we could build it to be a data structure that mutually
recurses with another structure that handles the meta data. For
example:

data SymbolicObj3 symbolicObj3Recurse = Union [symbolicObj3Recurse]

And then Fix SymbolicObj3 is equivalent to what we presently use.

This tactic is used in a way I'm very pleased with in
Graphics.Implicit.ExtOpenScad.Definitions for handling the ExtOpenScad
AST meta data. But there I wanted to force attachment of the meta data
to each statement, and here we want to just put it at different
positions... As such, I think the first approach is better for this
use case.

Chris

[cfh...@gmail.com]

Here are some of my thoughts, speaking as an engineer/user rather than a mathematician/coder:

1. I see a use for an object *container* which represents a "part" to me.
2. The part can be transformed as a whole (rigid body and affine transforms are most useful) and all its contained objects are transformed together.
3. The container contains a number of SymbolicObj3's (usually just one of these) and SymbolicObj2's, plus more items.
4. Metadata about the part as a whole is in the container.
5. Metadata about a contained object is embedded in that object.
6. I see great value in supporting SymbolicObj1's (lines) and SymbolicObj0's (points).
7. With the set listed above, I have the basic elements I have in my mental model as an engineer: the body of the object, its symmetry planes, the axes of its features (like bored holes), its surfaces, reference points, materials metadata, and annotations.

As an example, look at the bellcrank arm here: http://stores.homestead.com/Partsdude4x4/catalog/946965.jpg . When I think about this part I am especially interested in the centerlines of the two bored holes, the center point of the pivot ball, and the four planar faces surrounding the two holes; these are the functional elements of the geometry. I want to express these functional elements and their spatial relationships parametrically in extopenscad.

Cheers,
Chuck