Revision [529]
Last edited on 2009-05-08 20:41:30 by RalfFlickerAdditions:
By Ralf Flicker.
__Update (8 May 2009)__: The sequencing script described below has received an update, and is documented and demonstrated here: [[http://web.me.com/rflicker/algorhythm.htm algorhythm]].
__Update (8 May 2009)__: The sequencing script described below has received an update, and is documented and demonstrated here: [[http://web.me.com/rflicker/algorhythm.htm algorhythm]].
Revision [390]
Edited on 2009-04-02 03:43:19 by RalfFlickerAdditions:
__Prerequisites__: This part of the tutorial requires the reader to be familiar with the [[Scripting Lua script extension]] for Oxidizer. For some of the scripts presented below, the [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=utils.lua utils.lua]] and [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=mods.lua mods.lua]] script packages are required.
For specific tasks of a limited scope, we may be able to formulate a simple algorithmic description of the motion, for instance: "rotate by 360 degrees over 60 frames," or "modulate the variation weight by a cosine over 100 frames." For such modest sequences, it is a simple matter write a script that generates a sequence of genomes tracing out the motion. Two examples are given below, that apply various modulations to the first genome in the Oxidizer main list (to remind yourself of the Oxidizer Lua implementation, see the [[Scripting scripting tutorial]]). The first example simply zooms by a factor of two (from -1 to +1) and rotates the image by 200 degrees. This could have been done faster by a simple morph directly in Oxidizer, but just for illustrating the principle. The second example uses the same principle but calculates a full Xform (looping over all xforms) and color map rotation by calling the functions ''affine_Prot'' and ''cmap_rot''. This sequence will loop around when animated.::c::<
For specific tasks of a limited scope, we may be able to formulate a simple algorithmic description of the motion, for instance: "rotate by 360 degrees over 60 frames," or "modulate the variation weight by a cosine over 100 frames." For such modest sequences, it is a simple matter write a script that generates a sequence of genomes tracing out the motion. Two examples are given below, that apply various modulations to the first genome in the Oxidizer main list (to remind yourself of the Oxidizer Lua implementation, see the [[Scripting scripting tutorial]]). The first example simply zooms by a factor of two (from -1 to +1) and rotates the image by 200 degrees. This could have been done faster by a simple morph directly in Oxidizer, but just for illustrating the principle. The second example uses the same principle but calculates a full Xform (looping over all xforms) and color map rotation by calling the functions ''affine_Prot'' and ''cmap_rot''. This sequence will loop around when animated.::c::<
Deletions:
For specific tasks of a limited scope, we may be able to formulate a simple algorithmic description of the motion, for instance: "rotate by 360 degrees over 60 frames," or "modulate the variation weight by a cosine over 100 frames." For such modest sequences, it is a simple matter write a script that generates a sequence of genomes tracing out the motion. Two examples are given below, that apply various modulations to the first genome in the Oxidizer main list (to remind yourself of the Oxidizer Lua implementation, see the [[LuaScript script tutorial]]). The first example simply zooms by a factor of two (from -1 to +1) and rotates the image by 200 degrees. This could have been done faster by a simple morph directly in Oxidizer, but just for illustrating the principle. The second example uses the same principle but calculates a full Xform (looping over all xforms) and color map rotation by calling the functions ''affine_Prot'' and ''cmap_rot''. This sequence will loop around when animated.::c::<
Additions:
[2] = {nt, 1.25, curve="lin", a=1}}
interpolation_type = "Linear"}%%>>To see an example of morphing, and to introduce curves and interpolation, let's look at the control script in the box on the right, Example 3. This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously, while simultaneously applying XForm rotations and other things. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3, which disables the scripting action for the duration of the morph, while seq9 sequences the genome morph from the scripting level. These two implementations were so different that it broke the code into two versions, which I have opted to kept as separate scripts. The ability in seq9 to combine curves with morphing on the scripting level means that you can make smooth, flowing morphs even where flam3 would default to linear, like when you don't have enough boundary points for Catmull-Rom interpolation. The following video clip was produced by applying the control script in Example 3 to the same genome that was sequenced with Oxidizer/flam3 in Part I.---
The elements of the morphing sequence ##mseq## in seq9 have the following definition:
with one such table per morphing instance (seq7 has a different definition). We also see a first example of the curve and interpolation keywords being present in the ##cp## table. The complete specification of a control point element is the table:
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. Currently available curves are ''exp'', ''tanh'', ''sinh'', ''cos'', ''cos2'', ''sina'' and ''cosa''. All curves take the parameter ##a##, and ##sina## and ##cosa## also take the second parameter ##b##. Plots of the curves are shown on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Lastly, curves and smooth interpolation can be used independently, but also combined together, as illustrated in the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#smooth interpolation]] section.
Some more comments on the control script in Example 3 and features of seq9 (see also the mods.lua and utils.lua packages for more details):
- (line 4) ##morph## takes three arguments specifying the spatial interpolation ("pol" or "lin"), color interpolation ("hsl" or "rgb") and polarity, which can be either 1 (fixed polarity) or 0 (alternating). The "distance" argument to the morph function is normalized to [0,1], where 0 means the source genome and 1 means the target genome. Under alternating polarity, these roles will invert after each morph.
- (line 5) ##cmod_hsl## can do either hue, saturation or lightness correction by giving it the argument "h","s" or "l". Their value modes are hardwired as follows: hue is additive, saturation and lightness are multiplicative. By ramping the lightness you can implement cheap fade-to-black intros/outros, if you don't have a video editor.
- one could have set the ##mdef## and ##cp## definitions for ##affine_prot## with a ##FOR## loop just like in Example 2, if all channels were doing the same thing. One reason to define them separately, however, is that:
- (line 9, 32-34) you can then easily comment out channels, and insert them back in again. The channel definitions do not have to be consecutively numbered (you do not even have to start at 1 if you don't want to).
- (line 17-18) the morph here uses a combination of an exponential curve with ##a=-1## and smoothing with ##t=0##.
- (line 28-30) the saturation modulation is here just a constant adjustment by +25%, but it could also be varying or peaked (e.g. using the ##cos2## curve) to compensate for some particular genome with washed out colors compared to the rest.
I hope the above discussion, along with the example control scripts, have given you a flavor of one possible way to compose animation sequences via a scripting interface. Listing all the details and caveats of this particular code (seq7/seq9) is beyond the scope of this brief tutorial; for more information, the interested reader is referred to the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm seq7/seq9 home page]], and the [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=doq7.lua doq7.lua]] example control script (for seq7). See also the [[ScriptPage scripts page]] for more example scripts relevant to this tutorial. I leave you with a video clip of a random-walk beat-syncing experiment that was sequenced with seq7, enjoy!::c::
interpolation_type = "Linear"}%%>>To see an example of morphing, and to introduce curves and interpolation, let's look at the control script in the box on the right, Example 3. This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously, while simultaneously applying XForm rotations and other things. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3, which disables the scripting action for the duration of the morph, while seq9 sequences the genome morph from the scripting level. These two implementations were so different that it broke the code into two versions, which I have opted to kept as separate scripts. The ability in seq9 to combine curves with morphing on the scripting level means that you can make smooth, flowing morphs even where flam3 would default to linear, like when you don't have enough boundary points for Catmull-Rom interpolation. The following video clip was produced by applying the control script in Example 3 to the same genome that was sequenced with Oxidizer/flam3 in Part I.---
The elements of the morphing sequence ##mseq## in seq9 have the following definition:
with one such table per morphing instance (seq7 has a different definition). We also see a first example of the curve and interpolation keywords being present in the ##cp## table. The complete specification of a control point element is the table:
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. Currently available curves are ''exp'', ''tanh'', ''sinh'', ''cos'', ''cos2'', ''sina'' and ''cosa''. All curves take the parameter ##a##, and ##sina## and ##cosa## also take the second parameter ##b##. Plots of the curves are shown on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Lastly, curves and smooth interpolation can be used independently, but also combined together, as illustrated in the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#smooth interpolation]] section.
Some more comments on the control script in Example 3 and features of seq9 (see also the mods.lua and utils.lua packages for more details):
- (line 4) ##morph## takes three arguments specifying the spatial interpolation ("pol" or "lin"), color interpolation ("hsl" or "rgb") and polarity, which can be either 1 (fixed polarity) or 0 (alternating). The "distance" argument to the morph function is normalized to [0,1], where 0 means the source genome and 1 means the target genome. Under alternating polarity, these roles will invert after each morph.
- (line 5) ##cmod_hsl## can do either hue, saturation or lightness correction by giving it the argument "h","s" or "l". Their value modes are hardwired as follows: hue is additive, saturation and lightness are multiplicative. By ramping the lightness you can implement cheap fade-to-black intros/outros, if you don't have a video editor.
- one could have set the ##mdef## and ##cp## definitions for ##affine_prot## with a ##FOR## loop just like in Example 2, if all channels were doing the same thing. One reason to define them separately, however, is that:
- (line 9, 32-34) you can then easily comment out channels, and insert them back in again. The channel definitions do not have to be consecutively numbered (you do not even have to start at 1 if you don't want to).
- (line 17-18) the morph here uses a combination of an exponential curve with ##a=-1## and smoothing with ##t=0##.
- (line 28-30) the saturation modulation is here just a constant adjustment by +25%, but it could also be varying or peaked (e.g. using the ##cos2## curve) to compensate for some particular genome with washed out colors compared to the rest.
I hope the above discussion, along with the example control scripts, have given you a flavor of one possible way to compose animation sequences via a scripting interface. Listing all the details and caveats of this particular code (seq7/seq9) is beyond the scope of this brief tutorial; for more information, the interested reader is referred to the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm seq7/seq9 home page]], and the [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=doq7.lua doq7.lua]] example control script (for seq7). See also the [[ScriptPage scripts page]] for more example scripts relevant to this tutorial. I leave you with a video clip of a random-walk beat-syncing experiment that was sequenced with seq7, enjoy!::c::
Deletions:
[2] = {nt, 1.25, curve="lin", a=1}
interpolation_type = "Linear"}%%>>To see an example of morphing, and to introduce curves and interpolation, let's look at the control script in the box on the right, Example 3. This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3 and disables any scripting action for the duration of the morph, while seq9 sequences it from the scripting level. These two implementations were so different that it broke the code into two versions, which I have opted to kept as separate scripts. The ability in seq9 to combine curves with morphing on the scripting level means that you can make smooth, flowing morphs even where flam3 would default to linear, like when you don't have enough boundary points for Catmull-Rom interpolation. The video clip below was produced by applying the control script in Example 3 to the same genome that was sequenced with Oxidizer/flam3 in Part I.
The elements of the morphing sequence ##mseq## have the following definition:---
with one such table per morphing instance. We also see a first example of the curve and interpolation keywords being present in the ##cp## table. The complete specification of a control point element is the table:
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. Currently available curves are ''exp'', ''tanh'', ''sinh'', ''cos'', ''cos2'', ''sina'' and ''cosa''. All curves take the parameter ##a##, and ##sina## and ##cosa## also take the second parameter ##b##. Plots of the curves are shown on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Lastly, curves and smooth interpolation can be used independently, but also combined together, as illustrated in the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#smooth interpolation]] section.::c::
.......
Revision [383]
Edited on 2009-04-01 23:56:51 by RalfFlickerAdditions:
==Morphing, curves and interpolation==::c::>>Example 3: morphing with seq9%%(lua;1)nf = 80 -- frames per morph
mdef[6] = {cmod_hsl,"s"}
mdef[4] = {affine_Orot,{3,"a"}}
--mdef[5] = {affine_Prot,{1,"a"}}
mdef[7] = {affine_Prot,{3,"a"}}
[3] = {2*nf, nf, 3, 4}}
mc,mv = "exp",-1
mi,mt = "smooth",0
[4] = {3*nf, 1, curve=mc, a=mv, inter=mi, t=mt},
[5] = {3.5*nf, 1, curve=mc, a=mv, inter=mi, t=mt}}
nt = 3.5*nf
cp[6] = {
[1] = {0, 1.25, curve="lin", a=1},
[2] = {nt, 1.25, curve="lin", a=1}
--cp[5] = {
-- [1] = {0, 0, curve="tanh", a=1.5},
-- [2] = {nt, 720, curve="tanh", a=1.5}}
[1] = {0, 0, curve="tanh", a=1.5},
[2] = {nt, 720, curve="tanh", a=1.5}}
[1] = {0, 0, curve="tanh", a=1.5},
[2] = {nt, -720, curve="tanh", a=1.5}}
cp[4] = {
[1] = {0, 0, curve="tanh", a=1.5},
[2] = {nt, 720, curve="tanh", a=1.5}}
cp[7] = {
[2] = {2.5*nf, 600, curve="tanh", a=1},
[3] = {nt, 400, curve="tanh", a=1}}
estimator_radius = 4,
estimator_curve = 0.8,
temporal_filter_exp = 4,
interpolation_type = "Linear"}%%>>To see an example of morphing, and to introduce curves and interpolation, let's look at the control script in the box on the right, Example 3. This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3 and disables any scripting action for the duration of the morph, while seq9 sequences it from the scripting level. These two implementations were so different that it broke the code into two versions, which I have opted to kept as separate scripts. The ability in seq9 to combine curves with morphing on the scripting level means that you can make smooth, flowing morphs even where flam3 would default to linear, like when you don't have enough boundary points for Catmull-Rom interpolation. The video clip below was produced by applying the control script in Example 3 to the same genome that was sequenced with Oxidizer/flam3 in Part I.
""
""
The elements of the morphing sequence ##mseq## have the following definition:---
""
""
mdef[6] = {cmod_hsl,"s"}
mdef[4] = {affine_Orot,{3,"a"}}
--mdef[5] = {affine_Prot,{1,"a"}}
mdef[7] = {affine_Prot,{3,"a"}}
[3] = {2*nf, nf, 3, 4}}
mc,mv = "exp",-1
mi,mt = "smooth",0
[4] = {3*nf, 1, curve=mc, a=mv, inter=mi, t=mt},
[5] = {3.5*nf, 1, curve=mc, a=mv, inter=mi, t=mt}}
nt = 3.5*nf
cp[6] = {
[1] = {0, 1.25, curve="lin", a=1},
[2] = {nt, 1.25, curve="lin", a=1}
--cp[5] = {
-- [1] = {0, 0, curve="tanh", a=1.5},
-- [2] = {nt, 720, curve="tanh", a=1.5}}
[1] = {0, 0, curve="tanh", a=1.5},
[2] = {nt, 720, curve="tanh", a=1.5}}
[1] = {0, 0, curve="tanh", a=1.5},
[2] = {nt, -720, curve="tanh", a=1.5}}
cp[4] = {
[1] = {0, 0, curve="tanh", a=1.5},
[2] = {nt, 720, curve="tanh", a=1.5}}
cp[7] = {
[2] = {2.5*nf, 600, curve="tanh", a=1},
[3] = {nt, 400, curve="tanh", a=1}}
estimator_radius = 4,
estimator_curve = 0.8,
temporal_filter_exp = 4,
interpolation_type = "Linear"}%%>>To see an example of morphing, and to introduce curves and interpolation, let's look at the control script in the box on the right, Example 3. This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3 and disables any scripting action for the duration of the morph, while seq9 sequences it from the scripting level. These two implementations were so different that it broke the code into two versions, which I have opted to kept as separate scripts. The ability in seq9 to combine curves with morphing on the scripting level means that you can make smooth, flowing morphs even where flam3 would default to linear, like when you don't have enough boundary points for Catmull-Rom interpolation. The video clip below was produced by applying the control script in Example 3 to the same genome that was sequenced with Oxidizer/flam3 in Part I.
""
| The genome (sequence4.flam3) from Part I sequenced with seq9. |
The elements of the morphing sequence ##mseq## have the following definition:---
""
| Random-walk beat-syncing with seq7. |
Deletions:
mdef,cp,mseq = {},{},{}
[3] = {2*nf, nf, 3, 4}
mc,mv = "tanh",0.5
mi,mt = "linear",0
[4] = {3*nf, 1, curve=mc, a=mv, inter=mi, t=mt}}
%%>>To see an example of morphing, and to introduce curves and interpolation, let's look at the control script in the box on the right, Example 3. This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3 and disables any scripting action for the duration of the morph, while seq9 sequences it from the scripting level. These two implementations were so different that it broke the code into two versions, which I have opted to kept as separate scripts. The ability in seq9 to combine curves with morphing on the scripting level means that you can make smooth, flowing morphs even where flam3 would default to linear, like when you don't have enough boundary points for Catmull-Rom interpolation. The elements of the morphing sequence ##mseq## have the following definition:---
>>Example 4: genome morphing + xform rotations control script for seq9%%(lua;1)ng = #oxidizer_genomes
mdef,cp,mseq = {},{},{}
mdef[1] = {morph,{"pol","hue",1}} -- 0=alternating polarity, 1=fixed
--mdef[4] = {affine_Orot,{3,"a"}}
mdef[5] = {affine_Prot,{1,"a"}}
nf = 30
mlen = 60
mstart = {}
for i=1,ng-1 do mstart[i] = nf+(i-1)*(nf+mlen) end
for i=1,ng-1 do table.insert(mseq, {mstart[i], mlen, i, i+1}) end
nt = 3*(nf+mlen)+nf
mcurve = "exp"
mval = -1
mint = "smooth"
mt = 0
[1] = {mstart[1], 0, curve=mcurve, a=mval, inter=mint, t=0},
[2] = {mstart[1]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0},
[3] = {mstart[2], 0, curve=mcurve, a=mval, inter=mint, t=0},
[4] = {mstart[2]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0},
[5] = {mstart[3], 0, curve=mcurve, a=mval, inter=mint, t=0},
[6] = {mstart[3]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0}
[2] = {nt, 720, curve="tanh", a=1}}
[1] = {0, 0, curve="tanh", a=1},
[2] = {nt, -720, curve="tanh", a=1}}
--cp[4] = {
-- [1] = {0, 0, curve="sinh", a=1},
-- [2] = {nt, 720, curve="sinh", a=1}}
cp[5] = {
[1] = {0, 0, curve="sinh", a=1},
[2] = {nt, 720, curve="sinh", a=1}}
estimator_radius = 3,
estimator_curve = 0.75,
temporal_filter_exp = 7,
interpolation_type = "Linear"}%%>>
Revision [376]
Edited on 2009-03-31 02:38:46 by RalfFlickerAdditions:
%%>>To see an example of morphing, and to introduce curves and interpolation, let's look at the control script in the box on the right, Example 3. This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3 and disables any scripting action for the duration of the morph, while seq9 sequences it from the scripting level. These two implementations were so different that it broke the code into two versions, which I have opted to kept as separate scripts. The ability in seq9 to combine curves with morphing on the scripting level means that you can make smooth, flowing morphs even where flam3 would default to linear, like when you don't have enough boundary points for Catmull-Rom interpolation. The elements of the morphing sequence ##mseq## have the following definition:---
with one such table per morphing instance. We also see a first example of the curve and interpolation keywords being present in the ##cp## table. The complete specification of a control point element is the table:
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. Currently available curves are ''exp'', ''tanh'', ''sinh'', ''cos'', ''cos2'', ''sina'' and ''cosa''. All curves take the parameter ##a##, and ##sina## and ##cosa## also take the second parameter ##b##. Plots of the curves are shown on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Lastly, curves and smooth interpolation can be used independently, but also combined together, as illustrated in the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#smooth interpolation]] section.::c::
with one such table per morphing instance. We also see a first example of the curve and interpolation keywords being present in the ##cp## table. The complete specification of a control point element is the table:
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. Currently available curves are ''exp'', ''tanh'', ''sinh'', ''cos'', ''cos2'', ''sina'' and ''cosa''. All curves take the parameter ##a##, and ##sina## and ##cosa## also take the second parameter ##b##. Plots of the curves are shown on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Lastly, curves and smooth interpolation can be used independently, but also combined together, as illustrated in the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#smooth interpolation]] section.::c::
Deletions:
with one such table per morphing instance. We also see an example of the curve and interpolation keywords being used. The complete specification of a control point element is the table:
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. For a list of the available curves refer to the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Curves and smooth interpolation can be used independently, but also combined together.::c::
Revision [374]
Edited on 2009-03-31 02:08:54 by RalfFlickerAdditions:
The ##mdef## and ##cp## tables are required objects within a control script. Two more optional tables that seq9 will parse if presented with are the morph sequence ''mseq'' and global environment ''genv'' tables. The morph sequence table is required if the morph function is specified as a modulation channel. If no morph sequence is present, seq9 will by default apply its modulations to the first genome in Oxidizer, that is, ##oxidizer_genomes[1]##. The global environment parameters are just static adjustments that are not animated; for instance, in case some of the genomes of the sequence do not have consistent rendering parameters, you can make sure from the control script that they are all set consistently. This also makes it easy to alternate between generating preview sequences and final rendering sequences, by switching off density estimation in the former.
==Morphing, curves and interpolation==::c::>>Example 3: morphing with seq9%%(lua)nf = 60 -- frames per morph
mdef[1] = {morph,{"pol","hsl",0}} -- 0=alternating polarity, 1=fixed
mseq = {
[1] = {0, nf, 1, 2},
[2] = {nf, nf, 2, 3},
[3] = {2*nf, nf, 3, 4}
mc,mv = "tanh",0.5
mi,mt = "linear",0
[1] = {0, 0, curve=mc, a=mv, inter=mi, t=mt},
[2] = {nf, 1, curve=mc, a=mv, inter=mi, t=mt},
[3] = {2*nf, 0, curve=mc, a=mv, inter=mi, t=mt},
[4] = {3*nf, 1, curve=mc, a=mv, inter=mi, t=mt}}
%%>>To see an example of morphing, and to introduce the remaining features, curves and interpolation, let's look at a different control script for a marginally more advanced sequence (box on the right, Example 3). This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3, while seq9 sequences it explicitly. These two implementations are so different that it broke the code into two versions that are best kept separate. The elements of the morphing sequence ##mseq## have the following definition:---
##{start_time, morph_length, source_genome, target_genome}##
with one such table per morphing instance. We also see an example of the curve and interpolation keywords being used. The complete specification of a control point element is the table:
##{time, value, curve=, a=, b=, inter=, t=}##
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. For a list of the available curves refer to the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Curves and smooth interpolation can be used independently, but also combined together.::c::
>>Example 4: genome morphing + xform rotations control script for seq9%%(lua;1)ng = #oxidizer_genomes
mdef[1] = {morph,{"pol","hue",1}} -- 0=alternating polarity, 1=fixed
[1] = {mstart[1], 0, curve=mcurve, a=mval, inter=mint, t=0},
[2] = {mstart[1]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0},
[3] = {mstart[2], 0, curve=mcurve, a=mval, inter=mint, t=0},
[4] = {mstart[2]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0},
[5] = {mstart[3], 0, curve=mcurve, a=mval, inter=mint, t=0},
[6] = {mstart[3]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0}
interpolation_type = "Linear"}%%>>
.......
==Morphing, curves and interpolation==::c::>>Example 3: morphing with seq9%%(lua)nf = 60 -- frames per morph
mdef[1] = {morph,{"pol","hsl",0}} -- 0=alternating polarity, 1=fixed
mseq = {
[1] = {0, nf, 1, 2},
[2] = {nf, nf, 2, 3},
[3] = {2*nf, nf, 3, 4}
mc,mv = "tanh",0.5
mi,mt = "linear",0
[1] = {0, 0, curve=mc, a=mv, inter=mi, t=mt},
[2] = {nf, 1, curve=mc, a=mv, inter=mi, t=mt},
[3] = {2*nf, 0, curve=mc, a=mv, inter=mi, t=mt},
[4] = {3*nf, 1, curve=mc, a=mv, inter=mi, t=mt}}
%%>>To see an example of morphing, and to introduce the remaining features, curves and interpolation, let's look at a different control script for a marginally more advanced sequence (box on the right, Example 3). This script morphs consecutively between four genomes using the ''morph'' Lua function mentioned previously. This marks the difference between seq7 and seq9: the former hands over the morphing to flam3, while seq9 sequences it explicitly. These two implementations are so different that it broke the code into two versions that are best kept separate. The elements of the morphing sequence ##mseq## have the following definition:---
##{start_time, morph_length, source_genome, target_genome}##
with one such table per morphing instance. We also see an example of the curve and interpolation keywords being used. The complete specification of a control point element is the table:
##{time, value, curve=, a=, b=, inter=, t=}##
where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline discussed in [[Animation Part I]]. For a list of the available curves refer to the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Curves and smooth interpolation can be used independently, but also combined together.::c::
>>Example 4: genome morphing + xform rotations control script for seq9%%(lua;1)ng = #oxidizer_genomes
mdef[1] = {morph,{"pol","hue",1}} -- 0=alternating polarity, 1=fixed
[1] = {mstart[1], 0, curve=mcurve, a=mval, inter=mint, t=0},
[2] = {mstart[1]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0},
[3] = {mstart[2], 0, curve=mcurve, a=mval, inter=mint, t=0},
[4] = {mstart[2]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0},
[5] = {mstart[3], 0, curve=mcurve, a=mval, inter=mint, t=0},
[6] = {mstart[3]+mlen, 1, curve=mcurve, a=mval, inter=mint, t=0}
interpolation_type = "Linear"}%%>>
.......
Deletions:
>>Example 3: genome morphing + xform rotations control script%%(lua;1)ng = #oxidizer_genomes
mdef[1] = {morph,{"pol","hue",1}} -- 0=alternate polarity, 1=fixed
[1] = {mstart[1], 0, curve=mcurve, a=mval, inter='linear', t=0},
[2] = {mstart[1]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0},
[3] = {mstart[2], 0, curve=mcurve, a=mval, inter='linear', t=0},
[4] = {mstart[2]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0},
[5] = {mstart[3], 0, curve=mcurve, a=mval, inter='linear', t=0},
[6] = {mstart[3]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0}
interpolation_type = "Linear"}%%>>To introduce the remaining features, curves and interpolation, let's look at a different control script for a marginally more advanced sequence (box on the right).
The complete specification of a control point element is the table:
%%(lua) {time, value, curve=, a=, b=, inter=, t=}%%
Where ''curve'' is a string specifying the type of curve to use (by default linear, if this keyword is omitted), and ''a'' and ''b'' are adjustable parameters of the curve. The interpolation key ''inter'' can be set to either ''smooth'' or ''linear'' (default linear), and ''t'' is the tension parameter of the Catmull-Rom spline. For a list of the available curves refer to the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm#curves seq7 home page]]. Curves and smooth interpolation can be used independently, but also combined together.
Revision [373]
Edited on 2009-03-31 00:59:17 by RalfFlickerAdditions:
>>Example 3: genome morphing + xform rotations control script%%(lua;1)ng = #oxidizer_genomes
mdef[1] = {morph,{"pol","hue",1}} -- 0=alternate polarity, 1=fixed
nf = 30
mlen = 60
for i=1,ng-1 do mstart[i] = nf+(i-1)*(nf+mlen) end
nt = 3*(nf+mlen)+nf
[1] = {mstart[1], 0, curve=mcurve, a=mval, inter='linear', t=0},
[2] = {mstart[1]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0},
[3] = {mstart[2], 0, curve=mcurve, a=mval, inter='linear', t=0},
[4] = {mstart[2]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0},
[5] = {mstart[3], 0, curve=mcurve, a=mval, inter='linear', t=0},
[6] = {mstart[3]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0}
mdef[1] = {morph,{"pol","hue",1}} -- 0=alternate polarity, 1=fixed
nf = 30
mlen = 60
for i=1,ng-1 do mstart[i] = nf+(i-1)*(nf+mlen) end
nt = 3*(nf+mlen)+nf
[1] = {mstart[1], 0, curve=mcurve, a=mval, inter='linear', t=0},
[2] = {mstart[1]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0},
[3] = {mstart[2], 0, curve=mcurve, a=mval, inter='linear', t=0},
[4] = {mstart[2]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0},
[5] = {mstart[3], 0, curve=mcurve, a=mval, inter='linear', t=0},
[6] = {mstart[3]+mlen, 1, curve=mcurve, a=mval, inter='linear', t=0}
Deletions:
mdef[1] = {morph,{"pol","hue",0}} -- 0=alternate, 1=fixed polarity
nf = 80
mlen = nf
for i=1,ng-1 do mstart[i] = (i-1)*mlen end
[1] = {0, 0, curve=mcurve, a=mval, inter=mint, t=mt},
[2] = {nf, 1, curve=mcurve, a=mval, inter=mint, t=mt},
[3] = {2*nf, 0, curve=mcurve, a=mval, inter=mint, t=mt},
[4] = {3*nf, 1, curve=mcurve, a=mval, inter=mint, t=mt}
nt = 3*nf+nf/2
Revision [372]
Edited on 2009-03-31 00:51:43 by RalfFlickerAdditions:
These modes offer a wide range of possibilities for different types of parameter modulations, and all the Xform related functions in the mods.lua package have this structure (the morphing function ''morph'' and the color adjustment functions, e.g., cmap_rot and ''cmod_hsl'', work differently). We could also sequence a genome morph between different genomes in this type of script, by using a Lua morphing function, although we pay the price of not being able to exploit all the special tricks that are coded into flam3, and which can not be reproduced on the scripting level. Consequently, the Lua morph function (in the utils package) only interpolates the continuous genome parameters, and currently does nothing with discrete parameters like genome symmetry and final xform. But if you have no jumps in the discrete parameters, the benefit of using the Lua morph function instead of letting flam3 do the genome interpolation is that you can now add other parameter modulations on the scripting level, simultaneously with the genome morph. We will see some examples of this in the next section.
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. For repeating segments (for instance, for beat-syncing) it is also easy to use ##FOR## loops over control points to define repeating modulations of indefinite length (which may also include a random element, to make them less predictable). Lastly, the interface is substantially cleaner, giving an easier overview of the sequence of control points and the parameters being modulated.
The ##mdef## and ##cp## tables are required objects within a control script. Two more optional tables that seq9 will parse if presented with are the morph sequence ''mseq'' and global environment ''genv'' tables. The morph sequence table is required if the morph function is specified as a modulation channel. If no morph sequence is present, seq9 will by default apply its modulations to the first genome in Oxidizer, that is, ##oxidizer_genomes[1]##. The global environment parameters are just static adjustments that are not animated; for instance, in case some of the genomes of the sequence do not have consistent rendering parameters, you can make sure from the control script that they are all set consistently. This also makes it easy to alternate between generating preview sequences and final rendering sequences, by switching off density estimation in the former.::c::
>>%%(lua;1)ng = #oxidizer_genomes
mdef,cp,mseq = {},{},{}
mdef[1] = {morph,{"pol","hue",0}} -- 0=alternate, 1=fixed polarity
mdef[2] = {affine_Prot,{2,"a"}}
mdef[3] = {affine_Prot,{4,"a"}}
--mdef[4] = {affine_Orot,{3,"a"}}
mdef[5] = {affine_Prot,{1,"a"}}
nf = 80
mlen = nf
mstart = {}
for i=1,ng-1 do mstart[i] = (i-1)*mlen end
for i=1,ng-1 do table.insert(mseq, {mstart[i], mlen, i, i+1}) end
mcurve = "exp"
mval = -1
mint = "smooth"
mt = 0
[1] = {0, 0, curve=mcurve, a=mval, inter=mint, t=mt},
[2] = {nf, 1, curve=mcurve, a=mval, inter=mint, t=mt},
[3] = {2*nf, 0, curve=mcurve, a=mval, inter=mint, t=mt},
[4] = {3*nf, 1, curve=mcurve, a=mval, inter=mint, t=mt}
nt = 3*nf+nf/2
[1] = {0, 0, curve="tanh", a=1},
[2] = {nt, 720, curve="tanh", a=1}}
cp[3] = {
[1] = {0, 0, curve="tanh", a=1},
[2] = {nt, -720, curve="tanh", a=1}}
--cp[4] = {
-- [1] = {0, 0, curve="sinh", a=1},
-- [2] = {nt, 720, curve="sinh", a=1}}
cp[5] = {
[1] = {0, 0, curve="sinh", a=1},
[2] = {nt, 720, curve="sinh", a=1}}
genv = {
supersample = 3,
filter_shape = "Gaussian",
filter = 0.6,
quality = 1,
estimator_radius = 3,
estimator_curve = 0.75,
estimator_minimum = 0,
temporal_samples = 60,
temporal_filter_type = "Exponent",
temporal_filter_exp = 7,
interpolation = "Linear",
interpolation_type = "Linear"}%%>>To introduce the remaining features, curves and interpolation, let's look at a different control script for a marginally more advanced sequence (box on the right).
The complete specification of a control point element is the table:
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. For repeating segments (for instance, for beat-syncing) it is also easy to use ##FOR## loops over control points to define repeating modulations of indefinite length (which may also include a random element, to make them less predictable). Lastly, the interface is substantially cleaner, giving an easier overview of the sequence of control points and the parameters being modulated.
The ##mdef## and ##cp## tables are required objects within a control script. Two more optional tables that seq9 will parse if presented with are the morph sequence ''mseq'' and global environment ''genv'' tables. The morph sequence table is required if the morph function is specified as a modulation channel. If no morph sequence is present, seq9 will by default apply its modulations to the first genome in Oxidizer, that is, ##oxidizer_genomes[1]##. The global environment parameters are just static adjustments that are not animated; for instance, in case some of the genomes of the sequence do not have consistent rendering parameters, you can make sure from the control script that they are all set consistently. This also makes it easy to alternate between generating preview sequences and final rendering sequences, by switching off density estimation in the former.::c::
>>%%(lua;1)ng = #oxidizer_genomes
mdef,cp,mseq = {},{},{}
mdef[1] = {morph,{"pol","hue",0}} -- 0=alternate, 1=fixed polarity
mdef[2] = {affine_Prot,{2,"a"}}
mdef[3] = {affine_Prot,{4,"a"}}
--mdef[4] = {affine_Orot,{3,"a"}}
mdef[5] = {affine_Prot,{1,"a"}}
nf = 80
mlen = nf
mstart = {}
for i=1,ng-1 do mstart[i] = (i-1)*mlen end
for i=1,ng-1 do table.insert(mseq, {mstart[i], mlen, i, i+1}) end
mcurve = "exp"
mval = -1
mint = "smooth"
mt = 0
[1] = {0, 0, curve=mcurve, a=mval, inter=mint, t=mt},
[2] = {nf, 1, curve=mcurve, a=mval, inter=mint, t=mt},
[3] = {2*nf, 0, curve=mcurve, a=mval, inter=mint, t=mt},
[4] = {3*nf, 1, curve=mcurve, a=mval, inter=mint, t=mt}
nt = 3*nf+nf/2
[1] = {0, 0, curve="tanh", a=1},
[2] = {nt, 720, curve="tanh", a=1}}
cp[3] = {
[1] = {0, 0, curve="tanh", a=1},
[2] = {nt, -720, curve="tanh", a=1}}
--cp[4] = {
-- [1] = {0, 0, curve="sinh", a=1},
-- [2] = {nt, 720, curve="sinh", a=1}}
cp[5] = {
[1] = {0, 0, curve="sinh", a=1},
[2] = {nt, 720, curve="sinh", a=1}}
genv = {
supersample = 3,
filter_shape = "Gaussian",
filter = 0.6,
quality = 1,
estimator_radius = 3,
estimator_curve = 0.75,
estimator_minimum = 0,
temporal_samples = 60,
temporal_filter_type = "Exponent",
temporal_filter_exp = 7,
interpolation = "Linear",
interpolation_type = "Linear"}%%>>To introduce the remaining features, curves and interpolation, let's look at a different control script for a marginally more advanced sequence (box on the right).
The complete specification of a control point element is the table:
Deletions:
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. For repeating segments (for instance, for beat-syncing) it is also easy to use ##FOR## loops over control points to define repeating modulations of indefinite length (which may also include a random element, to make them less predictable). Lastly, the interface is significantly cleaner, giving an easier overview of the sequence of control points and which parameters are being modulated.
The ##mdef## and ##cp## tables are required within a control script. Two more optional tables that seq9 will parse if presented with are the morph sequence ''mseq'' and global environment ''genv'' tables. The morph sequence table is required if the morph function is specified as a modulation channel. If no morph sequence is present, seq9 will by default apply the specified modulations to the first genome in Oxidizer, that is, ##oxidizer_genomes[1]##. The global environment parameters are just static adjustments that are not animated; for instance, in case some of the genomes of the sequence do not have consistent rendering parameters.
.....
(need to rewrite the seq7 part....it's seq9 now)
There is also a lot of untapped potential here in using loops to define control points that repeat a certain pattern, for instance, if you are beat-syncing the animation to music.
Not yet explored in the examples above are the curve and smoothing features mentioned, which are optional keywords that can be added to each control point. The complete specification of a control point element is the table:
Revision [371]
Edited on 2009-03-31 00:24:07 by RalfFlickerAdditions:
To introduce the terminology of the next section, we shall henceforth think of the genome parameters being actively modified by the script as "modulation channels," and the starting and stopping configurations as "control points" (essentially key frames, but with a more general role than in [[Animation Part I]]). The above script examples show how to easily script a frame sequencer for simple morphs and loops, where the modulation channels and control points are hard-coded into a ##FOR## loop. But if we want to have many more control points for a longer animation sequence, all of which might address //different// modulation channels and be of different lengths, etc. - then doing it this way will be just as much work as doing key frame authoring by hand in Oxidizer. We need a more efficient interface for authoring movie sequences without being troubled by all the details that goes on under the hood.----
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. For repeating segments (for instance, for beat-syncing) it is also easy to use ##FOR## loops over control points to define repeating modulations of indefinite length (which may also include a random element, to make them less predictable). Lastly, the interface is significantly cleaner, giving an easier overview of the sequence of control points and which parameters are being modulated.
The ##mdef## and ##cp## tables are required within a control script. Two more optional tables that seq9 will parse if presented with are the morph sequence ''mseq'' and global environment ''genv'' tables. The morph sequence table is required if the morph function is specified as a modulation channel. If no morph sequence is present, seq9 will by default apply the specified modulations to the first genome in Oxidizer, that is, ##oxidizer_genomes[1]##. The global environment parameters are just static adjustments that are not animated; for instance, in case some of the genomes of the sequence do not have consistent rendering parameters.
There is also a lot of untapped potential here in using loops to define control points that repeat a certain pattern, for instance, if you are beat-syncing the animation to music.
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. For repeating segments (for instance, for beat-syncing) it is also easy to use ##FOR## loops over control points to define repeating modulations of indefinite length (which may also include a random element, to make them less predictable). Lastly, the interface is significantly cleaner, giving an easier overview of the sequence of control points and which parameters are being modulated.
The ##mdef## and ##cp## tables are required within a control script. Two more optional tables that seq9 will parse if presented with are the morph sequence ''mseq'' and global environment ''genv'' tables. The morph sequence table is required if the morph function is specified as a modulation channel. If no morph sequence is present, seq9 will by default apply the specified modulations to the first genome in Oxidizer, that is, ##oxidizer_genomes[1]##. The global environment parameters are just static adjustments that are not animated; for instance, in case some of the genomes of the sequence do not have consistent rendering parameters.
There is also a lot of untapped potential here in using loops to define control points that repeat a certain pattern, for instance, if you are beat-syncing the animation to music.
Deletions:
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. The interface is also cleaner, giving a direct overview of the sequence of control points, and which parameters are being modulated.
Here follows a brief overview of the parts and functions. There are four Lua tables that can be parsed by seq7 and part of the control script:
~##mdef## : modulation channels definition
~##cp## : control points (i.e. key frames)
~##morph## : morph sequence definition [optional]
~##genv## : global genome parameter settings [optional]
The first two (##mdef##, ##cp##) are required, while the last two (##morph##, ##genv##) are optional and can be omitted if no flam3 morphing or global genome parameter adjustments are requested. Here is an overview of how this works for animation scripting:
~-**Modulation channels.** Every genome parameter that you want to vary in some way must first be defined as a modulation channel in the ##mdef## table. This makes the parameter available for control point scripting.
~-**Control points.** For each channel defined in ##mdef## you then author/compose a sequence of control points (i.e. animation key frames) in the ##cp## table. The control points are time-value pairs, specifying the fixed points of the sequence. Between control points, seq7 will then interpolate appropriate values.
~-**Curve** and **smoothing.** You can also specify how a parameter value should move between control points by adding curve and interpolation keys to the ##cp## table:
~~o The curve key defines the basic shape of the transition from one control point to the next.
~~o Additionally one can invoke spline interpolation (Catmull-Rom) in order to smooth out the transitions across control point edges.
~-**Morphing.** You may optionally specify a genome morph sequence in the ##morph## table, to tell seq7 when to switch to the next genome in the list and initiate a flam3 morph sequence between two genomes. A morph trigger has additional duration and padding parameters.
~-**Global settings.** Lastly, you may in the control script also take care of any additional fixed genome parameter adjustments by defining the key-value pairs in the ##genv## table.
To see some simple examples of how a control script is written, let's redo Examples 1 and 2 above as control scripts. First the modulation channels definition table ##mdef## is set up for the parameters to be animated, with the appropriate function value modifiers, as described above. Each channel definition in ##mdef## must have a corresponding sequencing channel in the control points table ##cp## - if there is a mismatch between the ##mdef## and ##cp## channel setup, seq7 will complain. Each channel in ##cp## is a table of control points, and each control point is a table of time-value pairs, with optional curve and smoothing keywords. You can try the control scripts given below on a genome in Oxidizer: click the #%Grab#% button to save the code block; rename or relocate the file as necessary for seq7 to find it, or edit the path and file names in seq7; then run the seq7 script in Oxidizer.
Modifying and extending the sequences is also much easier, by simply inserting more table elements into ##mdef## and ##cp## to get more modulation channels and control points. There is also a lot of untapped potential here in using loops to define control points that repeat a certain pattern, for instance, if you are beat-syncing the animation to music.
Revision [370]
Edited on 2009-03-30 23:52:36 by RalfFlickerAdditions:
Having said all that, let's look at what the control scripts for the two examples given previously would look like:::c::<
sdir = luadir.."scripts_seq/" -- my control script directory
infile = sdir..qfile -- full path to control script%%>>In order to test these scripts, you need to edit seq9 to set up the file paths and file names for the external packages and the input control script, as indicated on lines 22-26 in the box on the right. In this setup, ''mdir'' must be the full path to the folder containing the utils and mods packages, and ''infile'' must be the full path to the control script file, but otherwise you may rearrange things to better reflect your directory structure (for instance, you do not have to use the intermediate ''luadir'', ''sdir'' and ''qfile'' variables if you don't want to).
Looking at the example control scripts above, we see that the animated parameters are defined in the table ''mdef'' (modulations definition), and the key frames are defined in the table ''cp'' (control points). A modulation channel is a table containing the name of the genome parameter or a function, followed by another table containing any required arguments (which vary between different functions) and the mode selector already encountered. The element ##cp[i]## defines the control point sequence for the genome parameter with the same-numbered modulation channel definition ##mdef[i]##. Each control point is a table of time-value pairs, with optional curve and interpolation keywords (discussed below). These are the basics of a control scripts for seq9.
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. The interface is also cleaner, giving a direct overview of the sequence of control points, and which parameters are being modulated.
Modifying and extending the sequences is also much easier, by simply inserting more table elements into ##mdef## and ##cp## to get more modulation channels and control points. There is also a lot of untapped potential here in using loops to define control points that repeat a certain pattern, for instance, if you are beat-syncing the animation to music.
sdir = luadir.."scripts_seq/" -- my control script directory
infile = sdir..qfile -- full path to control script%%>>In order to test these scripts, you need to edit seq9 to set up the file paths and file names for the external packages and the input control script, as indicated on lines 22-26 in the box on the right. In this setup, ''mdir'' must be the full path to the folder containing the utils and mods packages, and ''infile'' must be the full path to the control script file, but otherwise you may rearrange things to better reflect your directory structure (for instance, you do not have to use the intermediate ''luadir'', ''sdir'' and ''qfile'' variables if you don't want to).
Looking at the example control scripts above, we see that the animated parameters are defined in the table ''mdef'' (modulations definition), and the key frames are defined in the table ''cp'' (control points). A modulation channel is a table containing the name of the genome parameter or a function, followed by another table containing any required arguments (which vary between different functions) and the mode selector already encountered. The element ##cp[i]## defines the control point sequence for the genome parameter with the same-numbered modulation channel definition ##mdef[i]##. Each control point is a table of time-value pairs, with optional curve and interpolation keywords (discussed below). These are the basics of a control scripts for seq9.
Compared to the non-interpolating formulation in the previous section, what was gained by all this? For one thing, adding more modulation channels and new movie segments is as easy as inserting additional table elements in the ##mdef## and ##cp## tables. The interface is also cleaner, giving a direct overview of the sequence of control points, and which parameters are being modulated.
Modifying and extending the sequences is also much easier, by simply inserting more table elements into ##mdef## and ##cp## to get more modulation channels and control points. There is also a lot of untapped potential here in using loops to define control points that repeat a certain pattern, for instance, if you are beat-syncing the animation to music.
Deletions:
sdir = luadir.."scripts_seq/" -- control script directory
dofile(mdir..'utils.lua')
dofile(mdir..'mods.lua')
infile = sdir..qfile -- full path to control script%%>>In order to test these scripts, you need to edit seq9 to set up the file paths and file names for the external packages and the input control script, as indicated on lines 22-28 in the box on the right.
>>seq9 file paths and control script
mdir = luadir.."scripts_dev/" -- utils and mods directory
sdir = luadir.."scripts_seq/" -- control script directory
qfile = "cs1.lua" -- control script file name%%>>To start working with seq7, the file paths and names on lines 22-25 (shown right) must be setup first. If for some reason your "mdir" and "sdir" are not sub-directories under "luadir" like assumed here, then just rearrange those path variables to make it work with your folder structure. Once this is set up, you should never need to edit seq7.lua other than the "qfile" variable for every new control script file name.
Compared to the non-interpolating examples before, what was gained by all this? For one thing, the interface is cleaner, giving a direct overview of the progression of control points (##cp##), and which parameters are being modulated (##mdef##). Modifying and extending the sequences is also much easier, by simply inserting more table elements into ##mdef## and ##cp## to get more modulation channels and control points. There is also a lot of untapped potential here in using loops to define control points that repeat a certain pattern, for instance, if you are beat-syncing the animation to music.
Revision [369]
Edited on 2009-03-30 23:14:09 by RalfFlickerAdditions:
Obviously, if you want the morphing to be done in a //specific// way, you have no way of telling flam3 to do this, so we must instead calculate every time step of each genome morph ourselves. Also, if you have been doing everything manually so far, inserting key frames and adjusting parameters etc - at some point in the growing length of the sequence this procedure simply becomes too cumbersome and tedious to carry out by hand. This kind of work is suitable for doing with a script, for efficiency and repeatability (at least for the time being; the day Oxidizer implements an Animation Sequencer GUI all this will become obsolete). Here are a few examples of animations that you would do with a sequencing script:
- beat-syncing an animation to music
- "storyboard" sequences of many separate steps
- randomized looping modulations
- random walk morphing between genomes
There are many ways one could go about these things, and the scripts presented below are merely offered as examples of the types of methods that can be employed. One method of key frame authoring for an interpolating script will be the topic of the final section. This code has gradually grown out of a series of more specialized, non-interpolating animation sequencers that were designed to do just one specific thing, for instance Xform rotations. It may be of interest to the reader to also look at some of these earlier non-interpolating codes first, which is the topic of the next section.----
To introduce the terminology of the next section, we shall henceforth think of the genome parameters being actively modified by the script as "modulation channels," and the starting and stopping configurations as "control points" (essentially key frames, but with a more general role than in [[Animation Part I]]). The above script examples show how to easily script a frame sequencer for simple morphs and loops, where the modulation channels and control points are hard-coded into a FOR-loop. But if we want to have many more control points for a longer animation sequence, all of which might address //different// modulation channels and be of different lengths, etc. - then doing it this way will be just as much work as doing key frame authoring by hand in Oxidizer. We need a more efficient interface for authoring movie sequences without being troubled by all the details that goes on under the hood.----
One script that goes some way towards such a simplified interface goes by the unglamorous name [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=seq9.lua seq9.lua]]. This code is a parsing and interpolation engine that will do all the heavy lifting, while the movie director can focus on authoring "control scripts" for it. The technical details of this code is documented on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm seq7/seq9 home page]], which also contains several examples of animations produced with it.
It must be emphasized that while I offer these scripts as examples of tools that facilitate animation authoring, they are by no means trivial to use, and a modicum of manual scripting is still required. Those of you who have worked with audio or video sequencers like Logic or Final Cut will know what I am talking about: the timing, shaping, blending and cross-fading of events and segments - even with scripts in Oxidizer, we can not escape the job of authoring the events of the sequence in some abbreviated form like this.
Having said all that, let's look at what the control scripts for the two examples above would look like:::c::<
end%%>>::c::>>seq9 file paths and control script
qfile = "cs1.lua" -- control script file name
dofile(mdir..'utils.lua')
dofile(mdir..'mods.lua')
infile = sdir..qfile -- full path to control script%%>>In order to test these scripts, you need to edit seq9 to set up the file paths and file names for the external packages and the input control script, as indicated on lines 22-28 in the box on the right.
.....
(need to rewrite the seq7 part....it's seq9 now)
>>seq9 file paths and control script
To see some simple examples of how a control script is written, let's redo Examples 1 and 2 above as control scripts. First the modulation channels definition table ##mdef## is set up for the parameters to be animated, with the appropriate function value modifiers, as described above. Each channel definition in ##mdef## must have a corresponding sequencing channel in the control points table ##cp## - if there is a mismatch between the ##mdef## and ##cp## channel setup, seq7 will complain. Each channel in ##cp## is a table of control points, and each control point is a table of time-value pairs, with optional curve and smoothing keywords. You can try the control scripts given below on a genome in Oxidizer: click the #%Grab#% button to save the code block; rename or relocate the file as necessary for seq7 to find it, or edit the path and file names in seq7; then run the seq7 script in Oxidizer.
- beat-syncing an animation to music
- "storyboard" sequences of many separate steps
- randomized looping modulations
- random walk morphing between genomes
There are many ways one could go about these things, and the scripts presented below are merely offered as examples of the types of methods that can be employed. One method of key frame authoring for an interpolating script will be the topic of the final section. This code has gradually grown out of a series of more specialized, non-interpolating animation sequencers that were designed to do just one specific thing, for instance Xform rotations. It may be of interest to the reader to also look at some of these earlier non-interpolating codes first, which is the topic of the next section.----
To introduce the terminology of the next section, we shall henceforth think of the genome parameters being actively modified by the script as "modulation channels," and the starting and stopping configurations as "control points" (essentially key frames, but with a more general role than in [[Animation Part I]]). The above script examples show how to easily script a frame sequencer for simple morphs and loops, where the modulation channels and control points are hard-coded into a FOR-loop. But if we want to have many more control points for a longer animation sequence, all of which might address //different// modulation channels and be of different lengths, etc. - then doing it this way will be just as much work as doing key frame authoring by hand in Oxidizer. We need a more efficient interface for authoring movie sequences without being troubled by all the details that goes on under the hood.----
One script that goes some way towards such a simplified interface goes by the unglamorous name [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=seq9.lua seq9.lua]]. This code is a parsing and interpolation engine that will do all the heavy lifting, while the movie director can focus on authoring "control scripts" for it. The technical details of this code is documented on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm seq7/seq9 home page]], which also contains several examples of animations produced with it.
It must be emphasized that while I offer these scripts as examples of tools that facilitate animation authoring, they are by no means trivial to use, and a modicum of manual scripting is still required. Those of you who have worked with audio or video sequencers like Logic or Final Cut will know what I am talking about: the timing, shaping, blending and cross-fading of events and segments - even with scripts in Oxidizer, we can not escape the job of authoring the events of the sequence in some abbreviated form like this.
Having said all that, let's look at what the control scripts for the two examples above would look like:::c::<
end%%>>::c::>>seq9 file paths and control script
qfile = "cs1.lua" -- control script file name
dofile(mdir..'utils.lua')
dofile(mdir..'mods.lua')
infile = sdir..qfile -- full path to control script%%>>In order to test these scripts, you need to edit seq9 to set up the file paths and file names for the external packages and the input control script, as indicated on lines 22-28 in the box on the right.
.....
(need to rewrite the seq7 part....it's seq9 now)
>>seq9 file paths and control script
To see some simple examples of how a control script is written, let's redo Examples 1 and 2 above as control scripts. First the modulation channels definition table ##mdef## is set up for the parameters to be animated, with the appropriate function value modifiers, as described above. Each channel definition in ##mdef## must have a corresponding sequencing channel in the control points table ##cp## - if there is a mismatch between the ##mdef## and ##cp## channel setup, seq7 will complain. Each channel in ##cp## is a table of control points, and each control point is a table of time-value pairs, with optional curve and smoothing keywords. You can try the control scripts given below on a genome in Oxidizer: click the #%Grab#% button to save the code block; rename or relocate the file as necessary for seq7 to find it, or edit the path and file names in seq7; then run the seq7 script in Oxidizer.
Deletions:
So in this section we will look at how to use scripts for animation sequencing. There are many ways one could go about this, and the scripts presented below are merely examples of the types of methods that can be employed. The more powerful method of key frame authoring for an interpolating script will require a bit of explaining. This code has gradually grown out of a series of more specialized, non-interpolating animation sequencers that were designed to do just one specific thing, for instance Xform rotations. It may be of interest to the reader to also look at some of these earlier non-interpolating codes first.----
To introduce the terminology of the next section, we shall henceforth think of the genome parameters being actively modified by the script as "modulation channels," and the starting and stopping configurations as "control points" (essentially key frames, but with a more general role than in [[Animation Part I]]). The above script examples show how to easily script a frame sequencer for simple morphs and loops, where the modulation channels and control points are hard-coded into a FOR-loop. But if we want to have many more control points for a longer animation sequence, all of which might address //different// modulation channels and be of different lengths, etc. - then doing it this way will be just as much work as doing key frame authoring by hand in Oxidizer We need a more efficient interface for authoring movie sequences without being troubled by all the details that goes on under the hood.----
One script which accomplishes this in a particular way goes by the unglamorous name of [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=seq7.lua seq7.lua]]. This is the parsing and interpolation engine that will do the heavy lifting in this section, while we focus on authoring "control scripts" for it. The technical details of this code is documented on the [[http://homepage.mac.com/rflicker/TNS/ff3/ani.htm seq7 home page]], which also contains several examples of animations produced with it (parts of this documentation will be borrowed into the current tutorial). Even more details are documented in the example control script [[http://www.rampant-mac.com/wiki/wikka.php?wakka=ScriptPage/files.xml&action=download&file=doq7.lua doq7.lua]].
>>seq7 file paths and control script
To see some simple examples of how a control script is written, let's redo Examples 1 and 2 above as control scripts. First the modulation channels definition table ##mdef## is set up for the parameters to be animated, with the appropriate function value modifiers, as described above. Each channel definition in ##mdef## must have a corresponding sequencing channel in the control points table ##cp## - if there is a mismatch between the ##mdef## and ##cp## channel setup, seq7 will complain. Each channel in ##cp## is a table of control points, and each control point is a table of time-value pairs, with optional curve and smoothing keywords. You can try the control scripts given below on a genome in Oxidizer: click the #%Grab#% button to save the code block; rename or relocate the file as necessary for seq7 to find it, or edit the path and file names in seq7; then run the seq7 script in Oxidizer.----::c::<
end%%>>::c::----
Revision [366]
Edited on 2009-03-30 21:14:41 by RalfFlickerAdditions:
""""====Part II. Sequencing with scripts====
__Disclaimer__: The scripts employed in this article only reflect the contemporary efforts of the author, and are in no way to be understood as definitive or the only way of doing things. The reader is positively encouraged to experiment and come up with their own preferred methods, and to write much better scripts than those presented below.
===Overview===
- you want to combine morphing with other types of modulations
Obviously, if you want the morphing to be done in a //specific// way, you have no way of telling flam3 to do this, so we must instead calculate every time step of each genome morph ourselves. Also, if you have been doing everything manually so far, inserting key frames and adjusting parameters etc - at some point in the growing length of the sequence this procedure simply becomes too cumbersome and tedious to carry out by hand. As argued in the script tutorial, this kind of work is suitable for doing with a script, for efficiency and repeatability (at least for the time being; the day Oxidizer implements an Animation Sequencer GUI all this will become obsolete).
So in this section we will look at how to use scripts for animation sequencing. There are many ways one could go about this, and the scripts presented below are merely examples of the types of methods that can be employed. The more powerful method of key frame authoring for an interpolating script will require a bit of explaining. This code has gradually grown out of a series of more specialized, non-interpolating animation sequencers that were designed to do just one specific thing, for instance Xform rotations. It may be of interest to the reader to also look at some of these earlier non-interpolating codes first.----
===Non-interpolating sequencing===
For specific tasks of a limited scope, we may be able to formulate a simple algorithmic description of the motion, for instance: "rotate by 360 degrees over 60 frames," or "modulate the variation weight by a cosine over 100 frames." For such modest sequences, it is a simple matter write a script that generates a sequence of genomes tracing out the motion. Two examples are given below, that apply various modulations to the first genome in the Oxidizer main list (to remind yourself of the Oxidizer Lua implementation, see the [[LuaScript script tutorial]]). The first example simply zooms by a factor of two (from -1 to +1) and rotates the image by 200 degrees. This could have been done faster by a simple morph directly in Oxidizer, but just for illustrating the principle. The second example uses the same principle but calculates a full Xform (looping over all xforms) and color map rotation by calling the functions ''affine_Prot'' and ''cmap_rot''. This sequence will loop around when animated.::c::<
oxidizer_status["action"] = "replace"%%<<>>Example 2: Xform and color rotations
oxidizer_status["action"] = "replace"%%>>::c::The general structure is clear: first load required packages, define numerical values, then loop over the number of frames and apply the genome parameter adjustments. The starting genome is copied by value for each new frame (by the ''clone_genome'' function), the copy is then modified in-place and inserted into a new table, which is passed back into the global genome table ''oxidizer_genomes'' by reference at the end of the script. Most of the details of these codes should be familiar from the script tutorial. Remember to change the ''luadir'' variable on line 1 to the full path to the folder where you put the mods.lua and utils.lua files.
The arguments of the affine_Prot function on line 14 in example 2 has a special structure that will be important later on. The second element of the second argument ##{x,"v"}## is a modulation mode selector, which tells the function how to apply the numeric value given in the third argument to the function. This argument takes three different values:
These modes offer a wide range of possibilities for different types of parameter modulations, and all the Xform related functions in the mods.lua package have this structure (the morphing function ''morph'' and the color adjustment functions, e.g., cmap_rot and ''cmod_hsl'', work differently). We could also sequence a genome morph between different genomes in this type of script, by using a Lua morphing function, although we pay the price of not being able to leverage all the finesse and special tricks that are coded into flam3, and which can not be reproduced on the scripting level. Consequently, the Lua morph function (in the utils package) only interpolates the continuous genome parameters, and currently does nothing for the discrete parameters like genome symmetry and final xform. But if you have no jumps in the discrete parameters, the benefit of using the Lua morph function instead of letting flam3 do the genome interpolation is that you can now add other parameter modulations on the scripting level, simultaneously with the genome morph. We will see some examples of this in the next section.
To introduce the terminology of the next section, we shall henceforth think of the genome parameters being actively modified by the script as "modulation channels," and the starting and stopping configurations as "control points" (essentially key frames, but with a more general role than in [[Animation Part I]]). The above script examples show how to easily script a frame sequencer for simple morphs and loops, where the modulation channels and control points are hard-coded into a FOR-loop. But if we want to have many more control points for a longer animation sequence, all of which might address //different// modulation channels and be of different lengths, etc. - then doing it this way will be just as much work as doing key frame authoring by hand in Oxidizer We need a more efficient interface for authoring movie sequences without being troubled by all the details that goes on under the hood.----
__Disclaimer__: The scripts employed in this article only reflect the contemporary efforts of the author, and are in no way to be understood as definitive or the only way of doing things. The reader is positively encouraged to experiment and come up with their own preferred methods, and to write much better scripts than those presented below.
===Overview===
- you want to combine morphing with other types of modulations
Obviously, if you want the morphing to be done in a //specific// way, you have no way of telling flam3 to do this, so we must instead calculate every time step of each genome morph ourselves. Also, if you have been doing everything manually so far, inserting key frames and adjusting parameters etc - at some point in the growing length of the sequence this procedure simply becomes too cumbersome and tedious to carry out by hand. As argued in the script tutorial, this kind of work is suitable for doing with a script, for efficiency and repeatability (at least for the time being; the day Oxidizer implements an Animation Sequencer GUI all this will become obsolete).
So in this section we will look at how to use scripts for animation sequencing. There are many ways one could go about this, and the scripts presented below are merely examples of the types of methods that can be employed. The more powerful method of key frame authoring for an interpolating script will require a bit of explaining. This code has gradually grown out of a series of more specialized, non-interpolating animation sequencers that were designed to do just one specific thing, for instance Xform rotations. It may be of interest to the reader to also look at some of these earlier non-interpolating codes first.----
===Non-interpolating sequencing===
For specific tasks of a limited scope, we may be able to formulate a simple algorithmic description of the motion, for instance: "rotate by 360 degrees over 60 frames," or "modulate the variation weight by a cosine over 100 frames." For such modest sequences, it is a simple matter write a script that generates a sequence of genomes tracing out the motion. Two examples are given below, that apply various modulations to the first genome in the Oxidizer main list (to remind yourself of the Oxidizer Lua implementation, see the [[LuaScript script tutorial]]). The first example simply zooms by a factor of two (from -1 to +1) and rotates the image by 200 degrees. This could have been done faster by a simple morph directly in Oxidizer, but just for illustrating the principle. The second example uses the same principle but calculates a full Xform (looping over all xforms) and color map rotation by calling the functions ''affine_Prot'' and ''cmap_rot''. This sequence will loop around when animated.::c::<
oxidizer_status["action"] = "replace"%%<<>>Example 2: Xform and color rotations
oxidizer_status["action"] = "replace"%%>>::c::The general structure is clear: first load required packages, define numerical values, then loop over the number of frames and apply the genome parameter adjustments. The starting genome is copied by value for each new frame (by the ''clone_genome'' function), the copy is then modified in-place and inserted into a new table, which is passed back into the global genome table ''oxidizer_genomes'' by reference at the end of the script. Most of the details of these codes should be familiar from the script tutorial. Remember to change the ''luadir'' variable on line 1 to the full path to the folder where you put the mods.lua and utils.lua files.
The arguments of the affine_Prot function on line 14 in example 2 has a special structure that will be important later on. The second element of the second argument ##{x,"v"}## is a modulation mode selector, which tells the function how to apply the numeric value given in the third argument to the function. This argument takes three different values:
These modes offer a wide range of possibilities for different types of parameter modulations, and all the Xform related functions in the mods.lua package have this structure (the morphing function ''morph'' and the color adjustment functions, e.g., cmap_rot and ''cmod_hsl'', work differently). We could also sequence a genome morph between different genomes in this type of script, by using a Lua morphing function, although we pay the price of not being able to leverage all the finesse and special tricks that are coded into flam3, and which can not be reproduced on the scripting level. Consequently, the Lua morph function (in the utils package) only interpolates the continuous genome parameters, and currently does nothing for the discrete parameters like genome symmetry and final xform. But if you have no jumps in the discrete parameters, the benefit of using the Lua morph function instead of letting flam3 do the genome interpolation is that you can now add other parameter modulations on the scripting level, simultaneously with the genome morph. We will see some examples of this in the next section.
To introduce the terminology of the next section, we shall henceforth think of the genome parameters being actively modified by the script as "modulation channels," and the starting and stopping configurations as "control points" (essentially key frames, but with a more general role than in [[Animation Part I]]). The above script examples show how to easily script a frame sequencer for simple morphs and loops, where the modulation channels and control points are hard-coded into a FOR-loop. But if we want to have many more control points for a longer animation sequence, all of which might address //different// modulation channels and be of different lengths, etc. - then doing it this way will be just as much work as doing key frame authoring by hand in Oxidizer We need a more efficient interface for authoring movie sequences without being troubled by all the details that goes on under the hood.----
Deletions:
This is Part II of a two-part tutorial on animating fractal flames with Oxidizer.
===Table of contents===
~-""Non-interpolating sequencer""
~-""Interpolating sequencer""
----
===Sequencing overview===
- you want to combine morphing with other modulations
These points are fairly obvious: to force flam3 to follow a certain path it can not be allowed to do its own interpolation, but we must calculate every time step of each genome ourselves. If you're doing everything manually, inserting key frames and adjusting parameters, at some point in the growing length of the sequence this procedure simply becomes too cumbersome and tedious to carry out by hand. As argued in the script tutorial, this kind of work is suitable for doing with a script, for efficiency and repeatability (at least for the time being; the day Oxidizer implements an Animation Sequencer GUI all this will become obsolete).
So in this section we will look at how to use scripts for animation sequencing. There are many ways one could go about this, and the reader is encouraged to experiment and come up with their own preferred method. What I am going to present at length is a generalized scripting interface for (reasonably) efficient key frame authoring, which will require a bit of explaining. This code has grown out of a series of earlier and more specialized animation sequencers that were restricted to doing only one specific thing, for instance Xform rotations. It may be of interest to the reader to also look at some of these earlier non-interpolating codes first.
""""===Non-interpolating sequencer===
A sequencer of this kind generates a genome sequence from an algorithmic description of the motion (for instance "rotate by 360 degrees over 60 frames" or "modulate by a cosine over 100 frames"). This type of sequencing bypasses the use of key frames and interpolation, because it is given an exact instruction for how to calculate every frame of the sequence. Two examples are given below, where the first simply zooms by a factor of two (from -1 to +1) and rotates the image by 200 degrees (to remind yourself of the Oxidizer Lua implementation, see the [[LuaScript script tutorial]]). This could have been done much faster by a simple morph directly in Oxidizer, but just for illustrating the principle. The second example uses the same principle but calculates a full Xform and color map rotation by calling the functions ''affine_Prot'' and ''cmap_rot'' instead. This sequence will loop around when animated.----::c::<
oxidizer_status["action"] = "replace"%%>>::c::----
Most of the details of these codes should be familiar from the script tutorial, aside from the ''affine_Prot'' and ''cmap_rot'' functions from the mods.util package. Remember to change the ''luadir'' variable on line 1 to the full path to the folder where you put the mods.lua and utils.lua files. One detail that will be important later on is the second argument to the ''affine_Prot'' function on line 14 in example 2, which reads ##{x,"v"}##. The second element of this table is a mode selector, which tells the function how to apply the numeric value given in the third argument to the function. This argument can take three different values:
These modes offer a wide range of possibilities for different types of parameter modulations, and all the functions in the mods.lua package (except cmap_rot) have this structure.
These examples show how to generate frames for a single morph sequence between two control points, where the sequence lengths, parameter values and "modulation channels" were all hard-coded into a FOR-loop. But if we want to do this for many different morph sections of a longer sequence, which may all have different lengths, values and channels, then doing it this way will be just as much work as doing key frame morphing by hand! We need a more efficient interface for authoring the movie sequence without being troubled with all the calculations and looping that goes on under the hood.----
