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
I think Bree is just one of those placeholder textures they didn't pay much attention to as they knew there were other textures that we'd want to use more. Which, from my point of view, is true, I can't think of many times I've used her.
CHEERS!
The shader is fine, thank you =) It's the documentation that's taking this long. I kinda wish I were a faster writer, but I'm not. Definitely not with the load of technical writing I do for the day job...
But I was thinking... if anyone here is willing to try an "alpha" version (that is: no docs) of anything I have been bragging about here... be my guest. Just let me know what you are interested in.
And it would be best if you sent me an email (my address is the same nickname as here, but at the google mail service) or a PM at deviantArt rather than a forum PM here.
I can't say about EXR to HDR (I don't have any EXR maps), but HDR to TIFF - not anymore, it seems. Every HDR I have fed to various shaders in DS works well these days. Mine come from various sources: the Omnifreaker ones, ones from Openfootage.NET and other free sites, and those rendered in Vue and Bryce as well.
PS The "alpha" invitation extends to you as well =) So if you want to try my GI/HDR system, just let me know.
She was the default V5 one, wasn't she? I remember seeing her poor nose in a lot of the promos back then.
That's right and a version of her is also the default texture for G2F.
CHEERS!
I've been trying to figure out when it happened, but the best I can figure is that it just happened and it was a while before anyone realized that it actually did happen. It probably came in around the time 3DL broadened HDR support...which was before 4.5. 3DL had HDR by version 10.0.50. And looking back through change logs and such even more supports my idea that it just crept in, long before anyone declared 'formal support' for them. There are some hints that the HDR format (not exr) was at least partially supported in 2011. And there was an explicit declaration of support, sometime in 2013.
So, what it boils down to, is yet another under-documented, under-utilized and misunderstood feature of 3DL that should have been promoted...and with tdlmake doing the conversions, that support goes back even farther (and no I'm not talking about the omnifreaker script to convert them. It calls tdlmake and passes a bunch of seetings to it to make them into UE2 'preferred' maps). It all seems to be coupled with the idea that Studio couldn't use all the info (range) in a real HDR and that they needed to be pre-blurred/handled in some way to reduce the amount of info/shrunk to a small size to be useful and a whole bunch of other things that may have been true at one point but were not valid by 3DL version 9 and maybe even 8. Just because the DS shaders were stuck at an earlier 3DL version (6 maybe?). Very few, if any, really use 3DL 8 and later features (there weren't many new features in 9...lots of improvements to existing ones, though; 10 is when things started to get interesting)...and the 10 and 11 features are barely even considered, except by the few of us experimenting.
UE2 was out by July 2010...and UE was out long before that. The conversion script was a UE thing...along with the how to convert them tutorial.
That is an ancient requirement...really.
The lag time between when something shows up in 3DL and when it shows up in Studio is horrendous (if it actually gets formally recognized), even if there is now a closer version parity between the Studio version and the standalone builds. A good example would be the current physically plausible shading features in 3DL...I've seen code snippets and examples of shaders that would rival the results of the metal shaders in a PBR, but are nearly impossible to bring into DS, because ShaderBuilder is currently stuck in 2010 (if not earlier). Another one...a multilayer shader...no, not US2 style, but a 'real' topcoat layer along with the base diffuse (or two). Easily usable method of calling co-shaders....re-assignable include paths so you don't have to hack the source code to add the contents of an include file to the main shader source (this has two effects on a shader...it bloats it, so that makes it slower and it forces it to use parts of the include file that aren't needed...so it's again slowed down by having to evaluate then discard sections of code). I've done difference comparisons on the compiled shaders...those compiled by the standalone (where you can define the include paths) are smaller in size and are usually much faster when run.
You know, I don't think 3Delight does buckets the "old way" anymore in the raytrace hider. Not when calling the new path tracing aspects of trace(), at least (and I always have at least one "modern" trace() in the scene, in the GI light).
I have noticed that even though I have the bucket order set to "Zigzag" (verified on the RIB side), during complex calculations like RT SSS, particularly with area lights, 3Delight will display the finished buckets in a different order ("dancing around", so to speak), and often, for example, it will reveal the SSS-containing buckets all at once, when it´s done with all of them.
I haven't done much with other bucket orders lately..but that would definitely be a more recent 3DL 11 feature. When I discovered that I could shave a decent amount of time off matching size of buckets/bucket order to total image size I pretty much left it at that. I'll have to play around with them again. And yeah, if they've reprioritized it...hmmm...maybe it's in anticipation of bi-dir path-tracing?
The shader is fine, thank you =) It's the documentation that's taking this long. I kinda wish I were a faster writer, but I'm not. Definitely not with the load of technical writing I do for the day job...
But I was thinking... if anyone here is willing to try an "alpha" version (that is: no docs) of anything I have been bragging about here... be my guest. Just let me know what you are interested in.
And it would be best if you sent me an email (my address is the same nickname as here, but at the google mail service) or a PM at deviantArt rather than a forum PM here.
Documentation?
What's that?
Pre-blurring/convolving HDR maps actually used to be done in almost every renderer so as to reduce sampling noise in IBL. It used to be a helpful trick, but it's been obsolete for years.
Another name for black magic =)
Pre-blurring/convolving HDR maps actually used to be done in almost every renderer so as to reduce sampling noise in IBL. It used to be a helpful trick, but it's been obsolete for years.
Exactly...although, I don't think is was ever done in some of the 'institutional' renderers...
Sounds to me like someone from the 3Delight team needs to come and have a word with the DS team to show them how best to properly integrate 3DL into DS. Though thanks to the 'golden child' Iray, I can see this becoming something less of a priority.
CHEERS!
It really should be a priority, because the majority of content is for 3DL, and its still faster and can produce beautiful renders. Having two complete render engines would be a huge boon.
I'm guessing it might be awkward license agreements that's preventing Studio from having "all the good stuff" not an unwillingness from DAZ.
Could be, and I don't doubt a lot of compromises have had to be made to get Iray in there too, but that's another story for another thread. At least Kettu is going some way to unlocking the hidden potential of 3DL in DS.
CHEERS!
Speaking of DS integration, I suspect that the DAZ guys did their "freemium" thing with that: they created the "scripted rendering" interface and Shader Builder, and then they sat back and started waiting for the community to learn how to use these things (sans docs - as the community has always done, we are a desperately smart bunch here, aren't we) and then hopefully make some products for the DAZ store.
Zigraphix and a few others did create "scripted rendering"-related products for several specific needs (toon stuff and something like AOV, if I get the store descriptions right).
And that's that =D
Actually, I don't mind "scripted rendering" now - come to think of it, even in Maya you'd use MEL (scripting language) for "advanced" tasks.
What I am not fond of is, well, there are two things:
1) DS SDK and store QA allowing for plugins that won't work with "scripted rendering" seamlessly (think Garibaldi). I'd love to get in touch with Futurebiscuit (the author), since he could probably explain some of the inner mechanics of his plugin (and maybe there could be a way found to overcome the issues), but apparently he's very busy.
2) Lack of documentation and particularly sample scripts for specific areas like those darned shader mixer cameras (and cameras on the whole).
----------------
It was a PRMan trick.
Oh yeah, I forgot my biggest gripe with DAZ3D, but it's not software-related.
It's about the lack of effort to enforce professional nomenclature and understanding of the very basic things, like (yes right! here we go again!) the difference between a "shader" and a "shader preset". That linear workflow thing. 3Delight being a pro renderer capable of whatever you want (just do it). All that stuff.
Stuff like this should not be "crowd-sourced". The crowd will only accept knowledge from "authoritative" sources. The source with the most authority is the DAZ company themselves.
But when presets for UberSurface are called "shader packs" in the store... it kinda nullifies my every effort to educate the community.
I'm guessing it might be awkward license agreements that's preventing Studio from having "all the good stuff" not an unwillingness from DAZ.
Not so sure that is what's going on. To me it looks more like Marketing needs to pull their heads out and realize exactly what they've got. It seems like a case of 'why spend dev time on something that isn't being used'...but the question is, 'why isn't it being used'....answer...nobody knows that it is capable of being used THAT way.
Could be, as well. It sometimes seems to me there is not a single dedicated 3Delight (or general Renderman) specialist among the devs. I mean... some of the shader bulder functions are Pixie sources.
Read the changelog...
Not in this release of the beta 4.8, but definitely for the General Release...
Yeah, it seems to me, that all the forward momentum with 3DL went away somewhere in the DS 3 version...in that long stretch when the features of 3DL didn't change all that much (7-9, if I remember correctly). Yeah there were some improvements of existing features, optimizations and such, but nothing really new and earth shattering. Then comes 3DL 10 and DS gets left in the dust, because nobody is around who knows 3DL inside/out or really cares...(it works, so?)
I have an idea why they are Pixie sources...because they were GPLed...so readily available. And at the time, 3DL and Pixie were a lot closer to equal. Pixie development pretty much stopped several years ago, so now those things are much further away from the current 3DL than they were then. That was one of the goals of Pixie...be a 'universal' Rispec renderer...interchangeable with 3DL, Prman and any other one around. As long as the feature sets were static, that goal was close to being met. But it always had a pretty small dev team, so once the pace of changes picked up, it got harder and harder to maintain parity/advance.
As to the shader/shader preset...I'm afraid we are losing that one. On the Nvidia forums, for Iray, the line is so blurred now, and nobody is correcting for calling settings shaders, it doesn't matter. Even on the Renderman forums it's getting blurred...I think the only place it still has the original meaning is 3DL forums/3DL in general.
Lots of conjecture here... little, if any, reflects truth.
-Rob
That's good to know...I'd much rather be wrong on my guesses about it.
But you do have to admit that some of the stuff has been slow to come into Studio (yes, we know if they cloned you 5 times, the six of you wouldn't be enough to get it all done...).
Can you elaborate? Specifically why some of 3DL's functionality (like IBL) is not directly accessible.
I don't mean that to sound antagonistic, I'm genuinely curious.
Before I started reading this thread and a few others, I was naively pressing all the buttons on UE2 to experiment, and one day I just decided to stick an HDRI into UE2 to see what happened, and it worked.........but what's crazy is I also converted the very same HDRI with OmniFreakers script, and it also worked, but renders look different between the straight HDRI and the TDL/TIFF container.
But here's where it gets REALLY crazy.
I imported the HDRI into after effects, and converted that to a .TIFF, but it's a regular .TIFF and does not contain TDL information.
I stuck that into UE2.......and lo and behold, it worked....but the render also looked different. I can't understand how this even works.
So to recap, an .HDRI, a TDL TIFF, and a regular TIFF, all of the same exact image, all worked in UE2, but the renders all looked slightly different.
I'm not enough of a techie to understand it or explain any of it, but it's fascinating to me none the less.
Before I started reading this thread and a few others, I was naively pressing all the buttons on UE2 to experiment, and one day I just decided to stick an HDRI into UE2 to see what happened, and it worked.........but what's crazy is I also converted the very same HDRI with OmniFreakers script, and it also worked, but renders look different between the straight HDRI and the TDL/TIFF container.
But here's where it gets REALLY crazy.
I imported the HDRI into after effects, and converted that to a .TIFF, but it's a regular .TIFF and does not contain TDL information.
I stuck that into UE2.......and lo and behold, it worked....but the render also looked different. I can't understand how this even works.
So to recap, an .HDRI, a TDL TIFF, and a regular TIFF, all of the same exact image, all worked in UE2, but the renders all looked slightly different.
I'm not enough of a techie to understand it or explain any of it, but it's fascinating to me none the less.
As near as I can figure...
HDRs are handled directly by 3DL as HDRs and treated as such for all functions.
Tiffs are converted to tdls and then used...but with default parameters.
The Omnifreaker script manipulates it and then the conversion gets done...I haven't looked at it for quite a while so I don't remember exactly what it does. I think there may be some rotation involved.
As a result, while you may start out with the same image, by the time it's fed to the renderer, it is not the same image.
As near as I can figure...
HDRs are handled directly by 3DL as HDRs and treated as such for all functions.
Tiffs are converted to tdls and then used...but with default parameters.
The Omnifreaker script manipulates it and then the conversion gets done...I haven't looked at it for quite a while so I don't remember exactly what it does. I think there may be some rotation involved.
As a result, while you may start out with the same image, by the time it's fed to the renderer, it is not the same image.
That makes a lot of sense actually. I have noticed that the images I render usually look sharper/crisper when I load the original .HDRI with no conversion.
I need to locate and find the DzShaderLight IBL you posted about earlier. I had no idea anything like that existed and I'm curious to see what results it's capable of.
Try Shader Presets > Shader Builder > Light in the Content Library (not Smart Content)
I cannot use Iray with my laptop and upgrading is nowhere in my budget. I can't tell the difference between Iray and 3DL renders anyway. It's time for me to learn how to effectively use what I have. This thread is very interesting and informative.
Thanks, guys.
Welcome aboard and buckle up, the ride is just beginning.....
CHEERS!
Oh yeah, Kettu, you should take a look at this:
http://www.daz3d.com/forums/discussion/42372/
This is a mag called DS Creative, and I think you should contribute something to them.
CHEERS!