Age | Commit message (Collapse) | Author |
|
|
|
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
|
|
|
|
Make sure non-camera data is not casted to a Camera pointer.
Solution suggested by Damien Picard (@pioverfour).
|
|
Use the node topology cache and avoid modifying the node tree
in a non-threadsafe way to improve the predictability of using
the helper function. Replaces the implementation from
e0d40471364aafca967b6ebd52.
|
|
Since these values are only ever 0/1, use bool type.
|
|
Currently there are both "EDGERENDER" and "EDGEDRAW" flags, which are
almost always used together. Both are runtime data and not exposed to
RNA, used to skip drawing some edges after the subdivision surface
modifier. The render flag is a relic of the Blender internal renderer.
This commit removes the render flag and replaces its uses with the
draw flag.
|
|
This patch introduces the concept of a Cached Resource that can be
cached across compositor evaluations as well as used by multiple
operations in the same evaluation. Additionally, this patch implements a
new structure for the realtime compositor, the Static Cache Manager,
that manages all the cached resources and deletes them when they are no
longer needed.
This improves responsiveness while adjusting compositor node trees and
also conserves memory usage.
Differential Revision: https://developer.blender.org/D16357
Reviewed By: Clement Foucault
|
|
Error introduced by rB3c39a3affee7.
|
|
|
|
This issue might have produced crashes in some cases similar to
rBafd30e5e3a77.
|
|
|
|
|
|
This moves the implementation from the View to the draw manager itself.
However, this is not its final place and should be moved to the shader
create info at some point in the future.
For now it is not possible because of possible interaction with the
old draw manager codebase.
|
|
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 is a convenience when one needs to often change the current framebuffer
and avoid the overhead of creating many Main/Simple passes.
|
|
Was caused by uvs not being sourced from the correct buffer.
|
|
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.
|
|
Note: Still need to fix PBVH_BMESH.
|
|
|
|
These are unecessary now that we can bind buffers as textures directly.
|
|
Was caused by an extra point per stroke being drawn.
|
|
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.
|
|
This was caused by a wrongly sized vertex buffer for the stroke buffer.
|
|
For some reason stroke_id needs to be the triangle index, not the vertex
index.
|
|
Vertex indexing has not been updated and stroke_start usage was wrong.
Update all `stroke_start` usage.
|
|
`vert_len` was being shadowed and index_min & max wasn't correctly set.
|
|
|
|
Batching was broken / disabled and starting indices were wrong.
|
|
|
|
This allows using instancing in other ways, like resources indexing.
|
|
|
|
This fixes some firefly issues on corners of the cubemaps where the
blending factors would go above 1 or below 0.
|
|
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
|
|
This is an attempt to remove a driver bug.
|
|
objects
Move the material resources binding inside the
`DRW_shgroup_curves_create_sub` so that `DRW_shgroup_call_no_cull`
extracts the attributes.
|
|
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.
|
|
tmp
|
|
- Remove unused include
- Avoid repeating blender:: namespace
- Remove timer left in by mistake in previous commit
|
|
On a Ryzen 3700x I observed a 4ms improvement (from 5ms to 1ms)
on every redraw when sculpting with 88000 curves.
|