Blender 2.8 render crashes (EEVEE/Cycles), rigid body baking crashes, Alembic export crashes (Blender Bug) #403
Comments
|
This issue may have been solved and the fix may also prevent the Cycles render crashes in Blender 2.79 as well! EEVEE has been successfully rendering thousands of frames without a crash while using the viewport. The culprit seems to be the way we transferred materials an smooth shading from the previous mesh to the next frame mesh. I am not entirely sure why the following fixes work, but changing either to the original method would consistently result in a crash: Material TransferCaused Crashes: for m in src_mesh_data.materials:
dst_mesh_data.materials.append(m)No Crashes: material_names = []
for m in src_mesh_data.materials:
material_names.append(m.name)
for name in material_names:
for m in bpy.data.materials:
if m.name == name:
dst_mesh_data.materials.append(m)
breakSmooth Shading TransferCaused Crashes: for p in mesh_data.polygons:
p.use_smooth = TrueNo Crashes: values = [True] * len(mesh_data.polygons)
mesh_data.polygons.foreach_set("use_smooth", values)Feedback from users will be needed to determine if this fixes the issue or if render crashes still persist. |
rlguy
changed the title
rlguy
changed the title
|
Blender 2.80 seems to crash more frequently when rendering scenes created in Blender 2.79 (Such as example scenes). Locking the interface during render seems to prevent these crashes (Blender > Render > Lock Interface). |
|
I have created a simplified script that reproduces the EEVEE render crashing issue. This causes a crash in Blender 2.80 but not in Blender 2.79. I'll submit a report to the Blender developers perhaps tomorrow once I double check the script and check that this issue has not already been filed. Script and Explanation:import bpy
"""
DESCRIPTION:
This simplified script reproduces a crash I am experiencing in an addon. The addon's function is to
load and render mesh geometry for each frame of an animation. The addon does this by creating a Blender
object, and on each frame swap out the object's mesh data with new geometry and then delete the old
mesh data.
The crash happens after after attempting to modify the object, such as by smooth shading the mesh data,
adding materials, or setting location/scale/matrix_world of the object. The more frequently the object is
modified, the more frequent the crashes.
This crash only happens while rendering. The crashes can be reliably prevented by locking the interface
(Blender > Render > Lock Interface).
TO REPRODUCE:
1. Open the .blend file
2. Press 'Run Script'
3. Begin rendering the animation
ERROR OUTPUT:
Error : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF7B09D5D85
Module : C:\\Users\\ryanl\\Downloads\\blender-2.80-d415b5c7b85-win64\\blender-2.80.0-git.d415b5c7b85-windows64\\blender.exe
"""
def frame_change_pre(scene):
# The addon would load geometry from a file, but for a simplified test an icosphere works
vertices = [
(0.0000, 0.0000, -1.0000), (0.7236, -0.5257, -0.4472), (-0.2764, -0.8506, -0.4472), (-0.8944, 0.0000, -0.4472),
(-0.2764, 0.8506, -0.4472), (0.7236, 0.5257, -0.4472), (0.2764, -0.8506, 0.4472), (-0.7236, -0.5257, 0.4472),
(-0.7236, 0.5257, 0.4472), (0.2764, 0.8506, 0.4472), (0.8944, 0.0000, 0.4472), (0.0000, 0.0000, 1.0000)
]
triangles = [
(0, 1, 2), (1, 0, 5), (0, 2, 3), (0, 3, 4), (0, 4, 5), (1, 5, 10), (2, 1, 6), (3, 2, 7), (4, 3, 8), (5, 4, 9),
(1, 10, 6), (2, 6, 7), (3, 7, 8), (4, 8, 9), (5, 9, 10), (6, 10, 11), (7, 6, 11), (8, 7, 11), (9, 8, 11), (10, 9, 11)
]
# Create a new mesh with geometry
new_mesh_data = bpy.data.meshes.new("mesh_data" + str(scene.frame_current))
new_mesh_data.from_pydata(vertices, [], triangles)
# Swap the new mesh data and delete the old mesh data
mesh_cache = bpy.data.objects.get("mesh_cache")
old_mesh_data = mesh_cache.data
mesh_cache.data = new_mesh_data
bpy.data.meshes.remove(old_mesh_data)
# This is what causes the crash: the more frequently the mesh cache data is accessed, the more frequent the crash occurs.
# For a simplified test, we will repeatedly set smooth shading on the mesh data polygons. This also happens if setting the
# object location/scale/matrix_world, mesh data materials, and other data.
for i in range(1000):
for p in mesh_cache.data.polygons:
p.use_smooth = True
# Create a cache object to store the current frame mesh
mesh_cache_data = bpy.data.meshes.new("mesh_cache_data")
mesh_cache_data.from_pydata([], [], [])
mesh_cache_object = bpy.data.objects.new("mesh_cache", mesh_cache_data)
bpy.context.scene.collection.objects.link(mesh_cache_object)
bpy.app.handlers.frame_change_pre.append(frame_change_pre)Blend File Including ScriptTo Reproduce:
|
|
FWIW, I grabbed the experimental version of FLIP fluids today along with the latest build of Blender 2.80 64-bit for win10, THANK YOU for starting the work to get FLIP running in 2.80! While I can enable rendered mode in the viewport with Eevee I absolutely cannot render an animation and very rarely can I use F12 to render a single frame out of eevee. Full screen mode, locking the UI, and using the command-line to render all did not work for me. Cycles in 2.80 does work for viewport and animations, but only with the workarounds you suggested (fullscreen, locked UI, command line animation renders). I also confirmed that the "No Crashes" code changes you mentioned were seen on my system. So at least I can render with Cycles, but Eevee can't be used to render output files. |
|
Thanks for the feedback! We have had similar reports that some users are unable to render an animation or a single frame using F12 when trying the workarounds. At the moment there are many bugs related to Blender 2.80 render crashes on the Blender issue tracker. I'll be keeping an eye on the issue tracker and continue investigating this problem. It is possible that this issue could be caused by a Blender bug, a problem with our code, or a combination of both. A note about Cycles in 2.80: There is a Blender bug that will make it not possible to render dupliverts in Cycles, so this will affect whitewater rendering. Issue here: https://developer.blender.org/T58956 |
|
Just a quick update: It looks like I forgot to update this issue with a link to the Blender bug. It can be found here: https://developer.blender.org/T60094 The bug was recently aissigned earlier this week, so hopefully there will be a fix soon! |
rlguy
changed the title
|
This is happening for me, with whitewater particles DISABLED. Locking the interface stopped it from crashing on rendering. No idea why locking the interface fixed it but thanks @rlguy for the tip :) |
rlguy
changed the title
rlguy
changed the title
|
The Blender developers have fixed a different bug that caused baking a rigid body cache to fail if there was a FLIP Fluids domain in the scene: https://developer.blender.org/T60136 It looks like the issue detailed in this thread will also cause crashes when baking a rigid body cache, not just render crashes. I have added a note to let the developers know about this here: https://developer.blender.org/T60094#700781 |
|
Hello, what is the status of this issue? Blender released 2.80 RC1 and it'd be great to be able to render animation without crashing after 1 or 5 frames during rendering because FLIP Fluids meshes are present in the project. It makes almost impossible to render any animation in a reasonable time. |
|
I am quite disappointed that this bug has not been fixed yet and unfortunately we have not been able to provide a solution since the issue is within Blender and not the addon. The Blender developers planned to have all high priority bugs fixed by now, but at this point in time, the bug has not been fixed yet. Here is a timeline on the progress of this bug and everything that I know:
Commenting on the Blender issue thread could possibly show that there is an interest/desire for this bug to be fixed. |
|
Well... Too bad, I bought this plugin and it's pretty much useless because of this bug. It doesn't matter all plugin's mechanics work when I cannot render anything with it. I will report it to Blender dev team, you should poke them as well. The worst what can happen they deliberately ignored it because they wanted to reach the July release deadline and who knows how long we will wait for any other fixes when 2.80 is released after 4 years of development. Granted, when I reported a bug to them they managed to fix it within 48h when they got a blend file where the issue was present. |
|
The Blender bug was finally resolved two days ago. |
|
We have been working on testing and confirming the fix. Some API changes will be needed in the addon to support the fix in Blender 2.81. If we can fully confirm the fix and do not need to make any additional reports, a new version of the addon that is supported in Blender 2.81 will be made available during next week. |
rlguy
changed the title
|
Hey Everyone! A lot of questions over the weekend for how the update to fix this issue is going, so I'll add some info here for how this is progressing! I have been testing the recent fix in Blender 2.81 over the past few work days in order to confirm the fix. According to the Blender developers this fix is as stable as they can currently make it. A requirement for rendering a procedural mesh in Blender 2.81 is to lock the interface (Blender > Render > Lock Interface). See this comment from Sergey Sharybin for info on this fix. The addon will need to be updated to include some new Blender 2.81 API changes that are a part of the render crash fix. This is taking a bit longer than expected due to complications with confirming the fix and re-working the addon for the API update. We need to support Blender 2.79, 2.80, and 2.81, each of which have differences in the API. I want to make sure that we have a good code design to accommodate for the API differences between versions so that the code base can be easily maintained in the future. This task is my current focus and I will be taking a break from developing the force fields feature (#269) until I can integrate this fix into a new addon version. Here is the current progress on a few aspects of this bug fix. 1. Fluid Surface RenderingAfter much testing, it seems that crashes while rendering the FLIP Fluids surface has been completely fixed! Some of the Blender 2.81 API changes make fluid surface loading much simpler in code and also faster within the viewport. 2. Whitewater RenderingI have not yet been able to confirm the fix for whitewater rendering. The way we implement whitewater rendering (dupliverts) within the addon is not compatible with the 2.81 API changes to fix render crashes. This section of the addon needs to be largely reworked. So far I have tested a few designs, but have not yet been able to find a method that prevents render crashes completely. I may need to ask the Blender developers advice if I do not find a way to use the API to load whitewater. I'm sure I am just using the API incorrectly. In the worst case, I'll need to file another bug report if it turns out there is a bug in the API (let's hope not!). 3. Alembic ExportAlembic export of the surface mesh works great! Whitewater export will not work correctly until the whitewater rendering finds a solution. Note: as with Blender 2.79/2.80, a workaround of adding a modifier to the mesh is needed for Blender to recognize the mesh as animation. Details on this workaround here. 4. Crashes baking other Blender simulations (Rigid body, cloth)A side effect of the rendering bug is that baking other Blender simulations can result in a crash if a FLIP Fluids simulation is present in the scene. This aspect of the bug has not yet been tested. The whitewater rendering issue will need to find a solution before this can be fully tested. I know many of you are excited to use FLIP Fluids within Blender 2.80. Thank you for your patience as we update the addon for this huge fix! Let me know if you have any questions. I'll update this thread as the issue progresses. - Ryan |
|
Hey everyone, here's an update for how this fix is going! TL;DR: We have a proof-of-concept design for how to fix this issue. I am setting a deadline to release a new fixed version by September 27th. Progress SummaryI've received some helpful advice for how to properly use the API to prevent crashes during whitewater/duplivert rendering. I have created a minimal script as a design prototype (or proof-of-concept) for how the FLIP Fluids addon can handle whitewater playback and rendering without crashes. The prototype accounts for differences between Blender's 2.79/2.80/2.81 APIs and theoretically supports all features for whitewater rendering needed in the FLIP Fluids addon. It does not look like any additional bugs will need to be reported (good news!). While testing the design script today, it seems like the new methods are working quite well. I have only receieved crashes every few thousand frames compared to crashes every few frames using an older script. The design in this script is quite different from what is currently implemented in the FLIP Fluids addon. The render and mesh loading code within FLIP Fluids will need to be largely restructured. This isn't a huge task, but it also is not a small task. It will take a few days of coding to carefully implement and test. I will set a generous deadline to complete this task and release a new fixed version by September 27th (generous as in this is an overestimate for how long this should take). Proof-of-concept ScriptThe design script emulates how the FLIP Fluids addon can load, playback, and render whitewater meshes. The whitewater meshes are emulated by generating a random grid of particle locations. The particle rendering is emulated by generating a random object to be used as a duplivert child object. The script is compatible with Blender 2.79/2.80/2.81, but due to the issues in Blender 2.80, rendering with this script will still result in crashes. # Prototype design for FLIP Fluids whitewater rendering in Blender 2.79/2.80/2.81
#
# To use:
# 1. Open .blend file
# 2. press 'Run Script'
# 3. Playback timeline, render image, or render animation
#
import bpy, random
VIEWPORT_DUPLIVERTS = False # Set to True to display dupliverts in viewport
_IS_RENDERING = False # Internal variable, do not alter
# To emulate the whitewater particle cache, we will generate a random
# grid of vertices.
def generate_grid_geometry():
grid_vertices = []
grid_size = 45 + random.randint(0, 5)
for k in range(grid_size):
for j in range(grid_size):
for i in range(grid_size):
grid_vertices.append((i * 0.08, j * 0.08, k * 0.08))
return grid_vertices
# For the whitewater particle geometry, we'll use a randomly scaled icosphere.
def generate_icosphere_geometry():
scale = random.uniform(0.1, 0.2)
vertices = [
( 0.0000 * scale, 0.0000 * scale, -1.0000 * scale), ( 0.7236 * scale, -0.5257 * scale, -0.4472 * scale),
(-0.2764 * scale, -0.8506 * scale, -0.4472 * scale), (-0.8944 * scale, 0.0000 * scale, -0.4472 * scale),
(-0.2764 * scale, 0.8506 * scale, -0.4472 * scale), ( 0.7236 * scale, 0.5257 * scale, -0.4472 * scale),
( 0.2764 * scale, -0.8506 * scale, 0.4472 * scale), (-0.7236 * scale, -0.5257 * scale, 0.4472 * scale),
(-0.7236 * scale, 0.5257 * scale, 0.4472 * scale), ( 0.2764 * scale, 0.8506 * scale, 0.4472 * scale),
( 0.8944 * scale, 0.0000 * scale, 0.4472 * scale), ( 0.0000 * scale, 0.0000 * scale, 1.0000 * scale)
]
triangles = [
(0, 1, 2), (1, 0, 5), (0, 2, 3), (0, 3, 4), (0, 4, 5), (1, 5, 10), (2, 1, 6), (3, 2, 7), (4, 3, 8), (5, 4, 9),
(1, 10, 6), (2, 6, 7), (3, 7, 8), (4, 8, 9), (5, 9, 10), (6, 10, 11), (7, 6, 11), (8, 7, 11), (9, 8, 11), (10, 9, 11)
]
return vertices, triangles
def update_mesh_cache():
grid_vertices = generate_grid_geometry()
mesh_cache = bpy.data.objects.get("mesh_cache")
vcu_swap_object_mesh_data_geometry(mesh_cache, grid_vertices)
scale = random.uniform(0.5, 1.0)
offset = random.uniform(0.0, 1.0)
mesh_cache.scale = (scale, scale, scale)
mesh_cache.location = (offset, offset, offset)
def update_mesh_cache_instance_type():
instance_type = 'VERTS' if is_dupliverts_displayed() else 'NONE'
mesh_cache = bpy.data.objects.get("mesh_cache")
vcu_set_object_instance_type(mesh_cache, instance_type)
def update_duplivert_object():
vertices, triangles = generate_icosphere_geometry()
duplivert_object = bpy.data.objects.get("duplivert_object")
if duplivert_object is None:
create_new_duplivert_object()
duplivert_object = bpy.data.objects.get("duplivert_object")
vcu_swap_object_mesh_data_geometry(duplivert_object, vertices, triangles)
for p in duplivert_object.data.polygons:
p.use_smooth = True
scale = random.uniform(0.1, 0.35)
duplivert_object.parent = bpy.data.objects.get("mesh_cache")
duplivert_object.location = (0, 0, 0)
duplivert_object.scale[0] = scale
duplivert_object.scale[1] = scale
duplivert_object.scale[2] = scale
def create_new_mesh_cache_object():
print("Creating new mesh_cache object")
mesh_cache_data = bpy.data.meshes.new("mesh_cache_data")
mesh_cache_data.from_pydata([], [], [])
mesh_cache_object = bpy.data.objects.new("mesh_cache", mesh_cache_data)
vcu_link_object(mesh_cache_object)
def create_new_duplivert_object():
print("Creating new duplivert object")
duplivert_mesh_data = bpy.data.meshes.new("duplivert_mesh")
duplivert_mesh_data.from_pydata([], [], [])
duplivert_object = bpy.data.objects.new("duplivert_object", duplivert_mesh_data)
duplivert_object.parent = bpy.data.objects.get("mesh_cache")
vcu_link_object(duplivert_object)
def destroy_duplivert_object():
print("Destroying duplivert object")
duplivert_object = bpy.data.objects.get("duplivert_object")
mesh_data = duplivert_object.data
bpy.data.objects.remove(duplivert_object, do_unlink=True)
mesh_data.user_clear()
bpy.data.meshes.remove(mesh_data)
def is_dupliverts_displayed():
global _IS_RENDERING
global VIEWPORT_DUPLIVERTS
return _IS_RENDERING or VIEWPORT_DUPLIVERTS
### Version Compatibility Utils ###
def vcu_is_blender_28():
return bpy.app.version >= (2, 80, 0)
def vcu_is_blender_281():
return bpy.app.version >= (2, 81, 0)
def vcu_link_object(bl_object):
scene = bpy.context.scene
if vcu_is_blender_28():
scene.collection.objects.link(bl_object)
else:
scene.objects.link(bl_object)
def vcu_set_object_instance_type(bl_object, display_type):
if vcu_is_blender_28():
if bl_object.instance_type != display_type:
bl_object.instance_type = display_type
else:
if bl_object.dupli_type != display_type:
bl_object.dupli_type = display_type
def vcu_get_object_instance_type(bl_object):
if vcu_is_blender_28():
return bl_object.instance_type
else:
return bl_object.dupli_type
def vcu_swap_object_mesh_data_geometry(bl_object, vertices=[], triangles=[]):
if vcu_is_blender_281():
bl_object.data.clear_geometry()
bl_object.data.from_pydata(vertices, [], triangles)
else:
old_mesh_data = bl_object.data
new_mesh_data = bpy.data.meshes.new(old_mesh_data.name)
new_mesh_data.from_pydata(vertices, [], triangles)
bl_object.data = new_mesh_data
old_mesh_data.user_clear()
bpy.data.meshes.remove(old_mesh_data)
### Blender Python API Handlers ###
# This handler is called at the start of a render, before the first
# frame change.
# Any objects that need to be created/removed for the render should
# be done in this method to prevent crashes and incorrect rendering (in Blender 2.81).
def render_init(scene):
print("Render Init")
global _IS_RENDERING
_IS_RENDERING = True
duplivert_object = bpy.data.objects.get("duplivert_object")
if duplivert_object is None and is_dupliverts_displayed():
create_new_duplivert_object()
update_mesh_cache_instance_type()
# This handler is called at the end of a render and before the last
# frame change that updates the viewport to the original frame.
# Any objects that need to be removed for cleanup after a render should
# be done in this method to prevent crashes (in Blender 2.81).
def render_complete(scene):
print("Render Complete")
global _IS_RENDERING
_IS_RENDERING = False
duplivert_object = bpy.data.objects.get("duplivert_object")
if duplivert_object is not None and (not is_dupliverts_displayed()):
destroy_duplivert_object()
update_mesh_cache_instance_type()
# This handler is called when a render is cancelled and before the last frame
# change that updates the viewport to the original frame.
# If a render is canceled, the render_complete handler will not be called,
# so we just need to call render_complete from this method.
def render_cancel(scene):
print("Render Canceled")
render_complete(scene)
# This handler is called after the end of a frame change.
# During render, creating/removing new object during a frame change
# should not be done to prevent possible crashes (in Blender 2.81).
#
# Note: In Blender 2.79/2.80, creating/removing objects in this method
# is unavoidable. This will result in crashes in Blender 2.80 which
# is a known issue. This can cause crashes in Blender 2.79 which is
# also a known issue, but the crashes occur much less frequently.
def frame_change_post(scene):
print("Frame Change", scene.frame_current)
update_mesh_cache()
if is_dupliverts_displayed():
update_duplivert_object()
update_mesh_cache_instance_type()
### Main Script ###
mesh_cache = bpy.data.objects.get("mesh_cache")
if mesh_cache is None:
create_new_mesh_cache_object()
if render_init in bpy.app.handlers.render_init:
bpy.app.handlers.render_init.remove(render_init)
if render_complete in bpy.app.handlers.render_complete:
bpy.app.handlers.render_complete.remove(render_complete)
if render_cancel in bpy.app.handlers.render_cancel:
bpy.app.handlers.render_cancel.remove(render_cancel)
if frame_change_post in bpy.app.handlers.frame_change_post:
bpy.app.handlers.frame_change_post.remove(frame_change_post)
bpy.app.handlers.render_init.append(render_init)
bpy.app.handlers.render_complete.append(render_complete)
bpy.app.handlers.render_cancel.append(render_cancel)
bpy.app.handlers.frame_change_post.append(frame_change_post)Script + Blend FilesAttached are .blend files for testing that include the script. There are two .blend files contained in the .zip file:
whitewater_render_prototype_blend.zip How to use:
Looking forward to finally be able to fully use the FLIP Fluids addon in Blender 2.8x! Thank you for your patience. - Ryan |
|
Here's another progress update! TL;DR: Everything has been fixed! I will continue testing for the rest of the week and will release a new version of the addon on September 27th. I have restructured the addon render scripts to match the above design and have been running render tests over the past 4 days. Rendering in Blender 2.81 has been very stable during all of the render tests. There does not seem to be any issues with Alembic export or rigid/cloth simulation baking. At this point I would consider all of the issues related to this bug fixed in Blender 2.81. The restructuring also seems to make Blender 2.80 renders more stable, but crashes are still possible since 2.80 does not include the 2.81 bug fixes. There are a few small features and modifications I would like to add to the addon before releasing the next build. I will spend the rest of the week adding these changes while continuing render tests. I will release the next build on September 27th. Thank you for your patience! - Ryan |
|
Experimental version 9.0.6.1 is now available in the FLIP Fluids downloads! Release notes for this version can be found here. After a short period of public testing, we will add these fixes to a new stable version of the FLIP Fluids addon. Try it out! Please let us know if you notice any odd behaviour during render or playback. You may message us here, on the Blender Market, or at flip.fluids@gmail.com. Important Notes:
- Ryan |
|
FLIP Fluids version 1.0.6 is now available! This version includes fixes for these issues in Blender 2.81. Blender 2.81 is currently in Alpha and panned for release in November 2019. And just a reminder: the interface MUST be locked during render to prevent crashes in 2.81. You may do this by setting the Blender > Render > Lock Interface option, or automatically by activating the 'Enable Stable Rendering' operator in the FLIP Fluid Display Settings panel.
Closing this issue! |
|
Suggestion: Move the button that fixes the problem to the "Debug" section and enable it by default; I'm thinking that people who just experience this crash won't know it's got something to do with rendering or the viewport or the Display Settings and would maybe not expect the fix to be "hidden" there. |
|
Good suggestion! I think I'll automatically enable this upon creation of the domain. I'll add a popup warning as well if a render is started and the interface is unlocked. |
Blender Version (including hash): Blender 2.80 (d415b5c7b85)
FLIP Fluids Version: 9.0.5.1 (Experimental)
Operating System: Windows 10
CPU: Intel Core i7-7700 @ 3.60GHz
GFX: GTX 1070 8GB
RAM: 32GB
The FLIP Fluids addon is currently unable to render a frame in EEVEE without crashing (using F12). EEVEE rendering in the viewport appears stable. This seems to be related to this issue: https://github.com/rlguy/Blender-FLIP-Fluids/wiki/Scene-Troubleshooting#blender-often-crashes-suddenly-or-does-not-apply-transforms-while-rendering
A workaround that helps render stability is to lock the Blender interface during render (Blender > Render > Lock Interface).
Hoping to get to the bottom of this issue quickly!
The text was updated successfully, but these errors were encountered: