Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.Daz 3D is part of
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
I think it may be like trying to get glitter specks effects that are incredibly difficult at best unless the texture maps can be resized so that each pixel of the map is some fixed ratio (like 1-to-1) to each pixel in the final render. Apparently, some rock shaders are not the only ones to completely break with progressive render mode. Short of actually painting the dirt directly onto the texture maps in (whatever the pro ILM program is called, MARI?), I don't know of a simple shader setting to just make random dirt dust or glitter specks.
I do know that scripted (over my head) shaders can do some of that, tho from what I've seen it's easy to break. There may also be something in spaghetti land, tho again not a place I know well enough to enter without someone by my side to save me if I get tangled up in stuff, lol.
as for a make something a tad dusty, that would be a nice overcoat effect if it could be done in Daz Studio 3DL. It would also be incredibly nice for fingernails and makeup.
I've noticed the problem and commented ages ago.
never got a response more substantive than 'huh'
LOL! Thanks for the laugh Will
@ZarconDeeGrissom
well that seems at least some kind of explanation, I must admit that I have not yet entered the differences in the processes from progressive to the not progressive. The good thing is that I can make the shader work, so I might probably find a way around as well to use them in progressive. Some tinkering ahead...
This is part of my list of reasons why I use Iray. 3DL has SO many patch fixes that eventually I got tired of 'well, lighting X doesn't work with shader A unless I actually change the script, and then it only works without progressive on, but then you have to make sure the opacity + diffuse adds up to no more than 200% and then that breaks proper ray tracing so you really ought to rewrite all the shaders and...'
ugh
I havn't come across that many of those problems yet and on the other hand I came across some of that sort of problem with Iray as well, so its testing and learning and sometimes patching for both I guess
That isn't the fault of 3Delight...it's the fault of poorly writte
As I don't have that shader, I can't say for sure...
Oh my. Shader Mixer strikes again =(((
Linwelly, I honestly wish I could do _anything_ about it, but as you may have heard, Shader Mixer stuff has no source code that we could look at. No idea why progressive mode would break a noise function - but then, I don't know how that noise is antialiased internally. Could be the culprit.
Tell you what... you could try two things:
a) More of a test: export a RIB and change the "progressive" bit from 1 to 0 manually by using an editor like Notepad++ (this will keep the raytracer but disregard the mode). If you do "collect and localise" (and you want it unless you are okay with keeping the scene open in DS for the duration of the test), don't forget you need the RIB inside the folder that gets created. Then render the RIB in the standalone (I hope you do have it, if not - it's free on the 3Delight website, look for 3Delight Studio Pro, and you may uncheck 3DL for Maya and Katana during installation). Is the dirt still there?
b) A "cheat" which is not a cheat: render out the box only in vanilla mode but with all the textures removed and all the colours but dirt set to white. Ambient-only (no AO) white (no map) UE2 lighting probably works best because you just need a dirt overlay, it doesn't have to be shaded. Then you multiply it into your render in GIMP or whatever you're using.
Yes. yesyesyesyes. Exactly this. Rewrite all the ancient RSL code. Just do it once and then forget about any issues and get busy with setting up your world. Like me =P
Okay I still tinker with the code, but mostly because I like tinkering.
...totally __had__ to fix a displacement bound multiplier this spring, but it's because I had been stupid and never noticed I was multiplying by 1.5 in the shader. And then I was wondering why my displacement bounds are too small whenever a map is hitting full gamut LOOOOOOL
It wasn't even shader code. Rendertime script code. =)
Yes I am messing with you. Relax =) You don't have to do anything you don´t find fun. Neither do I. And this is my idea of fun.
I don't have the shader so that will be a bit difficult to guess. I think I encountered that problem once with shaders I wrote but can't remember exactely what it was
My guess would be on a difference in displacement handling. With progressive mode you use the raytrace hider under the hood. Without, you use Reyes which is known to handle geometry displacement like a champ. Micro displacement is an area where many pathtracing engines have difficulties.
Try to find displacement settings and crank them up
Eventually post the shader parameter and the log file. I need to see what happens after applying the shader and also what happens during rendering
My take on alSurface. I'm calling it awSurface.
An energy conserving, physically plausible shader. Needs more work (a proper Oren Nayar diffuse and GGX/GTR specular) to make it physically based but the PBR backbones are all there. It should be easily portable to Shader Builder and of course, hand written RSL. In fact, I think with hand written RSL, some of the stuff can be handed over to the renderer ie
Then it should be possible to use it in other apps.
Fix that for you.
All the hacks and patch jobs are done because DAZ never included a full, proper documentation, tutorials and best practices for Shader Mixer and Shader Builder. As many other pointed out, even the more modern RSL shadeops are not even listed in Shader Mixer/Builder or do not have all the inputs exposed. So shader writers either have to be very well versed in RSL and hand write their code, figure out how to import them via Shader Builder, or make do with DAZ archaic support of RSL shadeops.
Not actually surprising since they never even put in
I actually tested that DAZ old Cornell Box scene awhile ago - with DAZ own IDL photon mapper setup and UE2. Both with DS and the up to date standalone (12.0.125).
Within DS 4.7
With the standalone
That 6 second gap, became much larger at higher pixel and occlusion samples. I went all the way to 16x16 pixel samples and 2048 occlusion samples.
That's a reduction of 40% in render times and nothing has changed in the object, materials or shaders.
Hell, I even tried exporting the scene into .FBX and import it into Maya. That 30 seconds result went down to 20 seconds. I attribute the difference to proper implementation of photon mapping for multiple light bounces (I used ray trace depth 3 for testing). With even higher ray depth, UE2 has to actually fire more rays so it will be slower than just looking up the photon map.
DS 3delight implementation is piss poor at best, in terms of performance wise or completeness.
Ok, more accurately, 'I use Iray over 3DL because it's actually supported and not broken and Daz is never going to fix 3DL.'
Maybe so. But I'm just pointing out technically that statement is inaccurate. The responsibility of implementing a renderer and the supporting ecosystem lies on the people doing the implementation (DAZ), not the renderer (3delight) or the renderer developer (DNA Research). This is true for any renderer - Octane, Redshift, Cycles, Luxrender, Vray, Renderman, Arnold etc.
On that last note, I'm not sad about the situation. It's just the way it is. To really make use of 3delight, or any other renderer for that matter, we need to look at the best implementation, which in this case those done by 3delight team themselves (3dsmax, Maya and soon Katana) I wish there was one for Houdini though (and perhaps Blender). I'm actually quite optimistic about the prospects of being able to use the shader I've made in those apps as well as DAZ Studio. Multiple render passes/AOV and object ID to a deep EXR? Not just possible but plain easy. Adding procedural noise or curvature shade op to add grunge, dirt etc? Just plug the appropriate input in the material editor (Slate, Hypernode etc). Texture baking? Works and doesn't crash the app. Curve/strand based hair rendering without the need to collapse into geometry? Hell yeah.
Fix that again for you.
"Never" is too strong, I'm still not putting it past DAZ that they _will_ reconsider things when the OSLtracer is fully rolled out in 3Delight 13 (it's a whole new ballgame), but it's fairly unlikely, on the other hand. But theoretically possible. "DAZ Soon (tm)", y'know.
This is one thing where DS is sadly lacking, and I'm not even sure it's feasible to try and shoehorn texture generation in. On the other hand, I saw a reference to Substance Batch tools in the DS changelog... supposing DS could call a Substance file, make it generate a bitmap behind the scenes and then use it in the texture slot...
Have a question here -
I am trying to separate out parts of a portrait that I will be layering in Photoshop. I'm doing this because I want to superimpose a skeleton beneath a semi-transparent person for a cool ghost effect. I wanted to have more control of opacity rather than a global setting for the "living" person and his clothes and hair.
The full portrait 2000x1667 rendered in 49 minutes, the clothes in 11, and the eyes by themselves in 54. What gives? I gave up on the hair and circlet because they were at 76 percent after 50 minutes. So why would small individual parts take longer to render than the full portrait?
Here are the two smaller versions of what I want to put together (the skeleton here shown with transparent skin). It's M4's skeleton with AoA's Metalized Glass Shaders which I had to fit to G2M skin. That was an adventure itself. I used Rim Light Rig for the lighting.
First of all, some creative idea you've got going on, nice =)
Now, to your question. The obvious answer is that you need to optimise shader setup and render settings for "difficult" objects like transmapped stuff and reflective stuff.
First of all, you need to be using "progressive" mode which, as you may remember (no offence if you honestly do, I just have no way to read your mind =))) gives you a dedicated raytracer that is faster at, well, raytracing.
For hair: the easiest way to shave off some (sometimes a lot) rendertime in "vanilla" DS is using UberSurface (the original free one will do) and disabling "Occlusion" or at least setting it to "Override" with a high shading rate (as high as the slider goes).
Now, the circlet: are you rendering it separately from the hair or in the same scene? I'm asking because I can't tell if it's really raytracing reflection and so slows down by itself, or if it isn't raytracing but only gets caught in the slow transmapped hair thing.
Just tested the new stand alone. 12.0.160
That UE2 raycache scene is now 32 secs (was 36 seconds with the .12.0.125)
Looks like there's general improvements outside of the OSL and NSI stuff. Interesting to see if the GGX/GTR noise problems have been improved/fixed.
Might want to check is SSS enabled on the eyes/sclera. I generally skp using SSS on the eyes and just fake it with two diffuse lobes at different roughness. Unfortunately, that only works with a shader with the feature.
Playing around with adopting Beer-Bouguer-Lambert law.
Don't we all?
Of course, you can always port RSL codes yourself.
Just playing around with the colors. Here's a shot of the slightly revised shader, testing how objects look inside.
So nice to see depth/distance based attenuation working. Hmm, I wonder if I can add that depth based parameter I suggested awhile back. So it gets murkier near the base.
I will port my RSL stuff one day, but I want to see the right way to use the syntax for their "extended" closures _now_. =)
You could use altitude-based fog as a guide for how to get the depth to work - I think there was an open-source shader either in the Mosaic or K-3D package.
-double post-
Had to do it the hard way by making my own Fresnel function.
Physically based metal with complex IOR. Right now it's still hardcoded for copper. It's just a matter of completing the shader to take BaseColor and EdgeTint.
Sweet...
Here's what I have in mind for the section arrangement. Not final though.
Base
Diffuse
1st Specular/Reflection (currently GGX, but if possible I want to make it GTR. By default, strength will be 1 and the IOR is implicitly set to 1.8. If you want an IOR of 1.5, set strength to 0.625. Fully energy conserving, so you can push it pass 100% for really dim specular maps and the resulting spec/reflection will always be less than 100%).
2nd Specular (actually the same as above. So, two specular lobes, Usefull if you want to use an IOR more than 1.8).
Fuzz/Sheen (tentative, will depend on how easy to implement. Specular based rather than diffuse based ie velvet)
Transmission/Refraction
---
Coat
Clear Coat (fixed IOR of 1.5. So total IOR of all specular lobes at maximum minus fuzz is 4.1. The highest dieletric IOR is probably silicon at 3.9)
Thin Film (tentative, will depend on how easy to implement)
Plus your typical visibility overrides and of course per layer bump/normal/displacement. It's more inspired by PxrSurface/PxrDisney/Mantra Principled material rather than the standard 3delight material or Iray uber.
I guess I can put emission to in there, though personally I always hate having ambient/incandescence/emission in a surface material.
Unfortunately, at this time, anisotropy won't be usable in DS 4.7 because the 3delight version included in that version doesn't offer anisotropy for GGX or GTR. Probably needs 4.8 onward though I haven't checked. Environment map support? Maybe.
Haven't played with SSS yet.
Got most of it working.
Right now, sheen is enabled for dieletrics only and tied to dieletrics IOR.
Genesis 8 Female 3Delight Conversion
I picked up Duffy for G8F which is Iray only and am attempting to convert her to 3DL. I'm having some trouble with the eyes because of the G8F changes. I have been using AoA's Introduction to Character Surface Settings tutorial and some things are not responding. The tutorial used both AoA's Subsurface and Omnifreaker's Ubersurface shaders on the eye surfaces.
For example, using Omnifreaker Ubersurface shader on the cornea turns it black. When I lower the opacity, the iris texture shows through, but then the reflection goes away. I have a plane with a picture in front of her so that her eyes have something to reflect. Also, no matter how I fiddle with the settings (using AoA or Uber), the sclera remains pure white.
The eyes are just flat. Can someone help me out with the settings?
Never mind. I figured it out.
Looks like the base types are almost ready. I need to fiddle more with the glass.
No lights, pure ray tracing. 6 minutes with 12x12 pixel samples. With UE2's bounceGI 16 minutes 39.51 seconds.