Announcing Redshift - Biased GPU Renderer

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Search this Thread Display Modes
Old 03 March 2013   #46
Originally Posted by PanosRS: That's exactly right! Check out our docs for a complete list of what is translated.

Will you try to add support for choice third party stuff as well, such as the unbelievably useful Multi Texture map for 3ds Max? Obviously it would be a never-ending task to replicate all third party functionality, but there are some specific ones that are really quite terrific.
 
Old 03 March 2013   #47
Originally Posted by CaptainObvious: Will you try to add support for choice third party stuff as well, such as the unbelievably useful Multi Texture map for 3ds Max? Obviously it would be a never-ending task to replicate all third party functionality, but there are some specific ones that are really quite terrific.


That plugin does look pretty interesting!!

If we receive a lot of interest for a particular shading node (or plugin) we'll either try to replicate its functionality (within legal means of course!) or we'll talk to its author, obtain the shader source and convert it to our own CUDA shader fragment.

A CUDA program cannot do everything a CPU program can (like opening files) so sometimes this conversion might be impossible. But, for shaders, its very often possible.

-Panos
 
Old 03 March 2013   #48
Originally Posted by PanosRS: Hi Davius,

As for the 3dsMax version: yeah, on the tools side of things this is on the very top of the list!

-Panos

Can't wait to try this renderer! Hurry up guys!
 
Old 03 March 2013   #49
Originally Posted by davius: I'm sick of this "unbiased" path tracing wave - I just want images to look beautiful, not necessarily 100% physic accurate.

physics and bias are unrelated. An unbiased renderer can be inaccurate and a biased renderer can follow physics. The whole "it's correct because it's unbiased" is just marketing speak.
 
Old 03 March 2013   #50
Originally Posted by stew: physics and bias are unrelated. An unbiased renderer can be inaccurate and a biased renderer can follow physics. The whole "it's correct because it's unbiased" is just marketing speak.

Let's see if I pass the test:
An unbiased render means it uses no shortcuts (let's call optimizations?) to render a scene. It's closer to the real behavior of how light travels trough space since it traces its light samples starting from the light source. This also means way more light photons (to correlate with reality) to proper light a scene.

If I'm wrong (which I believe I may be in done points) please correct me.

Cheers
 
Old 03 March 2013   #51
Let's see if I pass the test:
An unbiased render means it uses no shortcuts (let's call optimizations?) to render a scene. It's closer to the real behavior of how light travels trough space since it traces its light samples starting from the light source. This also means way more light photons (to correlate with reality) to proper light a scene.


All renderers take shortcuts and make assumptions - and it already starts with assuming that a photon is a particle and not a wave* and using phong interpolated normals on flat triangles. Some of these introduce bias, some don't. Russian roulette for example does not introduce bias. Adaptive sampling the naive way (=adding more samples to a pixel) does introduce bias. Ignoring light sources with minimal contribution (a candle on the moon) is biased, terminating paths after a certain number of bounces or once they don't contribute significantly is biased. You'll notice that many renderers that advertise being unbiased have a "max bounces" parameter - which means they're biased. They may still be noisy progressive metropolis path tracers, but they're biased nonetheless. They're about as unbiased as a vegetable soup is vegetarian after you add two bacon bits.

Photon mapping and path tracing don't have any difference in tracing how light behaves. They can use the exact same physical models for light sources and shaders. It has nothing to do with tracing from the light source either - basic path tracing starts at the eye, not the light source, where photon mapping starts at both ends, light and eye.

Also, both a biased and an unbiased renderer can be consistent, that is eventually converge to the correct result if you let them render to infinity.

What makes a renderer unbiased then? If you let it render an infinite number of images of the same scene and compared it to reality, the average error of all images would be 0. Note that individual images can still have an error, a large one even - their average error needs to be 0. Doing the same with a biased renderer would result in an average error that's not 0, even though the error of individual images can be lower than in the unbiased version.

So really, unless you are rendering to infinity, bias vs unbiased is a purely academic exercise. Let's name things for what they are and say "path tracer" when we refer to Arnold or Maxwell and "irradiance cache" when we refer to C4D or Mental Ray.

About correctness, I dare anyone to look at these images and claim the (unbiased) path tracer is more correct than the biased progressive photon mapper:
http://graphics.ucsd.edu/~henrik/pa...photon_mapping/

* Don't call it physically correct until you can render doppler shift and double slit effects.

Last edited by stew : 03 March 2013 at 09:28 PM.
 
Old 03 March 2013   #52
Great explanation! Thanks! But don't forget that light behaves both as a particle AND a wave.

I just wish I could set my teapot to travel around 0.95c and see the timeline stretch while the grid shrinks. Maybe this way it would finish rendering faster...
 
Old 03 March 2013   #53
Originally Posted by davius: Great explanation! Thanks! But don't forget that light behaves both as a particle AND a wave.

I just wish I could set my teapot to travel around 0.95c and see the timeline stretch while the grid shrinks. Maybe this way it would finish rendering faster...


not for me
 
Old 03 March 2013   #54
Originally Posted by stew: physics and bias are unrelated. An unbiased renderer can be inaccurate and a biased renderer can follow physics. The whole "it's correct because it's unbiased" is just marketing speak.

I suspect this is a lost cause, just like the word "literally." I've given up and accepted that when people say "unbiased" they really mean "progressive brute force renderer with more physically plausible models than is standard in production rendering." To be fair, that IS a bit of a mouthfull.



Originally Posted by davius: Great explanation! Thanks! But don't forget that light behaves both as a particle AND a wave.

I just wish I could set my teapot to travel around 0.95c and see the timeline stretch while the grid shrinks. Maybe this way it would finish rendering faster...

I've actually seen an experimental render engine that simulated both redshift and the compressing effects of high speeds. You could set the speed of light to whatever you wanted (scaling time, effectively). So if you turned on a light for a single frame with a very low speed of light, it would take several frames for the light to reach the geometry. Kind of cool, but not very useful I suspect.
 
Old 03 March 2013   #55
Originally Posted by stew: About correctness, I dare anyone to look at these images and claim the (unbiased) path tracer is more correct than the biased progressive photon mapper:
http://graphics.ucsd.edu/~henrik/pa...photon_mapping/


I suggest showing converged scene with caustics from a point light seen through a mirror done with path tracing and with PPM, that will mess everybodys head

For example, such images are shown here: http://www.smallvcm.com/. Turns out, unbiased path tracing actually renders the scene with bias (no caustics), but they are present and correct in the biased progressive photon mapping
 
Old 03 March 2013   #56
Originally Posted by stew: physics and bias are unrelated. An unbiased renderer can be inaccurate and a biased renderer can follow physics. The whole "it's correct because it's unbiased" is just marketing speak.


This whole discussion is essentially splitting hairs, but that's not exactly true, though in general you're right.

When you define physical correctness as the "reference", then being physically inaccurate makes your renderer biased.

In other words, the definition of biased means that the expected error for any given pixel of any given render is zero. So whether or not a renderer is biased depends on what you define as "error". If your error is defined as the "distance" from a completely physically accurate simulation of light (a predictive rendering), then being physically inaccurate actually means your renderer is biased, even if the sampling processes are not biased.

Sorry to side-track your thread Nicolas, but I guess it already has been. Redshift looks pretty impressive, I look forward to hearing more about it.
__________________
If someone offers a penny for your thoughts, and you give them your two cents, where does the other penny go?

Last edited by Novakog : 03 March 2013 at 11:43 PM.
 
Old 03 March 2013   #57
Hi Panos, just wanted to thank you for being so transparent and honest about the realities and status of your software. Looking forward to trying this out.
__________________
Matthew Spencer | Jeff Koons Studio
 
Old 03 March 2013   #58
Thread automatically closed

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 07:06 PM.


Powered by vBulletin
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.