They may be similar (I don’t really know how each implementation works) but adaptive subdivision in Cycles has been stuck as an experimental feature for years, is a memory black hole, and not very stable for animation. So only for performance and stability, it can’t be compared to Octane’s texture displacement.
1 Like
It’s not using Adaptive Subdivision and doesn’t subdivide the mesh in a traditional sense. At least not with normal polygons. It layers planes, streaks and some other magic. If you use a low texture resolution and zoom in really close, you can see how it works.
I use it for almost anything that needs detail in Octane. It has some limitations but there’s also Vertex Displacement (which is slower and uses more RAM).
Adaptive Subdivision in Cycles is great but you would need to dice the scene at subpixel level to get a similar level of detail (and your RAM would explode). Texture Displacement in Octane works perfect for ~90% of all cases. V-Ray has something similar as far as I know.
8 Likes
Oh…! So that’s it, Octane’s Vertex Displacement is the one that’s closer to Cycles Adaptive Subdivision, it makes sense now. When I tried Octane the first time I had a hard time with vertex displacement, it is indeed slower.
I thought texture displacement was just a more “refined” version of vertex displacement, thanks for the explanation!
1 Like
If you leave “Total 12” it will follow this as maximum value for all other bounces
Try incresing it to 25 then you’ll see
1 Like
512 is insanely high and should be enough even in this case. Although I would make a shader that switches to a simple green color after 10 or so transparent bounces, You won’t be able to tell the difference anyway.
Transparent bounces are not affected the total number. It even says so in the tooltip.
2 Likes
As a lighter, I would love to have a more “artistic” approach to the light parameters. I kinda like having the choice in LuxCore to choose between a “power” parameter or the good old “intensity/exposure”.
Also adding a “temperature” color would be great.
3 Likes
I’m aware this is fairly niche, but I think I would be really cool if the light path could have more outputs relating to the angle of certain rays, like the halfway vector or the angle of incidence etc…
As for angle of incidence, you have the Layer weight node, or even Fresnel node
About the half-way vector afaik cycles doesn’t have it. And anyway the node should also know what light to take into account (but it’s maybe possible using some vector math?)
But those effects are dependent on camera view, not just on the light rays. Maybe DHX refers to that.
You already have the temperature node. Otherwise I think there’s an addon that allows to control lights (and also cameras) through photography-like properties. Can’t remember the name, tho.
I’m trying to implement a new fresnel node but to it get to take into account microfacet, models I need the half-way vector because normals are only accurate for optically flat surfaces.
Maybe I’m stupid, but it looks like the principled BSDF uses the half-way vector to calculate its theta i term for its fresnel. Meaning its fresnel falloff looks attucurate at roughnesses above 0.
You won’t be able to implement anything using the halfway vector in non-closure node. H is only defined when you have both ingoing and outgoing vectors. At the time the shader graph is evaluated, only the view direction is known, but not the light or reflection directions. Only after the shader graph is flattened to closures, Cycles goes into light and BSDF sampling and knows the second vector.
For calculating a half-way vector you need a light direction vector, but currently there’s no node that provides it. Light direction is freely available in Cycles code tho. If you want to stick only to existing shader nodes, you can try to make a trickery trick and get a cos(L, H) from comparing a principled diffuse with roughness=0 and roughness=1. For more information check out function calculate_principled_diffuse_brdf() in bsdf_principled_diffuse.h
1 Like
Well since I am extremely unfamiliar with cycles code, I guess my new suggestion is to add the light vector to the light path node. Thanks for the help though:)
Can you also define L and H for me, thanks.
I do wish to see some speed and memory improvements around this particular issue. We have similar problems around setting up scene optimized plants, hair cards etc with Cycles.
1 Like
L - a unit vector from the point of incidence to a light source
V - a unit vector from the point of incidence to the camera
H = normalize(L+V) - the half-way vector from your question
2 Likes
Hey guys,
Do we have any info on when and how light passes are going to be implemented as render passes,
Even just separating GI and others light is a great start. As a VFX artist, it’s literally the only thing left in blender to make it production-ready for medium-sized VFX Shops. Would love to hear the current limitations and time frame for this.
2 Likes