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.
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.
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 appropriately marks spans as VtxNonPreshaded if they use vertex
alpha or runtime lighting. In those cases, we properly fold the runtime
light color into the vertex color as expected by Plasma.
This matches us up more closely with what PlasmaMAX does and allows us
to really fix x-raying effects by properly forcing objects into the
correct render pass.
MOUL/DX9 will not rt light any vertex with a near-zero component in its
normal. This prevents shadows and decals from appearing on flat surfaces
in Ages exported for the MOUL engine. Instead of fighting with the
pipeline and vertex buffer code in Plasma, we'll just clamp the values
here.
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.
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...
Arbitrary data from a material's layer flags were able to creep into a
DSpan's criteria, causing geometry that should go into the same span to
spawn a new DSpan with an identical name. Only one of the DSpan objects
would be exported, and Uru would either show crazy stuff or crash as a
result.
We're only a BlendSpan if the *first* layer of a material has a blend.
Other layers are permitted to have blend modes, because those don't
affect the blending of the span itself against other spans.
This matches the behaviour of PlasmaMax:
42c4acbc9d/Sources/Tools/MaxConvert/plMeshConverter.cpp (L1205-L1210)
If certain modifiers are applied during the bake process, the resulting
lightmap is fullbright. To solve this, we cache the modifier data, clear
them away, then bake. When the export is completed, we then restore the
modifiers.
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.
plGeometrySpan.TempVertex.uvs now returns an immutable tuple, so we have
to convert that to a list. Furthermore, I took the liberty of changing
to code to avoid spin-washing on the first encounter of a bumpmapped
vertex.
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.
Really I guess this is implementing non-smoothing, since we previously
treated all faces as if they had smoothing enabled.
It's technically a breaking change, but should make Plasma with runtime
lighting match what you'd expect from the Blender 3D viewport.
It also matches how PlasmaMax treats meshes by default with no smoothing
groups attached.
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
Mark Eggert
