It looks like you used a “Join Geometry” node to join terrain and cylinders in your node tree. (Both are visible and update if you sculpt on them.)
If I use Join Geometry node that way, I get a heavy growing mesh if I increase instance count.
If terrain (for sculpting) and cylinder-scatter (gnodes which scatters cylinders over terrain) are different objects, performance is fine. but scattered cylinders dont update when sculpting terrain. I had to switch to normal mode and back to sculpt mode to see the changes.
Yes it’s working if you create one big node with everything in it. In theory that will not always happend, especially if you are importing multiple geonode modifier/objects and you want them to co-operate.
I agree with the Object Info node needing a few more options.
Yes Yes Yes!
The geonodes should be able to communicate properly. Nodes should be able to correctly send information from one to another. For example It’s quite limitating that we can’t read the scattered points position once we are not inside the initial system.
Maybe that’s what they are working on with their “portal” system? (on the deonode squad blendeer chat) that would be handy to links stuff from one object to another!
One thing we’ve been considering recently is removing the location and rotation controls from the primitive nodes. Instead you would use a transform node afterwards. The tradeoff here is between the idea of building block nodes that only do one essential operation and the convenience of having the controls available quickly.
We wanted some feedback on what people expect here, so we can make a more informed decision. What do you expect when you are using the primitive nodes? Keep in mind that we’ll be able to instance this geometry directly in the same node tree eventually, which will also give you control over its transform. Is it nicer to have all of the relevant controls in the same node, or should each node limit its scope?
Keep in mind, that portal node is a prototype so we can think about whether the solution is actually worth pursuing. Also, in the context of that prototype / idea, all of the portals go in the same node tree, just on different pages.
Ah my bad, i though it could also lead to other nodetree, that would be quite useful
One thing we’ve been considering recently is removing the location and rotation controls from the primitive nodes. Instead you would use a transform node afterwards.
I’d say it makes sense to have the controls separate from the node. I personally don’t have a strong opinion about it, as you said it’s a tradeoff that can favor both choices, so yay for having it separate.
A thing regarding node primitives I’d like to point out, is that it feels odd to me that to create a primitive, I have first to create another object, add a Nodes modifier on it, and then add a primitive node to the output to “disable” the original object and work with the new one.
It’s not a broken behavior, but it’s very counterintuitive to me. This of course comes from the choice of having geometry nodes as a modifier to add to objects, which feels somehow limiting to me in terms of workflow, instead of having a general node editor that operates without the need of being bound to one or more objects.
Like with materials, the need to have first an object to be able to work in a node editor it’s a workflow I hope will be revamped in the future.
+1 to Separating the Transform from the primitive and May i make an Only slightly related comment Re: Cube Node … i understand a cube technically has same sides… but it would be way more flexible if it had a Width, Length and Height Parameters
We can(in shaders at least) and should be able to create our own groups and expose relevant controls as we see fit. On that note, better tools for creating nodes and exposing controls(not just sockets), please.
I’m happy to keep the default tools more low level as well. We can always create custom tools if we need more. I’m finding in a few of mine that I’m using a transform after anyway so I can scale to eg, create constant offset per cut on a plane.
I would say that the Line node, when set to offset, should keep the Start Location as that feels a bit more fundamental to the Lines
I haven’t see a rationale for these portals. What are they supposed to achieve ?
I’m in favor of keeping the transform sockets in the primitive nodes, they’re handy and can be hidden with ctrl+H anyway -let alone more sophisticated visibiility controls for node properties that might or might not happen in the future.
I do think portals are usefull. The more complex a node tree gets the better it is to group all the inputs together in one place of the node tree. But then you dont want really long connections to cross through your whole tree to the places where you need them. Portals are an elegant way to have a less messy node tree.
But from what i’ve seen i think their “node pages” idea is horrible.
Yes, from what I can tell its basically a hidden connection.
You’re right, just hiding the line(connection) would achieve the same.
But with whatever way they end up its really important to show the all connections while the node is selected and not hide anything in selected state.
If they were to support a unified node graph and allow us to pass data vertically between collection nodes, geometry nodes, shader nodes within the same graph then I’d definitely be behind that. A single scene graph with different tools at different hierarchy levels would be a massive plus and really streamline artist workflows while allowing for properly interconnected assets. However, even then we have groups that let us pass things in and out.
If they’re a design to let us pass data between different node graphs (collection nodes / shaders etc) horizontally then surely that’s what the attribute system is already aimed at?
If it’s about cleaning up long noodles and being able to remote control some value further down the tree, well we have drivers for that. A more visual solution might be having different noodle styles or a remote that you can drop on a noodle and it’ll hide the connection between parts until hovered over.
I’d echo what @Kenzie said about improving groups. Groups are essentially becoming our currency for sharing shaders and now GN assets. They allow for tool hierarchy within node trees. The Attribute Processor proposal is really just another node group with a facelift from what I’ve seen thus far. I think encouraging hierarchy arbitrarily is a bit of a useability nightmare because it basically prevents you from easily connecting different sections now that you’ve put them in a different level. For organisation, frames are best and for packaging tools, groups serve that role.
I say this fully acknowledging that it’s just a prototype to see if it’s worth doing but what’s the use case here? What problem is it solving?
_
EDIT: Plane vs grids. It feels like the right solution to have the option of subdivisions on the plane for sure. The Grid primitive should just be removed from 3D and merged with the plane if inconsistency is an issue.
I don’t mind having to use the transform node instead of having them built in. I think it’s still wise to keep it where it seems needed though, like line (though that may be the only one where it’s needed?).
Also, only slightly related, but maybe there should be a “primitive” menu instead of all the primitives being in mesh? I know they are in “mesh” outside of geometry nodes, but the difference is that geo nodes has operations like subdivide and triangulate, and I’m sure many more to come in the future. Maybe just me, but it feels packed having them all together like that. I’d rather have the operations separate from the primitives, they feel distinct enough from one another to warrant it.
As for portals my opinion is almost entirely what @Erindale has already said. I do realize it is a prototype to check to see if there is value in it, and I think that is totally fair. Just somehow my intuition says it will introduce more problems then what it solves.
I want to add +1 to adding the subdivision to the plane primitive. You are absolutely right, doesnt matter if the original plane object doesnt have it.
