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.
On the surface, this allows lightmaps to be exported as PNGs. However,
it also includes a light refactor of image exporting to facilitate
requesting export formats and the targeting of plImageLibMod. This
should better enable #96.
Refraction Xform causes the camera movement to affect the resulting
output differently, leading to an envmap that seems to run around the
object in the opposite direction as you turn.
Reflection Xform keeps it much more steady, and also matches what
PlasmaMax outputs by default (they have a checkbox to use Refract mode).
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.
Jrius
Patrick Dulebohn
