| Age | Commit message (Collapse) | Author |
|---|
|
- MTexPoly structure & layer type.
- The 'Mesh.uv_textures' layers.
- DerivedMesh TexFace drawing.
- Scripts & UI.
|
|
|
|
Those new functions invert the winding of polygons, effectively inverting their normals.
A helper was also added to allow swapping two items in customdata layers.
Being able to invert normals outside of BMesh area is very important in several places,
like IO scripts or customnormals modifiers...
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1814
|
|
More in line with our other func names handling sub-item data (mainly, tessfaces' UVs and VCol...).
|
|
The final stage of the process (copying/interpolating new dst cddata from src cddata)
was simply broken in normal case, where we need to convert from source to destination
object space.
This patch is a bit verbose, but I cannot see how to avoid it really.
To think this code is in master since over 6 months and it only gets reported now... :/
|
|
Follow up to last commit, since bugs here aren't so obvious.
|
|
The issue was caused by CD_SHAPEKEY_INDEX layer being added to edge data,
now we make sure all the layers are nicely re-allocated.
|
|
Issue is rather well explained in T45471: our current customdata writing code easily generates several different blocks in blend file with same 'old' address. This is bad, because those addresses are used as 'uid' during reading process (it kind of work in Blender's own reading process, by mere luck mostly, but breaks the file specs).
Solution (suggested by Campbell, thanks) implemented by this patch is to avoid duplicating everything, and instead just overwrite what we needs to skip some cdlayers on write:
* the CustomData's `totlayer` number;
* the CustomData's `layers` array of CustomDataLayer (keeping its original address using the `writestruct_at_address` helper).
New design allows us to get completely rid of the no_free flag stuff in `write_customdata()`.
Note that this implies written data is **not** directly valid from Blend PoV, since its written typemap does not match written layers (this is not an issue because typemap is rebuilt on read anyway - and it's easy to fix this if really needed).
Also, the backward compatibility saving of mface data remains an issue here, see comment in code.
Reviewers: sergey, campbellbarton
Projects: #bf_blender
Maniphest Tasks: T45471
Differential Revision: https://developer.blender.org/D1425
|
|
|
|
The idea is pretty simple: instead of making temporary copy of all the
related custom data layers just pass the ownership from the DM to the
mesh.
This is really handy in cases when you've got DM which you need to
convert to Mesh datablock and wouldn't need that DM after conversion
anyway.
Foe example, render database conversion, exporters and even Modifier
Apply will benefit from this option.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1127
|
|
|
|
`CustomData_bmesh_interp_n` was expecting the 'dest' arg not to have its offset applied.
This was a bit confusing since the source args have it applied,
and in some cases we only have the destination with the offset.
|
|
|
|
Titles says everything, just two notes:
* We have to actually transfer plain *normals*, not 'compressed' clnors,
so had to add pre/post process to transfer to make the conversions.
* Also added interpolation and advanced copy/mixing to CD_NORMAL, for same reasons.
|
|
|
|
This add code needed to map a CD data layout from source mesh towards destination one,
and code needed to actually transfer data, using BKE's mesh remap generated data.
This allows to transfer most CD layers (vgroups, vcols, uvs...) as well as fake, boolean ones
(like smooth/sharp edges/faces, etc.). Some types are not yet transferable, mainly
shape keys, this is known TODO.
Data transfer can also use some advanced mixing in some cases (mostly, vgroups and vcols).
Notes:
* New transfer operators transfer data from active object towards selected ones.
* Modifier will be committed separately.
* Old weight transfer code (for vgroups) is kept for now, mostly because it is the only
usable one in weightpaint mode (it transfers from selected object to active one,
this is not sensible in Object mode, but needed in WeightPaint one). This will be addressed soon.
Again, heavily reviewed and enhanced by Campbell, thanks!
|
|
CustomData_duplicate_referenced_layer_n not used in master currently, but need it
in mesh tranfer branch.
|
|
UVLayers
This is only an indirect fix, in fact: this commit adds a public API to check
the maximum number of a given layer type (`CustomData_layertype_layers_max()`),
and uses it to forbid too much layer creation in `CustomData_merge()`.
This only affects UVs/VCol data though, but merge behavior in itself is not a bug
actually, how user managed to get thousands of different UV layer names remain
rather mysterious...
|
|
|
|
|
|
|
|
|
|
consideration
(which is also "[#36749] Joining objects with more than one uv map depends on list order")
Thanks Bastien Montagne and Brecht van Lommel for reviewing and some advice.
|
|
Neede for next commit (split normals API).
|
|
|
|
remove MEM_sys_types.h which was a duplicate.
|
|
nothing is changed (happens quite often that there is nothing to do).
|
|
when the block would be immediately allocated again.
|
|
vert/edge/face/loop if there are no free functions for the customdata
layers.
|
|
|
|
note: that this intentionally removes check to exit vpaint mode when a vertex color layer is removed,
since being in vertex-paint mode without a vertex color layer is supported.
also minor change to drawing camera limits while picking from previous commit.
|
|
the active layer, matching CustomData_get()
|
|
each UV and vertex color, gives overall ~9.5% drawing speedup in my tests.
was also doing NULL checks on UV's which are never NULL in this case.
|
|
unless they are needed.
configurable in 'Geometry Data' panel, will be added when running crease edges transform for example.
|
|
if vertex colors had no seams - it would interpolate the UV's too, now interpolate per-layer.
|
|
Issue was customdata wasnt being initialized for layers in the destination BMesh but not in the source data.
|
|
|
|
CustomData_has_interp() for vert & edges.
|
|
and vertex colors).
|
|
C with gcc.
helps for finding unused functions and making functions static, also did some minor code cleanup.
|
|
|
|
- replace (strcmp(vfont->name, FO_BUILTIN_NAME) == 0) with (BKE_vfont_is_builtin(vfont)).
- reduce some double promotions.
|
|
Issue was caused by do_versions being used pdata as reference for active/render/
stencil/clone layer indices instead of fdata.
Added some utility functions used only by do_versions to be sure this indices
are set from fdata for pre-bmesh files.
|
|
|
|
|
|
- bm.*.layers.*.verify()
- bm.*.layers.*.is_singleton
- bm.*.layers.*.copy_from(other)
also added api functons
- BM_data_layer_copy(...)
- CustomData_layertype_is_singleton(type)
|
|
Object has vertex group
Another crash with array caps, was caused by not making a deep enough
copy of CD field.
Also fixed the type of the 'mask' parameter, was int where it should
be 64-bit.
|
|
match BM_ function naming conventions
|
|
|
|
|
