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.
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.
This was troublesome in that the Blender documentation implies that
`FCurve.range()` returns times when it actually returns frame numbers.
This superceeds and closes#216. Prefer this fix because
`functools.reduce` is not as readable and the formatting is closer to
what exists in the animation converter.
This fixes the layer preshade color to be black when runtime lighting is
requested. Further, both preshade and runtime are properly set to black
for emissive layers.
This enables the Blender Mesh Normal panel and exports any double sided
mesh with double sided layers to Plasma. The implication is that the
mesh will be rendered twice in game--the second time with the winding
reversed. Wavesets marked double sided are ignored due to the runtime
generation of layers in game. Trying to make a double sided waveset is
therefore nonsense.
This allows for objects to print decals at runtime, like the baskets in
Eder Gira. Also, the same functionality can be hijacked for coincident
objects to exist as decals. This is basically a shortcut for adding hack
Z-flags to the base layer of a decal material.
This allows blend textures to be used for mesh transparency without
having to fiddle around too much. It was also a stab at fixing some
regressions in the MOUL engine around decals, but that bit failed,
sadly.
Two problems were fixed here:
- Materials were always exported unconditionally, meaning that we were
wasting time processing the same data over and over. This could have
generated "interesting" data (eg multiple hsGMaterials and friends with
the same name) that Plasma would have barfed on.
- Lightmaps were being applied to the incorrect materials
If the texture cache doesn't return images in exactly the order or way
that libHSPlasma is expecting, it raises a RuntimeError. We can detect
that we used a cached image and regenerate the data in that case...
instead of just outright failing with "image data size mismatch".
This operator takes a file as an argument and builds a cubemap from it.
Valid options are to supply the output from Plasma's
Graphics.Renderer.GrabCubeMap console command. The operator will find
the other five files and generate a cubemap with the faces saved by
Plasma. Otherwise, any arbitrary image can be supplied. If the filenames
do not fit the expected format, any missing faces will be replaced by
the face specified in the file selector. This will generally result in a
cubemap with six identical faces.
Previously, we allowed OpenGL to generate all of the mip levels for us
in a mipmap. This was pretty doggone fast and worked reasonably well.
However, with cube maps, we will need to use images that are not always
backed in Blender... this is because Blender stores cube maps as one
single image instead of one image per face. So, we need to be able to
generate those mip levels, preferably without touching Blender's
`Image.pixels`, which is slower than Christmas...
Also of note... `Image.gl_load()` will actually scale the iamge to a POT
when Blender is using OpenGL ES... but not on other platforms. So, now,
we just ask Blender to load the image and deal with the POT-izing later.
The con here is that the pure python implementation of the image scaling
function is SLOOOOOOOW. We're talking ~40 seconds to process a 1024x1024
mipmap. No one should be using the reference implementation, however,
and the C++ implementation shows no noticable slowdown over the OpenGL
code.
Whew.
Cube maps in Plasma are six separate images; however, Blender expects to
be supplied with one image that encompasses all of the cube faces.
Therefore, our texture cache needs to be able to support many images for
one request.
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.
Jrius
Patrick Dulebohn