From the design perspective of the dependency graph relation means data dependency.
The collision case you're mentioning is kinda a violation of this design, and I'd rather see that un-entagled…
Tested it and it still works fine!
Why do we need BLI_ASSERT_COLLECION_GOBJECT_HASH_IS_VALID after the collection_gobject_hash_ensure? And why is it needed here but not in the other use of the collection_gobject_hash_ensure some lines below?
Thanks for addressing the feedback, it is now much nicer!
@Alaska Never mind then. Seems that we can take of the message and merge commit from the UI now.
Lemme test the patch again, and if there will be no issues we'll just merge the change :)
Can you please rebase your patch on top of the main branch instead of merging he branch? This will align with the way how we work with the linear history of the main branch for the new features.
Unfortunately, I can not verify the code now because the build is currently broken (unrelated to this change).
I've tested the version of the patch from Phabricator and it worked fine. I didn't…
Marking as Requested changes since the design of the solution does not really seem optimal and at least requires much better explanation on the decision.
One question to consider is the desired behavior for the Geometry Nodes modifier, since the dependency code doesn't know if the nodes will actually use the geometry of the object, or only its…
That is, instead of hosting the addon repositories as "ghost" repos inside of the blender git folder like this
I am not sure what is the advantage of using lib folder would be, but the…
Putting on hold until #104573 is signed off, as the submodule part would need to be reconsidered.
Should be fixed now. You might need to force-reload the page in order for the new header and java-the-script to be loaded.
Should be fixed now. You might need to force-reload the page in order for the new header and java-the-script to be loaded.