@slowburn, thanks for the example scene, the adaptive sampling is clearly not working well here. We’ll investigate why, it’s not immediately obvious.
To everyone else, let’s try to stay on topic of cycles-x here, how to use units or how best to set up lighting in a scene like this is not that relevant to the adaptive sampling problem.
ok my point is that there is something wrong when the lighting values are too high, this is another example: same scene, only changing the intensity of the lamps and exposure I get better results in less time because adaptive sampler works better
That’s an interesting workaround, but I couldn’t make it work in my scene. There’s just not enough light reaching the darkest corners even if I increase environment intensity to absurd amounts. Hopefully devs can find a way to make adaptivity work identically with any combination of exposure and light intensity.
No, not at all. The interior does look a bit small when you put the big guy from UE in there 
Speaking of Unreal Engine. Just out of curiosity…
UPDATE: As it turned out, I made a mistake during my last test. I had some unrelated assets and elements (out of sight or hidden) in the UE scene that affected path tracer’s performance. I had to do a new test with a clean scene and ‘unified’ lighting.
Scene and lighting: Glass removed, assets placed inside a box with inverted faces and assigned emissive material that is set to 50. The number of samples set to 300 and the number of bounces to 5:
Unreal Engine 4 / 5 bounces, 300 samples / 39 sec
Cycles X / 5 bounces, 300 samples / 62 sec
Unreal Engine 4 / 5 bounces, 100 samples, OIDN / 13 sec
Cycles X / 5 bounces, 100 samples, OIDN / 22 sec
Bonus: Unreal Engine 5 / Lumen / Realtime
Unreal Engine 4 / HDRI / 5 bounces, 300 samples / 70 sec
Cycles X / HDRI / 5 bounces, 300 samples / 70 sec
It’s quite surprising to see Cycles so much faster than Unreal’s new pathtracer. How did you light the scene in UE? Because if it’s just the environment with light coming through the windows (without portals), then UE will be at a disadvantage.
I did a mistake during my test and had to retest everything again. I updated the comment with new info and results. Sorry for inconvenience.
PS. Noticed some interesting behavior. When I use default world shader (background), it produces very noisy result even at 300 samples. But 3 area lights (one for each window) at 100 samples produce cleaner picture at a fraction of time:
Background shader / White color / Strength set to 50 / 50 sec:
3 x Area lights / White color / Power set to 175W / 26 sec
Use that rig: slightly tinted arealights only visible for diffuse, and world texture for the rest
I would guess it is probably because of importance sampling? Somehow the world shader doesn’t have as high importance as the area lights I think. Would it reduce the difference if you use potral lights on the windows?
Portals do help, but they just made the picture (range of pixels) brighter. Here is what it looks like:
Rendering time went up (+25s), but still not as clean as area lights.
You can achieve similar result by opening pic with area lights in PS, and moving the mid-point (levels) to ~1,5. You’ll end with the same brightness but with less noise.
bug at cycle x daily build 0a8a190c819a 2021-09-10 16:35 when use time limit at render properties.
worked cycle x version 2021-09-6 18:07 d8088307847c
hardware used:
cpu i3 2328m intel hd 3000
solved with:
also sometime blender not responding while rendering.
Looks like there’s something wrong with portal lights in Cycles-X. Here’s how it works in 3.0:
But in Cycles-X scene gets noticeably brighter. Noise doesn’t get that much better (it’s hard to tell) and rendertime is up by 15%.
In all tests environment is just a white color with strength of 10.
Is this a known issue?
More info…
Occurs in builds done on Sept 11 for Windows 10 64 bit (not Sept 10 and before). Blender is also far more likely to lock up when there is a lot of data in the scene being rendered (enough to bog down the drawing code) or when the adaptive sampling has led to much of the image no longer being sampled (which means very frequent updates, the lockup always occurs when the image is refreshed).
My guess is that it might be caused by the fix for the rendered image not showing up until render completion on Windows, that issue can be worked around by rendering in a separate window and making sure there’s nothing displayed in the window beforehand (the locking up cannot be worked around).
Or maybe because tile size feature is implemented on this build ?
Anyway did you realize at sept 11 build the default UI seems different ? Like missing Layout and geometry node workspace tab at the top and if you see into default camera view it seems the camera Shift toward upper right making the default cube seems toward bottom left.
I don’t know this is an UI bug or they gonna change UI for 3.0 . I haven’t test on master yet is this bug also occur.
Yeah there is indeed something wrong with the UI
The world shader is not using node by default
Not sure what’s happening
The cause for these issues with the UI is probably related to this: rBa00507c482e2
A change was made to the start up file and something was wrong with it. So it has been fixed with rB5e0684b07d25
The major issue is that only the first commit has been merged into Cycles-X. The second one has not been merged into Cycles-X, and once it is everything should return to normal.
Indeed, this should be fixed in the next build.
This should be fixed in the next build. Also increments in seconds instead of milliseconds now.
I have not been able to reproduce this bug yet, my portal test scenes do not show a discrepancy with/without portals so far. Brightness is intended to stay the same in any case. A test scene would be helpful (note this can also be very simple, if you want to share a more complete scene like for the adaptive sampling that’s fine, but it’s not needed).
This may be something I’m working on fixing, not sure if it’s the same thing.
https://developer.blender.org/D12468
Hello! I’m trying Cycle-X branch, compliled myself right now in Ubuntu and I’m experiencing something strange with SSS on a specific Eye model, that has two mesh island, the overall sphere is a singl island but the iris and pupil is that selected mesh island inside the sphere.
Edit:
You can check the .blend if you want.
Edit 02:
Tried in blender Master and I have the same “problem” with RandomWalk but with the ChristensenBurley it’s working like expected, not “revealing” the geometry inside.
Strange, I can always reproduce the bug. Here’s a simple scene for testing:
Thanks everyone involved.