[FieldTrip] 3d scan with structure sensor - ft_read_headshape producing empty struct with no error or warning - suggestion

[Piotr Gawroński]

Dear fieldtrip Team

I am a new user of fieldtriptoolbox and have followed your tutorial on how to localize electrodes using 3D scanner, specifically using structure sensor by Occipital. I have encountered two issues and I adress each of these in separate e-mails. I used matlab 2020a.

When scanner app by Occipital on iPad is used in such way, that after scanning object, user does not switch to color-view of model but emails himself/herself a texture-less model, the .obj file generated has faces written with double slashes (as if texture vertices [vt] were expected in a file, but they are inexistent; only geometric vertices [v] and vertex normals [vn] are existent):
f 81183//81183 85716//85716 81187//81187
f 85412//85412 85716//85716 81183//81183
f 81387//81387 85745//85745 85429//85429
f 81189//81189 81190//81190 81191//81191

This results in your ft_read_headshape error-lessly and warning-lessly producing struct with emtpy data fields, that is I receive:
pos: [0x3 double]
tri: [0x3 double]

The issue here is that, matlab produces no warning or error but produces, what seems to be, faulty result. That seems to me to be primarily scanner app bug, however I suggest your toolbox at least warn about the issue, in case it happens to stumble upon such odd .obj file - which in my case seems to be always when I send myself model straight away after scanning, instead of firstly switching into colour-view tab.

What resolved this for me, was changing read_obj_new in a way that it possesses also:
f = sscanf(face_lines{i}, 'f %d//%d %d//%d %d//%d');
Having changed it that way, the file is read correctly, obviously without texture (since there is none associated with the file).

What I have also found useful in that case, is exporting that .obj as .ply file in some program (I used meshlab).
I am not reporting that as a bug since it is associated with, what seems to be, flawed behaviour of different app.

Regards
Piotr Gawroński
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.science.ru.nl/pipermail/fieldtrip/attachments/20201221/97b93ba2/attachment.htm>