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
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
That's fair. Yeah, I think the best we can hope for is that the UI and possibly previews are sped up. I would imagine that Filament will use Metal too, so Filament renders and animations should be great, though Nvidia renders most likely be no faster (though if it's also Apple Silicon-native I think we can rightly expect a 10-15% speed up there, too, just from by-passing Rosetta 2).
Still, it's probaby years away. so who knows what will be happening by then?
No, also no word on when it *might* be coming nor what the features might be when it does arrive nor, it appears, if it will even still be called "DAZ Studio 5".
No longer seem to be allowing more BETA testers. Tried without success.
Nah, we are ways away from it still, probably years still. At this point we'd need something flashy to celebrate it!
The pressure for them to make it happen soon is increasing. For one thing, it looks like it won't be possible to make the newest generation of Nvidia cards compatible with iRay without making changes on a new-major-version level.
So what does That bode For Iray, at least the GPU rendering version (As distinct from the Apple CPU rendering version)? Is this gloomy News for Nvidia Iray Enthusiasts?
On Macs? There is no GPU rendering, and hasn't been for some time.
If a new generation of Nvidia cards breaks DAZ Studio's iRay implementaton, I have no doubt DAZ will move fairly quicklly to fix it, either with newer drivers and DAZ Studio code or -- if we're lucky -- a new version that will fix it and give Mac users an actual upgrade. Their main customers are iRay users, I don't see them leaving them in the lurch for any length of time.
Sad state of affairs indeed - this thread started on July 7th, 2021 and there is still not even a hint at when we can expect to be able to use current tech in Daz Studio...
but all currant plugins may well not work
And what of the latest release version that's mentioned in the community blog? How well is that working on the Macintosh platform?
Maybe the button's broken? Although it was a year ago I posted this (and the page had been around a while before that). Interestingly, the page has been updated with new information and an Unreal experiment, so it looks like it's still being developed. I, for one, can't wait to try it out. Hopefully we begin to see invites soon.
Forgive me if you're joking, but if you're not... how long will it take before all the current plug-ins are working? Tomorrow? Next week? Next month? Next year? I believe the correct answer is "never". All of the current plug-ins will never work. If I'm not mistaken, some older already don't work in *this* and never will.
It was stated that when the next big version of DAZ Studio (or whatever it or "they" might be called, assuming two versions with slightly different names) that we'd still be able to keep and use a version of DAZ Studio 4.
They had a bare-bones version of the next, big DAZ Studio working three-and-a-half years ago, and Filament worked on the Mac then. The original plan was to release a stable version with more functions roughly three years ago and that over the course of the first year of release to bring it up to speed to full functionality.
They thought they could take it from the bare bones version to the full-featured version in a year-and-a-half, so really, they've had an extra two years to really polish it up and make it shine.
If they are truly not going to release it until all the plug-ins and scripts will work, well, that'll never happen.
With every minor tweak they make to DAZ Studio, something breaks for somebody. A week doesn't go by without someone having issues with crashing with the latest version, with scripts, with plug-ins, and Nvidia driver incompatibilities. Every. Week. That's not going away.
Moreover, it's crashing with *new* scripts and *new* plug-ins, so it's hard to tell if things are moving forward or backward.
Yes, some plug-ins and scripts will not work. but eventually, if they're really planning on releasing a Qt 6 version, I would think the best move would be to release it and let those of us willing to work through the kinks do so and those who want the "stability" of the current version stay with this version until they're comfortable with the newer version. We should be able to use both versions for until we're happy with the newer, bigger version.
Any major release is going to have launch problems, this major update will too. I originally applauded the DAZ team taking their time to "get it right", but in the meantime they continue to add features that we're told will work just as well in the new version and that as issues pop up in the current version and they're fixed, that they're also being fixed in the new version. I'm starting to worry that as both versions grow in complexity, there'll be more, not less issues when the new version is suddenly running on tens of thousands of different hardware and software system combinations they haven't tested it with.
On the plus side, I've saved thousands of dollars by not buying new content once the delay of the DAZ Studio 5 release was announced.
The next major version of Daz Studio will fail to load all current plug-ins (binary, platform/architecture-specific add-ons supplied as .dll/.dylib files) and will fail to run at least some scripts. The Daz own-brand plug-ins will of course be updated, at least where possible, but what PAs do (if they are still alive and active) will be up to them. This is an unavoidable outcome of changing the Qt version (and of course Daz may add other application changes on top, to support new features etc., though we have no information about that).
Remember that the annoucement about the new version was made by a non-developer, and was motivated by the need to roll out some kind of M# support - in the end they found a different solution there, and have been adding "next version" features to DS 4.20+ since then (while also, as I understand it, incorporating those and other things in the next version development) so it isn't really true to imply that the process itself is taking longer, rather the route has been changed.
It would seem that the need to support 50x0 cards may well be like the need to support M# chips - an impetus to make the next version releasable, hopefully in a rather less bare-bones state than seemed likely earlier, but Daz is not going to specify a date precisely because of the way the previous comments have come back to haunt them.
This is and will be true. Technology is a treadmill. Software changes over time and plugins must be maintained. In some cases, the people who made the plugins are no longer here (in the community or even in the world). In other cases, it simply does not make financial sense to stay on the treadmill. So, core software continues to work and some plugins fall by the way side. I do believe the bulk of plugins will need adaptation to work on the new platform, whenever it finally arrives. I doubt updated plugins will be free - It will take a lot of work and likely functionality will change. It is the way of things!
I am not even going to speculate on the arrival date for DS5 except to say it'll be Daz soon, with all that implies.
I think you can email that to the Qt devs, see what they say. It is their doing for not ensuring backwards compatibility and breaking everything in the new versions.If they had done as you say, perhaps none of this would have happened.
Plug-ins, unlike scripts, call on functions by their location in the application - so anything that changes that (the API, if I have my initialism correct) wil cause the plug-in to fail (at best). Daz has been very careful to keep the API constant through DS 4 since the betas (and before that through DS 3, and through the latter stages of DS 2) but a major chnage, like a new Qt framework and new application features, will break that. To some extent all that may be required may be a recompile against the new SDK/API, but if Daz wants to add or expand features (and prsumably we want them to do so) then some rewriting or refactoring may be required (see, for example, the way the the figure/skeleton class changed between DS 3 and DS 4 in order to add full weightmapping).
Yikes, this sounds like even after three and a half years, we're not closer to having third party plug-ins and sciprts updated at all. No reason to halt the rollout for that, I guess, since the 3rd party devs might not want to waste time supporting it until it's rolled out.
It wasn't about M# support as much as it was the version of the Mac OS; Intel machines with newer operating systems also didn't work. The only part of the announcement directly Apple Silicon related was that DAZ was going to ˆ to have a natvie version at some point. Still, the announcement wasn't made by a random guy on the street, either. I have to assume that he must have asked the developers about *some* guideline to use before posting. I highly doubt the developers had no idea what he was going to say until someone told him what was posted.
If, after three and a half years they're still at the "bare bones" state, then they have much bigger problems. DAZ Studio already supports M# chips via Rosetta 2, not ideal, but it's not impossible that they'll release an updated Qt version to support new Nvidia cards and *still* not be Apple Silicon native. Mac users are the minority.
I appreciate your effort, Richard, to try to keep things in perspective. I'm sorry that you that you have to deal with people like me, and I'm sure it's almost as frustrating for you than it is for me.
Take your time, DAZ, as much as you need, and get it as right as you can; I'll keep saving thousands a year until you're ready to release.
It might be nice, though, if we had *some* hint of what's coming when, though, but then... we'd probablly be back here in a few years whining about still waiting...
Totally understandable, but how do we deal with it? They've gone from a working, bare-bones application in three and a half years to what? It sounds like the difficulties of 2021 are still there. It doesn't sound like they have any solution to dealing with the broken plug-ins and scripts by third party developers any different than they did four years ago; if they keep doing what they're doing how much further along will we be in another three or four years? The plug-ins and scripts aren't going to fix themselves.
It doesn't mean backward compatibility is free and at one point, keeping it start to be more costly than ditching it and taking advantage of all the improvments made since the oldest backward compatibility version was shipped.
Using an example with an object oriented language, Python 3 voluntary broke backward compatibility with Python 2 because the Python dev team felt the benefits of doing it outweighted the cost of breaking backward compatibility / the cost of keeping it.
This is an interesting turn of events. DS 4.x will be kept available for everyone to use after the release of DS 5 (or whatever it might be). But ..... any 50xx or later cards won't be able to ever be used to render with Iray in DS 4.x, making it's useful shelf life limited. Additionally, it would appear that anyone who has plugins or scripts that they depend on heavily in DS 4.x, they may or may not be available at some point in next version of DS. So lets say you rely heavily on a script or plugin that you really need to see the results in Iray, then moving on to a 50xx card would in reality make that script/plugin virtually no longer usable in DS 5 (or whatever it will be called), unless of course it is a DAZ owned product (that will hopefully be available for the new version of DS). At least that seems to be a logical conclusion given what I know at this point. Of course I could be totally wrong, given we really don't know anything other than the 50xx cards will not ever work with Iray in DS 4.x, and some unknown number of scripts will no longer work, and no plugins will work (unless the developer decides to make them work)
Of course the big question is will the new version of DS have the ability to save files for use in DS 4.x? If not, it would seem that using the existing scripts/plugins to "bake" features into figures/scenes for use in DS 5 using DS 4.x could be a little less functional? I my own experience, I seldom know everything I will use in a scene, or all the plugins/scripts I might use until it's done. It's still a possibility to bake things into a scene using DS 4.x, but I often don't know I will need to use scene optimizer until I need it. The are work arounds, but none are ideal.
I can truly appreciate the benefits DS 4 has been receiving lately as a result of the next generation of DS development efforts. That likely means that DS 4 will be as modernized as it can get, while New DS carries on adding improvements not otherwise possible with the old Qt development software.
As a Mac owner, I am still quite upset that New DS hasn't made an appearance with things like Filament, Apple Silicon native support, UI fixes, GPU support (both Mac AND Windows) and performance/stability fixes. No New DS beta yet? Three and a half years down the road? A few months ago I pulled the plug on DAZ purchases and removed gallery and forum posts. This was immediately after a comment was directed at me for not being patient enough. It was a sit down and shut up response from someone who doesn't use a Mac. I suppose they weren't impacted and so were unable to understand why 3 years of waiting for basic compatibility was a long time (for us Mac users.)
That said...
It makes me wonder what project management tool/methodology is being used. If any at all. That would give DAZ management/developers an idea of when and what portions will be complete and ready for public release.
How far away are they from getting the core framework working with minimal useful capabilities for customers? Then what would be the timeline for getting the other plug-ins working? Those could roll out steadily over time. How many plug-ins are being written today that will not work with New DS? That's just compounding the existing problem.
Adoption of newer technology by the customers is moving faster than DAZ can keep up with. That's a shame.
Apple is currently on it's 4th generation of processors since the announcement of DS5 and is reported to be rolling out their 5th gen Apple Silicon Macs later this year. None of these Macs can natively run DS with performance and stability expected by consumers.
Just give up on Mac users, take the revenue hit, lay off a few employees, and focus on the customers you truly care about. It's not the Mac folks apparently.
Or prove me wrong. Show us something great. Soon.
Lee
You are way "above" the problem at the source level. Research what an "Application Binary Interface" is.
In summary, it's the rules on how different binary things, executables and libraries talk to each other. How they pass parameters, handle exceptions, everything. At the crux of it, if DAZ Studio is forced to upgrade the compiler it is built with, with an updated ABI, the old plugins using the old ABI will simply not load at runtime because the ABIs don't match. Full stop. None of the (all true) things you've stated are relevant.
The remedy is to recompile the plugins from source with a compiler with the same ABI as DAZ Studio's. But as Mr. Haseltine and others have pointed out, this will not be possible in all cases. There is simply no way around this.
ABIs do not change with every new version of a compiler, but they do change, in order to support new language features. C++ keeps evolving into a safer, more expressive language, and that is good, but the consequence is that they sometimes have to break backward binary compatibility.
A stable API is necessary but not sufficient. For the LoadLibrary call to succeed, the ABI has to be the same as well.
You keep the API the same by having the same C++ include files that describe the interfaces. That's why DAZ can't update the SDK.
But the same headers compiled with a different compiler can produce binaries with differing ABIs. It's the ABI that determines things like how to call a function, i.e. when to push parameters onto the stack and in what order, how to get the return value, i.e. on the stack or in a register, etc... all very low level things that are not determined by the API described in the header files. It's a function of the compiler.
The ABI does not change all that often, but it does change. And this is what happens when it does: Everyone has to recompile. There is no way around it.
I would expect Daz no to release an unfinished version to developers, and the PAs may be wary of counting it finished until any public build has had some testing to make sure there aren't any ABI (apologies for the wrong initialism earlier) breaking issues that need fixing. But I am not privy to any details. (Even if I did know more I would need permission to share, and probably wouldn't be the person chosen to do the sharing.)
Thanks for the correction, I had a vague feeling it might have been just the OS version rather than the chips but I didn't check. The announcer wasn't a developer, I wasn't privy to any discussions involved and again wouldn't be allowed to discuss them if I was.
Where did I say that? Again, I haven't seen the next major version, or read its specifications, but that doesn't mean it isn't far more developed than whatever was referred to in the first post here.