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.
Due to our disabling of texture baking when lightmapping, Blender would
not be able to cast light through transparent materials. Now, we revert
back to something resembling the manual method of lightmapping from the
bad old days of PyPRP.
Do note that because we attempt to batch object baking as much as
possible, I have disabled baking lightmaps to transparent objects.
This is because the transparent objects would need its textures disabled
for it to be baked to, but with the textures disabled, the renderer
would be unable to correctly determine the object's transparency. D'oh!
It would be possible, I suppose, to move them into their own batch, but
that makes the state machine a bit more complex. It would be better to
wait for someone to need that functionality, I think.
This fix only changes the behavior to use whatever the original
filename is. A complete fix would involve managing sound files and
ensuring that they are ogg-compressed.
Adds a framework for dealing with deprecated logic nodes. First
implementation is for Responder Commands, which hooks the messages
directly onto the Responder States. Note that the old socket definitions
are left alone because the upgrader will need that data.
This commit removes the ability for Responder State nodes to specify
Responder Command nodes. Now, Responder State nodes reference Message
nodes directly. Messages that support sending callbacks can now
reference other messages as linked outputs.
Note that old node trees are currently broken and will need to be
reworked by hand. TODO is to automatically upgrade those old command
based node trees. Also, LOGICWIZ code using command nodes needs to be
updated.
As it turns out, enumerating a collection that can be modified is a bad
idea. Indeed, Blender expects that we won't do this. Sometimes, it
appears to work, however, other times, Blender is unable to handle it
and the internal data gets corrupted, causing a crash.
This commit includes some bonus improvements for animated parenting
situations that I discovered through sciencing the various MOUL and PotS
PRPs. Hopefully it all works as advertised.
This causes an object to be given a plFilterCoordInterface instead of a
plCoordinateInterface. The difference is that plFilterCoordInterface
will reject changes to certain components of an object's transform. This
is useful in certain parenting situations, namely subworlds.
Not sure why this was happening, but if you got into a state where no
VisRegion was selected, the Environment Clear Color property would also
disappear.
Reordered to put the Clear Color at the top, so that it works
consistently and also makes it more obvious that it's unrelated to the
visibility regions.
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.
Generating lightmap previews in edit mode is nonsense. Also, there is
some issue in blender with changing the image assignment programatically
while in edit mode, so it's best to just disallow this entirely.
