Looking at the thread though, E-Cycles is that kind of thing where you need to keep builds around in so you can for sure have one that is golden (for normal use).
Otherwise, the project shows that optimizations that appear as low-hanging fruit may not be something that is a no-brainer to commit and the devs. are too dumb to realize it. You optimize one area and you could get lighting and shading issues due to how the features are interconnected. The devs. could perhaps fix any issues that come up, but big commits outside of blocking issues will not happen with the team wanting a stable 2.8 release next month.
For 2.81 though, I anticipate some nice Cycles commits will come in from Brecht, Lukas, and others. E-Cycles is great if you want the fastest results, but you take a risk. Better stick to 2.8 master if stability is needed more.
Are you sure it requires āallā of them? There is often kind of a Ā« minimum percentage of right owners Ā» required to take decisions. Iāve heard a lot of ā50% +1 personā, or 60%, 75%, ā¦ Depending the situation.
As far as I can tell, the general consensus is that it requires all of them, absent any provision that says otherwise.
Also, if every individual gets a vote, all you needed would be X+1 individuals to contribute a single line of code to override X contributors. It couldnāt reasonably work that way.
I think you are correct in that all authors need to agree to the new license. However, if an author doesnāt agree to the new terms, an effort could probably be made to replace their code so they no longer have a claim on the distribution. So i suppose a ālarge majorityā would be required for it to be possible.
This is a core point of distortion and possible inclination of a hybrid system.
Speaking of much larger systems is what happens between National States and Neoliberal Systems. The eternal dilemma between public and private system. (Nowadays is called Corruption, hehehe )
Hey, do you have some facts to back-up your claims? Did you use E-Cycles at all? I have facts that show the contrary of what you says ā E-Cycles producing more realistic and less artifacts than official builds:
Here, 2x faster to render, and correct render on top while Cycles stop itās path much earlier, giving black blotches
There are also all the cases were the official denoiser gives blotches or has noise still visible, while the AI denoiser is clean.
When bugs are reported, bugs are fixed in E-Cycles and here the BF is not the best example regarding breaking changes with lightning https://developer.blender.org/T54486. 2.8 had broken Subdivision, unsupported instances, etc. for months and still has more than 1300 bugs opened like back in January, because also beta was called in November last year, they kept adding breaking changes until some weeks although āstableā release is meant to be done also in some weeks.
Iām ok with critic but then please bring true information backed up with facts. Did you already had a look to the E-Cycles ratings?
Satisfied customer here. Works like a charm, good service and support #notsponsored
And I only bought into it due to the plan to merge it into main at some point, so blender can profit, more should handle it like this. A good compromise imho.
All the information I get is from reading the user feedback in the E-Cycles thread. I also didnāt say that all your builds gave problems for users, but thereās always an inherent risk of using bleeding-edge branches made by individuals who donāt have to go through the process of code review (as is the case for the development of master). This is fine since in many cases, some of the features may end up in master. Another example is the sculpt branch, some amazing features, but not every build is perfect.
Now of course master isnāt perfect either, but it seems most of the actual shading bugs is with the Principled shader as opposed to the building blocks. Youāre also far less likely to run into issues with things like energy conservation and quality if you use BPT instead of normal path tracing (as I have had no real issues with it at least).
Again, Iām not denying that E-Cycles has actually blown away normal Cycles in some areas like performance, and I do realize that some of your builds are of high quality, but you are responsible for making sure the marketing is accurate and honest (not just slick as we see from Intel, Nvidia, and other companies). I would also hold criticism of the BFās handling of Cycles at the moment as they are neck deep in trying to get 2.8 out the door (as the only things allowed now are bugfixes and resolutions for blocking issues).
The official code review is much more about making the life of code maintainers easy than about checking quality on the user side. Otherwise, their would be much less corrective commits.
So your point is that the imperfection of official builds is ok, because it only bugs for people using principled shader and normal path tracing = the vast majority of the user base but not you?
Again bold statement about marketing:
All the bug reports in the E-Cycles thread are much more visible than on the tracker and also concentrated in one thread. For Cycles, itās spread with every user opening up a thread per bug, asking if itās normal that xxx happens.
All known limitations of E-Cycles are listed on the product page, there is no known limitations information for Blender
What I was pointing too (the ratings) are independent third party reviews
Feature based funding is simply not sustainable and it is very limiting. Instead of hiring full time developers as it happens now, they would need to hire more contract developers. Though, it is highly likely that more developers would be working on Blender at certain times. However, it would increase the fluctuation rate which was quite an issue several years ago when coders were hired for certain open movie projects only. Several projects were started and plenty of concepts existed, but couldnāt be followed through as the developers could not be kept on board.
I was not particularly referring to a per-feature funding done by the Blender Foundation, but rather, inviting developers (thanks to these bounties) to port some python addons to C/C++, as patches, in order to, later, ease their implementation into Blender.
Could you give an actual example of what you have in mind? And what would in this case be the advantage of having this functionality in C/C++ rather than Python?
In order for these features to be directly implemented by default in Blenderā¦ without addon. To me (and according to the other comments from people who tried it), it seems pretty obvious that this addon is much more user-friendly than the current bezier curve tools.
I personally think that if an addon doesnāt require a lot of power from CPU/GPU, thereās not much difference from implementing it in C/C++ or python, having it as a built-in addon would do just as well.
I also think Python addons are much more manageable and easy to improve on.
ratmanās protects us
