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.
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.
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.
Font objects were exported as a completely different SceneObject,
causing the parenting relationship to be broken. This ensures that the
drawable is properly attached to the correct SceneObject.
Previously, reusing node trees required careful thought and
specification of specific nodes in the advanced logic modifier. This
tedious requirement has been removed in favor of ensuring that the nodes
themselves take into account whether or not they should generate and
attach plasma objects.
There are some cases where errors, while bad, are not the end of the
world. I'm thinking namely about compyling the age python. The age still
exports just fine, but the ancillary data is flawed. This new system
collects nonfatal errors until the export is done, then raises them all
at once.
Age output files are now handled in all aspects by a singleton manager.
This allows us to track all generated files and external dependency
files and ensure they are correctly copied over to the target game... Or
not, in the case of an age/prp export from the File > Export menu.
Currently only SFX files are handled as an external dependency. TODO are
python and SDL files.
Further, because we have an output file manager, we can bundle all the
files into a zip archive for releasing the age in one step. Wow such
amazing. ^_^
This provides the artist the ability to disable exporting layers that
would be DynamicCamMap (fast) in MOUL but DynamicEnvMap (slow) in PotS
in one fell swoop. Please note that disabling env map exporting will NOT
prevent waveset environment maps from exporting.
The lightmap modifier is now a more general "Bake Lighting" modifier
that can control how vertex colors are baked as well. The default vertex
color baking behavior is unaffected. It is now identical to adding a
Bake Lighting modifier, changing it to bake vertex colors without
specifying a pass.
Given that the Plasma World (read: age) is defined per scene, it seems
appropriate to limit the export to the current scene. Other scenes could
potentially have other age definitions...
This commit includes some bonus improvements for animated parenting
situations that I discovered through sciencing the various MOUL and PotS
PRPs. Hopefully it all works as advertised.
This causes an object to be given a plFilterCoordInterface instead of a
plCoordinateInterface. The difference is that plFilterCoordInterface
will reject changes to certain components of an object's transform. This
is useful in certain parenting situations, namely subworlds.
The only major issue with the console based progress solution is that
the user would have to remember to press "Toggle System Console" before
the export. This button corresponds to the operator
`bpy.ops.wm.console_toggle`. Unfortunately, Blender does not expose a
way for us to query the console state. So, we have to get nasty and use
ctypes to ask the OS if the console window is active. The user may
already have it open and hidden behind Blender's UI, after all.
This changeset causes the console to open during the export (unless
disabled in the export operator). If the console was closed before the
export, it closes again once the export is finished, unless there is an
error. If the console was open, it remains open.
Unfortunately, this only works on Windows. But, according to the source
code of `bpy.ops.wm.console_toggle`, Blender's `ghost_toggleConsole`
only functions on the Win32 subsystem... SDL, X11, and Cocoa are all
no-ops. Future work would include a patch submitted to Blender adding an
enum property to the console operator to avoid this code duplication.
For sanity, I stripped the progress manager into a subclass. From there,
I moved all of the progress printing into a thread so that we can accept
signals for step progress. If there is no step progress for a time, we
show the user a rolling set of ellipses to prove we're not dead (yet).
A common complaint that I have heard (and have nyself) is that there is
little indication of what Korman is doing in the background. In PyPRP,
the raw export log was dumped to the console, and many liked to watch it
travel by as an indicator of progress. As such, I have implemented a
rudimentary progress monitor that outputs to the console into the export
logger.
Unfortunately, there is no "easy" way to show progress in the Blender UI
currently. Korman makes the assumption that nothing will touch
Blender's context while it is executing. Attempts to mvoe the exporter
into a background thread have all resulted in spectacular failures. So,
this will have to do for now.
The export logger and export reporter have been merged together to form
an eventually much more powerful export analysis feature. For now, the
benefit is that general log messages don't have to be so fiddly with
print statements and string formatting. You're welcome.
Added the Render > Lighting modifier that lets one specify whether or not
we should forcibly use RT lights. This allows us to change the light
baking rules to allow the baking of nonanimated Plasma lights when this
setting is disabled. The modifier also has text explaining what the
lighting results should look like.
Jrius
James Thomas