Page MenuHome

Add generic precision option for text-based formats exporters (e.g. X3D, OBJ...)
Confirmed, NormalPublicTO DO

Description

io_scene_x3d importer/exporter texture coordinate precision is inadequate for some applications.

The x3d importer/exporter is hardwired to 4 decimal digit precision in generated texture coordinates.

For example, a finely meshed filleted edge on a large object with a single texture could easily have coordinate spacing in (u,v) of less than 1x10^-4, in which case you get a (u,v) space triangle with two vertices that have identical coordinates in the file, and thus zero area, etc. etc. which makes for all sorts of potential problems when the file is read back in.

The relevant lines from https://developer.blender.org/diffusion/BA/browse/master/io_scene_x3d/export_x3d.py
are:
813: fw('%.4f %.4f ' % x3d_v[0][slot_uv])
and
931: fw('%.4f %.4f ' % uv[:])
Obviously adjusting the precision to (say) 6 digits is a trivial modification.

Here is a patch that makes the precision default to 6, but also be adjustable:

Event Timeline

Bastien Montagne (mont29) lowered the priority of this task from 90 to Normal.Jul 4 2017, 3:39 PM

Thanks for the report, but there is no bug here, textual format will always have limited precision in their values…

Tweaking the amount of precision here (which is a tradeoff between precision and size of generated file) could be nice to add in a generic way for all exporters handling text-based format (can of OBJ at least, others for sure) is a nice and quite simple TODO though (add generic option, and use it to generate a float printf template…).

Bastien Montagne (mont29) renamed this task from X3D texture coordinate precision is inadequate for some applications. to Add generic precision option for text-based formats exporters (e.g. X3D, OBJ...).Jul 4 2017, 3:42 PM
Bastien Montagne (mont29) edited a custom field.

What needs to be done here? I would like to help, but I'm not exactly sure what the final result should be.

What needs to be done here? I would like to help, but I'm not exactly sure what the final result should be.

Hey John. Are you taking care of this one?

I'd like to try, but still not sure what the goal is?

I'd like to try, but still not sure what the goal is?

I am starting now, so I am not the best person to answer you. Still, as I understood, the idea is to give the user the option to define a float precision on export, because certain applications don't work with certain float precision. But you better ask someone with more experience in IRC to confirm this.

Not sure this is a good quick hack - mainly because it's quite a detailed option - should all ascii formats have precision for UV's and verts, ... normals too?

Probably if there are cases precision needs to be increased - we can increase it and not add too many options to exporters.

I suggest to use %.7g. It will ensure you have 7 digits of precision on both sides of the decimal combined, like float values have. For very small or large numbers it switches to scientific notation.

@Brecht Van Lommel (brecht) LGTM, although think this is only needed for UV's and vertices, think normals can be left at 4 (%.4g is fine too).

Just wondering: one of the above comments suggested changing the precision of all fields to %.7g. Are we still following this, or just the UV's and vertices. Also, should import also be changed?

suggest that trailing zeroes and trailing decimal points get removed as well to reduce file-size bloat.

@Shiman Zhang (shimanzhang2000), hard to say if it should be all fields. @Campbell Barton (campbellbarton) suggested %.7g for uvs and vertices, and %.4g for normals. I think most other should be %.7g too, but you need to look at it case by case if it makes sense.

Import would not be affected as far as I know.

@Don Brutzman (brutzman), %g does that.