w0rm/elm-obj-file

Encode and decode 3D geometry in the OBJ file format

elm-obj-file's Issues

Encoding to OBJ format

A support for encoding Obj files might be useful top. For example one could generate geometry using some existing helper functions from TriangularMesh and export it for Blender.

What the API could look like?

Autogenerate tangents

Tangents would allow rendering with normal mapping. Tangent can be calculated from positions and uv of three vertices from a face.

TBD: a tangent probably needs to store an additional value (1 or -1) that is needed to compute the direction of bitangent, so a Vector3d type might not be enough to store the value.

This depends on elm-3d-scene support for normal maps.

Parsing fails with Elm Debugger if too large

Just wanted to open this to save someone an hour or two some day in the future.

Above a certain number of vertices seems to run into the "Too much recursion" bug when developing locally.

Uploads were working just fine on your example site: https://unsoundscapes.com/elm-obj-file/examples/viewer/ but then when I went to use them in development it would blow up 😞.

Workaround

Turning off the elm debugger (using Vite this was: elmPlugin({ debug: false})) fixes it.

Autogenerate normals

This can potentially happen under the hood for Obj.Decode.faces and Obj.Decode.texturedFaces. Right now they would fail if the normals are missing.

Not sure how big of a deal this actually is. One could potentially create an OBJ file that has all the normals in it. In Blender this is as easy as checking “Write Normals” when exporting a file.

If we decide to generate normals in elm-obj-file, we need to consider supporting smoothing groups too. This may increase computational complexity of the code quite a bit. So it might be worth benchmarking loading a file with normals in it and a file where the normals are autogenerated.

Reindex when encoding

Currently, when encoding to OBJ, all the positions/normals/uvs are written unmodified. We could reindex them to get more compressed data.

A possible implementation might take rounded and serialised positions/normals/uvs as stings, and use them for the reverse index calculation.

Because this is a tradeoff between the size and performance, a new encoding option needs to be introduced.