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.
Export all images right-side up. OpenGL flips them because fail, so we
have to do a bit of work to correct that. Thankfully, this operation is
not as slow as I thought.
NOTE TO SELF: remember, texture page updating would be nice to have...
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...
This means we now export BOTH plDyanmicEnvMap and plDynamicCamMap. The
latter will only be exported on MOUL+, sadly. The former is "cube" mapping
and the latter is "plane" mapping. Instead of manually specifying the
refresh rate, I decided that Blender's "static" option means that it only
refreshes once (and never again) and animated means we refresh every 0.01
second, which seems to be the Cyan standard for "update every frame, blast
it!" NOTE: when cameras are exporting, we need to support Camera based
DCMs.
Static image based CEMs coming soon...
Previously, it appeared visually that only one material was applied to the
mesh. Appearances can be deceiving. We were actually exporting all
materials and such correctly. However, because we were using a dyanmic
type with class attributes to store per-material data... All materials
shared all data. So, all materials rendered all vertices. You saw visually
the one last material rendered. Fun, eh?
This includes changes to the light baking code to ensure that we don't
bake runtime lights. This code has several places it could be optimized in
the future when we have larger ages to test against.
This should make the average age look a little bit better. I hope... If
you want to get rid of this crappy lighting, create a vertex color layer.
Or, better yet, add a stupid lightmap modifier!
Still lots of considerations:
- Need to make faux lightgroups to avoid baking Plasma RT lights
- Still need to bake vertex colors
- Still need to export Plasma RT lights (D'oh!)
But, this is definitely a step in the right direction!
