Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
Adds a C++ based FBX importer, using 3rd party ufbx library (design task:
#131304). The old Python based importer is still there; the new one is marked
as "(experimental)" in the menu item. Drag-and-drop uses the old Python
importer; the new one is only in the menu item.
The new importer is generally 2x-5x faster than the old one, and often uses
less memory too. There's potential to make it several times faster still.
- ASCII FBX files are supported now
- Binary FBX files older than 7.1 (SDK 2012) version are supported now
- Better handling of "geometric transform" (common in 3dsmax), manifesting
as wrong rotation for some objects when in a hierarchy (e.g. #131172)
- Some FBX files that the old importer was failing to read are supported now
(e.g. cases 47344, 134983)
- Materials import more shader parameters (IOR, diffuse roughness,
anisotropy, subsurface, transmission, coat, sheen, thin film) and shader
models (e.g. OpenPBR or glTF2 materials from 3dsmax imports much better)
- Importer now creates layered/slotted animation actions. Each "take" inside
FBX file creates one action, and animated object within it gets a slot.
- Materials that use the same texture several times no longer create
duplicate images; the same image is used
- Material diffuse color animations were imported, but they only animated
the viewport color. Now they also animate the nodetree base color too.
- "Ignore Leaf Bones" option no longer ignores leaf bones that are actually
skinned to some parts of the mesh.
- Previous importer was creating orphan invisible Camera data objects for
some files (mostly from MotionBuilder?), new one properly creates these
cameras.
Import settings that existed in Python importer, but are NOT DONE in the new
one (mostly because not sure if they are useful, and no one asked for them
from feedback yet):
- Manual Orientation & Forward/Up Axis: not sure if actually useful. FBX
file itself specifies the axes fairly clearly. USD/glTF/Alembic also do
not have settings to override them.
- Use Pre/Post Rotation (defaults on): feels like it should just always be
on. ufbx handles that internally.
- Apply Transform (defaults off, warning icon): not sure if needed at all.
- Decal Offset: Cycles specific. None of other importers have it.
- Automatic Bone Orientation (defaults off): feels like current behavior
(either on or off) often produces "nonsensical bones" where bone direction
does not go towards the children with either setting. There are discussions
within I/O and Animation modules about different ways of bone
visualizations and/or different bone length axes, that would solve this
in general.
- Force Connect Children (defaults off): not sure when that would be useful.
On several animated armatures I tried, it turns armature animation
into garbage.
- Primary/Secondary Bone Axis: again not sure when would be useful.
Importer UI screenshots, performance benchmark details and TODOs for later
work are in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/132406
Disable dynamic SDL loading as well as disable SDL for release builds.
This was only used for audio output which can already use OpenAL
if there are back-ends not natively supported by Blender.
- Remove extern/sdlew/
- Remove the WITH_SDL_DYNLOAD build option.
- Remove `bpy.app.sdl.available`.
Ref !127554
Blender had a very limited (only uncompressed or MJPEG frames) .avi file
support, for both reading and writing. This is something that ffmpeg can
fully do.
This removes all of that. 3500 lines of code gone, primary motivations being:
- ffmpeg can read and write .avi files just fine, including ones with
uncompressed or MJPEG frames.
- Blender's ffmpeg integration could also be taught to produce uncompressed or
MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern
formats like H264 are better in every way, and already support "lossless"
option if needed.
- The "Lite" blender build configuration was excluding both ffmpeg and avi
anyway, so that config is something that can't read nor write any movies.
User visible changes:
- In scene image output type, under Video section now there's only Ffmpeg Video
(AVI Raw and AVI JPEG are gone)
- Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG,
it is set to Ffmpeg Video.
Pull Request: https://projects.blender.org/blender/blender/pulls/118409
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
