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
A more proper test. Only changed UE2 mode and the opacity of the hair geoshell for the IDL render. Every other settings is unchanged.
AO with soft shadows : 48.21 seconds
AO with directional shadows : 54.37 seconds
IDL with soft shadows : 14 minutes 55.44 seconds
IDL with directional shadows : 10 minutes 52.30 seconds
It is possible to get better renders from DS but you have to work a lot to adjust light and materials. Here is one I did two years ago. The glass and wine need more tweaking
I don't think render time should matter that much
Lovely renders! I wonder why IDL with soft shadows would take longer, though...
I also noticed the hair specular looks quite bright, maybe you could try toning it down a bit?
------------------
Takeo, hi! The glass itself looks quite nice, but the wine is indeed too dark - did you use SSS there or absorption? The little figurine on the right is also very cool, as is the reflective floor.
------------------
...While working on my planned release, I've done some testing of how well LAMH Human Hair Shader would play along with my shaders, lights and scripts. It's just a test, a very quick style, and I'm fairly rusty on setting up the Marschner model, so please don't be too harsh =)
It's supposed to be. The light intensities is set to maximum value, making matte materials pure white (255,255,255). So a blowout is expected.
Here's the toned down version of the lights, One with more ambient light and the other with less ambient. I'm using two sets of rim lights now (one set at 90 degrees and another set at 120 degrees, left and right) so there's very little shadow (since the light is coming from practically every direction).
I see now. I think I like the top one better, it looks less overexposed.
The new, sun light setup. Just one UE2 and one distant light. The setup has two more distant light for rim lights, but they are off by default.
The clothes are all still using DS default shader with the skin preset.
Not very convincing from what I see but the scene is not lit enough to really have an opinion.
Not much else actually happens to light at all inside materials, apart from absorption and possible re-emission =) Sometimes we call the results "refraction", sometimes "subsurface scattering", sometimes simply "absorption" - but it's still basically the same quantum physics inside.
The absorption thing is mathematically simple: Beer's law. You can consult the code from the second archive from Mario Marengo's thread:
http://forums.odforce.net/topic/9039-mario-marengos-glass/
The shader source code is the .vfl file. Not RSL, but close enough. There's also a glass.h in the first archive, you need it to understand the more complex functions.
Not very convincing from what I see but the scene is not lit enough to really have an opinion.
Well, hair should look like hair, no matter the lighting (and the light is coming through a curtain, so it's something that happens every day...), so that is a pretty lame excuse for not providing constructive criticism, don't you think? ;D How facile are you in this particular realisation of Marschner's model? I'm attaching a screenshot of my settings, what do you think could be improved?
Again, please - disregard the style; I need to get the actual material right.
Which is rather frustrating for me right now: the human hair shader settings in LAMH will only save as a deprecated .dsa on my machine - they keep reverting to defaults when the scene is saved/loaded; Garibaldi is easier to work with, to me (one word... clumping!), and saves materials correctly, but it's a lottery whether it would generate the curves in scripted rendering mode or not. I don't know what could be wrong. I asked in Garibaldi's dedicated thread, hopefully someone knows what to do.
I'm able to get prettier styles out of Garibaldi easier than out of LAMH, and the shader needs less tweaking IMO. So I'm pretty happy I did find a way to use Garibaldi with scripted rendering, even though it's a bit convoluted and will probably only work for hairstyles and not furred creatures (but hey, I prefer LAMH for fur anyway):
http://www.daz3d.com/forums/discussion/17751/P1200/#763886
Here's my girl again, with Garibaldi hair this time...
Sorry but some friend died recently and my head is like "blank" these days. You'll have to wait a bit to get a better answer from me
Oh, how sad. That's alright then, Takeo. Take your time. Condolences.
Condolences, Takeo. Sorry for your loss.
Thanks to both of you
Feeling better now
@Mustakettu85 : still not convinced and I don't know if that is because of the hair model or because of the shading but right now I'd say hair model. Seem too thin at the tip
And I think there is too much specular and specular reflection don't seem natural to me but that could be because of the hair model. Try with another one?
Good to know you're better.
...hmmmm, "too thin at the tip"... I'm always going for that "razor-cut" look (cuz I'm soo punk rock trying to be trendy LOL); you mean it's too much?
I'm slowly getting the differences between Garibaldi and LAMH shaders (the biggest thing that threw me off might have been the order in which parameters are shown; I keep mixing TT and TRT, just one letter is different!); but I still have huge problems actually styling in LAMH. The brush just does not "feel" as natural as in Garibaldi, and LAMH hates me when I try to grow hair on a figure directly, so I have to use skullcaps.
Here are my two latest attempts in both: the blonde Aiko3 has a Garibaldi style (the skin is my SSS), the redhaired V3 has a LAMH style on a cap (skin is default DS shader that can be really cute now that we have control over the fake scatter colours).
No, really, that's the best LAMH style I could come up with after a whole evening of fiddling and starting over.
That's better especially the second render. You could just use a sphere to do hair test
I don't know how are Garibaldi or Lamh in the hair creation process. The only one I used is blender's and it is very stable.
I should find some time to do some 3D thing again
Thank you. I find the second style extremely unfashionable, though =) I'm sorry I don't want to offend anyone, it's just my punk rock taste! =) I will keep on trying to create something I am happy with, style-wise.
A sphere won't help me learn how to style hair around ears, nose and cheekbones, unfortunately. That's one of the difficult parts.
...I'm thinking about digging into the source of this 3DfM hair shader and trying to apply what I learn from there to DS: https://3delight.atlassian.net/wiki/display/3DFM/3Delight+Hair
But that's quite a few steps down the road!
Thank you. I find the second style extremely unfashionable, though =) I'm sorry I don't want to offend anyone, it's just my punk rock taste! =) I will keep on trying to create something I am happy with, style-wise.
A sphere won't help me learn how to style hair around ears, nose and cheekbones, unfortunately. That's one of the difficult parts.
...I'm thinking about digging into the source of this 3DfM hair shader and trying to apply what I learn from there to DS: https://3delight.atlassian.net/wiki/display/3DFM/3Delight+Hair
But that's quite a few steps down the road!
I'll second the testing on a surface that is not perfectly linear, like a sphere.
I took a cylinder, sent it to hex, removed the ends, then sent it back to Studio. Threw a D-form on it to warp it a bit (like a vase), and "Exported' the thing as an obj file.
This gives ma a non-linear surface to see how shaders deal with that. And the ends show me what the shader looks like from the 'Other Side' as well.
I'll see if I can't find a few seconds today, to upload the 'vase' to sharcg or something.
My eyeballs have melted, my brain has leaked out my ears and I'm still not caught up with this thread...but I'm back...I hope. After two melted hard drives, needing to wait for a kernel update for my OS and reinstalling everything 2x (with DS itself being reinstalled about half a dozen times in the past 2 weeks alone), I think I'm ready to get back in the game.
I've been trying to play around with things discussed in this thread, but I'm having some problems with somethings...it's probably a path issue, but the photonGI just doesn't work right for me, at all. Oh, I can get a lit render, but there's no photon map to be found...so there's no GI. So it's like rendering with a plain old distant light (and yeah, tried about a bazillion different light combos, even 'from scratch' RSL ones). The raytrace script works very well and is blazingly fast...but I can't dump it to a working RIB (no collect/localize on the script...and I can't edit the RIB to get working output...I've tried...)
Here's a render...raytrace render script, Env2 and an area light. The paint is a car paint shader I'm working on getting into DS...it works, but tweaking the settings is getting to be a bit of a pain in the posterior (got a couple of dozen presets planned for it based on 'real' car colors...this is the BRG one, almost). Glass is the GlassJOF. Playing with a few other glass shaders, too.
Hey Mjc, glad to see you back!
As for photon GI - and photon anything - single-pass or two-pass? In my photon mapping adventures, I found out that two-pass is more robust with DS. Get my kit here and feel free to take it apart (there are some docs in the text file, too): www.mediafire.com/download/igbgaxgcg3jhavc/Kettus_Photon_Mapping_Kit.zip
It´s important to actually _load_ the map during the beauty pass, BTW.
And for robust raytraced GI/IBL the way it's supposed to be done for the 3Delight raytracer these days, use this code (I'm sure you know what to put before and after these lines, but it's literally all there is to a GI envlight these days that gives shadows from the HDR as great as those from envlight2):
http://www.daz3d.com/forums/discussion/45412/P30/#678700
RIB editing: just kill the "function" line after the RiDisplay call. Then it will render. Run ribdepends on that RIB to have it collect and localise... I hope to find out how to call it from within DS.
http://www.3delight.com/en/uploads/docs/3delight/3delight_17.html
While we're talking photon anything... This evil Fox will include caustics in the big kit =) Paolo Berto said photon mapping is still the best way to get them... so I made scripts to add them to raytraced GI. Something like this...
Thank you. I find the second style extremely unfashionable, though =) I'm sorry I don't want to offend anyone, it's just my punk rock taste! =) I will keep on trying to create something I am happy with, style-wise.
A sphere won't help me learn how to style hair around ears, nose and cheekbones, unfortunately. That's one of the difficult parts.
...I'm thinking about digging into the source of this 3DfM hair shader and trying to apply what I learn from there to DS: https://3delight.atlassian.net/wiki/display/3DFM/3Delight+Hair
But that's quite a few steps down the road!
I was thinking about just making a "fur ball" for shading test. For hair styling you sure need a human head
PS nice glass render
For the map...it's finding it that's the problem. The way WINE handles Windows paths isn't always conducive to locating things like that. It's the same for the RIB dumps, without DS doing it, it's hard to track down where everything is...ribdepends doesn't work either...because the one included with DS does Windows paths and the stand alone Linux one does Linux paths...or 'Not Found'. So basically I'm reduced to doing it by hand...
I have a similar problem with doing includes in shaders...without actually pasting the contents of the include file into the base shader code file I can't get it in there. Any includes directory I try to set up is never found and more often than not, if I comment out the includes the shader won't compile, so I can't generate the SDL with the Linux standalone and substitute it for the crippled DS version.
I'm not sure if it is 100% WINE"s fault though. It may be more due to the fact the DS 3DL does not have/access the 3DL ini file where you can define things like the includes directories. That and the insane way Windows has forced the split up of the program, content and user content directories...even if you put everything on a separate drive/partition, DS STILL wants to use the APPData folder for some things, even if you try to move everything elsewhere.
As for the caustics...well I guess I don't have to make it a priority now. :cheese:
I did run into a weird problem trying your Fiery Genesis- Radium version. It slowed to an absolute crawl...something like 16 hrs to finish. With all the Omnifreaker stuff and transmapping it took a couple hrs as a 'regular' render, but with your raytrace scripted render it slowed to impossible speeds (heck, Lux is faster...)
I think this question may help that slow as dirt issue.
So if all I want is a specified surface, to reflect light to illuminate other surfaces (not just reflect illuminated surfaces), I just inject that code somewhere for those specific surfaces?
Or would the masking and mapping process be even worse in run-time hours :blank: (days, months)? :coolhmm:
CTL-ALT-DEL...
CTL-ALT-DEL... lol. after first coffee, and the Brain's CTL-ALT-DEL, lol.
GI slow as bloody hell. I'm not surprised If I follow this.
1. Unbiased render engines take so long to render a scene, because they calculate most if not all of the paths light takes bouncing around a scene. That in itself is an incredible amount of math, akin to how many grains of sand are on a beach.
2. 3delight takes a few shortcuts to reduce the amount of maths involved, completely ignoring some things. Things like light bouncing off one surface to illuminate another for example.
3. There is "Machine level" algorithms, and "Higher level" algorithms. From what I gather, that GI code is not "Compiled" into machine language, implying that it must be translated on the run into something the CPU can comprehend. Like Basic or FORTRAN. This results in formulas requiring at least three times more computations to execute.
Now that GI code is implementing a global scene light bounce mechanism akin to what Unbiased render engines do, and it is not in machine code. So it is far more computationally demanding then that number of grains of sand on the beach. lol.
CTL-ALT-DEL... lol. after first coffee, and the Brain's CTL-ALT-DEL, lol.
GI slow as bloody hell. I'm not surprised If I follow this.
1. Unbiased render engines take so long to render a scene, because they calculate most if not all of the paths light takes bouncing around a scene. That in itself is an incredible amount of math, akin to how many grains of sand are on a beach.
2. 3delight takes a few shortcuts to reduce the amount of maths involved, completely ignoring some things. Things like light bouncing off one surface to illuminate another for example.
3. There is "Machine level" algorithms, and "Higher level" algorithms. From what I gather, that GI code is not "Compiled" into machine language, implying that it must be translated on the run into something the CPU can comprehend. Like Basic or FORTRAN. This results in formulas requiring at least three times more computations to execute.
Now that GI code is implementing a global scene light bounce mechanism akin to what Unbiased render engines do, and it is not in machine code. So it is far more computationally demanding then that number of grains of sand on the beach. lol.
Except...
The script makes use of a cache, thereby eliminating, in theory, a ton and a half of the processing.
Hmmm....now putting 3Delight into ML...wonder what kind of speed up THAT would do...
But the whole point of the 'new' raytrace hider and scripts is that it IS faster...except for me in these cases. It approaches point-cloud GI solutions in speed (some cases beats out point-cloud speed) with raytracing accuracy. It's like my machine is reading the cache by way of Hong Kong, Calcutta and London (with a loop around the Moon, thrown in for good measure), instead of off my hard drive. I know that it is faster, because I can render some fairly complex scenes using the same features of 3Delight, in the stand alone version, in minutes, while some of them take nigh on to forever in DS. Something is being lost in translation, so I'm not sure if it's a WINE/Windows problem or if DS is somehow broken or what it is. (no, I haven't gotten exact duplicate scenes to work right...yet)
hmm, that sounds almost like the worst case of what Seymour Cray was saying. Ram, ... It's allot better when you don't have to fake it.
(I'm not assuming for your situation, just thinking out loud in general)
So, Cache file on a heard drive somewhere, copied to Ram, that first must be swapped out to virtual ram on a heard drive somewhere, etc, lol. "O" the agony when the process must be repeated for every cache-window crunched by an algorithm, also in the virtual ram on a heard drive somewhere, Eeek. lol.
Doctor, we need more RAM, and lots of it, lol.
Dammit, Jim, I'm just a country sawbones...call Scotty.
Gods, Mjc, I'm so sorry you're stuck like this,
It looks like DS is heavily OS-dependent. There is a person who contacted me because he can't even get Envlight2 to behave properly on his OS X machine - shader builder seems to be doing something weird in the Mac build. And now you reporting the path thing.
Does the RIB render if you keep DS open on the same scene, so that all the files are still in the temp dir? Or is it that the Linux standalone won't recognise Win paths at all? Then I got this stupid idea... what about a Win3DL installation under WINE, have you tried rendering the RIBs with it?
Hmmm... as a last resort, you could probably make a macro for something like Notepad++ to automate converting Win paths to Linux ones?
But as for includes - to get shader builder to compile a shader with these, I have to dump them into the same .sl file as well, on Windows too. So that particular issue is not just because of WINE. Gotta be the no-.INI thing.
--------
Renderman-compatible renderers use SIMD. Makes interpreted code almost as fast as machine-level code, so they say. Then there is actually an option to compile into machine code now, IIRC... but I don't know how to access it from within DS, so I can't say I used it.
Either way, whatever I write, scripts or shaders, that all works really fast on my Windows machines (of which I have had quite a few at work because they keep dying there with alarming regularity: I keep asking folks to check the electrics, but no-one ever bothers to listen to me...). Kevin and Wowie here run Windows too, I believe, and the script is fast for them as well. So the issues Mjc has run into, that gotta be the OS thing. I have no idea where that GI cache actually resides, so what with the WINE and WIndows talking to each other over a broken phone, it may well be on one of the moons of Saturn.
Which makes me daaaaaaaamn sad. Because it's unfair.
4.6 NEVER had these headaches...I'm very tempted to go back...but then all the new 3Delight features go away, too. Heck, I'm being forced to try coding again...and that's something I haven't done in close to 30 yrs!
The cache resides in the temp folder for DS...but it seems to me, I haven't actually traced it down, that maybe a fixed path has crept into the code, somewhere, as opposed to a relative one. It makes sense, with that Env2 issue, too...because that IS not a shader issue, but caching one. WINE as it approaches Windows in interoperability is getting/exposing more and more Windows flaws. This whole paths/permissions thing is all MS fault...they started out with no restrictions and then in Vista dropped a very restrictive model and have tweaked and changed it so much that now it is worse than ever. Windows 8 has done no favors to the way software is installed/deployed on a system.
Having both the Linux and the Windows versions of 3 DL on the same machine, while possible, is not something that works too well...or at least it didn't before the version 10 series. With 10, I never needed it. Havent' tried it with 11. (the problems were with the old license server mode of operation...since 11 doesn't do that any longer it may work better).
And yes, the Linux version won't correctly read the Windows path info, no matter what. The RIB that is in the DS 'collected' folder is already written with short, local/relative paths, so there are no issues rendering with a different version/OS 3DL. It's when you have to use the 'outside' RIB that problems occur...or you need to be very good at manual RIB editing.
I should probably try Cutter again... http://www.fundza.com/cutter/about/index.html
But I was never any better with it than using a plain text editor. And the included Linux text editors are lightyears above and beyond Notepad and even better that Notepad++ (which I drop into WINE to replace its crappy notrpad clone)...DS MUST have a notepad.exe around to open the log file. I finally did succeed in getting DS to use a fake exe for Luxrender to open the native Linux version, but I still can't get it to pass the file over...so maybe, if I keep at it, I'll get this crap fixed, too (heck I even got Bryce to finally work in WINE...that is a tale for another day...preferably with a large amount of cerebral lubricant/adult beverages on hand).
On a side note...on speed. I usually recompile my shaders, after I get them built/tweaked by hand with -O3 switch. I think the default is -O2. I've seen that shave 10 secs off a 60 second render. You have to do it by hand, because I can find no way of forcing Shader Builder to call shaderdl with different than it's default compile options. You'd have to do the same with any other compile options coming out of Shader Builder. Of course if we had access/use of an ini file for the included 3Delight, we could set those options...maybe we should put in a feature request to add compile options to SB?
Also the annoying, often at a critical time...like right after you've finished adding all the user controls to a new, imported shader, but before you've actually saved it SB crashes...usually, it's an unhandled Qt exception, if you look deep enough or care enough to look.