| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
This was caused by `DRW_view_data_texture_list_size_validate` which now
delete everything from the render engine.
This might change in the future but for now we just avoid calling it from
the render loop (when using DRW_cache_restart).
|
|
|
|
There were several places attempting to check to see if scene lights
and world were enabled for display. This tries to find a common place
for both of these to reduce duplication.
Honestly, I couldn't find a really good spot for these and settled on
DRW_engine. It's not the best spot since they're not strictly drawing
related, but let's start here.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D12658
|
|
Caused by tricky state tracking. `GPU_framebuffer_bind()` is updating
the framebuffer on first time and will reset the viewport state of it.
|
|
Stereo viewport means the depth buffer is use twice as often as a
framebuffer attachment.
|
|
This was caused by camera background being rendered in world space, causing
floating point imprecision issues when camera was far from origin.
Adding a uniform to change vertex shader to process everything in viewspace
to fix the problem.
|
|
By argument naming and convention this is the intended argument order.
|
|
|
|
The planar reflections being rendered at the same resolution as the HiZ max
buffer, do not need any uv correction during raytracing.
However, the GTAO horizon buffer being at output resolution do need the
uv factors in order to match the pixels visible on screen. To avoid many
complication, we increase the size of the GTAO texture up to the hiz buffer
size. This way, if planar reflections need GTAO the texture is big enough.
We change the viewport of the GTAO framebuffer for the main view in order
to not have to modify Uvs in many places.
|
|
These 2 large tables, `areaTexBytes` and `searchTexBytes`, contributed
~176kb worth of duplicate data into the `blender` executable due to the
header being used in multiple places. We were lucky that only 2
translation units had included this header so only 1 duplicate copy of
each was wasted.
Define the tables as `extern` to address this.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D12723
|
|
There was a double lock in the object depth drawing function.
Also the texture read was not reading the texture with the right
format. Now it needs a conversion.
Fix T91981 Particle Edit make Blender Crash
Fix T92006 Light spot interactively point can't use
|
|
Addresses T77127 (Controller Drawing).
Adds VR controller visualization and custom drawing via draw
handlers. Add-ons can draw to the XR surface (headset display) and
mirror window by adding a View3D draw handler of region type 'XR' and
draw type 'POST_VIEW'. Controller drawing and custom overlays can be
toggled individually as XR session options, which will be added in a
future update to the VR Scene Inspection add-on.
For the actual drawing, the OpenXR XR_MSFT_controller_model extension
is used to load a glTF model provided by the XR runtime. The model's
vertex data is then used to create a GPUBatch in the XR session
state. Finally, this batch is drawn via the XR surface draw handler
mentioned above.
For runtimes that do not support the controller model extension, a
a simple fallback shape (sphere) is drawn instead.
Reviewed By: Severin, fclem
Differential Revision: https://developer.blender.org/D10948
|
|
- Use 2D cursor in the preview space using shortcuts
matching the UV editor and 3D view.
- Add Cursor tool, cursor transform.
- Support for cursor and bound-box pivot.
- Add pivot pie menu.
|
|
Match API naming prefix (BKE_vfont_*) and DNA_vfont_types.h.
|
|
|
|
|
|
Issue is that test cases re-uses draw manager. The new
`DRWRegisteredDrawEngine` struct is only freed when a
valid opengl context was found. what isn't the case
when running test cases.
Also made sure that re-using draw manager would use re-inited
values.
|
|
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
|
|
|
|
Implements T89789, T89792, custom grid (described as dynamic grid in
T78389) and UV grid snapping (T78391)
Replaces the default UV editor grid with 2 new types of grid :
* Custom grid: Allows the user to create an NxN grid, where the value
of N is specified by the user.
* Subdividing grid: Subdivides the UV editor grid when the user
zooms in the viewport and vice versa when zooming out.
UV snapping improvements :
* Increment snapping: Increment values for snapping are calculated based
on which grid type is being used in the UV editor
(subdividing or custom). In general the increment value is equal to
the distance between 2 visible grid lines.
* Absolute grid snap: New toggle added to increment snapping option in
the UV editor, allows UV grid snapping during translation.
Reviewed By: campbellbarton
Ref D12684
|
|
|
|
|
|
|
