Age | Commit message (Collapse) | Author |
|
A recent security update to macOS 10.15.7 causes crashes when using Eevee and
various other 3D viewport features. It appears that glGenerateMipmap is
broken, causing a crash whenever its commands are flushed/submitted to the GPU.
Ideally this would be fixed in a driver update, however it's unlikely this will
happen. Earlier macOS versions have been receiving security updates for 2 years,
and that window has just passed for 10.15. Further, computers with these GPUs
can't upgrade to a newer macOS version.
As a workaround, disable mipmaps on these GPUs, by setting the mipmap max level
to 0 and not calling glGenerateMipmaps. Effects like depth of field also use
mipmaps, but fill in the mip levels by other means. In those cases we keep the
mipmap level.
Differential Revision: https://developer.blender.org/D13295
|
|
Issue introduced in {7e66616b7e15} where the shader was replaced with a
2d image shader. This patch reverts several commits that removed the 3d
image shader.
|
|
We run into float precision issues here, clamp the number of octaves to
one less, which has little to no visual difference. This was empirically
determined to work up to 16 before, but with additional inputs like
roughness only 15 appears to work.
Also adds misisng clamp for the geometry nodes implementation.
|
|
Simple oversight.
|
|
Avoid using underscore prefix since these typically mean the variable
shouldn't be accessed directly (it may be accessed from a macro,
or memory on the stack which is assigned to a pointer).
In this case a more meaningful name can be used for the argument
that was shadowed.
|
|
This reverts commit e7fedf6dba5fe2ec39260943361915a6b2b8270a.
And also fix a compilation issue on windows.
Differential Revision: https://developer.blender.org/D12969
|
|
This reverts commit 03013d19d16704672f9db93bc62547651b6a5cb8.
This commit broke the windows build pretty badly and I don't
feel confident landing the fix for this without review.
Will post a possible fix in D12969 and we'll take it from there.
|
|
This adds generic attribute rendering support for meshes for Eevee and
Workbench. Each attribute is stored inside of the `MeshBufferList` as a
separate VBO, with a maximum of `GPU_MAX_ATTR` VBOs for consistency with
the GPU shader compilation code.
Since `DRW_MeshCDMask` is not general enough, attribute requests are
stored in new `DRW_AttributeRequest` structures inside of a convenient
`DRW_MeshAttributes` structure. The latter is used in a similar manner
as `DRW_MeshCDMask`, with the `MeshBatchCache` keeping track of needed,
used, and used-over-time attributes. Again, `GPU_MAX_ATTR` is used in
`DRW_MeshAttributes` to prevent too many attributes being used.
To ensure thread-safety when updating the used attributes list, a mutex
is added to the Mesh runtime. This mutex will also be used in the future
for other things when other part of the rendre pre-processing are multi-threaded.
`GPU_BATCH_VBO_MAX_LEN` was increased to 16 in order to accommodate for
this design.
Since `CD_PROP_COLOR` are a valid attribute type, sculpt vertex colors
are now handled using this system to avoid to complicate things. In the
future regular vertex colors will also use this. From this change, bit
operations for DRW_MeshCDMask are now using uint32_t (to match the
representation now used by the compiler).
Due to the difference in behavior for implicit type conversion for scalar types
between OpenGL and what users expect (a scalar `s` is converted to
`vec4(s, 0, 0, 1)` by OpenGL, vs. `vec4(s, s, s, 1)` in Blender's various node graphs) ,
all scalar types are using a float3 internally for now, which increases memory usage.
This will be resolved during or after the EEVEE rewrite as properly handling
this involves much deeper changes.
Ref T85075
Reviewed By: fclem
Maniphest Tasks: T85075
Differential Revision: https://developer.blender.org/D12969
|
|
```
warning: assignment discards ‘const’ qualifier from pointer target
warning: declaration of ‘co’ shadows a parameter
```
|
|
The drag and drop feature of objects in 3D View has been modified to include:
- Snap the object being dragged.
- Visual feedback through a box and the placement tool grid.
Maniphest Tasks: T90198
Differential Revision: https://developer.blender.org/D12912
|
|
|
|
This patch includes code from D9891 and D12754, so credit goes to Juanfran and Dalai.
I updated the patches to work with `master` and with the new overlay toggle.
The reason to include both changes as part of one patch is that the dimmed dashed lines work much better together with colored wires.
Theme setting for dash opacity:
{F11370574, size=full}
{F11286177, size=full, autoplay, loop}
{F11149912, size=full}
For adding the overlay I used `SpaceImageOverlay` as reference, although I'm not familiar with this code so there might be mistakes.
Reviewed By: #user_interface, HooglyBoogly
Differential Revision: https://developer.blender.org/D12886
|
|
|
|
Stereo viewport means the depth buffer is use twice as often as a
framebuffer attachment.
|
|
This was due to the shading evaluation being outdated inside the ShaderToRGBA
glsl code.
|
|
No functional change, just cleaning up the shader code a bit.
Part of this is removing dead code (the discard was never called), and
part is shuffling mix/max around based on feedback by Sybren Stüvel.
|
|
This is a necessary step for EEVEE's new arch. This moves more data
to the draw manager. This makes it easier to have the render or draw
engines manage their own data.
This makes more sense and cleans-up what the GPUViewport holds
Also rewrites the Texture pool manager to be in C++.
This also move the DefaultFramebuffer/TextureList and the engine related
data to a new `DRWViewData` struct. This struct manages the per view
(as in stereo view) engine data.
There is a bit of cleanup in the way the draw manager is setup.
We now use a temporary DRWData instead of creating a dummy viewport.
Development: fclem, jbakker
Differential Revision: https://developer.blender.org/D11966
|
|
|
|
|
|
This fixes T91828.
The current value of `GL_PACK_ALIGNMENT` may result in crash in the `gpu` module if the buffer is not aligned.
Differential Revision: https://developer.blender.org/D12720
|
|
Replacement for float curve in legacy Attribute Curve Map node.
Float Curve defaults to [0.0-1.0] range.
Reviewed By: JacquesLucke, brecht
Differential Revision: https://developer.blender.org/D12683
|
|
Use dashes to represent the function flow (while keeping continuous
lines for the data-flow).
It is important to tell both flows apart (the data and the function
flow). The sockets help with that, the noodles help this further.
The "data flow" is evaluated at every single node. A user can inspect
the output sockets of those nodes and have a glimpse at their values.
The "function flow" (nodes) however is only evaluated in the geometry
nodes. The noodles are not transporting data in the same sense of the
"data flow". All that can be inspected are the attributes the functions
depend on.
Having this clearly communicated should help users to inspect the
nodetrees, read and understand the different flows in the same tree.
---
Known limitations:
At the moment the dash lines are not equidistant:
* It would be nice to get the "uv.x" to be resampled for the bezier curve
so the dashes are equally distributed in the curve.
* Using distance between the P3 and P0 instead of the real bezier curve
length seems to be fine.
---
Full disclaimer:
Changes with that much of a visual impact tend to be controversial. So
far the main feedback is that dashed lines can be associated to broken
link, and that there are better ways to represent the flows (or
different information that should be visually represented).
I'm fully aware of that. However dashed lines are already used in the
viewport and outliner to indicate (hierarchical) relation. Besides,
other approaches (double-lines, having the data flow to be more
distinct, ...) didn't pan out in the end (or didn't look as good as
this).
---
Impact in other editors:
The compositor uses mostly a "data flow" nodetree, so no change is
expected there.
The shader nodetree is one that could but doesn't have to change its
visual language.
The shader nodetree uses mostly "function flow" with some "data flow" nodes.
One can argue that it should be adapted to follow the
same pattern as geometry nodes (with the new noodles and the diamond
sockets). Oh the other hand, a shader nodetree has a single context.
When a node depends on the "UV", there is only one UV at a time for the
entire nodetree. So it can also be treated as a psedo "data flow"
nodetree if we want to avoid too many changes in other parts of Blender.
Differential Revision: https://developer.blender.org/D12602
|
|
This makes it easier to spot which links contain fields and which
contain data. Actually, the patch makes all other links a bit thicker.
However, with soon-to-be-implemented theme changes, the
perceived thickness will be the same as before.
This is part of T91563.
Differential Revision: https://developer.blender.org/D12646
|
|
This patch fixes Eevee-regression https://developer.blender.org/T91697
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D12634
|
|
Previously, it was a diamond shape when the overall
shape was a diamond.
|
|
|
|
Goal is to add the length attribute to the Hair Info node, for better control over color gradients or similar along the hair.
Reviewed By: #eevee_viewport, brecht
Differential Revision: https://developer.blender.org/D10481
|
|
No functional change.
The shader is complicated by itself, having hardcoded values makes it
even more cryptic.
I also renamed the shader because the shader is not for the keyfarme diamond only,
but for all the keyframe shapes.
Differential Revision: https://developer.blender.org/D12615
|
|
|
|
This includes much improved GPU rendering performance, viewport interactivity,
new shadow catcher, revamped sampling settings, subsurface scattering anisotropy,
new GPU volume sampling, improved PMJ sampling pattern, and more.
Some features have also been removed or changed, breaking backwards compatibility.
Including the removal of the OpenCL backend, for which alternatives are under
development.
Release notes and code docs:
https://wiki.blender.org/wiki/Reference/Release_Notes/3.0/Cycles
https://wiki.blender.org/wiki/Source/Render/Cycles
Credits:
* Sergey Sharybin
* Brecht Van Lommel
* Patrick Mours (OptiX backend)
* Christophe Hery (subsurface scattering anisotropy)
* William Leeson (PMJ sampling pattern)
* Alaska (various fixes and tweaks)
* Thomas Dinges (various fixes)
For the full commit history, see the cycles-x branch. This squashes together
all the changes since intermediate changes would often fail building or tests.
Ref T87839, T87837, T87836
Fixes T90734, T89353, T80267, T80267, T77185, T69800
|
|
Added optional `name` argument to `GPUShader` constructor
(defaults to `pyGPUShader`), and added `name` getter to `GPUShader`.
Ref D12393
Reviewed By: campbellbarton, jbakker
|
|
Some GPU's have support for compute shaders, but don't support
GLSL 4.3. This resulted in compiler errors and crashes.
This issue could have been solved by supporting older GLSL languages but
that would have been a hassle to get it right. We already have a
fallback in place for GPU's that don't support compute shaders at all.
|
|
|
|
|
|
The parameter name was inconsistent between declaratation
and implementation.
|
|
|
|
This addresses reduced visibility of scenes (as displayed in the VR
headset) that can result from the 8-bit color depth format currently
used for XR swapchain images.
By switching to a swapchain format with higher color depth (RGB10_A2,
RGBA16, RGBA16F) for supported runtimes, visibility in VR should be
noticeably improved.
However, current limitations are lack of support for these higher
color depth formats by some XR runtimes, especially for OpenGL.
Also important to note that GPU_offscreen_create() now explicitly
takes in the texture format (eGPUTextureFormat) instead of a
"high_bitdepth" boolean.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D9842
|
|
While trying to get Blender 2.93.x LTS to build fine on all release architectures in Debian, I noticed that the misleading use of "mips" as integer variable caused problems when compiling on mips64el. The patch should fix the issue.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D12194
|
|
ID data-blocks that could be accessed from Python and weren't freed
using BKE_id_free_ex did not release the Python reference count.
Add BKE_libblock_free_data_py function to clear the Python reference
in this case.
Add asserts to ensure no Python reference is held in situations
when ID's are copied for internal use (not exposed through the RNA API),
to ensure these kinds of leaks don't go by unnoticed again.
|
|
|
|
|
|
To solve this, the unproject code was redone in order to simplify and optimize.
|
|
|
|
rBfb87d236edb7 made the values returned by `projmat_dimensions` more
standardized following the documentations. But the functions in Blender
that called `projmat_dimensions` followed a proposal that these values
corresponded to a distance of 1m of clip.
Adjust these functions to follow the new algorithm.
|
|
This patch fixes an issue with missing faces when assigning a material slot other than the first to faces on AMD TAHITI cards. Refer to T78390 and T74024 for a description of this issue.
This patch also incorporates fix from T78390 for KAVERI.
{F9029258}
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D9305
|
|
|
|
|
|
|
|
|
|
|