Age | Commit message (Collapse) | Author |
|
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
|
|
* 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.
|
|
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
|
|
This is part of the effor to simplify the View struct in order to implement
multiview rendering.
The viewvecs can easilly be replace by projection matrix operation.
Even if slightly more complex, there is no performance impact.
|
|
|
|
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
|
|
Rewrite PBVH draw to allocate attributes into individual VBOs.
The old system tried to create a single VBO that could feed
every open viewport. This required uploading every color and
UV attribute to the viewport whether needed or not, often exceeding
the VBO limit.
This new system creates one VBO per attribute. Each attribute layout is
given its own GPU batch which is cached inside the owning PBVH node.
Notes:
* This is a full C++ rewrite. The old code is still there; ripping it out
can happen later.
* PBVH nodes now have a collection of batches, PBVHBatches, that keeps
track of all the batches inside the node.
* Batches are built exclusively from a list of attributes.
* Each attribute has its own VBO.
* Overlays, workbench and EEVEE can all have different attribute
layouts, each of which will get its own batch.
Reviewed by: Clement Foucault
Differential Revision: https://developer.blender.org/D15428
Ref D15428
|
|
|
|
This is required by the Metal backend to perform flushing of temporary objective-C resources. This is implemented as a global autoreleasepool, and is to ensure consistency such that all rendering operations, whether called via events, or via main loop will be within an autoreleasepool.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15900
|
|
name collision.
For the Metal shader translation support for shader-global uniforms are remapped via macro's, and in such cases where a uniform name matches a vertex attribute name, compilation errors will occur due to this injected syntax being incompatible with the immediate code.
Also adding source-level function interface alternatives where sized arrays are passed in. These are not supported directly in Metal shading language and are instead handled as pointers. These pointers require explicit address-space qualifiers in some cases, if device/constant address space memory is passed into the function.
Ref T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D15898
|
|
Metaball, curve, text, and surface objects use the geometry component
system to add evaluated mesh object instances to the dependency graph
"for render engine" iterator. Therefore it is unnecessary to process
those object types in these loops-- it would either be redundant work
or a no-op.
|
|
With the ultimate goal of simplifying drawing and evaluation,
this patch makes the following changes and removes code:
- Use `Mesh` instead of `DispList` for evaluated basis metaballs.
- Remove all `DispList` drawing code, which is now unused.
- Simplify code that converts evaluated metaballs to meshes.
- Store the evaluated mesh in the evaluated geometry set.
This has the following indirect benefits:
- Evaluated meshes from metaball objects can be used in geometry nodes.
- Renderers can ignore evaluated metaball objects completely
- Cycles rendering no longer has to convert to mesh from `DispList`.
- We get closer to removing `DispList` completely.
- Optimizations to mesh rendering will also apply to metaball objects.
The vertex normals on the evaluated mesh are technically invalid;
the regular calculation wouldn't reproduce them. Metaball objects
don't support modifiers though, so it shouldn't be a problem.
Eventually we can support per-vertex custom normals (T93551).
Differential Revision: https://developer.blender.org/D14593
|
|
allocation of MTLBuffer resources.
The memory manager includes both a GPUContext-local manager which allocates per-context resources such as Circular Scratch Buffers for temporary data such as uniform updates and resource staging, and a GPUContext-global memory manager which features a pooled memory allocator for efficient re-use of resources, to reduce CPU-overhead of frequent memory allocations.
These Memory Managers act as a simple interface for use by other Metal backend modules and to coordinate the lifetime of buffers, to ensure that GPU-resident resources are correctly tracked and freed when no longer in use.
Note: This also contains dependent DIFF changes from D15027, though these will be removed once D15027 lands.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D15277
|
|
|
|
This patch adds support for PBVH drawing in EEVEE.
Notes:
# PBVH_FACES only. For Multires we'll need an API to get/cache attributes. DynTopo support will be merged in later with sculpt-dev's DynTopo implementation.
# Supports vertex color and UV attributes only; other types can be added fairly easily though.
# Workbench only sends the active vertex color and UV layers to the GPU.
# Added a new draw engine API method, DRW_cdlayer_attr_aliases_add. Please review.
# The vertex format object is now stored in the pbvh.
Reviewed By: Clément Foucault & Brecht Van Lommel & Jeroen Bakker
Differential Revision: https://developer.blender.org/D13897
Ref D13897
|
|
Also add missing task-ID reference & remove colon after \note as it
doesn't render properly in doxygen.
|
|
Use num & count (for counters), in drawing code, see: T85728.
|
|
Extends the changes started in f31c3f8114616bb to completely separate
much of the DRW curves code from the particle hair drawing. In the short
term this increases duplication, but the idea is to simplify development
by making it easier to do larger changes to the new code, and the new
system will replace the particle hair at some point.
After this, only the shaders themselves are shared.
Differential Revision: https://developer.blender.org/D14699
|
|
in workbench_engine.c
|
|
- Verrtex paint mode has been refactored into C++ templates.
It now works with both byte and float colors and point
& corner attribute domains.
- There is a new API for mixing colors (also based
on C++ templates). Unlike the existing APIs byte
and float colors are interpolated identically.
Interpolation does happen in a squared rgb space,
this may be changed in the future.
- Vertex paint now uses the sculpt undo system.
Reviewed By: Brecht Van Lommel.
Differential Revision: https://developer.blender.org/D14179
Ref D14179
|
|
The "PROP" in the name reflects its generic status, and removing
"LOOP" makes sense because it is no longer associated with just
mesh face corners. In general the goal is to remove extra semantic
meaning from the custom data types.
|
|
|
|
This code was duplicated in multiple engines. Now it is the draw manager
responsability to manage the throwaway fluid textures.
|
|
Undefined behaviour for divergent control-flow fixes, replacement for partial vector references, and resolution of a number of calculation precision issues occuring on macOS.
Authored by Apple: Michael Parkin-White
Ref: T96261
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D14437
|
|
The GPU evaluation for curves will have to change significantly from the
current particle hair drawing code, due to its more general use cases
and support for more curve types. To simplify that process and avoid
introducing regressions for the rendering of hair particle systems,
this commit splits drawing functions for the curves object and
particle hair.
The changes are just inlining of functions and copying code
where necessary.
Differential Revision: https://developer.blender.org/D14576
|
|
- Missing star prefix.
- Unnecessary indentation.
- Blank line after dot-points
(otherwise doxygen merges with the previous dot-point).
- Use back-slash for doxygen commands.
- Correct spelling.
|
|
This patch adds color attributes to TexPaintSlot. This allows an easier selection
when painting color attributes.
Previously when selecting a paint tool the user had to start a stroke, before the
UI reflected the correct TexPaintSlot. Now when switching the slot the active
tool is checked and immediate the UI is drawn correctly.
In the future the canvas selector will also be used to select an image or image texture node
to paint on. Basic implementation has already been done inside this patch.
A limitation of this patch is that is isn't possible anymore to rename images directly from
the selection panel. This is currently allowed in master. But as CustomDataLayers
aren't ID fields and not owned by the material supporting this wouldn't be easy.
{F12953989}
In the future we should update the create slot operator to also include color attributes.
Sources could also be extended to use other areas of the object that use image textures
(particles, geom nodes, etc... ).
Reviewed By: brecht
Maniphest Tasks: T96709
Differential Revision: https://developer.blender.org/D14455
|
|
|
|
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
|
|
This avoid conflicting defines in GLSL
Fix T96998 Blender 3.2.0 Alpha crashes on startup
|
|
Add blank lines after file references to avoid them being interpreted as
doc-strings the following declarations.
|
|
Add ccl_gpu_kernel_postfix as a statement macro to prevent the following
declarations from being indented.
|
|
|
|
MSL does not have an implicit global scope, this is emulated via macro's adding an indirection for uniforms, attributes, shader stage inputs and outputs such as:
#define roughness shaderinst->roughness.
Variables in GLSL which exist within uniform blocks can be directly referenced via the global scope, unlike standard C++. This means that variable name pollution occurs if subsequent local variables in the code use the same name, resulting in compilation errors.
A number of these conflicting names have been renamed to ensure unique naming and no further scope pollution.
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14452
|
|
Metal shading language follows the C++ 14 standard and in some cases requires a greater level of explicitness than GLSL. There are also some small language differences:
- Explicit type-casts (C++ requirements)
- Explicit constant values (C++ requirements, e.g. floating point values using 0.0 instead of 0).
- Metal/OpenGL compatibility paths
- GLSL Function prototypes
- Explicit accessors for vector types when sampling textures.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14378
|
|
The constant M_PI_4 is added to GLSL to ensure it works there too.
Differential Revision: https://developer.blender.org/D14288
|
|
When rendering using the command line the curvature wasn't rendered. The reason
was that the ui_scale wasn't initialized and therefore the same pixels where
sampled to detect the curvature. This is fixed by setting the ui_scale to 1 for any
image render.
|
|
|
|
|
|
|
|
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
|
|
This avoid making include mistake and potentially detect areas that do
not really need common_view_lib.glsl.
|
|
|
|
Caused by rBf75449b5f2b04b79, which was missing a null check when
attempting to extract a `CustomData` pointer from an mesh that might
be null if the object isn't a mesh object. The commit added null checks
elsewhere, so simply adding them here is a straightforward fix.
Fixes T95526, T95539
|
|
This is then easier to include in other modules.
|
|
|
|
The check for existence of custom data layers did not take wrapper nature of
mesh into account.
Quickest and safest for 3.1 solution is to take care of branching of checks
in the draw manager.
Ideally both wrapper and mesh access will happen via the same public API
without branching in the "user" code. That is something outside of the fix
for the coming release though.
Differential Revision: https://developer.blender.org/D14013
|