I kinda of understand that, but Blender is not a procedural software. So, GN looks like a whole different thing inside another thing… if that makes sense. In terms of design phylosophy, that’s the whole point of the mentioned shareability. Just give some nodes to people by default, already inside Blender. That’s all.
Solve basic needs, make people want more, people will download and buy more node groups and add-ons. But first, give a few and basic node groups who will solve basic needs within the DCC.
Right now, I see this way:
Blender is easy, GN is Hard, so let’s make even harder letting only low level nodes populate an already complicated system.
@DimitriBastos That is a good idea. It have already materialize in this form (see link, not finish), although I don’t think there is GN in the Bundle yet.
As for accessibility, Shader Node can already be quite hard to grasp if one want to build something more complex (See Nodevember).
Blender is and will stay a professional tools.
Turning the default Cube to something like Agent 327 or Sprite Fright will always be hard
Edit :
@DimitriBastos One thing I could add. Since 2-3 years there is a Huge boom of Blender tutorial on Youtube and others platform. Also Blender Market (and others free, see Baking Addon by Daniel) are making Blender quite ‘‘newbe-friendly’’ !
This is probable the most strongest point of Blender (and I know also for Unity)… Having this Huge community that can help you resolve problem and find solution super quick.
Also I’m sure with the Asset Browser there will be plenty of free and paid Asset bundle available in the future.
Sorry if this is off-topic, will stop right here. Just to finish my thought, It sure is hard. But Shaders have a Principled BSDF, for instance, and GN currently doesn’t have an easy to use node group even for the most basic needs.
And GN can be as professional as it needs to be, and even more, without alienate everyone who isn’t a technical 3D professional and let all the rest hoping for the first group to share something that the second group could finally use. Otherwise it will just be a “get good” situation, which doesn’t fit the Blender phylosophy in my opinion.
The Team even knows that the Asset Browser could be used on this matter, as it was discussed before on official blog posts, I just think this should be a 3.0 priority specially due to its importance for Blender as a milestone release.
EDIT: @fr002 , I agree with everything you said, but I just think that either way Geometry Nodes could benefit of having a few assets bundled on 3.0 release in order to help people out. I see and completely understand the community aspect. In fact, It was the first thing that make me use Blender in the past. It doesn’t change the fact that it would be a welcoming boost of usability in order to make people more confortable in using Geometry Nodes.
I also think this is important, and I’m excited to bundle some node groups with Blender. However, at this point it’s definitely not happening for 3.0, for two reasons:
The basic asset browser work is still finishing up, and it doesn’t support node groups as well as we would need yet.
There isn’t enough time for it given the time constraints of finishing up the fields conversion.
So hopefully this could be an area of focus for 3.1, we’ll see.
Fair enough, @HooglyBoogly and thank you very much for your input. I’m sorry if this was already stated before on another post, I was just trying to give some constructive feedback from another point of view.
I’m looking foward to see how this evolves in 3.1.
Is it possible to convert a field to a normal data ? i didnt get the whole concept of field so im asking, in this simple example, how can i randomize the z location ?
I didn’t understand what you meant by " instead of adding a key and adding a modifier in the graph editor" but, here is a random vertex displacement, this should kickstart your journey,
I’m not trying to displace the geometry, already made a little custom node to do that, im trying to have a random number on the z axes of the OBJECT, not the mesh or position.
The only way that I can think of (it’s sort of a workaround) is that instead of leaving the Index input of the ‘Random Values’ node unplugged you can try and plug in a ‘Value’ node with the value set to 1 so that the ‘Random Values’ node can output a single random value.
that’s what i was thinking about, but as float usually have a grey circle i didnt think of plugin it, so the green circle is for integer ? it should be grey and when we connect it with a float number it should do a round operation automatically
Yes, usually the little grey circle is used to represent float values (and green for integers) but from what I’ve observed, currently, the Blender node editor system doesn’t seem to be bothering too much about having matching input types (float, integers, vectors…) connected correctly to each other (meaning that if you plug a float value into an integer input or vice versa, for most of the times they’ll be working just fine. The same thing about how Vector values can be plugged into Color input sockets and they still work perfectly fine). But I agree, perhaps for the future, a little update on switching the color of the input sockets to match the types is properly going to be a vast improvement. And also, if I remember correctly, the last time I check, if a float value is connected to an integer input, the rounding operation will be automatically handled for you.
I’m interested in understanding better exactly what the trade-offs are between fields and attributes. I’ve tried to read this whole thread, but I haven’t seen developers mentioning the repercussions of fields. I don’t think all of those repercussions were immediately apparent to everyone commenting on the fields proposal. I think coders can often see the long-term impacts of decisions more easily than users can, because every time there’s any conceivable ambiguity, they get smacked with it in the face and have to make a decision about how to handle it.
I’m still in the “who moved my cheese” phase of dealing with fields, unfortunately. It seems to me that one of the issues with fields is the ambiguity: when we get position, when exactly are we getting position? With attributes, that was clear: we say what position we’re operating on by our noodles. To deal with that ambiguity in 3.0, the answer is, “we get the position immediately before we start evaluating the GN modifier.” While I can’t put my finger on it, I have this intuition that we may have some trouble with turning attributes, mid-stream, into other attributes; that resolving the ambiguity in this way limits what we can potentially do with a single GN modifier. But this is only an intuition, something that feels risky. And even if it is risky, there are potential workarounds, even if they’d be clunky.
It seems to me that the main advantage to the fields implementation is that we no longer have the MixRGB/Attribute MixRGB kind of duality; unfortunately, the 3.0 implementation makes it look like that node savings is more than made up for elsewhere. And it seems to me that a fields implementation is not actually necessary to solve that problem, because it could be abstracted behind interface, with Blender silently making a decision about which to use on the basis of noodle connections.
There is no ambiguity of where the position comes from in 3.0. The quoted sentence above is actually wrong (there might have been a tutorial that got this wrong). Which position is used has nothing to do with the modifier. Instead the position comes from the geometry that the field is evaluated on. Maybe the image below makes this more clear. The red arrow shows what you said (if I understand correctly), while the green arrow shows where the position actually comes from.
Obviously, Blender decides to do something here. There is something that it does, and consistently so. But I’m not sure people are going to be able to predict from the nodes.
These are artificial examples, and there are other structures we could use to remove the ambiguity, but I think once users start putting a lot of nodes in a graph, they’re going to run into problems with their intuitions related to these kinds of things (and the fact that there are hundreds of nodes is going to make it much harder for them to figure out where the problem is.)
These examples are less obvious indeed, and require a bit more getting-used-to. I do think that many of these low level nodes will be wrapped by more powerful node groups that work in a more obvious way in the future. Still, there is no ambiguity here:
In the Transfer Attribute node, the Attribute input is evaluated on the Target geometry. The Source Position on the other hand is evaluated on the geometry passed to the Group Output.
In the second example, the first Vector Math node is actually evaluated twice. Once on the position of the geometry passed to the the first Set Position node and then again for the second Set Position node.
