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.
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.
Marein Könings