When baking e.g. the Diffuse pass, use the existing filter logic to
disable glossy and transmission closures.
This reduces baking time and noise when baking individual components
of complex materials.
The problem here was that when direct light contibutions to baking were
disabled, the kernel just skipped all direct lighting evaluation.
However, at secondary bounces, "direct light" would actually end up
being indirect (since there's an extra bounce along the way), but
we're still skipping it.
Therefore, only apply direct lighting skipping at the first bounce.
Store subdivision surface creases in two new named float attributes:
- `crease_vert`
- `crease_edge`
This is similar to 2a56403cb0.
The attributes are naming conventions, so their data type and domain
aren't enforced, and may be interpolated when necessary. Editing tools
and the subdivision surface modifier use the hard-coded name. It might
be best if these were edited as generic attributes in the future, but
in the meantime using generic attributes helps.
The attributes are visible in the list, which is how they're now meant
to be removed. They are now interchangeable with any tool that works
with the generic attribute system-- even tools like vertex paint can
affect creases now.
This is a breaking change. Forward compatibility isn't preserved for
versions before 3.6, and the `crease` property in RNA is removed in
favor of making a smaller API surface area with just the attribute API.
`Mesh.vertex_creases` and `Mesh.edge_creases` now just return the
matching attribute if possible, and are now implemented in Python.
New functions `*ensure` and `*remove` also replace the operators to
add and remove the layers for Python.
A few extrude node test files have to be updated because of different
(now generic) attribute interpolation behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/108089
This fixes an issue where the light tree sampling algorithm would
discard light samples from groups of distance lights with an angle
greater than 0 when it shouldn't.
Pull Request: https://projects.blender.org/blender/blender/pulls/108832
Fractal noise is the idea of evaluating the same noise function multiple times with
different input parameters on each layer and then mixing the results. The individual
layers are usually called octaves.
The number of layers is controlled with a "Detail" slider.
The "Lacunarity" input controls a factor by which each successive layer gets scaled.
The existing Noise node already supports fractal noise. Now the Voronoi Noise node
supports it as well. The node also has a new "Normalize" property that ensures that
the output values stay in a [0.0, 1.0] range. That is except for the F2 feature where
in rare cases the output may be outside that range even with "Normalize" turned on.
How the individual octaves are mixed depends on the feature and output socket:
- F1/Smooth F1/F2:
- Distance/Color output:
The individual Distance/Color octaves are first multiplied by a factor of
`Roughness ^ (#layers - 1.0)` then added together to create the final output.
- Position output:
Each Position octave gets linearly interpolated with the combined output of the
previous octaves. The Roughness input serves as an interpolation factor with
0.0 resutling in only using the combined output of the previous octaves and
1.0 resulting in only using the current highest octave.
- Distance to Edge:
- Distance output:
The Distance octaves are mixed exactly like the Position octaves for F1/Smooth F1/F2.
It should be noted that Voronoi Noise is a relatively slow noise function, especially
at higher dimensions. Increasing the "Detail" makes it even slower. Therefore, when
optimizing a scene one should consider trying to use simpler noise functions instead
of Voronoi if the final result is close enough.
Pull Request: https://projects.blender.org/blender/blender/pulls/106827
So far, each closure in Cycles was either diffuse OR glossy OR
transmissive, and its color and contributions were assigned
to the corresponding direct/indirect/color passes.
However, since Glass is a single closure now, that is no longer enough,
since glass has both a glossy and a transmissive component.
Therefore, this commit adds support for splitting contributions from
the Glass closure between the two types.
For 4.0, we might want to also use this for Principled Hair since it
also technically has both types, but that would be a change from
the existing result so it's not part of 3.6 yet.
This reverts commit 451751380c.
Seems like this broke linux/mac, likely needs to detect of libxvid
is there or not. For now revert until we sort this out.
Currently, Windows some dependencies are built with MinGW/GCC 3.x
this commit removes that, in favor of building them with MSVC
via msys2. This will make it easier in the future to offer Win/Arm64
builds of blender.
Notable changes:
- This change drops support for the external libxvid library in favor
of ffmpegs built in support for this format. This has been done with
permission from the VFX module.
Pull Request: https://projects.blender.org/blender/blender/pulls/105502
With this change, instances of lamps and emissive meshes which do not
have their own light group assigned will use the light group of the
collection instance.
If an object does have a light group assigned, its instances will
continue to use it regardless of the collection instance's light group.
This PR adds initial cube (array) support. Depending on how the texture
is used a different image view is created. When used as a framebuffer
attachment only a single side of the cubemap is attached. The image
view is attached as a 2d texture array. When used as a shader resource
the image view is a cubemap.
Also adds test cases to test both scenarios.
Pull Request: https://projects.blender.org/blender/blender/pulls/108794
`sd->type` was set to `PRIMITIVE_TRIANGLE` when it should be
`PRIMITIVE_LAMP`.
Function #lights_intersect_impl sets `isect->prim` to `lamp`, which is
passed to function #shader_setup_from_sample. There `prim != PRIM_NONE`
is evaluated to `true`, thus setting `sd->type` to `PRIMITIVE_TRIANGLE`
erroneously. This fix checks `lamp != LAMP_NONE` first, as in all other
usages of #shader_setup_from_sample `LAMP_NONE` is passed as the value
of `lamp`.
Pull Request: https://projects.blender.org/blender/blender/pulls/108769
* opengl_context -> system_gpu_context. This is the operating system OpenGL,
Metal or Vulkan context provided by GHOST.
* gpu_context -> blender_gpu_context. This is the GPUContext provided by
the Blender GPU module, which wraps the GHOST context and adds some state.
* Various functions create/destroy/enable/disable both contexts, these have
just gpu_context in the name now.
Pull Request: https://projects.blender.org/blender/blender/pulls/108723
In Embree, tfar modification is taken into account by rtcIntersect1
only when hits are accepted. In order to overcome this, we now check
manually for a max_t value in the filter function.
Pull Request: https://projects.blender.org/blender/blender/pulls/108706
We should be recording only the N closest hits in case the number of
hits is exceeding the maximum allowed or the size of the hits stack.
Previously, some cases made it record hits beyond the furthest recorded
one due to lack of hit distance check.
The input socket of Image Texture node is connected with the UV output
of Texture Coordinate node by default, the later reads the geometry UV,
which is not available for lights because they have no real geometry.
The current implementation simply retrieves UV from shader data.
Pull Request: https://projects.blender.org/blender/blender/pulls/108691
This is added so that some texture pipeline with point light and spot
light could work as before. Some people use the Normal socket from
Texture Coordinate node for texturing light, however the Normal there is
actually the incoming light direction and should be corrected. Using the
Parametric socket from Geometry node + normal transform from world to
object with Vector Transform node delivers the same result as using the
Normal socket from Texture Coordinate node.
Currently for lights only normal transformation works, because only
there we fetch light transform properly. This is a confusing behaviour,
but testing if it's a lamp in all relevant functions could have bad
impact on the performance. A more proper solution would be to change
lights to real objects, which is planned for the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/108666
- "Invalid" in transformation messages.
- For three messages, translation occured after a string
- concatenation, so the full message was not found.
Instead, translate a format pattern and format it afterwards.
- Alembic errors when there is an import type mismatch.
Pull Request: https://projects.blender.org/blender/blender/pulls/108212
While the multiscattering GGX code is cool and solves the darkening problem at higher roughnesses, it's also currently buggy, hard to maintain and often impractical to use due to the higher noise and render time.
In practice, though, having the exact correct directional distribution is not that important as long as the overall albedo is correct and we a) don't get the darkening effect and b) do get the saturation effect at higher roughnesses.
This can simply be achieved by adding a second lobe (https://blog.selfshadow.com/publications/s2017-shading-course/imageworks/s2017_pbs_imageworks_slides_v2.pdf) or scaling the single-scattering GGX lobe (https://blog.selfshadow.com/publications/turquin/ms_comp_final.pdf). Both approaches require the same precomputation and produce outputs of comparable quality, so I went for the simple albedo scaling since it's easier to implement and more efficient.
Overall, the results are pretty good: All scenarios that I tested (Glossy BSDF, Glass BSDF, Principled BSDF with metallic or transmissive = 1) pass the white furnace test (a material with pure-white color in front of a pure-white background should be indistinguishable from the background if it preserves energy), and the overall albedo for non-white materials matches that produced by the real multi-scattering code (with the expected saturation increase as the roughness increases).
In order to produce the precomputed tables, the PR also includes a utility that computes them. This is not built by default, since there's no reason for a user to run it (it only makes sense for documentation/reproducibility purposes and when making changes to the microfacet models).
Pull Request: https://projects.blender.org/blender/blender/pulls/107958
The additional SocktType::VECTOR argument was being interpreted as flags,
which caused the OSL compiler to skip the input (since the Vector type enum
happens to align with the INTERNAL flag), which caused the OSL shader to
always use the hardcoded default absorption regardless of what was entered.
