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 reverts commit 03013d19d1.
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
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.
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
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
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/Cycleshttps://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
With this commit, curve objects support the geometry nodes modifier.
Curves objects now evaluate to `CurveEval` unless there was a previous
implicit conversion (tessellating modifiers, mesh modifiers, or the
settings in the curve "Geometry" panel). In the new code, curves are
only considered to be the wire edges-- any generated surface is a mesh
instead, stored in the evaluated geometry set.
The consolidation of concepts mentioned above allows remove a lot of
code that had to do with maintaining the `DispList` type temporarily
for modifiers and rendering. Instead, render engines see a separate
object for the mesh from the mesh geometry component, and when the
curve object evaluates to a curve, the `CurveEval` is always used for
drawing wire edges.
However, currently the `DispList` type is still maintained and used as
an intermediate step in implicit mesh conversion. In the future, more
uses of it could be changed to use `CurveEval` and `Mesh` instead.
This is mostly not changed behavior, it is just a formalization of
existing logic after recent fixes for 2.8 versions last year and two
years ago. Also, in the future more functionality can be converted
to nodes, removing cases of implicit conversions. For more discussion
on that topic, see T89676.
The `use_fill_deform` option is removed. It has not worked properly
since 2.62, and the choice for filling a curve before or after
deformation will work much better and be clearer with a node system.
Applying the geometry nodes modifier to generate a curve is not
implemented with this commit, so applying the modifier won't work
at all. This is a separate technical challenge, and should be solved
in a separate step.
Differential Revision: https://developer.blender.org/D11597
This patch allows dropping material assets from material slot under the mouse
cursor. Before this change the material slot had to be hand-picked from the
properties panel.
For consistency it is chosen to do this in any shading mode as the tooltip shows
what is exactly going to happen during release.
The feature also works for other object types than Meshes as it uses the drawn surface on the
GPU to detect the material slots. Performance of this patch has been tested with AMD GCN3.0
cards and are very responsive.
Reviewed By: fclem, Severin
Differential Revision: https://developer.blender.org/D12190
Previously, the Point Instance node in geometry nodes could only instance
existing objects or collections. The reason was that large parts of Blender
worked under the assumption that objects are the main unit of instancing.
Now we also want to instance geometry within an object, so a slightly larger
refactor was necessary.
This should not affect files that do not use the new kind of instances.
The main change is a redefinition of what "instanced data" is. Now, an
instances is a cow-object + object-data (the geometry). This can be nicely
seen in `struct DupliObject`. This allows the same object to generate
multiple geometries of different types which can be instanced individually.
A nice side effect of this refactor is that having multiple geometry components
is not a special case in the depsgraph object iterator anymore, because those
components are integrated with the `DupliObject` system.
Unfortunately, different systems that work with instances in Blender (e.g.
render engines and exporters) often work under the assumption that objects are
the main unit of instancing. So those have to be updated as well to be able to
handle the new instances. This patch updates Cycles, EEVEE and other viewport
engines. Exporters have not been updated yet. Some minimal (not master-ready)
changes to update the obj and alembic exporters can be found in P2336 and P2335.
Different file formats may want to handle these new instances in different ways.
For users, the only thing that changed is that the Point Instance node now
has a geometry mode.
This also fixes T88454.
Differential Revision: https://developer.blender.org/D11841
Remove redundant code for drawing text strings that contain only ASCII.
See D12293 for much more detail.
Differential Revision: https://developer.blender.org/D12293
Reviewed by Campbell Barton
`MeshBufferCache` is a struct representing a list of buffers.
As such, `GPUIndexBuf **tris_per_mat` is out of place as it does not
represent one of the buffers in the list.
In fact this member should be close to `GPUBatch **surface_per_mat` as
they are related.
The code for dependencies between buffer and batch had to be reworked
as it relies on the member's position.
Differential Revision: https://developer.blender.org/D12227
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
