This article refers to the representation of an object drawn on either the System Panel or the Dashboard Panel. It is aimed at readers who are looking to program components which require a degree of movement on the panel. For most uses of Flowcode world space is all that is required.
Flowcodes representation of scale
Internally an objects scale is kept as a scale factor in the X, Y and Z axis of the object. When accessing the SIM API this is the value that is altered, and relates to the diagonal of a transform matrix:
This is a transformation applied to the object which alters the size of it, and when rendered on the panel of all its child objects.
All API functions deal with this scale - this is mainly because the calculations involved in converting to other representations and back every time scale needs to be set would slow the programs down, but also because conversion to other representations can result in rounding errors and inaccuracies when combined with rotation.
Scale vs Size
For all its internal maths, Flowcode deals with scale.
However, there are a number of representations of the size of an object, and this can cause confusion.
Imagine all objects start off with a size of 1x1x1 (a unit box). The scale of any object can be thought of as its magnification from this unit.
For example, take a marble. If it starts off at 1x1x1, the size of the marble is also its scale (magnification) from this starting point. Double the scale and you will double the size of the marble. In this case, the terms size and scale are interchangeable - they mean exactly the same thing. All objects in Flowcode have a base size of 1x1x1.
OK, so if they are the same, why do we need them both? This relationship holds OK for the marble, but now imagine you have a handful of marbles and you put them all in a bag.
The scale of the bag (its magnification) is 1:1. But its size is dependant on the number and size of the marbles inside it. In the case of the bag, size and scale are not the same. We refer to the size of the bag when considering everything inside it as its local size.
Now, it is worth noting that although doubling the scale of the bag will appear to us to double the size of all the marbles in it, in relation to each other they are still the same. Following the definition of local size above (so consider the scale of the marble and everything in it) none of the marbles sizes have changed.
This is clearly not true from our point of view. We see things in world size, so doubling the scale of the bag doubles the size of everything in it. That is, the world size of the object considers not only the scale of an object and everything inside it, but also the scale of everything it is in. Double the scale of the bag and you double the world size of the marbles and the bag.
When do we use size and when do we use scale?
There are no hard and fast rules, but usually we will use world size when positioning and measuring objects on the panels as this is easier for us to visualise, and use scale when dealing with the maths behind a component as this is the 'raw' value used by the system. We may use the local size of an object when calculating its size in relation to other objects in the same group (so we can position one marble next to another without worrying about the scale of the bag).
Scale and rotation
Flowcode applies rotation before scale to an object. This means that rotating an object 90 degrees in X will make it appear that the height and depth of the object have switched. This is not the case, however, as this rotation will essentially cause the object to be lying on its side, with its Z axis parallel with the ground. Changing the Z scale will therefore affect what the viewer perceives as the Y.
Local and world space
- Main article: Local and World Space
When working with objects in the flowchart, local coordinates are always preferred over world coordinates. This is so that scaling an objects parent does not affect the 'coordinate space' of the program - moving to coordinates (1, 2, 3) will always move to the same point in the component, despite the users scaling of the component, which is out of the component authors control.
It is very difficult to program an object to behave as expected in all circumstances using the world position.
To calculate the world size from an objects local scale, this must be multiplied by the scales of all the objects children and parents in the Component Tree.