What was previously marked as transition cuts would really only cut goal
and POA tracking. Transition cutting requires the addition of a
transition ovveride. The engine supports cutting transitions on
plCameraMsg receipt by the virtual camera. The option looked sloppy on
regions (and should probably be controlled in the transitions), but it
has been added to camera message nodes for more control.
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.
On the surface, this allows lightmaps to be exported as PNGs. However,
it also includes a light refactor of image exporting to facilitate
requesting export formats and the targeting of plImageLibMod. This
should better enable #96.
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 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.
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.
Refraction Xform causes the camera movement to affect the resulting
output differently, leading to an envmap that seems to run around the
object in the opposite direction as you turn.
Reflection Xform keeps it much more steady, and also matches what
PlasmaMax outputs by default (they have a checkbox to use Refract mode).
It appears that when the progress logger was broken up into separate
classes, the progress_end function was not properly split and some
threading functionality remained in the base class.
This moves convex hull generation from the file serialization stage to
the object export stage. No longer are we dependent on spotty library
support for proper convex hulls.
The only major issue with the console based progress solution is that
the user would have to remember to press "Toggle System Console" before
the export. This button corresponds to the operator
`bpy.ops.wm.console_toggle`. Unfortunately, Blender does not expose a
way for us to query the console state. So, we have to get nasty and use
ctypes to ask the OS if the console window is active. The user may
already have it open and hidden behind Blender's UI, after all.
This changeset causes the console to open during the export (unless
disabled in the export operator). If the console was closed before the
export, it closes again once the export is finished, unless there is an
error. If the console was open, it remains open.
Unfortunately, this only works on Windows. But, according to the source
code of `bpy.ops.wm.console_toggle`, Blender's `ghost_toggleConsole`
only functions on the Win32 subsystem... SDL, X11, and Cocoa are all
no-ops. Future work would include a patch submitted to Blender adding an
enum property to the console operator to avoid this code duplication.
Now the progress display will recognize errors using the `__exit__`
magic method and print out an error header with the actual error
message. This is useful because when the mouse leaves the Blender
operator's report error, the error "window" is destroyed. This led to
potential silent failures.
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.
