138 lines
5.5 KiB
Plaintext
138 lines
5.5 KiB
Plaintext
I started ABX very informally, so I did not really have logical version numbers
|
|
initially, and I'm not sure about the earliest packages I made.
|
|
|
|
In April 2021, I started trying to formally package with a consistent version
|
|
number, with the following meanings:
|
|
|
|
|
|
0.1.0 (<2021):
|
|
Versions before 2021, with "Copy NLA" and "L.Ink Compos" and not much else.
|
|
|
|
There were some experimental version of context.py, file_context.py, and
|
|
blender_context.py in the source, but they were unused and buggy or incomplete.
|
|
|
|
|
|
0.2.0 (2021-02 to 2021-05):
|
|
Versions from April/May 2021, with major design changes:
|
|
|
|
* "Copy NLA" became "Copy Animation", and acquired new options:
|
|
- NLA (Old NLA behavior)
|
|
- Dopesheet (copy the "active action", which appears in the dopesheet).
|
|
- Copy/Rescale (instead of linking the animation, copy it, possibly rescaling)
|
|
- Scale Factor (if other than 1.0, the animation is scaled when copied)
|
|
|
|
* "L.Ink Compos" became "Ink/Paint Config", and also got new options:
|
|
- Ink-Thru (Freestyle ink workaround for transparency, can now be turned off)
|
|
- Billboards (Accurate alpha-billboard ink masking technique)
|
|
- Separate Sky (Generate sky on a separate render layer for accurate compositing)
|
|
|
|
* "Lunatics! Properties" got a new field for the scene "suffix" or title, used
|
|
exclusively to give some extra information in the scene name. This was to
|
|
accommodate short shot codes I was using, like "G.PoV" meaning "Georgiana
|
|
point-of-view shot", to clarify the letter-codes for the shots, especially
|
|
since I was changing some of them around.
|
|
|
|
|
|
0.2.5 (2021-05):
|
|
The last version before introducing the file_context data system into the main
|
|
functions of the program. It contains fully-working and tested file_context.py
|
|
and accumulate.py, but they haven't been updated with specific changes to
|
|
accommodate the Blender UI yet, and the abx_ui.py module doesn't use them.
|
|
|
|
I made this version as a stable fallback for production with all of the recent
|
|
bugfixes, but none of the new (and likely buggy) data system features.
|
|
|
|
Includes:
|
|
|
|
* render_profiles feature in the Render panel. This is a quick select for
|
|
changing the render settings and output filepath to be named consistently
|
|
and use the correct settings for the most common pre-visualization renders
|
|
I make, and the full PNG stream render.
|
|
- The profiles are hard-coded, because there's no contextual data yet.
|
|
- EXR files may be generated from previz. I didn't make any attempt to
|
|
stop this, because it's usually not relevant (they'll be clobbered by
|
|
the full PNG renders, which are done last -- but this could be a problem
|
|
if I tried to regenerate the previz later)
|
|
|
|
|
|
|
|
ROADMAP (for 2021?):
|
|
|
|
0.2.6 (2021-05):
|
|
The first attempt to incorporate YAML configuration into the program.
|
|
|
|
* Introduce better fallback behavior when project YAML files aren't found,
|
|
and give informative messages to the user about them.
|
|
|
|
* Move program defaults into abx.yaml and project.yaml files in the ABX
|
|
source code. Load these before project files to guarantee default requirements
|
|
are met.
|
|
|
|
* Use abx.yaml 'render_profiles' block to set options for render_profiles
|
|
|
|
0.2.7:
|
|
Replace "Lunatics! Properties" with "Project Properties" (the project name will
|
|
be one of the properties, and probably read-only). Parse the "role" field.
|
|
Generate read-only data from file_context and appropriate data-type fields
|
|
for unspecified ranks.
|
|
|
|
0.2.8:
|
|
Fix the schema override issue to allow for use with library assets or other
|
|
hierarchy besides episodes. Improve the handling of "rank" (possibly refactor
|
|
the code to make rank-handling more intuitive?)
|
|
|
|
0.2.9:
|
|
Write / save / update to filepath to allow changing the name based on the
|
|
input from the Project Properties (Not 100% sure I want this).
|
|
|
|
0.3.0:
|
|
0.3.0 should have full data support driving the program features.
|
|
|
|
0.3.1:
|
|
Pop-up report generation? I had this working experimentally, years ago, and
|
|
it'd be useful to generate pop-up reports for some of the introspection
|
|
features I want to add.
|
|
|
|
0.3.x:
|
|
Improvements to data system and other capabilities.
|
|
|
|
* Name context by group, rather than scene? Would be handy for library assets.
|
|
|
|
* Possible integration with KitCAT? There's significant overlap between ABX
|
|
and KitCAT and I already call the metadata files "kitcat" data in the sources.
|
|
Will they be merely interoperable, or should I actually make ABX into the KitCAT
|
|
plugin for Blender?
|
|
|
|
* Port ABX to Blender 2.8+, keeping 2.7 support, if possible. If I'm really
|
|
going to use 2.8 for compositing, I will need this.
|
|
|
|
0.4.x (hopefully during 2021, because these would be very useful to have!):
|
|
New features. Hopefully:
|
|
|
|
* Recognize/use "role" field.
|
|
* Ink/Paint Config for compositing (as opposed to rendering)
|
|
* Appropriate config tools for anim, mech, etc -- other roles
|
|
* Automate Freestyle "Ink-Camera" clipping system.
|
|
* Character Armature comparison (find misnamed or extra bones)
|
|
* Insert characters into an animation file
|
|
* Find/report broken dupligroups and/or animation proxies
|
|
* Generate linking report(s) -- information to support correct
|
|
linking diagrams, or possibly source for auto-generating them?
|
|
|
|
0.5.x:
|
|
Integration with Papagayo / Lipsync data for animation?
|
|
Maybe find the appropriate data files and run the lipsync importer on them?
|
|
Or perhaps incorporate the lipsync importer code?
|
|
|
|
|
|
0.6.x:
|
|
Automated management of credits & licensing? (Or does this all fall under
|
|
the heading of KitCAT?)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|