| Age | Commit message (Collapse) | Author |
|---|
|
This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
This previously caused a bug in T74283, that should be fixed now.
Differential Revision: https://developer.blender.org/D6695
|
|
than mesh"
This reverts commit f2b95b9eae2ee913c99cff7595527b18d8b49d0a.
Fix T74283: modifier display lost when moving object in edit mode.
The cause is not immediately obvious so better to revert and look at this
carefully.
|
|
This is in preparation of new object types. This only changes mesh_eval, we
may do the same for mesh_deform_eval and other areas in the future if there is
a need for it.
Differential Revision: https://developer.blender.org/D6695
|
|
|
|
Note that `BKE_library.h`/`library.c` were renamed to
`BKE_lib_id.h`/`lib_id.c` to avoid having a too generic name here.
Part of T72604.
|
|
Missed from fix for T70594 which reversed the normals,
Resolves T70809
|
|
- All parts of the code that need tessface should calculate it on demand.
- The check for tessloopnormal mask isn't correct
(since this is loop data, not tessface data).
|
|
Currently supports mesh, armature, lattice, curve & metaballs.
Access from pivot popover.
|
|
|
|
This also splits vertex access and allocation so it's possible
to copy coordinates into an existing array without allocating it.
|
|
T68035 by @luzpaz
|
|
We need to tag the `mesh_eval` of curve as owned, when we generate one,
otherwise freeing code would not free it.
|
|
|
|
This is old logic that no longer makes sense in the new depsgraph, and causes
issues when multiple threads try to modify the same bevel object.
Differential Revision: https://developer.blender.org/D4913
|
|
Curve function had two arguments:
- for_render, which was originally supposed to be used to control
whether viewport or render visibility for modifiers is to be
used.
- use_render_resolution, which sounds like it is supposed to control
whether viewport or render resolution for curves is to be used.
What is totally confusing is that those arguments were used
interchangeably: sometimes use_render_resolution would control
modifiers visibility.
This commit makes it so there is one single argument for this.
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D4850
|
|
|
|
Were ifdef-ed for a long time.
|
|
Force Displist to Mesh conversion if there is any modifier.
This is until we find a better way to store the batches per objects.
Also fix draw cache functions that were not returning final mesh edges.
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
Reviewers: brecht
Differential Revision: https://developer.blender.org/D4452
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
|
|
This was caused by curves pointing to each other
creating a cyclic dependency.
While the dependency graph detects this, generating a mesh for render
recursively generates data which cashes in this case.
Add in a check to detect cyclic links.
Note, this bug exists in 2.7x too - but only crashes on render
since 2.7x didn't use 'for_render' when converting data.
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
Turns out most of our 'local working copy' cases can use same set of
flags.
Note that this commit adds LIB_ID_COPY_CACHES to all our local meshes
copying, however this is no-op since that flag is unused during mesh
copying... We may want to add another set of flags without that one at
some point, but for now it would not be useful imho.
|
|
This was used in *one* place only... much better to have a dedicated
helper for that kind of things. ;)
|
|
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
|
|
|
|
than one material.
Am not totally convinced that generating meshes without fully valid
material info is a good thing, but this seems to be rather common in our
code base (in both mesh editing and convert-to-mesh cases).
So for now, duplicated code in mesh eval finalization to main displist
creation/eval function, synchronizing mat data at the end of modifiers
stack eval, if needed.
|
|
Curve modifier eval code was actually doing nothing to ensure we passed
mesh with valid normals when required by the modifier.
This is a bit basic, rough code, but think it should cover all cases,
time will say...
|
|
|
|
Helps separate variable names from descriptive text.
Was already used in some parts of the code,
double space and dashes were used elsewhere.
|
|
Not exactly sure why we did not have cached displist for bevel object
here... But anyway, that conversion operation should really happen
outside of depsgraph evaluation area, so makes sense to do it as when
generating geometry for rendering, imho. Also solves issues like loosing
hidden parts of the curve/surface, etc. Still using viewport resolution
for curves, though.
|
|
the object viewed."
This reverts commit 24677cf77bbd97827bb5789bc1e4d883732a59da.
|
|
object viewed.
|
|
|
|
Fixes edit-mesh not having a boundbox calculated for it.
|
|
|
|
The main goal of this patch is to cleanup the interface of every modifier. More specifically the interface of modifiers should be DerivedMesh-free.
Internally some modifiers still use DerivedMesh. However I think it is better when the wrappers are in the modifiers so that higher level functions can use the simplified interface.
This patch removes the applyModifier_DM and applyModifierEM_DM functions. In a previous patch (rB3614d9d) the other functions that used DerivedMesh have been removed.
Reviewers: brecht
|
|
Since shape keys are stored as raw floating point data, this
unfortunately requires changes to all code that works with it.
An additional complication is that bezier and nurbs control
points have different entry size, and can be mixed in the same
object (and hence shape key buffer).
Shape key entries are changed from:
bezier: float v1[3], v2[3], v3[3], tilt, pad, pad;
nurbs: float vec[3], tilt;
To:
bezier: float v1[3], v2[3], v3[3], tilt, radius, pad;
nurbs: float vec[3], tilt, radius, pad;
The official shape key element size is changed to 3 floats,
with 4 elements for bezier nodes, and 2 for nurbs. This also
means that the element count is not equal to the vertex count
anymore.
While searching for all curve Shape Key code, I also found that
BKE_curve_transform_ex and BKE_curve_translate were broken. This
can be seen by trying to change the Origin of a Curve with keys.
Reviewers: campbellbarton, sergey
Differential Revision: https://developer.blender.org/D3676
|
|
Specifically the deformVerts_DM, deformMatrices_DM, deformVertsEM_DM and deformMatricesEM_DM functions are not used anymore.
Reviewer: brecht
|
|
Also, fix missing cleanup of Object.runtime when copying Object
datablocks!
|
|
None of those calls actually passed a DerivedMesh.
|
|
|
|
Conflicts:
source/blender/blenkernel/BKE_group.h
source/blender/blenkernel/BKE_object.h
source/blender/blenkernel/intern/group.c
source/blender/blenkernel/intern/library_remap.c
source/blender/blenkernel/intern/object.c
source/blender/blenloader/intern/readfile.c
source/blender/editors/object/object_group.c
source/blender/editors/object/object_relations.c
source/blender/editors/physics/rigidbody_constraint.c
source/blender/editors/physics/rigidbody_object.c
source/blender/makesrna/intern/rna_group.c
|
|
Using G.main only to get main bled filepath, or built-in fonts, is OK.
So now using the 'valid' G_MAIN macro here instead.
|
|
Conflicts:
intern/cycles/blender/blender_object.cpp
source/blender/alembic/intern/abc_exporter.cc
source/blender/alembic/intern/abc_mball.cc
source/blender/alembic/intern/abc_mball.h
source/blender/blenkernel/BKE_anim.h
source/blender/blenkernel/BKE_displist.h
source/blender/blenkernel/BKE_dynamicpaint.h
source/blender/blenkernel/BKE_group.h
source/blender/blenkernel/BKE_mball.h
source/blender/blenkernel/BKE_mball_tessellate.h
source/blender/blenkernel/BKE_object.h
source/blender/blenkernel/BKE_scene.h
source/blender/blenkernel/intern/anim.c
source/blender/blenkernel/intern/depsgraph.c
source/blender/blenkernel/intern/displist.c
source/blender/blenkernel/intern/dynamicpaint.c
source/blender/blenkernel/intern/group.c
source/blender/blenkernel/intern/mball.c
source/blender/blenkernel/intern/mball_tessellate.c
source/blender/blenkernel/intern/mesh_convert.c
source/blender/blenkernel/intern/object.c
source/blender/blenkernel/intern/object_dupli.c
source/blender/blenkernel/intern/object_update.c
source/blender/blenkernel/intern/pointcache.c
source/blender/blenkernel/intern/scene.c
source/blender/blenkernel/intern/smoke.c
source/blender/depsgraph/intern/builder/deg_builder_nodes.cc
source/blender/depsgraph/intern/builder/deg_builder_relations.cc
source/blender/editors/include/ED_object.h
source/blender/editors/object/object_add.c
source/blender/editors/object/object_edit.c
source/blender/editors/object/object_modifier.c
source/blender/editors/physics/dynamicpaint_ops.c
source/blender/editors/sculpt_paint/paint_vertex.c
source/blender/editors/sculpt_paint/sculpt_uv.c
source/blender/editors/space_view3d/drawobject.c
source/blender/editors/space_view3d/view3d_draw.c
source/blender/editors/transform/transform_conversions.c
source/blender/editors/transform/transform_snap_object.c
source/blender/editors/util/ed_util.c
source/blender/gpu/intern/gpu_material.c
source/blender/makesrna/intern/rna_meta.c
source/blender/makesrna/intern/rna_object_api.c
source/blender/modifiers/intern/MOD_dynamicpaint.c
source/blenderplayer/bad_level_call_stubs/stubs.c
|
|
This commit actually adds some G.main... but at much, much higher level
than the ones it removes, so should still be better ;)
|
|
This causes a temporary spike in memory usage when creating a copy; the
entire copy will be removed anyway when DerivedMesh is removed.
|
