It is also important to take a look at whether or not this bug can be reproduce in Master. I am personally able to reproduce it in master and the results resemble those found in these reports:
A fix I found is to add a “sub-division surface” modifier to the affected object. Preferably in “Simple” mode to maintain the shape of the object. Then increase the “sub-division surface” level until the issue goes away.
Feedback: Rendering a simple Scene 8000x8000 pixel using Auto-Tile (2048x2048) will crash Cycles-X on my Nvidia: GT-710. Reducing Tile-size to 1024x1024 an no crash will happen.
Even with default cube? Is your card 1GB or 2GB vRAM version? Out of memory would be to be expected in some scenes with that low amount of vRAM.
I’m not sure if Blender can detect vRAM card capacity and available vRAM on all OSs and with all cards. Perhaps in a future determination of the optimal tile size according to available vRAM it will be possible, so that this is not a setting that depends on the user: https://developer.blender.org/T87836
Hey is it a known bug that at the moment. i have a havy scene and i hit render. And it is rendereing but when it is finished the result is nothing? (black)
In master it works
Hi I did some tests and I noticed some differences, I understand that everything is under development, but I bring these differences to your attention.
This detail is rendered with Blender 2.93.4 LTS
and this is instead rendered with today’s build of Cycles-X
But there are other differences between the two renders as surely was know, one that is now no longer visible here is that in the Render window with the tiles rendering the square of the tile is visible after removing the noise. but not in the saved image
I have a GT-710 with 2GB vRAM version and it’s not the defaut cube.
I used the monkeyhead and added a few Area lights with a backgroundplane, nothing more
The problems in your blend file also occur without adaptive sampling if you switch the sampling pattern from “Sobol” to " Progressive Multi-Jitter" (which happens automatically when using adaptive sampling).
Hi. There is a bug with animated vertex colors from imported alembic file. I’ve import alembic sequence from c4d. There is just a cloner with cubes and animated field that affects rotation and color from black to white. As you can see in video, colors start to jump randomly on some cubes from black to white. This bug appears only in a cycles viewport render. In eevee/material preview mode and in f12 cycles render everything seems to be ok. I’ve tried in ordinary cycles (2.93) and everything works fine.
when baking, if the tile size is below than UV maps resolution the bake result will be just black image.
as example if UV resolution is 1024x1024 and tile size is 1024 or more, the bake result will apear, but when change tile size below 1024 like 1023 bake result will apear as black image.
this bug do not occur when tile size is turned off. also the blocky bake result still apear in this build.
im using cpu, intel i3 2328m with intel hd 3000 IGP
I have tried a number of renders of this and I cannot seem to reproduce it. Could you send some other details such as the build you are using and you setup. Also are you using the CPU or GPU to render? If the GPU could you try rendering with the CPU and see if you get the same result?
I can reproduce this problem with all the latest Buildbot builds on Linux and on Windows. CPU or GPU doesn’t matter, both look exactly the same.
Just tried it with “blender-3.0.0-alpha+cycles-x.8d25aeb6a631-linux.x86_64-release” and the problem is there.
We are planning to add path guiding, which can help automate this sort of thing.
We have a planned to do item to automatically decrease this kind of tile size for GPUs with less memory. For now it has to be done manually.
I’m not aware of any bugs in the very latest cycles-x like this, there have been various fixes related to this in the past week, but it’s possible there is some remaining issue we are not aware of.
We changed the light clamping algorithm, which can lead to brighter results like this.
We perform denoising on the individual tiles as they are finished, and then over the full image at the end to avoid artifacts at the tile borders. We have considered removing this intermediate denoising preview to improve performance and avoid confusion like this. It’s unclear to us what would be the best solution.
A .blend file to reproduce this would be good. It’s not fully clear from your description if this is specific to cycles-x, or also happens with cycles in master. Either way, it can be reported as a bug in the tracker.
Any plans on merging the texture cache branch or implementing something similar ? This is a mandatory feature for production scenes imo. I believe that the shorts done at the blender foundation doesn’t encounter this kind of limitation since they push the texturing capacities of blender very far ( and they are doing amazing stuff ! ) and don’t use much of external textures/ressources. But if you take a look at a more standard production scenes, like the Moana Island from Disney or the USD samples from Animal Logic, it has 150+ of gigabytes of texture files. Render this in Cycles and you will need 200go+ of ram. Unusable for most people.
I know that people might thinks that this is extreme case scenarios, but it is not. This is the kind of data you need to achieve the quality they are targeting, and many smaller studios/schools targets those kind quality.
Even on school short films you can have 40/50 4k udims textures, 8k displacement, etc… For the sole fact that Cycles doesn’t have any kind of texture mipmapping makes it unusable for many people as soon as they scales up their scenes/projects.
In testing, Cycles X doesn’t seem to reduce the additional memory allocated when F12 is pressed. I was hoping this might be reduced. For an example scene here, F12 jumps me from 24 GB post-load to over 60 GB in both 2.93 and 3.0; I don’t really understand why this happens and whether it’s according to design, or indicates a limitation/bug.
Which viewport mode do you use, reloading of the textures after Cycles rendering for EEVEE could be the culpit (don’t know if Cycles and Eevee can use the same cached texture data, but it didn’t look like this from what I’m seeing and reloading textures after rendering for another renderer could be the problem).
Viewport doesn’t matter here. The memory duplication (so to speak) is also seen in commandline operation of blender. Generally speaking, though, I’m in solid mode.
