It was only checking for the identifier, but the type has to be equivalent as well.
Reviewers: mano-wii, brecht
Differential Revision: https://developer.blender.org/D8101
This commit adds a new model to the Sky Texture node, which is based on a
method by Nishita et al. and works by basically simulating volumetric
scattering in the atmosphere.
By making some approximations (such as only considering single scattering),
we get a fairly simple and fast simulation code that takes into account
Rayleigh and Mie scattering as well as Ozone absorption.
This code is used to precompute a 512x128 texture which is then looked up
during render time, and is fast enough to allow real-time tweaking in the
viewport.
Due to the nature of the simulation, it exposes several parameters that
allow for lots of flexibility in choosing the look and matching real-world
conditions (such as Air/Dust/Ozone density and altitude).
Additionally, the same volumetric approach can be used to compute absorption
of the direct sunlight, so the model also supports adding direct sunlight.
This makes it significantly easier to set up Sun+Sky illumination where
the direction, intensity and color of the sun actually matches the sky.
In order to support properly sampling the direct sun component, the commit
also adds logic for sampling a specific area to the kernel light sampling
code. This is combined with portal and background map sampling using MIS.
This sampling logic works for the common case of having one Sky texture
going into the Background shader, but if a custom input to the Vector
node is used or if there are multiple Sky textures, it falls back to using
only background map sampling (while automatically setting the resolution to
4096x2048 if auto resolution is used).
More infos and preview can be found here:
https://docs.google.com/document/d/1gQta0ygFWXTrl5Pmvl_nZRgUw0mWg0FJeRuNKS36m08/view
Underlying model, implementation and documentation by Marco (@nacioss).
Improvements, cleanup and sun sampling by @lukasstockner.
Differential Revision: https://developer.blender.org/D7896
This use the latest GPUTexture change to use the sampler state to avoid
the pole issues instead of using GLSL hacks.
This should fix T73942: Eevee mipmaps not respecting border mode.
Note that this also fix some discrepencies between cycles and eevee (like
boxmapping + clip).
This bridge between the new sampler state support from GPUTexture and
draw material handling.
The Sampler State is just the one from the texture for now. No change in
logic.
These are the modifications:
-With DRW modification we reduce the number of passes we need to populate.
-Rename passes for consistent naming.
-Reduce complexity in code compilation
-Cleanup how renderpass accumulation passes are setup, using pass instances.
-Make sculpt mode compatible with shadows
-Make hair passes compatible with SSS
-Error shader and lookdev materials now use standalone materials.
-Support default shader (world and material) using a default nodetree internally.
-Change BLEND_CLIP to be emulated by gpu nodetree. Making less shader variations.
-Use BLI_memblock for cache memory allocation.
-Renderpasses are handled by switching a UBO ref bind.
One major hack in this patch is the use of modified pointer as ghash keys.
This rely on the assumption that the keys will never overlap because the
number of options per key will never be bigger than the pointed struct.
The use of one single nodetree to support default material is also a bit hacky
since it won't support concurent usage of this nodetree.
(see EEVEE_shader_default_surface_nodetree)
Another change is that objects with shader errors now appear solid magenta instead
of shaded magenta. This is only because of code reuse purpose but could be changed
if really needed.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D7642
Current implementation would update the nodetree of the freestyle scene not the composite scene.
Reviewed By: Dalai Felinto
Differential Revision: https://developer.blender.org/D7770
The previous code only handled the RGBA socket case. For vectors, we simply
use the average of the 3 compoments. This is done using a temp Vector Math
node using the dot operation.
This commit adds the initial set of particles nodes. These are fairly
low level and are expected to be put into groups that we ship with Blender.
See D7384 for a description of the individual nodes.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7384
These socket types will be necessary for particle nodes.
The way these sockets are drawn can be changed separately.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7349
Those new socket types will be necessary for particle nodes.
The main difficulty with adding these socket types is that they
are the first that reference ID data in their `value`.
Therefore, user counting code had to be added in a couple new places.
Reviewers: brecht, mont29
Differential Revision: https://developer.blender.org/D7347
This implements a new builtin node tree type called `SimulationNodeTree`.
It is not yet embedded in the `Simulation` data block.
The node tree will initially be used for the new particle nodes system.
When the cmake option `WITH_NEW_SIMULATION_TYPE` is enabled, a new
`Simulation Editor` is shown in the editors menu (which is just a node editor).
This patch does not add entries to the Add Node menu, so it is empty.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D7287
Currently in fractal_noise functions, each subsequent octave doubles the
frequency and reduces the amplitude by half. This patch introduces Roughness
input to Noise and Wave nodes. This multiplier determines how quickly the
amplitudes of the subsequent octaves decrease.
Value of 0.5 will be the default, generating identical noise we had before.
Values above 0.5 will increase influence of each octave resulting in more
"rough" noise, most interesting pattern changes happen there. Values below
0.5 will result in more "smooth" noise.
Differential Revision: https://developer.blender.org/D7065
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
RE_engine_register_pass is sometimes in the headers with type
as an integer parameter, sometimes as eNodeSocketDatatype.
This caused warnings, the root cause was makesrna was not able
to generate the proper type for enums and defaulted to int.
makesrna has been extended with the RNA_def_property_enum_native_type
that allows telling makesrna the native type of an enum, if set it
will be used otherwise it will still fall back to int.
Differential Revision: https://developer.blender.org/D7117
Reviewed By: brecht
This has no user visible impact yet since smoke volumes only support a fixed
set of attributes, but will become important with the new volume object.
For GPU shader compilation, volume grids are now handled separately from
image textures. They are somewhere between a vertex attribute and an image
texture, basically an attribute that is stored as a texture.
Differential Revision: https://developer.blender.org/D6952
This is more in line with standard grids and means we don't have to make
many special exceptions in the upcoming change for arbitrary number of volume
grids support in Eevee.
The workbench shader was also changed to fix bugs where squared density was
used, and the smoke color would affect the density so that black smoke would
be invisible. This can change the look of smoke in workbench significantly.
When using the color grid when smoke has a constant color, the color grid
will no longer be premultiplied by the density. If the color is constant
we want to be able not to store a grid at all. This breaks one test for
Cycles and Eevee, but the setup in that test using a color without density
does not make sense. It suffers from artifacts since the unpremultiplied
color grid by itself will not have smooth boundaries.
Differential Revision: https://developer.blender.org/D6951
Currently the link limit of sockets is stored in bNodeSocket->limit.
This allows for a lot of flexibility, but is also very redundant.
In every case I've had to deal with so far, it would have "more correct"
to set the link limit per socket type and not per socket. I did not enforce
this constraint yet, because the link limit is exposed in the Python API,
which I did not want to break here.
In the future it might even make sense to only support only three kinds of link limits:
a) no links, b) at most one link, c) an arbitrary number links links. The other link
limits usually don't work well with tools (e.g. which link should be removed when a new
one is connected?) and is not used in practice. However, that is for another day.
Eventually, I would like to get rid of bNodeSocket->limit completely and replace it
either with fixed link limits or a callback in bNodeSocketType.
This patch consists of three parts:
**1. Support defining link limit in socket type**
This introduces a new `nodeSocketLinkLimit` function that serves as an indirection to
hide where the link limit of a socket is defined.
**2. Define link limits for builtin sockets on socket type**
Data sockets: one input, many outputs
Virtual sockets: one input, one output
Undefined sockets: many inputs, many outputs (to avoid that links are removed when the type of the socket is not known)
**3. Remove `bNodeSocketTemplate->limit`**
This wasn't used anymore after the second commit. Removing it simplifies socket definitions
in hundreds of places and removes a lot of redundancy.
Differential Revision: https://developer.blender.org/D7038
Reviewers: brecht
This further separates requested attributes and textures from the actual
node graph, that can be retained after the graph has been compiled and
freed. It makes it easier to add volume grids as a native concept, which
sits somewhere between an attribute and a texture.
It also adds explicit link types for UDIM tile mapping, rather than
relying on fairly hidden logic.
This patch adds new render passes to EEVEE. These passes include:
* Emission
* Diffuse Light
* Diffuse Color
* Glossy Light
* Glossy Color
* Environment
* Volume Scattering
* Volume Transmission
* Bloom
* Shadow
With these passes it will be possible to use EEVEE effectively for
compositing. During development we kept a close eye on how to get similar
results compared to cycles render passes there are some differences that
are related to how EEVEE works. For EEVEE we combined the passes to
`Diffuse` and `Specular`. There are no transmittance or sss passes anymore.
Cycles will be changed accordingly.
Cycles volume transmittance is added to multiple surface col passes. For
EEVEE we left the volume transmittance as a separate pass.
Known Limitations
* All materials that use alpha blending will not be rendered in the render
passes. Other transparency modes are supported.
* More GPU memory is required to store the render passes. When rendering
a HD image with all render passes enabled at max extra 570MB GPU memory is
required.
Implementation Details
An overview of render passes have been described in
https://wiki.blender.org/wiki/Source/Render/EEVEE/RenderPasses
Future Developments
* In this implementation the materials are re-rendered for Diffuse/Glossy
and Emission passes. We could use multi target rendering to improve the
render speed.
* Other passes can be added later
* Don't render material based passes when only requesting AO or Shadow.
* Add more passes to the system. These could include Cryptomatte, AOV's, Vector,
ObjectID, MaterialID, UV.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D6331
This patch provides an optimisation for Ease (Smoothstep) setting in the color ramp node.
This optimisation exists already for Constant and Linear modes.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6880
This node provides the ability to rotate a vector around a `center` point using either `Axis Angle` , `Single Axis` or `Euler` methods.
Reviewed By: #cycles, brecht
Differential Revision: https://developer.blender.org/D3789
