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.
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.
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.
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.
This allows us to ensure that a given NodeTree is only ever exported once.
A node reference acts as a way to attach a plMultiModifier to a
plSceneObject without using those terms. Things will work just fine if the
node reference isn't used, so as long as the entire tree is only used
once.
Future work: ensuring the whole logic tree is only ever exported once.
To ensure that there are really, really, REALLY no race conditions related
to coordinate interfaces, we now run through all modifiers before we
export and ask them if they need to make Coordinate Interfaces. I was
hearing some comments about clickables warping around. This sounds like
physical coordinate issues to me...
This makes sense because the pages to export checkboxes are here. The
export modal should be sort of a "last-chance" settings thing... not
actual core settings.
This means we now export BOTH plDyanmicEnvMap and plDynamicCamMap. The
latter will only be exported on MOUL+, sadly. The former is "cube" mapping
and the latter is "plane" mapping. Instead of manually specifying the
refresh rate, I decided that Blender's "static" option means that it only
refreshes once (and never again) and animated means we refresh every 0.01
second, which seems to be the Cyan standard for "update every frame, blast
it!" NOTE: when cameras are exporting, we need to support Camera based
DCMs.
Static image based CEMs coming soon...
This is done using the new checkboxes on the page list under the World
panel. Seemed like the best way to do it within our format. Perhaps the
rest of the exporter options should move to that panel at some point.
- Applying scale to *all* objects in the scene is now a pre-export step.
- Make sure we always export the physical's coordinates--this matches
Plasma's behavior.
This includes changes to the light baking code to ensure that we don't
bake runtime lights. This code has several places it could be optimized in
the future when we have larger ages to test against.
We now harvest information about texture images throughout the export
process and don't pull the trigger until we're totally done. There are
still some issues with regard to confusing UI, but we'll get to it.
It appears that we were storing PyHSPlasma objects in class attributes, so
they were being held after the plResManager went away--therefore their
keys were nuked. We should probably be holding keys and not objects, but
this fix works regardless.
So this is a fairly massive chunk. I tried to get our Plasma Modifiers to
match the Blender Modifier UI fairly well. In the process, I discovered
that Blender "helpfully" hides the modifier button on Empty objects. Bah.
Significant Changes:
- Hid all of the Blender Physics mess
- The Physics context is now the Plasma Object context
- Moved Plasma Object and Plasma Synchronization to the Context Formerly
Known as Physics
- Added a Plasma Modifier Panel
Here's how you create Plasma Modifiers:
- Add your PropertyGroup to properties.modifiers
- Make sure you have a pl_id naming your modifier, a category, and a label
- Implement the export() method to actually export something useful (not
goat porn, please)
- Implement your UI draw function in ui.modifiers.
- Wasn't that easy?
