| Age | Commit message (Collapse) | Author |
|---|
|
In normal conditions, `gpf` always has a value, but better move inside the NULL checking.
|
|
This reverts commit edee5a947b7ea3e1324aa334a22c7c9bbf47f5f7.
Fixes compilation error (Missing file BLI_float2.hh)
|
|
This reverts commit 8fb2ff458ba579dba08bfdf57d043ad158b5db07.
Missing some files.
|
|
This is a first part of the Shader Create Info system could be.
A shader create info provides a way to define shader structure, resources
and interfaces. This makes for a quick way to provide backend agnostic
binding informations while also making shader variations easy to declare.
- Clear source input (only one file). Cleans up the GPU api since we can create a
shader from one descriptor
- Resources and interfaces are generated by the backend (much simpler than parsing).
- Bindings are explicit from position in the array.
- GPUShaderInterface becomes a trivial translation of enums and string copy.
- No external dependency to third party lib.
- Cleaner code, less fragmentation of resources in several libs.
- Easy to modify / extend at runtime.
- no parser involve, very easy to code.
- Does not hold any data, can be static and kept on disc.
- Could hold precompiled bytecode for static shaders.
This also includes a new global dependency system.
GLSL shaders can include other sources by using #pragma BLENDER_REQUIRE(...).
This patch already migrated several builtin shaders. Other shaders should be migrated
one at a time, and could be done inside master.
There is a new compile directive `WITH_GPU_SHADER_BUILDER` this is an optional
directive for linting shaders to increase turn around time.
What is remaining:
- pyGPU API {T94975}
- Migration of other shaders. This could be a community effort.
Reviewed By: jbakker
Maniphest Tasks: T94975
Differential Revision: https://developer.blender.org/D13360
|
|
When paste new frames, the datablock need to be tagged to update the drawings.
|
|
When a new frame is created, ensure the keytype of source key is used.
|
|
Also ensure space at end of comment.
|
|
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
|
|
This reverts commit e339946515b00bc230bad2ec52a729dd914a8af3.
This broken the tablet pressure and it was impossible to set a proper strength.
|
|
Don't need check minimum constant value, brush value is enough.
|
|
There was a clamp with a value greater than 0.
|
|
The problem was the points were selected in edit mode and then sampled. Now, in draw mode, the points are always unselected to avoid this effect in the auto merge process.
|
|
The smooth was not working "smoothly" and any change in the factor produced a weird result.
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
|
|
The problem was the stroke was added to head and the `prev` pointer was NULL. Now check if there is the list is empty`next`.
|
|
This is part of T94439
|
|
This fix avoid the segment fault for several operators.
|
|
|
|
|
|
Fixes many instances of `-Wstringop-overread` warning on GCC 11
Differential Revision: https://developer.blender.org/D13672
|
|
Differential Revision: https://developer.blender.org/D12962
|
|
The problem was the number of points for each edge of the box was wrong and the wheelmouse effect was anulated.
Also fixed the value displayed in the status bar to keep consistency with subdivision value.
Reviewed By: lichtwerk
Maniphest Tasks: T93999
Differential Revision: https://developer.blender.org/D1363
|
|
The eraser checks the current, previous and next point (and sets pc0,
pc1 & pc2 corresponding to that for futher occlusion/brush/clipping
checks). For the very first point, it sets pc0 to pc1 [which makes sense,
there is no previous point, so we should assume the previous segment is
"visible" as soon as the first point is], but does so *before* pc1 is
even calculated. This makes following occlusion/brush/clipping checks
work with zero values [which leads to no earsing in most cases].
Now *first* calculate pc1, *then* set pc0 to pc1.
Maniphest Tasks: T94137
Differential Revision: https://developer.blender.org/D13593
|
|
Renamed or removed parameters which no longer exist.
|
|
Also add groups in some files.
|
|
his new modifier is equals to the existing mesh modifier but adapted to grease pencil.
The underlying functions used to calculate the shrink are the same used in meshes.
{F11794101}
Reviewed By: pepeland, HooglyBoogly
Differential Revision: https://developer.blender.org/D13192
|
|
Caused by {rB3b6ee8cee708}
The raw data is copied here correctly
[`BKE_gpencil_stroke_weights_duplicate` in
`BKE_gpencil_stroke_duplicate`] but the vertex groups names are missing.
Prior to above commit is was enough to have `ED_object_add_duplicate`
(this seemingly took care of duplicating object's defbase).
Now vertex groups names sit on the `bGPdata` rather than the `Object`,
and since the separate operation creates **new** `bGPdata` we have to
copy vertex groups names - and active index - over [via
`BKE_defgroup_copy_list`].
Maniphest Tasks: T93728
Differential Revision: https://developer.blender.org/D13509
|
|
Ref T92709
|
|
These existing names were unhelpful at best, actively confusing at
worst. This patch renames them to be consistent with the terms
used to refer to the values in the UI.
- `width` -> `offset`
- `ext1` -> `extrude`
- `ext2` -> `bevel_radius`
Differential Revision: https://developer.blender.org/D9627
|
|
Caused by {rBaa0ac0035a0d}.
Similar solution to {rBc0fdaf700a5}.
|
|
Bug introduced in {rBaa0ac0035a0d}.
The invalid depth fallback was changed to `FLT_MAX` in order to match the
annotation and gpencil operations.
This broke the `Interactive Light Track` operator which invalidates the
operation if the depth value is `1.0f`.
The chosen solution was to change the value tested in the annotation and
gpencil operations.
|
|
- When and is used in labels use ampsand
- When used in description use 'and'
|
|
When cut an stroke using the option Flat Caps, the falt was not done if the cut was done in the middle of the stroke.
Now the flat is applied to the segments created and also some cleanup of the code done.
|
|
This new option allows to combine all layers in the active one. Also the merge down option has been improved.
Reviewed By: mendio, pablo vazquez (UI)
Differential Revision: https://developer.blender.org/D13054
|
|
Issue seen when setting `Stroke Placement` of type `Stroke`.
Regression introduced in {rBaa0ac0035a0d3601672a0c732e3f8f932a36fc04}.
|
|
Operations such as erasing with occlusion and drawing on the surface
require reading the depth buffer.
However, this is being done with minimal efficiency.
Currently, to read the depth corresponding to each point of the new stroke,
a ReadPixel is called to send a message to the GPU and read the depth of
the corresponding pixel in the VRAM.
The communication between GPU and CPU is known to be a slow operation so
it is good to be avoided.
Therefore, save the entire depth buffer in a cache to be read directly
from the RAM.
(Also the `ED_view3d_autodist_depth` and `ED_view3d_autodist_depth_seg` have
been removed since they are no longer used).
Reviewed By: antoniov, fclem
Differential Revision: https://developer.blender.org/D10894
|
|
`pt0` was read when `NULL` and `is_occluded_pt1` could be read even if
it is not initialized.
|
|
|
|
Use arrays for wmEvent coordinates, this quiets warnings with GCC11.
- `x, y` -> `xy`.
- `prevx, prevy` -> `prev_xy`.
- `prevclickx, prevclicky` -> `prev_click_xy`.
There is still some cleanup such as using `copy_v2_v2_int()`,
this can be done separately.
Reviewed By: campbellbarton, Severin
Ref D12901
|
|
|
|
Pencil
Not naming the auto-generated vertexgroup after the selected bone was
just confusing (since the group would not have an effect), so now use
similar code that is used for meshes for greasepencil as well.
Maniphest Tasks: T92314
Differential Revision: https://developer.blender.org/D12906
|
|
By argument naming and convention this is the intended argument order.
|
|
Move runtime parameters out of context creation.
Not being able to choose another region and v3d limits the use of the
snap API.
|
|
- Drawing annotations used a deprecated value to detect
if drawing was supported.
- ED_space_sequencer_check_show_strip was checking the preview
image type (which doesn't impact strip display).
Signed-off-by: Campbell Barton <ideasman42@gmail.com>
|
|
The Paint operator only works in SPACE_VIEW3D and this is checked in the poll mtehod, so it's not logic check again.
These checkings were part of the old grease pencil but it was not removed.
|
|
The function was not doing anything and only was calling another function.
|
