Page MenuHome

Various issues with bpy.utils.units.to_string
Closed, InvalidPublic

Description

System Information
Windows 8.1 x64
Renderer: GeForce GTX 860M/PCIe/SSE2

Blender Version
Broken: 2.77.1 c885cea

Short description of error
Various issues with bpy.utils.units.to_string.

Exact steps for others to reproduce the error

  • split_unit argument does nothing:
bpy.utils.units.to_string('METRIC', 'VOLUME', 1.01, split_unit=True)

output:    1.01m³
should be: 1m³ 1cm³
  • Volume output values do not have ³ (or cu) indication if unit system is None (unlike rotation):
bpy.utils.units.to_string('NONE', 'VOLUME', 1)

output:    1
should be: 1³
  • compatible_unit argument is always True for Imperial unit system:
bpy.utils.units.to_string('IMPERIAL', 'VOLUME', 0.1, compatible_unit=False)

output:    3.531cu ft
should be: 3.531'³
  • compatible_unit is different for Metric and Imperial systems:
bpy.utils.units.to_string('METRIC', 'VOLUME', 1, compatible_unit=True)
bpy.utils.units.to_string('IMPERIAL', 'VOLUME', 0.1, compatible_unit=True)

output:    1m3
           1.308cu yd

should be: 1cu m
           1.308cu yd

Details

Type
Bug

Event Timeline

Bastien Montagne (mont29) closed this task as Invalid.
Bastien Montagne (mont29) claimed this task.

Thanks for the report, but those are either false/erroneous expectations, or design decisions - no bug here. Detailed explanations inlined below.

split_unit argument does nothing:

 bpy.utils.units.to_string('METRIC', 'VOLUME', 1.01, split_unit=True)
output:    1.01m³
should be: 1m³ 1cm³

This is totally false, 1.01m³ is 1m³ 10dm³ - and decimeter is a 'suppressed' unit, i.e. we don’t show it/use it, because it’s not commonly used (it's only defined in Blender to be able to convert user's input).

Volume output values do not have ³ (or cu) indication if unit system is None (unlike rotation):

 bpy.utils.units.to_string('NONE', 'VOLUME', 1)
output:    1
should be: 1³

Yeah… and for 2 you’d expect 2³, i.e. 8? Seriously, volumic or surfacic values without a unit are pure non-sense.

compatible_unit argument is always True for Imperial unit system:

bpy.utils.units.to_string('IMPERIAL', 'VOLUME', 0.1, compatible_unit=False)
output:    3.531cu ft
should be: 3.531'³

compatible_unit is different for Metric and Imperial systems:

bpy.utils.units.to_string('METRIC', 'VOLUME', 1, compatible_unit=True)
bpy.utils.units.to_string('IMPERIAL', 'VOLUME', 0.1, compatible_unit=True)
output:    1m3
           1.308cu yd
should be: 1cu m
           1.308cu yd

You do not understand what compatible_unit is. This option transforms some output to replace some 'non-common', not easily reached chars on typical keyboards, like exponent ones. Nothing else. Hence, 1m³ becomes 1m3, but there is absolutely no reason to alter 1cu yd, since it’s already a pure ASCII unit string…

As a side note, I never saw 1cu m notation, this is not standard at all (nor is 1'³ afaik, but am not a specialist of imperial system at all).

I agree with you on all topics except one:

bpy.utils.units.to_string('METRIC', 'VOLUME', 1.001, split_unit=True)

still output: 1.001m
when should:  1m 1cm

Nope, bpy.utils.units.to_string('METRIC', 'VOLUME', 1.001, split_unit=True) could give 1m³ 1dm³ (if dm³ was not a 'suppressed' unit).

To get 1m³ 1cm³ you would call bpy.utils.units.to_string('METRIC', 'VOLUME', 1.000001, split_unit=True) - but this won’t work, since such a small 'sub-unit' (1e-⁶ times 'main' order of magnitude) gets removed from UI unit drawing code…

You are right, I'm sorry. I was too careless when analyzing causes, I will test better next time.