CoolColJ's test pics thread

[Heavily Tessellated]

We need to pool together and give CCJ solo access to our yet-to-be-built Indigo cluster in the wee hours, this fool NEEDS a couple teraflops available at all times.

BTW, thanks for that http://www.cs.huji.ac.il/~danix/itm/ link, got lost there for a good half hour. (and not for nothin' but that spatially varying blur is as tricky/slick as the tonemapping tactics. DoF in post that looks as good as rendered? :gasp: )

[CoolColJ]

yes please!!!!!


I discovered something....

This scene I'm did to compare to Fry. I did 2 renders, one with a ground plane (same for Fry) and one without a ground plane outside of the view, or pool in this case. Huge difference in render times. And this brings Indigo's render time inline with Fry. I suspect Fry removes all geometry not in view from the calculations automaticly!
Because at the same render time, Indigo and Fry are neck to neck sample count wise, with 20million samples a piece at the 47 minute mark.

Removing the big ground plane outside of the view brought about massive differences in the render times to results ratio....
The sample rate is exactly the same as well, and I used Bidirectional MLT

2nd one is still dark from the supersampling, but man the caustics are all there very quickly! The first one was developing caustics dot by dot

maybe Indigo's engine needs some sorting in this area

[CoolColJ]

actually the pic is still dark after more rendering, and with different overall colours...

so even with the same tone mapping settings the pic is rendering differently without the ground plane, not just speed wise!

[OnoSendai]

Removing the big ground plane outside of the view brought about massive differences in the render times to results ratio....
The sample rate is exactly the same as well, and I used Bidirectional MLT

2nd one is still dark from the supersampling, but man the caustics are all there very quickly! The first one was developing caustics dot by dot

This is expected with bidirectional path tracing.
When you have a large plane, rays are cast from the sky to all positions on the plane. Therefore the chance of the ray hitting the surface of the pool, and then making a nice caustic path, is much less than if there is not a big plane under the pool.

So, when using bidir path tracing / bidir mlt, try and make the size of the scene not much bigger than the 'interesting' portion of the scene - i.e. the volume you will be looking at directly.

[OnoSendai]

actually the pic is still dark after more rendering, and with different overall colours...

so even with the same tone mapping settings the pic is rendering differently without the ground plane, not just speed wise!

If it converges to a different result, it's a bug.
Can you post the scene, or email it to me?
Just the one version as an .igs should do, I can comment in/out the ground plane.

[CoolColJ]

Only problem is, the scene is 90megs
The water mesh is pretty big

it does compress well though - 16.9 megs after zip compression

I'll try and host it somewhere

[OnoSendai]

Thanks for the scene.
Btw, the water mesh is building with a BIH, if you increase the tri threshold so it builds with a kd-tree, it renders about twice as fast.

[CoolColJ]

Thanks for the scene.
Btw, the water mesh is building with a BIH, if you increase the tri threshold so it builds with a kd-tree, it renders about twice as fast.

thanks

your right! samples per second jumps from under 7000 to 13,000+
micro-seconds / sample drops from high 100s to the 70s

I guess I should set my "bih_tri_threshold" to 800000

[OnoSendai]

Yeah,
perhaps I should bump up the default threshold, esp. since kd-tree building is a lot faster now.

[surreal]

Hey, if you need a spot to host any files (Size doesn't matter to me to much) I got tonnes of bandwidth and space to use up!

[CoolColJ]

Hey, if you need a spot to host any files (Size doesn't matter to me to much) I got tonnes of bandwidth and space to use up!

thanks for the offer, I'll keep it in mind for the future

[CoolColJ]

Removing the big ground plane outside of the view brought about massive differences in the render times to results ratio....
The sample rate is exactly the same as well, and I used Bidirectional MLT

2nd one is still dark from the supersampling, but man the caustics are all there very quickly! The first one was developing caustics dot by dot

This is expected with bidirectional path tracing.
When you have a large plane, rays are cast from the sky to all positions on the plane. Therefore the chance of the ray hitting the surface of the pool, and then making a nice caustic path, is much less than if there is not a big plane under the pool.

So, when using bidir path tracing / bidir mlt, try and make the size of the scene not much bigger than the 'interesting' portion of the scene - i.e. the volume you will be looking at directly.

I always thought Bidirectional MLT was smart enough to know when things can't be seen they shouldn't be attempted to be calculated?
What about stuff behind the camera that can't be seen, but will still influence the lighting?

so does the same thing happen with Pathtracing/MLT as well?
Well MLT doesn't seem to render the scene very well anyway....

[alex22]

I thought so too. I mean, I thought bi dir meant rays are sent from the camera too instead of just from the lights?

[OnoSendai]

Removing the big ground plane outside of the view brought about massive differences in the render times to results ratio....
The sample rate is exactly the same as well, and I used Bidirectional MLT

2nd one is still dark from the supersampling, but man the caustics are all there very quickly! The first one was developing caustics dot by dot

This is expected with bidirectional path tracing.
When you have a large plane, rays are cast from the sky to all positions on the plane. Therefore the chance of the ray hitting the surface of the pool, and then making a nice caustic path, is much less than if there is not a big plane under the pool.

So, when using bidir path tracing / bidir mlt, try and make the size of the scene not much bigger than the 'interesting' portion of the scene - i.e. the volume you will be looking at directly.

I always thought Bidirectional MLT was smart enough to know when things can't be seen they shouldn't be attempted to be calculated?
What about stuff behind the camera that can't be seen, but will still influence the lighting?

so does the same thing happen with Pathtracing/MLT as well?
Well MLT doesn't seem to render the scene very well anyway....

No, bidir mlt isn't 'smart enough' to magically avoid all sections of the scene behind the camera, esp. considering the indirect illumination from them may be significant for the final render.

[CoolColJ]

I love the top right one O.o

you should have made a bump map from the high poly model and used it for the low poly one - that should give close to similar results, then

I just realiased... no bump maps on specular material

I have not had any luck creating an overhead shot of a pool where you see all those caustics under the water like you do in real life - is it an Indigo issue?