Why can't we have *only Cycles* upgrades?

General Forums Blender and CG Discussions
#1

Blender Foundation, as usual, is full of work and projects. Right now they are deeply busy with Blender 2.8, and as a result it’s very likely that 2.79 will be the last release until that BIG ONE in 2018.
But on the Cycles-side, great progress and cool features appear often here and there. Who can tell from here to an year what new whistles and bells could have been worked on? Adaptive sampling, bevel and AO nodes, multilight, lightlinking, and more… all these stuff seems to be almost at reach, behind the next door. And some of them can actually get in master sooner or later. But, I can’t believe that we are going to wait until the whole 2.8 project will be completed to put our hands on a newer (official) Cycles version.

So - thread title question - since Cycles is an addon, why not release it as such? A simple “Download Cycles ver. X.x” button on the webpage, and maybe in the future the GSOC addon management stuff could come in for this.

Will blender 2.79b get a cycles edition?
#2

It is a lot easier to maintain it like this.
Every release they are making is a tremendous amount of work. That’s why they got away with the very short release cycles. The coders at the Blender Institute and Foundation were spending a significant amount of time just to do that. Now with the longer release cycles, they could again focus on other topics which are not directly related to bug fixing or maintenance.

Splitting Blender into different modules as you suggested is very difficult or almost impossible on a technical level. For Cycles it might be possible, though I could be wrong. But there are clearly a lot of GSOC projects that are not only adding additional functionality, but they are modifying the core of Blender as well. E.g. if two of them are making small changes in the bmesh code, you would need four “Core Blender” versions: The vanilla one, one for each of the GSOC projects and one with both changes. Keep in mind that the changes might be conflicting too. A lot of things are so tightly linked together that you can not easily split them apart. In theory, everyone want to have their software as modular as possible. In practice, it is very difficult and almost no one successfully achieves it.

At the end, the developers are going to decide what makes sense. Are they spending additional time before the 2.8 upgrade in order to give everyone the ability to use and test those great Cycles features or are they going to focus completely on 2.8 in order to get it out sooner.

#3

Yes i think it makes sense too, today its perfectly normal to work on multiple projects who combine to one project.
We dont develope MPEG library or JPG, PNG ibraries, we only make use of them in software solutions.

Allready there is Cycles stand alone, and Cycles is used in other non Blender products (other 3d software supporting blender).
Why should those other parties wait till 2.8 is out ?, it doesn’t make sense to wait for a next cycles release until some totally non related show stopper lets say Alembic or Bmesh operator issue is fixed.
And that would allow i believe for a truly short release cycles, not month’s but weeks or days without BCONx trial candidates.

I think BCON worked well over the years but it might not be bad to rethink development process with 2.8
There is allready a Cycles stand alone with some more futures in it… its maybe more of a question of when this will happen, as in terms of software management it would be normal to split it, while others can work on totally non related stuff. Thereby keeping the development speed in the project and their users happy.

Maybe similar arguments could be made for cloudsim, smoke sim, water simulations, particles, crowd sim, video compositor…
(as for particles maybe keep the old stuff, and add a new version to be able to have both)

#4

Yep, obviously the problem is how deep (and well) Cycles is integrated into Blender. Sometimes changes in Cycles require core Blender tweaks or viceversa, and in those cases my whole point falls apart

#5

This requires the project to have a well defined interfaces, such that each component can be removed and replaced with another one. That is theoretically possible, in practice no one does it, because it is not maintainable. The developers would need to test all possible combinations of those replaceable components. That’s simply not feasible.

#6

From what I see a lot of time is taken for bugfixing and releasing, It’s nice to have a new blender version every 6 month or so, but I guess if it was more often devs will spend their time coordinating these release.
I guess if Cycles for blender was standalone it will be more work to do release logistic and schedule.
All these IMO won’t make things append faster…

Now we are at a particular case because 2.8 will take more time, but this situation only happened with 2.5 before. And the transition between 2.49 and 2.5 went smoothly from what I recall.

@lsscpp : let’s wait and see, maybe there will be an intermediate release if 2.8 take too much time to get ironed out. Or in the other way around, maybe they will release a 2.8 without all the features but still usable…

#7

In a normal company with 10-20 developers in each part of the program yes, but in blender with few people full time making a whole program… it’s hard.

But I keep hope that they will implement round edges as experimental in 2.79x

#8

Also, in a normal company, they will ship releases every 12-24 months, with maybe a bugfix release every 6 months, if you are lucky.

The ability to get fresh hot builds every single day, with stable releases every few months is a rarity in the world.

#9

Why? Blender 2.49 had ‘a’ and ‘b’ releases, which had new features.

I can’t believe that we are going to wait until the whole 2.8 project will be completed to put our hands on a newer (official) Cycles version.

Maybe you don’t.

So - thread title question - since Cycles is an addon, why not release it as such?

I don’t think it has ever been a “pure” addon (using only the public addon interface), so there may well be difficulties here, not to mention all the administrative overhead…

#10

autodesk is not a normal company

It is not strange builds each few weeks or custom builds in some industries. For example, Unity or Unreal give builds each few time, in Unreal you have the source code. In other licensed software is similar.

#11

Blender is 3D software, and compared to Autodesk, Maxon with C4d, Newtek with Lightwave, and other companies that develop 3D software, Blender users count their blessings - as SterlingRoth writes, we have access to daily builds, and regular stable builds. I suppose only Modo users are somewhat lucky to have new stable builds twice/thrice a year.

In the world of commercial 3d software AutoDesk is actually quite normal (well, aside from their horrendous behaviour towards their customers at times).

With the aforementioned companies only official beta testers have access to new builds. Blender users are very, very lucky in this respect.

#12

I am, personally, torn on this. I would love to see more frequent updates of cycles functionality, and it bothers me that Eevee is getting more (public) attention despite being a restricted audience.

BUT, I don’t believe that Cycles in Blender is simply an “Addon”, but is more integrated than the third party solutions in other software.

The bottom line is, if Cycles were developed as an addon rather than fully integrated, we would probably get less in the same time.

I have to be honest, I’m more concerned about some of the other changes for 2.8, in particular, the complete changes to layer management and viewport changes. I like the old way of both, and worry about learning the new.

#13

If the new is better though (and if backwards compatibility is to be broken anyway), why stick with the old way (with its cruft and usability shortfalls)?

There was also some opposition to the new UI and workflow concepts introduced in 2.5, but it not only did Blender get far more users than it lost, the vast majority of the existing base saw the changes as an improvement.

As for Eevee bothering you, it is to be noted that it is not taking any dev. time away from Cycles because it’s being done by different people (neither Clement nor Dalai have much involvement in Cycles and neither Brecht nor Lukas is working with Eevee).

Now as for a Cycles release, I would indeed support the idea of a 2.79 “performance release” like what we saw with 2.78 (but the decision is up to the BF).

#14

Cycles is available as a standalone application. All changes to Cycles within the Blender repository are ported to the Cycles standalone repository. That means when features are added to Cycles during 2.8, the standalone repository (which is used by the implementations for Cinema4D, Poser, 3ds Max, Rhino, etc) gets these features too. Cycles also has its own version (1.8 in current master), so it could be developed completely on its own right away.

However ™, Cycles is not just like a Python Add-on that you can download and install easily. It’s a number of C++ libraries that are linked with Blender’s libraries within the Blender executable.
Cycles is indeed hooked up to Blender in a rather special way, that is through the C++ version of the Python API (you could call it Blender’s external C++ API), but it is still a separate library. (The part of Cycles that converts Blender data to Cycles also has a handful of bad-level calls to Blender’s internal functions, but that’s neglectable here).
I guess it would be possible have a version of 2.79 that includes later changes to the standalone, as long as no further changes to Blender are needed. As long as that’s the case, the library files of Cycles (i.e. some .dll’s on Windows) could simply be replaced and re-linked if I’m not missing something.
Now the issue I see, is that from what I heard from Cycles developers (I remember Lukas and Brecht saying this), the Blender rendering API is written tightly for the current needs of Blender Internal and Cycles. That would mean it’s not uncommon that new features in Cycles require changes in Blender’s code to work there as well. I don’t know how often this is the case though, so I rather have a Cycles dev judge this.

To my knowledge it’s still up in the air if there’s going to be another feature release (e.g. 2.79a) or not. Thing is, the more 2.7 release work has to be done, the longer 2.8 will take. Maybe the snake chases its own tail here and it’s not worth doing more 2.7 releases.

#15

Well maybe that was 10 years ago.
I recommend you to read about “unit testing”, and “principles of modular design”, “refactoring”,
As actually a lot of people code like this, and its build into most programming languages. (Include Using Import.…)
Developers wont need to test all combinations either (solved by unit testing), and code can detect if something is available or not (and thus provide an option to a user or not).

I myself create libraries used by several programs, and with each update, on one of these programs the shared libraries improve with it. So a function update in Program A, might one day be used in Program B, or C if you think good about design there is no need for conflicts and the programs B and C will evolve faster. Its good to spend time on refactoring and split objects out to their own classes, and files, so eventually they become libraries that have a broader use case then just one mega program.

#16

While Cycles is talking to Blender through the add-on API, the core of Cycles is linked into the Blender binary and not in a separate file. So there’s no way of replacing just the Cycles part without recompiling Blender as a whole. Cycles-only releases would then be, more or less, Blender releases with just a restricted list of updates and not like other add-on updates.

#17

On a large scale, it is not possible to use modular design. Unit testing is great, but they are for one library. You can’t cover everything with unit tests. And even worse, Blender does not have a dense coverage with unit tests.
In theory modular design is amazing, but in practice I haven’t seen an application which allows the user e.g. to pick the version of the physics library the application is using. Maintaining that would be an absolute nightmare. In theory, it is not a problem, in practice it sucks.

#18

Yep, that happens all the time. For example, all the Shader Nodes are defined directly in the Blender source code, and many other patches also require changing the RNA API.

However, I would also like to point out that it would technically be possible. The C++ RNA API is essentially a header file that wraps the C RNA functions in a C++ layer, so it would technically be possible to build Blender once, save the generated C++ headers, and then build Cycles with those headers. Assuming that the same compiler is used (might not even be neccessary, C ABIs are fairly forgiving), Blender could then load the Cycles .dll/.so and dynamically resolve the C API calls. However, that still has the problem that you can’t change the RNA API without a new Blender build, so in practice we would be very limited in which patches can be distributed that way.

#19

thanks for replying Lukas.
So, basically it could be possible depending on how deep the changes are. Let’s leave it as it is. Mine was just a sort of provocation…

#20

And what was the goal of the provocation?