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
Alright, separate highlight works.
You can select which part of the hair by fiddling around with the u value of uv coordinates. Obviously, you shouldn't enable it for the scalp in polyhair.
Probably be a good idea to add repeatable highlights and offset, rather than just one or relying on the poly hair tiling/uvs. I think I can also make it so it accepts texture mask, just in case you need a very specific placement and control the highlight strength. Got to work on the randomization options. Seems like Shader Builder is acting up with my randomization naming conventions.
Some rendered out variations of wider highlights, melanin concentrations and root to tip ramps.
I'm impressed!
Almost done. Just need to make sure it works with curve/strand based hair and works derive proper absorption values from hair textures.
Any progress on your works Wowie? I just realized that it's been 2 months since we have heard from you. Hope your doing OK!
Question about the inner mouth for Genesis 8 Male .... I'm working on getting the 3Delight set up for my Gino project. I just about have it done but the inner mouth looks so blown out. Not sure what's going on with that. I have posted my settings below. The teeth look fine but the tongue and the inner mouth are washed out. I even created a darker version of the maps in hopes that would fix the issue but it's not helping. Perhaps, like iRAY, the diffuse map needs to be plugged into another channel to get the correct natural red darkness that inner mouths have?
Is that with only the camera headlamp or are you actually using some lighting that produces ambient occlusion? With only the cam headlight this behaviour would be expected. But maybe simply lowering diffuse strength to about 60% would work as a compromize?
No, I'm using a light set converted from iRAY, Rambrandt, but of course tweaked to suit 3DL.... even with just the headlamp on I was getting that. I think I have it solved. My last bit about plugging in the inner mouth maps to the Specular channels worked fine! :-)
Ok:) Didn't think using a specular map would do much difference, since you used only the spec 1 lobe with maybe 25% strength. You shouldn´t use the same map as the diffuse channel, though, the spec controlmap should have a gamma value of 1, while the diffuse map should have gamma 0.
Ah, good tip. Thanks Sven!
Hi
Really rather impressed with Awe Shaders so far, but I'm having some diffs with the Shadow Catcher - I assume that's what I need on a plane to catch ground shadows in a scene with only an HDRI?
Works quite well on IBLMaster (although not as well as in iray), but I'm just getting a white plane using Awe Env dome and the Awe provided shadow catcher script - tried a shadow catcher shader mixer recipe Sven posted on another thread, and that comes up tinted dark (too tinted) and still no shadow (I think).
https://www.daz3d.com/gallery/#images/810786
https://www.daz3d.com/gallery/#images/810791
Scene is based on the Awe test scene, I just dropped the spheres, changed the dome image and the clothes and added a second G2F - also added a pt awe plane pointed at the ground in front as I thought I read somewhere about the catcher needing extra light help.
Here's one that did work, but I'm not trying to catch shadows...https://www.daz3d.com/gallery/#images/810891
Also, any advice on getting scripted 3dl to render to rib with collect and localise? I can't find a collect and localise setting on scripted 3DL - I run on Wine on Linux and nearly always run 3DL native on Linux - apart from having to switch rib off for shader mixer otherwise it doens't work.
Any help would be apprecriated.
Hi there! Not able to help much, as I couldn't get the awe shadowcatcher to work either, and I've seen other comments about issues with it. And the shadermixer version won't work with scripted pathtracing or aweSurface, unfortunately. Only workaround I have to offer is to render using IBLM light with aweSurface and the Raytracer Final script. That kind of works, you just need to up the IBLM diffuse samples to 64 or 128 (or maybe more) to get rid of the noise.
I remember wowie mentioned that the awe shadowcatcher needed awePT light for sharp shadows, as HDRI lighting only produced ambient occlusion type shadows.
Regarding rendering to RIB, I'm sure wowie or Mustakettu85 will drop by and offer some help;)
Thanks for the reply Sven
ah, so Shadow Catcher doesn't easily work then, at least I know it's not just my inability to get to work alone.
I did try adding an awe AreaPT light shader applied to a plane and positioned above and to the front of the ladies, pointed at their feet, but with the entire ground plane opaque and white I didn't expect much.
I also doubted a shadow catcher for regular 3DL would work considering how 'shadow play' 3dl shaders mostly look in awe light, but it was worth a try, and I'd been meaning to try to familiarise myself with Shader Mixer anyway.
I'll give iBLM a couple of run-throughs - using it would be preferable with Awe to the primitive sphere method anyway.
That's because it requires creating folders and running ribdepends with parameters, and I haven't gotten around digging in the DAZ Script doc to find how to do it.
You can easily run it manually on the RIB that DS generated, though.
ribdepends -package [path to a folder into which to copy files (it must exist beforehand!)] [path to your RIB]
You shouldn't close DS before you run this, obviously, so that ribdepends is able to find all the tdl and sdl files in the temp folder.
As for a shadowcatcher - if you guys really need one that works with GI and pathtracing, and you would be okay dealing with a small catch as regards the aweSurface model, then I could revisit my personal shadowcatcher project to make it usable by other people.
The catch is that mine doesn't take any environment spheres (and their rotation) into consideration; it will project shadows from an environment map according to my coordinate system (I think the public rendering scripts do have it, but I'll check again). So if you want aweSurface environment lighting and/or backdrop, you will need to either rotate the aweSphere by a specific angle and lock it, or apply aweEnvironment to a generic DS sphere primitive (normals inverted, equator at floor level) - so as to match the coordinate system.
So if you guys are fine with that, then when I'm on vacation (July), I will whack it into shape and upload the results.
Along the same lines, I'm thinking to do what you suggested a long time ago - adding environment map lookup to AWE Surface.
Don't know yet if the tiling/offset can be pushed from the environment sphere to the surface shaders. If they work, then the code should be transferable to the shadow catcher.
Thanks for giving my problem some thought Mustakettu85.
If I understand what you are suggesting is that I use unscripted 3Delight first to collect and localise the elements of the render, then run the scripted versions (to rib) and run the scripted rib on the collected folder like I normally do with a non-scripted 3Delight render?
I considered that might be an option, and tentetively tried it - I just threw the scripted rib into the collect folder and tried to run it as normal
I normally output the rib to a folder on /home (e.g. 3Delight/name_of_rib), cd into name_of_rib_collected and run
renderdl -id name_of_rib.rib - and no probs
- Of course it didn't work. The paths were off (pointing at C:/) - oh good grief, the rib is a mix of absolute and relative paths and despite having a global path set up, it also contains other path references in the body...sheesh!! So there goes just altering a global path at the top...(does that even do anything?....it still can't find shadowdistantlight.....?)
Ok, I'll give that a whirl after some sleep, I'm just off shift.
Thanks
GafftheHorse, the steps would be as follows:
- generate a RIB using the scripted renderer;
- then with DS still open:
1. create a folder to "collect and localise" into;
2. run ribdepends -package "folder" "original RIB" to have it "collect and localise" everything into the folder.
- then you can close DS;
- change to the folder - inside it there will be an updated RIB and everything it needs. Run renderdl on this new RIB.
Thanks for that clarification. I was kind of thinking along the lines of what I had to do with output from mcjteleblender to get scenes into blender.
Well, there's two ribdepends on my system, one from the 3Delight native install and one under DAZStudio4/bin - I guess the native one wouldn't be able to resolve the wine prefix pathnames any better, so studio4 it is.
Yup, that works (once at least), I think I've run into that 'won't output more than one rib file' bug. I couldn't get it to do another rib so I could test a few scene changes....the unscripted one with collect needs the pre-existing files to not exist, I tried that and leaving cleared files with 'touch'.
Could very well be - it's a staple on Windows, so we can't expect WINE to magically solve it.
In theory, you could generate RIBs with the vanilla render tab and then text-replace the vanilla headers with better headers generated by the scripted renderer.
Forgive me wowie and Kettu for being a bit slow
, so the shadows will be projected from a (fixed?) environment map? So you will have to adjust the HDRI to look like it's the source? So it's basically a hack?
Yeah I guess I could use that
Not a hack. Just a different way of doing things. You can do HDRI lookups directly in the code, without putting that map on an environment sphere - you just need to specify the right coordinate system. Then you can trace environment shadows very easily.
As of now, aweSurface does not do this direct lookup. It traces the map applied on a sphere.
So in order to match the lighting and shadow directions, you need to use the same map on the sphere and in the catcher, and rotate the sphere to match the coordinate system.
It might be possible to write a "sky rotation" widget to manipulate custom coordinate systems in the scripted renderer, but. In all honesty, it's basically uncharted territory development-wise, so it will take time and may be buggy. It's way easier to use a sphere, lock it, and if you want a different lighting angle, rotate the whole scene.
Kinda like in real-world =)
No, all Wine does is intercept Windows system calls and converts them to 'Linux equivalents. The only magical fix is if the bug is on the windows system side. It's using the same frameworks, so a programming bug is a programming bug otherwise.
Might have to look into that if I want to continue using Awe shaders. The Windows 3Delight renderer is ok for small files and simple scenes, but struggles on bigger, and since Daz 4.10.123 (or such), Studio only loads 1 time out of 4 without crashing, so a reload to get around it is not a workable solution for me.
Ok, tks:) Sounds like it could be useful=)
After testing, I found a round about message passing didn't work. Having the light 'pass' the map to surface shaders, both AWE Surface and the environment sphere shader does. As for the lookup, I think doing it with the old fashioned environment () may be possible and directly avoids the coordinate systems differences between 3delight/Maya and DS.
Even if this works, the drawback is that texture offsets on the sphere will not be passed to the shaders applied to everything else but the sphere.
I think you still need a DS-like coordsys for environment(). The example in the manual transforms the surface normal to world space. The default space is "current", which is the camera space => will move...
/* Do an env lookup */ vector Nf = faceforward( N, I ); color c = environment( "env.tdl", vtransform("world", Nf) ); /* Only fetch the alpha channel, if no alpha present, returns 1 */ float red_comp = environment( "env.tdl"[3], Nf, "fill", 1 );So would this shadowcatcher also work with PT arealights?
Nevermind, I forgot you cannot use a backdrop with scripted pathtracing
A backdrop like a 2D picture in the viewport? Cannot, and shouldn't. Whatever you're rendering with. I know some people say it's the easy way to add backgrounds, but DS is not a proper compositing app. Your total output will suffer in terms of quality.
But my shadowcatcher of course works with PT area lights. It's what it works with, PT area lights and HDRI maps.
Tks,great=)
Yeah, but we can do some 'creative' things with the Nf vector. Create a copy, do some matrix transforms and pass that instead of the actual Nf. Haven't tried it yet, so it may work or it may not.
Hmm, not entirely true.
At least not using the environment tab/DS viewport. But you can have a backdrop color/texture on the camera via an imager shader. Technically, DAZ Studio can actually have the viewport background serve as a backdrop on renders, since there's some imager shader trickery under the hood. But they don't/didn't implement the proper u/v transforms to get textures properly aligned to the render output.
It may even be possible to have DS calculate the proper world space vectors so you can use a HDRI as a background and have it oriented properly when you look around the scene. I was browsing the old DS3 scripting API docs a few days back and there's some world space vectors stuff in the API.
But sorry, I don't plan on working on that.
This is the what I have right now. The imager background color/texture won't show up if you have an environment sphere. I simply disable the camera visibility of the sphere in that shot. While it doesn't support HDRI as environment maps, you can use simple texture backgrounds or maybe some gradient stuff.
Already have this working.
Took the liberty to add both horizontal and vertical offsets, so you can actually move the vignet around the image if you want to. The third and fourth render are done with the scripted renderer. So yes, you can have a backdrop with scripted rendering (and a whole lot more).
As for should or shouldn't, I leave it to users.
Like, warranty void if removed? =P
I'd say that for a step towards actual quality compositing, you need colour correction controls on the backdrop. Or are they all in the "Colour" group?