Cycles Development Updates

Ah, okay, yeah, I’m already using the white noise for that sort of thing, it just sounded like there was . . . more. Same with the Light Path node.

I happily use white noise to get up to 7 different (and ther could be more) variations for instances or islands. I combine it with color separation RGB and HSL to obtain 6 different values to feed ‘Hue saturation value’ nodes

I do 12 in a “Color.Useful Derivatives” node group:
RGB.R, RGB.G, RGB.B
HSV.S, HSV.V
HSL.S, HSL.L (same as BW)
Hue (same for HSL and HSL, the others are not).
Log HSV (SV), Log HSV (VS)
Log HSL (SL), Log HSL (LS)
Could also add any of them together for more. The Log functions are useful for deriving info from base color maps, but depending on what the channels contains will have to be manually normalized.

Attendees

  • Brecht Van Lommel (Blender)
  • Sergey Sharybin (Blender)
  • Weizhen Huang (Blender)
  • Lukas Stockner (Blender)
  • Nikita Sirgienko (Intel)
  • Patrick Mours (NVIDIA)

Notes

For 4.2

  • Decided to accept the performance impact on AMD/Intel Metal
    • The slowdown only happens on specific hardware, which developers have no access to.
  • High prio reports:
    • Cycles HIP-RT Memory leak #120702
      • Seems to be bug in the library
      • Fixed in the open source version, which 4.3 is switching to
      • For 4.2 wait for the possible NIP-RT update
    • Blender crashing when using metal renderer #122022
      • Michael Jones was looking into it
    • OpenImageDenoise CUTLASS error after rendering image #122584
      • All the crucial parts are fixed for 4.2
    • Illegal address error with OptiX OSL with specific materials #122779
      • Possibly a driver bug, Patrick is looking into it
      • Possibility is to accept it for 4.2 initial release, and either look into work-around later, or have a fix done from the driver side.
  • Release notes seems to be good

For 4.3

  • White point patch
    • All the current feedback has been addressed, needs the final review
    • Known limitation: no feedback when picking something that is not close to blackbody radiation
  • Compression of pre-compiled libraries has landed #123557
  • Diffuse roughness control for principled BSDF
    • Need review from the Cycles side. Weizhen and Sergey will take care of that
    • EEVEE side is done
  • Weizhen is looking into bug reports, solving long-standing issues
  • Brecht is updating Cycles standalone
    • The script cycles_commits_sync.py is in the blender.git repository
    • Takes a bit longer than usually, because of the Git-LFS changes
  • Brecht cleaned up the project workboard, so there is now a column for the near-term next tasks to tackle
  • Alaska is working on patch to remove Intel/AMD Metal codepaths. Sergey reviews, hopefully land soon
  • Volume phase functions #123532
    • NVidia paper looks very interesting
    • Lukas would love to have a review
    • Some preliminary feedback:
      • Add links to papers
      • Better explanation of what the new phase functions are on artistic level
      • Are the parameters good and friendly for artists?
      • How do you mix different lobes?
      • Replace current one with the new one?

Future:

  • Split principled BSDF node
    • Helps EEVEE parameters (the GLSL parameters limit)
    • Helps OSL to discard unused closures
    • Probably better be done on the render engine side (as opposite to the Blender side) since layering might be done differently by different engines
  • How to handle volumes
    • Best acceleration structure
    • Combine them or sample separately
    • Look into what the state of the art is
    • The meeting mainly raised this topic, needs further investigation
  • Multi-part EXR files #123727
    • Helps speeding up load of EXR in external software
    • Eventually Blender will also only load requires passes, so will help there as well
    • Implement as an option, or even by default
  • Nikita raised a discussion of solving technical debt
    • Would be good to tackle it shorter term, and not for Blender 8.0
    • Testing frameworks are available already, but some aspects of Blender/Cycles might be hard to unit test
    • Need to look into it, and make code easy to unit test
    • Sergey is very interested in this, but has limited time. Nikita might have time to look into it for the denoise device selection
    • In the longer term we should strive towards accepting new features with tests included
  • Another technical debt topic was splitting up CMakeLists.txt. Could help some on-going development
  • There is old-standing patch to rework CUDA kernel build to use separable compilation #119746
    • Is still something to look into, but needs development time and priority
  • Doing kernel compression for AoT Intel kernels is being investigated
11 Likes

Hi. I just noticed that the behavior of the volume in geometry differs depending on the method used, what should be the correct behavior? Example:

A scene with a cube, suzanne with a geometry node that creates spheres from its vertices in three ways: as instances of a sphere, those spheres with realized instances, and only the points that cycles renders as spheres. There is no world light, only a point light

-Instances

-Realized Instances

-Points

As you can see, there are differences between the instances and the realized instances, the points appear completely black. Then I added an hdri to see if it changed anything.

-Instances

-Realized Instances

-Points

Is this a bug or is it expected behavior?

1 Like

this is the test file

volume in geometry.blend (3.4 MB)

1 Like

No idea why instancing matters but for points I can tell you that what’s going on is that, for some reason, points are one-sided.
I.e. if you put the camera inside a point with large radius, it’ll just be rendered invisible in Cycles.
As a result, any material that relies on the backside (aka the inside) (i.e. refraction, translucency, SSS, volume) is likely gonna look wrong.
I hope that will be fixed someday

1 Like

Some insight for those who still insist Cycles has a long way to go to be seen as viable for realism.

This is not an isolated case either, with a lot of people making the case against the quality of CGI in today’s blockbuster movies despite hundreds of millions of dollars and the use of the best technology in the business. In a way, having the latest of everything in shading, lighting, and tonemapping alone is not going to get us there in the absence of more robust tools for texturing and detailing (such as polishing UDIM and finally bringing micro-displacement out of experimental).

4 Likes

I mean, I wouldn’t have put it there if there wasn’t a difference with using realized meshes, if you know why there is a difference in those two specific cases I would like to know.

yeah, I see the difference, I’m saying I do not know

So I don’t really think Cycles is incapable of “sufficient realism” or whatever, but I don’t see what such a claim has to do with this video either. It’s about authenticity vs. perfection, not really “realism”.

What is true is, that a lot of not so great looking results in Cycles come down to choices in the scene design, in terms of blocking, lighting, perspective, and, like, moths drawn to the light.
Well placed detail or intentional lack thereof can come a long way to improving results. It has nothing at all to do with Cycle’s raw performance though

7 Likes

Attendees

  • Sergey Sharybin (Blender)
  • Weizhen Huang (Blender)
  • Lukas Stockner (Blender)
  • Nikita Sirgienko (Intel)

Notes

For 4.2

  • Crashes when using Metal was fixed by Michael Jones
  • No updates on HIP-RT memory leak and OptiX OSL
    • The previous idea of accepting known issues for the original 4.2 with a bug fix via driver or corrective release is open.

For 4.3

  • Wehzhen and Alaska are looking into expanding test coverage
  • Light linking and volume fix was re-iterated
    • Fixes immediate studio requirements.
    • Does not work correctly for nested volumes (which is similar in 4.1).
    • More complete fix is in discussion.
  • There is a report about self-intersecting volume objects
    • Cycles does early exit from the volume
    • Should be possible to consider such configuration as a “union” operation over the mesh parts
  • Weizhen is looking into implementing stochastic noise paper
    • CPU might not benefit from it that much, as the code is vectorized, so current focus is GPU
    • There is measurable speedup, but the image looks more noisy
    • Possibly required a better RNG state. The team will check on how to implement it offline.
    • Bump mapping is wrong with stochastic noise

Various

  • Intel is looking into implementing kernel compression as a DPC++ feature.
  • The meeting went into a quick summary of papers from EGSR. There are some interesting ones, but maybe ot the highest priority.
    [/quote]
8 Likes

Haven’t seen any mention of ReSTIR for a while. Hope it hasn’t been abandoned. :worried:

I suppose it’s mostly bug fixing for 4.2 right now.

4 Likes

I hope they look into texture mipmapping in the near future. I’m having so much trouble at work right now because any mid to big scene isn’t possible to render on the GPU :frowning:

5 Likes

yeah proper texture and mesh streaming (meshlets/nanite) would unlock insane scene scales

6 Likes

Yep. I didn’t know what that was about until I tried it on Arnold. A UDIM with 100 tiles and textures in 8k, but the memory used in rendering was minimal, I was quite surprised. Only one of those textures in blender seemed to take 1gb in memory, imagine all the textures of UDIM.

3 Likes

Yeah, it is scary, we’re working on something pretty “simple” in terms of textures, the biggest one is 4K, but most textures are in 2K or even 1K for some props, and yet a scene like this is eating almost 8GB on render time :smiling_face_with_tear:

5 Likes

Make sure your grayscale images are truly single channel.

2 Likes

Will that really help? I tried once with one of the props but the difference in RAM use was minimal.

…Though now I wonder if maybe the image wasn’t really saved with a single channel… :thinking:

Yes it really does help. It’s 1/3rd the size of a standard RGB image and 1/4th the size of an RGBA image.

The image viewer in blender will tell you the depth and how many channels the image has.

Also make sure you are using the bit depth you actually need. Not setting them all to the max value just for fun.

If you are using adaptive subdivision that is also known to have horrible memory consumption for no good reason.

I know one guy is building an addon to automatically convert your scenes images for you. Forgot what it’s called. If I find it I’ll edit this message.

8 Likes