I wish this was a default node but here’s my group if you want!
It does attribute vector rotation and I use it all the time
This would be a really usefull feature, It would allow to morph points from an object to another.
I know, right?
the task is here
https://developer.blender.org/T86970
But it seem that it will be for 3.0+
no more features for 2.93 i heard
I saw that this node outputs also volume, is it related to “point distribute volume” feature.
I was waiting for that thing.
‘Geometry Output’ node to output geometry from any point in the nodetree:
Object info node to have a ‘Geometry Set’ like dropdown to choose from the list of geometries in that object:
What do you think guys?
the first one is interesting, but I didn’t understand the second node.
Could be used in something like this:
@Pasang I understand how it supposed to work, what I’m not sure is what problems/limitations this supposed to help to overcome. Can you elaborate more on this topic, please?
Multi-Outputing of geometry would indeed be really interresting
But there’s a problem in your concept in my humble opinion
right now geometry node cannot create new object data block, so in order to work it would need a target (to write data on) what do you think?
It would be like connecting the output directly to ‘Group Output’ for each ‘Geometry Output’ node so don’t think it would need other objects as it could store the geometry in the same object. I honestly don’t know how easy/difficult it would be to implement or if it would even work or not. But the idea is cool I think.
It could solve this:
Output the points distributed geometry right before the instancing. There is a ‘Split Component’ node in work that would evaluate the entire node tree but this would work anywhere.
It would also be useful for creating new objects but using another one as a starting point like creating a roof separately on top of a house/building.
I’d love to have the ability to output multiple objects from a single node tree! Makes complete sense as well because in regular destructive modelling it’s pretty common to duplicate an object or separate parts of the mesh at different points.
That’s definitely the case. However doesn’t this process emerge at all because modeling is destructive?
I am also awaiting impatiently for concrete “collection nodes” plans. It’s like helping lego designers design new bricks for us.
Having a second stab at a still life scene here. The only hand modelled stuff is the shadow caster box around the whole scene and the one or two petals per flower type. Everything else was either an instanced icosphere, instanced cube or generated directly within the node tree.
Learned a bunch in the process and also finding more of a workflow that works with geo nodes, slightly by elimination. This process wasn’t it. My natural inclination is to make everything in a single node tree which is great for keeping stuff talking to each other and having the freedom to create that way. Unfortunately the performance got exponentially worse and obviously it was having to recalculate the whole tree so it wasn’t easy going. There is one single boolean being done on the table (subdivided cube having the flat bottom cut with another cube) and I basically had to unplug that to be able to work at all. By then end it was 4-5 seconds to update each new input change.
So lesson learned: Use separate objects. This would solve so many issues I think. I’m hoping it would mean that only the node tree currently being worked on would be updated which should be much faster and also things like transforms would be way easier to manage because you could just move something in 3D. This doesn’t really help architects and similar who need hyper connected models but should be fine for most artists I would think.
Some stuff I already had to split for the scattering like the flowers existed as separate node trees so they could be scattered on points in the basket. There were only 2 foxgloves so I made those inside the main tree.
Dust motes were another object that was just a point cloud (3D Grid with position randomisation) and a little triangle pyramid instanced on it. That worked really well for that instead of doing dust in post because the dust was actually in the light properly which was ace. Really easy process for that.
Weld / merge node would be super welcome for building stuff. Or having the option of loop cuts on the cylinder would actually have sufficed here as it was for making the dented paint pots. I used 3 cylinders stacked on top of each other to get the middle loops but then the Random per mesh island
in the shader would assign different colours to each band instead of the whole pot.
I made sure to keep a wishlist and a buglist this time. I will report the bugs tomorrow but the wishlist items:
- Attribute RGB Curves - this would really help for a bunch of organic transforms with things like cups / vases etc
- Instancing Geo on points with different seeds. Specifically the flowers here. I had to make several specific flowers instead of saying “Instance this other node tree and randomise this seed value for each different instance”
- Boolean performance as mentioned was prohibitively bad. I had to recolour the node to red so I would remember to plug it in at the end in place of my placeholder table.
- When the transform node is selected it would be amazing to have a 3D view loc/rot/scale gizmo to actually transform things. I ended up using an empty to drive the location of a few things like the foxgloves but then if I wanted to make numerical changes afterwards I would have to add another transform node but then my empty was offset if I wanted to go back to moving things in 3D.
- Gimbal lock. Quite a few times I had to stack transform nodes to be able to make the rotations I wanted. Not sure if this is fixable though.
- Do disconnected nodes get calculated? Can they be disabled until a full circuit is made? With the tree running slow it was especially noticeable while building up stuff that I knew and having unplugged for speed (like I would in a shader so it wouldn’t compile) but each adding a node would hang for 2-3 seconds and then it would get spliced into the wrong noodle, sometimes a long way away from where I was on the tree…
- Moving an object in 3D view that is being referenced by a Point Instance node (where the location, rotation and scale don’t effect anything until applied anyway) was not really possible with a heavy tree.
- Colouring frames and nodes causes the tree to update which doesn’t make a lot of sense as there’s no functional difference of a coloured node.
This was a really fun 3 and a bit days! Looking forward to having another go but taking advantage of more objects and seeing how that effects performance. As always, thanks for all the work everyone’s putting in!
Anybody else feel like position and other built in attributes should always come the first attribute on the spreadsheet?
I know this is probably just a familiarity thing with the “industry compatible” way, but I feel as though just alphabetically organizing attributes isn’t the best fit. Since most geometry will have positions and other built in attributes it would just feel more pleasant switching between them without other attributes pushing them to the side.
I’ve been using Blender for over half my life so it would actually be such an honour! Who do I need to lobby for this?
I believe the person who did the current splash screen gets to choose the next one
We are voting for you anyway. Publicate on finished Artworks.
I keep pushing my city scene. The old hair particle system wasn’t precise enough to do this. Can’t wait for edge face instance nodes with tangency whenever they come. In the meantime though, the memory performance is impressive! This scene has about 1700 objects, made of medium poly buildings (60-160k faces each) takes up only 4 gb of GPU ram.
The scene has 2.1m verts and 1.489m faces. Viewport performance is good in solid mode. However in material preview mode, it’s lagging quite a bit with an RTX 2080.
On my wishlist is the following and they are all things that have been mentioned before:
- a way to choose a number of each object to instance when using a collection instance
- tangent edge and and face instance nodes
- it seems that the attributes dropdown doesn’t list all the attributes just yet, like scale and rotation for example? Is the plan that all built in attributes will eventually be exposed in the list popup when choosing an attribute? The popup should work like the material list, with a search function
- I am still unsure how to inverse the impact of the attractor since all the math has to be within attribute nodes. This is one example that would be break the linearity, do all the nodes necessary to get the necessary attributes and join back into the main stack.
- How about a note node without a frame to label things
It shouldn’t. All data is basically lists, so it should then be simple list comprehensions.
The example i mention above is perfect scenario for this. I have an attribude called distance which is the distance between an attractor and the points used for instancing. I want to do do a series of operations like flip the attractor influence. As the system works at the moment, I have to access the points positions. There should be a way to get an attribute out of the geometry, do regular math operations, and then plug the attribute back in.
Beautiful scene! Perhaps the flowers need a bit of random things happening within the lovely fibonacci sequences.
It’s also nice to see how you’re taking GN to the limits at the moment. In my experience on working with node based geometry for over 8 years is that initially, I tried to do everything with nodes. Then I stepped back and realised that a few lines, cubes, or shapes drawn in the viewport and referenced into the node set up significantly simplify the workflow. In this case, we can also have multiple GN node setups in the same object. I wonder how that would impact performance - multiple node trees in the same object. I guess you were rereferring to separate node tress in different objects?