In some cases you may find that in order to create a complex element that you have to break it down into multiple formulas.
This can be achieved by using the Switch/Case method.
The Switch part is what will be split up into different cases.
The Case part is where a formula is executed when the value of the Switch is accepted by the Case.
This might sound complicated, and well... you are in the advanced tutorial.
Let's get right into an example.
Initialization
Formula
Switch[ T ] {
Case[ -1, 0.499999] {
X = 0
Y = 5
Z = T * 2 * Radius
B = 0
}
case[ 0.5, 2 ] {
X = Radius + Sin[ (1 + T) * Pi ] * Radius
Y = 15 + Sin[ (0 - T) * Pi ] * 10
Z = Radius + Cos[ (1 + T) * Pi ] * Radius
B = Sin[ (T - 0.5) * Pi ]
}
}
|
There are several things to notice about this formula.
The first is the syntax used for the Switch and the Case statements.
Notice the opening bracket { is on the same line as the Switch and Case statement.
This is very important!
Also notice the closing bracket(s) } is on it's own line(s).
You might think at the end we could just do "} }" instead of using two lines, but a closing bracket must match for the statement.
Since lines are processed one at a time, the first closing bracket closes the Case statement.
Then a new line must start, so on the next line we close the Switch brackets.
Also notice that we are using T for switching.
Even though T only runs from 0 to 1, notice that the Case statements go from -1 to 2.
The reason for this is that T is also calculated for an "Entry Position" and "Exit Position" to the element.
When this happens, T is less than 0 on Entry and greater than 1 on Exit.
If we had just used 0 and 1 in our Case statements, the Entry and Exit Positions would not match any case.
To say the least, this will have extremely undesirable results to your element.
Now, notice the first Case statement.
It goes from -1 to 0.499999.
So why not just 0.4?
Why so many 9's?
The formula calculations have a precision of 6 decimal points.
If you just used 0.4, then a value of 0.45 would not be processed causing bad results to your element.
To make sure that a value can always be processed we need to go out 6 decimal points.
If you Plot the formula, you will notice 2 distinct formulas are being used.
The first half of the element is a basic straight line.
The second half turns to the left, raises upwards and banks.
It is extremely important that each formula connects with the previous formula.
If your formulas do not connect up to each other, your element will have undesirable results.
The plotted formula should look like this:
So how does it work?
When the parser comes to the Switch statement, it will process the variable, value or calculation inside the Switch's open [ and close ] brackets.
Once this value has been obtained, the parser moves on to the Case statements.
When it reaches a Case statement, it will process the variable, value or calculation inside the Case's open [ and close ] brackets.
If there are 2 resulting values separated by a comma, then the 1st value is used as the Minimum value and the 2nd is used as the Maximum value.
If the value of the Switch is greater than or equal to the Minimum value and is less than or equal to the Maximum value, then this case is "TRUE" and the formula inside the Case's open { and close } brackets is calculated.
If the Case is "FALSE" then the formula inside the Case's open { and close } brackets is ignored, and the parser moves on to the next Case statement.
If there is only 1 resulting value when the Case's open [ and close ] brackets are processed, then the value from the Switch must be "EQUAL" (or exactly the same) as the value in the Case.
Also keep in mind that variables do not pass from one case to the next.
If a variable is set in the frst Case, do not expect that variable to be around for any other Case.
This can be tricky if you are setting positions to help link up the different formulas.
Here is a simple example to demonstrate.
This will simply make a straight line, but in 2 Case's to demonstrate.
;This is bad
Switch[ T ] {
Case[ -1, 0.499999 ] {
X = T * 10
Y = 1
Z = 0
tmpX = X
}
Case[ 0.5, 2 ] {
X = tmpX + ( T - 0.5 ) * 10
Y = 1
Z = 0
}
}
;This will correct the bad from above
Switch[ T ] {
Case[ -1, 0.499999 ] {
X = T * 10
Y = 1
Z = 0
}
Case[ 0.5, 2 ] {
tmpX = 0.5 * 10
X = tmpX + ( T - 0.5 ) * 10
Y = 1
Z = 0
}
}
|
Notice that the variable "tmpX" is no longer set in the first Case.
The bad way will actually carry over the last value of tmpX durring the main plotting.
However, after plotting is done, the formula is still used to help fit the beziers to the plot-points.
When this happens, all the variables are cleared.
So tmpX is NULL, and the value of T = 0.5 could (and probably will) be sent into the formula.
This would bypass the first Case, and go right into the second Case.
Since the first Case was never used, it never got a chance to set the tmpX variable.
So instead of setting it in the first case, the good way sets it in the same Case that it's going to be used.
This way, the first Case does not need to be used in order for tmpX to have the proper value.
|