This commit adds the "is volume scatter" output to the light path node
in the shader editor.
All the funcitonal code for this feature already exists in Cycles SVM
and OSL, but the output wasn't exposed on the node.
EEVEE does not support the feature, so it's output will
always be zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/134343
User may think of the `radius` vector value as RGB color, however it's
meant to be the depth of scattering for R/G/B channels. Now clarified in
the desctiption.
Pull Request: https://projects.blender.org/blender/blender/pulls/134088
Fairly weird, debug builds were fine, but release ones with clang 19
and mold failed at linking step, complaining about misisng
`bNode::output_sockets()` symbol.
Guess debug config somehow pulls this symbol from somewhere else?
This bug occurs when the user deletes the rightmost stop on a
color ramp with 2 stops. After doing this, the color ramp appears
to stop updating its results.
This bug is due to a shader optimization for color ramps. For ramps
with 2 stops or less, the first and second stops are hardcoded as
inputs to get the results of the color ramp. When deleting the
rightmost stop, the stop's data isn't actually changed. The ramp
just updates its total stop number. Because of this, the result of
the color ramp won't change.
This is fixed by only allowing this optimization when a ramp has
exactly 2 stops. This solution works well since it keeps color ramp
code neat and concise. It also makes more logical sense to only allow
this optimization to work with 2 stops since it uses 2 hardcoded values
from the color ramp. It's also unlikely this will lead to adverse
performance problems since it doesn't make sense to use a color ramp
with 1 color stop. In that case, the user should just use an RGB node.
Another possible solution for this problem would be to update the data
for the second stop in the color ramp to exactly match the first when
deleting the second stop. However, this is undesirable since the code
wouldn't make much sense to those who don't know about the color ramp
optimizations.
Pull Request: https://projects.blender.org/blender/blender/pulls/132951
Color to grayscale conversions should take into account the colorspace,
and these are considered to be in scene linear colorspace.
Note the RBG to BW node implementation is used for implicit conversions,
so that is covered as well.
No change with the default configuration.
Pull Request: https://projects.blender.org/blender/blender/pulls/133368
Use BLI_uniquename_cb to check and fix naming conflicts, and keep track
of the potentially modified node names in a map.
Reserve the material name, so that later the output node can be renamed to it
without conflicts. Also make sure there are no conflicts with names auto
generated by MaterialX, by always naming nodes ourselves.
Pull Request: https://projects.blender.org/blender/blender/pulls/133234
This uses the following accessor methods in more places in more places:
`is_group()`, `is_group_input()`, `is_group_output()`, `is_muted()`,
`is_frame()` and `is_reroute()`.
This results in simpler code and reduces the use of `bNode.type_legacy`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132899
This makes specifying a legacy type for new node types optional (e.g.
`GEO_NODE_MESH_TO_CURVE`). Instead, only the `idname` is used as a stable
identifier for node types. So there is less redundancy for now.
This change helps with the decentralized definition of nodes and reduces the
number minimum number of files that need to be changed for a new node from 5 to
4. It especially helps when multiple nodes are worked on at the same time,
because the legacy type definition was very prone to have merge conflicts.
For compatibility reasons and because it's still used by existing code, the
`legacy_type` is not removed. All existing nodes keep their current
`legacy_type`. New nodes will receive an auto-incremented legacy type. It's
still necessary to give nodes unique legacy types, because some code checks if
two nodes have the same type by comparing their `legacy_type`. These types only
have to be unique at run-time though. Some randomness is used to avoid depending
on stable generated legacy types accidentally.
Pull Request: https://projects.blender.org/blender/blender/pulls/133044
- "Strength" in the context of Grease Pencil, deals with opacity, and
adjusts the brush stroke alpha.
- "Strength" can mean measurable units like 'noise', 'light', etc.
- Anything else using physical strength in a generic concept.
Issue reported by Hoang Duy Tran.
Main goals of this refactor:
* Make it more obvious which update function should be used.
* Make it more obvious which parameters are required by using references instead
of pointers.
* Support passing in multiple modified trees instead of just a single one.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/132862
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
This removes the second to last usage of `NOD_static_types.hh` which we intend
to remove. A nice benefit is that the idname is now finally more explicit when a
node is registered. Previously it was difficult to search for the definition of
a node in the code when one had only the idname, which is the main identifier
for nodes.
The main change is in `node_type_base`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132815
As part of an effort to remove this header, reducing the need for macro/
include magic and making node definitions more independent, move
the node UI name and description definitions to each node's file.
The UI name, description, and idname are also moved to std::string
instead of char arrays.
Similar to b43e2168e3.
Pull Request: https://projects.blender.org/blender/blender/pulls/132708
Make the type structs non-trivial, use new and delete for allocation and
freeing, and use std::string for most strings they contain. Also use
StringRef instead of char pointers in a few places. Mainly this improves
ergonomics when working with the strings.
Pull Request: https://projects.blender.org/blender/blender/pulls/132750
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
The output node types were seemingly incorrect since the initial commit
and would produce incorrect MaterialX documents[1]. When MaterialX is
upgraded to 1.38.10 this will now fail material creation in Hydra.
Use the node type directly instead of setting things to their default
`color3` output type.
[1] See PR for an example.
Pull Request: https://projects.blender.org/blender/blender/pulls/132362
Typically we are more flexibl with the attribute domain and type,
especially in the context of color attributes. This node still used
the old "vertex color" concept (only byte colors on the face corner
domain). It should have been updated for color attributes. Now the
nodes uses the attribute API to retrieve the attribute which
automatically interpolates the domain and type.
Also fix the node's use of the active color attribute to use the new
string based system rather than CustomData. It's incorrect to use the
active color rather than the default, but changing that might break
existin files.
Pull Request: https://projects.blender.org/blender/blender/pulls/132149
A followup for 5e7f3e5c84.
Make the NOD_static_types.h file less important by moving `enum_name_legacy`
to be defined in the register function of every node. This helps our gradual transition
away from this file.
Also add a fallback to the node idname so that newly added nodes no longer need
to define the string value.
Pull Request: https://projects.blender.org/blender/blender/pulls/132131
Previous implemenation of 5 < d < 50 was taken from the main paper,
fitting for smaller sizes are found in the supplemental. They are less
forward-scattering.
Pull Request: https://projects.blender.org/blender/blender/pulls/130234
It's a relatively common occurrence to run out of space for the property name
when using the Attribute Node, making it unreadable. A big part of this space is
eaten up by the labels, especially since the space they take up scales up with
the node width.
It can be argued that the info provided by the labels (`Type:` & `Name:`), are
superfluous and not essential. Removing them does not make the node harder to
use, and frees up more space for the user to type longer property names.
This is quite similar to changes done in #127992 for Geometry Nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131543
- Gives O(1) access to string length in more cases
- Convenient string manipulation functions
- Clarify difference between "no string" and "empty string"
- Avoid the need for raw pointers in the API
- Shows which API string arguments are optional
Pull Request: https://projects.blender.org/blender/blender/pulls/131473
This adds tooltip descriptions for five items in the Principled BSDF
that currently have no descriptions at all. Sheen Weight: "Intensity
of the sheen layer, which simulates very small fibers on the surface".
Sheen Roughness: "Roughness of the sheen layer. Low and high roughness
values produce fuzzy or dusty appearance, respectively". Tint Color:
"Color of the sheen reflection". Thin Film Thickness: "Thickness of the
film in nanometers". Thin Film IOR: "Index of refraction (IOR) of the
thin film".
Pull Request: https://projects.blender.org/blender/blender/pulls/126735
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
This enables material displacement for UsdPreviewSurface import and
export. Scenarios are limited by what's supported by the preview surface
itself. Namely only Object Space displacement can be used (no vector
displacement)[1] and the Midlevel and Scale parameters are maintained by
adjusting the scale-bias on the image texture controlling the Height
(this means that Midlevel and Scale must be constants).
Hydra/MaterialX support is more complicated. First, there is a bug which
prevents scalar displacment from working correctly and that needs USD
2408+ for the fix[2]. Second, is that there's an open question about
which coordinate system to use for MaterialX's vector displacement maps.
Lastly, Hydra GL does not render displacement, making verification using
only Blender impossible[3]. As a result, this PR only makes MaterialX
"ready" for support, but stops short of actually connecting the final
piece of the node graph until more of the above can be sorted out.
Tests are added which cover:
- Variations of Midlevel and Scale values
- A constant Height setup
- Negative scenarios checking that only Object space is supported
and that midlevel and scale need to be constants
[1] https://openusd.org/release/spec_usdpreviewsurface.html
[2] https://github.com/PixarAnimationStudios/OpenUSD/issues/3325
[3] https://forum.aousd.org/t/materialx-displacement-hydra-storm/1098/2
Pull Request: https://projects.blender.org/blender/blender/pulls/128909
