On a related topic, and I hope I am not off topic, as the physics side of Blender lies in the same module as geometry nodes: what happened with Mantaflow? I know the main developer is not active anymore, but how broken is it, or how difficult would it be to fix its codebase, if anyone knows anything about it? Would it be salvageable?
Yes, I observed this over the years. I imagine this also makes sure the person is comfortable with foss culture and their code being out in the open as a basic principle, which tbh didnât seem like that was the case here (just a feeling, I really have no idea). This is why I think his approach was clumsy at best. However at no point was this explained to him. Shouldnât someone have said âif youâd like to contribute to Blender, this would be the way forwardâ?
Well donât you think that if his goal was to contribute or to get hired by BF he would have done things differently ?
I think the first steps would have been to get comfortable with blender code and probably submit a few patches to ease future work. And eventually start to look into how to integrate new physics systems into blender. And in the meantime probably get in touch with blender devs about the best way to do it so all that work eventually get integrated.
instead you summed up pretty well I think :
Obviously the open-source nature of blender raises the bar in finding appropriate developers, as they need to be not only talented enough they also need to dedicate some of their time to the software and maybe get hired eventually, probably not with the best incomes that you might find on top of that.
Anyway, looks like many ground work in GN is already done, I wonât be surprised if work on physics will start sooner than later.
I agree with your feeling, way he phrased it was something like âwhy should I give my code for freeâ. When contributing to FOSS you surely have to realize that code is free and open source regardless. What you might get paid for is your daily work. Blender isnât gonna buy the code. Thatâs impossible.
His comments about Mantaflow guys getting paid âmillionsâ was funny, but also shows he is misunderstood about the whole situation. Heâs just advertising code and hoping he sells it. There doesnât seem to be intention of contributing to Blender.
I have no idea, I have great trouble projecting myself into the minds of others. I can only speculate but have no real intuition in that regard. Youâre probably right.
What I read doesnât sound like a good fit for the project. Rockstar developers who gestate and emerge from the Blender community work fine. Rockstars coming in for the first time arenât a good fit if they are incapable of humbling themselves and understanding the long term goals and lack of resources of the foundation.
Iâd happily pay for this guyâs fork of Blender just like eCycles and kCycles and Octane and BforA.
haha , youâre right we canât know whatâs in otherâs head for sure !
In the meantime when reading the thread it seems obvious that the goal is more about making something external sold separately from blender.
Anyway at least if it can provide something useful while proper physics integration comes to blender, itâs likely to be interesting at least to get the ball rolling.
In the meantime being an external engine, itâs probably going to be limited by data IO through python, so we might end up with 1/ some kind of monolithic and obsolete built in system, 2/ promising but yet to be done geo-node system, 3/ modern but slow addon systemâŚ
On top of that like any tool there is a long road between the initial promising tests and something that is polished by some production feedback.
Iâm wondering if physics engine arenât a bit like render engines, in the sense that itâs pretty easy to write one at least in the beginning, but thatâs making it production ready that takes a lot of time⌠Anyway letâs wait and see !
A good point, being hired by the BF assumes an understanding of Blender project design and the ability to make that design better to fit future goals. The risk of just allowing this guy to create his own system with its own design on paid time is that we will end up with two systems that do not play with each other as opposed to a single harmonious design that can do everything the user expects.
Imagine then, you play with this new multi-solver and find out that a lot of things you can do with Geometry Nodes will not even be read by it, there is a real chance of that happening if it is not implemented as part of the design for Everything Nodes. We have had more than enough issues in the past with Blender having all of these separate systems that do not work well with each other and it is understandable the devs. want to get Blender away from this sort of thing (just because it might be useful for a handful of self-contained cases, the big gotcha then is that it is useful only for those self-contained cases and all that money just went down the drain).
Besides playing well with geometry nodes, to have single system like C4D is doing now it needs to be able to interact with constraints, drivers, actions and upcoming layered actions, dynamic assignment of materials, import-export⌠Ideally and realistically new system has to replace old physics system (Blender canât maintain multiple physics system), so youâll need complex versioning.
I think he said in his thread that not even all solvers interact with each otherâŚ
It all seems amazing when youâre just watching simple uninspiring demos on default cubes but before one starts abusing developers and Institute for not going all in on that, you have to think about how exactly useful it is in serious projects.
And biggest problem of such massive implementations is the cost of maintenance, which we know for a fact that Blender canât do. New devs (who are already hinting at leaving project if they donât get paid) will leave at one point, Blender canât keep people on payroll just to maintain stuff, and weâll end up again where we are with abandoned physics systems.
Main selling point of Geometry Nodes and all new projects is the low cost of maintenance. You donât need devs to maintain separate modifiers for solidify, weld, array and etc. You just need to maintain low level blocks which everything is built upon. Same future-proofing is happening in all parts of Blender, and in every modern software, no matter how rich. Nobody will pay anyone to implement their own system in this day and age.
I for one think that physics syms â animation nodes - sdf etc do need to be integrated in Geometry nodes.
If there are underlying reasons this is not possible at the moment they should be ironed out and changed in geometry nodes themselves. Although I have a feeling that it is more a question of time and resources than âimpossibilityâ.
Geometry nodes are a huge step forwards for Blender.
Geometry nodes are only 3 years old, the amount of work that has gone into them is impressive, including a complete rewrite for fields.
It is hard enough for many users to get used to them, having a completely separate system for other things (that are geometry related) would only complicate everything even more. Especially as they are constantly getting updated.
I am not against someone making an addon that is a different system but I do think the devs are right in wanting to unify the systems in core functionality. Not only for consistence of development but also from a users point of view.
Indeed ! I think everything that is in the modifier panel should be ported to GN in some way or anotherâŚ
Iâm not 100% sure if this should be the only system in blender, as maybe some kind of objects nodes that operates on object level rather than object data level might be a good separations between these two mode. Like edit mode vs object mode. Basically these âobjectâs nodesâ would be more like animation nodes and/or constraints, maybe theyâll work on armatures tooâŚ
Ideally it should be possible to make these two communicates by sending some custom props or attributes from object to geometry nodesâŚ
Well node tools to me seem like a step towards that, but they do need lots more specific nodes.
I imagine that would drastically limit the number of possible candidates, as most professional developers wouldnât have to deal with similar requirements going from one big company to another.
That is what makes FOSS unique in where to look in terms of hiring developers. Contributing as a volunteer beforehand can act as a resume that shows you understand the source and are capable of writing high quality code for a given module. It also shows dedication to the project (to reduce the risk that the developer leaves a bunch of unfinished, buggy functionality for the rest of the team to clean up in the case of being hired by someone else).
I get that part, but there are heaps of great softwares from houdini to embergen, and it seems Blender is missing out on most (if not all) of those devs.
Not many professional developers (or any kind of professional for that matter) have the luxury to dedicate big chunks of their free time to a foss project. That doesnât make them incompatible, but thatâs just my opinion.
Straying away from the topic, just my 2 cents.
Well first some contributors are hired from other companies like NVIDIA, AMD, Intel⌠Or more occasionally from studiosâŚ
And secondly this can be thought the other way around, I think most of the time BF prefers to invest in regular contributors, like they already did a lot and being hired is an opportunity to set their work to the next level.
Just like Clement and Eevee http://www.clement-foucault.com/#blender_pbr
Or Jacques with animation nodes before working on Geometry nodes.
Also I think many times blender development dynamic starts from the community rather than from the BF. If Clement and Jacques werenât there we might not have eevee or GN. If BF see some potential within the community they invest in it and make it the roadmap, rather than having a roadmap and see who is the closest fit within the community.
At least for some main big projectsâŚ
I might be way off but those guys are working mostly on their own stuff right? Basically AMD paying a dev to make sure blender runs on their products, and so on. It seems to be in their best interest to make sure a widely used softeware is compatible with their products.
I only said itâs a limiting factor, in no way would that mean that those guys couldnât do what they do.
Anyhow, this is derailing the topic, letâs get back to complain about the lack of physics and whatnot
Yes AMD and NVIDIA devs are promoting their companies, IIRC path guiding was implemented by NVIDIA as they made a library for that. I think it should work on AMD too, but I wonât be surprised if itâs faster on nvidia GPU
Anyway, they probably take care of some work, fix some bugs, clean some code, that regular devs donât have to do therefore they can focus on other thingsâŚ
Also Iâm not 100% sure but I think at some point BF were looking for specialized devs as sometimes the job section on blender.org is open âŚ
And for sure I see what you mean when you say that itâs a limiting factor.
In the end there will never be enough developers, even if they where 1000 thatâs just a fraction of actual blender users that are in need of something.
And since many features might take like 15mn to use but maybe weeks to be made, weâll always have the feeling that blender is lacking something, or that something should be prioritized against something else that feels less relevant to some users⌠Personally I tend to look at whatâs in there rather than what should be Itâs way less frustrating that way, and basically itâs been a while that I donât feel really limited with blender for what I do, so I take every new feature as a gift and an opportunity
Yep, I definitely like that glass half full mentality.
Iâm trying to look at the bright side as well, but at the same time I have to switch packages quite often because of limitations, so sometimes I canât help but be a bit impatient at times.
OpenPGL is from Intel actually, I do not believe Nvidia would actually develop anything related to rendering that does not run on CUDA or RTX right out of the gate (as for starters they do not have a CPU line yet).