| Age | Commit message (Collapse) | Author |
|---|
|
Currently there are many function declarations in `BKE_node.h` that
don't actually have implementations in blenkernel. This commit moves
the declarations to `NOD_composite.h`, `NOD_texture.h`, and
`NOD_shader.h` instead. This helps to clarify the purpose of the
different modules.
Differential Revision: https://developer.blender.org/D13869
|
|
|
|
|
|
|
|
|
|
This significantly reduces discontinuities on UV seams, by giving a better
match of the texture filtered colors on both sides of the seam. It works by
using pixels from adjacent faces across the UV seam.
This new option is called "Adjacent Faces" and is the default. The old option
is called "Extend", and extends border pixels outwards.
Differential Revision: https://developer.blender.org/D13303
|
|
Also ensure space at end of comment.
|
|
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
|
|
Includes unwanted changes
This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
|
|
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
|
|
Reverted because the commit removes a lot of commits.
This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
|
|
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
|
|
|
|
Note that some functions have been copied between these files.
De-duplication isn't trivial as there are differences in some functions.
|
|
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
|
|
Delay grease pencil for until after the render result is written
to the Blender side.
Differential Revision: https://developer.blender.org/D13740
|
|
When tiled rendering was used the render result was
allocated at the end of every view layer render as
opposite of an intended end of all rendering.
Modify the render_result_end so that it only ensures
pixels are allocated if pixels are actually copied
over.
|
|
|
|
Goals of this refactor:
* More unified approach to updating everything that needs to be updated
after a change in a node tree.
* The updates should happen in the correct order and quadratic or worse
algorithms should be avoided.
* Improve detection of changes to the output to avoid tagging the depsgraph
when it's not necessary.
* Move towards a more declarative style of defining nodes by having a
more centralized update procedure.
The refactor consists of two main parts:
* Node tree tagging and update refactor.
* Generally, when changes are done to a node tree, it is tagged dirty
until a global update function is called that updates everything in
the correct order.
* The tagging is more fine-grained compared to before, to allow for more
precise depsgraph update tagging.
* Depsgraph changes.
* The shading specific depsgraph node for node trees as been removed.
* Instead, there is a new `NTREE_OUTPUT` depsgrap node, which is only
tagged when the output of the node tree changed (e.g. the Group Output
or Material Output node).
* The copy-on-write relation from node trees to the data block they are
embedded in is now non-flushing. This avoids e.g. triggering a material
update after the shader node tree changed in unrelated ways. Instead
the material has a flushing relation to the new `NTREE_OUTPUT` node now.
* The depsgraph no longer reports data block changes through to cycles
through `Depsgraph.updates` when only the node tree changed in ways
that do not affect the output.
Avoiding unnecessary updates seems to work well for geometry nodes and cycles.
The situation is a bit worse when there are drivers on the node tree, but that
could potentially be improved separately in the future.
Avoiding updates in eevee and the compositor is more tricky, but also less urgent.
* Eevee updates are triggered by calling `DRW_notify_view_update` in
`ED_render_view3d_update` indirectly from `DEG_editors_update`.
* Compositor updates are triggered by `ED_node_composite_job` in `node_area_refresh`.
This is triggered by calling `ED_area_tag_refresh` in `node_area_listener`.
Removing updates always has the risk of breaking some dependency that no
one was aware of. It's not unlikely that this will happen here as well. Adding
back missing updates should be quite a bit easier than getting rid of
unnecessary updates though.
Differential Revision: https://developer.blender.org/D13246
|
|
|
|
Also add groups in some files.
|
|
Ref T92709
|
|
This included is needed for the `ATTR_NONNULL` macro used in the header.
As found in a recent c --> c++ if the includes get ordered in a different order
this could result in an error.
Re commits rBc20098e6ec6adee874a12e510aa4a56d89f92838
|
|
This reverts to following commits:
* rB5cad004d716da02f511bd34983ac7da820308676
* rB97e3a2d935ba9b21b127eda7ca104d4bcf4e48bd
* rBf60b95b5320f8d6abe6a629fe8fc4f1b94d0d91c
* rB0bd3cad04edf4bf9b9d3b1353f955534aa5e6740
* rBf72cc47d8edf849af98e196f721022bacf86a5e7
* rB3f7014ecc9d523997062eadd62888af5fc70a2b6
* rB0578921063fbb081239439062215f2538a31af4b
* rBc20098e6ec6adee874a12e510aa4a56d89f92838
* rBd5efda72f501ad95679d7ac554086a1fb18c1ac0
The original move to c++ that the other commits depended upon had some issues
that should be fixed before committing it again. The issues were reported in
T93797, T93809 and T93798.
We should also find a better rule for not using c-style casts going forward,
although that wouldn't have been reason enough to revert the commits.
Introducing something like a `MEM_new<T>` and `MEM_delete<T>`
function might help with the the most common case of casting the return
type of `MEM_malloc`.
Going forward, I recommend first committing the changes that don't
require converting files to c++. Then convert the shading node files
in smaller chunks. Especially don't mix fairly low risk changes like
moving some simple nodes, with higher risk changes.
|
|
Fixes compilation errors after rBd5efda72f501
Re sorted some includes.
|
|
|
|
|
|
In previous Blender version the tile highlight was stored in the
full frame (un-cropped) space. This was changed with the Cycles X
development and now the tiles and render result are always measured
relative to the cropped region.
Differential Revision: https://developer.blender.org/D12779
|
|
|
|
Previously we would only free animation strip data when doing final
renders. If not doing a final render or simply just playing back videos
in the VSE, we would not free decoders or non VSE cache data from the
strips.
This would lead to memory usage exploding in complex VSE scenes.
Now we instead use the dumb apporach of freeing everything that is not
currently visible.
|
|
|
|
|
|
The related issue which is fixed by this change is the missing noisy
image pass when denoising and border render is used,
Need to allocate passes after the passes has been copied from the
original render result.
|
|
Previously this was only loading built-in render passes. Now instead of trying
to load the scene render passes, load whatever passes exist in the cache file.
|
|
|
|
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
|
|
Caused by the lazily pass pixels allocation which didn't reset
allocation state of the render result.
Demo file: XXX
|
|
Need to ensure render result's pixels are allocated prior to merge.
Differential Revision: https://developer.blender.org/D12371
|
|
Caused by lazy allocation of passes.
|
|
Run into it when was re-working tiles in the Cycles X project.
Make sure the storage of highlighted tiles is emptied when the
render is finished or cancelled).
The error is only possible to happen if the engine did not do
something correct, but is still good to deal with such situations
more gracefully.
|
|
|
|
Should be no visible change on user side.
Preparing for render parts removal as part of Cycles X project.
Differential Revision: https://developer.blender.org/D12317
|
|
The idea is to only allocate pixel storage only when there is an actual
data to be written to them.
This moves the code forward a better support of high-res rendering when
pixel storage is not allocated until render engine is ready to provide
pixel data.
Is expected to be no functional changes for neither users no external
engines. The only difference is that the motion and depth passes will
be displayed as transparent for until render engine provides any tile
result (at which point the pixels will be allocated and initialized to
infinite depth).
Differential Revision: https://developer.blender.org/D12195
|
|
This patch exposes the Cycles Alembic Procedural through the MeshSequenceCache
modifier in order to use and test it from Blender.
To enable it, one has to switch the render feature set to experimental and
activate the Procedural in the modifier. An Alembic Procedural is then
created for each CacheFile from Blender set to use the Procedural, and each
Blender object having a MeshSequenceCache modifier is added to list of objects
of the right procedural.
The procedural's parameters derive from the CacheFile's properties which are
already exposed in the UI through the modifier, although more Cycles specific
options might be added in the future.
As there is currently no cache controls and since we load all the data at the
beginning of the render session, the procedural is only available during
viewport renders at the moment. When an Alembic procedural is rendered, data
from the archive are not read on the Blender side.
If a Cycles render is not active and the CacheFile is set to use the Cycles Procedural,
bounding boxes are used to display the objects in the scene as a signal that the
objects are not processed by Blender anymore. This is standard in other DCCs.
However this does not reduce the memory usage from Blender as the Alembic data
was already loaded either during an import or during a .blend file read.
This is mostly a hack to test the Cycles Alembic procedural until we have a
better Blender side mechanism for letting renderers load their own geometry,
which will be based on import and export settings on Collections (T68933).
Ref T79174, D3089
Reviewed By: brecht, sybren
Maniphest Tasks: T79174
Differential Revision: https://developer.blender.org/D10197
|
|
|
|
|
|
These should have been removed earlier but were forgotten.
|
|
|
