| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
Default mesa driver for ubuntu 20.04 fails when a name is defined twice.
M_PI is defined in both `common_workbench_lib` and `common_math_lib`. This patch
remove the define out of common_workbench_lib
For reference it fails on https://github.com/mesa3d/mesa/blob/mesa-20.0.8/src/compiler/glsl/glcpp/glcpp-parse.y#L1186
during the check if the macros are the same.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D8741
|
|
- add the use of DRWShaderLibrary to EEVEE's glsl codebase to reduce code
complexity and duplication.
- split bsdf_common_lib.glsl into multiple sub library which are now shared
with other engines.
- the surface shader code is now more organised and have its own files.
- change default world to use a material nodetree and make lookdev shader
more clear.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D8306
|
|
|
|
|
|
This patch is (almost) a complete rewrite of workbench engine.
The features remain unchanged but the code quality is greatly improved.
Hair shading is brighter but also more correct.
This also introduce the concept of `DRWShaderLibrary` to make a simple
include system inside the GLSL files.
Differential Revision: https://developer.blender.org/D7060
|
|
Based on @fclem's suggestion in D6421, this commit implements support for
storing all tiles of a UDIM texture in a single 2D array texture on the GPU.
Previously, Eevee was binding one OpenGL texture per tile, quickly running
into hardware limits with nontrivial UDIM texture sets.
Workbench meanwhile had no UDIM support at all, as reusing the per-tile
approach would require splitting the mesh by tile as well as texture.
With this commit, both Workbench as well as Eevee now support huge numbers
of tiles, with the eventual limits being GPU memory and ultimately
GL_MAX_ARRAY_TEXTURE_LAYERS, which tends to be in the 1000s on modern GPUs.
Initially my plan was to have one array texture per unique size, but managing
the different textures and keeping everything consistent ended up being way
too complex.
Therefore, we now use a simpler version that allocates a texture that
is large enough to fit the largest tile and then packs all tiles into as many
layers as necessary.
As a result, each UDIM texture only binds two textures (one for the actual
images, one for metadata) regardless of how many tiles are used.
Note that this rolls back per-tile GPUTextures, meaning that we again have
per-Image GPUTextures like we did before the original UDIM commit,
but now with four instead of two types.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6456
|
|
Now texture storage of images is defined by the alpha mode of the image. The
downside of this is that there can be artifacts near alpha edges where pixels
with zero alpha bleed in. It also adds more code complexity since image textures
are no longer all stored the same way.
This changes allows us to keep using sRGB texture formats, which have edge
darkening when stored with premultiplied alpha. Game engines seems to generally
do the same thing, and we want to be compatible with them.
|
|
Cycles now uses the color space on the image datablock, and uses OpenColorIO
to convert to scene linear as needed. Byte images do not take extra memory,
they are compressed in scene linear + sRGB transfer function which in common
cases is a no-op.
Eevee and workbench were changed to work similar. Float images are stored as
scene linear. Byte images are compressed as scene linear + sRGB and stored in
a GL_SRGB8_ALPHA8 texture. From the GLSL shader side this means they are read
as scene linear, simplifying the code and taking advantage of hardware support.
Further, OpenGL image textures are now all stored with premultiplied alpha.
Eevee texture sampling looks a little different now because interpolation
happens premultiplied and in scene linear space.
Overlays and grease pencil work in sRGB space so those now have an extra
conversion to sRGB after reading from image textures. This is not particularly
elegant but as long as engines use different conventions, one or the other
needs to do conversion.
This change breaks compatibility for cases where multiple image texture nodes
were using the same image with different color space node settings. However it
gives more predictable behavior for baking and texture painting if save, load
and image editing operations have a single color space to handle.
Differential Revision: https://developer.blender.org/D4807
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
This makes it possible to paint pixel art using the workbench.
Cubic interpolation is not supported but could be added if needed.
|
|
|
|
|
|
|
|
|
|
Also optimize deferred engine by only outputing material data if needed.
This make the bare flat shading mode (no effects) only a depth prepass.
|
|
This reduces the bandwidth + vram usage of workbench even further.
|
|
We exploit the fact that we are using the metallic workflow for material
and pass the metallic parameter instead of the specular color.
Pack the front facing bit in the color buffer only for matcap display.
Change buffer formats to use less bytes as possible.
Also don't request buffers that we won't use.
Saved 40MB on 2K screen on StudioLight + Shadows + Specular Lighting.
Includes several cleanups.
|
|
* Move the curvature computation to the cavity pass: One can argue it's not
the best performance wise (it gets a tiny perf pernalty if it is done
alone without the ssao), but it make the code cleaner and reduce
considerably the number of shader variation possible.
* Lower shader variation to 2^8 instead of 2^12
|
|
By using equation 7 from the paper, we make the surfaces nearest to the
viewpoint appear more "opaque". This gives better sense of ordering than
the previous weighting function that was really not doing anything.
|
|
There was a method explained in the Weighted Blended Order-Independent
Transparency paper to support hardware that does not support per render
target blending function.
So now only 2 geometry passes are required instead of 3 (one being the
outline/depth fill pass).
This also fix how the blending is done. There was some premult confusion
in the implementation.
|
|
This fixes the problem that matcaps have when using a very larg FOV in
perspective view.
This was because it was stupidly using the normal direction which can not
aligned with the view vector under perspective.
So to workaround this problem we don't use the normal as is, but compute
how much it's facing the camera.
This changes how matcaps looks in perspective because they now always use
the full range of the matcap (which is expected).
|
|
This fixes specular in perspective view.
|
|
- Uses the roughness setting of the basic eevee material
- renamed gloss_mir to roughness
- set default of roughness to 0.25
- renamed ray_mirror to metallic
- cleaned up material rna (BI mirror struct)
- use BLINN phong model
- normalize incoming/outgoing specular light
- when using camera oriented studiolight, the SolidLight will be used
for specular highlights
- EXPERIMENT: when in world oriented studiolight only the shadow direction will be used.
- change the settings of the internal light to make scenes more
readable
|
|
|
|
added a fresnel effect
TODO: solve memory leak
|
|
|
|
|
|
|
|
|
|
Normal packing. The sign is stored in the A of the color buffer.
if the A == 1.0 the normal should be inverted. before use.
The reason is that packing has more precision for frontfaces, than for
backfaces
|
|
|
|
- store normal in vec2
- use rgba_8 for colorBuffer
|
|
|
