5 ms·

> Not true. You can get speedups of 10x-100x by moving to the GPU. [...] Ok, I take you by your word. Mind you, all the points I made were about offline render

> Not true. You can get speedups of 10x-100x by moving to the GPU. [...] Ok, I take you by your word. Mind you, all the points I made were about offline rendering. I dare you to put your money where your mouth is. Disney's Moana Set[1] it a good, publicly available example. Show me how you get a 10× speed up using a GPU over 3Delight[2] with any commercial renderer out there. Really. I look forward to it. Note that I do not take you up on your 100× because it will satisfy me to see a 10× speedup to accept your point. By far. Price of GPU and CPU rig need to be comparable. Electricity cost must be factored in too so if your render costs twice as much, rig plus running costs, you divide your results by that factor. And vice versa. And as for your RIB comment earlier: don't worry -- we will add the scene parsing time to the finals; as we should. Total time will be from render command issued to final image being available on disk. And while this is an outdated example the scene complexity reflects what users of Houdini, even single artist types, are throwing at renderers nowadays. Or trying to. > What is making you think that people aren't improving their rendering algos or renderers [...] Uhhm, experience? I have been using offline renderers in production since 1994. And I see the rate of progress in commercial offline renderers drop in correlation with those people spending more effort on porting their stuff to GPUs. Sure, could be a coincidence and no causality at all. Maybe there are better explanations -- I'm all ears. > Not true. You can't get rid of the need for denoising when using Monte Carlo path tracing techniques [...] Says who? I would never make such a claim either way. So before you mis-quote me again: I ever said you can get rid of the need for denoising and I never said you cannot get rid of the need for denoising for Monte Carlo path tracing. In fact I never even mentioned Monte Carlo path tracing. Now going back to what I actually wrote: maybe re-read that. Notice the word I put in Italics so it was harder to miss? Just for the record: you are mis-quoting me for the fourth time in this thread. [1] https://www.technology.disneyanimation.com/islandscene https://www.technology.disneyanimation.com/islandscene [2] Just an indication (white bars only) since this misses data on electricity costs and parsing time (I think, but I will verify with them): https://documentation.3delightcloud.com/display/3DLC/Cloud+Rendering+Speed https://documentation.3delightcloud.com/display/3DLC/Cloud+R...

dahart 6y ago
> I never said you cannot get rid of the need for denoising for Monte Carlo path tracing. You claimed that investing in sampling algorithms would reduce the need for denoising. You claimed that 3Delight's sampling algorithm is proof of that. I disagree, I think denoising gives the same benefit to 3Delight as it does to Arnold & RenderMan, which is reduced time to a noise-free preview. > In fact I never even mentioned Monte Carlo path tracing. I don't even know what you mean by this, if we're not talking about Monte Carlo, why are you commenting on denoisers at all? You posted a link to 3delight's geo light sampling marketing comparison. You know that's a Monte Carlo method, right? > Sure, could be a coincidence and no causality at all. Maybe there are better explanations -- I'm all ears. Yes, that's right, it could be coincidence. Do you follow Siggraph or rendering research, and have you noticed that the rate of progress in CPU rendering algorithms has slowed? Do you have more examples of features that CPU-only renderers have that are surpassing everyone porting to GPU? I've seen only one example in this thread. > you are mis-quoting me for the fourth time in this thread. I don't believe that's true. I may be misunderstanding your points or summarizing you incorrectly or in a way you don't like. I am definitely disagreeing with some of your points and trying to explain why, but I don't believe I have mis-quoted you even once. >> You can't get rid of the need for denoising when using Monte Carlo path tracing techniques [...] > Says who? I would never make such a claim either way. Wikipedia says so, and I'm happy to repeat it. Would you not make that claim because you haven't studied what Monte Carlo is, or because you know of advanced techniques that are noise free? There are no known noise free Monte Carlo rendering techniques except for on trivial and/or hypothetical scenes. The kind of scenes you're talking about always have randomness (noise), because the very name "Monte Carlo" is referring to random sampling. I'm happy to explain more about why Monte Carlo comes with noise, in case it's not clear, or why denoisers will always be valuable in the context of Monte Carlo rendering methods...
- virtualritz 6y ago
  > You claimed that investing in sampling algorithms would reduce the need for denoising. You claimed that 3Delight's sampling algorithm is proof of that. I disagree, Then we agree to disagree. I can back up all my claims with hard data. Can you? 3Delight's changelog gives you access to all versions of the renderer maybe back to 2006 or so. I think their path tracing core is only after 2016. So we can download any 'sample', throw the same scene at it and calculate noise properties in the resulting image and see how they got better over time. Be my guest. I know the result and it will back up my claim. Cheers! :) > You posted a link to 3delight's geo light sampling marketing comparison Nice 2nd try but not biting. This is not marketing material. 3Delight doesn't employ a single marketing person and this was never published at the time when it was relevant (2017). > I'm happy to explain more about why Monte Carlo comes with noise, in case it's not clear, or why denoisers will always be valuable in the context of Monte Carlo rendering methods... Thank you for your kind offer, professor, no need. ;) May I remind you that I said (analogously) that relying on denoisers for improvement is a bad idea not that denoisers are a bad idea per se? But let's not try diverting this from you being put on the spot to prove your outlandish 10x+ speedup claim, shall we? Or are you preparing an extra reply to my challenge? 1. GPUs are not faster than CPUs for offline rendering when you factor in costs. 1.1. They are not even faster in the general case when you just go by GFLOPS/US$. You have to look at specific cases to get a speed advantage (exactly my point: you spend R&D on making the general case work within the restrictions of the special case. Example: FP precision). 3. Time spent working around restrictions of GPUs (data transfer, memory size, precision) could be better spent at improving a CPU renderer. Proof: 3Delight. 4. GPUs are not a general alternative to CPU offline rendering because of aforementioned restrictions. That they work in specific cases means the only good reason to invest in R&D supporting them is if your target audience only ever needs to deal with those special cases. No such renderer (claiming to cater only for such audiences) exists. Thus there are no renderers out there which should focus their R&D on GPU or they are simply lying to their customers (and/or themselves). > Do you follow Siggraph or rendering research, [...] Yes. > [...] and have you noticed that the rate of progress in CPU rendering algorithms has slowed? No. But I'm curious how you define a "CPU rendering algorithm". I'm all ears.

dahart 6y ago

> I never said you cannot get rid of the need for denoising for Monte Carlo path tracing. You claimed that investing in sampling algorithms would reduce the need for denoising. You claimed that 3Delight's sampling algorithm is proof of that. I disagree, I think denoising gives the same benefit to 3Delight as it does to Arnold & RenderMan, which is reduced time to a noise-free preview. > In fact I never even mentioned Monte Carlo path tracing. I don't even know what you mean by this, if we're not talking about Monte Carlo, why are you commenting on denoisers at all? You posted a link to 3delight's geo light sampling marketing comparison. You know that's a Monte Carlo method, right? > Sure, could be a coincidence and no causality at all. Maybe there are better explanations -- I'm all ears. Yes, that's right, it could be coincidence. Do you follow Siggraph or rendering research, and have you noticed that the rate of progress in CPU rendering algorithms has slowed? Do you have more examples of features that CPU-only renderers have that are surpassing everyone porting to GPU? I've seen only one example in this thread. > you are mis-quoting me for the fourth time in this thread. I don't believe that's true. I may be misunderstanding your points or summarizing you incorrectly or in a way you don't like. I am definitely disagreeing with some of your points and trying to explain why, but I don't believe I have mis-quoted you even once. >> You can't get rid of the need for denoising when using Monte Carlo path tracing techniques [...] > Says who? I would never make such a claim either way. Wikipedia says so, and I'm happy to repeat it. Would you not make that claim because you haven't studied what Monte Carlo is, or because you know of advanced techniques that are noise free? There are no known noise free Monte Carlo rendering techniques except for on trivial and/or hypothetical scenes. The kind of scenes you're talking about always have randomness (noise), because the very name "Monte Carlo" is referring to random sampling. I'm happy to explain more about why Monte Carlo comes with noise, in case it's not clear, or why denoisers will always be valuable in the context of Monte Carlo rendering methods...

virtualritz 6y ago
> You claimed that investing in sampling algorithms would reduce the need for denoising. You claimed that 3Delight's sampling algorithm is proof of that. I disagree, Then we agree to disagree. I can back up all my claims with hard data. Can you? 3Delight's changelog gives you access to all versions of the renderer maybe back to 2006 or so. I think their path tracing core is only after 2016. So we can download any 'sample', throw the same scene at it and calculate noise properties in the resulting image and see how they got better over time. Be my guest. I know the result and it will back up my claim. Cheers! :) > You posted a link to 3delight's geo light sampling marketing comparison Nice 2nd try but not biting. This is not marketing material. 3Delight doesn't employ a single marketing person and this was never published at the time when it was relevant (2017). > I'm happy to explain more about why Monte Carlo comes with noise, in case it's not clear, or why denoisers will always be valuable in the context of Monte Carlo rendering methods... Thank you for your kind offer, professor, no need. ;) May I remind you that I said (analogously) that relying on denoisers for improvement is a bad idea not that denoisers are a bad idea per se? But let's not try diverting this from you being put on the spot to prove your outlandish 10x+ speedup claim, shall we? Or are you preparing an extra reply to my challenge? 1. GPUs are not faster than CPUs for offline rendering when you factor in costs. 1.1. They are not even faster in the general case when you just go by GFLOPS/US$. You have to look at specific cases to get a speed advantage (exactly my point: you spend R&D on making the general case work within the restrictions of the special case. Example: FP precision). 3. Time spent working around restrictions of GPUs (data transfer, memory size, precision) could be better spent at improving a CPU renderer. Proof: 3Delight. 4. GPUs are not a general alternative to CPU offline rendering because of aforementioned restrictions. That they work in specific cases means the only good reason to invest in R&D supporting them is if your target audience only ever needs to deal with those special cases. No such renderer (claiming to cater only for such audiences) exists. Thus there are no renderers out there which should focus their R&D on GPU or they are simply lying to their customers (and/or themselves). > Do you follow Siggraph or rendering research, [...] Yes. > [...] and have you noticed that the rate of progress in CPU rendering algorithms has slowed? No. But I'm curious how you define a "CPU rendering algorithm". I'm all ears.