Cycles feedback

Archive User Feedback
952

The new anisotropic Random Walk appears to be roughly twice as strong as the old/fixed-radius one, Christensen-Burley and Eevee. Is this intended behaviour?

Subsurface Comparison
Subsurface Comparison1514×2064 262 KB

The top-left image is fixed-radius Random Walk with a 1.2cm radius (the physically correct scattering radius for skin). That’s what I’ve been using up to this point. Switching to the anisotropic version produces an overly-strong effect. Halving its radius brings it close to the old one but perhaps still slightly too strong, but doing so almost totally eliminates SSS in Eevee.

1 Like
953

Hey Brecht, thanks for your reply!

For our purposes, we never have use for the anti-aliased position pass, but I’d be interested to see if someone uses the anti-aliased pass in their workflow.

And as you said, the ideal would be the ability to configure filtering for every pass, but I understand that for 3.0 it’s a tall order with all the work on your plate with CyclesX re-write and merger! So for us, as you have proposed and in the case where no one is using the anti-aliased pass, changing the position pass to be aliased would be a great outcome for this situation.

954

Speaking of subsurface scattering, I believe that 3D tests should be done using photos of real objects as a reference, I downloaded some reference photos and I want to try in this way, otherwise the criticism becomes just a subjective evaluation guided by own taste.

SSS-ref
SSS-ref1133×1920 265 KB

10 Likes
955

Hi just the first test with Random Walk (Fixed Radius)
I think this first attempt is a good result for me, even without knowing the correct milk parameters.
Milk always has the same parameters in both images, one has only a light made with a mesh plane and the other is lighted with an HDRI Environment texture.

milk-glass_003
milk-glass_003400×800 207 KB
milk-glass_004
milk-glass_004400×800 30 KB

3 Likes
956

Not sure if it has been brought to the table already but,
why is the geometry being re-calculated again when we are hitting render from rendered view?

the geometry has already been calculated if in Rendered View is active,
why was it needed a second time on Final Render?

can’t CyclesX use data calculated by rendered view already?

957

I think some difference is expected. According to documentation:

Behaves similarly to Random Walk (Fixed Radius) but modulates the Radius based on the Color, Anisotropy, and IOR. This method thereby attempts to retain greater surface detail and color than Random Walk (Fixed Radius).

Although I’m seeing even bigger difference between different sss modes.
How exactly do you set the radius, since it has 3 components? Or do did you just use subsurface amount as a multiplier?

958

Yeah I’m using subsurface amount to modulate. Radius is left default (1.0, 0.2, 0.1) which is good enough for skin. Turning IOR up to 1.8-2.0 also brings the appearance closer to the others, but that’s not the correct IOR for skin (1.4). Changing anisotropy or color doesn’t seem to significantly affect the radius. I find it hard to believe that this is intended since I’m using physically correct values and all the other SS modes look correct except for the new one, which looks far too strong.

959

I don’t know the depths of how F12 cycles and viewport cycles work, but in case you have some hide difference between preview and final, the geometry recalculation should occur anyway

960

Blender prepare and store the scene for each render view / frame buffer individually which is a total waste of preparation time and memory. I understand that view dependent displacement should be individually tessellated and different geometry must be considered, but anything else should be shared. GPU memory is a bottleneck for many users and loading the scene and textures for each render view separately is a no go.

961

Yes,real reference materials are very helpful.
Here is a paper of measured volumetric materials with its scatter and absorption coefficients.Even HGreenstein phase is partly measured.

Most are fluids like milk etc.

btw i wonder why no SSS shader has a input mode for scatter and absorption coefficent values,like a volumetric shader?Since it is a kind of approximate volumetric scattering.I know its artisticly and for compartibility.But if you have a list of most common materials and its scatter and absorption values,it should be easy to calculate, since its all is still based on beer lamberts law.

1 Like
962

Yeah indeed that sounds bad :sweat_smile:

963

Isn’t that what the persistent data option is for?

1 Like
964

Persistent data keeps information from the previous “final render” to use in future “final renders”. However I do not believe it uses any information from the viewport render.

965

As others have pointed out there’s a few reasons:

  1. Geometry or modifiers are hidden in the viewport but not final render, or other way around. (This can be worked around with some code and could potentially become an optimization in the future?)
  2. Adaptive sub-division being calculated different depending on viewport size and location.

But I believe one of the main contributors is that the BVH used by Cycles in the viewport is different from the BVH used for final rendering. The BVH in the viewport is optimized to allow the user to modify the scene, plus it doesn’t calculated motion blur (at least not in it’s current state). The BVH used in the final render is optimized for speed and can be used to calculate motion blur.

1 Like
966

@slowburn
I agree with you, but we have the problem that with Random Walk in 3.0 many matrerials cannot be rendered “realistically”; this applies especially to translucent and (semi) transparent plastics, such as silicone, PVC etc…

As I described above, Random Walk (FR) fails when a light source is directly behind the object. In my previous examples (above) you can see this very well.

The light scattering and the light refraction at lamellas and profiles is not correct in Random walk, and thus extremely many materials cannot be represented correctly.

Blender 3.0 without the ability to create translucent/transparent plastics or similar materials would be completely useless. It’s like having a Lambroghini with a new 2000 hp engine, but no wheels, no brakes, and no windshields… ; )

Christensen-Burley mitigates the problem somewhat for the time being, because currently Christensen-Burley in 3.0 generates an extremely large amount of noise.
I need 10 times more samples with 3.0 to get a reasonably noise-free result than I did before with 2.93, and the render time is then also longer than with 2.93; this of course calls Cycles X into question!

Ultimately, however, we need an SSS shader algorithm that can represent all materials, but I suspect that won’t work with just random walk or random walk (FR).

The problem with SSS materials is that the angle of incidence and the angle of reflection are not the same, but change with density and depth. What works for stone, skin, milk etc. with random walk, unfortunately does not work with silicone, PVC, rubber, or even sugar (candies) or gelatin.

Even multi-layered car paint cannot be reproduced correctly enough with random walk in close-ups.

Perhaps we need something like Random Walk Translucent, which correctly represents the refraction and scattering of light in plastics, especially the glow at the ends of slats or profiles when a light source is next to or behind the object; here Random Walk fails completely.

I also assume that there must be a bug in RandomWalk (FR) at the moment, the shading (AO effect) is much too strong, and also the colors fade too much; like in your example in your bug report ⚓ T92374 Huge visual difference between SSS algorithms in Cycles
and in general there is no glow at the edges (slats etc…) here the light seems to be completely absorbed. It seems that this is the way random walk works, and that is why we need Christensen-Burley! (or something equivalent like Random Walk Translucent, which works better with Cycles X ) ; )

I strongly believe that Brecht and Sergey (or others) will find a way, also because they have to, but I think/fear that we won’t see it before 4.0…

967

The extra noise appears to come from limitations with how Christensen-Burley works within the feature set of Cycles-X and from a bug fix for Christensen-Burley that results in more noise. You can find mentions of this in the relavant commits:
https://developer.blender.org/rBS73a05ff9e83a31be34d32a92cd5fb4d17994e342
https://developer.blender.org/rBSa94343a8afcac5d6db09c8461e67ad1ba5a85d35

As for all your other comments talking about the limitaitons or issues of Random Walk and it’s comparison to other methods, I can not comment on them as I do not know enough about this area to comment.

968

@Pinus, improving Christensen-Burley to be able to render glowing materials as in your examples is just low priority for me, it was never designed for that and we’re not likely to change sampling algorithms to accommodate it.

There are other ways to render silicone, PVC, etc, but maybe not with the exact look that you got before. But the idea that it’s impossible to render these kinds of materials at all I don’t think is true. I can see pretty similar results for exampling adding principled BSDF + transparent BSDF, plus a principled volume shader inside, if you want that kind of non-physical effect where the material reflects more light than comes in.

Though I would suggest to apply an 50-80% reflective diffuse BSDF to your objects, make the lighting bright enough to get what you want, and then design your material. If you’re making your material glow to compensate for low lighting, that’s not what the rendering algorithms are optimized for.

4 Likes
969

I would also not forget that everything is moving towards a filmic based workflow, so it makes sense to me if newer shading algorithms are designed to work best with physically correct values for lights and correct values for the albedo of a material (with the exposure of the scene adjusted upwards for indoor scenes and sharply downward for outdoor scenes).

The old way of doing things was using far weaker lights to avoid burnout and then trying to compensate with tricks to improve realism (such as albedo values being much higher than they otherwise would). The filmic workflow really can only work at its best when everything in the scene conserves energy, but the nature of it means high albedo values can allow for some very bright materials without making them emissive to some extent.

970

@Alaska
thanks for the links, I already knew about Brecht’s comments. I suspect this may explain why Random Walk now does not render translucent plastics correctly:

However the previous logic (also in 2.93) was simply wrong, using a non-sensical view direction vector at the exit point.
We use an importance sampling weight estimate for the retro-reflection to try to better balance samples between the BSDF and BSSRDF.

Perhaps it would help if the “nonsensical view direction vector” could be transformed into a random walk “transucent” variant.

Unfortunately, I am not familiar enough with the complex matter, I can only make assumptions at the moment…

@brecht
it’s not about the glow, that’s a really nice side effect you can use creatively, I’m concerned about the refraction and scattering of light at the outer edges of slats or profiles (thin structures) when a lamp is behind the object, or to the side.

If you put a flashlight in the real world behind such a object made of translucent silicone etc. with profile/slats, then the light refracts/scatters at the ends of the slats or profile and makes them glow; and this is where Random Walk (FR) fails in 3.0

Please test this, you can also do this with a rectangular translucent pencil eraser; hold the lamp under it and then turn the block… (look at the edges)

Unfortunately, this effect cannot be reproduced with the method you described…

971

Could you take some photos of such objects with controlled lighting, that could be reproduced in Blender? Then it would be more clear what you are talking about.

Also if the glow at the ends is caused by total internal reflection, then that’s not something that sss algorithms could or should simulate.