Document non-tri mesh topology behaviour

[andybak]

I see that #703 added support for TRIANGLEFAN etc but from a brief glance it looks like it converts to a regular tri mesh on import. If so that means that round-tripping will be lossy.

Is my assumption correct? Should this be documented somewhere?

[andybak]

(more broadly - it would be good to have docs on exactly what is preserved in an import/export round trip)

[andybak]

Just tested and I can confirm that LINE_LOOP and LINE_STRIP become LINES after export

And TRIANGLE_STRIP and TRIANGLE_FAN become TRIANGLES

So round-tripping is currently lossy in this regard.

[pfcDorn]

hey.... Unity support only a few topologies which results into converted ones. And of course, a perfect round-trip is not possible here.
Unity MeshTopology

And yeah, the documentation lacks e bit behind with all the new features

[andybak]

hey.... Unity support only a few topologies which results into converted ones. And of course, a perfect round-trip is not possible here.

I disagree. Round-tripping is possible if we record the original toplogy type on the object. The question is whether it's worth it.

Preserving the precise indices for each type is probably more effort and more storage but might be worth considering later down the line. But the common case would be simply the ability too preserve the topology on export. In all cases I think sane indices can be recovered from the triangle mesh and all we need to know is the original topology type.

[hybridherbst]

Roundtripping between formats in the strict sense only works as long as the features to be roundtripped are shared between the involved softwares.

The variant of „roundtripping“ you mean involves storing additional meta data on import that can’t be interpreted by the importing software, just to have it around for a potential export later.

The extreme case is storing the entire glTF on import so that it can be „exported“ again, and then there’s varying levels inbetween to actual roundtrips (imported data is completely converted to the internal format of the importing software, exporting it leads to the same file structure). When metadata is used, any modification to the imported data results in undefined behavior (for example, a mesh tagged with „this actually uses line_fan“ is replaced at runtime with a triangle mesh and then exported).

UnityGltf does not store any metadata on import, by design. We aim to provide visually and hierarchically correct roundtrips.

The behavior you want should be achievable with an import and export plugin though! - e.g. storing the mesh metadata on import (in a component, or some dictionary, or…) and restoring it on export.

You are 100% right that we should document the design goals and behavior better!

[andybak]

Roundtripping between formats in the strict sense only works as long as the features to be roundtripped are shared between the involved softwares.

Not exactly. It's not whether the involved software supports the feature - it's whether it throws away data it doesn't directly support.

I agree that storing copies of the entire mesh would be too onerous - but simply recording the original topology is a single int and would cover the common case.

I think I'm putting this out there as a "this is the right thing to do" rather than "PR incoming". And I'm probably being overly idealistic as the benefit of this would only be realised if other software adopted a similar principle.

(on a side note - I only noticed this while trying to figure out if there was an elegant way to store quads and n-gons in GLTF. We need a way to preserve topology for low-poly mesh editing purposes)