WIP: IO: Add file unit type selector to stl importer and exporter #128337

Cedric Steiert · 2024-09-29T22:11:00+02:00

Cedric Steiert commented

2024-09-29 22:11:00 +02:00

First-time contributor

As STL is a unitless format, most other programs assume it to be millimeters. Blender on the other hand uses meters. This means, that whatever size the object has (e.g. 2m) it will always be assumed as millimeters in other apps (in case of 2m that would be 2mm, as no unit is saved, only the numeric value). Changing the unit system inside blender only changes the UI display values, not however the actual data and fiddling with the scene scale or export scale values can be quite tedious (time consuming for often users, confusing for sporadic users).

To allow for CAD modelling and exporting to STL in real life measures (which is desirable as STLs are commonly used for 3d printing), this PR supplies the user with a dropdown allowing to choose the target unit type (m, dm, cm, mm, in) used by the application he wishes to export for, whilst leaving a custom option for user defined scale (otherwise the scale factor input field is disabled); the chosen unit will modify the scale factor value. Additionally a new option got added to scale the mesh according to the used scene unit (e.g. scene unit cm, which then also assumes the stl scale values to be cm).
The default unit stays meter (factor 1) to not introduce any breaking changes to existing workflows, whilst still allowing anyone to quickly change units without having to think about conversion factors too much.

This change is inspired by the upcoming release of the x3d extension with a similar (but not identical) choosing option: 7e0b0e903a

The current feature proposal looks like this:
meter selected (default):

dropdown options:

millimeter selected (1m in blender is now 1m for most other apps as well):

when using millimeter as preset value, a user can model in real life measures and export/import in the correct scale. For example: model is 10x10cm (blender internally this equals to 0.1x0.1(m), thus in other apps as 0.1x0.1(mm)), a scale factor of 1000 will be applied, which results in a final scale of 100x100(mm)=10x10(cm).

The proposal got implemented for the stl importer and exporter.

As STL is a unitless format, most other programs assume it to be millimeters. Blender on the other hand uses meters. This means, that whatever size the object has (e.g. 2m) it will always be assumed as millimeters in other apps (in case of 2m that would be 2mm, as no unit is saved, only the numeric value). Changing the unit system inside blender only changes the UI display values, not however the actual data and fiddling with the scene scale or export scale values can be quite tedious (time consuming for often users, confusing for sporadic users). To allow for CAD modelling and exporting to STL in real life measures (which is desirable as STLs are commonly used for 3d printing), this PR supplies the user with a dropdown allowing to choose the target unit type (m, dm, cm, mm, in) used by the application he wishes to export for, whilst leaving a custom option for user defined scale (otherwise the scale factor input field is disabled); the chosen unit will modify the scale factor value. Additionally a new option got added to scale the mesh according to the used scene unit (e.g. scene unit cm, which then also assumes the stl scale values to be cm). The default unit stays meter (factor 1) to not introduce any breaking changes to existing workflows, whilst still allowing anyone to quickly change units without having to think about conversion factors too much. This change is inspired by the upcoming release of the x3d extension with a similar (but not identical) choosing option: https://projects.blender.org/extensions/io_scene_x3d/commit/7e0b0e903a2cc51706aeca1e9b3f394eaeee3ef1 The current feature proposal looks like this: meter selected (default): ![grafik](/attachments/ede1e389-dcec-4cf9-9514-f1494ec59dd8) dropdown options: ![grafik](/attachments/eec6b127-7637-4283-bc6d-d394d84556cf) millimeter selected (1m in blender is now 1m for most other apps as well): ![grafik](/attachments/ec702dfe-c3e0-4e32-81b1-e2a20718459d) when using millimeter as preset value, a user can model in real life measures and export/import in the correct scale. For example: model is 10x10cm (blender internally this equals to 0.1x0.1(m), thus in other apps as 0.1x0.1(mm)), a scale factor of 1000 will be applied, which results in a final scale of 100x100(mm)=10x10(cm). The proposal got implemented for the stl importer and exporter.

grafik.png

15 KiB

grafik.png

16 KiB

grafik.png

15 KiB

Cedric Steiert added 2 commits 2024-09-29 22:11:11 +02:00

IO: Add file unit type selector to stl importer and exporter 100476023a

As STL is a unitless format, most other programs assume it to be millimeters. Blender on the other hand uses meters. To allow for CAD modelling and exporting to STL in real life measures, this commit supplies the user with a dropdown allowing to choose the target unit type (m, dm, cm, mm, in), whilst leaving a custom option for user defined scale (otherwise scale factor input field is disabled); the chosen unit will modify the scale factor value.
The default unit stays meter (factor 1) to not introduce any breaking changes to existing workflows.

IO: add scene unit option to stl io unit type selctor 1711592188

This commit adds a new option to the dropdown to set the scale factor accordingly to the used scene unit of the blend file (blender assumes meter, thus a conversion from meter to unit system is needed). This is useful if the user already decides to model in the target unit system used by the other application.
Also done some cleanup, removed some redundant code.

Iliya Katushenock added this to the Pipeline, Assets & IO project 2024-09-29 23:25:23 +02:00

Iliya Katushenock reviewed 2024-09-29 23:26:13 +02:00

source/blender/io/common/IO_unit_type.hh Outdated

						
				@ -0,0 +1,35 @@

				/* SPDX-FileCopyrightText: 2023 Blender Authors

Iliya Katushenock commented

2024-09-29 23:26:13 +02:00

Today is 2024/

Today is `2024`/

Bujus_Krachus marked this conversation as resolved

Cedric Steiert added 1 commit 2024-09-30 00:59:46 +02:00

Fix: copyright year, c styleguide

buildbot/vexp-code-patch-lint Build done.

Details

buildbot/vexp-code-patch-linux-x86_64 Build done.

Details

buildbot/vexp-code-patch-windows-amd64 Build done.

Details

buildbot/vexp-code-patch-darwin-arm64 Build done.

Details

buildbot/vexp-code-patch-darwin-x86_64 Build done.

Details

buildbot/vexp-code-patch-coordinator Build done.

Details

9aab742e68

Cedric Steiert requested review from Aras Pranckevicius 2024-09-30 01:18:27 +02:00

Aras Pranckevicius commented

2024-09-30 10:50:22 +02:00

That's an interesting idea, but it makes me wonder: should some other formats that are "unit-less" (e.g. OBJ, PLY) also get the same feature?

Cedric Steiert commented

2024-09-30 11:46:00 +02:00

First-time contributor

should some other formats that are "unit-less" (e.g. OBJ, PLY) also get the same feature?

Should? Idk, that's for the blender team to decide.

Could? Yes, absolutely; most of the code is located in io common, only embedding to the individual UI's would be needed. Adding that feature to the other file types (If it gets accepted ofc), would create a more generalized standard UI, which i already outlined here (due to many differences in the IO core addons): https://blender.community/c/rightclickselect/DY5B/ (still a decision has to be made what options to consider as general, and whether to adjust the IO core addons individually or to create a one-size-fits-all-solution).

Recommended? Maybe. It for sure would be a nice feature, as it simplifies the unit conversion process if needed and is transparent in it's making (the scale factor is exposed to the user in the UI).
However the use cases fully depend on the users, their modelling preferences (large (200m(blender)=200mm(extern)=20cm(extern)) or little scaling (200mm(blender)=200mm(extern)) with grid scale adjustments needed), the external software used, etc.
I remember back in school when i did some CAD models for 3D-printing in blender on a sporadic basis it was always headscratches which factor to use and why, as somehow all attempts were different size in the slicer program than i'd expect it to be from blender (i foolishly assumed cm to be cm).

> should some other formats that are "unit-less" (e.g. OBJ, PLY) also get the same feature? Should? Idk, that's for the blender team to decide. Could? Yes, absolutely; most of the code is located in io common, only embedding to the individual UI's would be needed. Adding that feature to the other file types (If it gets accepted ofc), would create a more generalized standard UI, which i already outlined here (due to many differences in the IO core addons): https://blender.community/c/rightclickselect/DY5B/ (still a decision has to be made what options to consider as general, and whether to adjust the IO core addons individually or to create a one-size-fits-all-solution). Recommended? Maybe. It for sure would be a nice feature, as it simplifies the unit conversion process if needed and is transparent in it's making (the scale factor is exposed to the user in the UI). However the use cases fully depend on the users, their modelling preferences (large (200m(blender)=200mm(extern)=20cm(extern)) or little scaling (200mm(blender)=200mm(extern)) with grid scale adjustments needed), the external software used, etc. I remember back in school when i did some CAD models for 3D-printing in blender on a sporadic basis it was always headscratches which factor to use and why, as somehow all attempts were different size in the slicer program than i'd expect it to be from blender (i foolishly assumed cm to be cm).

Aras Pranckevicius commented

2024-10-03 09:59:31 +02:00

@blender-bot build

Aras Pranckevicius reviewed 2024-10-03 10:09:08 +02:00

source/blender/io/common/intern/unit_type.cc

						
				@ -0,0 +35,4 @@

				  char scene_unit = scene->unit.length_unit;

				  if (scene->unit.system == USER_UNIT_METRIC) {

				    switch (scene_unit) {

				      case '\0':  // kilometer

Aras Pranckevicius commented

2024-10-03 10:09:08 +02:00

Not quite like hardcoding unit system indices in that way. As far as I can tell, these would only work as long as no one reorders to alters the unit systems arrays inside unit.cc. Would it be better to use something like BKE_unit_base_scalar to get the scaling factors instead?

Not quite like hardcoding unit system indices in that way. As far as I can tell, these would only work as long as no one reorders to alters the unit systems arrays inside `unit.cc`. Would it be better to use something like `BKE_unit_base_scalar` to get the scaling factors instead?

Aras Pranckevicius commented

2024-10-03 10:10:40 +02:00

btw I'm not too familiar with the whole units system, perhaps @ideasman42 would have better opinions

Cedric Steiert commented

2024-10-15 16:07:25 +02:00

First-time contributor

Hi Aras, i didn't like the hardcoding either due to the reordering issue, usually try to avoid it.

In theory following code should work instead of hardcoding the bytes as type identifier and values as scalars

int base = BKE_unit_base_get((const void *)&scene->unit.system);
double base_scalar = BKE_unit_base_scalar(B_UNIT_LENGTH, base);

however base is always 1 and thus base_scalar always 1.0 no matter which scene unit is set for length in the blender scene properties. Even when changing the base here manually, only at int 5 there is another value despite 1.0.
I'll be honest, i have no idea how accessing the user defined scene unit works, thus the hardcoded approach.

The main issue is knowing which scene_unit is selected, only way i found until now is using scene->unit.length_unit and comparing it's byte values. I'd be glad to implement a proper idea over that if someone points me into the right direction.
The second thing is the scalars values, these could be refactored to using UN_SC_M from unit.cc, as they're already defined there.

little side note: only the dropdown entry Scene unit length of this PR is affected by this issue.

Hi Aras, i didn't like the hardcoding either due to the reordering issue, usually try to avoid it. In theory following code should work instead of hardcoding the bytes as type identifier and values as scalars ```cpp int base = BKE_unit_base_get((const void *)&scene->unit.system); double base_scalar = BKE_unit_base_scalar(B_UNIT_LENGTH, base); ``` however `base` is always `1` and thus `base_scalar` always `1.0` no matter which scene unit is set for length in the blender scene properties. Even when changing the `base` here manually, only at int `5` there is another value despite `1.0`. I'll be honest, i have no idea how accessing the user defined scene unit works, thus the hardcoded approach. The main issue is knowing which scene_unit is selected, only way i found until now is using `scene->unit.length_unit` and comparing it's byte values. I'd be glad to implement a proper idea over that if someone points me into the right direction. The second thing is the scalars values, these could be refactored to using `UN_SC_M` from `unit.cc`, as they're already defined there. _little side note: only the dropdown entry `Scene unit length` of this PR is affected by this issue._

Aras Pranckevicius referenced this pull request

2024-10-08 09:10:00 +02:00

USD: Adding an option to convert the scene's meters per unit value #122804

Cedric Steiert changed title from ~~IO: Add file unit type selector to stl importer and exporter~~ to WIP: IO: Add file unit type selector to stl importer and exporter

2024-10-15 16:22:41 +02:00

buildbot/vexp-code-patch-lint Build done.

Details

buildbot/vexp-code-patch-linux-x86_64 Build done.

Details

buildbot/vexp-code-patch-windows-amd64 Build done.

Details

buildbot/vexp-code-patch-darwin-arm64 Build done.

Details

buildbot/vexp-code-patch-darwin-x86_64 Build done.

Details

buildbot/vexp-code-patch-coordinator Build done.

Details

This pull request is marked as a work in progress.

View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u main:Bujus_Krachus-main

git checkout Bujus_Krachus-main

Sign in to join this conversation.

No reviewers

No Label

				`@ -0,0 +1,35 @@`
				`/* SPDX-FileCopyrightText: 2023 Blender Authors`

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

WIP: IO: Add file unit type selector to stl importer and exporter #128337

Checkout