Should also fix [#30266], [#29451], and partly [#30316].
Here are the changes made by this commit:
* It adds a "dirty" flag to DerivedMesh struct (for now, only DM_DIRTY_TESS_CDLAYERS, but more might be added as needed).
* It adds a new func, DM_update_tessface_data, which assumes tessfaces themselves are valid, but updates tessellated customdata from their poly/loop counter parts.
* At end of modstack, when valid tessellated faces are present in finaldm , but the cdlayers dirty flag is set, call that function (instead of recomputing the whole tessellation).
* Edits to the codes concerned (UVProject, DynamicPaint, and Subsurf modifiers).
* Also add to subsurf dm generation code the creation of a CD_POLYINDEX layer (mandatory for DM_update_tessface_data to work well, and imho all tessellated dm should have one).
Note: some pieces of old code are just #if 0’ed, will clean them later.
- The main problem was that in order to be accurate all particle
rotations have to be calculated incrementally so the only working
solution is to store rotations to the point cache (previously
this was only done for dynamic rotations). This can nearly double
the point cache size so it's not ideal to have this as a default
as in many cases you don't care about particle rotations.
- Particle rotation panel now has a new "enable" checkbox that
enables rotation calculations and the storing of rotations to
point cache.
- Old files will have rotations enabled via do_versions so that in
the worst case old files will only get bigger point caches, but no
sudden loss of particle rotations.
Fix for:
[#29758] Sequencer `Image Offset` error with render percentage
also:
* make preprocess parameters completely independent from render resolution
(they are always relative to *final* resolution now)
* fix yesterdays fix for proxy resolution rendering (the case of unbuild
proxies wasn't handled correctly)
old mesh MCol 'r' was blue, 'b' was red, but theres no reason to keep this for bmesh with MLoopCol.
Loading old files works, saving legacy format works too.
What wont work is loading a file after this revision and loading it in an older revision since the bmesh merge.
(it wont crash but the blue and red will be swapped on vertex color layers).
*Add menu is now translated.
*Nodes' title is now translated.
*Nodes' sockets' labels are now translated.
However, about the last point, and unless I’m mistaking, we’ll have to add the "i18n tag" N_() to all sockets' names, in the input/ouput templates declaration, in all nodes' files, as those sockets are collections created at runtime, I think po-generating script has no way to access that from bpy.types... Quite a piece of (borring) work. :/
Changed the create_vert_poly_map function to return a more compact
structure. Memory saved will vary depending on the mesh, but typically
it should be about one third of the old size.
this is no big improvement but at least its not a regression.
using the new operator for the bevel modifier can be enabled again be uncommenting a define.
Everything seems to work well (many tests making random changes over various meshes went good), but the code is a bit complex and hard to follow, due to the various possibilities of invalid poly/loop combinations… Code also makes more operations than previous tri/quad faces version (hence is a bit slower), but I don’t think we can do otherwise, it’s just the price for bmesh flexibility. ;)
Note: added the py script I used to make the tests, under source/tests/...
Issue was caused by MFACE layer adding for even DM without tessellated faces
which lead to adding new layer but with NULL data. This causes issues when layer
with faces (after extrude) was attempting to add because currently CD only checks
if layer type exists but does not check for size of the layer.
Solved by not adding MFACE layer if there's no tessellated faces.
This idea is borrowed from the multires modifier, which already
checked if the object was in sculpt mode and, if so, created the
PBVH. That check is now moved higher up the chain into
mesh_build_data(), so that it occurs for CDDerivedMesh too.
This also replaces an assert in cdDM_getPBVH for tesselated mesh faces
with a call to create them if missing.
Renamed the multiresModifier_update() function to
multires_modifier_update_mdisps() and made it visible to subsurf_ccg.c
so it can be called directly. No functional change, just a bit simpler.
Update handles positions after applying modifiers which seems to be expected behavior.
The only currently unsolved issue is about updating aligned handles because this needs
to determine in which order handles need to be recalculated which currently depends on
selection flags and which is quite tricky to do when running modifiers and animation data,
so currently just not update their positions for now.
Was missed check for if modifier is available for particular object type
which ended up with unpredictable results when modifier which isn't supported
yet for some object type as linked to that object type.
This is called when adding a multiries modifier. BMesh MDisps have
only one loop's displacements rather than a full face's, so don't
multiply by number of corners here.
(median point was sliding a bit from it's original position)
This happens because of how transformation for stabilization calculates:
image is scaling around it's center, so image translation should be recalculated
after scale was changed, but scale also depends on translation. That's where
tricky things happens. It's still not ideal for case of rotation, but before
fixing this issue better to figure out usecase and see if it's indeed
so needed to scale around image center (it might only be helpful to use
stabilization parameters in compositor nodes).
