Yes. Thank you for recognizing all of these downsides of the current approach and the otherwise advantages. The proposal should make it a lot more intuitive in many situations as well, such as using Point Transform after instancing to actually move the instances.
I was also baffled on how the system works until I realized the dedicated Instance entry in the spreadsheet, and was wondering how to add and use attributes with that.
About the downsides, I think it brings as much intuition as it theoretically takes away, so I think it’s a fair trade. You could consider to automatically add the conversion node when using modelling nodes after instancing, but it is arguable if it’s what the user would want.
Like @Hadriscus mentioned, avoiding intersections is one of the most desirable features when scattering, so it’s good to make steps on getting there.
I like this proposal. In the current system the user would always need to be carefull when using some nodes that just automatically realize the instance. I don’t think needing to be aware of instance is a downside, I think once the user understand using instances can have better performance, they should already know what an instance is. Never mention Blender gives a different outline color to instances, I think it is obvious enough.
Great proposal, I like pretty much everything about it. Attributes on instances in particular, been waiting for this one pretty much since day one.
Although other modifiers in the stack should probably display some kind of warning if instances from geo nodes modifier are not realised and cannot be processed. Ideal solution would be to convert whole modifiers system into everything nodes framework, then instances could be transferred between modifiers automatically.
Sounds great! I particularly like the potential to pass instance attributes into Cycles and Eevee, which will make for a very powerful workflow.
I am also happy to see that the instance node will be renamed to instance on points, as I always thought that point instance was a misleading name. On that subject, are there likely to be instance on faces and instance on edges nodes in the future?
Which begs the question of if it is a better idea to have a single node with a domain dropdown for point/edge/face. Though arguably you do need more options for instancing on edges and faces, like a percentage slide between points for edges, so maybe they are better as discrete nodes.
Morning, @jacqueslucke .
Please tell me, will the camera culling feature in Cycles also benefit from it? Currently, when you instance a million objects with GN, the camera sees it as one object, so it can’t cull instances that are outside the view cone, which takes a lot of functionality from the built in culling tool.
Thx, and again: Bravo!
Regarding that, I also have something to ask. One of my friends had made his own camera culling node group in 2.93 and he is looking forward to updating the node group to field once the development is done.
But my question is, is instancing Geometry now already doing culling by default? I downloaded the WIP patch way back and found out the culling behavior because it was super obvious, a bit too obvious to a point that was kind of buggy. And later in the diff page I read this:
Then later on it was fixed and got committed. And in master it is unnoticeable now, it is nice but I am no longer confident that it is actually doing the culling now because I just cannot tell. I want to ask @jacqueslucke is the Geometry instancing mode already doing culling by default? If so then it is super cool I can just go ahead and tell my friend that he no longer needs the node group now
Like others already said, the user Being aware of instancing is probably desired, after all, It’s a very foundamental concept in 3d graphics in general, and having warnings when instances can’t be processed can have also de good side effect of making beginners aware of the concept of instances, and incentivize them to investigate the concept, so… better feature discoverability!
One Idea that It’s probably related but maybe not directly to instances: when COPYING (not instancing) full geometry to points it would be great to transfer non constant attributes from points to the copied geometry and have them affect the original geometry per Copy.
Example: let’s say I have a “leaf” geometry node group that has some “bend” attribute that Deforms the whole geometry before it gets output from the group. If I scatter (copying, not instancing) the “leaf” geometry output on a ground plane, I’d like to have a “bend” attribute on the ground, maybe generated by a noise texture, that get transferred back and input on every copy of the original “leaf” group. So every copy of the leaf can have a different random bending depending on where it’s positioned on the ground geometry.
As I mentioned, I Know that It’s not Instancing, but I think being aware of the possibility to add such feature can somehow influence the decisions taken when designing instancing workflow.
Just for your information, we decided that explicit instancing is the way to go for geometry nodes.
I don’t plan to have a node just for instancing on edges/faces etc. Mainly because there would be many different options indeed. My hope is that we improve the abilities of node groups in the future to make it more feasible to create these more complex nodes as groups.
For geometry nodes itself, I think we can have nodes like Faces to Points or something like that.
No it is not. The thing mentioned in the screenshot is a little bit related but not really. This was just about culling at render time but not when preparing the data.
Sounds like something that could be achieved with a “loop” or “geometry field” mechanism in the future. Maybe in Blender 3.1, we’ll see. We still have to do more design work on that topic.
Yeah, like “for each point:
read bend attr on points
apply bend attr to geo group bend input
copy geo group on point”
I just thought that It could be a directly implemented feature in a possible “copy on points” group. But having general a looping system would be amazing, can’t wait. You devs are rocking!! Nice to read that you already decided for explicit instancing!
as explained in the post, not having the automatic conversion when working with per mesh-element instancing can cause problem down the line, as there will be attribute missing errors
Hey @Eary
i think what we all want is some optimization option at an instance level
for example an new “Instance Viewport Optimization” panel either per scene or per object
The problem is linked with instancing, not with geonode, so that’s a task for devs in charge of the viewport imho
Hmm not so sure about that. If I understand it correctly, in order to support geometry instancing, Jacques already changed the lower level logic of how instancing works in Blender in general, he made changes that was more than just the node system itself, he made sure the new instancing works with render engines and exporters etc., so I think it should still be related to the GN module.
I like this proposal, though it may need a selection field input? Mesh to Curve has a selection input so maybe this one also need it.
Just got an idea for circle packing with manipulatable instances. The poisson disk distribution mode was nice but it only made sure the points don’t overlap, not instance.Therefore it is common to see some areas with smaller sized instances having gaps while areas with larger instances being packed.
What about moving the point elimination logic to instances? For example, detect the bounding box or convex hull of individual instances, and don’t put the intance on the point if the bounding boxes overlap. Like instead of eliminating points, eliminate the instances. With explicit instancing this should be possible, right?
Edit: Second thought, perhaps not removing instances since it would still leave a hole there. Maybe just scale the instance down until there is no overlapping.
That still sounds like something that can be achieved with a loop mechanism. Like just instance geometry on a poisson distributed set of points, after the geometry has been instanced, the loop starts:
For every distributed point until every intersection check is false:
-Run an intersection check with neighbors, if current intersection is true then:
-Reduce the current point scale by a given step
This is the first brute force method I can think of… i bet it can be more efficient.
But what if you need to keep the scale of instances constant? My guess is that there are already well established methods for close packing objects in 3d space, since it’s an old problem.
Yeah, for sure there are already known packing algorithms, I guess
In the case that you mention, if one wants to keep the scale constant, I guess the point distribution can’t be done prior to the instancing, at least if the criterion is based on intersection. The distribute node has at least to know the bounding box/convex hull or full geometry that is being instanced, to re-distribute/delete the points according to the non-intersection condition.
I may have missed something while reading the proposal, but I see no mention to animation and instances, and automatic handling of animation offset of the same instances, that’s an important matter too, a forest does not move equally and a bunch of ducks don’t fly in sync
Unless it’s just transforms of the instances which are animated, then they are no longer instances. Especially the flying ducks example, which is certain to involve mesh deformation. At that point, each unique frame of the animation is more or less a unique mesh with its unique memory.
That’s why I say “automatic handling” because you may be able to decide how many “animated instances” you have, so for example a forest with with 1 million trees, 3 different models and 3 animation offset per model, that means 9 unique models to fill up 1 million trees in a forest
Yes please, also with an option to convert vertices to points
we keep having errors in our studio when working with raw-vertices because of missing attributes
And having the little octahedron display is very nice for visualization
Is it too bad if I post the same message twice in different threads?
I’m not sure if this is planned already or not, but I have found that the ‘Geometry to Instance’ node would be very handy. The node does the opposite to ‘Realize Instance’.
Why it might be needed: it would make possible to create different geometries and scatter them in one Geometry Nodes graph.
