Make rasterization consistently work in local tile coordinates.
Also avoid memory leak when baking multiple tiles: high resolution bake
mesh has been created for every tile.
Pull Request: https://projects.blender.org/blender/blender/pulls/145163
When rendering to an image/video file, check whether the recursive
directory creation actually succeeded. If not, log an error and stop,
instead of trying to write the file.
This results in easier to understand error messages, and will help to
triage some (what we think are) race conditions with the Blender Studio
render farm.
Pull Request: https://projects.blender.org/blender/blender/pulls/145118
Supports baking to object and tangent space.
Compatible with Cycles Vector Displacement node which has the
(tangent, normal, bitangent) convention.
The viewport situation is a bit confusing: seems that Eevee
does not handle vector displacement properly and rips all faces
apart. Cycles renders the displaced object correctly.
Not entirely happy with the UI, as displacement space does not
really belong to the Output, but so doesn't Low Resolution Mesh.
Perhaps the best would be to have a separate pass to revisit the
settings, and also make it more clear what the Low Resolution Mesh
actually does.
Pull Request: https://projects.blender.org/blender/blender/pulls/145014
Almost all settings were duplicated between BakeData and RenderData.
The only missing field was the bake type, which is stored as a custom
property in Cycles.
This change:
- Removes unused bake_samples and bake_biasdist.
- Migrates settings like bake_margin to BakeData.
- Switches multires baker to use bake_margin.
- Introduces bake type in the BakeData, the same way how it was
defined in RenderData::bake_mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/144984
This change makes it so baking displacement to the high-resolution mesh
(Use Low Resolution Mesh option is OFF, displacement is calculated
between top multi-resolution level and subdivided viewport level mesh)
uses texture UVs and tangent space from the high-res mesh.
This matches intended use-case when object baked with such configuration
have subdivision surface applied to them bringing overall resolution to
the same level as the highest multi-resolution level.
The issue was simple to see when baking high-res displacement for an
object which uses "Keep Corners, Junctions" UV smoothing.
The unfortunate aspect is increased memory usage due to calculation of
the grid index and grid UV mapping, but it is not too bad (12 bytes per
loop, so is like 48Mb per million face). Feels like there is a way to
optimize it by utilizing knowledge that high-res mesh faces are created
in a specific order, but also feels it is not that important at this
moment.
Pull Request: https://projects.blender.org/blender/blender/pulls/144935
The main idea is to switch Bake from Multires from legacy DerivedMesh
to Subdiv. On the development side of things this change removes a lot
of code, also making it easier easier to rework CustomData and related
topics, without being pulled down by the DerivedMesh.
On the user level switch to Subdiv means:
- Much more closer handling of the multi-resolution data: the derived
mesh code was close, but not exactly the same when it comes to the
final look of mesh.
Other than less obvious cases (like old DerivedMesh approach doing
recursive subdivision instead of pushing subdivided vertices on the
limit surface) there are more obvious ones like difference in edge
creases, and non-supported vertex creases by the DerivedMesh.
- UV interpolation is done correctly now when baking to non-base level
(baking to multi-resolution level >= 1).
Previously in this case the old derived mesh interpolation was used
to interpolate face-varying data, which gives different results from
the OpenSubdiv interpolation.
- Ngon faces are properly supported now.
A possible remaining issue is the fact that getting normal from CCG
always uses smooth interpolation. Based on the code it always has been
the case, so while it is something to look into it might be considered
a separate topic to dig into.
* PROP_COLOR_GAMMA is sRGB, not display space
* Hex colors are always sRGB
* Image byte buffers are in byte_buffer.colorspace
Fixes for sequencer text, image painting, render stamp and tooltips.
The default display space is sRGB, so this change will not be noticed
in most files.
Ref #144911
Pull Request: https://projects.blender.org/blender/blender/pulls/144565
The crash is caused by libepoxy GL functions pointing to nullptrs.
libepoxy "Automatically initializes as new GL functions are used.",
so to call a function without a GL context bound, the function must
have been called before with a bound context.
This PR ensures there's a valid GL context bound for the whole
`WM_exit` scope.
(4.5 backport candidate)
Pull Request: https://projects.blender.org/blender/blender/pulls/144572
This PR contains the following incremental changes:
- Remove dead code of AO multires baker
- Use C++ primitives in multires baker (and cleanup some comments and naming)
- Remove unused bake user scale
Pull Request: https://projects.blender.org/blender/blender/pulls/143707
* Replace G.quiet by CLG_quiet_set/get
* CLOG_INFO_NOCHECK prints are now suppressed when quiet, these were
typically inside a if (!G.quiet) conditional already.
* Change some prints for blend files, color management and rendering to
use CLOG, that were previously using if (!G.quiet) printf().
Pull Request: https://projects.blender.org/blender/blender/pulls/143138
This patch moves the rules that alias Image to Combined for pass names
to the context implementations. This is because this only makes sense
for contexts that deal with passes, while it wouldn't make much sense
for other possible contexts like VSE modifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/143419
Use `BLI_strncpy_utf8` & `BLI_snprintf_utf8` for fixed size buffers in
DNA and screen data structures such as panels, menus & operators.
This could be considered a fix as copying a UTF8 string into a smaller
buffer without proper truncation can create an invalid UTF8 sequence.
However identifying which of these users are likely to run into would
be time consuming and not especially useful.
The compositor context has a number of pure virtual methods that could
be optional or removed altogether, so this patch refactors that by
reducing unnecessary pure virtual methods.
Pull Request: https://projects.blender.org/blender/blender/pulls/143091
This patch replaces the Composite node with the Group Output node as the
primary compositor output. The old node was removed and versioned. This
was done for consistency with Geometry Nodes and in preparation for more
generic use of the compositor in VSE modifiers, layered compositing, NPR
multi-stage compositing, and more.
The Group Output node relies on the node tree interface, so we now have
a default interface of a single input and a single output. For now, only
the first input is considered while the rest are ignored, just like the
Geometry Nodes design. Furthermore, the input is required to be of type
color. Warnings and errors are issues if any of those are not met, also
similar to Geometry Nodes.
This introduces a new limitation: Composite outputs can no longer exist
in node groups, since they obviously then act as their respective group
outputs.
A refactor for the compositor scheduler is needed to simplify the logic
after this change, but this will be done in a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/142232
Mistake in b19696c0b8
Don't reference the data from the `Array` which will just be the inline
buffer if `require_tangent` is false (for displacement baking).
I still observe a crash when multires baking, but that's deep in Cycles
code.
- Tangent calculation functions no longer use the CustomData struct as
an input and output.
- The "orco" and UV map calculations are exposed as separate API
functions to avoid a confusing internal choice between the two
- Redundancy in the API is removed, function names are clarified
- Code is moved to C++ namespace
- The "orco" case is clarified in the mesh draw tangent VBO extraction
- CD_TANGENT layers are not stored in CustomData anymore, so some of
that infrastructure is removed.
- Broken logic for caching tangents in CustomData is removed. That
hasn't worked for many years, if it every worked. We could investigate
adding caching again later if that's helpful.
Overall the change is motivated by the need to move away from CustomData
for #122398. But the changes should be a general improvement that makes
the code easier to understand either way.
Testing for this PR included using the default render UV in materials,
referencing specific UV tangents by name, using the spherical position-
based tangents in a material, and baking textures (multires and normal
baking).
Pull Request: https://projects.blender.org/blender/blender/pulls/141799
The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Add render category, which is automatically enabled when using -f or -a
command line flags for background rendering.
* Add extra logs to mention scene, view layer and frame ahead of time rather
than including it in every line.
* Remaining time was removed from Cycles, this will be added back for animations
at the render pipeline level.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
The crash seems to come from libepoxy GL functions pointing to null.
It seems that libepoxy "Automatically initializes as new GL functions are used."
and that to call a function without a GL context bound, the function
must have been called before with a bound context.
This just modifies the scope of the context binding from
DRW_module_exit to RE_engines_exit, which seems the safest solution
for 4.5.
Pull Request: https://projects.blender.org/blender/blender/pulls/141233
This PR adds several more built-in variables for path templates:
- `scene_name`: name of the current scene.
- `camera_name`: name of the current camera.
- `node_name`: only for paths owned by a node; the name of the node.
- `blend_name_lib`: name of the blend file of the ID the path property
is on, sans file extension.
- `blend_dir`: path up to (but not including) the currently open blend
file.
- `blend_dir_lib`: path up to (but not including) the blend file of the
ID the path property is on.
Additionally, adding support for `node_name` required re-thinking the
"path template type" system a bit:
Previously, the the `PropertyPathTemplateType` of a property completely
dictated what variables were made available to it. However, if we stuck
with that system then we would need to split
`PROP_VARIABLES_RENDER_OUTPUT` into two enum items: one for "normal"
render output paths like the one that lives on the `Scene`, and one for
"node" render output paths like the ones on the File Output node.
Instead of doing that, this PR makes `PropertyPathTemplateType` only
responsible for dictating the "purpose-specific" variables. In this
case, render-specific variables like fps, resolution, etc. Then the
availability of variables like `node_name` are instead based on what
owns the path (a node or not, in this case). There are also general
variables, like `blend_name`, that are now available to all path
templates.
(Part of #133001)
Pull Request: https://projects.blender.org/blender/blender/pulls/139438
Change the maximum data-block name from 64 to 256 bytes by increasing MAX_ID_NAME value.
Also increase a few related non-ID data name max size, essentially the action slots identifiers, as these are the primary key used to match an Action's slot to an ID by name.
Other sub-data (bones, modifiers, etc.) lengths are not modified here, as these can be made actual dynamic strings in the future, while keeping (a reasonable level of) forward compatibility, during the course of Blender 5 release cycles.
Implements #137608.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/137196
Previously `blend_name` was using the same path to get its file name
as `//` used. However, the choice of path for `//` seems to be
bespokely chosen at each call site. There may be a logic to it, but
if so it's not immediately clear what it is.
This PR changes `blend_name` to instead always use the currently open
("global") file path, making it well-defined and predictable for
users.
This also prepares better for PR #139438 for 5.0, which adds
`blend_name_lib`, which always uses the blend file that the ID owning
the path is linked from. Over-all this should be much more predictable
and controllable for users.
Pull Request: https://projects.blender.org/blender/blender/pulls/140474
This is replaced by geometry nodes, where volumes can now be generated from
point clouds and meshes with more control, and more efficient rendering as a
sparse volume.
No backwareds compatibility is provided, as this would be complicated, and
probably this feature was not used much in the past few years.
This node was supported in Cycles only, not by EEVEE.
Pull Request: https://projects.blender.org/blender/blender/pulls/140292
