Seems interesting.
But it reminds me of how (to my knowledge) there’s unfortunately zero documentation about what exactly a ‘Rotation’ actually is to geometry nodes.
Mathematically speaking, is it an euler representation? And if so, what kind (axis-angle, euler-angles)? A rotation matrix (I guess not)? A quaternion representation (I guess neither)?
Anyway, looking at how one or another of the newly introduced nodes basically converts a ‘Rotation’ to/from all of the above, it would seem it must be something different alltogether? Makes it kinda feel even more mysterious and esotheric to me.
Currently rotations are stored as attributes and passed between nodes in as plain vectors in Euler XYZ format. After the change is finished, they’ll be stored and passed as quaternions. For now we’ll still show the socket default values in the UI as Eulers, with various nodes to build them from different formats.
The main benefits are better UX, since it’s clear that vectors and rotations aren’t interchangeable (using the few rotation nodes we have is quite confusing right now, especially the first time), and better performance, since Eulers are a very bad format in that respect.
Is it the same case as before that although rotations are displayed as Eulers in the entry boxes we need to convert to radians if we plug in an external value?
I didn’t mean to press you, I was asking whether transformations would be represented with a matrix or with a quaternion plus location and scale information. If I remember correctly there was a discussion about this ?
This could be quite confusing now with the naming conventions, until you know that anywhere a node name has the label “rotation” , it actually means quaternion.
I do wonder if the “euler to rotation” style naming would be better as “euler to quaternion” etc to know more explicitly what is happening. Though I can understand why the sockets themselves would retain the rotation naming.
On a similar note, wasn’t there a proposal to allow all vec3 and vec4 sockets to be able to twirled down to expose each component? Having all of these separate and combine vector nodes really does clutter the node list and node graphs. As a reference, the Unity shader graph does this feature really well!
Not sure how often someone would really need access to the individual components of a quaternion, but no doubt there are use cases. Hopefully there will be a slerp node for the quats or maybe the mix node does this correctly?
What’s current state on Vector2 attribute support?
UV maps have been ported to general attributes, but still them being outputted as Vector3 makes them not fully usable and still need manual conversion to work and export.
With 3.6 LTS out now, the Blender Foundation finally provides us a video (in the release notes) that fully demystifies the workings of the new Simulation Zone and how inputs and outputs work.
It is tricky to understand at first, but the video walks through how to create a basic particle system that at long last lifts Blender off of the bottom of the barrel (since there is no longer any such thing as a start and end frame for particle emission). It also goes through on how updating data for the next frame works so you can plug in things like a particle lifetime. Even in this first iteration, you can do a ton of things that the old system simply cannot do.
Like usual, do not forget to use the knowledge you gain to build up your asset library, but the devs. do plan to eventually ship particle effect presets with Blender.
That is the correct way to present assets that are either more specialized or are heavier on file size (as Blender itself is getting big enough already). There can even be a feature within Blender that allows you to interface with the BF’s asset page and automatically download and install what is there.
I am guessing the reason why the particle demo is there is because it presents a full array of possibilities rather than the building blocks like we already have with hair nodes. I am guessing the bundled particle and simulation assets will come in the same style (accompanied by operators such as ‘quick particles’).
Thanks! Couldn’t see the link (don’t know if that’s because I’m not on twitter or due to the latest twitter contretemps), but his YT channel’s here. Didn’t see it on that either.
This adds support for running a set of nodes repeatedly. The number
of iterations can be controlled dynamically as an input of the repeat
zone. The repeat zone can be added in via the search or from the
Add > Utilities menu.
The main use case is to replace long repetitive node chains with a more
flexible alternative. Technically, repeat zones can also be used for
many other use cases. However, due to their serial nature, performance
is very sub-optimal when they are used to solve problems that could
be processed in parallel. Better solutions for such use cases will
be worked on separately.
Repeat zones are similar to simulation zones. The major difference is
that they have no concept of time and are always evaluated entirely in
the current frame, while in simulations only a single iteration is
evaluated per frame.
Stopping the repetition early using a dynamic condition is not yet
supported. “Break” functionality can be implemented manually using
Switch nodes in the loop for now. It’s likely that this functionality
will be built into the repeat zone in the future.
For now, things are kept more simple.
Remaining Todos after this first version:
Improve socket inspection and viewer node support. Currently, only
the first iteration is taken into account for socket inspection
and the viewer.
Make loop evaluation more lazy. Currently, the evaluation is eager,
meaning that it evaluates some nodes even though their output may not
be required.
