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.
The "strength" of the normal mapping is the red channel of its runtime
colour.
If the normal map is a specular map, it should be Add blending,
otherwise it should use MADD blending.
A few unfinished bits:
1. This doesn't properly handle multi-material objects, which are
permitted to have separate bumpmaps on each material.
2. This doesn't generate the BumpLutRamp image for the Du, Dv, Dw
layers.
