I have thought of a workflow like this, to create face animation in a 2D view, but then projecting on top of a model and such.
Though it makes sense to use pixel boolean operations in the compositor, this way is kinda weak, because Blender currently missing, real time compositing capabilities (though there are talks to make this happen in the foreseable future). Pixel based operations work nicely provided that you exclude the real time factor.
So the most obvious solution is to model everything in 3D with the risk of loosing the 2D philosophy. But with your work so far I can see this idea becoming feasible once again.
Creating a 2D animated rig, with boolean operations and such, animated and fine-tuned properly right on the 3D view, with no intermediate steps.
Hey, what’s the status on this? It looks really cool. It would be nice if you could upload a patch to https://developer.blender.org (could include WIP in the name) so that it’s easier to try it.
Now that instances shouldn’t be realized by the nodes, maybe it could be possible to make this modify the instance references. If an instance is used multiple times it could duplicate the reference before modifying it.
I also thought about the possibility of reusing some of this code for a separate “Slice Curves” node that takes a 2d curve or 2d curve instances as input together with parameters like slice direction, width and padding and then outputs all slices as instances. This would be quite useful together with the text nodes I’m working on. What do you think?
Here’s an example of what I mean by slicing, made with the current boolean node:
I have no idea what this instancing is all about. I’ve briefly seen people talk about it in the chat, and nothing more. Is there a doc I can look up?
As for slicing, you should be able to use most of the boolean functions for that. They can generate a mesh containing all intersection points for you, which you then just need to walk along / trace correctly. I can’t guarantee the relevant code won’t change anymore, but it should stay mostly the same.
Might be much easier to just generate very thin boxes and use boolean subtraction instead though.
I haven’t had time to look at your code so I could be wrong, but generally what you do to support instances is not realize instances but instead run the code for each geometry set inside the input, using geometry_set.modify_geometry_sets. It would take a bit more work in this case though I guess as instance position has to be taken into account, and if the instance reference is used multiple times the cut version would have to be a copy of the original.
I just realized as this is in 2D I wonder how instances should be treated if they are not on the same plane?
I’m unfortunately a bit stuck. An update changed how curves are stored internally, and I can’t turn that new representation into a linked list and back without inevitably running into an exception somewhere down the line.
I currently don’t have the time to spend days debugging this, so unless someone else can jump in and implement that part, I’ll have to put the project on hiatus until I have excessive free time again.
Here’s an up-to-date version of blender with the base parts of the Curve Bool Modifier only. Meaning the modifier should show up in Blender, but not do anything.
The modifier is implemented in source/blender/nodes/geometry/nodes/node_geo_curve_bool.cc
The short term goal is to take data from CurvesGeometry, turn it into a double linked list (such as CurvePoint), storing all relevant point data, and then turn it back into a CurvesGeometry output, without crashing Blender.
Just copying CurveGeometry was supposed to be an even more simplified step. I’ve copied in a function from subdivide_curves.cc that’s supposed to copy existing curve data, but it causes a segfault. That one had me stumped last time I looked into it. The segfault happens outside of the node’s logic, probably during the update or draw call. If we can’t even copy the data, it’s hard to see how we can create new data from the linked list representation later. So that’s probably a good place to start.
Once we can turn the data from CurveGeometry to a linked list and back again, most of the old code should work again.
If you find a solution, that’d be wonderful. If you can’t , no worries, I’ll just have to pester the curve developer . It’s time to finish this either way.
Hello. Sorry for bringing up a dead topic. It’s just that some time ago I made some progress in learning blender and now, remembering this project, I see that it requires a complete census.
That is a good concept. We need this tool.
But from an implementation point of view, the following design needs to be considered:
And finally, after solving all the questions about the behavior of the curves, it is possible, based on all the algorithms tested above, to design this node.
This is at least to make an implementation of o = N^2 → 2log(n). Right now it meah what for 1000 x 1000 points we need do 10000000 tests. For join 10 curves by 1000 points … oh god … (1000 * 500 * 500 * 500 ... ( 1000 / 2 = 500 just for delete points in intersection area lol)). And of course, you can somehow optimize this so as not to check points that do not exactly intersect. But that’s the point BVHTree
I don’t have time for this (because of my studies and other projects), so these are just notes for the future.