search

w0rm / elm-obj-file

Encode and decode 3D geometry in the OBJ file format
https://package.elm-lang.org/packages/w0rm/elm-obj-file/latest
BSD 3-Clause "New" or "Revised" License
24 stars 4 forks source link

Encoding to OBJ format #9

Closed w0rm closed 3 years ago

w0rm commented 3 years ago

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?

w0rm commented 3 years ago

Some open questions:

  1. Should we fix the encoded coordinate system to ObjCoordinates or let encode any coordinate system?
  2. Should we convert units while encoding, allow to choose decimal precision?
  3. Should we reindex positions/normals/uvs (slower, but producing smaller files, especially for multipart OBJ files)?
  4. Should we join coplanar adjacent triangles? What if the result is not convex?
  5. Can there be errors? e.g. what to do in case of weird groups/object/material names
  6. Does it make sense to expose a Value type (similar to Json, and allow decoding into Value = simply parsing, then allow for faster decoding from it)
ianmackenzie commented 3 years ago
  1. My inclination would be to allow geometry in any coordinate system to be encoded - I'm not sure you gain much type safety by requiring ObjCoordinates.
  2. This would mean passing a desired unit conversion function to the top-level encoding function, to choose whether something is exported in meters/centimeters/millimeters etc.? That does seem like it could be useful, especially if exporting for a program that expects certain units...
  3. Off the top of my head reindexing seems like something that would be better done separately (e.g. in elm-triangular-mesh or similar) but not totally sure 🤷‍♂️
  4. Similar for joining coplanar triangles, this seems like a generally-useful geometric operation that would ideally be implemented as standalone functionality somewhere.
  5. Not sure about errors...off the top of my head my inclination would be to say 'no errors' and weird names either just get written out as is or perhaps with some basic fixes applied (replacing spaces with underscores, etc.)
  6. Would have to see what the APIs would look like in each case, but having a Value type can be a bit constraining (for example you can sometimes parse faster if you know exactly what you're expecting to parse - parsing into a Value means you have to handle all possible cases)
w0rm commented 3 years ago

@ianmackenzie thanks for your comments!

  1. Makes sense!
  2. Yeah, this is what I thought about. What about being able to control decimal precision when exporting, what's the best way to set it?
  3. I was thinking that while triangular mesh indexes things per vertex, OBJ file has separate indices for positions, normals and uvs. This would allow to have a more compact representation. Anyway, this can be left out of an MVP and added later.
  4. Right, but if elm-obj-file only allows triangular mesh, it cannot output polygonal faces without merging the faces. Maybe elm-obj file could support decoding/encoding in https://github.com/odf/elm-mesh format
  5. Good point, I guess I could sanitise the names to make sure it doesn't break the format. What about empty lists of faces, points etc, shall I skip such sections from the file?
  6. I already have a sort of Value type, that is passed down in the decoder as List Group, I've been thinking about exposing it. This way something can be encoded/decoded without serialising to a string. Or one could keep it around as a catalog of meshes, and because it is already parsed, individual meshes could be pulled on demand quicker.