Age | Commit message (Collapse) | Author |
|
This makes it clear that only the final "r_data" is being changed.
Also rename a variable to be less vague.
|
|
Just a few minor improvements: declare variables where they are
initialized, decrease scope, expand some variable names, and use
LISTBASE_FOREACH.
|
|
Having up to nine levels of indentation make this function hard to
follow. Instead of indenting the rest of the loop for a simple special
case, just continue.
|
|
This commit uses continue in loops and returning early to reduce
indentation in long functions, only where this results in a significant
improvement. Also includes a few LISTBASE_FOREACH macros.
|
|
Caused by rBa308607a5334, which mistakenly removed these lines.
|
|
These changes should result in more readable and undestandable code,
especially where while loops were use instead of for loops. They are
not comprehensive, and I skipped wherever the change was not obvious.
|
|
Corrects 34 miscellaneous misspelled words.
Differential Revision: https://developer.blender.org/D9248
Reviewed by Campbell Barton
|
|
Note that possibility to pass the new ID pointer as parameter was kept,
as this is needed for some rather specific cases (like in depsgraph/COW,
when copying into already allocated memory).
Part of T71219.
|
|
I think this wasn't allowed before because the section of a curve was
built in multiple parts. But since rBe34d3e32dda7, the whole slice
of a curve is built in one piece, so we can easily support curve
caps for all geometry types, including the new custom profile option.
Note that this also allows "caps" when the fill type is not full.
They could easily be disabled by checking for "Full" fill type
if that was preferred in the future.
See the patch for images.
Differential Revision: https://developer.blender.org/D8911
|
|
Also order sizeof(..) first to promote other values to size_t.
|
|
|
|
|
|
|
|
This is to improve the case of T71055 where curves share the same batch
cache when they shouldn't.
This however, does not help to fix edit mode display.
The real fix would be to have a similar handling to what the mesh modifiers
do and duplicate the whole Curve data. But this is too much work/change for
the 2.83 release.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7569
|
|
This is to improve the case of T71055 where curves share the same batch
cache when they shouldn't.
This however, does not help to fix edit mode display.
The real fix would be to have a similar handling to what the mesh modifiers
do and duplicate the whole Curve data. But this is too much work/change for
the 2.83 release.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D7569
|
|
There is no user visible difference in standard builds, as there are no
volume modifiers yet. When using WITH_NEW_OBJECT_TYPES some deform only
modifiers are now available for hair and pointcloud objects.
Differential Revision: https://developer.blender.org/D7141
|
|
The files are now split up into the following sections:
- `BKE_anim_path.h` and `anim_path.c` for path/curve functions.
- `BKE_anim_visualization.h` and `anim_visualizationanim_path.c` for
animation visualization (mostly motion paths).
- `BKE_duplilist.h` for DupliList function declarations. These were
already implemented in `object_dupli.c`, so they were rather out of
place being declared in `BKE_anim.h` in the first place.
No functional changes.
|
|
|
|
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...
|
|
|