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.
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.
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 makes things incredibly more complex because Blender stores those
animations on the ObData ID instead of the Object ID data block. Dang. So,
the animation modifier's detection code had to be pretty much scrapped.
The newer code is a little hacky in places. Hopefully we can address this
soon-ish.
These rules made sense in 0.01 when we promoted modifier names. However,
these have been disallowed for over a year now. These restrictions are
sneaky and serve no purpose now.
Marein Könings