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.
So, the previous hypothesis was absolutely WRONG. The real issue was the
appending of .001s and such when you have a material on many objects. Each
object-material pair has its own light group now because object Plasma
modifiers can change the rules a bit.
w00t for fixage
Doobes has reported that _LIGHTMAPGEN groups can be intermittently left
attached to some lamps. This is similar to a UnicodeDecodeError we were
having before in which a cached Blender object pointer became trashed
somehow. I think in this case our cached copy of the light group is no
longer equal to what is found in bpy.data.groups, so the removal fails...
Or something along those lines.
So, we now find the group again from the list and erase that. As a final
sanity test, on blend file save, we nuke all _LIGHTMAPGEN groups.
Darryl Pogue
Marein Könings