Any chance of DAZ supporting AMD or Intel cards for rendering?
lipluck81
Posts: 30
Any chance of DAZ supporting AMD or Intel cards for rendering? NVIDIA's business practices have been questionable in the past few years, and I'm reluctant to buy their products.
(And no, I'm not going to program it myself using AMD or Intel's rendering SDK's, then program it into DAZ, lol.)
Post edited by lipluck81 on
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
Simple answer, no. Daz Studio uses the NVIDIA iRay render engine, AMD and Intel do not support this. You can always render using CPU. on PC I use RTX 3080TI, on Macbook I use i9 CPU for rendering. sucks but it is what it is.
well Filament is supported
iray is a Nvidia render engine
As Richard Haseltine has pointed out numerous times, nothing is stopping anyone from implementing AMD ProRender into DS, least of all AMD themselves. Iray is made by NVidia, is only supported by NVidia GPUs, and presumably was integrated into DS with NVidia's help. I don't know of any rendering engines that support Intel GPUs, but admittedly I haven't looked into it.
Filament uses my integrated Intel graphics on one of my computers (confirmed by GPU-Z)
it uses BOTH my Nividia card AND my AMD Vega graphics on my other one (and looks considerably better as a result, no blocky shadows )
And every time he does, a little part of me dies inside. Opinions on software development from people who are not software developers should be taken with a grain of salt, if not the entire shaker. Integrating a render engine would be a challenge even with good SDK documentation, to say nothing of the state of the documentation that we actually have. The statement is true only in the same sense that nothing is stopping me from building a fusion reactor in my living room, either.
But one can indeed render in IRay using the the CPU's floating point coprocessors, can't one? It'll be 10x slower, but one can, right? Or has this changed?
A plugin of any kind is just a matter of coding, while a fusion reactor requires physical resources that are intended to be impossible for a random person to acquire. In other words, national and international laws stop you from building a fusion reactor in your living room, not to mention the logistics of getting enough water to cool it, etc.
Also, Reality was created by a user integrating another render engine into DS, so it's not unprecedented. I'm nowhere near the programmer you are, but I sympathize with your frustration over the poor documentation. I'm not saying it would be easy, just pointing out that it CAN be done, because it HAS been done.
If you're actually asking: yes, you can render IRay on CPU.
There are some SDKs (Software Development Kits) for AMD Radeon graphics cards like OpenCL and Vulkan.
If you like to use AMD graphics card switch to Unity. Daz Studio has free bridge for it.
Rendering in Unity is in instant (real time mostly) but it is not so easy to get the same results like in iRay.
https://docs.unity3d.com/Packages/[email protected]/manual//raytracing-requirements.html
https://docs.unity3d.com/6000.2/Documentation/Manual/system-requirements.html
Even if someone could provide another render engine for Studio ( Octane alredy exists ) the shaders designed for Iray won't be directly useable for another renderer, so it would only be useable with a lot of user adjustment of materials.
You can also use Blender - it supports AMD and Intel graphics cards:
https://www.blender.org/download/requirements/
There are free Daz Studio to Blender bridges and the commercial one.
While great for previews, Filament is hardly a replacement for propper rendering.
So, I really don't understand, why Filament is even worth mentioning.
BTW
Implementing IRAY has been a mistake, pushing DAZ Studio into a corner, stripping users off choices.
We are limited to Iray and limited to Nvidea.
and those Nvidea GPUs are very expensive.
@Gordig
A part of me just died inside.
OK, I'll try again because writing that is so dismissive of what people who give us plugins actually went through to create them, and nothing could be farther from the truth. The fact that it has been done is not the best metric and it is the go-to justification I keep hearing. Yes, it has been done. But it required a dev of more skill and experience than it would have if DAZ made it easier. All this means that we will have less cool stuff to use because fewer people are able to participate in writing plugins.
Because the DS SDK documentation is largely insufficient, it isn't "just a matter of coding". The canonical first programming problems of implementing the Sieve of Eratosthenes or the Fibonacci Series are "just a matter of coding". When the task depends on interaction with a large, complicated API in a language like C++ which is not self documenting and has no introspection facilities, figuring out how to do basic things ranges from easy to very, very difficult. It might be imagined that DS is as large and complicated a context as the thing that it excels at. I don't
Compounding that is the fact that not everything you see in DS's GUI is even in the public header files, so you end up searching through tens of megabytes of JSON looking for clues on how things work. That's what I had to do a long time ago to figure out how material assignment worked, or just recently to figure out where the G9's fiber eyebrow topology is stored; the vertex data was there, but how they sare divided up into strands was a mystery (spoiler alert: It's not in the C++ SDK at all). Or how to find hidden material/ vertex groups for geoshells. I can go on and on.
Writing an addon for DAZ Studio is not "just a matter of coding", it's difficult and frustrating sequence of figuring out things that should have been documented. If you think I'm just making things up instead of trying to highlight legitimate concerns, go to the SDK forums and count the number of unanswered technical questions where some enterprising geek was going to make a go at adding something cool, but couldn't get an answer to a basic question.
If the documentation were better, DAZ Studio would be better.
there's always generative Ai
I have been using it with rendered start and end frames with Wan2.2 and LTX
its probably not impossible to icreate a bridge, plugin or something to do it in Studio itself
Blender has Ai plugins
one could do poses along the timeline and generate the animation ibetween
yeah you do need a Nvidia card though
Two things. What TheMysteryIsThePoint said contains absolutely zero exaggeration. I've considered making a plugin because I want something to be in a panel, not in a modal dialog. Nope. Not gonna try. Just programming a script can be a balding via pulling one's own hair out experience.
And second, yes, Daz Studio would be better if there were better documentation.
That isn't the kind of statement I would make without verification with someone who is a software developer.
Yet people have produced functioning plug-ins, with a bit of iterating, by feeding the documentation and samples to ChatGPT or Gemini.
Do bear in mind that this is the DS 4.5 SDK - a lowest common denominator. It is possible to use later objects via the QObject (I think) approach which has been discussed in various threads, because the scripting functions are updated with DS (largely) since they are interpreted.
Well, some people aren't fixated on photorealism, and therefore aren't "limited" to iRay and Nvidia. Some people find toon renders and animations to be propper [sic] rendering and even prefer it to iRay. People were doing incredible 3D renders years before iRay was created and have continued doing them without iRay, even now.
Still, nothing stops anyone from moving their DAZ content to Blender (or Maya, or C4D, or Unreal, or Unity) and doing amazing stills and animations, without iRay. DAZ implementing iRay wasn't a "mistake" anymore than it was for any one of us to hang all our hopes and dreams on iRay. I'm not a fan of nor do I normally use Iray but I appreciate the incredible things people are doing with it here every single day, it's inspiring. Not once have I felt stripped of choices.
I'm confused. You've told me, unequivocably, that that is against the Terms of Use. So much so that I suggested we begin an external project to independently create our own documentation specifically for use with LLMs. With no real explanation, you claimed that that too was against the Terms of Use and deleted the post.
But yep, I was waiting for you and this particular response. Again, the question is not whether other people have managed to make plugins, but rather whether there is good enough documentation so that anyone who wants to help make DS better is able to do so. I've been doing nothing but C/C++ for the last almost 4 decades; if that's where the technical bar is to participate then, well, that is not how to foster a thriving development community and DS will not gain cool plugins at the rate that it could. That's all I'm saying. That shouldn't evoke such poor justifications for something as clear and industry standard as "if you have an SDK, you should support it" (or at the very least, not ignore devs who are trying to make your app better, at no cost to you). The same response, "there exists at least one plugin, so everything must be fine" is inexplicably tone deaf. Look at the SDK forums for people's pain.
Again, you've told me, unequivocably, that this is reverse engineering, and against the Terms of Use.
But neither is it the kind of statement that you would make with it. I can think of lots of things that would stop someone. That are stopping someone. Me. A developer of almost 40 years. And I'm just exporting geometry... simple, right? Well, 7 years later I'm still having to figure things out the hard way all while being told that there must be something wrong with me personally because, look over there, someone else managed to make a plugin.
You're the one who analogized writing a plugin to building a fusion reactor. I was merely pointing out why the analogy wasn't apt. It's not dismissive to state that a plugin, no matter the complexity, is just lines of code - specifically, as opposed to a physical machine that requires expensive and legally restricted components - it's a simple statement of fact. That's not to diminish the hard work, problem solving and creativity that go into them. I know, from experience, that coding isn't easy, and fully acknowledge that Daz doesn't make it any easier, and I'm not blaming you for your difficulty in accomplishing what you want to in coding for DS.
I think I may have overreacted, and apologize. Maybe its because my experience with DAZ related personnel has been so different from the way I'm treated at Blender, SideFX, or even Autodesk. Instead of saying "Yes, the documentation is insufficient, but we're working on it. But because you're working on an important tool where over 400 people have downloaded the latest version to assist in their getting the most out of their experience with our software, we can spare 5 fricking minutes to answer your simple question that you've politely tendered." what I actually get ranges from being completely ignored by some to outright hostility over a fabricated offense that makes no sense whatsoever (that has now gone totally surreal because the offenses were later offered as a solution to poor documentation, in place of... better documentation). And I don't understand why. All I've ever tried to do is to make a tool for people to use because it was a tool that I myself needed. I never kicked anyone's puppy.
Being endlessly critical of the available documentation is not asking politely, whatever words it may be wrapped in - especially when said doccumentation is not a working hours project (yes, I wish daz did allocate more offocial resources to documentation - but I am also aware that doing so will absolutely not eliminate the asking of questions that are then answered directly).
Reverse engineering isn't allowed, but the changelogs do often provide the relevant information (which is, indeed, a form of working on it) and on other occasions we have been given guidance to pass on. Using a tool like ChatGPT dos not bypass the license terms, but that doesn't absolutely prohibit its use in accordance with the terms - reverse engineering is relevant where things are not documented, or where the documentation is circumvented to try to duck the license terms.