For sanity, I stripped the progress manager into a subclass. From there,
I moved all of the progress printing into a thread so that we can accept
signals for step progress. If there is no step progress for a time, we
show the user a rolling set of ellipses to prove we're not dead (yet).
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.
The changeset referenced makes the assumption that
`grouped_fcurves[chan]` is a dict. We really can't assume anything about
types this deep inside the animation converter.
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.
When use_sphere is enabled, the lamp cutoff is at exactly the distance
value. Otherwise, the distance value is the point at which the lamp
intensity is half its starting value.
This probably doesn't match Blender 1-to-1, but it's closer to Blender's
lighting logic than the existing use_sphere calculations.
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.
