@Richard Antalik (ISS) okay, got it!
If you think you found a better solution for some usecases in this patch, please mention it in D7517 or here and we can combine efforts. Although Campbell would need to give a greenlight on this first to have any future. I have a feeling like this goes something like the colored wireframes or similar "simple" features...
psys_emitter_customdata_mask(ParticleSystem * psys, CustomData_MeshMasks * r_cddata_masks) Line 1953 C requiredDataMask(Object * UNUSED_ob, ModifierData * md, CustomData_MeshMasks * r_cddata_masks) Line 104 C BKE_modifier_calc_data_masks(Scene * scene, Object * ob, ModifierData * md, CustomData_MeshMasks * final_datamask, int required_mode, ModifierData * previewmd, const CustomData_MeshMasks * previewmask) Line 573 C mesh_calc_modifiers(Depsgraph * depsgraph, Scene * scene, Object * ob, int useDeform, const bool need_mapping, const CustomData_MeshMasks * dataMask, const int index, const bool use_cache, const bool allow_shared_mesh, Mesh * * r_deform, Mesh * * r_final) Line 951 C mesh_build_data(Depsgraph * depsgraph, Scene * scene, Object * ob, const CustomData_MeshMasks * dataMask, const bool need_mapping) Line 1805 C makeDerivedMesh(Depsgraph * depsgraph, Scene * scene, Object * ob, BMEditMesh * em, const CustomData_MeshMasks * dataMask) Line 1920 C BKE_object_handle_data_update(Depsgraph * depsgraph, Scene * scene, Object * ob) Line 194 C BKE_object_eval_uber_data(Depsgraph * depsgraph, Scene * scene, Object * ob) Line 385 C
Are you aware of D7517?
Build modifier for Text still works in reversed order.
I think what is expected here is that, with this build modifier and text, first letter appear, then second letter, then third ... But here is first the last letter...
Fri, Jul 3
Fixed the variable name to clnors as to be inline with the rest of the code.
how to apply this patch to blender??
Thu, Jul 2
@Clément Foucault (fclem)
Mask modifier can deal with new edges. Object and edit modes both.
The different shading is caused by the edit cage rendering on top of the wireframe. This is a known issue (see T64915).
This is almost the same issue as T67888 but in this case it is just because using the convert to > mesh from curve operator.
@Campbell Barton (campbellbarton) I know the eventual goal is to have a better duplicator system, but to me it seems like this patch is a bit orthogonal to that, lots of times you want a contiguous mesh.
Wed, Jul 1
Just a simpliest demo
any news? poke.
Updated for new master.
Tue, Jun 30
Mon, Jun 29
btw vertex paint visible with regular subdiv, but hides with multires.
Affected modifiers (at least):
Sun, Jun 28
The workaround does not even seem to work now. I guess it's a bug in the modifier stack evaluation that think it can skip ORCO since we are in solid shading mode at first.
Sat, Jun 27
Fri, Jun 26
This has been reported before, see T78269: Mirror modifier lost UV offset only, will merge these reports.
The commit rBe3a420c4773a I just made improves the situation here: now a more consistent choice is made as to which UV island gets the extra geometry needed after a bevel. But the original bug report also wants a better shape in the resulting UV map for the interpolated faces. That is harder to fix, and so it remains a Known Issue that the UV map will not be exactly as the original reporter would like.
I just committed change rBe3a420c4773a which uses some disambiguation rules to help solve this problem.
I will say it fixes this problem, even though the results still do not look great on the example blend: that example has both a UV map and a Loop color assignment. Those two together make for a harder case to solve (there is a detection of "connected islands" that has to pay attention to both of those maps). If one deletes the apparently unused uv map from the example, the result looks good, in my opinion.
Thu, Jun 25
Idk if it is correct place, but I have this bit of info about modifiers unnecessary recalculation,
may be it can help to check Blender`s behavior more precisely.