Skip to content

(io): mesh attributes created after getInput aren't locked

Marc SCHWEITZER requested to merge 614-io-mesh-attributes-created-after-getinput-aren-t-locked into dev

Description

Some attributes of ::fwData::Mesh may be created later (aka after the New()), like points/cells normals/colors/texture coordinates.

But this can lead to some unpredicted unlock issues on internal arrays of ::fwData::Mesh, when using new RAII methods like getLockedInput if the mesh hasn't point normals when getting the locked input the corresponding array will not be lock (because it will be null), so if you set normals afterwards, corresponding array will still be in unlock state.

We now create all attributes (colors/normals/texture) at mesh creation, we also store an attribute binary mask that can be check to be sure which attribute is set or not. We don't rely anymore on the nullptr of internal arrays.

We also modify mesh iterator to remove the lock it performs, so we need systematically call mesh->lock() if we don't use RAII methods from service.

Along with previous modifications, we also modify internal structure of CellsData arrays, previously we store std::uint64_t values, we change values to std::uint32_t much more adaptable on both 32bits and 64bits systems.

To deal with all previous modifications we also updated data mesh version (version 4), fwData version (V15) & arData version (V17AR). We provide structural patches to load/save previous version of data.

Some of our unit test has also be updated.

Closes #614 (closed)

Closes #583 (closed)

How to test it?

That's the tricky part, you will need to test almost everything, from the main applications to the tiny unit-test.

  • Test everything that you have in mind involving parsing a data mesh
  • Launch all sight unit tests
  • Try to load/save from previous version
Edited by Romain MANCIAUX

Merge request reports