| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Seems like a driver bug but doing glFlush() before these calls fixes it.
|
|
Instead of doing a lot of alpha blended drawing with jittering, use the
fragment shader to do the masking using a circle mask.
This is much simpler and requires much less resources.
Hopefully this may solve the issue we have with the Intels UHD Graphics 620
on linux.
|
|
Also use unsigned shifting for values not in int range.
|
|
|
|
Fixes T55987
|
|
|
|
|
|
|
|
|
|
... in the timeline.
|
|
|
|
|
|
|
|
|
|
That was caused by a thread safety issue on gpu_batch_presets_unregister()
which was not designed to be used for this kind of situation (managing 3D
meshes batches).
|
|
The Camera to Object space matrix was not implemented in gpu_codegen.
|
|
This makes it possible to tweak indirect lighting in the shader.
Only a subset of the outputs is supported and the ray depth has not exactly
the same meaning:
Is Camera : Supported.
Is Shadow : Supported.
Is Diffuse : Supported.
Is Glossy : Supported.
Is Singular : Not supported. Same as Is Glossy.
Is Reflection : Not supported. Same as Is Glossy.
Is Transmission : Not supported. Same as Is Glossy.
Ray Length : Not supported. Defaults to 1.0.
Ray Depth : Indicate the current bounce when baking the light cache.
Diffuse Depth : Same as Ray Depth but only when baking diffuse light.
Glossy Depth : Same as Ray Depth but only when baking specular light.
Transparent Depth : Not supported. Defaults to 0.
Transmission Depth : Not supported. Same as Glossy Depth.
Caveat: Is Glossy does not work with Screen Space Reflections but does work
with reflection planes (when used with SSR or not).
We have to render the world twice for that to work.
|
|
Also minor cleanup for the Bump node.
|
|
Only do GPU material updates through depsgraph evaluation now. This was
already happening for material, just missing for the world.
|
|
|
|
|
|
This does not work with the box projection mode. Implementing for box
projection mode would be difficult, slow, and produce a lot of code
duplication. Also i'm not sure this is worth it, as it's not a common use
case.
|
|
|
|
Take the full derivative and compute its length instead of using fwidth.
|
|
Before it was triggering shader recompilation. Include small cleanup/opti.
|
|
This was causing bad behavior of the node Normal.
|
|
Although the normal was normalized when evaluating the lighting, the normal
is often used for other purpose. In this case using the non normalized
normal maybe the source of errors.
|
|
|
|
This fits Cycles better even if it is only for grey scale values. This only
work if the blend mode is Alpha Blend or Alpha Hashed.
|
|
Reviewers: fclem
Differential Revision: https://developer.blender.org/D3903
|
|
This is a nasty bug. Because the node does not get properlly tagged as SSS
(sss_id is 0) but is still evaluated (so tagging the GPUMaterial as having
SSS). The sssProfile UBO is still declared and we need to bind something
to it.
|
|
|
|
On some platform does not support line width > 1.0 and can even throw and
error. Better check an at least display something rather than no lines at
all.
|
|
Node group inputs should behave like cycles now.
----
We create dummy nodes that contains the default values for the nodegroup
inputs and link them to the sockets. This way the uniform buffer gathering
function can read them.
But we also need to disconnect all the internal links to sockets that have
hidden values. Theses sockets must not get the values from the nodegroup
input sockets if there is no link to them otherwise we get broken results
(i.e.: normals for a bsdf node).
|
|
|
|
(old X-ray) is enabled
Differential Revision: https://developer.blender.org/D3828
|
|
|
|
|
|
|
|
With the new automatic handle algorithm, it is possible to do a lot
of the animation via keyframes without touching the curves. It is
however necessary to change the keyframe interpolation and handle
types in certain cases. Currently the dopesheet/action editor
allows changing the types, but does not show them in any way.
To fix, add a new menu option to display this information. For handle
type, it is represented using the shape of the key icons: diamond for
Free, clipped diamond for Aligned, square for Vector, circle for Auto
Clamp, and cirle with dot for Automatic.
Non-bezier interpolation is a property of intervals between keys,
so it is marked by drawing lines, similar to holds. In this initial
version, only the fact of non-bezier interpolation is displayed,
without distinguishing types. For summaries, the line is drawn at
half alpha if not all curves in the group are non-bezier.
In addition, it is sometimes helpful to know the general direction
of change of the curve, and which keys are extremes. This commit
also adds an option to highlight extremes, based on comparing the
keyed values with adjacent keys. Half-intensity display is used
for overshot bezier extremes, or non-uniform summaries.
Reviewers: brecht, aligorith, billreynish
Differential Revision: https://developer.blender.org/D3788
|
|
Adding a workaround in this case: we blit the depth buffer instead of the
stencil buffer and use the copy as the texture. This is slower but at
least it should work.
|
|
When calling glBlitFramebuffer on most (if not all) mac that have a GPU
from the Radeon Pro series, the data is not properly copied and only a
subset of the pixels are correctly copied.
This only happens when blitting the depth buffer if the depth buffer is
GL_DEPTH24_STENCIL8.
Changing the depth buffer format to GPU_DEPTH32F_STENCIL8 fixes the issue
but only works if blitting the depth componnent. The stencil componnent
still provoke issues when being copied.
|
|
|
|
Previous Framebuffer can be NULL.
|
|
Apparently the registry is not large enough and the compiler does something bad in indexing the array.
|
|
This is caused by a driver bug that prevent us from rendering to (or even
binding) a texture mip level that is below GL_TEXTURE_MAX_LEVEL of the
target texture. This is fine in most drivers (and legal AFAIK) but not on
thoses Intels HDXXX + Windows.
As a fix we just put GL_TEXTURE_MAX_LEVEL lower (which is illegal because
it is undefined behaviour), but in practice it works ok and does not
trigger any warnings or errors.
This commit fixes most of the problems encountered on these GPUs (T56668).
|
|
|
|
|
|
|
