Nothing sorts of special happens...PureSpider wrote:Hey neo0.?
Turn your max bounces down to 8 with Indigo and compare again then.
Indigo 2.4/2.6 roadmap
- pixie
- Posts: 2332
- Joined: Sat Dec 29, 2007 4:54 am
- Location: Away from paradise
- 3D Software: Cinema 4D
- Contact:
Re: Indigo 2.4/2.6 roadmap
Re: Indigo 2.4/2.6 roadmap
Oh now I see what you mean.. Sorry, the physics of indigo is somewhat confusing for me.. :Peman7613 wrote:neo0. wrote: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..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.
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
I will try changing the max bounces down to 8 when I get back, but I doubt that will have much of an effect.. Anyhow, are we really contesting the idea that a GPU powered renderer is faster than one that relies on the CPU? Even if the max bounces in octane were set to 10,000 I highly doubt that it wouldn't be faster, considering how GPU has hundreds of stream processors to handle these bounces.
- PureSpider
- Posts: 1459
- Joined: Tue Apr 08, 2008 9:37 am
- Location: Karlsruhe, BW, Germany
- Contact:
Re: Indigo 2.4/2.6 roadmap
No.neo0. wrote:Anyhow, are we really contesting the idea that a GPU powered renderer is faster than one that relies on the CPU? Even if the max bounces in octane were set to 10,000 I highly doubt that it wouldn't be faster, considering how GPU has hundreds of stream processors to handle these bounces.
But we ARE contesting the idea that your GPU is the holy unbiased rendering grail.
It can aid in rendering scenes and make the rendering a lot faster, but it's not magic or something.
Re: Indigo 2.4/2.6 roadmap
I dont ever remember saying that though. All I originally said was that, in octane, I could load one of the default scenes (with millions of polygons) and it loaded and rendered faster than it does in indigo.. Heck, skindigo tends to crash if I import more than 400,000 polygons.. Don't quote me on that though. I have 4 Gbs of RAM, and I often have to try multiple times to get my renders off the ground.
Re: Indigo 2.4/2.6 roadmap
neo0. wrote: Heck, skindigo tends to crash if I import more than 400,000 polygons..
Your exporter crashes when you import a file?...
Where did you get the idea that the default scenes have millions of polygons? The chess one has ~30,000 tris, and the spaceship one has ~90,000 tris.neo0. wrote: All I originally said was that, in octane, I could load one of the default scenes (with millions of polygons) and it loaded and rendered faster than it does in indigo..
- Borgleader
- Posts: 2149
- Joined: Mon Jun 16, 2008 10:48 am
Re: Indigo 2.4/2.6 roadmap
Sorry to breakup your Indigo vs Octane conversation but I was wondering (and no I haven't re-read the entire thread to see if it was mentioned although i did search the forums) if we could have a little "auto-hide" button for the rendering settings in Indigo because right now you can dock it in different places but i thought it'd be interesting to have the possibility to make it close itself automatically when you know you wont be changing anything.
(For those who use/tried MS Visual Studio, they have the same options for the solution/debug/parameters/... panels)
(For those who use/tried MS Visual Studio, they have the same options for the solution/debug/parameters/... panels)
Re: Indigo 2.4/2.6 roadmap
Even with maxdepth=N, bidirectional will fire off many more rays (on the order of N^2) to connect the eye and light subpaths, do lots of computation to weight the paths, and splat them at different parts of the image. Compare this to normal path tracing, which really only does N bounces and contributes to 1 image splat; of course, it will take many more samples to get the same image quality, and it has difficulty with non-trivial scenes...
I'm still not sold on the comparison that was linked (the final images, used features, AA quality and noise levels were very different), but in the end users will use whatever works best for them.
I'm still not sold on the comparison that was linked (the final images, used features, AA quality and noise levels were very different), but in the end users will use whatever works best for them.
Re: Indigo 2.4/2.6 roadmap
Even if it had the same ray depth as indigo, I highly doubt you would be getting 3.5 million samples per second.
Re: Indigo 2.4/2.6 roadmap
lyc : this is something that I find strange regarding the way indigo counts samples. Actually, when bidir generates a M number of successful connections, the sample counter should be increased by M, not 1. This often fools beginners regarding the efficiency of bidir. In terms of quantity of information and SNR, it's really M times higher.lycium wrote:Even with maxdepth=N, bidirectional will fire off many more rays (on the order of N^2) to connect the eye and light subpaths, do lots of computation to weight the paths, and splat them at different parts of the image. Compare this to normal path tracing, which really only does N bounces and contributes to 1 image splat; of course, it will take many more samples to get the same image quality, and it has difficulty with non-trivial scenes...
Etienne
-
- Posts: 1828
- Joined: Mon Sep 04, 2006 3:33 pm
Re: Indigo 2.4/2.6 roadmap
Give it up. Stop comparing arbitrary numbers and get back to making nice images!neo0. wrote:Even if it had the same ray depth as indigo, I highly doubt you would be getting 3.5 million samples per second.
Re: Indigo 2.4/2.6 roadmap
Is it only Skindigo, if u export does the memory get full?neo0. wrote:skindigo tends to crash if I import more than 400,000 polygons.. Don't quote me on that though. I have 4 Gbs of RAM, and I often have to try multiple times to get my renders off the ground.
Have u overclocked pc parts? Any weird problems with other applications crashing more than usual.
I render 1,7M tris and (using instancing 206M tris) with just 1,6GB memory under Indigo (most for textures). No crashing.
Same scene takes 4,5 Gb in Luxrender + 1 of the mat takes 2,4 Gb to render on Luxball preview scene (thats because of aditsional alpha maps - lux doesnt support png alpha) and 700Mb on Indigo preview. No crashing in Lux either.
Re: Indigo 2.4/2.6 roadmap
I have 4 GB of ram, nothing overclocked. After exporting anything over 100,000 polies, it always hangs for a few seconds. When it get's up to 300k it hangs for like a minute.. Anything much more than that and it just crashes...
Re: Indigo 2.4/2.6 roadmap
Ah - that's because skindigo outputs xml meshes instead of igmeshes I think. That will be fixed.
Re: Indigo 2.4/2.6 roadmap
Benn, is there anything you can tell us regarding the progress of indigo 2.4?
Re: Indigo 2.4/2.6 roadmap
hey guys,
been working on the 2.4 ui a little bit today and i've got a little bit to show off.
this is not reviewed by nick or ben yet, so dont get all exited about it
been working on the 2.4 ui a little bit today and i've got a little bit to show off.
this is not reviewed by nick or ben yet, so dont get all exited about it
Who is online
Users browsing this forum: No registered users and 52 guests