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.
OK, this commit does a lot, and it was hard to separate the changes, so
mega-commit.
- We now export stencils in such a way that Plasma layers can be affected
by multiple stencils, theoretically matching the Blender behavior
- We don't try to animate stencils or even offer animation options. This
is nonsense.
- In our zealousness to skip over illegal texture slots, there was a bug
introduced in which we queried texture fcurve paths illegally,
potentially causing animations to be exported incorrectly. This has been
fixed.
- There was a potential issue with the animation command node's material
option in which the message could be sent to the wrong page. This has
been corrected by making the Object field mandatory for all animation
types.
This idiotic change was introduced in stealth mode from 2.76 to 2.77. It has something to do with 3d textures, supposedly. I think the person who made this change is simply an asshat...
Ok, so, the exporter incorrectly assumed it created all plLayerAnimations.
In reality, nodes could create the plLayerAnimation first. If the material
exporter recreates the object, bad things happen, and an invalid
plLayerAnimation is added to the hsGMaterial. UruExplorer then goes
KABLOOEY!!!
Korlib will have two components: a python implementation in Korman and a
C++ "_korlib" module that will be insanely fast. Users will apreciate it,
and devs will be glad they don't have to compile the C version.
To ensure that there are really, really, REALLY no race conditions related
to coordinate interfaces, we now run through all modifiers before we
export and ask them if they need to make Coordinate Interfaces. I was
hearing some comments about clickables warping around. This sounds like
physical coordinate issues to me...
jb