For some reason, this modifier is disabling facing in its own Burger
King type way. This apparently worked before, but, now that angles are
being exported correctly, this breaks things in game. So, don't export
any facing conditions at all.
Weird feature request by artists. Korman's lighting equation selection
looks like it should work fine with this, though. The key is to be sure
that we don't pick up a stale autocolor layer.
* Removed the `OrderedDict`s
* Changed some stuff from the code review
* Fixed a typo
* Added these imports: `from __future__ import annotations`
and `from typing import *`
* Moved `from __future__ import annotations` to the top.
* Changed type annotation `any`s to `Any`
the `pre_export_optional_cube_region` function is a decent idea, but it
predates the ability to do things like `foo = yield bar()` in
`pre_export()` generator methods. So, we remove it in favor of yielding
and assigning in one line. This should clean up some noisy warnings from
Blender after the export is over.
Both the facing target conditional and object in volume and facing
detector store the cosine of the angle. We were only doing the cosine
for one case but not the other.
GUI Dialog Mods don't require any particular object type - they're just
hints about what's going on with the GUI. Limiting them to meshes
actually breaks the Note Popup modifier, which attaches a GUI Dialog
modifier to an empty.
The helpers added in #367 are great, but they don't quite match up with
what's being done here. Maybe that's why I neglected to convert this
over to the new thing. Anywho, just use the closest newflangled match.
The `_sound_name` field does not include the channel suffix (eg `:L` and
`:R`), so this would explode when attempting to control a stereo sound
that has been split into mono channels.
This means you can't add VisRegions to your GUI pages. You also can't
make an empty object be a panic link region. Those kinds of things just
don't make sense.
* Fix CubeMap Bug
* Adds a sanity check that raises an error if a CubeMap doesn't have an image.
* Refine coding
* Adjust a few things per Hoikas' suggestion
* Update korman/exporter/material.py
Fix line of code per Hoikas' suggestion
Co-authored-by: Adam Johnson <AdamJohnso@gmail.com>
* Update korman/exporter/material.py
---------
Co-authored-by: Adam Johnson <AdamJohnso@gmail.com>
Our calculations try to fill the entire screen with the GUI objects. So,
really, what we want the GUI Camera scaling to do is allow the artist to
make the GUI smaller onscreen by pushing the camera away. This is a
*less than* 100% scaling.
We will now calculate the area-weighted normal of all polygons in the
GUI page, then flip it to create the direction that the GUI camera
should face. This will, theoretically, be more intuitive to artists in
that the GUI camera should always point at what they've modelled instead
of imposing arbitrary rules on the coordinate system of GUI objects.
This adds just enough plumbing to be able to export GUI popup notes
using the standard xDialogToggle.py. There are still a number of TODOs
and FIXMEs in the basic stuff, but the design is mostly solid. The idea
is that you'll create a GUI page for any objects that need to appear in
a GUI. The GUI does not require an explicit GUI camera, however. For
now, an automatic GUI camera will be made facing the largest object's -Z
axis.
The Python File Nodes were always picking up the group owner's
`plAGMasterMod` key instead of the group's `plMsgForwarder` key. This is
fixed by using the appropriate generic method for fetching an
animation's key.
Blender's `bpy.ops.object.duplicate()` operator changes the underlying
object that's selected to be the duplicate while the code expected for
the underlying object to remain unchanged. This uses a lower-level ID
copy mechanism that should hopefully give the intended result.
There are some things that exist in `pre_export()`, eg animations, that
don't actually generate anything that needs to be memory managed. So,
it's ok if `pre_export()` isn't actually a generator function. It does
need to return either a generator or `None`, however.
Previously, this functionality was implemented in context-dependent operators. Considering that Korman is becoming increasingly complex and is now generating entirely new objects (potentially with modifiers) as part of its export process, it was becoming cumbersome to use those operators.
It is now possible to write
```python
my_object = yield create_something()
```
to ensure that temporary objects are always managed by the exporter. Previously, the more verbose
```python
my_object = create_something()
yield my_object
```
was needed.
1Codealot
Patrick Dulebohn