| Age | Commit message (Collapse) | Author |
|---|
|
This changes the drawing paradigm a bit. The VAO configuration is done
JIT-style and depends on context active shader.
This is to allow more flexibility for implementations to do optimization
at lower level.
The vao cache is now its own class to isolate the concept. It is this
class that is reference by the GLContext for ownership of the containing
VAO ids.
|
|
|
|
Also add new flags to communicate specific behavior to future backend.
|
|
We instead use a handle reference counter on the GPUVertBufs used by
the instancing batches. This make sure that if an update happens on the
GPUVertBuf used to contruct the batch, they will never have the same
memory address than the previously allocated ones (since they are still
pending deletion thanks to the refcounter).
This avoid the linear search to update the GPUBatch in the case a
batch is deleted (which was even a bad option since they could be only
cleared)
|
|
|
|
A handle refcount is here to avoid freeing of the GPUVertBuf datablock
if it is still referenced somewhere else.
This does not prevent deleting the actual data. This is to avoid too
much zombie data usage.
This is in order to avoid most hacks inside `draw_instance_data.c`.
|
|
This is in order to better encapsulate / isolate the drawing code.
|
|
|
|
|
|
|
|
This remove the use of batch->program and replace it with batch->shader.
This will allow GL abstraction latter.
|
|
|
|
|
|
It was impossible for drivers to use shape key properties, modifiers
generate a new mesh. After mesh evaluation the shape keys are no longer
necessary, and because of this the `key` pointer was not copied. As
drivers work on evaluated data, however, they do need this `key`
pointer.
This commit makes the `key` pointer available in evaluated meshes, but
this is somewhat dangerous. There was an explicit reason why the key on
result was kept at null pointer: to have the evaluated mesh in a
consistent state. Assigning this pointer makes it potentially
inconsistent, as the evaluated mesh and the original shape key may have
different topologies.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7785
|
|
|
|
|
|
It was always possible to set it to zero by typing in the value.
This new soft limit is more consistent with the fluid cache
and the Scene.frame_start property.
|
|
|
|
Missed this comment when updating fix for T77409.
|
|
|
|
|
|
|
|
|
|
|
|
This was a regression in deaff945d0b9 which skips copying a mesh.
Dupli-verts/faces were not updated to account for this.
This supports iterating over edit-mesh vertices & faces,
since falling back to a full copy (as we do in some places)
will be slow while transforming geometry.
This commit looks as if it would change behavior with orcos,
since any edit-mesh deformation causes them to be assigned.
However in practice there is no functional change, details in comments.
|
|
Two sided faces aren't supported and would cause many issues elsewhere.
|
|
Dupli verts/faces named these arguments differently.
|
|
Replace the evaluated mesh with VertexDupliData.mvert since only
vertices are used. This makes dupli-vert similar to how dupli-face
was already working.
|
|
De-duplicate mesh access & comments.
|
|
Needed for supporting edit-mode dupli-verts.
Currently the un-scaled short values are used to avoid
changing behavior (noted in comments).
|
|
|
|
Make it obvious which values are used read-only, which are written to.
|
|
|
|
Disable antialiasing which caused artifacts.
Differential Revision: https://developer.blender.org/D8497
|
|
|
|
|
|
|
|
|
|
|
|
When using constant falloff symmetry was working fine because the same
deformation is applied twice on the same vertices. When using no
constant falloffs, the deformation is different between symmetry passes,
so vertices need to be separated by symmetry areas to get the right
deformation from its symmetry pass without being overwriten by the next
one.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D8541
|
|
This was missing in previous commit
|
|
This adds the boundary_falloff_type and boundary_offset to control how the
falloff of the Boundary Brush is applied.
Boundary Origin Offset is the same concept as the Pose Origin offset in
the Pose Brush. It is a multiplier that adds extra length to the brush
radius to locate the deformation pivot further from the boundary without
affecting the falloff.
The Falloff type includes Constant (previous default), brush radius, loop
and loop and invert. Loop and Loop and Invert can be used to create
deformation patterns in a mesh.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D8526
|
|
The only_stroke parameter is not used
|
|
Now the list of materials is cleanup and any duplicated material is removed.
|
|
This is required in other places and need to be shared.
|
|
When two similar colors were adjacent, the colors were not merged.
|
|
When the color was black, the original value was not initialized and get a NaN value with unexpected results.
Also cleanup code.
|
|
|
|
|
|
This allows to resample the stroke to avoid too dense geometry.
|
