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

[Bastien Montagne]

Hi Brecht,

Thanks for breaking my dream of using CDDM and EDBM the same way! :D

Seriously, yes, now I realize EDBM needs a specific handling in most 
cases... Didn't noticed that modifiers never actually get such one, it 
is always converted first into a CDDM.

So as I'd rather avoid adding any loop normal code in BMesh for now, I 
simply enforced this EDBM -> CDDM conversion in case the object uses 
loop normals. Obviously not a trunk-valid solution, but will allow me to 
finish the DM part of the work, before diving into bmesh one. ;)

Bastien

On 19/10/2013 02:18, Brecht Van Lommel wrote:
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>