| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This disables motion blur for geometry instances in eevee, which did
not work correctly anyway. See code comment for more details.
Differential Revision: https://developer.blender.org/D13334
|
|
For now made DRW_notify_view_update_offscreen static.
|
|
|
|
Reviewed By: fclem
Differential Revision: D13235
|
|
|
|
modifier, but only if the instanced objects material has a normal map assigned.
This is only a workaround to avoid the crash. The underlying issue is left
unfixed.
New report for tracking the underlying issue is T93223.
|
|
|
|
After rBb9febb54a492, the evaluated mesh from a curve is now presented
to render engines as a separate mesh object, but some code still assumed
that a curve object itself could have an evaluated mesh. However, this is
still true for surface objects and metaballs, which don't
use geometry sets yet.
Differential Revision: https://developer.blender.org/D13272
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
|
|
The Cycles accurate mode was removed, but the Eevee option for this has
a different meaning and should not have been removed. The Eevee accurate
makes cryptomatte accumulate for every sample, which Cycles has always
done regardless of any option.
|
|
|
|
The layers were not aliased properly for usage in the shaders.
Regression caused by rB03013d19d167.
|
|
|
|
rBaa13c4b386b13111 added a check for the active object
in drawing code, but it missed adding a check for the active
base before trying to retrieve its object.
|
|
|
|
With instancing becoming more common with geometry nodes,
instances are less of a separate thing and more of an essential part
of evaluated data. Displaying them with a separate outline, while
helpful in some cases, is not worth the lack of visibility or confusion
about selected/active status. Information about the performance
of the scene due to instancing is always available with the statistics
like vertex count, etc.
The problems were compounded by the fact that the instancing
system is used to output geometry components that don't correspond
to the object's original type. So this patch also fixes that problem.
Fixes T92079, T81010
Ref T91310
Differential Revision: https://developer.blender.org/D13133
|
|
|
|
This patch adds shader compilation tests for the basic engine in `shaders_test.cc`
Addresses T92701
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D13066
|
|
Adding virtual constructors to base classes.
|
|
|
|
Image engine is used to draw an image into a space. The current
structure wasn't clear and couldn't be easilly extended. This refactor
spliced the image draw engine into 3 main components.
- Space accessors: contains an interface to communicate with space data
(Image editor, UV Editor, Node Editor) in a common way. This reduced
the branching in the code base.
- DrawingMode: contains an interface to the used tactic to draw an image
inside the space framebuffer. Currently only one mode is implemented;
in the future there could be a separate drawing mode for huge images.
- ImageEngine: the core that connects the draw manager with the space
data and drawing mode.
|
|
|
|
|
|
External symbols in C files need
to be marked as such otherwise
the linker will not find them.
|
|
|
|
|
|
Previously, `ImageTile->ok` and `ImageUser->ok` were used to indicate
whether an image failed to load. There were three possible values
which (probably) had the following meanings:
* `0`: There was an error while loading the image. Don't try to load again.
* `1`: Default value. Try to load the image.
* `2`: The image was loaded successfully.
This image-wide flag did not make sense unfortunately, because loading
may work for some frames of an image sequence but not for others.
Remember than an image data block can also contain a movie.
The purpose of the `->ok` flag was to serve as an optimization to avoid
trying to load a file over and over again when there is an error (e.g. the
file does not exist or is invalid). To get the optimization back, the patch
is changing `MovieCache` so that it can also cache failed load attempts.
As a consequence, `ibuf` is allowed to be `NULL` in a few more places.
I added the appropriate null checks.
This also solves issues when image sequences are used with the
Image Texture node in Geometry nodes (also see D12827).
Differential Revision: https://developer.blender.org/D12957
|
|
|
|
|
|
|
|
Caused by own {rB5aa3167e48b2}.
Related commit: {rBebaa3fcedd23}.
For stereo renders, `BKE_image_is_multilayer` is true, however we seem
to get to down to `space_image_gpu_texture_get` [where this is called]
from `IMAGE_cache_init` with a NULL Image->RenderResult.
So what then happens is that `BKE_image_multilayer_index` is called and
even though it has an appropriate codepath for stereo, it earlies out
and does not set multi_index correctly.
Still a bit puzzled why RenderResult is NULL for a render, but since
other places also check for a valid RenderResult before going down the
_multilayer_ route (and doing _multiview_ instead), now do the same
thing, BKE_image_multiview_index is now called in these cases (and seems
to behave correctly, checked with layers and passes and all seems to
display correctly, either in stereo or choosing individual eyes).
thx @jbakker & @brecht for double-checking.
Maniphest Tasks: T92608
Differential Revision: https://developer.blender.org/D13063
|
|
|
|
Added namespace blender::draw::image_engine. Code is still C-a-like.
Only changed the obvious code style to CPP (structs, nullptr, casts).
|
|
This patch adds support for selecting pointclouds.
Since pointclouds were not properly drawn to the selection buffer (as diagonsed by output from `glReadPixels` and Renderdoc), they were not able to be selectable by depth picking or occlusion queries. In `basic_engine`, objects were rendered with a shader which draws to a depth buffer but only assumes a single position vertex attribute. Pointclouds, though, require at least another vertex attribute `pos_inst` which provides the instance offsets. Thus, this patch adds another shader variant for pointclouds which supports these two attributes and renders the points appropriately.
{F11652666}
Addresses T92415
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D13059
|
|
This patch adds support for selecting pointclouds.
Since pointclouds were not properly drawn to the selection buffer (as diagonsed by output from `glReadPixels` and Renderdoc), they were not able to be selectable by depth picking or occlusion queries. In `basic_engine`, objects were rendered with a shader which draws to a depth buffer but only assumes a single position vertex attribute. Pointclouds, though, require at least another vertex attribute `pos_inst` which provides the instance offsets. Thus, this patch adds another shader variant for pointclouds which supports these two attributes and renders the points appropriately.
{F11652666}
Addresses T92415
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D13059
|
|
This reverts commit a50f8b3fd8e74d7cc0f2224f110c85493acee1cc.
|
|
This patch adds support for selecting pointclouds.
Since pointclouds were not properly drawn to the selection buffer (as diagonsed by output from `glReadPixels` and Renderdoc), they were not able to be selectable by depth picking or occlusion queries. In `basic_engine`, objects were rendered with a shader which draws to a depth buffer but only assumes a single position vertex attribute. Pointclouds, though, require at least another vertex attribute `pos_inst` which provides the instance offsets. Thus, this patch adds another shader variant for pointclouds which supports these two attributes and renders the points appropriately.
{F11652666}
Addresses T92415
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D13059
|
|
|
|
Lattice wires are drawn as part of "Extras". Unlike the other types
details (Cameras, Lights, Lightprobes and Speakers), Lattices actually
have boundingboxes defined, so hide the lattice wires if only the
boundingbox is requested.
Maniphest Tasks: T88443
Differential Revision: https://developer.blender.org/D11343
|
|
|
|
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
|
|
This adjusts some calculations and visibility flags for XR viewports in
order to account for a possible scale factor in the XR view matrix.
This scale factor can be introduced via the XR session settings base
scale, which allows a viewer to begin their session at a specific
reference scale, or the XR session state navigation scale, which allows
a viewer to adjust their scale relative to the reference scale during
the session.
Reviewed by Severin as part of D11501, but requested to be committed
separately.
|
|
|
|
|
|
|
|
|
