Setting up Units for Millimetres

[Kagukara]

When setting up Bforartists for millimetres it doesn't recognise the already set parameters if an object (Cude for instance) hasn't been placed, or after quitting and reopening the application. I have tested this on version 3.6.1 and 3.6.0 AppImages.

Steps to Reproduce

1. Launch bforartists AppImage (no .config files)
2. Add Cube from the Header

• If you don't add a Cube now, your Cube after setting up Millimetres will be:
• • Scale X,Y,Z = 1.000 and Dimensions: X,Y,Z = 2000 mm
• • Unit Scale is still 0.001 and Length is Millimetres
• Adding and then deleting the Cube also works

3. Go to Scene → Units in Properties side menu
4. Change Unit Scale to 0.001
5. Change Length to Millimetres
6. Go to Overlays in the Viewport Header
7. Change Grid Scale to 0.001
8. Go to View and change Clip Far to 10000 mm
9. Add another Cube from the Header

• Cube is Scale X,Y,Z = 1.000 and Dimensions: X,Y,Z = 2 mm
• Deleting and re-adding a Cube will keep its Scale and Dimensions

10. Edit → Save Startup File → Save Startup File

Writing homefile: "/home/richard/.config/bforartists/4.0/config/startup.blend" ok
Info: Startup file saved

• Saving with the Cube still in the scene doesn't matter

11. File → Quit → Don't Save

Saved session recovery to "/tmp/quit.blend"
Writing userprefs: "/home/richard/.config/bforartists/4.0/config/userpref.blend" ok
Info: Preferences saved

Bforartists quit

• Saving the file and renaming it to userpref.blend and replacing the existing one doesn't help

12. Launch bforartists appimage (.config now has files)

Read prefs: "/home/richard/.config/bforartists/4.0/config/userpref.blend"

13. Add Cube from the Header

• • Cube is now Scale X,Y,Z = 1.000 and Dimensions: X,Y,Z = 2000 mm
• • Unit Scale is still 0.001 and Length is Millimetres
• Changing back Unit Scale to 1.0 and Length to Meters the Cube is:
• • Scale X,Y,Z = 1.000 and Dimensions: X,Y,Z = 2000 m

At step 13 the only way for the Cube to be scaled properly is to Load Factory Settings and redo steps 2 → 8. Load Factory Settings doesn't delete the startup.blend file in ~/.config/bforartists/4.0/config/ so you'll have cubes set to 2000 mm unless you either Load Factory Settings or remove the startup.blend from ~/.config/bforartists/4.0/config/.

Temporary Fix

• Set these parameters and Save Startup File
• • Unit Scale: 1.00
• • Length: Meters
• • Grid Scale: 0.001
• • Clip Near: 0.01 m
• • Clip Far: 1000 m

Just have to work in meters for the time being.

System Information

• OS: Arch Linux
• Kernel: 6.4.11-arch2-1
• GPU: AMD Radeon RX 7900 XTX (gfx1100, LLVM 18.0.0, DRM 3.52, 6.4.11-arch2-1)
• GPU Driver: 4.6 Mesa 23.3.0-devel (git-71a2d651c1)
• AppImage Version: Bforartists-3.6.1.glibc2.28-x86_64.AppImage

[Draise14]

Thanks for the detailed report!!! I'm having difficulty understanding the issue here though.

What is the goal?

I have done the unit measurements and file startup savings trying to copy what you're doing, but I don't see any inconsistencies and I cannot reproduce the issue.

1. Adding a cube will always be unit scale 1.000 and the dimensions will be 2000mm or 2m, depending on scene units. If you change the unit scale, it will be 1 unit scale at X multiplier. Ei.. 0.001 would be 2mm instead, but still be 1 unit scale. Unit scale is a software unit that's internal, and when you apply scale, you can keep scale to 1.000 at 2mm to store in the startup - and when you scale back up to 2m and it would be 1000.000 unit scale. Scale of an object is a relative scale to world scale units in internal units, not scene measurement units.
2. Changing view clip and grid size does not affect anything other than the camera clip and grid overlay.
3. Scene units in length is a readout, but it's relative to your scene units.

Here is an example where the dimensions changes to scene units, but the scale remains the same.

Here is an example of the object scaled to 0.001 - with the correct dimensions listed based on scene units. Units are ok.

Here I save the startup with an applied scale of the 2mm cube, set the scene units to mm and saved startup, it says it's 2mm wide when loading again. Cannot reproduce the issue.

If I have a 2mm object with 1 unit scale - then with a new unit scale at 0.001, the new relative dimension of the 2mm cube would be 0.000002mm if I change the unit scale to 0.001. it is best to keep unit scale to 1 internal units, and keep the dimensions relative to 1 for simplicity in your startup units. it is a bit like a multiplier. On export, you can store in the correct FBX units you'd need.

Could you do some screen captures of your issue to help understand it a bit better - so I can reproduce? Right now I can't seem to find the problem. Thank you for the detailed explanation, yet a screen capture could speak a thousand words.

[Kagukara]

The goal was to have millimetres setup properly, so I watched this video on how to set it up. How to : Setup Blender into millimetres (mm) - Blender Tutorial

Default factory settings:

How it looks at step 9:

How it looks at step 13:

[Draise14]

If you add a new cube at unit scale 0.001 then the new cube will be scale 1.000 at 2mm.

If you save a 2m cube in the startup, it will be 2000mm large, best to delete it and add a new cube.

I changed the grid to mm too (scene units 0.001)

[Kagukara]

If you add a new cube at unit scale 0.001 then the new cube will be scale 1.000 at 2mm.

Correct.

If you save a 2m cube in the startup, it will be 2000mm large

This was not the case. New Cubes will be 2000 mm, the Cube that was 2 mm before would still be 2 mm on startup. Like I said in my steps to reproduce.

[Draise14]

Cannot reproduce. I saved the startup with the new units, and the new cube is 2mm.

[Draise14]

Note: This may be a new build of Bforartists, and we are currently working on 3.6.2, so this may be an issue from earlier builds. Will try the appimage now.

[Kagukara]

Here is a video of the steps (video had to be compressed so I could upload it, but is still readable):
https://github.com/Bforartists/Bforartists/assets/43391109/e0822c24-4337-445b-bffc-223da9a251a3

[Draise14]

Confirmed, the appimage has the issue, but not the latest builds. 3.6.2 should come out later this week and this shouldn't be an issue. Must have been a Blender issue that bleed through, and a reason they did a point release.

[Kagukara]

Thank you for the confirmation, and great to hear that its not present in the latest build. Will come back to confirm myself when it releases, and then close the issue if it is fixed.

[Draise14]

I have tested the steps in Blender 3.6.2, the issue remains. I also tested in the latest release candidate for Bforartists 3.6.2 appimage, same issue. But since this is now escalated to a Blender issue - there is not much we can do. I recommend you report this directly to Blender here: https://projects.blender.org/

[Draise14]

Found blender 4.0.0 on the 28-08-2023 doesn't have the issue on Windows... so.. I really don't know what's up here, will postpone. Next weekend, could you test the devbuild?

[Kagukara]

Tried to instal blender-develop-git from the aur. DISABLE_CUDA=1, DISABLE_OPTIX=1 and DISABLE_USD=1 disabled so it could start building.

Like all the other blender packages on arch and the aur it failed to build. Not sure why this is the case, but I have a feeling it something to do with me using mesa-git drivers or something. As this was the case a while ago I opted to looking for an appimage for blender which lead me to bforartists. Sorry I cannot test blender 4.0.0/devbuild unless there is an appimage.

[ReinerBforartists]

Appimage for 3.6.2 is up. https://github.com/Bforartists/Bforartists/releases/tag/v3.6.2

[Kagukara]

The issue is still there in 3.6.2 AppImage.

[ReinerBforartists]

I have tested the steps in Blender 3.6.2, the issue remains.

@Kagugara , @Draise14 , is this issue reported to Blender already? When it's a Blender bug then there is little that we can do except reporting it.

[Kagukara]

Blender has now been fixed in the arch repository now allowing me to download the package. I have changed it to millimetres and it works as intended. This is blender version 3.6.4.

This was already an issue reported to blender, I added to the issue linking to this issue for more information.

So as its working now, I'm just waiting for an updated appimage.

[ReinerBforartists]

Many thanks @Kagukara. Blender 4 is at its way, and will arrive in around two weeks. And so will Bforartists 4. I hope that this version brings the fix then.

[Kagukara]

This issue still persists in Bforartists_401-.glibc2.35-x86_64.AppImage. I have rechecked Blender 3.6.5 and this issue doesn't happen. I'm unable to build the blender-git package on the aur as it segfaults.

[Draise14]

Would a build on an Arch distro help you test? I wonder if this is an issue due to compiling the Appimage from Debian based build - then trying to use it on an Arch distro?

[Kagukara]

If I could get a PKGBUILD file that would be nice, as the bforartists packages on the aur are flagged out of date. Or if you're talking about building the appimage on an arch distro that might also help if its easier.

[Draise14]

This issue still persists in Bforartists_401-.glibc2.35-x86_64.AppImage. I have rechecked Blender 3.6.5 and this issue doesn't happen. I'm unable to build the blender-git package on the aur as it segfaults.

Could you also check in Blender 4.1 per chance?

[Kagukara]

I'm unable to build the blender-git package on the aur as it segfaults.

The version on archlinux is 3.6.5 and if Blender 4.1 is the blender-git package on the aur, then unfortunate not.

EDIT: I've posted a comment of my blender.crash.txt to the blender-git package, so hopefully I get a response on how to fix the problem.

[ReinerBforartists]

This issue still persists in Bforartists_401-.glibc2.35-x86_64.AppImage. I have rechecked Blender 3.6.5 and this issue doesn't happen. I'm unable to build the blender-git package on the aur as it segfaults.

The problem here is that Blender 3.6.5 is version 3.6.5 of the code. But we are already at the Blender 4.1.0 code with Bforartists. And so this is no valid comparison. We would need to check if the problem also exists in the Blender 4.1.0 code. And for that we need a working Arch version compiled from the Blender master.

We are simply in trouble here since nobody uses Arch in our team. And on top of it , Arch is a very own beast when it comes to compiling Blender / Bforartists as you just have found out. So it can happen that we will simply not find a solution here.

[ReinerBforartists]

I will close this now as known issue. There is unfortunately nothing that we can do at our end.

[Kagukara]

I have been able to install blender 4.1.0 and this doesn't happen, it is only happening in bforartists. @ReinerBforartists

[ReinerBforartists]

Many thanks for getting back here. I could reopen it, but we have still simply no idea where this comes from :/

[Kagukara]

Would it be possible if someone on the bforartists team could maintain the aur package? As it could be an issue with the appimage and compiling from source maybe a possible fix. At the moment the bforartists-git has no maintainers, and both are flagged out of date.

https://aur.archlinux.org/packages/bforartists-git

https://aur.archlinux.org/packages/bforartists

[ReinerBforartists]

As told, we don't have any Arch users in our team anymore. The one who did this has left the team. And so we don't have somebody who is able to maintain it. Sorry.

[Draise14]

I have Garuda on virtual that may load Bforartists without GPU (last known working version: 3.6.2). It's an arch distro, maybe that can be troubleshooted there. Will do a compile and see.

[Draise14]

Ah, scratch that. No-longer works due to Blender updating OpenGL.

[Kagukara]

Try using distrobox, I just remembered that existed. I made a container using distrobox create --image debian:12.5, downloaded the .deb from the website and did sudo apt install ~/downloads/bforartists_402.deb. But when I go to run the program I get /opt/bforartists/bforartists: error while loading shared libraries: libxkbcommon.so.0: cannot open shared object file: No such file or directory.

[Kagukara]

I got it working with distrobox inside a debian 12.5 container. I had to install libxkbcommon-x11-0 and libsm6 in the container via sudo apt install.

Installed libwayland-cursor0, libwayland-egl1 and libdecor-0-0 as well to get no more Unable to find.

I redid the initial steps and still got the same result. That being when adding a new cube the dimensions: X,Y,Z = 2000mm instead of dimensions: X,Y,Z = 2mm.

[Draise14]

I've got Hyper-V working on W11 and it is accessing the GPU nicely - so Bforartists loads there now. So I will make the environment and try compile from source, see if it's the Appimage or something else.

This is really obscure, because technically we haven't touched this part of the code that would store or do alter anything like this.

[Draise14]

Ok, can confirm, this issue persists in the Windows build too.

This is a frustrating one, because the code to add geo is identical to Blender, and there is no error.

[Draise14]

Ok, double checked in Blender. Same issue. So yeah, this is a blender issue from main.

@Kagukara Please report to Blender! I can maybe report it tomorrow.

[Kagukara]

@Kagukara Please report to Blender! I can maybe report it tomorrow.

Its already reported here: https://projects.blender.org/blender/blender/issues/108385 as I said in this comment: #3695 (comment)

Ok, double checked in Blender. Same issue. So yeah, this is a blender issue from main.

How come the issue doesn't happen in Blender for me though? I've tried it in 3.6.5, 4.0.2, 4.1 and 4.2.

[Draise14]

blender_SMQS5Fvrp4.mp4

You aren't setting "default unit of millimeters". You are setting a default unit system of "Metric" and preferred length value of "Millimeters". The "Length" input does not change how big new items will be created, it only changes how the values are shown:

This is from a build in the Blender main from yesterday.

I think the size of the default object being unpredictable, as yes, it is unpredictable... is probably a bug and unintended UX directly inherited from Blender. Looking at the code, everything should be created to 1 scene unit in each axis (2 scene units total). Scene units are agnostic to the display of the scene unit scale for the measurements ratio, agnostic to the measurement type, and agnostic to the grid view, or should be agnostic. The geometry are set by one scene unit scale on all axis (+1x, -1x, +1y -1y +1z -1z).

blender_KnxPTZoZuq.mp4

This will have to be fixed by upstream from Blender directly, since the unpredictability can be reproduced in Blender.

And to clarify, the scene unit is relative to when you re-update the depsgraph, so when you save the startup, instead of building to 0.001 of that sessions scale of a scene unit, the new scene scale becomes 1 again, and the scene unit display will then show 0.2mm instead of 20mm for that same cube stored in the startup blend, because it is resetting the internal scene units to 1 again. I think that would be the core issue from Blender and why it "appears" to work. If you store the new startup yet again, then 0.2mm for a scene unit will then load up to be 0.0002, unless you put the scene units scale back to 1 again...

Ngl, that's a really odd and broken UX.

[Kagukara]

I don't quite understand what you've said but, it looks like you know what is going on and understand whats happening.

As to how its working for me I've provided a video:
Video in 3840x2160 with lowered bitrate

millimetres.mp4

Video converted to 1920x1080

millimetres-1080.mp4

Before doing "Save Startup File" the cube shown as larger (dimensions: X,Y,Z = 2000mm), once you've "Save Startup File" and restarted blender all newly created cubes are now dimensions: X,Y,Z = 2mm. Doing this in bforartists keeps the dimension at 2000mm even after doing "Save Startup File" and restarting.

Are you able to replicated this?

EDIT: Didn't realise the video cut off before the end, re-uploaded it and should be fine now.

[Draise14]

Can confirm, it is as expected in Bforartists. Cube comes in at 2 blender/scene units, regardless of unit scale precision or measurement drawing in the GUI, or grid. It is agnostic, which is correct and expected UX. Tooltip mentions the precision of the scale, not the default spawn dimensions of objects - so getting a new object scale is bizzare.

I have confirmed in Blender though... that it is broken.

When you scale the UI up to 1.000 in Blender again, save startup again, the object will spawn at 20mm instead of 2 scene units of 2m. So If I save startup after that again at 0.001, the 20mm "scene unit" will then be 0.02mm, and the new spawned cube will be at another dimension of 20mm, also broken. Blender is storing new scene unit scales, which makes resetting scene units strangely a 3 setting jiggle. And for some reason the grid scale is affecting how the objects are spawning, when it should only be the grid overlay setting. These by UX, should be entirely agnostic.

[Kagukara]

Thank you for looking at this further and providing a more in-depth explanations.

If bforartists is working as intended, how would I go about setting up millimetres so that when you add a cube it adds it at 2x2x2mm with the grid being 1mm per square?

Is there a setting to change the default size the objects are being added as or is it not possible/a different way?

[Kagukara]

I've also updated the video so it doesn't cut off, from my understanding and the video I still get a different result from the latest tests you've provided.

[Draise14]

There is currently no intended (thus documented) method to set the default size of an added object.

Though I could build this into Bforartists as intented in the GUI code, and add that to the tooltip... and make it predictable, without needing to save startup too.

[ReinerBforartists]

This would imho be a job for an addon then. Not the main UI. We promised feature parity with Blender. And this one could bring us into trouble. But this would be a new task then.

The initial task, well, it is nothing that we could fix at our end. It is a fundamental how Blender works. Can we close it?

[Draise14]

Will add it to the power user tools addon.