6 ms·

Maybe you misunderstood me. I didn't peg the amount of noise to CPU vs. GPU rendering. I said that these renderers produce too much noise. All of them. And the

Maybe you misunderstood me. I didn't peg the amount of noise to CPU vs. GPU rendering. I said that these renderers produce too much noise. All of them. And the solution is not denoising. The solutions are novel algorithms that produce faster convergence. There are other issues of course. Noise is just one. What I implied was that the developers would better spend their time fixing these than trying make stuff fit into a GPU. This[1] is a comparison of light sampling in 3Delight, Autodesk's Arnold and Pixar's RenderMan (RMan). TLDR; The bottom of the page has a 'Conclusion' section which is worth reading. The page is from around 2017 if my memory serves me right and was a private page requiring a password at the time. Pixar asked 3Delight to not make it public until RMan 21 was out. After which 3Delight re-ran the tests and RMan came out worse even. They never published the results because they do not care about publicity. Mind you, these were all pure CPU renderers at the time. Few people know about this. What everyone is exposed to is just the marketing mumbo jumbo on the vendors websites. As one can guess even skimming over this comparisons there are many things one must get right. E.g. speed of convergence. I.e.: what is the threshold of samples I can get away with? Some renderers converge linearly. An image with twice as much samples will have half the noise. But others manage to converge non-linear in a good or a bad way (twice the samples give you more than twice the quality or less than twice the quality). Another is bias: does the image look the same when it has fewer samples and you squint or is it darker/brighter than a reference that has 'infinite' samples? Very important for artists doing look development: time to first pixel. The graphs on the website have not changed much with recent versions of Arnold & RMan, unfortunately. Note that shaders wise 3Delight already used OSL (byte-code, run-time interpreted) whereas Arnold & RMan used C++ (at the time). Basically, what I tried to say was: if I was Pixar or Autodesk (insert any other renderer vendor here that came from CPU land) and saw this page (which Autodesk & Pixar did then) ... considering that the competition is running on the same metal, a CPU – maybe I'd try to get to the same level of speed/quality before putting a bunch of new problems on my plate that come when you strive for making this all work on a GPU. [1] https://www.3delight.com/documentation/display/3DSP/Geo+Light+Sampling+Algorithms+Comparison https://www.3delight.com/documentation/display/3DSP/Geo+Ligh...

dahart 6y ago
> And the solution is not denoising. The solutions are novel algorithms that produce faster convergence. IMO, there are a few things you seem to be confused about. 1- There are no perfect sampling algorithms, the need for denoising will never go away. 3Delight's geo light sampling does not remove the need for denoising. 2- Denoising and better sampling are independent. You can do both, and everyone already is doing both. 3- 3Delight's geo light sampling is a pretty narrow use-case way to compare renderers. Games don't generally use geo lights at all, and films only rarely. What 3delight doesn't show you in that web page is how their sphere, quad & point light sampling algorithms compare to Pixar's & Arnold's, which is what everyone uses in practice. Spoiler alert: it's not better. > Very important for artists doing look development: time to first pixel. Your 3delight page doesn't say whether they're using binary or ascii .rib files. (How do I know it's being fair?) It doesn't compare realistic production scenes. It doesn't compare texturing quality, or how well the renderers perform under extreme memory usage. You are being sucked into some marketing, and missing the bigger picture.
- virtualritz 6y ago
  1. Of course not. And I didn't say so. 2. I never contested that too. What I did say is that GPU porting of offline renderers is a waste of time better spent otherwise. And that denoising is solving a problem you would have less off if you didn't waste time with the former. And that 3Delight is proof of that. 3. I never said this was a broad use case. I was making a point in the context of ray-tracing which is the topic of this HNs discussion. But I do assure you: comparing these renderers by other means wouldn't make them look better. > Your 3delight page doesn't say whether they're using binary or ascii .rib files. This is completely unimportant. The resp. renderer plug-ins were used inside Maya and 'render' was pressed. 3Delight didn't need to generate RIB files. Neither did (P)RMan. The Ri API is a C binding that can talk directly to the renderer or spit out RIB. If Pixar uses this in their Maya plug-in, I dunno. Every time I used RenderMan from inside Maya I was working at some facility that had their own exporter. Arnold: I have no idea if it writes .ass files or talks directly to the renderer. In any case, if you checked the numbers on the page for building up the ray acceleration structure it would be obvious to you that any amount of file I/O with the example scene in question is negligible. I know a bit about this. I was maintainer of the Liquid Maya rendering translator at Rising Sun Pictures and wrote the Affogato Softimage to RenderMan exporter there. I also wrote a direct in-memory export that made Nuke render with 3Delight using the Ri (called AtomKraft for Nuke) and was heavily involved in the Atomkraft for AfterEffects. So I can assure you RIB is not a factor in this comparison. Trust me. :) Texturing quality is the same with the caveat that Pixar can only use power of two textures. Which can have adverse effects on memory use and all implications coming from that. Meaning that if I have e.g. a 46k pixels per axis resolution texture I have to upsample that to 64k to get the same quality that I can get in 3Delight using ... well: a 46k texture. Because the next closest power of two I could use with RMan, 32k, will mean I loose 14k of resolution (aka quality) per axis axis. And lastly, apart from that: if you compare texture cache efficiency between those two, I am happy to bet considerable money on who will come out on top. Guess. :] > you are being sucked into some marketing, and missing the bigger picture. What marketing? 3Delight doesn't have any and that page is not known and extremely hard to find even through google unless you enter exact search terms. I do not need marketing to be a tad informed about these topics. I have been using Pixar's RenderMan for almost 20 years in production and 3Delight for a decade.

dahart 6y ago

> And the solution is not denoising. The solutions are novel algorithms that produce faster convergence. IMO, there are a few things you seem to be confused about. 1- There are no perfect sampling algorithms, the need for denoising will never go away. 3Delight's geo light sampling does not remove the need for denoising. 2- Denoising and better sampling are independent. You can do both, and everyone already is doing both. 3- 3Delight's geo light sampling is a pretty narrow use-case way to compare renderers. Games don't generally use geo lights at all, and films only rarely. What 3delight doesn't show you in that web page is how their sphere, quad & point light sampling algorithms compare to Pixar's & Arnold's, which is what everyone uses in practice. Spoiler alert: it's not better. > Very important for artists doing look development: time to first pixel. Your 3delight page doesn't say whether they're using binary or ascii .rib files. (How do I know it's being fair?) It doesn't compare realistic production scenes. It doesn't compare texturing quality, or how well the renderers perform under extreme memory usage. You are being sucked into some marketing, and missing the bigger picture.

virtualritz 6y ago
1. Of course not. And I didn't say so. 2. I never contested that too. What I did say is that GPU porting of offline renderers is a waste of time better spent otherwise. And that denoising is solving a problem you would have less off if you didn't waste time with the former. And that 3Delight is proof of that. 3. I never said this was a broad use case. I was making a point in the context of ray-tracing which is the topic of this HNs discussion. But I do assure you: comparing these renderers by other means wouldn't make them look better. > Your 3delight page doesn't say whether they're using binary or ascii .rib files. This is completely unimportant. The resp. renderer plug-ins were used inside Maya and 'render' was pressed. 3Delight didn't need to generate RIB files. Neither did (P)RMan. The Ri API is a C binding that can talk directly to the renderer or spit out RIB. If Pixar uses this in their Maya plug-in, I dunno. Every time I used RenderMan from inside Maya I was working at some facility that had their own exporter. Arnold: I have no idea if it writes .ass files or talks directly to the renderer. In any case, if you checked the numbers on the page for building up the ray acceleration structure it would be obvious to you that any amount of file I/O with the example scene in question is negligible. I know a bit about this. I was maintainer of the Liquid Maya rendering translator at Rising Sun Pictures and wrote the Affogato Softimage to RenderMan exporter there. I also wrote a direct in-memory export that made Nuke render with 3Delight using the Ri (called AtomKraft for Nuke) and was heavily involved in the Atomkraft for AfterEffects. So I can assure you RIB is not a factor in this comparison. Trust me. :) Texturing quality is the same with the caveat that Pixar can only use power of two textures. Which can have adverse effects on memory use and all implications coming from that. Meaning that if I have e.g. a 46k pixels per axis resolution texture I have to upsample that to 64k to get the same quality that I can get in 3Delight using ... well: a 46k texture. Because the next closest power of two I could use with RMan, 32k, will mean I loose 14k of resolution (aka quality) per axis axis. And lastly, apart from that: if you compare texture cache efficiency between those two, I am happy to bet considerable money on who will come out on top. Guess. :] > you are being sucked into some marketing, and missing the bigger picture. What marketing? 3Delight doesn't have any and that page is not known and extremely hard to find even through google unless you enter exact search terms. I do not need marketing to be a tad informed about these topics. I have been using Pixar's RenderMan for almost 20 years in production and 3Delight for a decade.