- User Since
- Dec 16 2019, 9:13 AM (68 w, 6 d)
Jan 25 2021
Dec 15 2020
Calling load from file on previews from python crashes blender..
preview_collection = bpy.utils.previews.new()
preview_collection.load(name, os.path.join(ICONS_PATH, name + '.png'), 'IMAGE')
Jun 12 2020
@Bastien Montagne (mont29) ..and I told you that the bug has nothing to do with my script. It's related to the fact that object linking/unlinking to the scene performed without cutting a new UNDO step crashed blender when ctrl+z is pressed. How is that related to my script? You can choose to return CANCELLED from a script or to remove the UNOD flag if you do not wish that behaviour in the first place, but that does not mean that you have to crash the app. Obviously blender doesn't have a strategy to handle these corner cases..
As a side node here and potential workaround for anyone facing a similar problem: you can avoid this crash by unlinking post-event generated objects in undo_pre handler, and then link it back in undo_post
Probably related to T77557
Jun 10 2020
@Campbell Barton (campbellbarton) how? Can I access this feature from python? is it possible to add an undo step which will be jumped(undo multiple steps in one) when Ctrl+z is pressed?
@Campbell Barton (campbellbarton) batching the unexpected undo step into the previous one would feel more natural than if a new step is created. If you create a new undesired step, that could be cause for confusion
when ctrl+z is pressed and you have to press it multiple times to undo the unexpected steps.
And also this would be more consistent with the current definition of what UNDO flag means. basicaly, you are asking for a new undo step to be created whan an UNDO flag is present, and if none is pressent you want the last changes to be merged into the last existing step.
I think that this approach could address many of the UNDO related issues in blender and besided that it could be beneficial when post event operations are performed to be linked to the last undo step..
Jun 9 2020
Using application timers, execution queues and custom ops to react to events on main thread appears to be the acceptable solution to my problem, according to the docs https://docs.blender.org/api/current/bpy.app.timers.html
Jun 8 2020
OK then, what exactly can I do from a handler? Is it safe at least to call custom operators from handlers? And then I can create objects from inside the execute method of these ops..
@Bastien Montagne (mont29) yes that works if you use operators to create stuff, but if you don't add new objects with a custom operator then adding the UNDO flag + FINISHED is not an option. Adding new objects can happen on any callback handler: timer handler, deps graph update handler, nodes updates, even the undo handler
Calling the esoteric bpy.ops.ed.undo_push() after object link to the scene, appears to be working in this particular case..
I agree that performance is important, but this cannot stay the way it is now. 'Fast crashing' blender is not a solution for anyone :) I am pretty sure there are many important third party plugins rendered unusable by this change. What can be done to fix it?
@Bastien Montagne (mont29) I am doing something very similar to this script in a different project, unrelated to modal operators, and it's crashing when linking to the scene. I can't share that code.. but what I can say is that I am using depsgraph_update_handler_post() to create and link the objects to the scene.
Maybe introducing new API calls similar to bpy.ops.ed.undo_push() in order to cut new UNDO checkpoints can be a solution for user defined scripts.. Then, they can decide when to cut an check point and when to ignore it.
Anyway, I think is very unusual to crash blender only because you missed an UNDO checkpoint
new issue probably related T77557
Migth be related to this T77595
Jun 7 2020
blender.exe :0x00007FF6A2A2C260 BKE_scene_set_background
blender.exe :0x00007FF6A555F220 setup_app_data
blender.exe :0x00007FF6A555E600 BKE_blendfile_read_from_memfile
blender.exe :0x00007FF6A557B740 BKE_memfile_undo_decode
blender.exe :0x00007FF6A31362B0 memfile_undosys_step_decode
blender.exe :0x00007FF6A555E2F0 undosys_step_decode
blender.exe :0x00007FF6A555DEF0 BKE_undosys_step_undo_with_data_ex
blender.exe :0x00007FF6A3137540 ed_undo_step_impl
blender.exe :0x00007FF6A3137300 ed_undo_exec
blender.exe :0x00007FF6A2BC77A0 wm_operator_invoke
blender.exe :0x00007FF6A2BC5630 wm_handler_operator_call
blender.exe :0x00007FF6A2BC6CE0 wm_handlers_do_keymap_with_keymap_handler
blender.exe :0x00007FF6A2BC65B0 wm_handlers_do_intern
blender.exe :0x00007FF6A2BC5BE0 wm_handlers_do
blender.exe :0x00007FF6A2BC3260 wm_event_do_handlers
blender.exe :0x00007FF6A2BAEDC0 WM_main
blender.exe :0x00007FF6A293A530 main
Jun 6 2020
@Bastien Montagne (mont29) thanks. I can't reproduce this one either with the latest build. I have another thus, related to undoing and object linking to the scene. But i think is better to open another task for that one if I can reproduce it..
Jun 5 2020
May 30 2020
I had a similar issue. Adding a redo handler with a view_layer.update() inside fixed the crash in my case.
May 2 2020
Maybe I am in error here. I was under the impression that H has an unified underling architecture. Anyway, I would do the geometry nodes the same way as H does DOPS. A declarative approach is always superior to an imperative one.
You have more room for underling strategies, less input/output manual wiring, automatic data conversion(e.g object -> mesh) when necessary for the input stream, and overall a nicer user experience.
@Brecht Van Lommel (brecht) By pass-through I was referring to the fact that you can merge multiple objects(mesh data, volumes, particles, etc) under a single data stream. The current node will transform only the bits it's concerned with and everything else will be passed through to the next node in the network.
In simulations(DOPS), the only difference is the fact that you have time based constraints or physics constraints. You can think of SOPs as DOPS always in frame zero. In essence, geometry nodes underlying behavior is not much different
than DOPS's behavior. You still have to do a pass-through modified state to the next node in the tree, similarly to what happens in a looping simulation. IMO, there shouldn't be a hard link between object data in the scene and the nodes operating on this data. The data represents the state of the system and the nodes are just transformations applied to this data based on some constraints or selection patterns.
@Brecht Van Lommel (brecht) There is always a sweet spot between nodes and parametrization. Too many nodes are hard to manage manually and you become unproductive; too much programming/parametrization will make it hard for a non-programmer to use.
Some of the stuff John Cox was talking about in the previous post for anyone who wants to take a look:
Visualizing dependencies - https://www.sidefx.com/docs/houdini/network/dependencies.html
Geometry Spreadsheet and Attributes - https://www.youtube.com/watch?v=VwQEkqXutxo
Geometry Visualizer - https://vimeo.com/167151977
@Brecht Van Lommel (brecht)
I am not sure if I explained well enough what I meant by state pass through:
My idea was to limit the number of links between nodes by passing down the line the entire scene(object state) and each node will "select" based on some selection expressions(manually editable if necessary)
what mesh data to transform. In houdini they are doing something similar, and the nodes are editable though the properties panel which gives you more room for parametrization.
Also they kinda have it both ways if you want more coding you can choose VEX or python, or if you like nodes you can use VOPS
From what I am seeing, you are trying to achieve something similar to houdini VOPS, which is great if you like pure nodes, but as I have said earlier: this will become node spaghetti quite fast.
My point here is that you should consider node parametrization/expressions as well if you want to keep the nodetree clean and manageable.
What is wrong with this proposal? https://wiki.blender.org/wiki/Source/Nodes/UnifiedSimulationSystemProposal
Why not a state "pass-through" solution like the one presented in that paper? It would be closer to what Houdini does and believe me, the node tree is alot cleaner and easier to manage
And why "cluster" sets? Selection sets or selection groups would much more intutitive. The "cluster" word is usualy reserved for other stuff like a point cloud..
Dec 16 2019
IMO, these options should be added to the weld modifier:
- verts snap only, without welding
- remeve/fix degenerate faces/edges(degenerate dissolve)
- remove unused verts(delete loose)
- removing interior faces would be nice, but that requires a volumetric solution based on AO map baking or boolean/voxel remesh