TWEENER v1.3 [release version] 21Mar01 FREEWARE by Peter Shafer, Copyright 2001. Bug reports to: dearmad@applesnake.net Tweener's home: www.applesnake.net TECHNICAL AND OTHER STUFF: For: POLYRAY raytracer and Moray v2.02 & v2.5 DOS. Recommend: DTA (Dave's Targa Animator) for putting together your animations; the MORAY modeler program for making keyframes already formatted exactly as Tweener expects them. You can find DTA at Tweener's homesite. Or Bink from www.radgametools.com which does a *very* good job of color reduction and an *amazing* job of sound compression so you can add full stereo sound to your animations! Need: 80286 or better, DOS v3.3+, 640k minimum. (Runs fine in win3.1 and win95 from my limited testing in those OS's.) Legal: In the general spirit of Raytracers and those of us who love them, Tweener is FREEWARE and can be given away, copied, and distributed for free as much as you want, as long as it is NEVER distributed for any profit or any fee whatsoever either privately or commercially either alone or as part of any compilation! Comes with: TWEENER.EXE: the executable TWEENER.DOC: this document TTITLE.TLE: A small title-screen graphic that Tweener needs. INTRODUCTION Tweener is named for what it does: the "In-Between" frames of your animation. Think of it as a simple-minded assistant animator who Disney, Pixar, Rhythm & Hues, and PDI all have passed over when recruiting for their latest feature-length animation. So ok, Tweener ain't talented, and it ain't no Preston Blair, but it tries hard, and actually can help. Tweener is designed to work with POLYRAY. And while not strictly needed, MORAY v2.02 or v2.5 can really help a lot with making your key-frames. Tweener needs a POLYRAY script file (.PI) formatted in a particular way, which happens to be the way MORAY writes them. If you still want to hand-script, you can, if you follow a few simple rules of syntax. When you're controlling a lot of objects (say over 20) or a very complex one (CSG's), Tweener can simplify the process, or muck it up for WEEKS as it has done for me sometimes while programming it! You merely create your keyframes in MORAY and export them as .PI files (Polyray format). Tweener can handle any amount of keyframes from 2 up to 30 with a corrosponding amount of objects found by: 7000/keyframes. So up to 3500 primitives can be in a scene if you run Tweener at 2 keyframes. At 30 keyframes you the limit is 233 objects. You can actually have more, like THOUSANDS of objects: see how to later in this document. You can control object motion, light fades, camera position, focal distance, aperture, spotlight fall-offs, 9 spline paths, and motion styles, and probably more... I forget it all. Note that "keyframes" does NOT refer to a limit on how many frames can be in your animation. Keyframes are the positions you set, how many frames are between these positions is entirely up to you. Also, for longer animations you will string together many shorter "takes" to make the entire film. USAGE Starting Tweener: "Tweener [keyframe1] [keyframe2]... [keyframe7] [ENTER]" This will run Tweener and load your keyframes in the order listed. Be SURE to leave OUT the file extension; Tweener will automatically append ".PI" to your names. So "Tweener exa1 exa2" would load EXA1.PI and EXA2.PI as your keyframes. You must enter at least two frames, but need not use all 7, and can use keyframes in multiple spots, such as: "Tweener exa1 exa2 exa1" to return things to the start keyframe. Options: If you type "*" followed by a number from 2 to 30 this will set up the optional keyframe/object relationship before loading your keyframes. For example, if you type "Tweener *3 exa1 exa2 exa3" you will set up Tweener's memory use to allow 3 keyframes and 7000/3=2333 maximum objects. If you type nothing for this option Tweener will default to "*7" and allow 1000 objects. Working with Tweener: Once Tweener loads and parses all the necessary data from your .PI files you'll be presented with a screen filled with numbers. Don't be overwhelmed; it's all pretty easy, most of your hard work is behind you when you made dramatic, accurate, and compelling keyframes in MORAY or by hand scripting your POLYRAY files. The MAIN SCREEN: The green writing at the top of the screen describes what is in each column: Object: The name you gave the object in MORAY. If you want to give an object a name while scripting by hand you will need to place it after "//" on the same line as the object is declared: "object { //[objectnamehere]" or defined: "define [csgname] //[yourassigned name here]" A maximum of 13 characters can be displayed here, so keep your name lengths under that. Scale: The scaling factors applied. For lights this is actually the color/intensity, and for cameras this is actually its position (From). Rotate: The rotation (in degrees) applied to the object. For Cameras this is the "At" part, where it points to, and for Lights it is the position. Xslate: The translations applied to the object. For spotlights, this is where it's pointed at. [Offscreen]: Some objects (Spotlights, and the Camera notably) have a fourth set of data applied to them which is not displayed but IS manipulable with Tweener. For *spotlights*, the data applies to their fall-off and radius, for *cameras* it is the angle of view. While these ARE kept track of and CAN be motion-styled (speed/slow, etc), they are not displayed on the screen. Each line lists the data applying to the object beginning at keyframe #1, with the data to more keyframes listed in sequence below that object's name header. CSG objects' header items are highlighted by brighter printing; their components are listed below them dimmed. Note that the objects in a CSG's list may NOT be ALL of the objects contained therein in the actual .PI script. This is because Tweener parses your script file in order, and sometimes you include previously defined objects within newly defined ones. Instead, the "missing" object will be listed in the first place they occurred in the actual script. Don't worry, every object is here, somewhere, on the screen. I hope. The camera (viewpoint) is always listed in a shade of purple, bright purple when it has changes in it's transformations between keyframes. All lights are in gold, brighter when the values of their transformations change between keyframes. All objects are displayed in gray when they do not change, brighter when they head a CSG group. Objects are red when there are changes to their transformations between any keyframes. Bright when they head a CSG group, dimmer when they are not a CSG head. Controls are listed at the bottom of the screen in blue. In the bottom right are two letters "K:" and "O:" followed by numbers. This just displays the memory set up to allow for Keyframes and Objects. Navigation: You can navigate this screen by using the up and down arrow keys to move one object up or down. Also, PgUp and PgDown jump a screen at a time, while HOME goes to the top and END goes to the bottom. Frame Control [F1]: When you access this, Tweener will switch screens, and the controls should then be pretty obvious: When initially run, Tweener assumes a frame rate of 24 fps and that your animation will be as many frames long as there are keyframes, resulting in an animation of however many seconds duration this calculates out to be.. You can, of course, change this rate; indeed you will most likely want to. Just enter the number of the item you wish to change and then enter a new amount. Jiffies (only when entered directly) and total frames MUST be whole numbers, of course. Note that when the amount of your keyframe files are NOT evenly divisible into your total frames (as calculated or entered), your total frames can be rounded to a suitable number. For example, if you have 3 keyframes and you entered 6 for your desired total frames, it would get changed to 5, so that your keyframes fall evenly on frames 1, 3, and 5. Also, you can unevenly divide your keyframes between your total frames. The first keyframe always begins at frame 1 and the last falls on the last frame of your animation. If the division is listed on this screen as a 0 for each of your keyframes, then the animation is evenly distributed. Otherwise, the numbers listed here tell which frame that keyframe will begin on. I have tried to build into Tweener all the checksafes it needs to monitor illegal keyframe divisions and to correct these for you, however, you will want to double check your frame division before you output your animation. The Frame controls in Tweener are most important in deciding your total number of frames, as that then gets written into your animation file automatically. The FPS and Jiffies are for you to set when you use DTA (or some other image to animation program you may have access to), and the total length of the animation displayed is for your reference and timing purposes only. Object Controls [F2]: I don't expect you'll need to modify every object you have in your keyframes through these tools, but sometimes there are some handy things you can do here and you may spend quite a bit of time in this screen. On the left are a few control instructions. You can hit [F1] to instantly convert EVERY movement style except those objects moving along splines into SISO. [F2] will knock everything back to the Smooth type. This can speed up a lot of hand-tweaking of character animations. On the right is a list which you can scroll by using the up and down arrow keys, the PgUp and PgDown keys (to jump quicker), and the RIGHT arrow key (to enter a specific object # to jump to). The object currently selected is highlighted in blue. Just hit [enter] when you are highlighting the object you wish to edit. Hitting [ESC] takes you back to the main screen. Once you've selected an object for detailing, you will be presented with another screen. At the top are the object's attributes, along with it's movement TYPE and movement STYLE for EACH attribute and EACH keyframe. Movement STYLE is the way in which the object moves from that keyframe to the next. The styles possible are: Smooth, Speed, Slow, and SISO. SMOOTH is the default and may be the way you think computer animation always works, with even interpolation between your two points. This is a pretty common method, but can look unrealistic. SPEED is an accelerating movement, starting slower and ending faster. SLOW is just the opposite, it starts out fast and slows as it goes. When you use either Speed or Slow, you will be prompted for the "power". This is the power factor (as in y^x) your object is changed at over time. higher numbers have more noticeable effects. Any number is applicable, just think about what you will be doing: Speed = time^x and Slow = time^(1/x). ^2 is usually too much, try 1.5, but experiment. SISO is probably the one you will use the most when you're animating a character. SISO stands for "Slow In Slow Out." Basically it starts slowly, accelerates, and then decelerates it to the next keyframed position. SISO is most handy and accurate in this version of Tweener when used between only two keyframes, otherwise you will get a jumpy look as the object slows down and then accelerates over more than one keyframe. Experiment, you'll see what I mean. Eventually I hope to interpolate over multiple keyframes better with a future version. To summarize, in the Object Control screen you select what you want to modify and at which keyframe you want to modify it. Note that for your last keyframe, you can modify ONLY the transformation data. For your other keyframes you can modify everything. When entering components to transformation data, separate the items by commas (example: "2,3.45,-4.01"). THE SPLINE OBJECT Tweener supports up to 9 independent spline paths with up to 10 points each. You make them for Tweener in MORAY by using an object (any kind) which you name "#spline##". The first (#) refers to the number of your spline and the second (##) refers to the point in the spline this object represents. So the first point of your #1 spline would be: "1spline1" and the second point in it would be "1spline2". If you have more than one spline path you will have "2spline1"... "2spline2", etc... Just place your spline objects at their control points in your keyframes. When I'm using MORAY, I like to use spheres for this, scaled to be very small so they don't interfere with my wireframe modelling. Be SURE you don't skip over a point, as Tweener will then interpret that control point to be at <0,0,0>. NOTE: If you create a spline with less than 3 points, you will run into animation errors when asking for the object to face into the spline, and I don't what would happen if you have only one point. There is no reason to have a spline of 2 or less points, just move your object linearly between the two extremes. When the final .PI animation files are completed by Tweener, your spline objects will NOT be in your scene, instead, their positions will be made into the control points of your spline paths. By default the movement interpolation from point to point is divided evenly between your keyframes. In order to change this, you may have your object's "translation" be Speed or Slow via the Object Controls, then for that keyframe to the next it will follow that movement style. A SISO (Slow-in Slow-out) movement is not allowed for spline objects (yet) and Tweener will not allow you to enter that sort of movement style. FACING INTO A SPLINE When you have an object following a spline path it will normally not change it's initial angles. But when you link an object to a spline path in Tweener, Tweener will ask if you want it to "Face" with the spline or some "Other" angle. If you chose the "Other" option then your angle changes will be independent of the spline, otherwise it will change with the spline. In order for your object to face perfectly into the spline along it's travel path, make sure when you create it in your scene file that it parallels the Y axis so that it's direction of travel would be toward the NEGATIVE. That means if you increment it's Y position (translate) by a negative number it would be heading forward into the direction of its travel. This also means that when your OBJECT is rotated at <0,0,0> it is facing this way. This means that you may need to create a CSG for your object at the origin and join your rotated object to it and move it in the animation by means of the CSG so that even though when you created the object and had to rotate it (<0,-90,0> for example) to get it to face -y, the CSG object will be rotated <0,0,0>. I hope this makes sense! Also, if your object is the main camera it should present the option to "Watch" a spline, this means the "At" of the camera will face the spline path without changing any other motion of the camera. PARTICLE GENERATOR OBJECT You may add a particle generator much the same way you include a spline, by creating a simple object (a sphere for example) and naming it #"particles". The # is 1-9, as you can have up to 9 particle generators in the scene. For now there are no controls of the particle generators (PG) built into Tweener that you can take advantage of. All they are for now is a way to accurately position a non-moving PG. A simple 50 sphere bursting generator will be written into your .PI animation file, but you will need to hand tweak the settings you need for you animation. I will mess around with adding features to this but don't expect anything very rapidly as I'm back in school until summer. FOCUS OBJECT This is used much like any of the above special objects, however it has some special properties. The object must be named "focus". There are no numbers before or after it as you only ever have one. The scale of its x component defines the camera aperture. Since Moray does not allow scaling to 0 (perfect focus aperture) 0.01 is defined as this and the actual aperture you will get in Polyray is 10x this number, so the formula would be: (x-0.01)*10. Thus 0.01=0 and 0.06 would give you 0.6 aperture (pretty blurry). The x translational component defines the focal distance. If you leave this at 0 and do not move it then the focal distance will use the Polyray default of whatever your camera "At" distance calculates out to. However, if you increase the translational component along the x axis then this will be used as your distance. Never cross to or below 0 or you will get bad results. None of the other components to this object matter. Keep in mind, however, you can change its movement style. Hooking it up to a spline is not recommended and will yield bad results. BEZIER PATCHES There is currently no support for Bezier patches interpolating smoothly between your keyframes. Instead they will instantly change when a new keyframe is begun. NUMERICAL ACCURACY Numbers are internally accurate to the 5th decimal point, but only displayed to the 2nd (1st for angles). Also they can range up and down to any 16 digit number or e^208 with 6 accurate digits. However, only 3 digits on both sides of the decimal point will be displayed (including any negative symbol). This is a little confusing, but in general don't worry about numerical accuracy, it IS there, however, I make it a practice to use digits only to the 3rd place in my own animations anyway. NOTES ABOUT THE FORMAT Tweener EXPECTS If you do not own MORAY and still want to use Tweener, you can. However, your scripted file must be formatted in a particular way for it to be accurately parsed. If you DO have and use MORAY to make your keyframes, you can practically skip this section, unless you plan to do any script editing by hand at a later time. I HIGHLY recommend using MORAY for your keyframing. I designed Tweener based upon how MORAY exports .PI files. Either way, you will probably want to read the special object "spline" section which is covered below. Viewpoint (The Camera): The key items in your viewpoint MUST be listed together beginning with the "from" line. All the other details you can have through POLYRAY are not yet supported by Tweener: define viewpoint { from at up angle ## } Lights: Lights are simple. Just follow your standard format, BUT, use separate lines for each vector. With Spotlights, use a separate line for the last sequence of numbers: light //namehere , , //spotlights may have the following: #, ##, ### CSG and grouped Objects: You begin your definition normally, but separate the "object {" on the next line. Also, NEVER define an object within another definition, it sometimes works, but sometimes not. See the bug list below for a workaround. define csgthing //namehere object { //namehere sphere <0,0,0>,1 texture scale <1,1,1> rotate <1,1,1> } + object { //namehere sphere <0,0,0> , .5 texture scale <.5,.5,.5> translate <1,0,0> } } Declared objects: Objects which are described in their actual appearance, and not aliased through a definition have no special rules. object { //NAMEHERE sphere <0,0,0>, 1 texture translate <10,-3.04,2> } or object { //NAMEHERE object { //NAMEHERE sphere <0,0,0>,1 texture transforms <-,-,-> } + object { //NAMEHERE sphere <0,0,0>, 1 texture transforms <-,-,-> } } WHAT Tweener DOESN'T DO: (Known bugs, missing features, to-do list) Tweener should be able to really help you with animating things in POLYRAY, but there are a few things it won't do. Some of them by design, and others because I yet lack the time to program the feature. Bugs are listed "B:", features missing which I might NOT add for a LONG time (if at all) "*:", features missing which I hope to add sometime soon as "+:". B: This "Bug" isn't Tweener's fault- it's MORAY's. When *grouping* objects and not CSG'ing them, Moray sometimes ungroups them when it exports to a .PI file. Easy workaround: Don't EVER use groups, go ahead and CSG everything. +: Better interpolation between multiple keyframes for Speed, Slow and SISO. It's ok now for two keyframe animations, though, or if you do some post-Tweener hand-tweaking. *: Will not handle textures defined within the .PI file very well. I have not built in texture animation, and am not sure that I will as it is sufficiently complex enough to warrant a lot of hand-tweaking when I use it in my own animations anyway. And there is no easy way to transform textures over a series of keyframes in MORAY anyway. Workaround: define all your textures in an included .INC file with the same name as your .PI file. Example: "frame1.pi" and "frame2.pi" has all objects keyframed and "frame.inc" has all textures defined that are used in the keyframe files. This will ensure that they do not get screwed up by the parser. *: No support for sweeps doing cool morphs between frames. I'm not sure if I'll be adding this anytime soon unless there's a clamor for it. For now they act as regular objects... Also, no support for Bezier patches smoothly morphing between keyframes. B: There is hardly any specific support for nested defined objects in your script file. It may work, but I've only tested this a little and not on really complex models, so best not to do it! While Tweener can easily get the data for them, it has trouble outputting them accurately to the animation file. Workaround: Don't do it. Define your CSG's separately and then include them as so: define shape1 object { sphere <0,0,0>,1 ... } } define csgshape object { box <0,0,0>,<1,1,1> ... } + object { shape1 ... } } This is clearer syntax anyway and easier to manipulate later by hand scripting should you be so inclined. B: This next one can be a BIG PROBLEM if you're not careful when you make your models: For now 'Tweener cannot deal with defined objects that include objects with transformations that do not explicitly declare themselves as objects. This means you MAY have to clean up MORAY'S output a bit or just avoid using MORAY'S COPY command WHILE using it's automatic transformations and referenced objects. Lutz left lots of bugs int hat area of his code. Basically what you need to do is go ahead and use the COPY command, but position the copies in place yourself. An example of the syntax in the .PI file is: NOT THIS WAY: (used automatic MORAY translation in COPY) define shape1 object { sphere <0,0,0>,1 ... } } define csgshape object { box <0,0,0>,<1,1,1> ... } + shape1 { translate <10,0,5> } + shape1 { translate <5,0,5> rotate <180,0,0> ... //Etc... } ... } YES, LIKE THIS: (COPIED in MORAY but without automatic changes, then positioned by moving object myself) define shape1 object { sphere <0,0,0>,1 ... } } define csgshape object { box <0,0,0>,<1,1,1> ... } + object { //THIS IS WHAT'S ADDED shape1 translate <10,0,5> } + object { //THIS IS THE EXPLICIT DECLARATION shape1 translate <5,0,5> rotate <180,0,0> } ... } FINAL NOTES AND TIPS ON USAGE: 1: OBJECT LIMITS: While 'Tweener supports 850 objects in 7 keyframes at a time, this is by no means your true limit. Your true limit on objects is how many objects are declared in your .PI file. Sneaky users who want to move thousands of objects (say an asteroid field or something) all in basically the same direction can use MORAY's UDO object creator and (for example my SNOW or TREEFORM program)to create *1* object containing thousands. Moray exports this object in a .IN# file which is then "included" in the .PI file and referenced from within there as *one* object. 2: KEYFRAME LIMITS: Don't think of this as the limit to your entire animation- it's not. A keyframe set is more closely akin to a "shot" in your animation. When you camera will "cut to" something else, that's a good indicator of where a new keyframe set should begin. I've created animations over 2 minutes in length comprised of hundreds of shots and never gone beyond using 7 keyframes or anything. 3: CONSISTENCY OF .PI FILES: THIS IS IMPORTANT. Your keyframe set must be absolutely consistent from one to the other when loaded into Tweener all at once. This means you should NOT add any objects, delete them, or redefine them under the same name in MORAY or by handscripting. If you want something to disappear, scale it to <0,0,0>. If you want something to be added, start a new keyframe set. If you don't, you'll get very bizarre results. 4: WHAT USED TO BE CALLED FAR ANGLES: I dropped "Far" angle support completey as Moray can handle this if you type in your transformations. For example if you have an object that you want to do a 360 degree turn, simply export one keyframe then a second having input "360" as the rotation. While it will appear in the same spot, Moray (for once) exports this accurately not as 0 but 360. VERSION HISTORY OF PUBLICLY AVAILABLE COMPILES: This section is for my own reference, ignore it if you like. I tinker with 'Tweener a lot so it goes through a lot of versions, forgive me. :o) 3/21/01 (v1.3) Finally killed the display colors bug when detecting changes and tightened code. Added aperture and focal point distance controls using a "focus" object, added startup option to let user define max keyframes/objects on startup. Fixed no_shadow problem with lights. 1/12/01 (v1.2) Added basic particle generator support, and decided to increment the number now that 1.1c (the beta) is done producing the short "Fireflies" for me and seems very stable. 1/05/01 (v1.1c) Fixed: upside down bug when facing into spline; write bug didn't copy tagged INCLUDE lines to final .PI; spline facing bug when more than 2 keyframes used-tightened code nicely; flags back to "h" when a path is taken off a spline and made linear; bug from Moray that failed to tag UDO objects with "_Ref"- deleted the "_Ref"; unresolved (-1/128) expression bug noticed in heightfields; resolved expression (.0078) for example- works with "/" or "*"; bug related to fix in v1.1b this time with lines tagged at the end that should *not* be written twice to the animation file. Added: New title graphic (smaller); inside access to help screen; function to mass change transitions to SS and SM styles; checks to make sure Spline paths are never SS style. 12/25/00 (v1.1b) Added spline facing option! Fixed *extremely* rare bug with objects named with the keywords: "scale," "rotate," or, "translate." These words can now be included in object names like: "scaler," or "translate_block," etc... 12/18/00 (v1.1a) The date is misleading here as this version is old but wasn't released for awhile. Changed the memory allocation to allow 850 objects in 7 keyframes as this is a lot handier than 10 keyframes and 600 objects. Completely dropped 'Tweener formatted data overlay saving- it simply did NOT work and I could work around not having it, however, I am working on this idea. 3/3/99 (v1.1) Added support for Moray v2.5 formatted polyray scripts- camera parsing and export. Cleaned up uneven keyframing- made it clearer (I hope). Finalized fix for bug related to the 2x tagged lines- some tags were far apart but on the same line. Updated setup. Added support for still output to particular directories. Added TIPS section to manual- details the particularites of use. Removed "FAR" angle- better data display. MORAY can do this for you just type in your rotation angle. 2/24/99 (v1.0d) Grrr. Odd bug in exported data. Some lines got tagged twice but it only ever read the first tag in export and would thus double export a single linked data set... why didn't I encounter this before? Fixed with an unmentionable variable name as a flag and by adding 10 lines of spaghetti code! Also reworded error text to more accurately reflect possible crash reasons. 2/15/99 (v1.0c) Fixed another detail to the FOV bug of v1.0a! Pisses me off because I thought it was FIXED but poor math skills lead to poor fixes... Also cleaned up very minor informational text errors and reworded a few things in compiled .PI file comments. 7/26/97 (v1.0b) Not sure what I did here as some code was done long ago. Cleaned up a few text problems and such. Also updated the MANUAL listing a newly discovered bug involving the COPY command in MORAY and unexplicitely declared objects. ALL objects must be declared. 7/16/97 (v1.0a) In creating an animated short, I found a rarely occurring camera FOV bug which would throw off smooth transitions between "takes" if you were changing the camera FOV. Fixed by adding the aspect multiplier to both ends of the FOV equation in the camera define. Noticed that loading Tweener-formatted data overlays eats up memory... not crashing at this time, so I'll fix it later, maybe. 6/19/97 (v1.0) At last I think all the killer bugs are gone. Fixed error with dropping objects on tagged lines (I think). Placed on website. 5/30/97 (v0.9b) (Not released) Whoa, major internal changes! Added SISO motion style, uneven division of keyframes, cosmetic changes, and lots of internal code re- writing. Bug Fixes: Rewrote animation output completely and had to edit a lot of the Parsing code as a result, so that control points could be passed accurately. Resulted in about 10k of code being removed, which is cool and more efficient! 5/26/97 (v0.9) The Beta version. Included Tweener.ini setup utility for finding various files easier. Dropped max objects from 650 to 600. Added Tweener-formatted data saving and loading so after you've heavily tweaked a set of keyframes, you can save what you did and reload it to tweak some more if the animation flops when you render it. Dropped need to enter file extensions. Bug Fixes: Fixed display routine to display all data all the time, fixed texture dropping when no transforms followed (I think it's fixed, that is). 5/18/97 (v0.8b) Another Alpha version. Many, many features added: added motion styles, splines, support for spotlights and camera angles, changed memory set-up to 10 keyframes with 650 objects (may change this yet), modified interface to make navigation easier, added opening screen. Bug fixes: Major rewrite of parsing routine! It's MUCH better now! Fixed bad openfile tags so now more than 5 keyframes can be used (up to 10 max). 5/9/97 (v0.8a) Fixed an atrocious bug in parsing files related to nested declared objects. Posted to website. 5/8/97 (v0.8) First public availability. Alpha version. Lacks splines, motion type/style, and many other features. Beta to follow shortly!