Page 3 of 7

Re: Indigo 2.4/2.6 roadmap

Posted: Sun Feb 28, 2010 9:34 pm
by lycium
neo0. wrote:Well, whatever it does I hope it is atleast as fast as other GPU renderers. In octane, I remember pulling 3 million samples per second in a scene that had over 10 million polygons..
How many samples per second would you like? Actually it can be made almost arbitrarily high: we simply make the samples black some fraction of the time (eg. 90%), and for the rest we bump up the brightness to compensate (eg. 10x) - this is the basis of Russian roulette, an essential method in unbiased rendering. Statistically this will converge to the same image, but the samples per second is magically 10x higher!

Of course, this will take much longer to get a reasonable image, so you are actually shooting yourself in the foot if you care about producing a decent image in a given amount of time. The take-away point is that samples per second isn't a good measure of a renderer's "speed"; to give an analogy, if I declare "I can eat a thousand items of food per minute!" as measured with rice, and you're trying to match it by eating eggs, you would rightly object that the comparison is unfair.

I've made this point before in another thread:
lycium wrote:hmm there's no sense in attacking marketing stuff of octane or arion i think; for one thing it could be completely correct, eg. if you compare samples per second.

this of course doesn't take into account the kind of samples taken... for example, if you compare the results of:

1. typical gpu path tracing, deterministic light connection at end of path.
2. typical cpu path tracing, deterministic light connection at every bounce.
3. bidirectional path tracing, re-weighted sum of all scattering events.

i think many samples of one type are needed to get an equivalent result computed with the next; bidir makes theoretically optimal usage of a light path's information.
My post here isn't directed at any particular renderers; for any two renderers their samples per second figures aren't directly comparable. With fewer samples per second you should expect the image to converge more rapidly - it's relatively easy to make a renderer that gives many samples per second under simplifying conditions, but how about one that delivers a clean image in reasonable time, using true unbiased rendering (a mathematical concept which has become a marketing term for something different), and in difficult scenes? There's an American saying for this: "all the speed in the world doesn't help you if you're headed the wrong way".

Indigo is aimed at delivering the highest possible image quality, and doing that as fast as possible. If you've done a comparison and find its performance to be lacking, we'd like to hear about it! We're always trying to improve our product :)

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 7:29 am
by neo0.
Well.. Okay, let me put it this way... With octane renderer, a scene over 10 times as big as anything I have done with indigo converged in minutes.. How does that sound? :)

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 7:47 am
by Godzilla
neo0. wrote:Well.. Okay, let me put it this way... With octane renderer, a scene over 10 times as big as anything I have done with indigo converged in minutes.. How does that sound? :)

What exactly were you rendering that had so many polygons? I, for one, find it hard to believe you created a model in Sketchup with more than 10 million polygons.

Would you care to post screen shots of this render you're talking about? I'm sure I'm not the the only one who would love to see it.

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 7:56 am
by PureSpider
neo0. wrote:Well.. Okay, let me put it this way... With octane renderer, a scene over 10 times as big as anything I have done with indigo converged in minutes.. How does that sound? :)
Thats sounds like you didn't understand ANYTHING lyc posted...

Octane does 8 bounces of the rays (max setting is 64 iirc), Indigo does 10k (or 100k?) bounces by default...
So if you put a mirror opposite to another one and look "inside" it Octane will show 8 pictures of the mirror, Indigo will show 10k (or 100k...).
I hope that got it clear finally.

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 8:17 am
by pixie
PureSpider wrote:
neo0. wrote:Well.. Okay, let me put it this way... With octane renderer, a scene over 10 times as big as anything I have done with indigo converged in minutes.. How does that sound? :)
Thats sounds like you didn't understand ANYTHING lyc posted...

Octane does 8 bounces of the rays (max setting is 64 iirc), Indigo does 10k (or 100k?) bounces by default...
So if you put a mirror opposite to another one and look "inside" it Octane will show 8 pictures of the mirror, Indigo will show 10k (or 100k...).
I hope that got it clear finally.
"If a tree falls in a forest and no one is around to hear it, does it make a sound?"

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 9:39 am
by fused
pixie wrote:"If a tree falls in a forest and no one is around to hear it, does it make a sound?"
yes. full stop.

unless the tree falls in a vacuum forrest.

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 10:35 am
by lycium
Godzilla wrote:
neo0. wrote:Well.. Okay, let me put it this way... With octane renderer, a scene over 10 times as big as anything I have done with indigo converged in minutes.. How does that sound? :)
What exactly were you rendering that had so many polygons? I, for one, find it hard to believe you created a model in Sketchup with more than 10 million polygons.

Would you care to post screen shots of this render you're talking about? I'm sure I'm not the the only one who would love to see it.
Yes, I also hope this somewhat abstract discussion can be grounded with an example.

Indigo samples environment maps very efficiently, so I am doubtful that renderers not doing this sampling (resorting to tricks such as blurring the env map) can converge more quickly, and even when left longer can produce an image of similar quality. neo0, take off the gloves and show us an unfavourable comparison!

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 11:23 am
by galinette
By the way, it would be a good thing to have the Signal to Noise Ratio (SNR) of an image being rendered, in dB. I know this is not perfect, as some parts may be noisy, and others not, and the concept could be tweaked. Further with that idea, providing a SNR limit instead of samples or time would be interesting for batch processing.

When speaking about SNR ratio, I have remarked that dark parts of images are always noisier than bright parts, because at equivalent noise level, SNR is lower. Maybe the MLT algorithm light contribution metric could be tweaked to improve this.

Etienne

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 12:29 pm
by neo0.
Thats sounds like you didn't understand ANYTHING lyc posted...

Octane does 8 bounces of the rays (max setting is 64 iirc), Indigo does 10k (or 100k?) bounces by default...
So if you put a mirror opposite to another one and look "inside" it Octane will show 8 pictures of the mirror, Indigo will show 10k (or 100k...).
I hope that got it clear finally.
That still doesn't explain why octane clears up your scene much faster than indigo does. Even with it's ray bounce limit, it still clears up your scene in a fraction of the time indigo takes..

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 12:34 pm
by lycium
Hmm I don't see example images and hardware specs...

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 12:37 pm
by eman7613
neo0. wrote:
Thats sounds like you didn't understand ANYTHING lyc posted...

Octane does 8 bounces of the rays (max setting is 64 iirc), Indigo does 10k (or 100k?) bounces by default...
So if you put a mirror opposite to another one and look "inside" it Octane will show 8 pictures of the mirror, Indigo will show 10k (or 100k...).
I hope that got it clear finally.
That still doesn't explain why octane clears up your scene much faster than indigo does. Even with it's ray bounce limit, it still clears up your scene in a fraction of the time indigo takes..

It does explain why. It is becasue Indigo is doing more work to produce a more accurate image. For simple scenes this wont mean much visual difference, for physically complicated scenes (complicated in the physics required to produce an accurate result, not in geometrical measurement) the difference will become noticeable, and possibly even be dramatic

Another way to think about it, I could find a fraction x/y that is close to pi, and gets me 100 decimal places of accruacy. But if there is a situation where you need 10000 accurate decimal places, your going to notice the diffrence in time and quality.

: Edited for accidentaly removing a sentence

Re: Indigo 2.4/2.6 roadmap

Posted: Mon Mar 01, 2010 12:47 pm
by pixie
lycium wrote:Hmm I don't see example images and hardware specs...
Example images and hardware specs

Re: Indigo 2.4/2.6 roadmap

Posted: Tue Mar 02, 2010 12:39 am
by CTZn
galinette wrote:Maybe the MLT algorithm light contribution metric could be tweaked to improve this.
If there are any ways to improve MLT then that's my pick for future versions (maybe not 2.4/2.6 tho).

Now I think that neo0.'s point is: "look, I've got this image. *tries to read lyc's posts* ouch ! anyways, I've got this image".

neo0. isn't much after accuracy or how maths are applied I believe. The discussion is sterile imho :)

oh gzavye :cry:

;)

Re: Indigo 2.4/2.6 roadmap

Posted: Tue Mar 02, 2010 1:01 am
by PureSpider
This is not even advanced maths.
Compare max 8 calculations per ray to max 100k calculations per ray... EVERYONE should be able to see where the speed of Octane comes from, then.

Hey neo0.?
Turn your max bounces down to 8 with Indigo and compare again then.

Re: Indigo 2.4/2.6 roadmap

Posted: Tue Mar 02, 2010 1:40 am
by StompinTom
All that aside, I'm sure I'm not the only one excited to hear about any speedups that may be coming up our way!