Since now half a year it says succinctly: "...the Mac version will follow soon...".
I think I speak in the name of all Mac users when I ask here about the state of affairs.
I would be happy to get an honest answer.
Will there be further Mac versions of Terragen or is the effort simply too big and 4.5.71 was the last official Mac version? Where are the difficulties?
Already 4.5.71 is not optimally adapted to the new macOS (Ventura). For me, the performance and usability suffers compared to previous versions and has become very sluggish.
The Mac build of Terragen 4.6 should be out before the end of January. I'm sorry it was put on hold towards the end of last year while we prioritized Terragen Sky Early Access, but Terragen 4.6 for Mac is a top priority now. The "difficulties" are just that we had to re-create the build setup for a number of reasons. It's 95% done and I am pretty sure we'll release it before the end of January.
Here we are, and January has come and gone, and still no Mac upgrade. Starting to doubt the true commitment to continued development. Is there a new date or is it time to look elsewhere?
There's a 4.6 Frontier build for the Mac now. You can get it with Help -> Check for Updates (if Terragen is running with a Pro or Creative license).
The app should be 'notarized' but despite that it's still showing a warning when opened, and you might need to bypass that to run it. Another issue is that the OpenVDB plugin isn't loading in some cases. If you're able to try this build and send us feedback that would be much appreciated.
Quote from: Matt on February 21, 2023, 02:31:26 PMThere's a 4.6 Frontier build for the Mac now. You can get it with Help -> Check for Updates (if Terragen is running with a Pro or Creative license).
The app should be 'notarized' but despite that it's still showing a warning when opened, and you might need to bypass that to run it. Another issue is that the OpenVDB plugin isn't loading in some cases. If you're able to try this build and send us feedback that would be much appreciated.
I've got the warning here, and I've also got the openVDB plugin not being allowed to open. Any suggestions on how to address the OpenVDB plugin issue? What all "new" (post-4.5) features _should_ be working in this MacOS Frontier release?
More generally, when can MacOS customers expect a _stable_ release with feature parity? November 2022 was
half a year ago, just sayin'.
Apologies if I sound a bit frustrated. It feels as if "MacOS progress" is increasingly lagging & deprioritized behind Windows
and now Linux as well. While I can accept it to a point versus Windows, seeing Mac is now ALSO consistently lagging behind Linux feels much more frustrating, and much less... justifiable, esp. given how long the current disparity has existed.
System Details:
Hardware:
Hardware Overview:
Model Name: Mac Pro
Model Identifier: MacPro6,1
Processor Name: 12-Core Intel Xeon E5
Processor Speed: 2.7 GHz
Number of Processors: 1
Total Number of Cores: 12
L2 Cache (per Core): 256 KB
L3 Cache: 30 MB
Hyper-Threading Technology: Enabled
Memory: 64 GB
System Firmware Version: 474.0.0.0.0
OS Loader Version: 540.120.3~22
SMC Version (system): 2.20f18
Panel Illumination Version: 1.4a6
Memory:
Memory Slots:
ECC: Enabled
Upgradeable Memory: Yes
DIMM1:
Size: 16 GB
Type: DDR3 ECC
Speed: 1866 MHz
Status: OK
Manufacturer: 0x80CE
Part Number: 0x4D33393342324737305148302D434D412020
DIMM2:
Size: 16 GB
Type: DDR3 ECC
Speed: 1866 MHz
Status: OK
Manufacturer: 0x80CE
Part Number: 0x4D33393342324737305148302D434D412020
DIMM3:
Size: 16 GB
Type: DDR3 ECC
Speed: 1866 MHz
Status: OK
Manufacturer: 0x80CE
Part Number: 0x4D33393342324737305148302D434D412020
DIMM4:
Size: 16 GB
Type: DDR3 ECC
Speed: 1866 MHz
Status: OK
Manufacturer: 0x80CE
Part Number: 0x4D33393342324737305148302D434D412020
NVMExpress:
Generic SSD Controller:
Samsung SSD 970 EVO Plus 2TB:
Capacity: 2 TB (2,000,398,934,016 bytes)
TRIM Support: Yes
Model: Samsung SSD 970 EVO Plus 2TB
Revision: 4B2QEXM7
Link Width: x4
Link Speed: 5.0 GT/s
Detachable Drive: No
BSD Name: disk0
Partition Map Type: GPT (GUID Partition Table)
Removable Media: No
S.M.A.R.T. status: Verified
PCI:
AMD FirePro D700:
Name: ATY,Ikura
Type: Display Controller
Driver Installed: Yes
MSI: Yes
Bus: PCI
Slot: Slot-1
Vendor ID: 0x1002
Device ID: 0x6798
Subsystem Vendor ID: 0x106b
Subsystem ID: 0x0128
Revision ID: 0x0000
Link Width: x16
Link Speed: 8.0 GT/s
AMD FirePro D700:
Name: ATY,IkuraS
Type: Display Controller
Driver Installed: Yes
MSI: Yes
Bus: PCI
Slot: Slot-2
Vendor ID: 0x1002
Device ID: 0x6798
Subsystem Vendor ID: 0x106b
Subsystem ID: 0x0127
Revision ID: 0x0000
Link Width: x16
Link Speed: 8.0 GT/s
Diagnostics:
Power On Self-Test:
Last Run: 4/21/23, 11:40 AM
Result: Passed
Graphics/Displays:
AMD FirePro D700:
Chipset Model: AMD FirePro D700
Type: GPU
Bus: PCIe
Slot: Slot-1
PCIe Lane Width: x16
VRAM (Total): 6 GB
Vendor: AMD (0x1002)
Device ID: 0x6798
Revision ID: 0x0000
ROM Revision: 113-C3861J-687
VBIOS Version: 113-C3861XA-028
EFI Driver Version: 01.0D.687
Automatic Graphics Switching: Supported
gMux Version: 4.0.11 [3.2.8]
Metal Family: Supported, Metal GPUFamily macOS 2
Connection Type: No Display Connected
AMD FirePro D700:
Chipset Model: AMD FirePro D700
Type: GPU
Bus: PCIe
Slot: Slot-2
PCIe Lane Width: x16
VRAM (Total): 6 GB
Vendor: AMD (0x1002)
Device ID: 0x6798
Revision ID: 0x0000
ROM Revision: 113-C3861J-687
VBIOS Version: 113-C3861XB-028
EFI Driver Version: 01.0D.687
Automatic Graphics Switching: Supported
gMux Version: 4.0.11 [3.2.8]
Metal Family: Supported, Metal GPUFamily macOS 2
Displays:
DELL S3221QS:
Resolution: 5120 x 2880 (5K/UHD+ - Ultra High Definition Plus)
UI Looks like: 2560 x 1440 @ 30.00Hz
Framebuffer Depth: 30-Bit Color (ARGB2101010)
Display Serial Number: JVNKB33
Main Display: Yes
Mirror: Off
Online: Yes
Rotation: Supported
Printer Software:
PPDs:
PPDs:
Printers:
Printers:
Image Capture Devices:
Image Capture Devices:
Image Capture Support:
Image Capture Support:
Path: /Library/Image Capture/Support/LegacyDeviceDiscoveryHelpers/AirScanLegacyDiscovery.app/Contents/Info.plist
Version: 17
System Library Extensions:
System Library Extensions:
Path: /System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/AppleXserveRAID.kext
Version: 533.120.2
Path: /System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/FireWireStorageDeviceSpecifics.kext
Version: 533.120.2
Path: /System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/USBStorageDeviceSpecifics.kext
Version: 533.120.2
Path: /System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/AppleATAPIStorage.kext
Version: 533.120.2
Path: /System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/SCSIDeviceSpecifics.kext
Version: 533.120.2
Path: /System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/SonyXDCAMDriver.kext
Version: 533.120.2
Path: /System/Library/Extensions/AFKACIPCKext.kext
Version: 1.0
Path: /System/Library/Extensions/AppleHIDKeyboardEmbedded.kext
Version: 1.2.0
Path: /System/Library/Extensions/IOStreamFamily.kext/Contents/PlugIns/IOStreamUserClient.kext
Version: 1.1.0
Path: /System/Library/Extensions/AppleBSDKextStarter.kext/Contents/PlugIns/AppleBSDKextStarterVPN.kext
Version: 1.0
Path: /System/Library/Extensions/AppleBSDKextStarter.kext/Contents/PlugIns/AppleBSDKextStarterTMPFS.kext
Version: 1.0
Path: /System/Library/Extensions/AppleTopCase.kext
Version: 5450.8
Path: /System/Library/Extensions/AppleTopCase.kext/Contents/PlugIns/AppleTopCaseDriverV2.kext
Version: 5450.8
Path: /System/Library/Extensions/AppleTopCase.kext/Contents/PlugIns/AppleTopCaseActuatorHIDDriver.kext
Version: 5450.8
Path: /System/Library/Extensions/IOVideoFamily.kext/Contents/PlugIns/IOVideoDeviceUserClient.kext
Version: 1.2.0
Path: /System/Library/Extensions/AppleGameControllerPersonality.kext
Version: 1.0
Path: /System/Library/Extensions/AppleUSBTopCase.kext
Version: 256
Path: /System/Library/Extensions/IOHIDFamily.kext/Contents/PlugIns/IOHIDEventDriver.kext
Version: 2.0.0
Path: /System/Library/Extensions/IOHIDFamily.kext/Contents/PlugIns/IOHIDUserClient.kext
Version: 2.0.0
Path: /System/Library/Extensions/IOHIDFamily.kext/Contents/PlugIns/IOHIDEventDriverSafeBoot.kext
Version: 2.0.0
Path: /System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/IOUSBHIDDriverSafeBoot.kext
Version: 900.4.2
Path: /System/Library/Extensions/CellPhoneHelper.kext
Version: 1.4.0
Path: /System/Library/Extensions/IOUSBHostFamily.kext/Contents/PlugIns/IOUSBHostHIDDeviceSafeBoot.kext
Version: 1.2
Library Extensions:
Library Extensions:
Printers:
Status: The printers list is empty. To add printers, choose Apple menu > System Preferences..., click Printers & Scanners, and then click Add (+).
CUPS Version: CUPS/2.3.4 (macOS 12.6.5; x86_64) IPP/2.0
Software:
System Software Overview:
System Version: macOS 12.6.5 (21G531)
Kernel Version: Darwin 21.6.0
Time since boot: 5 days 22:40
So after a couple minutes of debugging, I was able to ascertain that the problem loading the OpenVDB plugin stems from it having a dependency on libtbb.12.dylib (but is looking for it in `/usr/local/opt/tbb/lib/libtbb.12.dylib`). Even in Contents/MacOS if I hardlink from `libtbb.12.dylib` to `libtbb.dylib` (which is present), it won't find it there, suggesting somebody messed up the dylib path linkage for libtbb as part of the build process.
Looking at the `tgopenvdb` binary directly, using `otool -L tgopenvdb` reveals the following:
% otool -L tgopenvdb
tgopenvdb:
@executable_path/../Frameworks/UCMessengerLib.framework/Versions/A/UCMessengerLib (compatibility version 1.0.0, current version 1.0.0)
/usr/local/opt/tbb/lib/libtbb.12.dylib (compatibility version 12.0.0, current version 12.5.0)
@rpath/libopenvdb.9.1.dylib (compatibility version 9.1.0, current version 9.1.1)
@executable_path/../Frameworks/trlib.framework/Versions/A/trlib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)
The second line is clearly incorrect, stating `/usr/local/opt/tbb/lib/libtbb.12.dylib` when it should state `@executable_path/libtbb.dylib` (adjust for whether libtbb.12.dylib should have present but wasnt). Binaries can have lookup paths patched using `install_name_tool -change <orig path> <fix path> <binary>` but then you'd need to self-sign (or obviously Matt & co could properly fix / rebuild).
Alas, after tracking down, fixing all the incorrect libtbb paths, re-codesigning all changed binaries, etc. (call it 20 mins I'll never get back), loading the app got past loading libtbb.dylib... and immediately encountered another dylib that wasn't present, period -- `libblosc.1.dylib`. Although I know what that is (see here if you care or want to pursue further (https://github.com/Blosc/c-blosc)), I couldn't afford to spend more time on it.
Given the error messages when run from cmd line show these problems very clearly, I do not understand why more of an effort wasn't made to fix them. The ship-state of the "Frontier" release suggests it wasn't ever run from the cmd line. This is a minor build problem, that took maybe 5 minutes at most to diagnose, then a few iterations at around 3 mins each to address each broken binary's path, until I hit one that required more work. If Planetside KNOWS there's something more serious hiding in there, then please tell us.
Hopefully Matt or someone can make the fixes required and re-release a properly-functional Frontier Mac release package shortly.
@Planetside: Please reach out if you need info on anything related to debugging above. Without knowing exactly how you're handling builds, the above is about the best info I can provide, but the problem blocking tgopenvdb loading is obviously a combo of incorrect embedded dylib paths, and missing dependencies.
Put another half-hour or so into debugging, and after fixing & satisfying libblosc.dylib rpath, as well as fixing libboost_iostreams-mt.dylib rpath, I suspect I've finally hit the point where I cannot go further from here. The next remaining problem is that the build doesn't appear to have libtbbmalloc.dylib properly linked as a dependency for libtbb.dylib, resulting in the following (_after_ fixing the rpath problems mentioned previously):
2023-04-28 12:12:41.583 Terragen 4[48855:7865380] Error loading /Applications/Terragen 4/Terragen 4.app/Contents/PlugIns/tgopenvdb.bundle/Contents/MacOS/tgopenvdb: dlopen(/Applications/Terragen 4/Terragen 4.app/Contents/PlugIns/tgopenvdb.bundle/Contents/MacOS/tgopenvdb, 0x0106): Symbol not found: (__ZN3tbb6detail2r110deallocateERNS0_2d117small_object_poolEPvmRKNS2_14execution_dataE)
Referenced from: '/Applications/Terragen 4/Terragen 4.app/Contents/PlugIns/tgopenvdb.bundle/Contents/MacOS/tgopenvdb'
Expected in: '/Applications/Terragen 4/Terragen 4.app/Contents/MacOS/libtbb.dylib'
It appears however the libtbb.dylib integration was handled, the tgopenvdb binary was never properly linked with libtbbmalloc (and `otool -L tgopenvdb`confirms same -- while the TG4 app links against libtbbmalloc.dylib, the "tgopenvdb" plugin binary does not). That leads to loading tgopenvdb failing over missing symbols which normally I'd expect to be provided by libtbbmalloc.dylib, per the above error messages.
Unfortunately, there's not a whole lot I can do to resolve this problem after the fact -- this isn't something a simple install_name_tool change can fix, unlike the prior issues. The app and plugin need to be rebuilt with all symbol dependencies present (and proper setup for rpaths). It would be really spiffy if Matt or someone from Planetside could give some idea of when all the existing fixes needed (mentioned in this and prior post) can be integrated and released in a new Mac Frontier build?
Thanks! And where should I send the involce? ;D
There's a new Frontier build today for the Mac, version 4.6.36. You can get it with Help -> Check for Updates (if Terragen is running with a Pro or Creative license). This should resolve the issues with the OpenVDB plugin and the Notarization of the app.
We'll probably follow up with a Release build in the next couple of weeks, which will also include some rendering improvements.