AMD FireRender/ProRender
mtl1
Posts: 1,508
in The Commons
For those of you that watched AMD's presentation at SIGGRAPH, AMD just renamed FireRender as ProRender and placed it within their open-source GPU renderer initiatives. It's OpenCL and plays well with other programs.
Since DS already supports things like Lux and Octane, I wonder if it's possible to develop a plugin for ProRender... hmm.
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
vray!
renderman!
While it would be great to have a Renderman ( PRman) plugin for DS now that it's free for non commercial use, I fear it would have the same issues as 3delight. The complexity of Renderman is well beyond what that average DS user is willing to learn. Plus the new internal shader definition "languge" uses c/c++ calls/syntax may make the transition even more difficult.
Personally, I would love to have a Renderman plugin. I just don't think it will ever happen (hope I'm wrong).
A Vray plugin would be nice, but Vray isn't cheap, so it would have the same issues that the Octane plugin now has ..... why buy it when we have Iray and 3Delight for free ( yes, there are many good reasons, but that seems to be the prevailing mindset).
the complexities of LuxRender were arguably out of the comfort zone of most DS users but Studio users still have two offerings that bridge that gap.
A Renderman "interface" for DS is still very much a possibltiy and I would love to have it too.
RIB files will render in Pixar's Renderman with only a little tweaking as long as you don't try to use compiled shaders.
Kendall
Vray seconded! it would be a really great renderer to see in Studio - and there are tons of free Vray shader/materials available
Whew, looks like iRay & nVidia have open source competition. This make AMD CPUs and GPUs much more interesting, more likely to be adapted into DirectX 12, Metal, and Vulkan, and as open source it is liable to be adapted into other open source SW, such as Blender.
Technically, it shouldn't be too hard to port over 3de and iray mats over to Prorender/Radeon Rays, if my presumption of it being a PBR render is correct.
The article I read about the ProRender engine is that it is PBR based as well. And with the ProRender's ability to do openCL, DirectX 12, Metal, and Vulkan and choose between CPU, GPU, CPU+GPU renders and it being opensource; DAZ Studio should have excellent support for PBR renders for all the major graphics library hardware and software varients - to say nothing of other SW like Unity, Poser, Carrara, and Blender.
It looks like the source code for ProRender won't be made available until September. Unless someone gets early access, I don't think programmers will be able to say how easy or hard it would be to make into a DAZ plugin or bridge before the code is released.
I'm not particularly worried about that part as it will be easier than the iRay SDK.
DAZ models port over to Unity/UE4 PBR renderers pretty well using FBX, no? Or do the shaders/materials still need significant adjustments?
Well I've only used a few old 3DU Poser style models in Unity with PBR so far but the PBR does work well, even for those old Poser characters and Unity is improving it all the time. However, PBR is a bigger hit on a game engine that you don't want on mobile, at least not for a 2 or 3 more interations of mobile SW & HW. It'll get there though.
..for me it wasn't the complexities of Lux, it was the instabilities of the Reality4 plugin and glacial render time as my old CPU doesn't support the routines that allow for the speed boost. Iray is already painfully slow, but no where near so as Reality/Lux.
I too have the full Renderman, but yes, it is very daunting to use. A Daz RIB interface would be most welcome.
The problem with using RIB to export to Pixars Renderman is that RIB only supports a fraction of the available options/capabilities of Renderman. So if you want to go beyond the basics, you'll need a means to edit the RIB file to take advantage of the full suite of features available.
...so you are saying we need a full plugin like Reality for Lux.
No. DS doesn't even support all of the features in 3DL, therefore the RIB output from DS is a subset of that featureset. Since DS knows NOTHING about Pixar's Renderman it cannot add anything for it to RIB that is beyond what it knows for 3DL.
DustRider's statement is worded incorrectly: RIB supports ALL of Renderman's features, but has only those features capable of being written to it by the UI that created the RIB file.
EDIT: RIB files are a type of programming language. Far more can be done within them than any UI will be able to generate. Programming RIB is a *very* high paying occupation.
In order to support Pixar's Renderman implementation with any level of usefulness, one would need a plugin FAR more complex than Reality or Lux. Those two are primarily materials/surfaces conversion plugins. Neither adds access any of the special features of LuxRender.
EDIT2: Also, few of the commercial shaders will be of any use for a PRMan plugin. Any of them that are pre-compiled for 3DL, or that use 3DL specific (non-RiSpec) nodes will not compile or work for PRMan, and vice versa. Both 3DL and PRMan extend RenderMan with custom features beyond the RiSpec standard.
Kendall
...what about a plugin more on the line of the one for Octane?
OcDS is extremely complex and very much specific to Octane. What it will take is someone dedicating the time to work out communications between DS and the Engine.
Kendall
Hmm. All this talk reminds me of something: gpuOcelot was originally set up as a way to emulate CUDA GPGPU devices in Linux to test GPGPU code. Given that OpenCL is, well, open, I wonder how easy it would be to emulate a CUDA device using a wrapper of some sort.
Otoy is working on exactly this, just for their engine. Considering that gpuOcelot is OSS, go ahead and take a bash at it. It'd be interesting to see what you can come up with. (Not meant sarcastically, I really am interested to see. I don't have time for anything else ATM.)
Kendall
Bahaha, I don't have time either :) I head back to work on the 24th and I'm working on other projects in the time being.
Having said that, gpuOcelot only supports an older version of CUDA, but it shouldn't be *that* hard to translate the newer function calls...