Divide the spline into segments if you need to avoid bending
It’s a workaround, but dividing the spline has its own problems.
I’d rather have a proper solution. @HooglyBoogly, do you know what is the issue here?
This is indeed a tricky one for me too. I’m also trying to work my way around this one.
You can Align Rotation to Euler and plug the Normal into the “Vector” input (NOT into the Rotation), select Pivot Point to Z and align on X or Y.
This on the other hand is normal (I think). The point from the corner would follow the rotation of curve.
I feel that there is a gap opening slowly, between the dev’s joy of inventing new features and the need for basic, polished tools for the average blender user. While we now can display the execution time of a node in milliseconds, i still miss such things like connecting curves and welding edges, e.g. for the skin- or the solidify- modifier, extruding and insetting faces, beveling edges, selecting text blocks or fonts etc.
Maybe the plan to rely on the community for those “simple” things isn’t working so well? Hans recently mentioned that he is disappointed how few community reviewing happens. Maybe this is a clear symptom for having some of us lost behind? Idk. As i said, just a feeling.
If you are interested, I can talk here about ideas and examples made with geometry nodes.
I tried before, but I can’t. Today, after fixing a bug, it became real: Creating the solidify modifier
Here’s an example.
There are still difficulties about finding the primitive data associated with the desired one.
Example: data of all polygons associated with an edge, vertex whose index is known.
Edit: But I think this may partially solve the accumulation of attributes.
Today I tried to recreate the spiral modifier.
(I have not found a way to upload this video here without youtube)
Download here (free)
Problems finding the original edge / vertex normal and applying them to new geometry.
But for now, you can not think about it.
Also, there is no way to create lists of values yet. (There is a topic about this here, but so far it is no news). Otherwise, due to the data about the edges, it is realizable.
Does anyone know how to disable node auto offset by default? When changing it in the startup file, the setting is per-editor, so when you create new GN editor panel, it comes with auto-offset enabled. This means that I always realize it’s been enabled only after it does damage to my node layout, and only then I disable it, and it wrecks my node layout anyway when I create new GN editor.
This should be in the user preferences, not in the editor itself. This is a workflow preference of an individual. It’s hardly something the same person wants to have enabled in some of the node editors and disabled in others, ESPECIALLY not having different state of this toggle in multiple editors of the same type (for example two GN node editors in different workspace tabs).
I am trying to generate some twisted tree roots:
The thing is, that I need to twist the splines making up the roots before I spread them apart using random rotation. If I do it after, I get this, which I don’t want:
I want to first do this:
And then rotate the spline randomly to branch out. I want the rotation to be driven by the Curve Parameter Factor. Here is my problem:
The curve parameter factor will not work before realizing instances:
When I try to use the curve parameter factor after realizing instances:
I lose the ability to transform individual root branches because they’ve been merged into one mesh and lost their individual transforms.
Is this a bug? I don’t see any logical reason as to why I could not use Curve Parameter Factor before realizing the instances. Originally, I thought the problem is that before realizing instances, I am transforming (rotating) just a single curve in it’s own space, therefore twisting the curve around it’s infinitely thin radius, but this would mean if I use location of some static point instead of curve center, then the rotation around Z using Curve Parameter Factor as the amount should still result in the spiral, but it still doesn’t:
So how would I go about twisting the curves into a braid before realizing the instances?
Until realized, all your instances are just points, with a reference to geometry.
You can NOT modify geometry.
For this reason, I first copy everything as an array, given the index attribute. And then I use it to randomize the real geometry.
Ah, that makes sense
I am curious about couple more things.
How would I go about transferring the curve factor to geometry when turning curve to mesh? The Capture Attribute node seems to do exactly that according to the docs: Capture Attribute Node — Blender Manual but in practice, it doesn’t seem to work despite being set up the same:
The output attribute has no effect. I’d like to bake the Curve Parameter factor into the vertices of the mesh as a float attribute.
If I successfully managed to capture an attribute, how do I store it for later use? I mean how do I name the attribute to use it down the stream. I can’t imagine having to make complicated cobweb of super long node links just to use that captured attribute in the rest of the node tree.
That would be a job for transfer attribute, but it doesn’t work on curves in 3.0 you have to use master
I thought you were part of that discussion a few weeks ago, when named attributes were removed ? Yes you do have to make long links if you need to capture attributes from early in the tree and use them much later.
That being said master has hidden links now I think ? which mostly solve that problem
I don’t believe that will solve the problem. you will still have ugly cobweb going out of the output socket to numerous destinations somewhere:
And you will still have node links arriving to some random input socket from miles and miles away, requiring you to trace the link back over long distance to find out what’s actually plugged in there:
I can’t see how that could ever be an alternative to storing capture attribute output under any custom name and then simply getting it in a form of get node down the stream. You won’t have dozens out outputs going out from somewhere, and on inputs, you will immediately see what’s plugged there, instead having to track down the source following long wires
Yes this is why I said “mostly”.
I also don’t consider hidden links alone as elegant or practical as get/set nodes, but with a few more improvements, maybe ? (named hidden links, portal nodes, etc)
Yeah, unless there is some concept of naming of the links, it won’t solve the problem. And once there is a concept of naming of the links, we’ll just have worse, less explicit ways of doing the named attributes
- You need to capture the curve attribute ON the curve.
- Group individual actions into nodes! It is important! These are functions! If you can’t group them, then don’t complain about the sizes!
what do you think would be more compact?
Sorry, but that makes no sense. There is a big difference between evaluating function at each step and storing a result of evaluated function as a data in the topology.
For example imagine you have a tree, and you calculate a vertical gradient from top to bottom based on the geometry bounds. Then you bend the tree, and then you want to access that vertical gradient again. If you create a function that generates vertical position gradient and evaluate it on the bent tree, then the result will obviously be wrong. You no longer have a gradient from the bottom of the trunk to the tip of the tree, but bent. It’s not longer a gradient along the bent tree height.
That’s just basic programming concept. The step at which you evaluate the data matters, that’s why group encapsulation is not a solution to many things.
I really didn’t understand what you mean, but for me there were no problems in estimating the thickness of the barrel
The problem is interesting. Is it possible to immediately inherit interpolated attributes from the domain when distributing points?
it would be possible to inherit the polygon number and uv to move between polygon points, but …
I have another question. When I generate something using curve to mesh, the resulting mesh correctly generates UV mapping along the direction of the spline on the generated mesh. But how do I modify this UV mapping?
I mean, if I can define the attributes only on the group input, in case of the root GN node tree on the GN node tree input, how do I access the UVmap attribute which has been generated by the Curve to Mesh node so that I can transform it? Because obviously that attribute is not present on the input, it’s generated inside of the network. O_o
Found it. I have to capture attribute of the U spline and V spline factor making up the spline mesh. But it’s still crazy I can’t just store this as a named “mapping” attribute, and instead, every time I want to reference this UV mapping I’ve created, I need to drag out crazy long line from that one socket.
Some time ago someone asked about an example of how lack of named attributes limits the workflow. This is exactly how: If I want to use the UV mapping of the spline generated meshes I have now generated multiple times down the tree, this is how my node tree is going to end up looking:
I don’t see how something like this:
Could ever be considered a threat to GN fields design, or substituted by this: ⚓ T93293 Hidden links
The idea of a scripting language where you can’t name your variables is insane
What’s even more worrisome is the idea that this will be he solution: ⚙ D13675 Nodes: Support linking to named reroute from link drag search. I can already see the horror of hundreds of wires going all over under the nodes. All that effort spent to reinvent the wheel of variables with names.