Feature Request: A node's rotational origin should be separate to a node's scale origin
CompSciFutures opened this issue · comments
The origin used by Node#setScale() & Node#setRotation() are currently shared. There exists a need to manipulate these separately.
For example, consider a Node which has its top & left edges aligned to the top left of the screen (say a top nav bar). To maintain an adaptive design, one might use Node#setScale() to first scale it and everything it contains so that it fits onto the screen whilst still maintaining aspect ratios. In this situation the origin would be set to (0,0) so that it can be scaled down and to the right from the top left.
Now consider some operation that requires one to spin the same nav bar (for example, flipping it to show a different nav bar). this would require one to change the x and/or y origin (depending on the animation) to 0.5, thus causing the node to suddenly centre itself on the top left corner before spinning out of place.
I thought a little more about this and some of us prefer the OpenGL transformation matrix way of doing things because that it what we are used to. What would be neat is a camera#setTransform(mat4) so one can use something like glMatrix to do whatever one desires.
I can see a use-case for mutating the transform matrix directly, but I'm very against introducing another origin. Our current MountPoint, Origin, Align system is complicated enough. If those concepts aren't sufficient in certain cases, structuring your scene graph in a more flexible way (e.g. by having a node in between) is the way to go.
Closing, because this introduces unnecessary complexity.
@michaelobriena Feel free to re-open.
Hi Alex,
I do agree with your view re: adding further complexity, but if you are going to take that purist view then you should consider supporting the use of transformation matrices directly, eg, through something like Famous#Node.setTransformationMatrix() and Famous#Node.getTransformationMatrix().
I am finding that the famous coordinate system is slowing down development.
This does come with some problems as I discovered while attempting to build a wrapper overnight. Implementing support for both coordinate systems is troublesome and state can not be converted easily in both directions. The getTransformationMatrix() operation is easy, but the setTransformationMatrix() operation can result in an infinite number of solutions when storing rotational information using the Famous coordinate system.
To fix this in a way that maintains the architectural integrity of Famous, I propose that you consider pulling out the famous coordinate system into a layer that sits between the engine and the framework then represent everything within the engine using 4x4s.
A big task, but certainly one that would make Famous more compatible with the OpenGL styled school of thought. This has some merit as it would make implementing existing algorithms much easier and would make the engine more accessible to those of us that have been taught the classical view of 3D programming.
ap
@Aprender While I appreciate the idea, this is not something we will be working on. As far as I know, a transform origin effecting both rotation and scale is pretty standard.
I am finding that the famous coordinate system is slowing down development.
Can you elaborate on this point? Are you looking for special layouts to ease this?