Continuing the discussion from Geometry Nodes:
Hello everyone! Tell me who knows, I’m trying to edit keyframes of GEO NODE
, but I can’t see them in any editor. Is it possible at all?
Yeah it doesn’t show in 2.92 version but it works in 2.93 for me
Performance is a subject regarding the new node system
https://developer.blender.org/D10596
The increase seen in this commit (for point scattering) may seem small, but every little bit counts. Larger increases might be expected for more complex attribute usage.
Meanwhile, Vector data can now be rotated
https://developer.blender.org/rBe12ad2bce0cca84a10915d8da1417b71142432d1
5 Likes
Dang ! Thanks. I have a scene with 2279 dominos, I’m sure it’ll help.
Sharing few ideas on how Geometry nodes could support workflow involving Curves. What do you think guys?
17 Likes
Curves are definitively something to consider for Blender Geomery nodes.
2 Likes
It’s not possible at the moment and given the state of the project it’s too hypothetical to state that it will be possible or not. I won’t hold my breath on that. The ID management part could be possible right now (need to be tested to be sure) .
But unwrap and assign texture seems out of scope for now. But as the project is at a very early stage maybe that’s something that will eventually append.
Here’s my challenge. I have 3 sets of buildings. Small, medium and tall. Let’s say they all have 20 different models for each set. I want to spread them. If I put them all in one collection, they will be equally spread on the ground. I would like to be able to dose the quantities. I want more small buildings, some med and just a few tall ones. If I make them in separate trees and join geo, then they will overlap on top or each others.
Nice ! unfortunately you can’t really do that in a simple and efficient way yet :
You can’t set the ratio of instances per collection yet, and also you can’t access the bounding box or dimensions of an object and do stuff with it…
Probably the best way to do something would be to have blocs of equal size, with more or less buildings on them depending on the size of the buildings. Then use these blocs as instances spreaded all over the city. And using a grid or poisson distribution to space them…
Now if you want to add roads and stuff that will probably fail pretty badly…
I wonder how houdini guys do these kind of things, I’ll see if I can find something on youtube…
I think there was a way to do this in City Builder but then again, it’s a software especially designed to build cities.
1 Like
Yes, for now there is really a few nodes available. Some really cool stuff are doable but it’s also very easy to get stuck because a node or a functionality is missing… It’s like learning 3D again …
I thought of something that is slightly off topic. Right now, we have 3 different node editors. Imagine what it will be like when everything nodes gets even bigger. There might be like 10 different node editors, and it’s already hard to tell which one you are in. Before it’s too late, and while it’s easier to fix, why don’t you combine them into one node editor that switches based on context? It would be so much more easy and simple for beginners to wrap their brain around.
But this will not be easy to implement. How do you define context? It would be very troublesome, especially when you need to look at the properties of a part of an object and it automatically switches. So here is my idea: Outliner nodes. In a way, these outliner nodes would be the one nodetree to rule them all. It would have everything in the scene, and let you edit the hierarchy, modifiers, constraints, object data, transform and everything. I think that the development of geometry and particle nodes, and better shader nodes is great! But we need to go more simple first. We need to have a way to edit the lowest level thing before we move up to too many higher level things.
Pictures speak louder than words, so here is my terrible looking mockup on how the default scene would look.
It’s bad, but you get the idea. All of the nodes would have a child of and a parent of socket, to change the relationship. Some nodes would be automatically added, for instance, when you edit an object, a shape node would be added into the data socket. Or when you move an object, the transform node is added, with the coordinates you moved it to. But the system would have an amazing versatility. Need to swap the location of two objects? Swap the transform nodes. This could also remove the need for shape keys. Just use a math node between two shape nodes. You could easily hide objects, by putting a filter node after them. Of course, this would get complicated. But it would give so much power.
How does this connect to my first idea? Most of the nodes would represent other nodetrees. Like the material and modifier nodes. To edit them, you could press a hotkey and you would “enter” the nodetree. From here you can edit the nodetree, and then “exit” the nodetree to return to the outliner nodes editor. This would be very much like the idea of nodegroups.
Anyways, it’s just an idea, but I believe it has a serious potential. Maybe it will only end up as an addon. I hope something comes out of it. However it is done, I want to stop thinking of different node editors, and start thinking of them as one thing. I do want to point out that there are many holes in my idea, and I know that. It’s just a concept.
3 Likes
I just came across the spreadsheet editor concept mentioned in this topic. Something like that could be very useful in combination with my idea.
Is it posible to preserve UVs and custom normals using join geometry? My UVs and normals reset when I join meshes. Is it a workarround or is it planned to be fixed? It would be really useful to me to join meshes in a non destructive way.
I think there’s some good ideas in there. Personally, having worked with Maya for years, I would stay FAR away from a “global node editor”. Why, because it is a mess. I would keep things contextual, with ways to communicate between contexts (just like geometry nodes can now send attributes to Cycles for rendering). However what you’re mocking up here looks like a blend between rigging nodes and “scene assembly” nodes. At some point, if we want to handle big data inside Blender, we’re going to have to manage things from a proper scene graph. I’m not sure this should handle constraints or parenting, since this can be pretty complicated on its own, I’m more thinking of caches, collections and lights. I’m not sure what role would the outliner play in such a future ?
I do like that idea though, “entering” object data like you enter a node group. This would take the scene-wide navigation to the node editor. Tab in an object, you’re into geometry nodes… tab in its matrix info, you’re in rigging nodes…
1 Like
What if, in each “node editor” workspace, you can lock it to not sync with context, like in the properties window.
Hey, that’s interesting for sure !
The data each editor work on is very different, even if they look similar.
I don’t know how it works in houdini, could you mix some shader or compositing nodes inside the same geometry nodetree ?
Wouldn’t that be confusing to have access at all the nodes in blender in the same tree and can’t plug a render output in a shader’s color ?
I think the original problem is how to avoid confusion and know in which editor you are, in that case I think workspaces helps a lot. I tend to switch back and forth between shading and compositing, having them in different workspace help me to know where I am.
I don’t think in the end that there will be that much editors, probably something like a constraint nodetree for rigging, texture node editor : hope it will get revamped but who is using it ATM ? maybe it will disappear…
All the particles and simulation could be added to geometry nodes, I’m not sure other type of editors would be added except some addons.
Maybe at some point something simpler like what you suggest here would be implemented :
In the same fashion we can click on a modifier node bring the current nodetree, clicking on a shader could bring the shader editor if a nodetree is open on the screen. That’s probably something that would be worked on anyway if there is a general confusion .
I don’t know but I’m sure it will be worked on eventually. It’s true that’s would be quite useful to keep UV and other things when joining. That also seems to append when instances get converted to mesh (if you add a modifier after the geo nodes) and that’s inconvenient too.
I don’t know how much these commits would help : https://developer.blender.org/rB4fece16d458e75bc408c62814c9d2b86637ab92e
https://developer.blender.org/rB80f7f1070f177ae543f2fa35dd5d458e87ff30c1
Thanks for the links. I hope this improvements come soon. This is gonna speed up my workflow.
I am separating the points and instancing based on that
The values are in a ratio format i.e. If you want your ratio small : med : big to be 1:2:3 then just type in 1,2 and 3. You can put whatever buildings you want in the three collections, and it will work just fine.
Buildings.blend (1.0 MB) (Blender 2.93)