This way we remove the need for the srgb boolean uniform and a lot of code complexity. However, mesh update is going to be a bit slower.
I did not benchmark the performance impact.
This also fix a typo in draw_cache_impl_particles.c and fix hair not using vertex color in workbench.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D6610
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
Previously this limit was rather high, but with UDIMs it's fairly easy
to reach this many images. Even though this exceeds the texture limit
on most hardware as far as I can tell, it should at least not crash.
The old code uses a fixed array which overflows eventually, this fix
replaces the array with a GSet.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D6416
This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender.
With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser.
Therefore, code that is not yet aware of tiles will just access the default tile as usual.
The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9.
Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator.
The following features are supported so far:
- Automatic detection and loading of all tiles when opening the first tile (1001)
- Saving all tiles
- Adding and removing tiles
- Filling tiles with generated images
- Drawing all tiles in the Image Editor
- Viewing a tiled grid even if no image is selected
- Rendering tiled images in Eevee
- Rendering tiled images in Cycles (in SVM mode)
- Automatically skipping loading of unused tiles in Cycles
- 2D texture painting (also across tiles)
- 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders)
- Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID)
- Different resolutions between tiles
There still are some missing features that will be added later (see T72390):
- Workbench engine support
- Packing/Unpacking support
- Baking support
- Cycles OSL support
- many other Blender features that rely on images
Thanks to Brecht for the review and to all who tested the intermediate versions!
Differential Revision: https://developer.blender.org/D3509
This patch adds a new Vertex Color node. The node also returns the alpha
of the vertex color layer as an output.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5767
This patch continue the efforts to split the `gpu_shader_material` file
started in D5569.
Dependency resolution is now recursive. Each shading node gets its own
file. Additionally, some utility files are added to be shared between
files, like `math_util`, `color_util`, and `hash`. Some files are always
included because they may be used in the execution function, like
`world_normals`.
Some glsl functions appeared to be unused, so they were removed, like
`output_node`, `bits_to_01`, and `exp_blender`. Other functions have
been renamed to be more general and get used as utils, like `texco_norm`
which became `vector_normalize`.
A lot of the opengl tests fails, but those same tests also fail in
master, so this is probably unrelated to this patch.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5616
Compiling this big file for every Eevee material is bad for performance, and
now that we are adding more nodes it gets worse. This patch adds a simple
mechanism to split up that file, and use only the parts used by shader nodes.
When a function is used by GPU_link, we detect which GLSL file it came from
and use it in GLSL code generation automatically. Dependencies between GLSL
files are manually specified, and function names must be unique across all
GLSL files.
Most of the actual splitting up will be done in later commits.
Differential Revision: https://developer.blender.org/D5569
The object color property is added as an additional output in
the Object Info node.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5554
Alpha blended Transparency is now using dual source blending making it
fully compatible with cycles Transparent BSDF.
Multiply and additive blend mode can be achieved using some nodes and are
going to be removed.
In the Intel HD 4000 driver a shader has to be deleted in the same context in which it is created.
However, because you can't use a rendering context on different threads, to maintain the multithreaded compilation, the solution was to use the `GL_ARB_get_program_binary` and copy the binary generated for the shader and generate a shader on the main context using that binary.
This solution is limited only to Intel HD 4000 and windows.
Reviewers: fclem
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D5019
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
The wrong transformation was used. Add a new matrix specially for this case.
This also fix the Node texture coordinate that was suffering the same issue.
Until now, Orcos were computed by the gpu (GLSL) and were not taking into
account the modifier stack (breaking orco for deformed mesh).
Now Orco is now computed on CPU but only if a modifier stack is present.
Tagging that an ORCO layer is present is done via a 4th component, which is
a waste of memory/bandwidth. Best would be to do the same as auto attrib
color space and save a bool uniform somewhere but for now it's too
disruptive.
In this case, the generic vertex attribute is {0,0,0,1}. So we look for
this case.
This fixes black text objects with a normal map applied. Also this could
help porting sculpt mode drawing to Eevee without supporting normal
mapping.
Note that will just fix black meshes due to T61870 but objects will not
show their normal map. So it's not a fix for this issue.
This is a hacky fix. We just convert the int as a float and use it as such.
This works ok for small int but will not be correct for numbers greater
than 4194303.
Correct support would require deeper change for UBO creation and socket
conversion.
This commit possibly fixes the T58938.
The crash happens when a shader that is created in a rendering context is deleted and another shader with the same name/program of the deleted one is created in the same context and used in another context.
