-
I'm frequently asked for tips on optimizing LiveMotion compositions, so I decided to put together info on a whole series of topics and post it here. The messages below should give you some ideas on how and why LM does certain things, and how you can best take advantage of its approach to building SWFs. This list isn't exhausitve (and hopefully not exhausting) by any means, so please feel free to ask questions or add your own optimization tips.
Thanks,
JNack
[Edited by JNack on 05-31-2001 at 06:10 PM]
-
Flash-native vs. non-Flash-native transformation
First off, it's important to realize that LM allows you to animate many more characteristics than the Flash player can handle natively. LM separates the top five native Flash characteristics under the Transform twistie for each object on the timeline. I'll go more into depth about what happens when you animate other characteristics, and I'll point out ways to make even the native Flash transforms export more efficiently.
-
Frame rate, attributes, and size
Be aware of the relationship between frame rate, animated attributes, and file size. The SWF format doesn't really care how you've assigned keyframes and tweens in your editing tool; when you export SWF, it stores all the changing values for an object on every frame on which they're changing. Each bit of data is quite lightweight (very roughly 6 bytes per frame for each changing attribute), but they can add up, especially at higher frame rates.
To illustrate the relationship, start with an object that's changing position over the course of 1 second in a movie set to 10 frames per second (fps). The tweening would require only 60 bytes or so--pretty efficient. But change the frame rate to 30fps and re-export. You'll see that the animation is smoother, but the tweening information is now three times heavier. Now trying fading the object over the same period of time. The tweening information doubles in size again. At this point your SWF still is fairly lightweight, but consider the file size required when you create an animation style that varies five attributes over 10 seconds, then apply it to each letter in a 30-letter sentence.
The point is simply that you should bear in mind the file size costs of animating even Flash-native attributes. Luckily, LM lets you vary your frame rate without adjusting the duration of your animations, so it's easy to dial frame rate up and down to trade file size for smoothness.
-
Regular vs. time-independent groups
On a related note, Flash (the authoring tool and SWF format) doesn't have an exact match for LM's concept of groups as containers that can be animated and transformed like other objects. Therefore LM must break apart its groups when it exports, writing transformation info for each item. One exception to this is time-independent groups, which LM exports as Flash movie clips. By giving each member of a group only the transformations unique to it, and by applying the common transformations at the time-independent group level, you can save significant file size.
To understand the file size implications, make ten objects, animate their scale over 1 second, then group them and animate the rotation of the group. Export and note the file size. Now select the group and from the Timeline menu choose Time Independent. Export and note the new file size. In my test I save 1.5kb. The more frames, objects, and attributes I use, the more the file size savings increases.
You can get dramatic savings when you duplicate groups and make sure they're set to be time independent. On export LM will wrap the contents in a Flash movie clip, and if the contents and transformations are identical (see below), it will recognize that they're the same and will re-use the contents.
So should you always use time-independent groups? If you're doing strictly linear animation, probably so. Remember, though, that if you stop the main timeline, TIGs will continue to play unless you add a behavior that targets and stops them. You also won't be able to see their contents moving in the editing environment, though it's easy to change the time independent setting back and forth as you work.
-
Pre- vs. post-transforms
LM has an interesting concept of pre-transform and post-transform. Put most simply, pre-transforms affect the artwork itself, whereas post transforms are applied just to particular instances of the artwork. This has implications for how LM optimizes SWFs by storing single objects and re-using them in the SWF, as well as for how it stores each object.
When you first import a piece of artwork and scale it, you're applying pre transforms; that is, you're changing the native size of that artwork and therefore (if it exports as a bitmap) the number of pixels it contains. To see this in action, place an image and export, then scale it up and export again. When you set a stopwatch for the scale attribute, you begin to apply post transforms; that is, you're just scaling that particular copy of the artwork. The trick is to find the point at which your artwork appears the largest, then choose Object->Transform->Make Actual Size. Now the native artwork is only as big as it needs to be in that situation, and at other points it will be scaled down and the effects of the scaling won't be so visible. The actual size determines the size required in the SWF.
You can see pre- vs. post-transforms at work by creating a circle and using the 3D palette to apply a 5-pixel bevel. Notice that when you pre-transform the circle, the bevel remains 5 pixels (because you're changing the source artwork), but when you post-transform the circle, the bevel distance scales with the rest of the circle (because you're transforming that copy of the circle, not the source object). Notice also that if you make a small beveled circle and post-transform it by setting a scale stopwatch and scaling it up, you can redefine its native size by choosing Make Actual Size.
Understanding pre- and post-transforms is essential when you want to duplicate animations without blowing up the size of your SWF. Earlier I mentioned that it's possible to save size by wrapping animated elements in a TIG, then applying transformations at the group level. Be aware that if you apply *pre* transforms at the group level to a duplicate TIG, that group will export separately from the original (the artwork it contains still may be stored once, but the animations applied to it will export twice). By setting a stopwatch, duplicating a TIG, and applying a *post* transform to the duplicate, however, you're telling LM that it should keep the underlying artwork the same and scale up just that particular instance of it.
-
Aliases
Now that you know a little about pre-/post-transforms and how SWF stored animation data, it'll be easier to understand the uses of LM aliases. Aliases make it easy to edit multiple objects at once in LM, and they export as single entities to Flash (that is, an animated TIG with several aliases should export to SWF just once). When you rotate or skew a symbol, you're usually applying a post-transform (that is, you're changing just the copy you're touching), but when you scale it, by default you're applying a pre-transform (that's why each copy scales). You can apply post-scales to an alias by first setting a scale stopwatch on the timeline, then scaling the alias. Color and object properties (shape type, points, etc.) are pre-transforms.
In the example above (duplicating time-independent groups and scaling one while keeping a single copy in the SWF), try making an alias to the original TIG animation, then setting a stopwatch and scaling the TIG. This should ensure that LM exports just one copy and uses it twice in the SWF.
Incidentally, using aliases can also speed up the performance of LM and reduce the size of its LIV source files.
-
Imported artwork vs. native versions
LM can have trouble exporting certain kinds of imported artwork efficiently. In particular, Illustrator files can contain objects that get rasterized when exported to SWF (for a complete list, see Larry Sullivan's FAQ at http://homepage.mac.com/ivansull/). Imported gradients can be particularly troublesome, so while you may import them, it's usually worth your while to re-create native versions in LM and delete the imported originals. The LM versions will export natively to SWF and won't slow down the editing environment so much. Also try converting Illustrator type into outlines before importing it into LM.
[Edited by JNack on 06-01-2001 at 12:55 PM]
-
Animating color vs. tint
If you're familiar with Flash, you might expect LM to vary the shade of objects in the same way that Flash does. But instead of varying tint (a native Flash transformation), LM varies the actual color of the object or layer. While this approach can yield more accurate results and allows you to apply color changes on just certain layers (Flash tint applies to a whole object), it requires LM to generate new artwork on every frame where color is changing. Therefore be judicious in animating color transformations, especially on artwork that will generate a bitmap on export to SWF. (For more info on what will become a bitmap on export, see http://www.adobe.com/support/techgui...cts/page4.html.)
You may be able to work around the file size penalty by making your shape a mask and animate the color of a rectangle beneath the mask. A new rectangle will be created on every frame, but it'll be about 35 bytes (almost definitely smaller than a new copy of your shape). One caveat: LM won't allow you to use vector artwork as a mask if you import it, but you can usually use the shape as a mask if you *paste* it instead. Converting the shape to a single color without a stroke before pasting may help.
[Edited by JNack on 06-01-2001 at 02:56 PM]
-
Clipping and re-using sounds
LM's sound handling can be both good and bad, depending on what you're trying to do. On the good side, unlike Flash it can clip off extra sound data you don't need. Let's say you bring in a three-second sound and decide you want only the first second's worth of audio, so you slide the end point of the object's lifetime back to 1 second; LM will export only 1 second's worth of data. But what if you use the sound again later, but this time you use all three seconds? LM will store a second copy of the sound, meaning you now have a total of four seconds' worth of audio data in your SWF--not so good.
To get around this, you can try wrapping sounds in time-independent groups, then setting the end point of the TIGs so that the sound gets clipped where you want, but the entire sound is stored just once. One warning: because the Flash player doesn't synchronize event sounds and animation, setting the out points in this way might not clip the sounds exactly where you specified. Since this depends heavily on processor speed, frame rate, and other factors, you should test your SWF on various computers.
-
Per-object settings and performance
Be smart with per-object export settings. Per-object settings let you finesse your SWF export by picking the best format for bitmap-creating objects, then reduce colors, play with quality, etc. Unfortunately, LM has to store and track each setting, which can translate to increased memory use and slower performance. Therefore it makes sense to pick the setting that makes the most sense for the most objects and store it at the document setting (this is what you're doing when you specify settings without having selected Object in the Export palette and made a new setting). Also use Active Export Preview to check whether an object will become a bitmap on export; if not, there's no point in weighing it down with a per-object setting.
-
Multi-layer objects
Objects with multiple object layers, even if those layers are simple shapes, will become bitmaps when exported to Flash. If you're using basic shapes in object layers, consider using multiple objects on the timeline so that they can export as vectors. You can still group the objects and animate characteristics at the group level so that you can manage just a single object. Note that this doesn't mean you should never use multi-layer objects. Sometimes those objects can export and animate more efficiently than a the pile of single-layer objects that would be required to achieve the same appearance.
-
Object opacity vs. object layer opacity
Try to avoid varying object *layer* opacity over time and instead vary object opacity. Object layer opacity controls how each layer of a multi-layer object blends with other layers, whereas object opacity (native to Flash) applies to an entire object. LM has to generate new artwork when you vary object layer opacity; when you change object opacity, however, it's handled natively in the Flash player. Some confusion comes from the fact that on a single-layer object, the two settings appear to have the same effect.
Some designers vary object layer opacity to make artwork appear and disappear in various custom states (useful when creating remote rollovers, for example). It would be more efficient to group the artwork and create the custom states at the group level; that way you could vary the object opacity of the grouped artwork, and LM would export just a single copy. Or, in the same scenario, you could skip the grouping and just turn off all object layers in rollover states where you want the artwork hidden. When all layers are hidden, LM will export just a blank placeholder.
-
Animating text size, tracking, and leading
Animating text size is almost never a good idea; in its attempt to be super-accurate, LM will generate new font information on every frame. Instead, animate the scale of a text object. That way LM will use native Flash scaling on a single piece of artwork.
Animating the tracking and leading of a text object is very cool in that it allows you to keep a single, editable word or phrase on the timeline while distributing its characters vertically and horizontally. But on export, LM will generate a new text object on every frame, meaning your SWF will be heavier and playback chunkier than if you animated each letter. Therefore, though it won't be as elegant in the editing environment, it may be more efficient to use the Break Apart Text command and animate the individual letters. You can still group the animated letters to get the effect of working with a single text object.
-
Animating gradients
Flash can't animate gradient characteristics such as angle and gradient stops natively, so LM generates a new gradient on each frame where the characteristics are changing. You can achieve much the same effect by positioning a gradient under a mask, then spinning or stretching it as necessary.
-
Distortion lenses
Distortion lens can look extremely cool, but animating them can quickly make your SWFs heavy. Using a lower frame rate will cause LM to generate fewer bitmaps, and using a very low per-object export setting with a distortion lens can reduce file size without compromising visual quality (after all, each image will be visible for only a fraction of a second). You can also use hold keyframes on the distortion characteristics in conjunction with regular keyframes on opacity keyframes to fade between versions of the lens. LM will only need to generate bitmaps where the distortion characteristics change.
Distortion lenses work particularly well when exporting to animated GIF. For example, try running a quantize effect at 8 frames per second over a word in a typical banner; in my tests with the GIF color palette set to 8 colors, I still have several kilobytes left over for other content.
-
thanks for all the info
-
Renaming groups
JNack
What if you were to make an alias of a group or TIG and then you changed the name of the alias, would it still export as one?
Alan M.
-
Re: Renaming groups
Hey, Alan. Names are shared among copies of an alias, so renaming one will rename all the other instances of it. Also, names aren't preserved on export, so they shouldn't have any effect on symbolization and reuse.
--JNack
-
Re: Per-object settings and performance
Hi JNack
I use Per Object settings but it seems that once I make one per object setting I have to go around and do it to all the Objects. How would I set the default object setting that would be used for all objects but still use Per Object settings for what I want. Whenever I Change one Per Object setting all other objects seem to display the same settings unless I give them there own Per Object Setting. Maybe I should just ignore this?
Alan M.
-
Re: Pre- vs. post-transforms
NJack
Joe Bowden said that Duplicating an object will most often export as one and will in reality symbolize or alias when exported. Is this true and if so when? Also the info about grouped objects having to have transforms attached to each object as apposed to using a Time Independent Group that only has transforms written once is excellent advice. Thanks.
(Just a side question)
I've been trying all different ways to embed behaviors inside multiple objects that I then turned into TIGs which I then gave over and down states which have TIGs inside downstate timelines all in an effort to get one down state to trigger two different down state triggers but I can't seem to make anything work. What I am trying to do is make a draggable object. Do you think it is possible with LM 1.0.2 or not? Should I give up I can't sleep at night?
Alan M.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|