This means the transform tools can be unaware of shape keys, and topology changing tools must only preserve per vertex customdata. The most similar thing we have to sculpt currently is shape keys, and to edit those we basically replace the vertex coordinates with the shape key on entering edit mode, and then sync things back on exit or when switching active shape key. That would avoid the hashing, which I expect to be rather slow and memory intensive. Is having a layer exist for only part of the vertices really important, is that how other software works? I was expecting sculpt layers to exist for all vertices. It’s reasonable to ignore that for now though and make one case work well first. The proposal mostly deals with the dynamic topology bmesh case I think, it’s not entirely clear to me how it extends to multires for example. The main complexity here is dealing with the different mesh representations, there are regular meshes, multires meshes and dyntopo bmeshes. Write to disk, Expose to UI and Create the UI To be continued in part 2 (the focus of further research and investigation) when exiting sculpt mode delete CustomData and rewrite it to match current layer data.when entering sculpt mode delete all layer data and restore it from CustomData.
To mask a layer iterate over the layer and use BM_ELEM_CD_SET_FLOAT to set desired mask value for the vert. Create a GHash where the key is a vert pointer and the value a list of layer indexes that belong to this vert.Sculpt layers must survive/work with dynotopo. Users may mask/unmask these sculpt layers, for the purpose of working with large complicated meshes more easily. Sculpt layers will be arbitrary selections of verts that are stored.
0 kommentar(er)
