Surpising default loading behaviour, i.e. Trimesh(..., process=True)

Thanks for this great package with many helpful components. I’d like to report some of my experience with it in case it might help improve things.

The Trimesh object seems to do some processing of a mesh upon loading. While I understand it is useful in some cases, it might not be the desired behaviour in others. This has caught me by surprise and took me some time to figure out. This seems a recurrent issue (#222, #435).

In my use case, I typically have a reference mesh and some deformed versions of it. All of them should keep the same structure for comparison purposes, even if containing artefacts. While setting process=False works, it wasn’t intuitive to me at first. It made me look for a bug where there wasn’t any. I maybe also missed a warning about this in the docs.

My suggestion would be to keep the mesh as it is by default (i.e. process=False) and if at all needed the user can look for and enable to additional processing steps.

Again, thanks for your efforts in creating this package.

[mikedh]

I think this is a consequence of varying use cases. We’ve walked back what process=True does over the last year or two, to just merging vertices and removing NaN values, but I could see how it could catch people unaware.

My use case is part data exported from CAD packages, and thus you always want vertices merged (similar use cases include 3D printing, collision models for robotics, CAD analysis, etc). If you were dealing with models for visual purposes, you would almost never want vertices merged. It seems like it boils down to what the use case is, and I’ve arbitrarily chosen my own as the default.

I’ll definitely add a line in the README that mentions the behavior to minimize surprise. I’m pretty hesitant to change the default though, one way or the other one of those two groups is going to have to explicitly pass something to process.

Thanks for the report!

[mikedh]

Haha I guess the things that make OBJ tough to support is also the thing that makes writing an exporter so easy (which probably explains the popularity): OBJ files are just a jumble of lines, and the position of lines relative to other lines matters. There is no header to parse so data is all over the place.

If I could wave a magic wand and choose the most common in-the-wild format, I’d pick GLB 2.0 in a heartbeat. It does everything, has an awesomely specific spec, you can easily parse the JSON header then load binary blobs super fast, meshes are just “list of faces, list of vertices, list of UV’s, etc” (no “faces are v/vt/vn”), it supports PBR materials, etc. GLB2 feels like the future, OBJ feels like a legacy format that had no good alternatives for a long time.

BTW, if you use face groups heavily, the new exporter currently doesn’t have support for them for the reasons you mentioned (annoying and slow parsing). Though if you can figure out a way to support them in the new loader, PR’s would be appreciated!