The only difference is that you need two compiled kernels, instead of one, with spectral rendering enabled or disabled, which should be straightforward to implement with this patch. So it’s not a problem to add it in the future. The only concern I have is increasing by almost 30% the size of Blender installation.
Yeah so the switch will be there if people are fine with some increase in installation size.
It was on Graphic All, note the Cycles X version was very buggy, and it does not have the spectral nodes support.
This is the Cycles X version:
Here is the 2.93 version with less bugs (note it’s also buggy though, just not as buggy) and the spectral nodes support:
The biggest issue is not on disk space, it’s on downloading and hosting.
The bigger it is, the more it cost the blender foundation on hosting, and the more difficult it becomes for people with limited bandwidth to download … and of course the bigger the carbon footprint as will
I am quite sure that Blender is going to become more modular in the future, though that is going to take quite a while. Having a basic version and just add modules like Cycles or Cycles Spectral as needed, or add fluid simulation, … will start to make more and more sense from my point of view.
There is also loading time, would you really want Blender to be like the big guns and take over a minute to load? Why not also have Blender use 16 gigabytes of RAM in an empty scene while we’re at it, give it that authentic heavyweight professional app. feel?
In addition, unless you want to go back to slow disk drives for your apps, keep in mind that we are not yet to the point where SSD memory is growing on trees (as far as price per gig is concerned).
I would say this is comparable to the switch from rasterization to pathtracing. People may not need spectral, but rendering evolves ever closer to reality and there’s no reason to think npr won’t be possible once we get there.
It’s the equivalent of 30% more traffic, 30% more hosting costs. (Probably not exactly, as the prices probably increase sublinearly, but still)
That’s money that then can’t go to other parts of the operation. Fewer devs, fewer artists. It could actually be quite a big deal, slowing down bug handling and feature expansion.
I really hope that’s not the case though. It’d extremely suck if that were the one thing stopping Cycles from getting spectral support.
I think it’d potentially allow new npr effects. But manipulating the three color channels completely independently, as probably is assumed to be possible for a lot of npr workflows, isn’t gonna work with spectral rendering.
Hosting costs? the servers are sponsored by dell, bandwidth by xs4alll (source). The bandwidth is not limitless though so there is a cost (as things would slow down if that link gets saturated) but it’s not monetary in nature.
One thing that is cool with blender is that it’s quite lightweight and fast to open.
I think this is due to the fact that a lot of care is put to limit the app size growing.
I’m sure they’ll end up finding a solution, it won’t make any sense to get rid of all this dev time just because of it.
But thanks to these kind of attention we don’t have a bloated app that takes 5mn to lauch.
It’s not the first time that something like this is discussed.
I don’t quite understand what all this discussion is about. The increase in Cycles kernel-size (being the root cause for all the issue at hand) would only apply, if spectral rendering was a thing you could just turn on and off in Blender before rendering at will.
Unless I’m missing something here.
But why would anybody need this so badly to justify all the hassle? They could just, as @thinsoldier suggested, provide one rgb cycles build and one spectral cycles build. Problem solved.
In an ideal scenario a user could even install the spectral cycles as an external renderer on top of a blender installation which shipped with rgb cycles. Then one could switch between the two at runtime as you can switch between cycles and eevee or luxcore or whatever.
Though I believe currently cycles is fuzed a bit too tightly with blender internally for this to work.
On the other hand, afaik, there’s work being done on disentangling this more and interfacing cycles via some api, so maybe someday it might work like that.
So this is one of those hysteric BA-discussions again, right?
There is no indication whatsoever Brecht considers to outright reject the patch alltogether because of kernel-size considerations.
Those considerations only apply to the idea of making spectral rendering a runtime option to switch on and off anytime.
Some difficult questions would rise if we go down this route. For example, in the spectral version, there is no need to have the RGB Blackbody node anymore since it will be replaced by a spectral one. But in RGB version Cycles, you still need it. Having two kernels side by side would justify the idea to keep the RGB Blackbody Node for RGB Cycles compatibility, but having two different versions of Blender, it doesn’t sound right to get the Spectral version to keep something it doesn’t need just for another version of Blender. Now think about how many more design choice can be made differently in the future in spectral vs RGB version, does it make sense for the devs to maintain two versions of Blender like this? It seems to me that it is not realistic.
I see where you’re coming from. Though isn’t this the exact same situation which would also occur if it was two seperate kernels maintained side-by-side, as advocated by the ‘never mind the extra size’-camp?
The only difference between that and my suggestion being my suggestion needs Blender to be built twice for each release (per platform etc.).
Given all the daily builds etc., alphas, betas and what not already officially provided on blender.org, this seems not to be a pothential issue.
Or am I missing something here?