Keep hitting testing issues with the Structure Sensor SDK, where doing TDD (Test Driven Development) becomes almost impoossible between the stage of completing a scan, and doing further processing.
One of the core ideas of TDD (indeed, any testing) is repeatability, and without some way to save a known starting point for an STMesh, it is frustratingly difficult to test further processing to check results coming out the other end are valid, repeatable or efficiently handled.
Have managed to save out an OBJ file using the current SDK, but that only gives you a point in the full workflow that is past where we need to test the full flow.
What the SDK desperately needs is a way to write out an STMesh to disk, possibly using NSCoding, and then re-read that in as a newly instatiated STMesh object.
I’ve trawled the forum and this seems to be a common request/requirement, wanted for things like saving meshes that are a ‘work in progress’, along with sample, repeatable data.
If you are trying to run custom algorithms with the STMesh, like decimated low-poly versions using code other that that supplied, it’s extremely difficult without a known STMesh to start from; and with no obvious way to get that baseline standard STMesh as a saveable object, you are already backed into workarounds rather than smooth workflows.
Yes, you can save a local OBJ file, and work with that, but then there is no way to reload that mesh into a new STMesh object and continue from that point.
Right now, for testing, we are having to scan a static object multiple times, as part of a user-driven flow, and simply try and get them to be as close as possible to each other every time. But that’s simply not accurate enough for full testing, and negates a ‘repeatable’ workflow that we can use to get some accurate numbers out of the algorithms we run on finished meshes.
Are there any plans, or ‘quick wins’ with custom code, that can allow us to get a raw STMesh out of the SDK that we can work with, and reload for continous integration and TDD?