Blender Conference 2024 Talks

General Forums Latest News
43

I don’t get it, either.
Currently, hidden behind an experimental tag, we have volume nodes for geometry nodes.
The idea will be to mix volumes from meshes, with volumes from OpenVDB files/caches, with volumes from math formulas.
If they could be used as node tools ; they could be used in any mode.

I understand that Hans could not be everywhere.
But his work on SDF volume nodes could be continued by somebody else.
Or that could be something happening next year, after current sculpt mode targets (brush refactor, dyntopo refactor wrap-up, multires improvements).

44

I think the design of volume grids was still in the oven.

1 Like
45

I trust the developers to make reasonable decisions as to where the development should be heading for Geometry Nodes, primarily basing it on what users want would be naive in my view.
There are two quite large development directions as far as I can see. There are simulations and there are volumes (including SDF). But, there are quite a few core issues within Geometry Nodes. Instancing is one of them. Another one as far as I know is to make it possible to use Geometry Nodes as assets. I am sure there are more.
Whatever they decide to tackle, they need to make sure to consider the other topics that exist. Even though SDFs appear quite popular at the moment (at least in this forum), it would be stupid to push this topic forward if it would lead to more issues or if it would make for instance the mentioned core issues significantly more difficult to solve.
The people who know best whether those kinds of conflicts exist and what appears to be the best way to tackle them, are the developers and the developers alone. Sure, if there are options, it is great if they involve the community.

46

I maybe misunderstanding, you can mark a Geometry node modifier as an asset.

You can drag the GN asset onto an object as a modifier and even inside another GN modifier as a node group.

1 Like
47

Last time I checked, sharing was still problematic. So that might not anymore be a problem.

48

Yes and no, the same thing applies to sharing shader node groups, you need to share a blend file (even empty with just the node group with a fake user). I do not think it is problematic.

2 Likes
49

Depends on the geonode. If you’ve hardcoded some drivers in there, or other objects - yeah, can be an issue in some cases. But hardly different than sharing a blender file without packing the textures.

But consider someone like Higgsas shares setups on a regular basis, and we can make use of them with no sharing deficiencies.

50

Is it just me? I often find the whole asset management in .blend files awkward. Not being able to just edit everything about an asset from Asset Manager is awkward. I wish that if I see an asset, I could just edit everything about it no matter what file it is in.

1 Like
51

It’s not just you. I tried (again) a couple times last week to append a rigged character, and see if I could work with it in some stress-free manner. Nope. Overide this, overide that, wonder if i’m supposed to be doing that, wondering what might still not be working, and several different menu commands that all have a similar name and aren’t much help in deciding which one i should be using in the first place.

Working with assets feels like an anti-feature. It feels like a team of people tried to cover every possible scenario of “what might someone want to do”, while oddly making it difficult to understand (or even accomplish) what an average use might want to do. I just want a paintbrush, and someone is handing me a horse and pine tree and telling me how i can create my own paintbrush with no restrictions…

2 Likes
52

I wonder how assets could be improved to remove this awkwardness. I cannot think of anything though. Can you write to another .blend file without opening it?.. Can they be opened in the background?.. Is there a fundamental flaw in the whole design of the system?..

1 Like
53

I have not done too much with assets, mostly materials and GN node groups. You can edit those in the file you append them to, but that does not change the asset in the assets file (probably a good thing for me)

I do not think so, if you need to edit the original asset for future projects you have to edit its file in the asset folder.

I agree that it does seem a little convoluted to organize but I am getting used to it.

Not sure about characters (I have not animated any), but as a test I marked an animated traction engine as an asset.

It was loads of different objects with a huge rig all instanced to a different scene to move the instance around as a whole along a path, while the mechanics are animated in a different scene where the engine “runs on the spot”

I marked the instance as asset saved the file to my asset folder and dragged it into a new file from the asset browser.
The result was both the “static engine” with the rig and animation + the instance that follows its curve.

I think that is logical because the instance refers to the static objects and rig.
The animations are also imported but if you want you can delete the key-frames.

It is all still editable and re pose-able.

Not sure about “overrides” I have never used them, nor know why I would want them in this case, (this could be my ignorance)

54

In my humble opinion, it would be sensible to not wait much longer with implementing an SDF modeling toolset if Blender doesn’t want to fall behind. SDF modeling is rapidly rising in popularity because of its accessibility and powerful modeling capabilities without topology worries.

Blender’s metaball toolset is ancient and dated, and volume to mesh functions are already there in Geometry Nodes. Add-ons like Blob Fusion and SDF Prototyper already make use of it for SDF modeling tools. Adding a dedicated SDF toolset is not a matter of starting from scratch anymore in Blender.

2 Likes
55

I think exactly the same. I would not expect it to be perfect or even take lots of work at this point. I would expect(maybe wish) it to be sort of minimal viable product, which would be great. I think the whole idea to ship anything at all so it can be improved with user feedback would be perfect for SDF. It’s new, nobody knows where or how it is going to go at this point. It would be logical to act as soon as possible now. Have no idea what Ace_Dragon is talking about. I think it would benefit a lot from more open kind of development and even making mistakes and trying things out the sooner the better. It’s also exciting. Which is important. I want exciting stuff to play around with as soon as possible. :smiley:

This sort of looks a bit like Geometry Nodes to me. How many changes have been made? How many things broke when nodes where changing constantly - it’s such a mess! I love it! I want that with SDF :smiley: Bring it on. :smiley:

Huh? What’s that about? Long-awaited? I mean, sure, improvements there seem absolutely awesome and very welcome, but who had serious problems with that? Modelling and UV mapping? Who is complaining about that in Blender? I mean, considering all the picture with improvements happening and all. Those “tentpoles” are steady, no idea where the paranoia is coming from.

2 Likes
56

My whole post was an explanation as to why it is stupid to just go for it. Sure, it might be possible it won’t cause issues down the line, but I don’t know. Now, you are saying to just go for it, even if it was to cause massive problems down the line?

Edit: To be very clear. If the developers were aware of problems it might cause down the line and they would go for it anyways, this would be literally a waste of resources.

1 Like
57

Looking forward to what they conclude with the survey… And what the most wanted features/wishes are…

58

I think it is also quite reasonable to envisage items, included by default in their survey, as possible targets for close future years of development.

I think that issues encountered with Geometry Nodes are a lot more specific than that.

Instancing was the first benefit, brought by geometry nodes.
We have now a workflow to instance, more satisfying with geometry nodes, than previous ones with particles or parenting.
A new field was open. And issues about it were discovered.
There are bugreports about Realize Instances node. It is not preserving enough data in some cases.
We may consider that we are facing lacks or new limitations. But they are a lot less numerous than the ones of older workflows.
I don’t really see why there would be limitations preventing to use the feature ; because Geometry instanced would be SDF volumes.
I don’t see flaws in the idea to reuse current workflow to instances them.

Yes. Volumes are costly. Users have to be carefully, manipulating them.
But 4.2 Geometry Nodes are already able to instance volumes.

I don’t expect anything about Geometry Nodes to reach all expectations in one go.
I would expect the feature to grow incrementally, like what happened for the rest of Geometry Nodes, we currently have.
But in this case, people would be very frustrated if they could not use fields with them.
That makes sense to consider, that could represent an overload of work of new bugreports to triage.
Hans only completed two milestones on the five detailed ones.

But to me, development is not what is present, in the official release.
I think that could be possible that somebody will work on milestone 3 in 2025.
And on the other hand, the task exists. There are nodes in main branch.
We are not in a situation where nothing would have been done on the subject.

59

Is that was already clarified and “translated”?
What Ton is push people to think of? Donating more money because someone get too much? Finally bring basic tools to blender?

60

@moderators: Excuse the inconvenience, there is a lot of off-topic discussion going on here. Maybe someone can try to split that off, when you have a minute.
To make your life easier, I tried my best to make a list of which posts (seem to) adress which (out of several unrelated) foreign subjects (I’ll give the discussion about the keynote and what Ton did or didn’t express there the benefit of the doubt).

Posts about the possibility of native sdf-support:
#35
#40 - #45
#54 - #56
#58
#62 - #64

Posts about asset management:
#46 - #53

greetings, Kologe

2 Likes
61

That’s not my point.
There are always issues in software. Geometry Nodes is very new and instancing is just one example where it is not yet complete. It would be surprising if there aren’t more loose ends.
When you continue the work, you have to make sure that you are not making the fixing and finishing of those loose ends significantly more difficult. (As well as other planned developments)
The people who have the understanding in that regards are the developers. Even if the the survey shows the community wants feature X and all the development fund contributors want feature X too, it would be stupid to just go for it, if before that A, B and possibly C need to be properly prepared first.
My interpretation of what I am reading here is, we don’t care about A, B and C, we want X no matter what.

62

OK. But if there are A,B and C considered, developers could communicate about that.

In 4.3, we get Grease Pencil features that required a refactor that took time.
They were blog articles to explain it, and users understood.

I think that everybody, on this forum, already heard many times exaggerations about a fall of Blender, if such or such feature was not adopted immediately.

It is true, that SDF modeling is popular, interesting for being at same time intuitive and useful in very technical stuff. But it is not the alpha and omega of modeling, yet. And Blender can not be reduced to modeling. Interest for Cycles, EEVEE, Grease Pencil, VSE, Geometry Nodes, Animation, Free Open Source Software… are guaranteeing that Blender will not fall ; if it does not have SDF in the next decade. Especially after @Metin_Seven 's demonstration, that add-ons are already useable.

I think that does not harm, to let SDF enthusiasts sharing their enthusiasm about the fact, that had been considered in the survey, and that had been mentioned by Francesco in Roadmap Overview talk.
But you are right, that will not happen at detriment of cohesion of development.
Sergey’s part of talk was about consolidation of development.
And we should wait for official announcement.
Maybe I am wrong, but I suppose that developers have been consulted about items present in the survey and Francesco’s talk ; and they did not clearly reject the idea.

Currently, on both sides, everybody is speculating about when that could happen or if that will happen or if that would hurt development of something else.
But with experimental nodes in main branch, a detailed task, serious thread on devtalk and addons ; that is a little bit more than just an idea floating in the air.
There is a will to try.

1 Like