Moving negative imperial units works incorrectly #74552

New Issue

Christopher Marcel Beumont · 2020-03-08T21:11:57+01:00

2020-03-08 21:11:57 +01:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Quadro M5000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.16

Blender Version
Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: 77d23b0bd7
Worked: None

Moving an object negative imperial units works incorrectly. Moving an object -X' Y" moves the object negative X feet but positive Y inches. It requires you to type -X' -Y" or -(X'Y") instead which is not how negative imperial units are written.

Exact steps for others to reproduce the error

Open blender
Click on the splash screen image to make it go away
In the scene properties, change the "Unit System" under "Units" to "Imperial"
Delete the default cube
Add a cube
Type "G" type "Z" type "-1" hit "Enter"
In the "Operator Panel" on the lower left hand side, type in -1'6"
Notice the cube move up 6" instead of down
The final position shows as -0.5 instead of -1.5

12 inches = 1 foot
3 feet = 1 yard
1,760 yards = 1 mile

Note: Everything including architectural plans/shop drawing in the US are in imperial units. We are so sorry world.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: Quadro M5000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.16 **Blender Version** Broken: version: 2.82 (sub 7), branch: master, commit date: 2020-02-12 16:20, hash: `77d23b0bd7` Worked: None **Moving an object negative imperial units works incorrectly. Moving an object -X' Y" moves the object negative X feet but positive Y inches. It requires you to type -X' -Y" or -(X'Y") instead which is not how negative imperial units are written.** **Exact steps for others to reproduce the error** * Open blender * Click on the splash screen image to make it go away * In the scene properties, change the "Unit System" under "Units" to "Imperial" * Delete the default cube * Add a cube * Type "G" type "Z" type "-1" hit "Enter" * In the "Operator Panel" on the lower left hand side, type in -1'6" * Notice the cube move up 6" instead of down * The final position shows as -0.5 instead of -1.5 12 inches = 1 foot 3 feet = 1 yard 1,760 yards = 1 mile Note: Everything including architectural plans/shop drawing in the US are in imperial units. We are so sorry world.

Christopher Marcel Beumont commented

2020-03-08 21:11:57 +01:00

Added subscriber: @windex

Germano Cavalcante commented

2020-03-09 13:13:00 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-03-09 13:13:00 +01:00

I can confirm this behavior, but I don't understand much about imperial unity to understand how it should be.

Analyzing the user_string_to_number function, -1'6" is converted to (-1 * 1 + 6 * 0.0833333313) * 0.304800004
I suppose it should be converted to (-(1*1+6*0.0833333313 ))*0.304800004
But I need to do some research to confirm this.

I can confirm this behavior, but I don't understand much about imperial unity to understand how it should be. Analyzing the `user_string_to_number` function, `-1'6"` is converted to `(-1 * 1 + 6 * 0.0833333313) * 0.304800004` I suppose it should be converted to `(-(1*1+6*0.0833333313 ))*0.304800004` But I need to do some research to confirm this.

Evan Wilson commented

2020-03-09 18:24:53 +01:00

Added subscriber: @EAW

Evan Wilson commented

2020-03-09 18:24:53 +01:00

I suppose it should be converted to (-(1*1+6*0.0833333313 ))*0.304800004
But I need to do some research to confirm this.

As an American, I can confirm that movement of -1.5ft is the expected result when entering -1'6".

Writing it out as -1'-6" (as seen below) makes no sense to me.

I am guessing that it is rare to write -1m50cm in metric, and that writing -1.5m would be more common.
So the fact that -1 m 50 cm and -1m50cm both result in -0.5m might be the expected norm in metric, but I suspect that this too is an odd "Blenderism."

> I suppose it should be converted to `(-(1*1+6*0.0833333313 ))*0.304800004` > But I need to do some research to confirm this. As an American, I can confirm that movement of `-1.5ft` is the expected result when entering `-1'6"`. Writing it out as `-1'-6"` (as seen below) makes no sense to me. ![makes no sense.png](https://archive.blender.org/developer/F8397699/makes_no_sense.png) --- I am guessing that it is rare to write -1m50cm in metric, and that writing -1.5m would be more common. So the fact that `-1 m 50 cm` and `-1m50cm` both result in `-0.5m` might be the expected norm in metric, but I suspect that this too is an odd "Blenderism." ![-1 m 50 cm.png](https://archive.blender.org/developer/F8397665/-1_m_50_cm.png) ![-1m50cm.png](https://archive.blender.org/developer/F8397680/-1m50cm.png) ![-0.5 m.png](https://archive.blender.org/developer/F8397667/-0.5_m.png)

Evan Wilson changed title from ~~Moving negative imperial units~~ to Moving negative imperial units works incorrectly

2020-03-09 18:29:27 +01:00

Evan Wilson commented

2020-03-09 18:29:27 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Campbell Barton commented

2020-05-21 08:10:09 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2020-05-21 08:10:09 +02:00

In general, I'd suggest to avoid doing anything two clever here, it's fairly likely to back-fire consider users may mix these with Python expressions.
Having said that, both cases look like they could be handled.
For - there could be an implicit conversion from - to -( ... )
The trick would be to do it without breaking statements like
-4 + 0.5 / -1.1

Regarding evaluating
1'6 as 1'6"
this seems simpler, since we could make a rule that ensures the next lower unit type is added if a unit-type was the suffix of the previous number and the next number has none.

Although we might only do this in simple cases, as there are limits to what could be realistically supported.

eg:

1'(4+4) to 1'(4+4)" ? - probably not.

But
1'2.5 to 1'2.5" ... might be reasonable.

For both of these we might want to define a "simple" expression, so if the expression doesn't involve maths / parenthesis, some assumptions can be made.
Although I don't really like this as it means
1'6 might evaluate differently to 2+1'6

Perhaps the same part of the code that replaces ' could do a look-ahead and add the " after the next number.
And try to be robust and support cases like:
10_0.1e-10'9_0.1e+2 to 10_0.1e-10'9_0.1e+2"

Or, we could stop trying to mix Python and unit's as we do now, and instead, only support one or the other.
Only allowing explicit mixing:

{1"2}+{2m3cm} so first we evaluate everything in the {}.
as units. Then pass to Python.

As {...} are used for dictionaries & set's in Python, the chance people want to construct these in a math expression in very low.

In simple cases like 1"2, no need for surrounding by {...}.

In general, I'd suggest to avoid doing anything two clever here, it's fairly likely to back-fire consider users may mix these with Python expressions. Having said that, both cases look like they could be handled. For `-` there could be an implicit conversion from `-` to `-( ... )` The trick would be to do it without breaking statements like `-4 + 0.5 / -1.1` ---- Regarding evaluating `1'6` as `1'6"` this seems simpler, since we could make a rule that ensures the next lower unit type is added if a unit-type was the suffix of the previous number and the next number has none. Although we might only do this in simple cases, as there are limits to what could be realistically supported. eg: `1'(4+4)` to `1'(4+4)"` ? - probably not. But `1'2.5` to `1'2.5"` ... might be reasonable. ---- For both of these we might want to define a "simple" expression, so if the expression doesn't involve maths / parenthesis, some assumptions can be made. Although I don't really like this as it means `1'6` might evaluate differently to `2+1'6` Perhaps the same part of the code that replaces `'` could do a look-ahead and add the `"` after the next number. And try to be robust and support cases like: `10_0.1e-10'9_0.1e+2` to `10_0.1e-10'9_0.1e+2"` ---- Or, we could stop trying to mix Python and unit's as we do now, and instead, only support one or the other. Only allowing explicit mixing: `{1"2}+{2m3cm}` so first we evaluate everything in the `{}`. as units. Then pass to Python. As `{...}` are used for dictionaries & set's in Python, the chance people want to construct these in a math expression in very low. In simple cases like `1"2`, no need for surrounding by `{`...`}`.

blender-admin commented

2020-06-01 14:22:27 +02:00

This issue was referenced by 45dbc38a8b

This issue was referenced by 45dbc38a8b156a6e704575f4935c7f3f9cf96e5d

Hans Goudey commented

2020-06-01 14:38:23 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue

2020-06-01 14:38:23 +02:00

Hans Goudey self-assigned this 2020-06-01 14:38:23 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Moving negative imperial units works incorrectly #74552