![]() ![]() I was maintainer of the Liquid Maya rendering translator at Rising Sun Pictures and wrote the Affogato Softimage to RenderMan exporter there. 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. ass files or talks directly to the renderer. If Pixar uses this in their Maya plug-in, I dunno.Įvery time I used RenderMan from inside Maya I was working at some facility that had their own exporter. The Ri API is a C binding that can talk directly to the renderer or spit out RIB. ![]() renderer plug-ins were used inside Maya and 'render' was pressed.ģDelight didn't need to generate RIB files. > Your 3delight page doesn't say whether they're using binary or ascii. But I do assure you: comparing these renderers by other means wouldn't make them look better. ![]() I was making a point in the context of ray-tracing which is the topic of this HNs discussion. And that denoising is solving a problem you would have less off if you didn't waste time with the former.ģ. What I did say is that GPU porting of offline renderers is a waste of time better spent otherwise. You are being sucked into some marketing, and missing the bigger picture.Ģ. It doesn't compare texturing quality, or how well the renderers perform under extreme memory usage. (How do I know it's being fair?) It doesn't compare realistic production scenes. Your 3delight page doesn't say whether they're using binary or ascii. > Very important for artists doing look development: time to first pixel. 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. Games don't generally use geo lights at all, and films only rarely. You can do both, and everyone already is doing both.ģ- 3Delight's geo light sampling is a pretty narrow use-case way to compare renderers. 3Delight's geo light sampling does not remove the need for denoising.Ģ- Denoising and better sampling are independent. IMO, there are a few things you seem to be confused about.ġ- There are no perfect sampling algorithms, the need for denoising will never go away. The solutions are novel algorithms that produce faster convergence. 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. Note that shaders wise 3Delight already used OSL (byte-code, run-time interpreted) whereas Arnold & RMan used C++ (at the time).īasically, 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). The graphs on the website have not changed much with recent versions of Arnold & RMan, unfortunately. Very important for artists doing look development: time to first pixel. 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).Īnother 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? An image with twice as much samples will have half the noise. I.e.: what is the threshold of samples I can get away with? Some renderers converge linearly. ![]() What everyone is exposed to is just the marketing mumbo jumbo on the vendors websites.Īs one can guess even skimming over this comparisons there are many things one must get right.Į.g. Mind you, these were all pure CPU renderers at the time.įew people know about this. They never published the results because they do not care about publicity. Pixar asked 3Delight to not make it public until RMan 21 was out.Īfter which 3Delight re-ran the tests and RMan came out worse even. The page is from around 2017 if my memory serves me right and was a private page requiring a password at the time. TLDR The bottom of the page has a 'Conclusion' section which is worth reading. This is a comparison of light sampling in 3Delight, Autodesk's Arnold and Pixar's RenderMan (RMan). What I implied was that the developers would better spend their time fixing these than trying make stuff fit into a GPU. I said that these renderers produce too much noise. I didn't peg the amount of noise to CPU vs. ![]()
0 Comments
Leave a Reply. |