[Bf-committers] BMesh, EditBMesh, EditDerivedBMesh, and CD layers…

[Brecht Van Lommel]

Hi Bastien,

The problem is that we have two ways of storing customdata. For
regular Meshes each layer will be stored in its own array with size
equal to the number of elements. For BMEditMeshes each element stores
its own data from all layers in a little memory block.

For Meshes it's quite easy to add a layer with CustomData_add_layer,
as it will just allocate the array. For BMEditMeshes this is more
complicated and would involve resizing all element memory blocks.
Calling CustomData_add_layer will not do this. For this particular
case I would also not suggest to add things that way.

If you look at the definition of EditDerivedBMesh, you can see it has
a number of arrays like vertexCos, vertexNos, polyNos and polyCos.
That's probably the right place to add this normal layer, as an array
there, rather than storing it as a customdata layer. This may not be
ideal, but I don't know of a simpler solution at the moment. You
aren't actually allowed to modify the BMEditMesh in EditDerivedBMesh,
so you can't resize the little memory blocks for each loop (and it
would be too slow anyway).

Brecht.

On Fri, Oct 18, 2013 at 1:06 PM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
> Hi devs,
>
> This mail is mainly addressed to Campbell, who is our bmesh expert, but
> I think it may interest others as well? Anyway, I’m facing currently a
> bug in my loop normals work that I can’t really understand. I suspect
> I’m doing something wrong, but could not find examples in similar code
> to understand what to do, and if we do have some doc about bmesh, I
> found nothing about how CD layers are handled - looking to the code, it
> seems pretty complex (esp. the interactions between bmesh, editbmesh and
> editderivedbmesh)... :/
>
> So, this two-lines patch (against trunk) is enough to crash Blender in
> Edit mode as soon as you add or remove geometry:
> http://www.pasteall.org/46610/diff
>
> Note that all 'array-like' layers (normal, but also sticky, mcol,
> shapekey…) crash, while all single-values (be it int or float - bweight,
> crease etc.) do not crash. Crash happens in mempool
> (BLI_mempool_alloc(), pool->free->next has aberrant values), so this is
> likely a mem overwrite, yet gcc's sanitize build does not say anything
> until the segfault.
>
> So questions are:
> 1) Is adding a CD layer this way over an EditDerivedBMesh illegal? In
> which case, how are we supposed to process?
> 2) Does anyone know if we have written doc about CD layers handling in
> the bmesh area?
>
> Regards,
> Bastien
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers