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.
In a previous changeset, the Advanced Logic modifier was changed to
defer exporting logic until the very end of the export process. This
means that many nodes are designed with the assumption that all
non-logic PRP objects are fully exported by the time they are exported.
LogicWiz modifiers, however, violated this assumption by exporting
during the main export() phase.
So, this adds a new `pre_export()` phase for all modifiers that lets
them generate logic trees and even entirely new Plasma Objects safely.
Futher, old LogicWiz modifiers have been tweaked to not leak junked
objects if the export fails in the middle of those modifiers.
In user testing, the "Bake All" operator overwriting the "Col" layer was
blowing away too much manual shading, reducing the usefulness of the
feature severely. This changes us to using the "autocolor" layer and
making it a somewhat ephemeral coloring layer. Any "autocolor" layer
generated by the exporter should be removed when the export finishes.
Otherwise, it should persist.
You can now bake "finalized" lighting to either vertex colors or a
lightmap image. This can be done either from the toolbox or from the
individual lightmap modifier. The purpose of doing this is to allow the
artist to opt-into a workflow where they can chose when to incur the
performance penalty, instead of on export. The downside is that the
artist now has to manually click a bake button. But, for some Ages,
especially "finished" ones receiving small updates, there is no need to
rebake the lighting each export.
This is the beginning of a workflow loop to (hopefully) improve the
performance of exporting Ages with expensive lighting. This commit
allows you to generate the autocolor layer in the Korman UI and rename
it to `col` to prevent needless re-baking.
This allows you to explicitly select quaternion animations. These appear
to be the default for bone animations and were silently dropped on the
floor before this change. A selection of quaternion or axis angle
implicitly disables bezier interpolation. Also fix the assumption that
Eulers are always in XYZ order.
Mark Eggert
Jrius
