We need to use the matrix provided by the higher level export code, not
the worldspace matrix. In some engine versions (MOUL), this will be
subworld space instead of worldspace.
I don't really want to talk about it. *Gulp*. Anyway, you define
multiple animations on either the animation modifier or the textures
panel. The UIs have all been unified. By default, you have an "(Entire
Animation)" that represents the old single animation. You may create
additional sub-animations over an arbitrary range of keyframes. Once
other animations are defined, the "(Entire Animation)" may be deleted.
However, if all subanimations are deleted, the "(Entire Animation)" will
resurect itself with its last known settings.
Behavior change: object animations (except for fixed cameras) now
REQUIRE an animation modifier be attached to export. It is now an error
to attach an animation modifier to any camera except for a fixed camera.
This is for if you have a layer that has an animated opacity but no
alpha, it will be able to receive the material's color animation. For
now, we won't apply those to upper layers as that doesn't really seem
like what we would expect.
This fixes a number of long standing chicken and egg problems that could
prevent opacity animations from working properly on RT-Lit materials.
Also addresses a number of odd situations where the lighting results
might drastically change in unexpected ways.
The default definition of `pre_export()` (for documentation purposes)
was hiding the real default implementation of `pre_export()`, causing
any modifiers relying on said default implementation to export nothing.
It looks like simply attaching a lamp to a group already has fairly
major implications for how it's exported. If you're adding a lamp into
a group, then you are basically saying, "I only want to affect these
specific objects.", so marking them as movable (meaning, "apply me
to all objects") doesn't really make sense in that context.
If we've unleashed Satan on a material, he will perform his dark magick
on the material colors. Therefore, we need to prefix the satanic
materials with something other than "RTLit_" lest the plain old runtime
lit materials be infected by the prince of darkness.
The dumb string lookup probably worked most of the time, but with recent
changes that can cause layers and materials to be renamed to things not
matching the pattern exactly, it's better to explicitly lookup the keys.
This will prevent Dynamic Text Maps from seemingly "breaking" for no
reason just because the lighting strategy changes.
I'm probably late to the party, but I have found that PotS can't handle more than 8 RT lamps on one material. This might vary by target engine, though, so no failure pronouncement is made.
Jrius
Mark Eggert