Matrix representation of graph node position?

Design API
#1

Gents,

Having now spent a fair bit of time with Famous vs rolling my own 3d, I’m finding Famous a bit slow to dev with and I think the source of the problem is the coordinate system.

Q) Are you considering representing the position of a node using a similar system as famous (position/rotation/scale/etc), or have you considered representing it as a 4x4 transformation matrix instead?

While the famous way of doing things is “easier” for the untrained, Matrices are how one is taught these things in school and is how the various literature and text books present the concept of scene graph.

The reason I raise it is because of the following:

  • I have found the Famous coordinate system is a constant source of frustration when one is comfortable using matrices. Specifically, the Famous coordinate system actually slows down development and makes code more brittle. This is because

  • there is an implicit order in which the various transformations have been composed that sometimes isn’t appropriate to the task at hand (for example, I may want to rotate then scale; other times I may want to scale then rotate)

  • there are implicit transformations being applied to nodes when one doesn’t expect it (For example, sometimes I want to translate-scale-detranslate-rotate-translate-scale a node, that is impossibly difficult in famous because of the implicit origin/align/etc side effects that come with its graph), and

  • there exists useful transformations that are impossible with the Famous coordinate system (skew is the simplest example).

  • I think you will find it will make the internal API alot simpler. Having spent a bit of time in the Famous internals, some of the least pleasant code within Famous has a lot to do with wrangling the Famous coordinate system.

There is a certain elegance and simplicity with matrix representation of transforms that has been lost with the Famous API and I think its worth reconsidering.

To make this more concrete, what would be convenient is a Node#setMatrix() / Node#getMatrix()

You could still implement that simpler interface for the less lin-alg inclined, but it would be most useful to be able to work with matrixens if one so desires. It is easy to implement get position/scale and for the sake of simplicity, if one has done a setMatrix() then it would be reasonable for the node to throw an exception if one then does something like a getRotation().

Just a thought. Possibly a good one.

ap.

Default values for origin, align, and moutPoint
#2

Famous uses 4x4 matrices.

It wasn’t documented well: First, set this to true. Then, use Node.addComponent to add a Transform (they call it “transform”, not “matrix”). Then, you can simply provide a Float32Array to the transform.local property to set the “matrix” values.

To help you calculate the values to apply to transform.local (i.e. matrix.local), I’d recommend you use my DOMMatrix polyfill, which is part of the Geometry Interfaces spec, as that will become standard in browsers. You can make any number of DOMMatrix instances, multiply them in any order, etc, then finally apply the values to the Famous Transform .local property. Follow links in the README to learn more about the DOMMatrix API…

After you apply the values you want to the .local property of a Famous Transform, your Famous Node should be able to render with it. Sorry, I didn’t have time to make a full example, but that’s the idea.

In any case, I’ll be sure to make the matrices of Nodes easily accessible in my prototype (they are DOMMatrix instances).

#3

This is like the hidden manual to famous. Thanks so much for the info.

So about the excessive updates - do you have anything to add? Take a look at refamous.org, a few of us were left hanging, any help would be appreciated.

1 Like
#4

No probs!

That’s cool that you’re making that effort for the community. I’d help if I weren’t dedicated to the new engine.