Number of precision digits can be easily changed on _precision variables, for loc, rot, sca, normal and uv.
Details
Diff Detail
Event Timeline
Changed the variables positions from start of file to inside of the export().
Created a basic interface.
Wouldn't mind getting @Campbell Barton (campbellbarton)'s view on this patch, but already noted several important points below.
| io_scene_obj/__init__.py | ||
|---|---|---|
| 291–297 ↗ | (On Diff #25430) | What is the added value of this option? Why would one want to keep extra zeros? |
| 298–316 ↗ | (On Diff #25430) | Think we could keep it to two precision values? Or even one? I can see why one could want to carefully optimize its precision versus file size, but imho this adds way too many new parameters for a very limited usecase. |
| io_scene_obj/export_obj.py | ||
| 32–33 ↗ | (On Diff #25430) | f is forced in non-exponential notation, so precision varies actually with its value (since high numbers will get more digits than small numbers). g uses either flat or exponential notation, ensuring always the same amount of significant digits. The choice between those therefore goes way beyond 'remove trailing zeros'. And am not even sure whether OBJ supports actually scientific notation, there is nothing in the specs about it... |
| 149 ↗ | (On Diff #25430) | Using format still has a significant overhead compared to old 'printf' like syntax, afaik. |
| io_scene_obj/__init__.py | ||
|---|---|---|
| 291–297 ↗ | (On Diff #25430) | I thought about the line alignment, for editing with awk / sed (I don't know if it makes a difference) |
| 298–316 ↗ | (On Diff #25430) | Yes, makes sense. Maybe one option, and make normal and vertices proportional to this one, with a minimum size (like 2 digits)? |
| io_scene_obj/export_obj.py | ||
| 32–33 ↗ | (On Diff #25430) | So, we can't use %g ... |
| 149 ↗ | (On Diff #25430) | Yes, shall be. I used it due to the %f / %g option. Removing it allows the use of printf. |