Now we know if we don’t render our main characters it’s faster. That fact relieves me. Not sure how that affects scriptwriting but it’s worth trying. Computers are starting to meddle in production matters y’all
1 Like
Yes, the volumes are not working yet.
I would like to see the altered demofiles for the Cycles-x branch,
bcs I do find alot of speed regressions based on the standard demo files.
Doesnt has to mean much, ofc. 
Didnt tinker with new rendersettings.
Anyone else seen speed regressions from out-of-the-box demos, or is it just me?
Just in case.
Be careful when you test if you have GPU+CPU hybrid render enabled from prefrences, it doesn’t work yet for cycles-x branch. That is, even if you have GPU+CPU enabled from the preferences, if you use GPU compute device it will only use the GPU in cycles-x branch, but in the tests with official builds you will be using GPU+CPU.
1 Like
I noticed that it renders as a single tile now. What are the advantages of this?
Advantages: You don’t have to play with tile sizes, you get to see the entire frame sooner, more flexibility to mix in CPU or other devices into the mix without worrying about each device type having different tile sizes for optimum work distribution, it doesn’t seem slower than tiles so why not, and it matches expectations set by other known-fast renderers like octane.
Let’s see how this all goes! I think we’re gonna have to see how quickly it comes together but it’s awesome they already have those test scenes running on their prototype.
Sad that adaptive subdivision/micro displacement is going to miss the first release if I understood the question on stream correctly though. Hoping that glints can be part of the path guiding but a cursory glance at some research papers doesn’t mention it.
5 Likes
Make configuration simpler for the user. Tile size and optimal tiles size generated a lot of confusion throughout history.
It is not that they have simply removed Tiles settings, supposedly they have made optimal render times not depend on tile size anymore, and that it has the same performance with a single large tile.
2 Likes
I like that. I’ve always set Cycles to Progressive rendering mode anyway, as it offers a complete view from the start, and enables you to stop the rendering when you’re satisfied with the noise level.
4 Likes
My main concern is about vRAM usage. The smaller the tile size, the less use of vRAM. Apparently that in cycles-x branch has not changed, because the higher the output resolution of the render, the greater the use of vRAM while rendering. This can be a real problem for large output resolutions. If you have a card with not much vRAM you can save out of vRAM problem by selecting small tile sizes.
I’m not sure how we’re going to handle that yet.
5 Likes
Octane handles this by keeping the output image in system memory, I suspect that is what the Cycle devs will have to do as well. Kind of a “out-of-core” final image.
This is good news for sure, speed is one of the reasons I don’t use Cycles.
Jason
3 Likes
I like it. My thoughts:
- The spreadsheet editor is currently used to show previews for nodes (Only geometry for now, but I imagine shader and composite will eventually use it. The spreadsheet editor was originally planned to be used for everything)
- I think it might clutter the node editor (Won’t we want this for almost everything if we use it for map range? )
- Since we like to use concepts that are already implemented, I doubt that the devs will want to put the work into a preview on a specialized node.
My conclusion and possible solution:
Make a “Node viewer” mode for the graph editor that lets you view the enabled node. (similar to the spreadsheet editor) This would not only work for map range, but for more precise views of coloramps, color frequencies of textures, all the rgb curves at once, etc.
1 Like
I did a very quick test. Fast GI does indeed decrease the render time, though the results are quite different.
That said, it’s a rough test and I might be missing something about how the new Cycles works, hence some settings may affect the final look:
Rendered on a dual 1080ti
Fast GI on the left, 1min 59sec
Without Fast GI on the right, 3min 03sec (with min light bounces on it takes up to 4min 34sec).
Assuming I’m not overlooking any new setting, for comparison with 2.93 it takes 3min 08sec therefore without fast GI there isn’t much difference, but I understand this is a new branch, so things will be adjusted and finessed along the way.
4 Likes
I think multiple GPU rendering is not supported yet.
4 Likes
Even though I see the two GPUs under System/Devices?
I think so but I am not sure, maybe you can try to disable one card and check if the cycles-x render time changes
2 Likes
Fast GI has been in cycles for years just under the name Simplify AO
4 Likes
Strange, I think I did some renders with the Simplify AO in 2.93 with the same scene, I can’t seem to remember such a drastic change look-wise. I’ll do more tests.
I don’t understand why fast GI would affect the color temperature of your lights.
Fast GI works by replacing actual GI with AO. I forget if it uses solid white or the world background color, but it won’t take into account any local lights.
1 Like
It uses the world background. And it actually replace GI starting from the specified number of bounces. To avoid drastic changes usually 2 bounces are enough
4 Likes
With just one AO bounce the tint of light bounce off colored surfaces is greatly reduced, and I don’t think there is a workaround for that. If result is very dark with only Fast GI approximation values, you can enable Ambient Occlusion in World tab and play with Distance there which is the same value as AO Distance in Fast GI approximation item (starting tests with small distance values)
But as lsscpp have pointed out above it is probably best to use 1 only for fast viewport but render with a value of 2.