- User Since
- Dec 10 2018, 5:22 PM (184 w, 5 d)
Tue, May 31
It seems my new card is keeping these issues at bay for now. Although sometimes there's some unexpected slow down and it can take a lot of re-starting Blender to get a render to actually work. I do have a question though that I'm struggling to find a definitive answer to. If I bought a 2nd RTX 3060, would Blender definitely make use of it? or does it just cap at one card's memory? I gather the 3090s though have the technology to link up, but that aside? I used to have regular crashes while using two 1070s which would be instantly remedied by turning one of them off. Hard to get solid info in this area.
May 26 2022
ah dang. I can't reproduce it any more. Might have to just write this off. I reproduced it twice and now I can't.
here you go
Confirmed that it does it repeatably in my current scene with seemingly any two objects. The objects are likely part of a collection that has been instanced. Can also confirm it doesn't happen in 3.1.2
May 25 2022
ok, I've more or less finished working on that last file now so I'll pick things back up when my next scene starts bugging.
May 23 2022
does Blender automatically store crash logs? I can't seem to find mine. I thought you had to run blender in a certain mode. I looked up files from the link but just found two empty folders.
just an insta-crash. Happens while moving/editing objects while viewport is rendering in cycles.
Now I get flash crashes. But that's fairly standard.
update: ah, I forgot that Blender doesn't like dual GPUs. That said, if I use just one GPU I get this error:
Feb 22 2022
This is still present in 3.0.1
renders in cycles but, in Eevee, an imported vdb file turns off volume fog (when applied to a cube with principled volume shader applied).
Bit of an update, which may have resolved the issue. I applied the scale of the cubes and now, in cycles, they appear to be working simultaneously. So I still think this is a bug but one related to scale perhaps?
Feb 21 2022
Sep 15 2021
Sep 14 2021
Apr 13 2021
not really, it's about 1GB and would be a pain to transfer. It's full of messy geometry that went from Oculus Medium, decimated, then to 3d Coat, up-scaled, then decimated again. So high denisty geometry and the scene was probably just too much for little Blender to handle. It's very keen on crashing with heavy scenes I find.
Update. I went through and cleared all custom normals. Set everything to smooth, removed auto smooth and deleted any double verts. Still crashed but I no longer had the normals error in the previous debug...
Apr 12 2021
Apr 9 2021
Not sure if I've sent a video of the issue before but here's a video of me scaling a vdb file and like a dimmer switch, it's scale is directly affecting the cube of volume in the scene. (the cube just has a standard volumetric shader to give it some atmos).
any news on this issue? can confirm it's still doing it in 2.92.0
Would appreciate someone helping me work through this. I've just permanently broke a scene that I've been working on for a few weeks because I imported a VDB file and it's stopping normal volumetrics from working at all.
Mar 25 2021
It does look similar to aspects of both of those. Such a shame as I use volumetrics in just about every scene. There's always high levels of noise alongside the blocky issue. Has there been any progress with the issue?
Mar 21 2021
Another quick note. The problem is greatly exaggerated at higher render sizes.
Mar 20 2021
Mar 16 2021
This is still an issue in 2021. But I do note the workaround.
Feb 2 2021
Update: if you start off with a bez curve (shift+A, Curve, Bezier) and use your shape as a bevel profile, this error does not occur. It's only when you create a circle privative (and either leave it as a circle or edit the shape of the circle) and bevel that.
Jan 20 2021
sorry I deleted it. I'll try again next time it happens.
Jan 11 2021
Any theories? I see other issues with dds textures here: https://developer.blender.org/T64758
Jan 9 2021
Ok here we go. The dds file format seems to not be friendly in general. I can't open this kind of file in Photoshop. So likely Blender isn't happy either.
Update: I realised I had to delete the materials too, as that's where the problem lies. Now I can render again. Will see if I can drill down any more on the material. It's probably something to do with the image texture used.
edit: sorry, just saw your response. I'll see what I can do.
Watch the attached video. Open the new Blender file and do what I do in the video. I've attached the vdb file. Essentially import the vdb cloud file, add the default volumetric shader and then scale it up and down and watch the density of the large cube's volumetric shader go in and out in proportion to the vdb file. It's a scaling issue of some kind related to some aspect of certain vdb files.
I uploaded a video to show how it looks for me. Unfortunately the audio didn't capture but if you just re-read what I said above it's about as precise as it needs to be. In the video I open the file, note that there's nothing visible in the scene because the fog density of the shader (that's applied to a cube encompassing the scene) is set to 1.0. I unhide the vdb file and it erroneously causes the fog density to change, so now, once the vdb file is unhidden, we CAN see the scene. However, the density has not changed from 1.0. At the end of the video I re-load the file and it's still broken (the volumetric fog is neither 0 or 1, it's somewhere in between). You have to restart Blender to fix it. Using Eevee.
Try this. There's a cube in the scene with fog density set to 1.0 so you can't see anything. Look in the scene collections for the vdb file which is currently hidden. Unhide it and the fog will reduce in density visibly but will still be at 1.0
Jan 8 2021
Dec 4 2020
and it just did it again, so it's not a one off.
Dec 3 2020
Nov 19 2020
ok, thanks for all the info. Sorry if I'm unable to devote more time to it, I just get really busy. But I think in future I'll try to keep texture sizes as small as possible and see if that helps.
Nov 12 2020
So I can confirm that the GPU is being used as per the check you mentioned in the Task manager. So that's cool.
Nov 10 2020
Quick question while I look through debug logs. Is it fairly normal for the text file to be hundreds of megabytes?
Think this might be relevant too. Sorry. I'm crashing so many times I'm not sure if all these text files relate to the same crash. I think they do.
Not sure what the above means but it crashed again. Although I will say that I didn't start Blender with the blender_debug_gpu.cmd, I started it with blender_debug_log.cmd because I was expecting a non-gpu related crash. But just in case, here are the files (this is 2.90.1):
Nov 9 2020
Just had another crash in 2.90 and wanted to run the logs past you just in case it was something different. I felt like this scene should have been a bit more stable for some reason. Crashed while activating cycles in viewport.
Nov 3 2020
Do you think it's worth maybe saving incrementally and noting any new assets imported between increments? I have this happen all the time and if I had to guess, I'd say it was after importing a model.
My system doesn't save those files for some reason.
Nov 2 2020
usually this is resolved by restarting Blender. It's rendering again but the big issue is that it's just not using the GPU. I can select it and when it renders, the RAM is maxed out and GPU is around 0% and renders take 10 x as long.
been trying to get it to crash but it won't. But I do get this:
Nov 1 2020
oh, never mind, that was my confusion. I did test on 2.91 as instructed. I just thought that 2.91 was now released, so I tried on 2.90.1 this time. So yeah to confirm, I had also tested on 2.91 and it still crashed.
just a quick update. Downloaded the 2.90.1 official release and upon clicking the cycles viewport render it insta-crashed.
Oct 25 2020
Sorry I was really busy. Uploaded the log files but there isn't anything under: C:\Users\[your username]\AppData\Local\Temp\[project name].crash.txt
Oct 20 2020
Confirmed that it also crashes in 2.91 alpha both in viewport and regular render window. Rendering fine in 2.83. Just to emphasize, my scene was rendering fine for a good while, it just suddenly stopped being able to. But I have had a few random and sudden crashes during rendering in 2.9x
Oct 19 2020
**Confirmed that it does render ok in 2.83
Aug 29 2020
Jul 19 2020
Just to add some other examples of this bug. You can see the squares in the mist pass and then in another scene (circled in red) it's very subtle. Then I added some water (test002c) and you could faintly see the squares so I put some emission on the vdb just to really highlight the problem. Then I added a cube just to see if it was the water that was the issue (test002d) and what's odd is that I didn't touch the settings on the vdb material but it looks way different. The water is a cube with some volumetrics added. Let me know if you want the Blender file.
Jun 26 2020
Update: I can confirm that closing Blender and re-opening it fixes the initial undo issue, but need to check that it doesn't come back as I've generally had weird issues with the undo function over the last few days.
Also worth noting with my current Blender setup is that I can't undo camera moves using CTRL+SHIFT+Z, nor does the global undo work for this. Just mention because it's undo-realted.