- User Since
- Feb 2 2015, 7:31 PM (398 w, 6 d)
Jul 9 2022
Hello, I just wanted to inform you that it is possible that I think it is possible that some bug reports will be created even after this fix, but I don't know how to reproduce it in Blender.
Jan 10 2022
Jan 7 2022
It seems that the sync can be done with GPU_finish() instead of BLI_task_graph_work_and_wait(task_graph) or drw_mesh_batch_cache_check_available(task_graph, me).
Sep 24 2021
Finally, I tried to push my first patch in upbge but today I realized that it was still crashing in some scenes.
Sep 23 2021
Thanks very much @ everyone and @Ray molenkamp (LazyDodo) for the fix!
Sep 22 2021
Hi, no I haven't an helpful stacktrace.
Sep 12 2021
Sep 10 2021
This patch seems to prevent the crash:
Sep 9 2021
Sep 3 2021
Aug 9 2021
Yes, sorry I forgot to mention the number of frames. Actually it is variable but it always happen on my computer.
Another user on openVFX reported similar issue. I attach a test file with the code above:
Mar 3 2021
Hi, I noticed this commit is causing a performances regression in mr_elephant scene.
Maybe VOLUMETRIC_SHADOW_MAX_STEP can be limited during navigation and increased when image is static.
Feb 18 2021
Thanks for review and commit!
Feb 17 2021
Idk if it can help, but for this issue, i temporarly reverted changes done in eevee_effects.c to "fix" the issue in upbge. https://github.com/UPBGE/upbge/commit/e74f476c3ed50c7203f6e29cb8720d2f7155b704
Feb 15 2021
Feb 10 2021
Feb 9 2021
Sep 18 2020
Sep 11 2020
Aug 10 2020
Aug 8 2020
Jul 27 2020
Jul 2 2020
Jun 2 2020
Mar 17 2020
Quoted Text it involves more than that
yes, I didn't look at GHOST_WindowManager::removeWindow(), but it's true that there's often a check:
Mar 14 2020
Jan 8 2020
Nov 13 2019
Ok, thanks, I understand.
Nov 12 2019
Oct 25 2019
I close this since we can use ctrl + click and that it is more a design decision, and can be discussed another time.
Oct 15 2019
Oct 7 2019
Thanks for the commit : )
Oct 4 2019
(for the fun an image to test offscreens in 2.8 with bge. The image rendered is the same than what we currently see in the viewport... :) )
Aug 14 2019
Jul 22 2019
The issue mentionned by @Everton Schneider (eversimo) can be fixed with this:
I can't reproduce this bug anymore in last 2.8 master (22/07/2019). Can you confirm that this is solved and close this report if all is right for you @Mal Duffin (mal_cando) ? Thanks
Jul 20 2019
Yes, this change was intentional. Here was the commit: https://developer.blender.org/rB64acb70e7f0f92b667cfaa006c94b5b8f3b79c27 which explain the reason. I close this report as this is not a bug. Thanks for report though
With last master, I managed to render with a GTX 1080 on windows (it didn't crash). It took 1 min and 55 seconds. I'm not sure, but for big scenes, or scenes rendered with a very high resolution, I managed to avoid some crashes following this tutorial http://artificialflight.org/blog/2013/cycles-crash-cuda-tdr-error/ (create a TdrDelay DWORD key in regedit and set the value to 16). If you follow this tutorial, is this working for you?
I don't think it can be considered as a bug. TAB key has always been set to switch between edit mode and object mode, and a text object can't really be considered as a full text editor. Tabulations can be replaced with spaces eventually. As this is not a bug, and in order to try to keep the bug tracker with high priority tasks, I take the liberty to tag this report as invalid.
I didn't managed to reproduce this bug. Tested with GTX 1080 last drivers on windows 10
I don't know if bpy_traceback.c changed, or if python was updated since 2.79b.
Jul 18 2019
I just tested on windows. By default, openAL is selected on my computer and the sound plays normally. If I select SDL, the sound is not played whereas the sound is played both with openAL and SDL in 2.79b. When I replace 2.8 SDL2.dll with 2.79b SDL2.dll, the sound works correctly both with openAL and SDL in 2.8. Then it seems to come from SDL2 lib update in 2.8 I think
Jul 11 2019
I don't know if it can help but following this tutorial: http://artificialflight.org/blog/2013/cycles-crash-cuda-tdr-error/ , I managed to render very high quality pictures with EEVEE (even if the tuto concerns cycles). Increasing the timeout delay in regedit on windows might help, I'm not sure though. I think this is more a driver limitation than a blender bug (if increasing the delay solves the issue)
Jun 25 2019
I confirm this seems to be solved, then I close this (Add Action > Change status > Resolved > submit).
Jun 23 2019
I can't reproduce this bug in the last 2.8 master. Can you confirm @Roelf De Kock (kiemdoder) ? If this is fixed for you, you can close the bug report with add action > change status > resolved
Jun 7 2019
May 30 2019
Precision: It occurs only in 3D view
Ok, thanks, this is weird, I'm on windows 64 family edition with a french keyboard (AZERTY). This doesn't work for me, neither when I build, neither when I test on buildbot version. But if you can't reproduce that and if this is working for other users, this is not important. If other users have the same issue, this could be fixed later
May 27 2019
May 24 2019
I'm not sure but it can be related to track to constraint on the main camera. When I remove this constraint, it doesn't crash for me
May 9 2019
Apr 25 2019
Apr 16 2019
I join a .gif video to show before and after applying the patch on my computer:
Apr 15 2019
I can confirm an issue with delete bake action.
Apr 14 2019
Apr 4 2019
I closed this bug report as official bge is no longer maintained as far I know. I think this bug has been fixed by panzergame (Tristan Porteries) in some upbge versions, (upbge is a fork of Blender which has been developped since bge development stopped). I wanted to close all the tasks in the tracker where I was involved and related to bge to do some clean up. The bug might still be in blender 2.79, but I don't think it will be fixed
Mar 28 2019
Or maybe it is possible to force to go in object mode before F12 rendering
This concerns only cycles.
Mar 25 2019
I add a .diff between the 2 particle edit.c too if it can be useful:
I add test files here:
I'm not sure, but it seems there is something in cycles code which seems not in eevee's code:
Mar 23 2019
In fact I have warnings in the console:
I can't reproduce this bug in last 2.8 build. @Lucas Boutrot (thornydre) : Could you check with last buildbot from here: https://builder.blender.org/download/ and close the task (add action > change status) if this is working for you?
(changing objects selection state stops the cache from being created but the sims keeps running. I guess this is normal as the possibility to move selected objects during simulation has to be supported)
I can't reproduce the crash neither following the described steps (gxt 1080, windows 10 64, last blender master)
Mar 11 2019
Mar 8 2019
Note: The same bug has already been reported and fixed here: https://developer.blender.org/T56147 but it seems it happens again
I triage this as incomplete as there was no feedback from the user. I think it has been solved. At least I can't reproduce it on my computer in last 2.8. Feel free to reopen it if you can still reproduce it in last 2.8 master
Feb 21 2019
there is a similar issue here: https://developer.blender.org/T57698
I don't know if it can help but when we comment these lines :
there's a similar reported bug here: https://developer.blender.org/T59729 . I don't know if there is a way to merge the 2
Feb 17 2019
Feb 15 2019
I don't really know if there is still a bug. I note this commit from Clément Foucault as reference: https://developer.blender.org/rBb62d140be9319ec
Feb 14 2019
I can't reproduce the bug in last 2.8 master. I tested with several types of meshes. @Nikos Priniotakis (Nikos_prinio) : Can you test in last built from buildbot https://builder.blender.org/download/ and if this is working for you, can you change the bug status to resolved (Add Action > change status > resolved)? Thanks
I can't reproduce the bug in last 2.8 master. Can you confirm it is working for you too @Jo (p34k) in last 2.8 built from buildbot: https://builder.blender.org/download/ , and if it's working, can you change the status to resolved (Add Action >change status > resolved)? Thanks!
Feb 13 2019
This is surely not a proper fix but it is just meant to indicate to the depsgraph that if we're doing a rigidbody simulation, I guess before building particle system we have to sync object transformation with rigidbody object tranformation:
I can reproduce this bug.
Here is another test file:
I can't reproduce this crash in last 2.8 master. can you confirm it is working for you too @David (daviddomingues_) in last built from buildbot: https://builder.blender.org/download/ and change the status to resolved if this is working? (Add Action > change status > resolved)
Feb 12 2019
I change the status to resolved. Tell me if I do something wrong
Oh I didn't see that I can change status. I try to change the status to resolved then. Thanks for the feedback