Properly initialize clump curve mapping tables for duplis and other cases
where this was missed by making a generic init/free function instead of
duplicating the same logic in multiple places. Also fold lattice deform
init into this.
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
The goal is to improve clarity and readability, without
introducing big design changes.
Follows the recent obmat to object_to_world refactor: the
similar naming is used, and it is a run-time only rename,
meaning, there is no affect on .blend files.
This patch does not touch the redundant inversions. Those
can be removed in almost (if not all) cases, but it would
be the best to do it as a separate change.
Differential Revision: https://developer.blender.org/D16367
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
This was because `stroke_id` was not using `vertex_start`.
But since `vertex_start` is not 1 based like it used to be, we need to add
1 to it to avoid a fragment depth of `0.0` which would be equal to the
background and not render.
This allows using drawcalls with non default vertex range.
These calls will be culled like any other instance by the GPU culling
pipeline. But they will not be batched together since the vertex range
is part of the group.
* External engines do not use the PBVH and need slower depsgraph updates.
* Final depsgraph tag after stroke finishes was missing for sculpt color
painting, caused missing updates for other viewports as well as any
modifiers or nodes on other objects using the colors.
This change the attribute binding scheme to something similar to the
curves objects. Attributes are now buffer textures sampled per points.
The actual geometry is now rendered using an index buffer that avoid too
many vertex shader invocation.
Drawcall is wrapped in a DRW function to reduce complexity of future
changes.
In T93382, the problem was that the Blender-side rendering code was
still generating the subsurface passes because the old render pass
flags were set, even though Cycles doesn't generate them anymore.
After a closer look, it turns out that the entire hardcoded pass
creation code can be removed. We already have an Engine API function
to query the list of render passes from the engine, so we might as
well just call that and create the returned passes.
Turns out that Eevee already did this anyways. On the Cycles side, it
allows to deduplicate a lot of `BlenderSync::sync_render_passes`.
Before, passes were defined in engine.py and in sync.cpp. Now, all
passes that engine.py returns are created automatically, so sync.cpp
only needs to handle a few special cases.
I'm not really concerned about affecting external renderer addons,
since they already needed to handle the old "builtin passes" in
their Engine API implementation anyways to make them show up in the
compositor. So, unless they missed that for like 10 releases, they
should not notice any difference.
Differential Revision: https://developer.blender.org/D16295
MTLBatch and MTLDrawList implementation enables use of Metal Viewport for UI and Workbench. Includes Vertex descriptor caching and SSBO Vertex Fetch mode draw call submission.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D16101
color uniform assignment needing to be changed to ucolor was missed.
Ref T101445
Reviewed By: fclem
Maniphest Tasks: T101445
Differential Revision: https://developer.blender.org/D16236
Problem here was that layer_collection_objects_sync wasn't called when
the holdout property is updated due to frame change, so the changed
visibility flag was never applied to ob->base_flag.
Turns out there's no real reason to handle the per-object holdout
property through the layer system. So, instead of merging both the
layer holdout and object holdout into base_flag and checking that
from the render engines, only handle the layer holdout (which can't
be animated, so no issue here) through base_flag and explicitly also
check the object holdout in the render engines.
Turns out PBVH drawing and normal mesh batches are not mutually
exclusive inside the draw cache; there are edge cases with modifiers
and instancing where you need both, and forcing one or the other
inside this function leads to memory corruption.
This commit replaces the `Mesh_Runtime` struct embedded in `Mesh`
with `blender::bke::MeshRuntime`. This has quite a few benefits:
- It's possible to use C++ types like `std::mutex`, `Array`,
`BitVector`, etc. more easily
- Meshes saved in files are slightly smaller
- Copying and writing meshes is a bit more obvious without
clearing of runtime data, etc.
The first is by far the most important. It will allows us to avoid a
bunch of manual memory management boilerplate that is error-prone and
annoying. It should also simplify future CoW improvements for runtime
data.
This patch doesn't change anything besides changing `mesh.runtime.data`
to `mesh.runtime->data`. The cleanups above will happen separately.
Differential Revision: https://developer.blender.org/D16180
Allows improving performance with BLI_task.hh in draw extraction code.
Threading added in c15a63d21e improved performance by 3-4x
for me, but didn't make a difference until now.
