Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
I seem to remember talk about DAZ Studio running in "emulation mode," using Rosetta.
I did a Google search, and here is a quote:
"Yes, Daz Studio runs on Apple Silicon (M1/M2/M3/M4) Macs, but it operates through Apple's Rosetta 2 translation layer, not natively. While the app is stable for modeling and scene setup, Iray rendering is significantly slower than on dedicated NVIDIA PC hardware because it relies on the CPU. "
You are correct, my mistake; there are current Mac Intel-Native versions, just not Apple Silicon-native versions. Thanks for the correction.
That's for Apple Silicon (M-series) machines, not Mac Intel machines. I should have remembered that since I currently have three Intel Macs running DAZ Studio natively besides my M4 Pro running using Rosetta.
I would think the Intel Macs are nearing their "outdated" status (is that the right term) since the Silicon Macs have been around for awhile.
Hey, I was a huge Mac fan from 2007 till maybe 2021.
But I got tired of the limitations due to Apple's choices of hardware internals.
I've had a Windows PC for DAZ Studio for about 6 years now. It has a wimpy 6GB nVidia card.
But so far it handles all my DAZ Studio content just fine,
Last macOS version supporting nVidia "non-apple-supplied-cards" was macOS 10.13.6 as when macOS 10.14 arrived the nVidia/Apple grudge made nVidia stop developing drivers for their cards.
CPU render is slow, but the M4 Max is pretty fast for CPU rendering. Ther biggest issue with any different render engine is the mateiral settings, it's never a straight forwards conversion, was a problem even between Poser and Studio back in the days, same with 3DL and Iray, or 3DL and LuxRenderer, or whatever engine you port your materials too.
Even engines that claim pure PBR can differ in how the interpret material settings.
Please fix your camera and controls. It's been so long, so many updates, and yet the direct control mode, when you need to quickly move the camera around the scene, hasn't been fixed. The camera twitches, sometimes jams, or moves jerkily. Everything works perfectly in 24. Why is it so hard to transfer these settings to 26? This problem isn't just mine. It's a common one. Please!
Try scroling the mouse-wheel in and out, or seelct a nearby object and Aim at it - those seem to reset things fairly often, though it is a pain.
Hi everyone. I thought you'd all like to hear my experiences with a new M5 Mac running both Daz Studio 4.24 and of course Daz Studio 2026 Beta. I have not as yet done detailed timings and so on, this is just perception of speed so far (it only arrived this earlier week). First, a little history. I've had an M2 Max Macbook Pro for a while, and it ran Daz Studio just fine, with reasonable speed on non-rendering tasks. The iRay rendering was a little sluggish, which is hardly surprising given the lack of GPU iRay support on Apple Silicon, but it was livable. Rendering itself was slow, but steady. So last year I took the step of purchasing a Lenovo Thinkpad 'top of the range' laptop, with plenty of RAM, 4tb of SSD for all those Daz goodies. It wasn't cheap, as you can imagine. And yes, the rendering on 4.24 was clearly faster, but not by a huge amount. However, everything else, notably morph loading and manipulation of figures became considerably slower. Moreover, larger scenes became unmanageable. After much thought, I put this down to Apple having unified memory across the GPU and CPU architecture, whereas the laptop was limited to 8gb of GPU memory. Since the Apple announcement a few weeks ago, I have indulged myself in the purchase of an M5 Max Macbook Pro, with 128Gb of unified memory and 8tb of SSD. I've tried both 2026 beta and 4.24. Needless to say, neither are using the 40 GPUs that the M5 has to offer (I presume). Despite this, the iRay preview is considerably faster on both than on the Thinkpad with iRay support. And the load times and manipulation of figures are dramatically faster. Instead of weaiting for a morph to load when I want to tweak a hand position or alter an expression, the response is mostly instantaneous. And of course, the 2026 beta is faster still, as appears to be the case on all platforms. On the downside, and important to note, is that the current release of 2026 beta does not properly scale menu typefaces on macos. Consequently, on ALL screen resolutions for the mac (running the latest Tahoe release), the 2026 Beta is essentially unusable, though you can muddle through with the zoom accessibility feature if you really want to. It does run fine with this important exception. This has been raised as a bug, and will hopefully be addressed shortly. My advice, in summary therefore, is to get an Apple Silicon based Macbook if looking at laptops. If looking at desktops, then obviously a whole set of other choices become available, including faster SSDs and more powerful GPUs. It's not a cheap option, it should be noted. Attached: showing latest 2026 beta, comparing native mac menu scale to Daz menu scale. If anyone has a work around, do tell, noting that changing screen resolution does not address this.
Incidentally, the screen capture above has inadvertently given the impression this is usable. This screen capture is less than 1/4 of the screen. The menus are in practice virtually unusable without very careful mouse placement and excellent eyesight... I could put it onto a larger monitor I guess, but that kinda defeats the point of a laptop.
Yes, UI scaling is off in the mac builds due to an issue with it that causes a serious memory leak. This is not intended to be the state in the long-term but it is needed to make the application usable at all for certaiin Mac set-ups.
To work around the Memoryleak-fixing UI scaling use a non 4K screen.
I would like it in 2026 also, please. It really does help both my work flow my left hand does 3D-Mouse, right hand does the mouse.
One thing I've noticed when it comes to zooming in/out using the zoom "button" and mousedown, is that it suddenly aborts the zxooming, it got a sudden mouseup event.
My workflow for Daz 4 was to work in the main viewport while setting the aux viewport in a smaller window to iray mode so I could move lights around and see realtime updates. On a 3090 this resulted in peformance barely good enough to be usable, so I had high hopes that after upgrading to a 5090 this would become even smoother and more useful. However in Daz 2026 with this setup, both the main viewport and the aux iray viewport will freeze completely for several seconds while iray spins up, and this freeze happens every time you start and stop moving the camera, making this workflow pretty unusable. In addition, the aux viewport won't update the canvas until you make it active by mousing over something. Beyond general improvements to the viewport performance that everyone has already asked for, is there any word on specifically improving the usability of iray in the viewport and also specifically the aux viewport?
That is due to Iray, not DS. I would suggest turning Iray Preview off until you have the camera in position.
But Daz 4 is much much faster to initialize iray in the viewport, and considering the terrible performance in the new daz viewport in non-iray mode, I doubt all the blame can be laid on Iray. And the viewport not even updating until you mouse over that window has to be on Daz's end.
Bug Report - The "Tools" toolbar in the Activities section of the Customize interface window can't be permanently turned off. If I create a custom layout, go in and turn off the Tools toolbar and/or completely delete all entries related to it in the toolbar customization window, it will stay off for the session. However even if I then save the custom layout, when I restart Daz, it will be forced back on and undelete itself from the settings. This causes a lot of problem becuase I created a custom toolbar with only the icons I want, but every time I restart daz the toolbar section gets flooded with all the redundant icons that I have turned off. So every time I start Daz I need to reload my custom workspace layout just to get it to go away again.
Even if you go into toolbars.dsx and force remove the entry for Tools, every time you restart Daz it gets force re-added to the file.
Does Daz to Unreal plugin work yet?
AFAIK none of the bridges have been updated yet.
Daz Studio 6.25.2026.6423
Windows 11 Version 25H2
NVIDIA GeForce RTX 5090 Laptop GPU/PCIe/SSE2 4.6.0 NVIDIA 595.79
I've 2 seemingly random crashes of Daz Studio since I started using Daz Studio 6.25.2026.6423.
Crash #1
My computer had been asleep for several hours. I woke up the machine, and DS was minimized. When I un-minimized it, the display in the viewport was messed up. It showed what looked like a miniature partial screen shot of my desktop, showing a portion of the Daz Studio view port. I could only partially get control of Daz Studio, so I attempted to close it, and it crashed.
Other non-Daz windows had the same odd behavior when restoring after being minimized, but they all recovered instantly from it, and re-painted their windows properly.
I may have just installed the NVIDIA 595.79 driver, but not rebooted yet. I have seen this situation occasionally with Windows in the past. I normally don't do this with Daz Studio open, but I think I forgot about it, and had just gotten an Nvidia alert and decided to install it without thinking.
I had been doing repeated iterations of posing a figure, simulating the scene, then rendering. The scene is tiny: 1 figure, about 20 cameras, 4 emissive surfaces which serve as physics-based lights.
Crash #2
I booted my computer with a cold-start (equivalent to a Windows restart), did some stuff, then launched Daz Studio 6.25.2026.6423. It crashed. I waited about 10 seconds, then launched it again, and every was "fine".
Attached is the log file. It shows the log from the beginning of the first start to the beginning of the second start. The time difference between the last log message and the restart is the amount of time I waited plus however long it took Daz Studio to crash.
When you had crash #2, was there a crash dialog, or did it crash without displaying any dialogs? Can you remember what the dialog stated, if there was one?
Yes, there was a crash dialog. I think it said the same thing as every other crash dialog I've ever seen: Something about an address error. The main DS window never showed up. Not sure if the splash screen was still there or not - - I don't remember seeing it after the crash. It was there before the crash. Everything was normal until the crash occurred.
Which DrawStyle was in use?
Texture Shaded
I encountered a very strange bug/glitch in the Beta. I used the rotate tool on my camera and the entire scene sort of reverted to where it had been a few minutes earlier. The environmental asset cameras I had deleted were suddenly undeleted. One of the cameras I set up was deleted while the other was rotated. The hair asset I had previously deleted was back, render settings were all undone.
I've attached my log file if the programming team is interested. The bug happens towards the end about 11:13 or 11:14 a.m.
Sounds like something triggered redos from the undo stack
Picked up another bug in the Beta where I cannot use the translation/rotation tools to move anything except the environmental base. Character, lights, planes, cameras--the only way to move them is through the parameters tab. The scene works fine in 4.24.
// DAZ Studio version 6.25.2026.6423 filetype DAZ Script
// Before running this code, make sure the Content Library Pane is visible, with at least one asset selected:
var oPaneMgr = MainWindow.getPaneMgr();
var oContentLibPane = oPaneMgr.findPane("DzContentLibraryPane");
var aSelAssets = oContentLibPane.getSelectedAssets();
var oAsset, oFile;
for (var i = 0; i < aSelAssets.length; i++) {
oAsset = aSelAssets[i];
oFile = oAsset.getAsLocalFile();
}
// End-of-code
Hi,
In the above snippet, I'm getting the following warning in the Script IDE:
file:///C:/Scripts/Issue/Sample.dsa:17: Calling C++ methods with 'this' objects different from the one they were retrieved from is broken, due to historical reasons. The original object is used as 'this' object. You can allow the given 'this' object to be used by setting 'pragma NativeMethodBehavior: AcceptThisObject'
The warning occurs inside the for loop. I have no idea what the warning means.
My only guess is scoping, that some variable is or isnt defined in the loop scope and is changed, are you using var or let ?
As the snippets states I'm using var. If something was out of scope I'd get an undefined error surely. The warning is printed everytime 'oAsset' is accessed.