I think that boils down to “geometry fields”, and that’s not coming
@sozap @moshus loops indeed looks fine for this job. I hope that in the future we will have simulation clock decoupled from scene clock as having them together won’t have much sense in a lot of situations.
Preferably I’d like to have Clock Node that can generate N frames for given part of the node graph.
@Hadriscus haven heard that term nor why it wont happen?
1 Like
Hoping we will have a loop outside of simulations without a clock at all or coupled to any kind of frames. One that instantly calculates something for n times (and just lasts as long it takes, like other nodes in the normal branch) . But maybe that is what you are meant.
1 Like
Kind of yes. Having to use timeline to generate N number of static assets is too much micro-management and there should be a better UI idea for it.
2 Likes
Sure ! Loops and simulations are two different tools, and both are needed for a complete procedural system.
Since GN develops hacker’s instinct in everyone using them, of course people try crazy and inappropriate stuff , like using simulation to emulate these simpler “for loops”, where you specify a number of iterations that runs on a bunch of nodes when the graph is evaluated, without taking time into account. This is something planned as well !
I’m pretty sure that once we’ll have simulation loops available these one will be done soon after.
Why devs decided to start with simulation rather than these simpler ones ? : hard to tell , probably since simulation opens more possibilities, or maybe they are more inline with the hair system, that will also need simulation in order to be fully replaced ? …
Time will tell, but I think we are on the same page !
4 Likes
There was a bunch of us some time ago who tried to generate several primitives at once by plugging a field into the primitive’s dimension inputs, as if the geometry data could act as a field and output as many suzannes as the attribute array is long. But it doesn’t, so simulations are welcome here.
2 Likes
You can create mesh in GN, connect attribute that you want to Group Input (so it appears in modifier tab) and then instance it on object level in Animation Nodes, than can give you full procedural control over modifier attributes. Hope video will help
I need random per UV island
Cycles:
Eevee:
5 Likes
Many ways to skin this monkey:
…and the principle follows from Island Index.
Pretty sure Xeofrios’ method would be more performant tho.
4 Likes
Any chance someday that they add random per uv island directly to eevee and cycles?
6 Likes
It would be even better if this kind of imagery bound for the Geometry Nodes thread was made in Geometry Nodes. I do believe this can be done in Blender without too much difficulty 
2 Likes
So, Lukas just dropped the matrix nodes. This is going to be FUN
12 Likes
they’re useful for what exactly ?
A matrix represents a full transform. It doesn’t say anything about how to get there, contrary to euler angles, and it can be interpolated to and from smoothly. Surprisingly this operation is called a multiplication. Internally in Blender all object transforms are stored as matrices, constraints use them as well, etc. It is the preferred way of orienting stuff around. It’s useful for rigging, because you can mix transforms exactly the way you like instead of relying on a weird combination of hardcoded constraints. It’s useful for scattering/orienting stuff along a curve, instead of storing independent tangent/normal/binormal axes, you’d store a matrix. It also goes very well with the geometry nodes mantra of giving access to low-level components and build higher-level node groups from those. I can only assume the future node-based constraints are going to use this type extensively.
This is to an extent possible with a quaternion representation of rotations, which is the argument raised in the PR discussion. I personally feel the pros outweighs the cons greatly
That being said I am not technical enough to judge the precision concerns raised. But generally, matrices are absolutely central in 3D, so it makes sense for a tool aimed at TDs to offer them.
13 Likes
In simple terms, a matrix could be described as a vector of vectors. Instead of just storing a single value (like a scalar), or a list of values (like a vector), a matrix can store an array of values. Kinda like an excel spreadsheet all contained in a single socket.
Why is this essential? It makes tasks that were incredibly complicated and messy much simpler and easier to handle. Before, in order to customize transforms and such, we had to make matrices and manually preform operations on them from the ground up. With matrix nodes, we’ll be able to reduce these complaints tasks into simple setups.
For reference, here’s what you used to have to do to simply multiply a matrix by a vector:
When matrix math nodes are implemented, we’ll be able to do this with one node.
8 Likes