This operator takes a file as an argument and builds a cubemap from it.
Valid options are to supply the output from Plasma's
Graphics.Renderer.GrabCubeMap console command. The operator will find
the other five files and generate a cubemap with the faces saved by
Plasma. Otherwise, any arbitrary image can be supplied. If the filenames
do not fit the expected format, any missing faces will be replaced by
the face specified in the file selector. This will generally result in a
cubemap with six identical faces.
Previously, we allowed OpenGL to generate all of the mip levels for us
in a mipmap. This was pretty doggone fast and worked reasonably well.
However, with cube maps, we will need to use images that are not always
backed in Blender... this is because Blender stores cube maps as one
single image instead of one image per face. So, we need to be able to
generate those mip levels, preferably without touching Blender's
`Image.pixels`, which is slower than Christmas...
Also of note... `Image.gl_load()` will actually scale the iamge to a POT
when Blender is using OpenGL ES... but not on other platforms. So, now,
we just ask Blender to load the image and deal with the POT-izing later.
The con here is that the pure python implementation of the image scaling
function is SLOOOOOOOW. We're talking ~40 seconds to process a 1024x1024
mipmap. No one should be using the reference implementation, however,
and the C++ implementation shows no noticable slowdown over the OpenGL
code.
Whew.
Cube maps in Plasma are six separate images; however, Blender expects to
be supplied with one image that encompasses all of the cube faces.
Therefore, our texture cache needs to be able to support many images for
one request.
This provides the artist the ability to disable exporting layers that
would be DynamicCamMap (fast) in MOUL but DynamicEnvMap (slow) in PotS
in one fell swoop. Please note that disabling env map exporting will NOT
prevent waveset environment maps from exporting.
Blender used to not specify COMPAT_ENGINES on the physics panels. It
does now, and the new poll methods are incompatible with ours. This
results in lots of noisy errors being raised when in Blender Render mode
with the Korman addon active.
The lightmap modifier is now a more general "Bake Lighting" modifier
that can control how vertex colors are baked as well. The default vertex
color baking behavior is unaffected. It is now identical to adding a
Bake Lighting modifier, changing it to bake vertex colors without
specifying a pass.
Unfortunately, packed images don't appear to store any kind of modify
time attribute. In the case of those, we're just idly hoping that we can
find one on disk.
Previously, the C korlib used a custom buffer class to avoid a memcpy
operation. However, pyMipmap expects binary string (PyBytes) objects, so
this changes the code to use them. Future work would be to continue
using PyBytes and removing the copy. For now, there are bigger fish to
fry...
Some operators, namely the bake operator, require there to be an
active_object. The lightmap operator manages the selection, so this only
fixes Blender whining about the context being incorrect due to a
technicality.
Pull request #114 was causing messages that could wait but had no child
messages to always have waits generated for them. This was causing some
responder states to never be marked completed. This ensures only
messages that need to be waited on have waits generated for them.
Messages that must be waited on include:
- the last waitable message if the responder is attatched to a PFM
- the last waitable message if it's the last message in the state
- any waitable message that has a child message
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.
