maybe the attr delete node should have dynamic inputs?
It definitely looks quite rediculous when we need to delete a lot of attr
we need loops⊠or at least I think having loops will help a lot in many situations
Mayble a simple text with , to separate attributes to delete or âallâ
Fuzzy search would be really useful might cover this. Eg pos.*
to remove pos.x
pos.y
and pos.z
. It might be able to work so just *
would clear everything.
Agreed, although âfuzzy searchâ isnât the right implementation you are thinking of (that could get quite disastrous), thatâs a âwild cardâ search.
I wonder could we use the geometry nodes on a collection. For example to randomize array of monkeys. Or move apart peices of pre-fractured object?
Yeah⊠and arrays! This would help a lot when creating new geometry
you can chose a âcollectionâ instead of object in point instance node, but I doubt it will be possible for whole collections⊠It would be easy to crash blender I suppose
It should be possible, we need it!
possible to bring back textures after array geometry nodes and spline modifier? or this is BUG?
Hi guys, i got a question regarding the collection instance node. If i remember correctly there was a patch in the works allowing to define the count of each object in the collection. What happened to this ? I would also like to know, if it would be possible to use the bounding boxes of the objects to be used with the poisson disc method to avoid intersection. Thanks !
@HooglyBoogly I saw the speedup with primitive nodes. Impressive ! Is that why tweaking values in the redo panel is incredibly slow with regular primitive creation ? No chance this could be improved ? Obviously I donât understand the specifics (bmesh versus mesh, etc) and I know thatâs not what youâre working on. Iâm just surprised it can be achieved in a context and not in another.
Anyway, great work and thanks for all the primitives !
We need a script node, but one that works as fast a C codeâŠ
Itâs called modifying the source code
In all seriousness though implementing a full programming language might be out of the scope of stuff for a while, not to mention buggy as heck since anyoneâs code is now fair game. That could do a lot wrong to the blender ecosystem. Most users should never have to write a line of code for their modeling tasks, including python. The processor nodes will likely be familiar, performant, and multi-threaded the answer for this.
If itâs well contained and limited in scope, I could see it happening !
Interesting issue. Right now we cannot âframe allâ distributed objects.
The camera is zooming in the center of the original object and we need to zoom back a lot to see the entire scene.
Project link https://www.dropbox.com/s/si4vkg1qr6jbr5g/Zoom.blend?dl=0
P.s. It is strange that we cannot attach the blend.file here.
Also the attribute autocomplete dont have the âScaleâ attribute. Hopefully thats only during the beta testing of this feature.
Seem like it
In all seriousness though implementing a full programming language might be out of the scope of stuff for a while, not to mention buggy as heck since anyoneâs code is now fair game.
In the chat they were talking about doing the processor node and the script node at the same time.
so the processor node would be visual scripting of the script node ect⊠so twice as less work in theory
I am about to use GNodes for a large scenery creation (rally stages for some sim), so I made a quick test and tried to weight paint a 100k vertices âground meshâ to populate some GNodes vegetation instances onto, but the performance is really terrible - the weight painting is laggy, the viewport fps drops even with a very small count of instances.
Feature-wise the GNodes are really powerful and with great potential in many areas, but the performance seems to be even worse than when using particles to me. Or am I doing something wrong?
Is there any chance this will get (significantly) better in future?