P2P doesn’t have to be exclusive - but rather supplementary. It would certainly lighten the load on the BF servers.
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.
That’s good then… Not entirely sure where the problem lies in that case. But Brecht said even the current Kernel size is already problematic somehow…
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?
That sounds more like problem significantly expanded upon. Are you saying there would be two complete full builds and hence downloads of Blender, one with ‘normal’ Cycles and another with Spectral Cycles?
If so, rather then increasing download and data requirements by 30%, they are now 100% larger, since just about everyone (to start of with) would need to download both in order to support and render ALL old projects with Cycles while starting to use Spectral Cycles for new projects.
Add to that you are now possibly swapping/switching between two running editions of Blender, so those concerned about RAM usage and loading times just doubled both in order to have each running.
And we haven’t even considered the fact we just doubled the build bot, etc requirements and workload to manage, talk about taking away dev resources as others were worried about.
So no, having two builds for cycles doesn’t solve the problem, it just creates a whole lot more issues.
No. Only if you misrepresent the problem at hand. Said problem being a significant increase in kernel-size for only one single feature.
Maybe true, but only so for a limited period of transition. Most people would probably soon grow accustomed to just using the spectral build, create all their future projects in the spectral builds and the demand for the rgb build would probably fade quickly.
What have been the reasons given why the rgb kernel is all that important anyway? There was some rather vague talk about npr supposedly benefiting from it, and there’s some performance penalty to be expected from the spectral kernel if I understood correctly.
From what I’ve gathered, the performance penalty introduced by the spectral kernel should be moderate enough most people would probably swallow it eventually (this has happened before).
Anyway, I claim ‘rendering old projects in Cycles’ would soon become a specialized niche-usecase. If this were true, the rgb kernel could just be a compiler flag for those who really need it.
Kind of like how you can e.g. build Blender without Optix or CUDA, if you feel like it.
If that turns out to be the case, then why not stick with just a single build and download at 30% larger (rather then managing two full download versions) during said transition phase and then later drop the RGB Cycles kernal and hence reduce the download by 30%.
The perfect release to do that would be a LTS one, that way if anyone needs the old Cycles they would still have it in a build that is getting bug fixes for 2 years, while any new productions can continue with a build that only has Spectral Cycles going forward.
Imo that should just be the same node, but on the spectral version there ought to be an extra checkbox (default on) “Spectral” or something
Will Spectral make Cycles look better and more realistic? If the answer is a resounding “yes” then I think it needs to be absolutely part of the official Blender release, and if that means increasing the download size – so be it! It’d be worth it and I don’t really see it as an unsurmountable issue in 2022.
On the other hand, if it’s more of a different-but-not-any-better type of thing, then by all means go on and keep arguing about 7zip and servers and viruses and whatever else brings joy into your lives!
To be clear, I was just stating the usual arguments prevalent in IT circles about software distribution best practices. Not what I enjoy personally!
Aside from that, The problem is accumulative, every increase in blender size need to be absolutely necessary for the BF.
After all, they are the one’s who are paying for thous servers, and they are the one’s who have to consider the moral question of their carbon footprint, not us…
And of course consider all their users needs, not just the pros.
In Egypt, the internet cost about 5% of the monthly income of the average family…
Not being able to afford food because your kid is learning Blender is not nice…
I understand that progress is inevitable, but some compromises should be considered more carefully than the simple logic that you suggested …
Netflix has estimated that one hour of streaming by one user on its platform produces “well under” 100g of carbon dioxide equivalent (CO2e) – a unit of measure that indicates carbon footprint. More specifically, the Carbon Trust says the European average is 55g to 56g of CO2e for every hour of streaming video. That is equivalent to driving about 300 metres in a car.
For most, I think the answer is no. Certain other features are likely easier to implement, and you can get realistic yellow sodium lamps that doesn’t contain a lot of red and blue and fluorescent lamps with the correct - but horrible - color cast. For most other shading uses, spectral data wouldn’t even be available. So to me, it depends on those “other features”, but it wouldn’t be high on my priority list.
Thank you for the dose of reality.
Unless you really want to make lots of prism renders, spectral rendering is a can of worms that doesn’t gain much visual impact considering the render time and development impacts.
It really depends, sometimes it really matters:
Think about a scene where a character wearing blue clothes standing under an orange street light at night. It matters.
The buttom line is, RGB rendering is doomed from the root, in that RGB is not energy, it is defined on top of CIE XYZ chromaticity, and it only represent tristimulus, I.E. human eye cone cell response, therefore the way RGB light react with the scene is not physical, it cannot.
I also believe spectral rendering is the most elegant way to have “wide gamut” rendering.
It definitely worth the development effort and I firmly believe spectral rendering is the future.
Not a very compelling sample there, TBH.
a renderer is just a model. it’s a simplified approximation of light transport. you can make it more or less simplified, but it is never going to be more than a model.
How does spectral rendering work with RGB textures? Every aspect of computer graphics is built to match that model to our tristimulus eyes. we can try to extrapolate from those RGB textures but it’s just a handwavy guess in a sea of handwavy guesses.
I’m not really that compelled by the very specific use cases, within the context of blender. For mitsuba, or some other technical renderer, sure. But it seems like a ton of work for a slightly bluer suzanne…
It reconstructs it into spectra. Basically it tries to find a mixture of wavelengths that look the same as the RGB mixture. Ideally the default behavior should produce a smooth spectrum to prevent extreme behaviors.
Well I can always go a little more extreme with my example:
Again the buttom line is that RGB is not energy, at least spectral lights can be a more proper model for the energy in light transport rendering.
I agree that spectral rendering is more accurate in certain (often contrived) use cases.
I disagree that it should be anywhere near the top of the priorities list.