@Paul Spooner Blender 3.1.2 is also what I have been using for the files of this course. For me the downloaded file works just fine in that version. I re-uploaded the file to be sure. Right now I don't see areason why it would behave like that for you. Can you try again?And do you get any error messages from Blender?

@Simon Thommes The problem was on my Linux box. Just opened it in 3.0.0 on Win10 and it worked fine. Clean installed 3.1.2 and that worked too. Guess the problem is with my Linux system, or the download didn't finish. Will take a look this afternoon.

@Paul Spooner Turns out the download on my Linux box was 110 Bytes, so looks like that was the problem. I just figured you had a super optimized save file! Downloaded the full 1.8 MB and it worked fine. Thanks!

@Nicholas Cliffe Oh, I must have messed that up in editing, my bad

@Sebastian Kloch Thank you! Yes, I'm trying to give the entire picture of actually being able to use the concept in a professional environment. I'm glad that's being appreciated!

@claudio Silberman It's good practice to separate logical steps that have value on their own into individual node trees. That means you can use them in isolation on other objects and while working you can disable/exchange them easily without having to shuffle nodes around.

@Simon Thommes  thanks, and I also saw in the next chapter that  you use multiple set position and by having the scattering in a different node it's always on the surface

And then "Math" node's value attribute allowed me to scale the "hills" on the plane just like in the video.

@Eimantas Vaičiūnas The Scale node is actually just a Vector Math node with its mode set to Scale. It doesn't show up as such in the general node search or the add menu, but when you drag and search from a node link (like I do in the video) the search is more granular, so it will also suggest different modes and in-/outputs of a node.

@Simon Thommes This is a neat trick. Thanks! TIL :)

@David Rivera Not sure what you mean. Are you sure that's the right timestamp?

@Simon Thommes it's on 1:11. When you create the mesh grid.

@David Rivera Ah I see, yes.Part of this setup is that I want to be able to manually draw in a density mask. If you do the subdivision procedurally, that means that the original data that you can actually manually adjust  (edit mode etc.), doesn't change. So the resolution of the plane to paint on would be way to low to paint a usable mask.

@Simon Thommes Great. Thank you for the reply. In regards of my other question: How can the user see how "fast" the GN was computed (processed) in time?

@David Rivera You have ti enable the Timings overlay in the overlay settings of the node editor. The time that is shown for the group output is an approximation of the total execution time of the node-tree.

In the end, my large rocks were intersecting with my medium/small rocks in some places. Is this a consequence of the way you set up the node tree? If so, do you recommend a way of having them not intersect?

@Joseph Naughton The next video in this series should address this issue, it's taking the same base setup and adding on top of it for a slightly more advanced workflow. You can use the proximity node to remove points that are too close to other points. Just keep in mind that the scale randomization messes with the radius as well.

@Simon Thommes  I just watched then realised it was addressed there. Thank you!!

@Ingmar Franz I think this has to do with the data type of the color. When I convert the color attribute back to Byte Color which is the default for vertex colors  it seems to work fine without increasing the threshold.

@Simon Thommes Thanks a lot for your answer! So, this surprising result with the "Math Node" is probably a calculation artifact. But how can I know when to use which type of precision. I just found this in the Blender 3.5 Manual (https://docs.blender.org/manual/en/3.5/modeling/meshes/properties/object_data.html#creating-a-new-color-attribute):%C2%A0                                       Data Type

The data type to represent colors internally.

Color

RGBA color with floating-point precision.

Byte Color

RGBA color with 8-bit precision.

@Ingmar Franz What that means is how much data is stored for each channel of the color. 32bit floating point is 4 times as much data as the byte color (8bit). So you are using up a lot more data but get higher precision. In most cases when you are painting a color map byte color will usually be enough, but when you are working with data where you need accuracy, like normal or position vectors for example. It is better to opt for 32bit.

But regardless of that the issue that you identified might actually be a bug. I'm a bit surprised that this happens, as in theory true 0 should be possible with both types of color and the channels should be independent of each other. My guess is that this is an issue with vertex painting that only manifests itself with the higher precision of 32bit color.

It would be very useful if you could create a bug report via Help - Report a Bug with the file you prepared and describing the issue!

@Simon Thommes Thanks a lot for the explanations. I've created a bug report here: https://developer.blender.org/T103657%C2%A0 PS: I've just realized that creating a bug report from inside Blender automatically enters your system informations. But why doing it the easy way if it can be also done complicated (as I did before) 😉😁.

@Ingmar Franz Thanks for making the report! Yes, that's why that is the way I recommend people to do it. Another tip about that: You can also upload images, videos and files simply with drag'n drop into the text field. Working at the Blender Studio I've made several dozens of reports by now :D

@Simon Thommes Thank you, that's another good tip! My free Dropbox account is just 200 MB from it's maximum limit 😉.