@Max Schwall Glad to hear the course was what you were looking for!

Hm, I'm not sure, that should work just as you predicted. I gave it a quick test and indeed it does work for me, so my guess is that there is a small mistake in your setup. Make sure that the capture attribute node is really placed right after the points are distributed, before the instances are created and that it is set to capture on the point domain.

Geometry Nodes have also been improved quite a bit since I recorded this course. For example the viewer node is a big help when debugging node-trees like this. You can use it by clicking on a node with ctrl+shift, once for selecting the geometry and another time for a field.

@Simon Thommes Thanks for replying !! I really appreciate that you are taking time for these feedbacks on our questions.

I checked my script again and the nodes were in the correct order as you described. Also the domain and data type were correct, so I could not find the mistake unfortunately... It seems like there is an issue when I mix data from different geometry types like using curves as input for the geometry and a field that was captured originally from points via the Capture Attribute node. Also in the viewer node all curves appear just black (instead of colourful as they should) with this combination.. Also it seems like the same problem appears, when I try to use the Geometry output of the first Capture Attribute (IDs) as an input for the Realize Geometry node while keeping the field from the second Capture Attribute (position) for the Vector Rotate. Which is confusing somehow as the geometry/the instances should stay the same I guess..

Anyway, just wanted to mention this, maybe someone else has/had the same problem and could fix it :) If so please let me know where I took a wrong turn ! Thanks.

@Max Schwall If there is reason to believe that something isn't working as it should in Blender you can always make a bug report. Here I do feel like there is still some misunderstanding and a mistake in your setup because of it.

>  when I try to use the Geometry output of the first Capture Attribute (IDs) as an input for the Realize Geometry node while keeping the field from the second Capture Attribute (position)

This cannot work, since when you capture an attribute you bind it together with the geometry you capture it on. The field output of that node cannot be used with another geometry, that does not originate from the geometry output of the same node somewhere upstream. So trying to use the field of the second capture node with the geometry of the first cannot work. Hopefully this also gives a hint to the other problems you are having.

@Simon Thommes that was the decisive hint !

@Steven L Fleshman I'm planning to. Time is a bit limited between the movie projects and wroking on Blender development, but hopefully I can extend a chapter about simulation nodes soon

@Jan Simowski Hey Jan, I'm glad you liked the course!

I see what you are trying to achieve, but I'm not sure how exactly you have been trying it so far. I'll just try to explain best I can how exactly I would go about this:

The same as the root position is calculated per spline by capturing it on the instances you want to use an attribute per spline. In this case, as you only need the root position, you can just use the same attribute that is already being captured. Setting the radius, however needs to happen after you realized the curve geometry, as all the different splines needs a different radius and that radius attribute is defined on the point domain. So you can simply add a Set Curve Radius node after the Realize Instances node and use the mapped distance as the Radius input.

The only issue now is that you are fully overwriting the radius you had previously set. So additionally you should add a Radius input node and multiply your mapped distance as a factor.

That should give you the result you were looking for. Let me know whether this made it clear what you were doing wrong before :)

@Simon Thommes Thank you Simon for your quick and on-point reply! Core of my issue was as you mention the missing "Realize Instances". I was thrown off by the fact that the Scale Instance does work for the lenght of the grass before Ralize Instance. Funny enough I even found a combination where the pre-realize-scaling in principle also worked for the thickness of the grass as desired, but without the single blade getting pointy, and I could not marry that with the spline. I got a bushel of tubes so to speak. So ultimately I followed your Advice, and am now calculating a Distance from the position we captured already via Vector Math Node and feed that through a Map Range and a Float Curve into another Set Curve Radius. The Map Range considers how large the patch is, so that the falloff in Thickness matches the size.

It appears I will have to stick my nose more deeply into the "attributes & domains" concepts, as that topic is still a bit fuzzy for me at the moment.

Again, your Series and Help is much appreciated. I took a peek into your Procedural Shader Series already and will delve into that once I feel I got a firmer grasp on the Geonodes. I expect to model for 3D-Printing a lot, so the Geonodes are probably more crucial to me than the shadernodes.

@Jan Simowski That's great to hear!

It's true that the different topics like attribute domains and geometry components take quite some getting used to in the beginning. Maybe try watching the theory parts of the course again. I tried making them as in-depth and at the same time concise as possible for exactly that purpose, so people would be able to rewatch a certain topic without having to go through hours of material. But that also means that upon first viewing some details might get lost, as it's very dense with information.

@David Rivera This was actually the last video from this series. I went over all the fundamental concepts that make out geometry nodes. But Hopefully I can find some time to do another training series that gets more advanced after our current film project.

@Simon Thommes Thank you . you are a great teacher

@Simon Thommes Suggestion 2) Having a random number per object like with the "Random" output of the Object Info shader node would serve a similar goal, again helping to further randomize the application of geo node modifiers on multiple objects. Suggestion 3) (Presumably more complex to implement and control) Imagine an object with one (or more) geo node modifiers with exposed inputs. Instead of manually picking some nice looking ones out of the numerous possible variations (like you did with the four large/medium/small rocks in the rock scatter example), a system that varies all exposed parameters of "instantiated" objects with geo node modifier(s) automatically (each parameter within its respective bounds) would be great to populate large scenes in a fully procedural and non-repetitive way.

@Hermann Vortisch 1) Is already implemented in Blender 3.4 2) We're aware of that use case I want to have it as well. The current idea is to utilize the custom property system to not only pass a random value per object into the system. But potentially multiple that you could also manually adjust. It would just be randomized whenever the object is duplicated. This would also basically solve 3)

@Simon Thommes 1) nice, thank you for letting me know! 2)+3) Is there any way to integrate parameter randomization in the existing UI of the geometry nodes modifier, like adding this "property" in a similar fashion as setting a geometry nodes input to be controlled by an attribute? Anyway, I am looking forward to the solution the blender devs will come up with!

@Hermann Vortisch I agree that it would be nice to have a single place to have an overview of the parameters like the modifier panel. With the ability to access custom object properties in geonodes and also in shader nodes it becomes a bit unclear where that place would be. I'm not sure what the best answer to this is. There are different ideas floating around to package procedural assets in a more generalized way and this topic is part of that.

@Rob Mulally Thanks for the kind words! Yes, Blender 3.4 will finally have an integrated geometry nodes preview system for the viewport, including an attribute overlay to preview fields. That will make it a lot easier to understand what is happening in the node-tree. Also for educational material, like this, this will be incredibly valuable. :)

@Micah Sibert These kinds of questions will become more clear as you are using geometry nodes more. everything follows a clear logic that just takes some time to figure out all the details and fully internalize. So that logic is what I am focusing on in this course. Most of the nodes we currently have  are quite low level and thus not very smart. They simply perform very clear tasks, so what inputs are used for that is in the hands of the user. For example, if the mesh circle was not at the origin, you could still perform the same effect, you simply have to know the actual origin center and consider that in your operations (position - center). But in terms of workflow it is usually good to keep things simple. Split off separate steps into individual node-trees or objects and use instancing in a smart way. That saves performance and does not alter the geometry/shading. Instancing the grass tufts on a plane is what I am doing in the example scene. There is no reason here to stuff all of this into a single node-tree and do the deformation part of curling the blades after instancing.

I agree that for this it would be helpful to just see more examples, but I simply don't have the time to prepare any more of those. But that's were I really recommend just trying things out yourself.

@Kevin Healy There are a lot of areas of geometry nodes that are either in current development, still in the design stage or simply just a plan for the future. I think in a lot of cases it would probably make sense to approach most of these topics in a practical way with a more workshop oriented course whenever the time has come. Volumes for example are an area that still is really limited in what can be done with nodes, though there are some really interesting developments currently!

@Satyaki Mandal The actual vector rotation is done on the position of the points in order to create the curl effect. This happens for each point of the curves with the given parameters for the rotation axis, the rotation center and the angle. So these parameters have to be passed in for each of the points. The rotation center should be the point where a grass blade stands on the ground for the proper curl effect. Otherwise the grass blades are stretched on one side and shrunken on the other side of the rotation. This gets more important the further away from the object center a grass blade is and that is what the first sketch is about. To get this position for all of the points that needs this information as the rotation center you need to capture the position attribute of the instances so that this position is propagated to all points of a curve when the instances are realized. The rotation axis (so the axis around which the points are rotated) can also make use of this root position. That is what the other sketch is about.

The reason that the radius of the smaller blades is smaller as well without realizing the instances is that in that case only one single curve is actually turned into a mesh and then instanced around, scaling it down. That is how instances work, they refer to some geometry that can be transformed independently per instance. When the curves are realized first and then turned to a mesh. This actually happens on each curve individually and so the radius on them is the same, as they are not scaled down afterwards.

I hope explaining tit in more detail like this helps you out!

@Simon Thommes I think that the initial portion of Satyaki's question was a point I am also confused on. We capture the the position attribute, normalize it to get a direction to rotate, and then rotate that direction around the z axis finally adding that to the random value.

@Gary Brimer I didn't realize hitting enter would send a comment. It is confusing that the direction derived from the position of the curve origin would then need to be rotated. The only thing I can think is that we are then using that direction to inform an axis around which we are using to offset points, not an axis around which we are rotating geometry. But it would be nice to find a place to learn more about this type of math. It's always almost making sense. I really appreciate this entire series and without it I don't think I would understand geometry nodes at all. Thank you Simon!

@Gary Brimer Hopefully I can clear this up more: For the curling we don't simply offset the points into a direction, but actually rotate them around an axis. This axis is different for each grass blade though and depends on the grass blade's position. A simple way to create the axis that we need to rotate around is to rotate the blade position by 90deg around the Z axis. This is what the graphic is supposed to illustrate. You can also think of an example: A grass blade standing on the X axis needs to be rotated around the Y axis to be tilted away from the origin.

@陈雨冬 for the time being the videos that are currently available will be the extent of the course. I'm open to add more chapters/tutorials later on, but in the coming months I will be busy with our current open movie production. So during that time that will definitely not happen.