It's triggering an assertion in cpython.
Sun, Jul 21
Looks like this bug only happens with the debug build configuration. I tested rc2, and then built the current master with release target. Both handle the error cases gracefully.
It's a papercut. The timeline scrollbar handles do not align with the mouse when dragged. This is expected behaviour, but only when the scrollbar size is at maximum or minimum width, to allow for further zooming in both directions.
Tue, Jul 16
Here is a diff to apply on top of this revision.
Updating this diff to incorporate the changes from D5108 to include support for edge selection.
Jun 17 2019
Gset is just the equivalent to a set in C++ or Java. You can find the implementation in BLI_ghash.c by looking for the BLI_gset_ prefix.
Jun 13 2019
This problem is not limited to Dyntopo, any mesh with high enough density will show some defects. The problem seems to originate from node texture. I was able to somewhat isolate this particular problem.
I think he is referring to the offset between mouse cursor and scrollbar handle when zooming back in. The cursor reaches the left border before the scrollbar does. This forces you to move the handle multiple times to zoom all the way out.
Jun 12 2019
Just noticed that text->nlines is 1 in BPY_execute_text, independent of the actual lines. Don't know whether this has to do with anything.
Maybe windows 7 does handle the pagefile differently compared to windows 10. Or there is not enough room on your disk for the pagefile to grow. The pagefile is used to offload data from memory to disk when necessary. In theory you can set its size manually, but I'm not sure whether this will help.
Jun 11 2019
Looks like you don't have enough RAM for this scene. I had a look at the Task Manager while doing the same as you did in the video. My RAM usage went from 2.9 GB to 7.9GB. You could try if works for you when you have your RAM usage below 2.9GB before starting blender. The final render will use even more RAM, primarily because the Subdivision Surface modifier on Landscape.
Jun 10 2019
Only the numbers are emulated. The Period is already assigned to the Pivot Point menu. However you can assign a key manually in Preferences -> Keymap (search for "View Selected").
@matc (matc) normally when we developers set a bug to confirm, it should be assigned to a developer immediately. Otherwise it's looks as if it's been triaged but none of the developers have assessed what kind of priority it has and who should look into it. If you don't know who to assign it to, just leave as Needs Triage.
Jun 6 2019
This seems to have been fixed. Do you still experience this with current versions?
Jun 5 2019
I think the problem originates in the use of rna_Brush_gpencil_tool_items. I guess it is using the names of annotation brushes. At least BKE_libblock_find_name returns a brush without gpencil_settings for "Erase". This is the brush that causes the crash I described further up. Otherwise I don't experience any crashes.
Jun 4 2019
I think the expected behaviour is closer to the patch I posted previously.
Jun 3 2019
I can confirm Alpha Blend fixes the ghosting. But Show Backface appears to be optional.
In BKE_pbvh_search_gather the PBVHNode points to 0xcccc...
this is expected.
I modified the file a bit. I stickied the properties for the two spheres. One sphere has a material with Screen Space Refraction enabled and the other disabled. The cube has Screen Space Refraction enabled and Transmission set to 1.0.
Now I'm able to reproduce.
I don't have any problem selecting bones in your file. Maybe your key mappings are messed up. Could you try to Load Factory Settings from the bottom left corner of the Preferences window?
Can you upload a .blend file that allows to reproduce the problem within a few steps?
Looks like there is a problem with importing relative files. Looks like this is normal for python.
Jun 2 2019
Can you create and upload a .blend file with the error? With the default cube I'm not running into problems adding, removing and resizing lights.
The same is happening with other modifiers. Essentially every modifier that preserves the original edges has this problem. Using "Adjust edit cage to modifier result" on the modifier fixes the problem with the side effect of being able to select generated edges.
I couldn't reproduce this problem. Can you upload a .blend file?
Crash happens in stats_object_edit(Object *obedit, SceneStats *stats) where BKE_editmesh_from_object(obedit) returns NULL. Selecting "StickHandRD" in the Outliner has the same effect.
Falloff without falloff:
I had a look at the code. It looks like the brush weight is only used as limit. Every calculated weight that exceeds that limit would be set to that limit.
I can confirm. I'm crashing at the end of the animation once the keyframe jumps back to 1. Or when selcting keyframe 0 and then keyframe 1.
Can you provide the exact version of blender that worked? You can find the Hash in the top right corner of the splash screen.
I can still trigger this bug fairly frequently just by rendering the default .blend file at a low resolution.
Jun 1 2019
Works fine on Windows 10 with RX580.
I can reproduce it like this on 0360a2920dec9028d:
The old startup.blend has the broken tools for x86, but is otherwise working. One thing I noticed is that bmain->brushes initially contains only valid Grease Pencil brushes with gpencil_settings. But once the broken tools are manually switched to working ones, then the brush of the broken tool (with gpencil_settings set to NULL) is added to bmain->brushes. This does somehow only happen for Erase and Fill but not for Draw.
I tried opening all files mentioned in this thread with x86 and x64 blender (version 3f23299403d4f20f) on windows 10. Initially no file causes a crash for either version. Only the broken eraser tool can cause problems when gp_get_default_eraser finds the broken eraser before the default eraser (gpencil_settings is NULL).
Could be that the problem is in DepsgraphNodeBuilder::build_object_data_geometry where only materials are handled which are returned by give_current_material. When setting a link to Object, then the material in ob->data is ignored. But I'm not sure how this wouldn't have caused problems with the default cube.
May 24 2019
Diff against current master.
May 20 2019
May 9 2019
This fixes tool_slots with NULL brushes.
May 7 2019
Keymaps appear to be in release/scripts/presets/keyconfig/keymap_data/.
May 6 2019
Before newlibadr_us() the lower 32bit of p->tool_slots[i].brush are the same for 64bit and 32bit.
May 5 2019
I think I found where "Draw" is coming from.
I'm ok with that. There is still something wrong with having the "Draw" there. Or is ts->gp_paint not limited to grease pencil tools? And it should be the same for 32bit and 64bit anyway.
May 4 2019
For me 32bit Blender crashes when opening the default "2D Animation". The problem seems to be that 32bit Blender somehow gets to use "Draw" where 64bit Blender is using "Draw Pencil". But "Draw" is not a grease pencil tool.
May 3 2019
I think the easiest way to fix this, is to use the property value as active item in ui_searchbox_update.
I had worked on this a couple of weeks ago. I updated my version to current master (D4792).
Apr 15 2019
I added an audio track in the sequencer to do some testing. Everything seams to work fine. Only when adding another track while rendering, the added track is part of the remaining render. But this seems to be a general problem, as moving the cube in the default scene while rendering does show up in the render too. I assume this is limited to animation rendering.
Apr 14 2019
The two calls to BKE_sound_update_scene both come from a depencygraph. One holds the copies for the viewport and the other one for the renderer. Both are running in their own thread. BKE_scene_graph_update_tagged happens to not be called for the render thread. But BKE_scene_graph_update_for_newframe is called for both, which is a problem.
I can't add a bone contstraint to b__R_UpperArm__.
When I open RJ17ANAN3.BUG.blend I get the following output:
Dependency cycle detected: 'OBRig - Mover.RIGHT HAND.BONE_CONSTRAINTS()' depends on 'OBrig.b__R_Hand__.BONE_DONE()' through 'Copy Rotation' 'OBrig.b__R_Hand__.BONE_DONE()' depends on 'OBrig.POSE_IK_SOLVER()' through 'IK Solver Result' 'OBrig.POSE_IK_SOLVER()' depends on 'OBrig.POSE_INIT_IK()' through 'Init IK -> IK Solver' 'OBrig.POSE_INIT_IK()' depends on 'OBrig.POSE_INIT()' through 'Pose Init -> Pose Init IK' 'OBrig.POSE_INIT()' depends on 'OBRig - Mover.RIGHT HAND.BONE_DONE()' through 'IK' 'OBRig - Mover.RIGHT HAND.BONE_DONE()' depends on 'OBRig - Mover.RIGHT HAND.BONE_READY()' through 'Ready -> Done' 'OBRig - Mover.RIGHT HAND.BONE_READY()' depends on 'OBRig - Mover.RIGHT HAND.BONE_CONSTRAINTS()' through 'Constraints -> Ready' Dependency cycle detected: 'OBrig.POSE_INIT()' depends on 'OBRig - Mover.LEFT HAND.BONE_DONE()' through 'IK' 'OBRig - Mover.LEFT HAND.BONE_DONE()' depends on 'OBRig - Mover.LEFT HAND.BONE_READY()' through 'Ready -> Done' 'OBRig - Mover.LEFT HAND.BONE_READY()' depends on 'OBRig - Mover.LEFT HAND.BONE_CONSTRAINTS()' through 'Constraints -> Ready' 'OBRig - Mover.LEFT HAND.BONE_CONSTRAINTS()' depends on 'OBrig.b__L_Hand__.BONE_DONE()' through 'Copy Rotation' 'OBrig.b__L_Hand__.BONE_DONE()' depends on 'OBrig.POSE_IK_SOLVER()' through 'IK Solver Result' 'OBrig.POSE_IK_SOLVER()' depends on 'OBrig.POSE_INIT_IK()' through 'Init IK -> IK Solver' 'OBrig.POSE_INIT_IK()' depends on 'OBrig.POSE_INIT()' through 'Pose Init -> Pose Init IK' Detected 2 dependency cycles
But I don't crash when I reproduce the situation in your last picture. Could you provide step by step instruction to crash blender with one of your files?
The problem seams to have been introduced in 48f9e24f0c1e Enable dependency graph update while rendering.
Apr 13 2019
It just feels weird, having a brush setting that allows you to change the active object material but not its own material.
Apr 11 2019
I found a possible fix for this. Not sure if it will cause other problems, but appears to be working in 3D view and when rendering.
@Mohan (pattamp) In case you are looking for a workaround. When I subdivide the red stroke a few times, the problem seems to go away.
Updated the api documentation to reflect the changes.
Apr 10 2019
Apr 3 2019
Apr 2 2019
With this change it's possible to work with the original file. There are 10 blocks ("Data from GD") remaining, that are not freed until the file has been saved once.
Apr 1 2019
Without this line my artifacts disappear.
Mar 25 2019
On linux it looks good for me too.
My error does not appear to be related to DEG. I had to draw two strokes and hit undo twice to trigger the crash. (Fedora with 4.20.16 kernel). I was not able to trigger the crash on windows 10 .
@Sebastian Parborg (zeddb) Does clipping work properly for you in Rendered?
@Sebastian Parborg (zeddb) This has been fixed with 7454fa927b80118 and 106551b9ad1f12. Clipping does not look like it's implemented in a way that would enhance performance.
Mar 23 2019
Does ./blender --debug-gpu always crash for you? What kernel version are you currently using? (uname -a)
This would solve my problem.
Mar 21 2019
@Antonio Vazquez (antoniov) The only thing remaining is the slow creation of new materials. But I guess this will be a new task. Looks otherwise good to be me.
The file does not have the bug for me by default either.
I can't reproduce this behaviour.
Not sure if this is by design. But proportional editing appears to be able to change the mesh outside of the clipped region (Alt+B), unlike with hidden vertices (H, Alt+H).
Mar 20 2019
The peak in 2. is most likely happening while the scene is prepared for rendering. For 1. and 2. having about the same render time is probably due to 3. performing bad. During 42 seconds 3. is able to render roughly 8% of the scene, which should save about 3.5s. This could be lost to the overhead of rendering on CPU and GPU simultaneously.
@Ahmad Bilal (SomeAB) I think the Task Manager only shows 3D usage in the overview. I had two switch one of the sub graphs to COMPUTE_2 to see the actual load. For me 3D peaks at the beginning at 15% and COMPUTE_2 is continuosly above 80%.
@Antonio Vazquez (antoniov) I don't think it's possible to distinguish between topbar and properties panel. I can only think of rna_MaterialIndex_update to do this.
@William Reynish (billreynish) I can confirm that changing a pinned material in the topbar is not possible. We have the same problem currently on master. I tried to implement this before, but failed to get a consistent look for both cases. @Antonio Vazquez (antoniov) previously posted pictures of how it did look like.
Mar 19 2019
This particular case appears to be fixed since f57fce3534258e449 .
Moved to minimal changes in UI.
Can't redo either. Win 10 (without intel) d47f827019f and e2abb1bf5cbcd
Fixed object constraint target
I updated D4250 to current master.
update to master, freeing but->search_arg without checking for but->editstr
Mar 18 2019
@Matias Mendiola (mendio) If we fake it to look the same in both cases, we would have to remove the slot related controls (move up, down, lock). The list of materials in each case would be of different length. (You can pin any existing grease pencil material, but you can only select between slots if unpinned.)
@William Reynish (billreynish) @Matias Mendiola (mendio) With this patch the material for a brush is NULL by default and the active material of a object is used instead, unless a brush has a pinned material. The material property on the right side changes the active material for a object, the same way as the layer property changes the current layer. Active layer and active materials affect all brushes.
One material is a property of the brush, the other is a property of the object.
fixed warnings and errors
Updated diff to work with current master.