Slicer preview is nonsensical

[shdwshard]

Application Version

4.10.0

Platform

Mac OS X

Printer

Tronxy X5SA

Reproduction steps

Tried to slice a large model Visited the Preview screen

Actual results

The visualization is nonsensical with "rays" eminating from the model, and the model itself is not rendered properly

Expected results

The visualization should have been an accurate representation of the slicing results

Checklist of files to include

• [ ] Log file
• [X] Project file

Additional information & file uploads

Garden Tank.3mf.zip

[fvrmr]

Hi @shdwshard do you have a M1? If so, it is a known issue. This is happening because Cura uses OpenGL libraries and with the new Macbooks containing the M1 processing chips, Apple has introduced incompatibilities between the OpenGL libaries used and the latest firmware used by Macbooks.

[mikelexp]

I'm having the same problem with 4.11 on an Intel Mac (MacBook Pro 16 i7). 4.10 was ok.

[shdwshard]

No, I have an intel based MacBook Pro.

Interestingly a reboot solved the issue, so more than a direct incompatibility, it seems like the OpenGL libraries used by Cura are unstable on newer MacOS versions.

This is also a machine I use for gaming, so it's possible some state gets left over, or the is switches to the discrete GPU in a way that Cura doesn't like.

[fvrmr]

@shdwshard good to know that a reboot solved your issue. It is correct that the OpenGL libraries are not working well with MacOS especially with M1. Are you maybe using Monterey Beta?

A possible work around is to set manually for force_empty_shader_cache = True under [view] in the cura.cfg file. If there is no [view] header you can create one. You can find your cura.cfg file via Help - Show Configuration Folder.

[shdwshard]

No, I'm on Big Sur, and I will definitely try that if it happens again.

Apple seems to be really focused on Metal, so I guess it's no surprise that OpenGL compatibility is sliding/suffering in recent OS releases.

Just FYI, here are some more detailed stats of my system so you have another data point as to what systems can hit this problem.

MacOS Big Sur
Version 11.5.2 (20G95)
MacBook Pro (16-inch, 2019)
Processor 2.3 GHz 8-Core Intel Core i9
Memory 16 GB 2667 MHz DDR4
Graphics AMD Radeon Pro 5500M 4 GB

[Ghostkeeper]

So... I'm guessing this is really just a bug in the OpenGL implementation of your video drivers?

We are kind of stuck with Qt (lest we have to rewrite our entire front-end), and Qt doesn't support Metal. It does support Vulkan, but this will require some extra tricks to pull off since Vulkan libraries are not provided by MacOS itself; we'd need to provide it with our distribution and I don't know how portable that would be with the 4 versions of MacOS that Cura currently supports. And I fear that Vulkan is going to be in a similar state to OpenGL, perhaps even worse because it's less battle-tested than OpenGL.

I don't know what we at Cura could really do about this problem.

[colatuttorf]

So... I'm guessing this is really just a bug in the OpenGL implementation of your video drivers?

We are kind of stuck with Qt (lest we have to rewrite our entire front-end), and Qt doesn't support Metal. It does support Vulkan, but this will require some extra tricks to pull off since Vulkan libraries are not provided by MacOS itself; we'd need to provide it with our distribution and I don't know how portable that would be with the 4 versions of MacOS that Cura currently supports. And I fear that Vulkan is going to be in a similar state to OpenGL, perhaps even worse because it's less battle-tested than OpenGL.

I don't know what we at Cura could really do about this problem.

It sounds like Qt has supported Metal natively since 5.14 released in 2019, and all releases since. What Qt build does Cura use, and is there a roadmap to updating it to a more recent version?

[Ghostkeeper]

Cura uses Qt 5.15.2 at the moment. We are planning to update it to Qt 6.2, but this drops support for QtQuick.Controls 1 which is what 75% of our GUI is built with so that is a major issue. 5.15.2 is the last version that still support QtQuick.Controls 1.

I think my comment in September was based on https://forum.qt.io/topic/101591/qt-and-metal/5, which is old information. It's an opt-in feature since Qt 5.14 for 3D graphics only, and in 5.15 they added the ability to run QtQuick on top of that too which we need in Cura.

It seems that the issue is then that we would need to call upon a new system called QRhi instead of using QOpenGLContext. It's a rewrite of our entire graphics stack including shaders, but likely will remain supported for longer. This does require SPIR-V to be supported though, so it would cause us to drop support for OpenGL versions before 4.6, which is a problem because quite a few laptops are still lingering on 4.1, 4.0 or even 3.X.

[rburema]

While all those larger updates are still going on in the background (early next year ... some of the things we have to do to upgrade to (Py)Qt6.2 are extensive), we are considering a relatively small to the way we render things that we hope might just also solve these problems.

Could any of you try to install and run this version https://storage.googleapis.com/software.ultimaker.com/cura/graphics-test_Ultimaker_Cura-4.12.99-Darwin__20211027.dmg and report back?

I don't have all that high hopes for this one, but it might just work.

[antoooooooooooonie]

Confirmed to still happen on Cura 5.2.1

Not sure if yet another screenshot of a glitched preview is even useful at this point but:

Computer specs:

Is there any known fix for this besides downgrading Cura? Or is it related to me running macOS Ventura?

[shdwshard]

Shutting down and restarting the machine fixes the issue for me, and tends to make me think this is a GPU or GPU Driver state issue more than a version specific problem. My M1 has some other weird transients with graphics overlays and such which are also remedied by a cold boot.

[altimac]

@shdwshard good to know that a reboot solved your issue. It is correct that the OpenGL libraries are not working well with MacOS especially with M1. Are you maybe using Monterey Beta?

A possible work around is to set manually for force_empty_shader_cache = True under [view] in the cura.cfg file. If there is no [view] header you can create one. You can find your cura.cfg file via Help - Show Configuration Folder.

Unfortunately I can confirm that this hack does not work. At least once the problem appeared, quitting Cura,editing the cura.cfg file to add this setting and relaunching cura (reopening the same project), slicing and previewing still shows the same bug.

Unfortunately the only fix is a reboot of the machine, which is very inconvenient.

Intel MacBook Pro too.