Mh thank you!
I did know about the flip face node. I knew there had to be something like that.
I tried the method with the curve directly as a base shape but I get none straight corners. I don’t know why.
Gonna guess its because you’re doing a resample somewhere - resample doesn’t care about your corners right now. Current hack to resample with corners is:
curve-to-mesh(no profile)->split edges->mesh-to-curve->resample.
Mh ok it seems that it can give me straight corners but then when I add the resample, the base mesh just got messed up.
Without the resample:
With the resample:
Very strange. I use length of .5 as I used it before.
using a selection with normals I got back the full mesh but the resample is doing wrong things now haha.
it’s pretty messy
Hi
Double-Check your object scale… “large-enough” resamples convert line-segments into curve points.
see them like this:
…adds complexity in that you would need to capture curve deltas and lengths to correct for those (which is why the square-building setups are so popular).
Good luck
Damn I tried the Flip faces after my extrude… it’s just amazing how this thing is just not flipping the faces I select. I’m lost there.
I transfer attribute normal from the extrude and compare to select negative normal values… and then… it flip faces randomly. magical.
This setup seems to work for me.
Changed the the first frame of the main nodetree accordingly to zeroskills explanations.
But this left me with the last face flipped of the row due to applying mesh to curve and curve to mesh again (not sure if this is expected behaviour). So i had to flip the last face(did this only for ground level as an example) inside the ground nodegroup.
? erm, no - that doesn’t make sense, because the extrude normal is the thing that is pointing in the wrong direction.
What I meant was like so:
So, your challenge becomes about defining what the correct normal is to start off with… that’s why I do the base off of a curve (because the normals are consistent), and use those consistent normals to do later comparisons with.
Another quick workaround is to use mesh surfaces (instead of edges) to extrude from:
like so:
… the presence of the surface means Blender doesn’t have to guess the normals and they will be consistent.
Good luck
Oh wow ok thank you very much. I think I can understand a certain logic there but not the entire thing.
I’ll study it more.
So thank you for this 1st issue resolved. That’s moving forward.
@zeroskilz Thank you too a lot for giving us the path to follow.
I tried at the beginning to fill the mesh and extrude then. I got right normals but then none straight conners using a resample. This resample ignoring har corners is a headeck
Yeah, there are so many “gotchas” when working with such limited building blocks as we have in GN… at least with Blender 3.x’s GN you have many solutions that feel like they are way simpler to implement in GN than in python… it didn’t really feel like that with the “early” GN, so hopefully things will only improve.
@moshus - I forgot about that detail: that thing with the final face flipping has been around for ages… when doing the edge split you lose the normal info that the curve carried, so you would need to capture it pre-splitting, and use that normal instead of the split-edge’s normal in calculations further down the GN network.
The devs. at one point called for volunteers to submit patches implementing nodes they really want to see right away (since so much time is being spent on bugfixes, optimizations, general architecture, and now hair).
On that last part, Blender’s woefully limited and outdated hair system is finally on its way out in favor of a brand new system that is not deeply intwined in the particle code. This takes attention away from just building geometry with nodes, but keep in mind that a lot of features in 2.4x and before were more or less hacks that could be implemented quickly. The outdated particle system will also be ripped out and replaced in the same manner.
Hope I didn’t come across as ungrateful.
Been very happy with Blender 3+ GN’s architecture decisions so far and it only seems like things are getting better… even with the “gotchas” a lot of things don’t require patches, just node-groups.
Which from a general architecture viewpoint I think is a win for Blender. 
Yeah it’s already unbelievable what we can achieved is a such short period of GN existance.
I saw major updates between 3.0 and 3.1.4 I currently use.
I think I may have won the internet for the day
U is the length along the line * a scalar
I use the dot of the vector to a point from the closest point on a curve, to it’s normal rotated 90 on it’s tangent to flip the U which is distance from the line
I present 2d noise flowing along a curve on the surface of a mesh
AFAIK Early GN was much more powerful in theory, it just lacked some nodes that are now in 3.X GN. I understand the decision to change GN though, if the goal is to replace the modifier stack.
I really want a way to do “parametric” instances, because it make it way easier to work with instances that are custom nodes.
Some animation like that should be trivial to do yet it takes too much math to deal with point rotation and it will be kind of a problem for artists who can’t do the math if a trivial setup involves understanding things like modulo, trigonometry, … or maybe there is an easier way to do things but if it is the case it is certainly not obvious to find out.
Hi, nice job! but I think the issue is what if you want 50 pies? are you going to copy and paste the custom node 50 times and join them? What if you could make the sweep some kind of field and somehow vary its value after instancing each arc?
That’s what I’m talking about. Maybe there is a need for some sort of proxy system, I’m not sure how it could be dealt with. I didn’t look at the implementation. I myself only know about
Modulo because I have some programming skills, which is not the case for everybody using Blender.
Anyway I still think there is a better to do the previous setup with the tools we have now, although I didn’t find it yet.
Hi
I wasn’t commenting on the power of the previous GN, just my personal experience where implementing a solution in it felt like more effort than just doing it in Python (Also not saying 3.x is perfect, as I still sometimes get that thought, but I think it’s a lot better (IMO)).
You can try use my curve sweeper for your type of problem…
… what you’re saying about instances doesn’t really make sense to me since I think of instances as equivalent to “singletons” in programming language terms (whereas “instances” there can have different properties, here you are limited to scale and rotation, as far as the geometry goes)… i.e. when you’re talking about multiple instances, they by definition have to be the same… anything you generate that has unique geometry has to be its own instance (i.e. realized). Hope that helps clear things up and why I would take the curve-sweep approach over the instance approach.
Good luck.
Wow, thanks, where can I download your custom node?
Yes your solution is better obviously since it uses curves directly instead of meshes. Mine is just tricking points into positioning them a certain way according to their indexes depending on the number of points within each arc mesh.
Of course with the current language in GN my point about “parametric instances” is a bit of an oxymoron.
Maybe have different “mesh primitives generated from point” core nodes as operations on points (like subdivide mesh which is an operation on a mesh), these shapes would allow field style inputs and wouldn’t require the creation of instances and the use of “instance on points” node, but it wouldn’t really solve the “custom object node” case.
Thanks.
