| Age | Commit message (Collapse) | Author |
|---|
|
Explicit constructor for mat3 from a mat4 is not valid and cannot be overloaded.
Adding explicit texture resource type flags for depth textures. This is an explicit requirement for Metal Shading language. This is a temporary compatibility, as this path is already supported in GPU_SHADER_CREATE_INFO under ImageType::DEPTH_2D, though required in shader source for MSL shaders which do not have create info.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14418
|
|
This should have no regression.
|
|
|
|
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
|
|
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D14306
|
|
An alpha component can be specified for an object's color. This adds an alpha
socket to the object info shader node allowing for the alpha component of the
object's color to be accessed in the shader editor.
Differential Revision: https://developer.blender.org/D14141
|
|
This avoid potential shader recompilation and is more in line
with vulkan design.
|
|
|
|
|
|
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
|
|
A Bump node without a Height input is meaningless and does nothing.
As such, it is available as an old workaround that allows making Node
Group inputs that default to normal when not connected, by routing
via a no-op Bump node before doing math.
Cycles specifically recognizes this use case and either bypasses
the node, or converts it into a Geometry Normal node, but Eevee
was still evaluating it as usual. That incurred performance cost,
and also normalized the vector unlike Cycles.
This implements the same bypass logic for Eevee. Since I'm not
sure if it's possible to totally remove the node at this stage,
it emits a no-op function call to copy the input vector.
Differential Revision: https://developer.blender.org/D14045
|
|
This was caused by macros interpreted as recursive. Workaround by
not using macros at all and just define local variables which
hopefully will be optimized.
|
|
|
|
Missing include statements of the gpu_shader_colorspace_lib.glsl in
various shaders ignored the target texture color space.
|
|
|
|
This is too much impractical and offers no real benefit.
|
|
With (center) position, radius and random value outputs.
Eevee does not yet support rendering point clouds, but an untested
implementation of this node was added for when it does.
Ref T92573
|
|
When adding the shader create infos some additional resources where defined
that doesn't exist in the shader itself. This commit will remove them.
|
|
This adds vertex creasing support for OpenSubDiv for modeling, rendering,
Alembic and USD I/O.
For modeling, vertex creasing follows the edge creasing implementation with an
operator accessible through the Vertex menu in Edit Mode, and some parameter in
the properties panel. The option in the Subsurf and Multires to use edge
creasing also affects vertex creasing.
The vertex crease data is stored as a CustomData layer, unlike edge creases
which for now are stored in `MEdge`, but will in the future also be moved to
a `CustomData` layer. See comments for details on the difference in behavior
for the `CD_CREASE` layer between egdes and vertices.
For Cycles this adds sockets on the Mesh node to hold data about which vertices
are creased (one socket for the indices, one for the weigths).
Viewport rendering of vertex creasing reuses the same color scheme as for edges
and creased vertices are drawn bigger than uncreased vertices.
For Alembic and USD, vertex crease support follows the edge crease
implementation, they are always read, but only exported if a `Subsurf` modifier
is present on the Mesh.
Reviewed By: brecht, fclem, sergey, sybren, campbellbarton
Differential Revision: https://developer.blender.org/D10145
|
|
|
|
This merge the description into one struct only that can be more easily
copied during `finalize()`.
The in and out layout parameters are better named and extended with the
invocation count (with fallback support)
|
|
Route cause was data alignment mismatch between GPU and CPU. This
mismatch would not allow us to bind the UBO where data wasn't available
on the GPU.
Fixed by using float4 in stead of float2. This could eventually be
packed, but that would lead to less readable code.
|
|
Cause of the issue isn't that clear, but the NVIDIA GLSL compiler
complained that it couldn't find an overloaded function when the second
parameter is an interger. This change fixes it by using a float.
|
|
This patch converts GPU_SHADER_2D_IMAGE_MULTI_RECT_COLOR shader to use
the GPUShaderCreateInfo pattern. It can be used as a reference when
converting other shaders.
In this special case the flat uniform vector cannot be used anymore as it
doesn't fit as push constants. To solve this a uniform buffer is used.
|
|
|
|
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
|
|
Shader isn't used and not accessible via py-api.
|
|
Shader isn't used and not accessible via py-api.
|
|
Shader isn't used and not accessible via the py-api.
|
|
Shader isn't used and isn't accessible via py-api.
|
|
|
|
|
|
This replaces lost functionality from the old GN Attribute Map Range node.
This also adds vector support to the shader version of the node.
Notes:
This breaks forward compatibility as this node now uses data storage.
Reviewed By: HooglyBoogly, brecht
Differential Revision: https://developer.blender.org/D12760
|
|
with the CPU and GPU
When rendering volume surfaces in unbounded worlds the volume stepping can produce large values. If used with a magic texture node the values can results in a Inf float which when used in a sin or cos produces a NaN.
To fix this the input values are mapped into the periodic range of the sin and cos functions (-2*PI 2*PI) this stops the possibility of a Inf occurring and thus the NaN. It also improves the accuracy and smoothness of the result due to loss of precision when large values are summed with smaller ones effectively removing the parts of the smaller number (i.e. those in the -2PI to 2PI range) that result in variation of the output of sin and cos.
Reviewed By: brecht
Maniphest Tasks: T92036
Differential Revision: https://developer.blender.org/D12821
|
|
|
|
Issue introduced in {7e66616b7e15} where the shader was replaced with a
2d image shader. This patch reverts several commits that removed the 3d
image shader.
|
|
We run into float precision issues here, clamp the number of octaves to
one less, which has little to no visual difference. This was empirically
determined to work up to 16 before, but with additional inputs like
roughness only 15 appears to work.
Also adds misisng clamp for the geometry nodes implementation.
|
|
|
|
This patch includes code from D9891 and D12754, so credit goes to Juanfran and Dalai.
I updated the patches to work with `master` and with the new overlay toggle.
The reason to include both changes as part of one patch is that the dimmed dashed lines work much better together with colored wires.
Theme setting for dash opacity:
{F11370574, size=full}
{F11286177, size=full, autoplay, loop}
{F11149912, size=full}
For adding the overlay I used `SpaceImageOverlay` as reference, although I'm not familiar with this code so there might be mistakes.
Reviewed By: #user_interface, HooglyBoogly
Differential Revision: https://developer.blender.org/D12886
|
|
This was due to the shading evaluation being outdated inside the ShaderToRGBA
glsl code.
|
|
No functional change, just cleaning up the shader code a bit.
Part of this is removing dead code (the discard was never called), and
part is shuffling mix/max around based on feedback by Sybren Stüvel.
|
|
Replacement for float curve in legacy Attribute Curve Map node.
Float Curve defaults to [0.0-1.0] range.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D12683
|
|
Use dashes to represent the function flow (while keeping continuous
lines for the data-flow).
It is important to tell both flows apart (the data and the function
flow). The sockets help with that, the noodles help this further.
The "data flow" is evaluated at every single node. A user can inspect
the output sockets of those nodes and have a glimpse at their values.
The "function flow" (nodes) however is only evaluated in the geometry
nodes. The noodles are not transporting data in the same sense of the
"data flow". All that can be inspected are the attributes the functions
depend on.
Having this clearly communicated should help users to inspect the
nodetrees, read and understand the different flows in the same tree.
---
Known limitations:
At the moment the dash lines are not equidistant:
* It would be nice to get the "uv.x" to be resampled for the bezier curve
so the dashes are equally distributed in the curve.
* Using distance between the P3 and P0 instead of the real bezier curve
length seems to be fine.
---
Full disclaimer:
Changes with that much of a visual impact tend to be controversial. So
far the main feedback is that dashed lines can be associated to broken
link, and that there are better ways to represent the flows (or
different information that should be visually represented).
I'm fully aware of that. However dashed lines are already used in the
viewport and outliner to indicate (hierarchical) relation. Besides,
other approaches (double-lines, having the data flow to be more
distinct, ...) didn't pan out in the end (or didn't look as good as
this).
---
Impact in other editors:
The compositor uses mostly a "data flow" nodetree, so no change is
expected there.
The shader nodetree is one that could but doesn't have to change its
visual language.
The shader nodetree uses mostly "function flow" with some "data flow" nodes.
One can argue that it should be adapted to follow the
same pattern as geometry nodes (with the new noodles and the diamond
sockets). Oh the other hand, a shader nodetree has a single context.
When a node depends on the "UV", there is only one UV at a time for the
entire nodetree. So it can also be treated as a psedo "data flow"
nodetree if we want to avoid too many changes in other parts of Blender.
Differential Revision: https://developer.blender.org/D12602
|
|
This makes it easier to spot which links contain fields and which
contain data. Actually, the patch makes all other links a bit thicker.
However, with soon-to-be-implemented theme changes, the
perceived thickness will be the same as before.
This is part of T91563.
Differential Revision: https://developer.blender.org/D12646
|
|
Previously, it was a diamond shape when the overall
shape was a diamond.
|
|
Goal is to add the length attribute to the Hair Info node, for better control over color gradients or similar along the hair.
Reviewed By: #eevee_viewport, brecht
Differential Revision: https://developer.blender.org/D10481
|
|
No functional change.
The shader is complicated by itself, having hardcoded values makes it
even more cryptic.
I also renamed the shader because the shader is not for the keyfarme diamond only,
but for all the keyframe shapes.
Differential Revision: https://developer.blender.org/D12615
|
