| Age | Commit message (Collapse) | Author |
|---|
|
This avoid conflicting defines in GLSL
Fix T96998 Blender 3.2.0 Alpha crashes on startup
|
|
|
|
UV editor used wire color for drawing unselected vertices.
Add color variable to shader, so theme color can be used.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D14373
|
|
|
|
This function was not used for anything other than mat4. This
was because of a limitation of the DRW module/
This makes it cleaner for the GLSL and also less tempting to use
it for other unconventional purpose.
|
|
Explicit constructor for mat3 from a mat4 is not valid and cannot be overloaded.
Adding explicit texture resource type flags for depth textures. This is an explicit requirement for Metal Shading language. This is a temporary compatibility, as this path is already supported in GPU_SHADER_CREATE_INFO under ImageType::DEPTH_2D, though required in shader source for MSL shaders which do not have create info.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14418
|
|
Should have no regression.
|
|
This should have no regression.
|
|
Metal shading language follows the C++ 14 standard and in some cases requires a greater level of explicitness than GLSL. There are also some small language differences:
- Explicit type-casts (C++ requirements)
- Explicit constant values (C++ requirements, e.g. floating point values using 0.0 instead of 0).
- Metal/OpenGL compatibility paths
- GLSL Function prototypes
- Explicit accessors for vector types when sampling textures.
Authored by Apple: Michael Parkin-White
Ref T96261
Reviewed By: fclem
Maniphest Tasks: T96261
Differential Revision: https://developer.blender.org/D14378
|
|
|
|
This reverts commit 1558b270e9fcbc2e23fa248b0e7e770dddae155c.
An earlier commit (rB101fadcf6b93c) introduced some new functionality,
which was overlooked in reviewing this commit & got broken.
Will re-commit after the issue has been fixed.
Ref: D13687
|
|
Regression in 3267c91b4d5caab7da8aef071a446dd2e86f86a9.
|
|
|
|
This fixes the second part of T93573 that 8506f3d9fe9359518e didn't
properly address. Specifically, outlines of instances still had the
selected color in edit mode in wireframe view. This change is the
same as that commit, just in a different place.
Differential Revision: https://developer.blender.org/D14229
|
|
This patch adds edge selection support for UV editing (refer T76545).
Developed as a part of GSoC 2021 project - UV Editor Improvements.
Previously, selections in the UV editor always flushed down to vertices
and this caused multiple issues such as T76343, T78757 and T26676.
This patch fixes that by adding edge selection support for all UV
operators and adding support for flushing selections between vertices
and edges. Updating UV select modes is now done using a separate
operator, which also handles select mode flushing and undo for UV
select modes. Drawing edges (in UV edge mode) is also updated to match
the edit-mesh display in the 3D viewport.
Notes on technical changes made with this patch:
* MLOOPUV_EDGESEL flag is restored (was removed in rB9fa29fe7652a).
* Support for flushing selection between vertices and edges.
* Restored the BMLoopUV.select_edge boolean in the Python API.
* New operator to update UV select modes and flushing.
* UV select mode is now part of editmesh undo.
TODOs added with this patch:
* Edge support for shortest path operator (currently uses vertex path logic).
* Change default theme color instead of reducing contrast with edge-select.
* Proper UV element selections for Reveal Hidden operator.
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D12028
|
|
|
|
This commit removes the outline from instances generated from an object
when in edit mode. This takes the change in aa13c4b386b1 a bit further,
with the idea that instance outlines are more like regular outlines.
Because evaluated object data that doesn't match the original object
type is treated as an instance internally, this fixes the way evaluated
meshes for curves objects have an outline, for example.
See the differential revision for a visual comparison.
Differential Revision: https://developer.blender.org/D14226
|
|
Motion paths can now be initialised to more sensible frame ranges,
rather than simply 1-250:
- Scene Frame Range
- Selected Keyframes
- All Keyframes
The Motion Paths operators are now also added to the Object context menu
and the Dopesheet context menu.
The scene range operator was removed, because the operators now
automatically find the range when baking the motion paths.
The clear operator now appears separated in "Selected Only" and "All",
because it was not clear for the user what the button was doing.
Reviewed By: sybren, looch
Maniphest Tasks: T93047
Differential Revision: https://developer.blender.org/D13687
|
|
|
|
This fixes a crash on selected platforms.
|
|
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
|
|
This adds initial support for edit mode for the experimental new curves
object. For now we can only toggle in and out of the mode, no real
interraction is possible.
This patch also adds empty menus in edit mode. Those were added mainly
to quiet warnings as the menus are programmatically added to the edit
mode based on the object type and context.
Ref T95769
Reviewed By: JacquesLucke, HooglyBoogly
Maniphest Tasks: T95769
Differential Revision: https://developer.blender.org/D14136
|
|
This adds the boilerplate code that is necessary to use the tool/brush/paint
systems in the new sculpt curves mode.
Two temporary dummy tools are part of this patch. They do nothing and
only serve to test the boilerplate. When the first actual tool is added,
those dummy tools will be removed.
Differential Revision: https://developer.blender.org/D14117
|
|
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
|
|
|
|
Viewport cull bones during selection to avoid depth-picking
reading the depth buffer for bones that aren't in the viewport.
Files with thousands of bones could hang blender for seconds while
selecting. The issue could still happen with overlapping bones or when
zoomed out so all bones are under the cursor, however in practice this
rarely happens.
Now files with many bones select quickly.
Related changes include:
- Split `BKE_pchan_minmax` out of `BKE_pose_minmax`.
- Add `mat3_to_size_max_axis` to return the length of the largest
axis (used for scaling the radius).
Reviewed By: sybren
Maniphest Tasks: T91253
Ref D13990
|
|
Based on discussions from T95355 and T94193, the plan is to use
the name "Curves" to describe the data-block container for multiple
curves. Eventually this will replace the existing "Curve" data-block.
However, it will be a while before the curve data-block can be replaced
so in order to distinguish the two curve types in the UI, "Hair Curves"
will be used, but eventually changed back to "Curves".
This patch renames "hair-related" files, functions, types, and variable
names to this convention. A deep rename is preferred to keep code
consistent and to avoid any "hair" terminology from leaking, since the
new data-block is meant for all curve types, not just hair use cases.
The downside of this naming is that the difference between "Curve"
and "Curves" has become important. That was considered during
design discussons and deemed acceptable, especially given the
non-permanent nature of the somewhat common conflict.
Some points of interest:
- All DNA compatibility is lost, just like rBf59767ff9729.
- I renamed `ID_HA` to `ID_CV` so there is no complete mismatch.
- `hair_curves` is used where necessary to distinguish from the
existing "curves" plural.
- I didn't rename any of the cycles/rendering code function names,
since that is also used by the old hair particle system.
Differential Revision: https://developer.blender.org/D14007
|
|
Dashed line display was changed since 2.7x, using white on black
instead of grey on black.
This made selection difficult to see as white is brighter
than the default selected color.
Match the grey used in 2.7x.
|
|
|
|
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
|
|
These aren't used for picking bones so there is no need to draw them.
|
|
In order to use a workaround builtin uniform, we need to count it
just like other uniforms and give it some space in the name buffer.
This also fixes extensions being added after the uniform declaration.
All `#extension` directives are now part of the gl backend.
|
|
The evaluated mesh is a result of evaluated modifiers, and referencing
other evaluated IDs such as materials.
It can not be stored in the EditMesh structure which is intended to be
re-used by many areas. Such sharing was causing ownership errors causing
bugs like
T93855: Cycles crash with edit mode and simultaneous viewport and final render
The proposed solution is to store the evaluated edit mesh and its cage in
the object's runtime field. The motivation goes as following:
- It allows to avoid ownership problems like the ones in the linked report.
- Object level is chosen over mesh level is because the evaluated mesh
is affected by modifiers, which are on the object level.
This patch allows to have modifier stack of an object which shares mesh with
an object which is in edit mode to be properly taken into account (before
the change the modifier stack from the active object will be used for all
objects which share the mesh).
There is a change in the way how copy-on-write is handled in the edit mode to
allow proper state update when changing active scene (or having two windows
with different scenes). Previously, the copt-on-write would have been ignored
by skipping tagging CoW component. Now it is ignored from within the CoW
operation callback. This allows to update edit pointers for objects which are
not from the current depsgraph and where the edit_mesh was never assigned in
the case when the depsgraph was evaluated prior the active depsgraph.
There is no user level changes changes expected with the CoW handling changes:
should not affect on neither performance, nor memory consumption.
Tested scenarios:
- Various modifiers configurations of objects sharing mesh and be part of the
same scene.
- Steps from the reports: T93855, T82952, T77359
This also fixes T76609, T72733 and perhaps other reports.
Differential Revision: https://developer.blender.org/D13824
|
|
Custom bones are drawn by instancing the GPUBatch of the base object. To
access the mesh and its GPUBatch, `BKE_object_get_evaluated_mesh` was
used. However, since GPU subdivision support, this will return a
subdivision wrapper which will never be drawn, and thus will have an
invalid batch, which caused the crash.
`BKE_object_get_evaluated_mesh_no_subsurf` should be used instead, to
return the mesh that will be drawn, and have the subdivision evaluated
on the GPU. Note that the rest of the draw code is already using this
function.
|
|
This adds vertex creasing support for OpenSubDiv for modeling, rendering,
Alembic and USD I/O.
For modeling, vertex creasing follows the edge creasing implementation with an
operator accessible through the Vertex menu in Edit Mode, and some parameter in
the properties panel. The option in the Subsurf and Multires to use edge
creasing also affects vertex creasing.
The vertex crease data is stored as a CustomData layer, unlike edge creases
which for now are stored in `MEdge`, but will in the future also be moved to
a `CustomData` layer. See comments for details on the difference in behavior
for the `CD_CREASE` layer between egdes and vertices.
For Cycles this adds sockets on the Mesh node to hold data about which vertices
are creased (one socket for the indices, one for the weigths).
Viewport rendering of vertex creasing reuses the same color scheme as for edges
and creased vertices are drawn bigger than uncreased vertices.
For Alembic and USD, vertex crease support follows the edge crease
implementation, they are always read, but only exported if a `Subsurf` modifier
is present on the Mesh.
Reviewed By: brecht, fclem, sergey, sybren, campbellbarton
Differential Revision: https://developer.blender.org/D10145
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
When weight painting the bone overlay is extremely intrusive,
effectively requiring either extensive use of hiding individual
bones, or disabling the whole bone overlay between selections.
This addresses the issue by adding a bone opacity slider that
is used for the 'wireframe' armature drawing mode. It directly
controls the uniform opacity as a straightforward option.
Differential Revision: https://developer.blender.org/D11804
|
|
This evaluator is used in order to evaluate subdivision at render time, allowing for
faster renders of meshes with a subdivision surface modifier placed at the last
position in the modifier list.
When evaluating the subsurf modifier, we detect whether we can delegate evaluation
to the draw code. If so, the subdivision is first evaluated on the GPU using our own
custom evaluator (only the coarse data needs to be initially sent to the GPU), then,
buffers for the final `MeshBufferCache` are filled on the GPU using a set of
compute shaders. However, some buffers are still filled on the CPU side, if doing so
on the GPU is impractical (e.g. the line adjacency buffer used for x-ray, whose
logic is hardly GPU compatible).
This is done at the mesh buffer extraction level so that the result can be readily used
in the various OpenGL engines, without having to write custom geometry or tesselation
shaders.
We use our own subdivision evaluation shaders, instead of OpenSubDiv's vanilla one, in
order to control the data layout, and interpolation. For example, we store vertex colors
as compressed 16-bit integers, while OpenSubDiv's default evaluator only work for float
types.
In order to still access the modified geometry on the CPU side, for use in modifiers
or transform operators, a dedicated wrapper type is added `MESH_WRAPPER_TYPE_SUBD`.
Subdivision will be lazily evaluated via `BKE_object_get_evaluated_mesh` which will
create such a wrapper if possible. If the final subdivision surface is not needed on
the CPU side, `BKE_object_get_evaluated_mesh_no_subsurf` should be used.
Enabling or disabling GPU subdivision can be done through the user preferences (under
Viewport -> Subdivision).
See patch description for benchmarks.
Reviewed By: campbellbarton, jbakker, fclem, brecht, #eevee_viewport
Differential Revision: https://developer.blender.org/D12406
|
|
Also add groups in some files.
|
|
Ref T92709
|
|
In the original design draw engines had to copy with a limitation that
they were not allowed to reuse complex data structures between drawing
calls. Data that could be reused were limited to:
- GPUFramebuffers
- GPUTextures
- Memory that could be removed calling MEM_freeN (storage list)
- DRWPass
This is fine when the storage list contains arrays or structs but when
more complex data types (vectors, maps) etc wasn't possible.
This patch adds instance_data that can be reused between drawing calls.
The instance_data is controlled by the draw engine and doesn't need to
be limited as described above.
When an engines stores instance_data it must implement the
`DrawEngineType.instance_free` callback to free the data.
The patch originates from eevee rewrite. But was added to master as the
image engine rewrite also has a need for it.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D13425
|
|
Wire-only meshes have a special case in the overlay drawing to give
the wire shader a special color (which avoids the lines being dashed,
somehow). The fast path for duplis didn't have that special case.
Differential Revision: https://developer.blender.org/D13196
|
|
The problem is that drw_batch_cache_generate_requested_delayed
is called on the object, which uses the original object data type to
choose which data type to get info for. So for curves and text it uses
the incorrect type (not the evaluated mesh like we hardcoded in the
armature overlay code).
To fix this I hardcoded the "delayed" generation to only use the
evaluated mesh. Luckily it wasn't use elsewhere besides this
armature overlay system. That seems like the simplest fix for
3.0. A proper solution should rewrite this whole area anyway.
Differential Revision: https://developer.blender.org/D13439
|
|
This part of the drawing code assumes that the bone custom object
has only one evaluated geometry component, and it also uses the
object type to check which data to draw, with the functions like
`DRW_cache_object_surface_get` that just take an object input.
Those functions usually work on evaluated objects, which use the
instancing system to access a temporary object with `object.data`
replaced for data types that don't match the original object.
That assumption used to work, but now curve, point cloud, or volume
objects can have an evaluated mesh which is not accessed with the
same object for render engine drawing.
The "correct" solution for the way this code is structured would be to
loop through all of the geometry components and try to get GPU batches
from every one of them. However, that significantly increases complexity
in an area that should probably be refactored anyway. This patch treats
the mesh as a special case, and only draws the evaluated mesh.
The **best** solution in my opinion might be refactoring this area to
use the instancing system with some sort of viewport-only flag so
the custom shape instances aren't added in the render.
The solution is "partial" because the "Wireframe" option only works
for meshes from mesh objects, even after this fix, and because other
data besides meshes is not displayed at all.
Differential Revision: https://developer.blender.org/D13038
|
|
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
|
|
|
|
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 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 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.
|
|
Match API naming prefix (BKE_vfont_*) and DNA_vfont_types.h.
|
