Performance issues with complex meshes

[darrengarvey]

Performance issues with complex meshes

[oliveroxtoby]

Firstly, why does ShapeRefs only store the string name of the relevant faces rather than just storing the faces themselves? This is what I changed locally and that removes the huge overhead of needing to go from the string names back to the face objects (saving me ~40 hours per case).

That's good to know! No particular reason. I haven't really got to doing any optimisation on this as it hasn't been much of an obstacle in the examples I've run. I'd be interested to see your example in order to understand better, if you can share it.

Secondly, I can guess at why matchFaces exists: maybe a user manually selected the face in an object that was used to create a mesh, rather than selecting the face on the mesh object itself. But this resolving process is very expensive (about 6 hours of the remaining 6 hours processing time), and AFAICT isn't needed if creating the case programmatically or if a user is careful in selecting the correct faces when creating a mesh refinement.

Correct, but I would like to keep this flexibility. Sometimes it's much more convenient to select a face on a simpler object than the full compound that the mesh is composed of. I'd gratefully receive any optimisations though. Presumably we can detect and skip if we see the selection has been made on the primary mesh shape.

I'm new to the code so could be missing something crucial so thought I'd ask before going down the wrong path.

No problem. I sadly have very little time for this project so unfortunately I've erred on the side of adequacy rather than optimality, in many respects.

I'm wondering if all of this resolving work could be done only if manually selecting faces and the underlying object properties could contain the raw data needed to quickly generate a mesh. That way if not manually selecting things, most of the processing cost could be skipped.

Sounds good.