so i assume the cuda 10 support its for the old cards also?
Hi, if I understand the developer correctly it break older cards, GTX 600 for example.
It is a bug in Cuda 10 and we hope Nvidia fix this with a next update.
They are informed about the bug.
Cheers, mib
What about Pascal?
I donāt know if this has already been posted, but the user known as Smilebags started a thread in the devtalk forum with an interest in Cycles being able to have spectral rendering capabilities.
The difference compared with a standard proposal though is that he is writing actual code to make it happen. This is because Brecht mentions early on that he is fully supportive of the idea as long as the resulting performance hit can be minimized. So far, it looks like the spectral rendering will be an option (so scenes that donāt make use of things like dispersion can use regular RGB tracing).
3 Likes
Can confirm gtx1080s are fine with CUDA 10
1 Like
Itās on this forum too:
Thanks @Ace_Dragon for bringing this up here.
Iām Chris Cook (known as smilebags on various platforms since before I can remember).
As you said, Iāve been working to get a spectral version of cycles working, and although Iām a bit out of my depths in some areas (specifically regarding how BSDFs are evaluated) it has been relatively quick progress.
My question to the larger community:
Is this a desired feature?
What would you consider an acceptable performance hit?
What benefit do you see in having it?
There is always going to be a tradeoff with performance, but it isnāt as significant as some might think - from my unoptimised code so far, it seems about 20-30% slower than regular Cycles. There are various optimisations which can be made, and I feel we can get it close to being as fast as Cycles is right now, for scenes which Cycles can render right now. Obviously spectrally dependent materials such as realistic glass will be noisy, but Iām also hoping that the various optimisations coming such as adaptive sampling (if it lands soon is another question) will help negate these performance hits.
The primary benefit of spectral rendering isnāt actually in getting spectral āeffectsā, but instead it is simply a better way to get realistic results. Colours under daylight appear different than they do under flourescent. Cycles canāt handle this, but spectral renders can. There are also some differences in how colours appear after multiple bounces.
If done right, there might not actually be a need to have separate spectral and RGB modes, and you will always get the benefit of spectral sampling. I would only consider this if my solution was as fast as or close to as fast as current Cycles.
If there are any developers who are familiar with how Cycles works, I would love to talk about it. I understand the spectral side of it, but not the Cycles side of this problem.
6 Likes
In vast majority of cases, the difference between spectral and non-spectral output will be so tiny it wonāt be worth the performance hit. At all. Thatās why almost none of the truly production ready renderers are spectral.
2 Likes
I think that is probably true for some applications. That being said, there are many applications in which it has quite a large impact, such as with unusual emission spectra from flourescent light. If someone said āI want these colours to look how they do in this videoā (which happens to be shot under flourescent light, you either have hours of fiddling in post to match them, or trade a bit of performance and get the right colours immediately.
I donāt necessarily think that is the reason, though it is certainly part of it. Manuka is a great example of where theyāve done it properly and been commended for it, though it is only speculation if we are to try to say how fast it is. My thoughts is that it is āfast enoughā for when people care about accurate colour reproduction.
1 Like
In any case we could have a different branch for spectral version of cycles to do tests while it is optimized. So developers and users could draw better conclusions by doing tests, and eventually deciding if it is convenient to have it in master.
Or eventually, could we have an option to choose to use spectral version of cycles in a similar way that we can choose to use OSL?
@smilebags, thanks for the interest in this!
Yes, Iām definitely hoping that this wouldnāt be merged too early, not until later versions of 2.8x, because in order for it not to be a regression, it needs to perform well and be nice to use, as the current Cycles is.
This is exactly why I started building it. Until we test how it fits with Cyclesā code, we wonāt know the performance impact and ultimately whether it is worth it.
I have already re-created an RGB sampler in my spectral version, which just uses a larger colour gamut, though obviously this isnāt going to be any more accurate than what Cycles has implemented already.
Simulating fluorescent light with intention to match a footage lit by fluorescent lights right in the renderer (which would be way more time consuming than doing it in post) is that tiny minority of cases. Thatās why I said āvast majorityā but not āallāā¦ because of those 
And yes, I am aware of Manuka, but people at WETA are crazy and are willing to go great lengths to squeeze last fractions of percent of realism even if it meant compromising performance or workflow, because they have tremendous computational resources as well as staff to compensate for it. Blender is at the very other of the spectrum, where it mostly server freelancers and small studios, where ratio between performance and quality is higher priority than the quality alone.
Thatās not to say I am against efforts to improve Cycles. Not at all. Itās just that I, personally, could not justify 30% performance hit, or even as little as 10% in exchange for how little quality improvement Iād get in return.
If you take a look at a Blender featured gallery here: https://blenderartists.org/tags/featured I can almost guarantee you youād have a very hard time finding a single scene which would benefit from spectral rendering in any noticeable way. In case of completely converged results, the difference would probably be very hard to tell even with close A/B comparison. For less converged results, the difference would probably end up being just colored vs monochromatic noise.
With all that being said, Iād be very happy if you proved me wrong, so I wish you success in your efforts
1 Like
I couldnāt either. Keep in mind those numbers are from a few afternoons of fiddling after never seeing Cyclesā code before, Iām pretty sure I can get it much faster than it is now. Iāve not implemented any sort of spectral-specific optimisations yet, even acceleration methods such as hero wavelength.
You are right, I just had a look and considering the differences Iāve seen in my own tests, not many of those scenes would look substantially different if rendered spectrally, but if the tradeoff is worth it (it is never going to be worth it for every application) then I think having the option to choose is still a merit.
I personally would consider 5% performance hit (at worst) to be kind of a threshold. If I knew that I can get 95% of my usual rendering speed with some small light transport details which come from spectral rendering, Iād probably just keep it enabled all the time and donāt even bother to ever turn it off. Itās when I approach that 10% performance loss line that I start to question if it pays off. So if you manage to reduce the performance hit to the minimum, I can easily imagine using it all the time, and perhaps it even being a new default.
Iāll be happy with 20%, and could handle 30% easily. IMHO
1 Like
Although there is large variability with the benefit from some spectral optimisations, I would hope that for a good proportion of scenes, the performance could be within 10% of RGB.
There are some situations which might actually converge faster in spectral, though these are certainly the minority (scenes with a large light contribution from a narrow band of the spectrum, aka scenes with a strong colour cast).
Im hopeful but not particularly confident that spectral rendering could be enabled without too much consideration on the majority of scenes.
I think you should wait to see some comparisons first, since Iām talking about RGB compatible scenes (no dispersion). Some spectral effects take a lot longer to resolve, and thereās only so much optimisation one can do for that.
Itās not that simple. Imagine you are doing a long animation, having to use renderfarm. The expenses to render it are 1000EUR. Would you be willing to pay 1300EUR instead for something you barely see and your client will almost certainly not notice?
1 Like
Out of curiosityā¦ do you do spectral rendering in Cycles just for fun? Because you enjoy that particular topic? I am asking because there are quite a few Cycles features people have been requesting for a lot time, but are not implemented yet. And most of them would bring a lot more benefits to the table than spectral rendering.
Cycles developers with time to spare are worth beyond gold
Yes, the main reason for doing this is personal interest. I have been a photographer in the past, and Iām currently a programmer, and Iāve always had an interest in light and colour.
I would be more than happy to work on implementing new features in Cycles if I could justify the time, either with money or another benefit. In fact, I feel thereās a good number of developers who would be willing to implement features in cycles if they were to get paid for their time.
Out of interest, what sorts of things are being most requested?