Mac chat - any info about 3DCoats' performance on any new M1 machine ? - thx!

[David McEachern]

Hello, 

Just upgraded to 3D Coat 2023 after seeing MacOS ARM support being added. when I open the 2023.29, I get the error: (0,0) : ERR : Invalid configuration. Verify the registered application interface. No interface loads and the error repeatedly pops up if I click around. I'm on a Mac Studio M1 Ultra with Ventura 13.5.2. (I've also sent an email to support with screen shots.) 

Edited September 22, 2023 by David McEachern

[Hickz]

Yeah, I have the same issue as David, here's a screenshot:

[Hickz]

@SERGYI , are there any updates? We're itching to try the live booleans here too

[SERGYI]

Thank you all for the feedback. I have uploaded "3DCoat 2023.31" for macOS:
https://pilgway.com/~sergyi/links-macOS.html
The build is for Intel (not Universal). Here is the reason. I have bought a Mac mini M1 and investigated the cause of the issues you have encountered. It turned out that the "AngelScript" library does not support the native calling of functions and methods on the Apple M1 chip. "3DCoat" is heavily dependent on the "AngelScript". All functions and methods (thousands and thousands of them) are registered in "3DCoat" in a way that counts on the native calling of functions and methods. We will discuss this situation at the meetings to understand what we can do with this problem.

[Hickz]

Thank you for the update, Sergyi. Unfortunately, it seems like live booleans aren't working on macOS, so can't test them alas. Otherwise seems to work as previous builds have.

[Metin Seven]

Good to read that you've got an Apple Silicon Mac now, @SERGYI! I hope you will be able to solve the AngelScript issue soon.

[voidcore]

Reading at Anglescript homepage we can now see since a few months:
 

• Added support for native calling conventions on Apple OS's with M1/M2 CPUs (Thanks Sam Tupy)

So can we expect a native Mac apple silicon build now that works? I have been holding off upgrading from my old 3dcoat in waiting for this. Best regards!

[Metin Seven]

On 9/12/2024 at 5:40 PM, voidcore said:

Reading at Anglescript homepage we can now see since a few months:
 

• Added support for native calling conventions on Apple OS's with M1/M2 CPUs (Thanks Sam Tupy)

So can we expect a native Mac apple silicon build now that works? I have been holding off upgrading from my old 3dcoat in waiting for this. Best regards!

Any news about improved Apple Silicon support in 3D-Coat for macOS?

Thanks!

Edited January 24, 2025 by Metin Seven

[SERGYI]

On 1/24/2025 at 1:24 PM, Metin Seven said:

Any news about improved Apple Silicon support in 3D-Coat for macOS?

Thanks!

I am still waiting while our employee converts "3DCoat 202x" UI scripts to "Python". In the meantime, I compared the performance of the "3DCoat 202x" on my old Mac Pro Intel Xeon E5 vs. Mac mini M1. Temporarily, I have removed the "AngelScript" library from the Xcode project and commented out all source code in the "3DCoat 202x" project that uses the "AngelScript". Then, I built two "3DCoat 202x" executables for macOS: the first for Intel architecture (x86_64) and the second for Apple architecture (arm64). "3DCoat 202x" without the "AngelScript" doesn't display most of its interface. But it shows enough to run AUTOPO on a scene from a file. Here are the results of AUTOPO on the same file:
Mac Pro CPU Intel Xeon E5 3.7 GHz, RAM 32 GB 1866 MHz DDR3, Storage 480 GB SSD PCIe: 22 seconds on Intel executable;
Mac mini CPU Apple M1, RAM 16 GB, Storage 245 GB SSD NVMe: 11 seconds on Intel (x86_64) executable, 10 seconds on Apple (arm64) executable.
These results show that the Intel executable is 2 times faster on Apple M1 than on Intel Xeon E5. Also, they show that the Apple executable (arm64) gives about a 9% performance boost. So, the switch from Intel Xeon E5 to Apple M1 CPU dramatically increases the performance of the Intel executable. However, switching from the Intel executable to the Apple executable on Apple M1 gives only a tiny fraction of that initial boost. Of course, the Apple executable will not be more stable than the Intel executable because instability comes from data and how the algorithms process that data. The stability does not come from the architecture of executable instructions.