AWE Shading Kit for DAZ Studio and 3delight

wowie

Sven Dullah said:

You're thinking simple fog I guess, not true volumetrics? 

As simple as it gets. Volumetrics effects probably needs ray marching. Still doable, but that needs a proper volume shader.

Sven Dullah

wowie said:

Sven Dullah said:

You're thinking simple fog I guess, not true volumetrics? 

As simple as it gets. Volumetrics effects probably needs ray marching. Still doable, but that needs a proper volume shader.

Would be totally awe-some, either way! 

Torquinox

wowie said:

Padone said:

@wowie @Sven Is there any reason one would use iray vs awe ?

I mean apart gpu rendering. If awe can do the same as the iray uber shader then 3delight may be even better than iray since 3delight supports micro displacement and mipmaps and motion blur that iray doesn't. This is not to criticize anything I'm genuinely curious since I know very little of awe and I'm wondering if it may be a valid modern solution that could compare to iray and cycles for example.

How is 3delight + awe with caustics ?

p.s. I know there's tons of docs about this, indeed it is because there's tons of docs that I'm looking for a more simple and quick answer. That may also be useful to anyone interested.

p.p.s. Just scrubbled a bit in the docs. Am I correct that there's no volume support ? How does awe with volumetric lights and objects ? edit. I now see there's the uber volume that I guess can work together with awe ?

I've sent you a PM of my rather long answer.

That's too bad. I am quite interested in that answer, even if it is rather long.

wowie

Torquinox said:

That's too bad. I am quite interested in that answer, even if it is rather long.

Sent what I wrote to your PM.

Padone

I was just waiting for the permission by @wowie to repost the PM. Here it is.

 

1. I'll answer the hardware stuff first though it may be off topic. GPU rendering in general can be faster, even much faster. But I'm not using any GPU renderer, until they have:

• a GPU (with a GPU renderer) that's at least 8x faster than a CPU
• costing under US$ 400 or less
• while consuming power below 150 watts
• all the while not dissipating excessive heat (something north of 80° C) or producing more than 32 db of noise

With my updated rig (Ryzen 5700G), I can render complete scenes in 720p somewhere around 12 min, while consuming less than 100 watts in a virtually noise-free environment. Sure, I can use faster CPU like a i9 12900K or Ryzen 5950X, but 12900K power consumption is way too high and I can't justify a GPU with a 5950X. Even a 3060 12 GB is something like 180 watts (GPU only) and roughly 4x my CPU (in Cycles).

In short, I'm heavily power limited. I can't really justify more than 250 watts for a single rendering machine.

2. 3Delight handle caustics just fine. Problem is I haven't look into using it with my stuff.

Here's the long winded answer.

3Delight handle caustics via photon mapping rather than brute force path tracing, so there will always be caveats associated with the method. Personally, I dislike the approach.

Now DAZ Studio's 3Delight is a whole different beast altogether. To get photon mapping to work, you'll need a photon emitter (usually either a camera or a light). None of the default light/camera has photon emitter support. That means a user will have to create their own light (or imager shader attached to the camera) via either Shader Builder or Shader Mixer. Then you need to setup your surface shaders to process the emitted photon maps via a specific RSL instructions (photonmap () or caustic ()).

I've only seen one tutorial all the way back in DS3 days from DAZ on how to actually do this and that's with a photon emitting camera. I've never been able to figure out how to properly do it with not just a light shader, but a path traced area light shader. I think I got it to work with a point/spot light shader at some point. Mustakettu have looked into this stuff earlier and further than me, feel free to ask her for more info.

3. Volumetrics not only doable, but I think generally 3delight's strong point.

Again, the problem is that requires user(s) to write/attach a volume shader to either a surface (for an object to have a volume), a light (for a volumetric light) or the camera (for volumetric fog effects). Just like photon mapping, I've simply haven't look into writing volume shaders for my stuff.

4. There are stuff I really like to have before doing all those stuff (like curvature support and camera effects). With the latest build done, I have looked into doing these. Camera effects will likely need a volume shader attached to the camera (rather than an imager shader).

Since you've brought up documentation - there's almost zero documentation of doing any of this stuff with 3Delight's path tracer. Most of the documentation available were in 3delight's forum (no longer easily accessible), the developer documentation or generic Renderman tutorials all over the internet. Unfortunately, 3Delight is more strict with shader writing. There are stuff that works with Renderman that's not easily transferrable to 3delight.

Sven Dullah

Tks Padone and wowie

Torquinox

wowie said:

Torquinox said:

That's too bad. I am quite interested in that answer, even if it is rather long.

Sent what I wrote to your PM.

Thank you! :) 

Torquinox

It would be very cool to see 3DL volumetrics working in DS.

I'm amazed Wowie does all he does with such stringent power restrictions. It seems the GPU manufacturers are going for more power consumption with likely higher cost.

My recent build based on an i5 12600k and Rog Strix 3060 stays whisper quiet and amazingly cool, even under load. I see max temps around 35C for GPU and CPU - It's nothing like the 85-90C that happened far too often in my old machine. Come to think of it, I'm surprised the old machine still runs when temperatures got so high. Noise was much louder, too. New machine does exceed Wowie's goals for cost and power consumption.

wowie

Rather quick and dirty test. Have an idea to add a switch to alter the output with height from the ground plane. Haven't quite work it out yet though. Also how it interacts with amount of light.

Sven Dullah

@wowie

Mann I would love to show you my appreciation, can't find you though on patreon or gumroad etc. Am I missing something? Or would you accept a gift card in a market place of your choice?

That "fog" test looks very promising, would make for excellent haze while keeping rendertimes reasonable!(?) Are you applying gamma diffuse offset as a function of distance?

Another one, made with an earlier awe build, used a simple fog cam to render the depth pass, in GIMP added as a "lighten only" layer. Probably tinted to a light blue-ish tone. (The pic was basically an ultra scatter test) 

wowie

Sven Dullah said:

@wowie

Mann I would love to show you my appreciation, can't find you though on patreon or gumroad etc. Am I missing something? Or would you accept a gift card in a market place of your choice?

I'll send you all the related info later via email.

That "fog" test looks very promising, would make for excellent haze while keeping rendertimes reasonable!(?)

It's just a pattern generation, I've not seen any render hit so far.

Are you applying gamma diffuse offset as a function of distance?

Going slightly technical. There's a power function so you can how the value ramp between near and far plane ramps up. Gamma is actually a power function too. There's also a cutoff so you can control where the ramp starts going above zero. Essentially an offset how far into the scene the effect starts. Plus the two color slots for the near and far plane. It might be possible to actually add texture to those too.

Another one, made with an earlier awe build, used a simple fog cam to render the depth pass, in GIMP added as a "lighten only" layer. Probably tinted to a light blue-ish tone. (The pic was basically an ultra scatter test)

OK. so lighten only basically adding values on dark values. I've got some ideas about what you'll be able to do (multiply, add etc).

Sven Dullah

wowie said:

OK. so lighten only basically adding values on dark values. I've got some ideas about what you'll be able to do (multiply, add etc).

Yes of course, I might have used a duplicate layer using also color data, screen or add. Can't wait...

wowie

Halfway there, I think.

Padone

@wowie Looks nice as a ground fog, can it use a texture ? I mean to animate some clouds for example.

wowie

Padone said:

@wowie Looks nice as a ground fog, can it use a texture ? I mean to animate some clouds for example.

Hmm, I'm not entirely sure what you mean?

It is possible to use a texture instead of just a solid color for the fog. Even separate textures for near/far values and have a blend for everything in between. I also think it is possible to have a procedural noise (likely something like fbm noise) instead or as a multiplier. Though I'm not really versed in doing noise mostly due to lazyness.

The only gotcha I see right now is how to uv the texture onto everything on the scene. I'll probably just use screen projected uv for textures. I will have to check and test to see if looks OK though. Doing it this way may look too flat.

kyoto kid

...need to keep up with this thread more regularly. Volumetrics?  That woudl be great The Iray volumetrics are resource hogs. 

Sven those test scenes with the pool table and room look  incredible. In the image with the 3 headed hydra and the one that you posted just above, did you use Terradome3 for the terrain? 

Sven Dullah

kyoto kid said:

Sven those test scenes with the pool table and room look  incredible. In the image with the 3 headed hydra and the one that you posted just above, did you use Terradome3 for the terrain? 

Tks kk! Nope, they are just high poly DS primitive planes. I used mCasuals "Elevate" script and painted height maps and scatter maps in GIMP.  For the surfaces I used free 8k PBR textures. 

Padone

@wowie Thank you for the explanation.

wowie

Padone said:

@wowie Thank you for the explanation.

After a bit of thinking, I think I might be able to work something out.

Its likely posible to come with a fog shader and a light control (i'm thinking of a point light) that you can animate to control the fog shader. Kinda similar to AoA light flagging scheme. but the lights don't actually emit light or shadows. By animating the light or its properties, you'll be able the amount of fog or maybe how high it goes above the ground.

Sven Dullah

wowie said:

Padone said:

@wowie Thank you for the explanation.

After a bit of thinking, I think I might be able to work something out.

Its likely posible to come with a fog shader and a light control (i'm thinking of a point light) that you can animate to control the fog shader. Kinda similar to AoA light flagging scheme. but the lights don't actually emit light or shadows. By animating the light or its properties, you'll be able the amount of fog or maybe how high it goes above the ground.

 

Padone

@wowie Sounds great .. would be nice to have animated fog/clouds spreading around the scene for 3delight. In blender we use animated procedural textures with the principled volume shader, that's why I asked about textures.

wowie

OK, settled with a screen projected texture. I haven't written the proper uv tiling yet so right now though.

Seems to work quite well when the texture have some blur applied. Interesting effect when I blur the texture along depth.

wowie

So, I did something rather stupid and re-installed Windows. Unfortunately, wiping out the souce codes of the current build. Thankfully, I've made backups for most shaders, though I haven't made a backup of the fog shader.

Anyway, been working on a new build based of a backup of an older one. Just finished doing leftover cleanup, so time for some render tests..

I still need to check how it renders with newer DS builds and update the other shaders. Obviously, it'll produce slight different render than the current build since I learned a thing or two (and mostly forgot how I did some other).

Torquinox

Sorry you had the misfortune. Renders look impressive, though bump is a bit too strong for my taste. Skin bump is often a problem, anyway. No easy, one-size-fits-all fix.

Padone

In the daz uber shader the bump depends on the pixel density, that's awful if you ask me and can't imagine what kind of twisted reason the daz team had when implemented it. That's why a different bump is used for every part of the figure to make them match, and also why iray doesn't convert fine the 3dl bumps.

At diffeo we managed to convert this to blender, stills awful.

https://bitbucket.org/Diffeomorphic/import_daz/issues/433/lets-bump-it-right

So, if awe uses the iray textures, the bump will be affected as well and needs to be fixed for the various figure parts. Unless in awe the bump depends on the pixel density as well.

wowie

Padone said:

In the daz uber shader the bump depends on the pixel density, that's awful if you ask me and can't imagine what kind of twisted reason the daz team had when implemented it. That's why a different bump is used for every part of the figure to make them match, and also why iray doesn't convert fine the 3dl bumps.

At diffeo we managed to convert this to blender, stills awful.

https://bitbucket.org/Diffeomorphic/import_daz/issues/433/lets-bump-it-right

So, if awe uses the iray textures, the bump will be affected as well and needs to be fixed for the various figure parts. Unless in awe the bump depends on the pixel density as well.

Bump code is pretty much the same for all Renderman/3delight shaders.

They probably did it to break up the specular highlights/reflection. What should be done is something like Pixar's bump2roughness.

https://rmanwiki.pixar.com/display/REN24/PxrBumpRoughness

Here's a more detail explanation of the approach

https://github.com/bram0101/Bump2Roughness

 

Padone

@wowie I mean that you can't use the iray bump textures in 3delight without converting the bump values by the pixel density. The same as we do for blender. Then mipmapping has nothing to do with this iray doesn't use mipmapping. Unless I misunderstand what you're pointing out.

For pixel density I mean the pixel density of the texture on the geometry surface, that depends on uv-mapping. Not the pixel density of the sceen, that may be fixed by mipmapping + bump2roughness. If you read #433 at diffeo linked above it's explained better.

Torquinox

Padone said:

In the daz uber shader the bump depends on the pixel density, that's awful if you ask me and can't imagine what kind of twisted reason the daz team had when implemented it. That's why a different bump is used for every part of the figure to make them match, and also why iray doesn't convert fine the 3dl bumps.

At diffeo we managed to convert this to blender, stills awful.

https://bitbucket.org/Diffeomorphic/import_daz/issues/433/lets-bump-it-right

So, if awe uses the iray textures, the bump will be affected as well and needs to be fixed for the various figure parts. Unless in awe the bump depends on the pixel density as well.

I'm not sure Iunderstand what you're saying. IME, pixel density affects the appearance of aliasing in a bump map. Too much bump height exacerbates the appearance of aliasing. Bump height is governed by the grayscale value of each pixel with black (0) being strong negative bump and white (255) being strong positive bump. The 0-50 bump scale referenced in the uber shader document is a multiplier, it seems. THe real problem is, if the pixel density changes between two material zones and it's supposed to be a continuous material, that could create a defect in the way it looks. One would have likely to do something to blend the edges. Normal mapping can sometimes help with how bumps look. Pixel density changes will still be a problem. and skin is weird! As a surface, it has a lot going on. What am I missing?   

jestmart

Black is only negative if you set the minimum bump value to a negative value.

Torquinox

jestmart said:

Black is only negative if you set the minimum bump value to a negative value.

I think that's software dependent actually. Or perhaps a practice issue? I've always treated 128 as base with lighter and darker becoming higher and lower. I see that a lot in existing bump maps, as well.