blender/blender-addons
19
43
Fork 96
Code Issues 627 Pull Requests 27 Projects 1 Releases Wiki Activity

Render crash when using Python API to modify object data in frame_change_pre handler #60094

New Issue
Closed
opened 2019-01-03 00:27:43 +01:00 by Ryan Guy · 77 comments
Ryan Guy commented 2019-01-03 00:27:43 +01:00
Copy Link

System Information
Operating system: Windows 10 Home
Graphics card: GTX 1070 8GB

Blender Version
Broken: 2.80, .4dd0a90f4213, 2019-01-01
Worked: 2.79b release

Short description of error

Blender crashes while rendering and animation when object data is modified inside the frame_change_pre handler using the Python API. The crashes only seem to occur while rendering and not during playback. The frequency of crashes seems to be related to the frequency at which the object data is modified.

This is part of an addon that reads and renders geometry data from a sequence of files. 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 geometry. I have a created a simplified script that reproduces this crash within the first few frames of rendering:

import bpy


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)

This is the error Blender reports (EXCEPTION_ACCESS_VIOLATION):

Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF6F95E6650
Module  : C:\\Users\\ryanl\\Downloads\\blender-2.80.0-git.4dd0a90f4213-windows64\\blender.exe

Exact steps for others to reproduce the error

Attached is a .blend file including the script that reproduces this issue.

  1. Open the .blend file
  2. Press 'Run Script'
  3. Begin rendering the animation (Blender > Render > Render Animation)

bug_script_280.blend

**System Information** Operating system: Windows 10 Home Graphics card: GTX 1070 8GB **Blender Version** Broken: 2.80, .4dd0a90f4213, 2019-01-01 Worked: 2.79b release **Short description of error** Blender crashes while rendering and animation when object data is modified inside the frame_change_pre handler using the Python API. The crashes only seem to occur while rendering and not during playback. The frequency of crashes seems to be related to the frequency at which the object data is modified. This is part of an addon that reads and renders geometry data from a sequence of files. 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 geometry. I have a created a simplified script that reproduces this crash within the first few frames of rendering: ``` import bpy 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) ``` This is the error Blender reports (**EXCEPTION_ACCESS_VIOLATION**): ``` Error : EXCEPTION_ACCESS_VIOLATION Address : 0x00007FF6F95E6650 Module : C:\\Users\\ryanl\\Downloads\\blender-2.80.0-git.4dd0a90f4213-windows64\\blender.exe ``` **Exact steps for others to reproduce the error** Attached is a .blend file including the script that reproduces this issue. 1. Open the .blend file 2. Press 'Run Script' 3. Begin rendering the animation (Blender > Render > Render Animation) [bug_script_280.blend](https://archive.blender.org/developer/F6154836/bug_script_280.blend)
Ryan Guy commented 2019-01-03 00:27:43 +01:00
Author
Copy Link

Added subscriber: @rlguy

Added subscriber: @rlguy
blender-admin commented 2019-01-03 00:27:43 +01:00
Copy Link

blender/blender#67627 was marked as duplicate of this issue

blender/blender#67627 was marked as duplicate of this issue
blender-admin commented 2019-01-03 00:27:43 +01:00
Copy Link

blender/blender#67819 was marked as duplicate of this issue

blender/blender#67819 was marked as duplicate of this issue
blender-admin commented 2019-01-03 00:27:43 +01:00
Copy Link

blender/blender#64065 was marked as duplicate of this issue

blender/blender#64065 was marked as duplicate of this issue
blender-admin commented 2019-01-03 00:27:43 +01:00
Copy Link

blender/blender#63610 was marked as duplicate of this issue

blender/blender#63610 was marked as duplicate of this issue
blender-admin commented 2019-01-03 00:27:43 +01:00
Copy Link

blender/blender#62632 was marked as duplicate of this issue

blender/blender#62632 was marked as duplicate of this issue
blender-admin commented 2019-01-03 00:27:43 +01:00
Copy Link

#62096 was marked as duplicate of this issue

#62096 was marked as duplicate of this issue
André Savik commented 2019-01-06 10:48:56 +01:00
Copy Link

Added subscriber: @Klutz

Added subscriber: @Klutz
André Savik commented 2019-01-06 10:48:56 +01:00
Copy Link

Can confirm the same bug on the Linux build:

version: 2.80 (sub 40), branch: blender2.7, commit date: 2019-01-04 21:18, hash: a77b63c56943, type: Release
build date: 2019-01-05, 00:56:39
platform: Linux

Can confirm the same bug on the Linux build: version: 2.80 (sub 40), branch: blender2.7, commit date: 2019-01-04 21:18, hash: a77b63c56943, type: Release build date: 2019-01-05, 00:56:39 platform: Linux
Campbell Barton was assigned by Sebastian Parborg 2019-01-25 11:36:36 +01:00
Sebastian Parborg commented 2019-03-13 12:31:09 +01:00
Member
Copy Link

Added subscriber: @AdrianCabrera

Added subscriber: @AdrianCabrera
Brecht Van Lommel commented 2019-03-16 18:04:25 +01:00
Owner
Copy Link

Added subscriber: @knusk

Added subscriber: @knusk
Brecht Van Lommel commented 2019-03-18 14:00:25 +01:00
Owner
Copy Link

Added subscribers: @Sergey, @ideasman42, @brecht

Added subscribers: @Sergey, @ideasman42, @brecht
Campbell Barton was unassigned by Brecht Van Lommel 2019-03-18 14:00:25 +01:00
Brecht Van Lommel commented 2019-03-18 14:00:25 +01:00
Owner
Copy Link

Changing priority since variations of this crash have been reported a few times, and commonly used add-ons like Animation Nodes and FLIP fluids suffer from it.

This may be more a dependency graph issue than a Python API one.

In general it would be good to clarify which kind of data scripts are allowed or recommended to edit in the various handlers, it's not so clear anymore with multiple depsgraphs.

Changing priority since variations of this crash have been reported a few times, and commonly used add-ons like Animation Nodes and FLIP fluids suffer from it. This may be more a dependency graph issue than a Python API one. In general it would be good to clarify which kind of data scripts are allowed or recommended to edit in the various handlers, it's not so clear anymore with multiple depsgraphs.
Jacques Lucke commented 2019-03-21 15:29:59 +01:00
Member
Copy Link

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke
Omar Emara commented 2019-03-21 18:29:01 +01:00
Member
Copy Link

Added subscriber: @OmarEmaraDev

Added subscriber: @OmarEmaraDev
julian commented 2019-03-22 04:39:17 +01:00
Copy Link

Added subscriber: @anon

Added subscriber: @anon
Dennis Wissel commented 2019-03-23 12:14:08 +01:00
Copy Link

Added subscriber: @dsine

Added subscriber: @dsine
Juan Gea commented 2019-03-25 09:46:46 +01:00
Copy Link

Added subscriber: @juang3d

Added subscriber: @juang3d
Juan Gea commented 2019-03-25 09:46:46 +01:00
Copy Link

Just stumbled upon this bug, what a big bug!

I'm being completely unable to render one project right now because of this, I hope it gets fixed soon.

Cheers!

Just stumbled upon this bug, what a big bug! I'm being completely unable to render one project right now because of this, I hope it gets fixed soon. Cheers!
iad alk commented 2019-03-26 02:18:07 +01:00
Copy Link

Added subscriber: @iad

Added subscriber: @iad
Sebastian Parborg commented 2019-04-16 11:54:40 +02:00
Member
Copy Link

Added subscriber: @hansfbaier

Added subscriber: @hansfbaier
Daniel commented 2019-04-26 11:04:02 +02:00
Copy Link

Added subscriber: @bestdani

Added subscriber: @bestdani
Jacques Lucke commented 2019-05-02 15:23:09 +02:00
Member
Copy Link

Added subscribers: @EricS-4, @LazyDodo, @1D_Inc

Added subscribers: @EricS-4, @LazyDodo, @1D_Inc
Michael Hermann commented 2019-05-14 11:49:06 +02:00
Copy Link

Added subscriber: @MichaelHermann

Added subscriber: @MichaelHermann
Sergey Sharybin was assigned by Brecht Van Lommel 2019-05-28 17:43:25 +02:00
Sergey Sharybin commented 2019-05-29 16:31:48 +02:00
Owner
Copy Link

Developer note: this issue is caused by a threading conflict between viewport which is catching with its dependency graph in the main thread with the render thread which is modifying main database while it is used by viewport.

Not sure how/whether this worked in 2.7x yet.

Developer note: this issue is caused by a threading conflict between viewport which is catching with its dependency graph in the main thread with the render thread which is modifying main database while it is used by viewport. Not sure how/whether this worked in 2.7x yet.
Jacques Lucke commented 2019-05-29 16:34:27 +02:00
Member
Copy Link

These crashes existed in 2.79 two when certain things were done. Usually one was able to fix it by rendering from the terminal or locking the UI during rendering. I think these workarounds did not work anymore in Blender 2.8 (haven't tried for quite some time thought).

These crashes existed in 2.79 two when certain things were done. Usually one was able to fix it by rendering from the terminal or locking the UI during rendering. I think these workarounds did not work anymore in Blender 2.8 (haven't tried for quite some time thought).
Todor Nikolov commented 2019-06-08 16:12:35 +02:00
Copy Link

Added subscriber: @TodorNikolov

Added subscriber: @TodorNikolov
Ryan Guy commented 2019-06-13 22:18:47 +02:00
Author
Copy Link

I was testing the recent fix for blender/blender#60136 and noticed that this issue will cause a crash when baking a rigid body cache. Here is a modified version of the .blend file in the original post to reproduce this issue:

bug_script_280_rigid_body.blend

To Reproduce:

  • Open the .blend file
  • Press 'Run Script'

Bake the rigid body world cache

Sometimes the cache bakes successfully without a crash. Repeating step 3 by deleting the cache results in a crash within a few attempts for me.

Error Output:

Error   : EXCEPTION_ACCESS_VIOLATION
Address : 0x00007FF760C36840
Module  : C:\Users\ryanl\Downloads\blender-2.80.0-git.5e626e766459-windows64\blender.exe
I was testing the recent fix for blender/blender#60136 and noticed that this issue will cause a crash when baking a rigid body cache. Here is a modified version of the .blend file in the original post to reproduce this issue: [bug_script_280_rigid_body.blend](https://archive.blender.org/developer/F7102005/bug_script_280_rigid_body.blend) To Reproduce: - Open the .blend file - Press 'Run Script' # Bake the rigid body world cache Sometimes the cache bakes successfully without a crash. Repeating step 3 by deleting the cache results in a crash within a few attempts for me. Error Output: ``` Error : EXCEPTION_ACCESS_VIOLATION Address : 0x00007FF760C36840 Module : C:\Users\ryanl\Downloads\blender-2.80.0-git.5e626e766459-windows64\blender.exe ```
Fin O'Riordan commented 2019-07-07 17:30:14 +02:00
Copy Link

Added subscriber: @FinbarrORiordan

Added subscriber: @FinbarrORiordan
Lance Phan commented 2019-07-08 11:09:54 +02:00
Copy Link

Added subscriber: @ssendam

Added subscriber: @ssendam
Sam Green commented 2019-07-08 18:02:13 +02:00
Copy Link

Added subscriber: @SamGreen

Added subscriber: @SamGreen
Georg K commented 2019-07-12 22:09:28 +02:00
Copy Link

Added subscriber: @georgK

Added subscriber: @georgK
Piotr commented 2019-07-16 12:55:49 +02:00
Copy Link

Added subscriber: @Lewiatan

Added subscriber: @Lewiatan
Piotr commented 2019-07-16 12:55:49 +02:00
Copy Link

What is the status of this issue? This bug makes using FLIP Fluid plugin impossible because Blender 2.80 Rc 1 crashes during rendering (sometimes as soon as I press "render" (ctrl+F12) ) if FLIP Fluids' objects are present in the scene regardless if I render PNG pictures or a movie.

What is the status of this issue? This bug makes using FLIP Fluid plugin impossible because Blender 2.80 Rc 1 crashes during rendering (sometimes as soon as I press "render" (ctrl+F12) ) if FLIP Fluids' objects are present in the scene regardless if I render PNG pictures or a movie.
Sergey Sharybin commented 2019-07-16 14:17:26 +02:00
Owner
Copy Link

Status is: Open, Confirmed, High

This issue is rooting a deep design issues, which were also quite bad in Blender 2.79 but somehow crash was managed to not happen so often.

Possible workaround is to render with Lock Interface option enabled.

Status is: Open, Confirmed, High This issue is rooting a deep design issues, which were also quite bad in Blender 2.79 but somehow crash was managed to not happen so often. Possible workaround is to render with `Lock Interface` option enabled.
Juan Gea commented 2019-07-16 14:48:04 +02:00
Copy Link

Lock Interface did not solve the issue, when I experienced the problem I tried it, without luck, I cannot test it right away, I'm on a hard and tight deadline, but I remember trying everything, even this, and it didn't work

Lock Interface did not solve the issue, when I experienced the problem I tried it, without luck, I cannot test it right away, I'm on a hard and tight deadline, but I remember trying everything, even this, and it didn't work
Ryan Guy commented 2019-07-16 18:19:07 +02:00
Author
Copy Link

From FLIP Fluids user reports regarding this render crash issue in Blender 2.80, it seems that the Lock Interface workaround works for roughly half of the users. I have tested systems where locking the interface helps reduce render crashes and some systems where this does not work. In my experience, the render crash frequency increases as the amount of mesh geometry increases.

Render crashes in Blender 2.79 are much less frequent and a workaround of setting the Render Display to Fullscreens seems to work for all FLIP Fluids users.

From FLIP Fluids user reports regarding this render crash issue in Blender 2.80, it seems that the Lock Interface workaround works for roughly half of the users. I have tested systems where locking the interface helps reduce render crashes and some systems where this does not work. In my experience, the render crash frequency increases as the amount of mesh geometry increases. Render crashes in Blender 2.79 are much less frequent and a workaround of setting the Render Display to Fullscreens seems to work for all FLIP Fluids users.
Piotr commented 2019-07-16 22:34:22 +02:00
Copy Link

In #60094#723914, @Sergey wrote:
Status is: Open, Confirmed, High

This issue is rooting a deep design issues, which were also quite bad in Blender 2.79 but somehow crash was managed to not happen so often.

Possible workaround is to render with Lock Interface option enabled.

Do you plan to fix this bug soon? It sounds like it will take months to fix it

> In #60094#723914, @Sergey wrote: > Status is: Open, Confirmed, High > > This issue is rooting a deep design issues, which were also quite bad in Blender 2.79 but somehow crash was managed to not happen so often. > > Possible workaround is to render with `Lock Interface` option enabled. Do you plan to fix this bug soon? It sounds like it will take months to fix it
Piotr commented 2019-07-16 22:37:45 +02:00
Copy Link

In #60094#724170, @rlguy wrote:
From FLIP Fluids user reports regarding this render crash issue in Blender 2.80, it seems that the Lock Interface workaround works for roughly half of the users. I have tested systems where locking the interface helps reduce render crashes and some systems where this does not work. In my experience, the render crash frequency increases as the amount of mesh geometry increases.

Render crashes in Blender 2.79 are much less frequent and a workaround of setting the Render Display to Fullscreens seems to work for all FLIP Fluids users.

I did notice if I had only FLIP Fluids domain and inflow mesh in the project, Blender 2.80 Rc 1 didn't crash at all. Locking Interface worked for me, I hope it will stay that way.

> In #60094#724170, @rlguy wrote: > From FLIP Fluids user reports regarding this render crash issue in Blender 2.80, it seems that the Lock Interface workaround works for roughly half of the users. I have tested systems where locking the interface helps reduce render crashes and some systems where this does not work. In my experience, the render crash frequency increases as the amount of mesh geometry increases. > > Render crashes in Blender 2.79 are much less frequent and a workaround of setting the Render Display to Fullscreens seems to work for all FLIP Fluids users. I did notice if I had only FLIP Fluids domain and inflow mesh in the project, Blender 2.80 Rc 1 didn't crash at all. Locking Interface worked for me, I hope it will stay that way.
Steve White commented 2019-07-22 18:28:09 +02:00
Copy Link

Added subscriber: @Massivetree

Added subscriber: @Massivetree
Steve White commented 2019-07-22 18:28:09 +02:00
Copy Link

I really hope this gets fixed soon(and I mean before the stable release of 2.8). Flip Fluids is essentially unusable in Blender 2.8 because of it.

I really hope this gets fixed soon(and I mean before the stable release of 2.8). Flip Fluids is essentially unusable in Blender 2.8 because of it.
Juan Gea commented 2019-07-22 21:05:54 +02:00
Copy Link

This is not only flip fluid related, this could probably affect also elbeem or Mantaflow, since in the end they are generating meshes too

This is not only flip fluid related, this could probably affect also elbeem or Mantaflow, since in the end they are generating meshes too
Jacques Lucke commented 2019-07-29 19:27:58 +02:00
Member
Copy Link

Added subscribers: @AieKick, @GavinScott

Added subscribers: @AieKick, @GavinScott
Sybren A. Stüvel commented 2019-07-31 12:31:13 +02:00
Member
Copy Link

Added subscriber: @dr.sybren

Added subscriber: @dr.sybren
Rafael commented 2019-08-01 01:20:43 +02:00
Copy Link

Added subscriber: @argelis99

Added subscriber: @argelis99
Rafael commented 2019-08-01 01:20:43 +02:00
Copy Link

Is there any work around for this? Even in the official release of 2.8 it crashes on render when using flip fluids. This has been an issue since January, can the Dev team at least tell us if this is something that CAN be fixed? Any communication on such an old high priority issue would be highly appreciated.

Is there any work around for this? Even in the official release of 2.8 it crashes on render when using flip fluids. This has been an issue since January, can the Dev team at least tell us if this is something that CAN be fixed? Any communication on such an old high priority issue would be highly appreciated.
Sergey Sharybin commented 2019-08-01 09:56:48 +02:00
Owner
Copy Link

This of course can and will be fixed.

This of course can and will be fixed.
Simon Hilling commented 2019-08-03 12:06:16 +02:00
Copy Link

Added subscriber: @Thrilling

Added subscriber: @Thrilling
Simon Hilling commented 2019-08-03 12:06:16 +02:00
Copy Link

I'd very much appreciate this issue being fixed. Really excited for 2.8 and Flip Fluids but currently can't render any big files overnight which of course is a big problem.

I'd very much appreciate this issue being fixed. Really excited for 2.8 and Flip Fluids but currently can't render any big files overnight which of course is a big problem.
Florian commented 2019-08-06 20:26:04 +02:00
Copy Link

Added subscriber: @Mitsuma

Added subscriber: @Mitsuma
Eirik Svensen commented 2019-08-07 11:35:29 +02:00
Copy Link

Added subscriber: @kolibrieirik

Added subscriber: @kolibrieirik
Alex Vuong commented 2019-08-07 19:53:03 +02:00
Copy Link

Added subscriber: @jvbandelero

Added subscriber: @jvbandelero
Alyssa Anderson commented 2019-08-07 23:17:59 +02:00
Copy Link

Added subscriber: @PaulAnderson

Added subscriber: @PaulAnderson
Alyssa Anderson commented 2019-08-07 23:17:59 +02:00
Copy Link

I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.

I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.
Steve White commented 2019-08-07 23:47:28 +02:00
Copy Link

In #60094#748133, @PaulAnderson wrote:
I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.

Interesting, thank you Alyssa, so far I've been able to render a few dozen frames with no crash where before it would crash after 1 or 2.

> In #60094#748133, @PaulAnderson wrote: > I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes. Interesting, thank you Alyssa, so far I've been able to render a few dozen frames with no crash where before it would crash after 1 or 2.
Juan Gea commented 2019-08-08 10:30:48 +02:00
Copy Link

In #60094#748133, @PaulAnderson wrote:
I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes.

Yep, this was a “semi” workaround, Jacques mentioned it here before, but it still crashes after a few frames.

> In #60094#748133, @PaulAnderson wrote: > I seem to have encountered a work-around. If you go under the Render menu and check Lock Interface it stops the crashes. Yep, this was a “semi” workaround, Jacques mentioned it here before, but it still crashes after a few frames.
Ethan Sherriff commented 2019-08-08 22:00:41 +02:00
Copy Link

Added subscriber: @EthanSherriff

Added subscriber: @EthanSherriff
lucas veber commented 2019-08-09 09:28:31 +02:00
Copy Link

Added subscriber: @LucasVeber

Added subscriber: @LucasVeber
LapisSea commented 2019-08-10 02:17:41 +02:00
Copy Link

Added subscriber: @LapisSea

Added subscriber: @LapisSea
Sam Mousa commented 2019-08-22 01:42:40 +02:00
Copy Link

Added subscriber: @Mrqozy

Added subscriber: @Mrqozy
Sam Mousa commented 2019-08-22 01:42:40 +02:00
Copy Link

please fix this!
flip fluids is a must for any water sim in blender, the internal fluid simulation engine is a pain.
its a shame blender devs haven't fixed this bug already.

please fix this! flip fluids is a must for any water sim in blender, the internal fluid simulation engine is a pain. its a shame blender devs haven't fixed this bug already.
Philipp Oeser commented 2019-09-06 12:49:30 +02:00
Member
Copy Link

Added subscriber: @lichtwerk

Added subscriber: @lichtwerk
Philipp Oeser commented 2019-09-06 12:49:30 +02:00
Member
Copy Link

@Sergey : Just a note I have added this to 2.81 milestone (since it was set to "High"), I think you are on it already, right?

@Sergey : Just a note I have added this to 2.81 milestone (since it was set to "High"), I think you are on it already, right?
Sergey Sharybin commented 2019-09-11 11:07:03 +02:00
Owner
Copy Link

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Sergey Sharybin commented 2019-09-11 11:07:04 +02:00
Owner
Copy Link

There are the following changes now made:

Currently it's as stable as we can make it. It is indeed true that interface is better be locked, otherwise render thread might cause conflicts with the viewport (due to python handlers possibly modifying data while it's being drawn by the viewport).

There are ways around it, but needs some design changes. Will be handled outside of the bug tracker as a regular development.

There are the following changes now made: - Dependency graph is always guaranteed to be fully evaluated after handlers for POST depsgraph/frame change (including adding/removing objects, modifying them and so on). - It is possible to access evaluated versions of datablocks from handlers. See https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Python_API#Handlers Currently it's as stable as we can make it. It is indeed true that interface is better be locked, otherwise render thread might cause conflicts with the viewport (due to python handlers possibly modifying data while it's being drawn by the viewport). There are ways around it, but needs some design changes. Will be handled outside of the bug tracker as a regular development.
Eirik Svensen commented 2019-09-11 11:09:02 +02:00
Copy Link

Removed subscriber: @kolibrieirik

Removed subscriber: @kolibrieirik
lucas veber commented 2019-09-11 11:14:30 +02:00
Copy Link

Great news, thanks @Sergey !

Currently it's as stable as we can make it.

Does it mean it may still crashes under certain circumstances?

Great news, thanks @Sergey ! > Currently it's as stable as we can make it. Does it mean it may still crashes under certain circumstances?
Sergey Sharybin commented 2019-09-11 11:19:12 +02:00
Owner
Copy Link

Does it mean it may still crashes under certain circumstances?

Yes. If Python handler is adding/removing objects and rendering is happening without Locked Interface.
This was always an issue.

> Does it mean it may still crashes under certain circumstances? Yes. If Python handler is adding/removing objects and rendering is happening without Locked Interface. This was always an issue.
Steve White commented 2019-09-11 14:30:58 +02:00
Copy Link

Thank you Sergey. Is the 2.8 build updated after the final release last month with these fixes? Should I reinstall the 2.8 version? Or is this fix only in the 2.81 version?

Thank you Sergey. Is the 2.8 build updated after the final release last month with these fixes? Should I reinstall the 2.8 version? Or is this fix only in the 2.81 version?
Sergey Sharybin commented 2019-09-11 14:43:16 +02:00
Owner
Copy Link

The fixes will be available in the net round of nightly builds and in 2.81.

The fixes will be available in the net round of nightly builds and in 2.81.
lucas veber commented 2019-09-11 14:44:04 +02:00
Copy Link

2.81 release is scheduled for november as far as I remember, I'd bet they won't release a corrective 2.80a version but rather count on 2.81.

2.81 release is scheduled for november as far as I remember, I'd bet they won't release a corrective 2.80a version but rather count on 2.81.
Matthew Pallotta commented 2019-09-14 16:19:23 +02:00
Copy Link

Added subscriber: @MatthewPallotta

Added subscriber: @MatthewPallotta
Casey Connor commented 2019-12-25 22:03:31 +01:00
Copy Link

Added subscriber: @clepsydrae

Added subscriber: @clepsydrae
michael campbell commented 2021-06-01 17:34:56 +02:00
Copy Link

Added subscriber: @3di

Added subscriber: @3di
michael campbell commented 2021-06-01 17:34:56 +02:00
Copy Link

still getting the problem here, should I open a new report?

still getting the problem here, should I open a new report?
Philipp Oeser commented 2021-06-01 18:02:06 +02:00
Member
Copy Link

In #60094#1169192, @3di wrote:
still getting the problem here, should I open a new report?

If Render → Lock Interface doesnt solve it for you: yes, please.
https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data

> In #60094#1169192, @3di wrote: > still getting the problem here, should I open a new report? If `Render` → `Lock Interface` doesnt solve it for you: yes, please. https://docs.blender.org/api/master/bpy.app.handlers.html#note-on-altering-data
Josiah Chapman commented 2021-06-15 01:01:28 +02:00
Copy Link

Added subscriber: @josiahc

Added subscriber: @josiahc
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
Interest
Animation & Rigging

  
Interest
Blender Cloud

  
Interest
Collada

  
Interest
Core

  
Interest
Documentation

  
Interest
Eevee & Viewport

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
Import and Export

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Nodes & Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds, Tests & Devices

  
Interest
Python API

  
Interest
Rendering & Cycles

  
Interest
Sculpt, Paint & Texture

  
Interest
Translations

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Meta
Good First Issue

  
Meta
Papercut

  
Module
Add-ons (BF-Blender)

  
Module
Add-ons (Community)

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
Sergey Sharybin
37 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-addons#60094
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?