* Fixed PBVH_FACES vcol draw bug.
* Fixed boundary smooth being turned on
if its temp customdata layer exists.
* Fixed unnesting of brush panels from
last commit improperly showing up
in the workspace tab for sculpt
instead of the brush tab.
* PBVH drawing for eevee is now used for
PBVH_FACES as well as PBVH_BMESH.
* PBVH_FACES now uses pbvh draw for eevee rendering
* Refactored gpu_pbvh_gpu_make_vcol_offs into a
more general gpu_pbvh_gpu_make_attr_offs.
This should be a usable alternative to using a generic
attribute gpu system (whether the one that's #ifdef'd out
in gpu_buffers.c, or the new one that hit master
recently).
* Textured workbench draw mode now works for pbvh drawing.
* Fixed nasty stack overflow in dyntopo edge collapse.
* PBVH_BMESH construction is now partially
threaded.
* Fixed n**2 behavior in freelist-based
bmesh id implementation. I'd really
rather get range-tree faster, but
this works as a stopgap.
* Removed a bunch of debug ATTR_NO_OPTs.
* Mesh now has a render_color_index member.
+ We really need an attribute ref system
based on (domain, type, name) triplets.
* RNA uses render_color_index in all three
cases (loop colors, vert colors, and
the generic attribute types).
* PBVH draw uses render_color_index too.
UI list.
* Added an index to Mesh for active color attribute.
This seems janky to me, shouldn't this (along
with the active attribute index) be a
domain, name, cdtype triplet?
* Added a little api to preserve the active attribute
and color indices when changing mesh customdata
layouts. See above comment.
* The vertex color panel is now completely unified.
* TODO: allow setting render color layer (not sure how
to do this).
Adds a `wmOperatorCallContext` typedef for the existing `WM_OP_XXX`
operator context enum. This adds type safety, allows the compiler to
produce better warnings and helps understanding what a variable is for.
Differential Revision: https://developer.blender.org/D13113
Reviewed by: Campbell Barton
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.
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 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
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
* You can now edit brush input mappings
inside the main workspace brush panels.
* PBVH_CHECK_NAN now limits how many reports
it prints from a given source file.
* Fixed various problems with shift-smooth strength
setting.
* Fixed a NaN in the smoothing code.
* The dyntopo collapse function now
properly snaps UVs, including at
island boundaries.
* PBVHTriBufs are now split by UVs
(and face sets); this turned out
to be surprising easy.
* Also fixed a few bugs relating to
hiding/revealing stuff.
* Brush radius wasn't being calculated correctly if symmetry was on.
* Unnessed SCULPT_run_commandlist, it now calls
do_symmetrical_brush_actions instead of the reverse.
* Renamed MDynTopoVert to MSculptVert. Old name didn't
make sense given that all three PBVH types now use it.
Mercifully it's never saved in files, and even if it
somehow was saved the CD file loading code checks for
that.
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
* BrushChannel now uses its refine callback to
generate new structs for individual BrushChannelType's.
- It generates a .value member that's a copy of
one of the exisitng float_ bool_ enum_ etc_value members.
- Haven't figured out how to delete the XXX_value members
yet though.
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
