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
As I have said before, If they don't it isn't because they are not interested in updating. I just expect that there would be WAY more negative responses to adding pbr to 3dl than positive reactions. And if your unaware of how negative the 3dl users have been about PBR then your really not paying attention to these forums. They have repeatedly said that they do not want realism. You may think that PBR for 3dl would be great but I suspect you would have a hard time finding even a dozen people on these forums who would express that with you.
This hasn't been my experience. Especially for complex scenes Iray is many times slower for me. 3delight and yes the light is good.
Just to be a bit pedantic: Physically Correct Lighting/Plausible Shading is not the same as PBR. Both methods are still 'biased' as opposed to 'unbiased' but use a plethora of steps to speed the rendering. Ray Caching, Path Buffering, Path Tracing, and other methods can keep the calculations way down. The downsides are the expense of static resources. Where PBR throws massive processing at the problem, these methods throw massive memory/cache at the problem.
Let's be realistic, the new features aren't going to operate in 32bit space efficiently (if at all) and will require 64bit level resources. BUT... either you use massive amounts of VRAM or massive amounts of DRAM. Somewhere, the resources get consumed. Again, it falls back on the limitations of the OS.
Kendall
I am not in a position to know, nor have I asked, but it looks to me that DAZ's in-house RenderMan resources are probably severely lacking. I've not seen anything in quite some time to make me believe that their RenderMan person(s) is/are still around. Supporting 3DL from the DLL standpoint is fairly straight forward and one can nominally use the new(er) libraries with the older code with little effort. However, writing new bricks and supporting new features within the engine may be outside of the resources available. We must remember that DAZ's resources are finite and personnel must be allocated where the "most good" will happen.
This is why I wondered if DAZ is going to rely on PAs to expose the new features. For sure, there will be some inherent speed increases from internal DLL routines calling newer, more efficient, DLL routines. How much of a performance increase we'll see is a question mark, especially when we already take a performance hit simply from using the DLL in the first place.
In all fairness... Autodesk didn't add the new features to the Maya plugin, DNAr did. Also, the plugin for Maya isn't free beyond the limitations in the standalone, where DAZ is providing a fully exposed engine for no cost to the user.
Kendall
Why do people assume the reason someone doesn't use Iray is because their computer can't handle it or their gxf card is lacking. Neither is the case for me. Simply put ... I prefer 3DL and 4.7 for my needs.
Sooo ... Back to my question ... lol ... Has anyone tested the new Old Garden set in 3DL? I just want to know how it looks.
Mostly because the majority of those responding are referencing that very reason. It is true that I also use 3DL for most of my work, and I have no dearth of hardware resources. However, I also use Iray where it is appropriate without hesitation. I have absolutely no qualms about resurfacing things as the needs arise, including taking the item into Substance Painter and redoing it completely if I don't have something appropriate already. In fact, I rarely leave surfaces as the creator shipped them. In most cases, the PA's selection of materials is completely wrong for my needs so I have to manipulate them anyway. In most cases, I don't even use complete items most of the time unless the item is simply a blouse, a pair of pants, or a singular prop. Environments are a guaranteed "not use most things" since I buy them because they "mostly" fit my needs and keep me from having to do it myself. More often than not the first thing that happens is that the item(s) are either exported to Hexagon for modification or is taken into the PGE to have pieces removed.
It's looking like no one reading this thread has tried it in 3DL. I do not have this item since it is outside of the composition needs that I have. Going by what I'm seeing in the unshaded promo, I don't see anything that couldn't be fairly easily manipulated surface wise. Everything *looks* to be geometry as opposed to transmapped, but I cannot get a close enough look at the vegetation to tell if the leaves and petals are real or planes.
I cannot tell what method was used for any wood grain, or other displaced/bump-mapped/normal-mapped surfaces that have texture. However, it shouldn't be too hard to apply generic textures to the surfaces.
Kendall
Thanks, Ken :D
...which is what I have been saying all along as well, especially when it comes to interior scenes.
...so where does one find this script?
Ask her via PM.
OK, here's a very quick test just using DS 4.7. Don't know if this still ships with the 4.8 or 4.9.
Default DS render options
3 minutes 46.49 seconds
Default DS render options with progressive rendering enabled.
3 minutes 1.10 seconds
Fast but noisy.
Default DS render options with progressive rendering enabled using UE2. IDL strength is 200%, occlusion samples 128, shading rate is default, max error is 0.0010, max trace distance is 500.
8 minutes 46.67 seconds
And last, the same scene with raycaching enabled via kettu's script. Used the Raytracer General option, but changed the bucket size to 16, since that is what's used in the other renders.
2 minutes 29.13 seconds
Those with iray should be able to do comparison pretty easily. Just load the scene, set your render settings and render.
Yes, the DNA people did an amazing job with integration in Softimage, Maya and Max. I don't use Katana and it's not even out yet so I don't know about that.
Unlike iray, 3delight support both NPR and physically plausible rendering. Those who don't want realism can continue using 3delight and the existing shaders/libraries. Those who want to use physically plausible shading can also use the same renderer, just with a different shader. Just call it something else than DAZ Default - DAZ Default PBR or something. Houdini devs took that approach with Mantra. Probably the only other renderer I know that support REYES, ray tracing, and PBR rendering in one renderer (since Pixar has dropped REYES and RSL altogether with RIS 21).
Her kit has no DLL whatsoever. It's all just shader code and scripts. All the power is already in the renderer built into DAZ Studio, it's just been untapped all this time.
All the script does is insert one line into the .RIB to enable ray caching (along with the usual render options parameters). C4D users with 3delight also had to resort to RIB editing to get that.
She basically wrote a few shaders (general dielectric, metal, glass, hair), an area light shader, updated point/spot/distant light and even managed to get a photon mapping kit to get caustics. Here's a thought - someone in DAZ should get in touch with her. Or maybe group of PAs still interested in 3delight.
One thing to consider; most of the 3Delight shaders and light sets we are discussing had to be done the way they were simply because at the time they were created most computers did not have the ability to access 4 GB of RAM which is the limit of a 32 bit program. And until 32 bit computers and software go the way of the dodo, it wouldn't be practical to upgrade the light sets to support it unless you creates an entirely separate version for 64 bit.
The DLL I'm talking about is the 3DL one than DAZ calls from DS to start the rendering process. The options that are used to start/control the DLL severely limit the performance.
Kendall
Iray already requires 64 bit to run, the 32 bit DS does indeed still only use 3DL. The question is whether DAZ still has the personnel to modify the shaders and such to take advantage of the new features. Renderman programming skills are fairly rare and tend to be expensive to obtain.
Kendall
@WillowRaven - Loaded in the Full Scene. Switched render engine from Iray to 3Delight. Hit render. :)
Thanks, Digital Lite Design. Were any lights used or are these the default lights?
It loads with a distant light. :)
Thanks :D
...however, Iray being newer, wouldn't finding skilled developers for it (outside of Nvidia) be even more difficult?
The other issue is, how many people are realistically doing this on 32 bit systems that only allow 2 GB (3 if set to Large Address Aware) of memory to be allocated fo any single application. I couldn't use UE in 32 bit without the process crashing (which is why I never bought into the Uber shader and light expansions). Crikey, even without UE, using say a Stonemason set and a couple characters often resulted in a crash.
...if you have the AOA Advanced lights, I'd try the Ambient with the AoA Distant light.
I was until recently, believe it or not. Have to build a new PC to replace the antique I was using (I had it maxed out with 2 GB RAM on the motherboard).
....I had 4 and still experienced frequent crashes.
Well, I experinced crashes too, for that matter. The point that I was making, and that got misplaced somewhere, is that back when omnifreaker did the UberEnvironment lights, we didn't have a 64 bit DAZ Studio yet, so we would have been slowing or renders even more if cachin had been enabled.
RiSpec programming and RSL in particular are VERY rare skills. Those who have the skills (and are willing to move to Cali) can demand substantial payment. There are those of us who know the languages and do the occasional contract work, but many of us are getting older, not friendly to relocation (EDIT: removed due to disturbing misinterpretation of original content), and not fans of having our hard written RSL code "claimed" by the clients as "work for hire" and "exclusive" to them. This is why you don't see much RiSpec and RSL in the open, the clients pay a lot for the work put in to get the "look" and keep it for themselves. Even when one does come in with documentation that one has "tools" that exist before starting to work for them, many times the contracts have clauses that keep people from taking positions creating similar RiSpec/RSL for periods of time afterward. -- Yes, I am bitter about it.
Iray, being newer and OSL compatible, has the attention of the younger crowd and has many more GUI based utilities. I've found that lately the "young pups" are not patient enough (on the whole) to sit and program in the traditional way. Even at the Engineering Schools the Faculty bemoan the lack of perseverance in modern students, the Liberal Arts University Faculties are beside themselves at the calibre of "Computer Science" students in their classes.
Kendall
...so how does one acquire those skills? Or is RSL/RiSpec kept as some deep dark secret you have to pay 1,000$s to learn?
I totally agree with the state of programming today. Nobody appears to care about documenting anything, and stuff seems slapped together just to work for the "time being". Too much spaghetti and not enough style anymore.
Yeah, I know other people who did contract work, and I agree with you on it as well.
Make a deal with the Dark Side...
Mostly by doing. RiSpec docs are readily available. As with any programming language, there are levels to pricing depending on what you are trying to do -- from free to very expensive. Always keep in mind that there are 2 sides to RenderMan -- the RiSpec side which is standardized and is supposed to give very similar results on any RiSpec Compliant Render Engine. "Similar" is used because a lot of RiSpec includes the use of random and noise. By definition, these introduce variance. And then there's the Engine Specific extensions that are outside the spec that no one else has, or that other's have that is "kinda sorta" like it. Once you enter into the extensions, you are forever in "one camp, or the other".
DS has some very interesting features for playing with RSL and RiSpec and seeing the results pretty much immediately, though a lot of it is also limited. The other way is to grab your favorite text editor/IDE, start writing code and feeding it to an engine to see what happens.
If you create a very small reference scene and output a RIB, you'll get an idea of how massively large the code can become. Due to the nature of the beast, RIBs with many millions of lines of code are not uncommon. Make sure that your Text Editor is not 32 bit. Notepad++ is notorious for not being able to handle RIB files well.
Kendall
When I programmerer the only really rare skill amongst programmers was those programmers that actually made a concerted effort to test their code thoroughly enough. Anything else was learnable on an as-needed basis.
You've never played with AI/Expert Systems languages, have you?
There are many programming languages that do not use the same skills as programming in C, C++, BASIC, or Pascal. OPS5, Lisp, Forth, Prolog, and others. There are languages that look a lot like XML/JSON but without the objects. There are strict sequential languages that have few methods for jumps, and no subroutines at all (sorta like writing everything in inline assy). There are languages where almost nothing is sequential. There are even languages that change/morph as you program them (Forth is one of these).
Many of these take years of training to learn before one can competantly write anything of value in them. Many of them you may never get the chance to program UNLESS you've had specific training in the first place.
EDIT: RIB is a lot like a description file that happens to contain code. There are a lot of global variables (with really stupid single letter names) that have very specific meanings in one context, while having a completely different meaning in another context, yet the two are mere lines apart.
I remember when I was younger, a much more experienced programmer once opined the following: "The only language every programmer understands is Profanity."
Kendall
...I totally agree with that last quote.