Slow shadows in beta 10?

Rolling back to beta 9 is really hard (please give us just a zip file for install), so I haven’t done a side by side, but shadows seem to be going really slow in beta 10.



I have about 43 million particles in one loader and one fspot. The fspot has a map setting of 512 pixels and the render is using final pass density for lighting density (no override). Draw point filter is Bicubic, self-shadow filter is Nearest Neighbor. Render image is 864x486



First I do a render with PCache on (LCache off) to remove the overhead of the particle loading off the network.



Render time 9:02.



Second, cached, render takes 3:41.



Turn off lighting and re-render, and the render time drops to 1:36.



Considering that both renders had to load the particles off the network, the lighting seems to be taking an aweful long time. 512 with nearest neighbor should be really fast, no?


  • Chad

I switched to bicubic for the shadow filter, and render time jumped to 25:25.


  • Chad

Just so you know, there was some broken code in the lighting section in 0.9.9, so if you want to compare, use 0.9.8 as reference.



We will investigate what is going on - chances are 0.9.10 is also broken :o(



Cheers,



Borislav “Bobo” Petrov

Technical Director 3D VFX

Frantic Films Winnipeg

Sorry, I need the visiblity !=1 working, so I guess I just need to live with slow renders.


  • Chad

Sorry, I need the visiblity

!=1 working, so I guess I just

need to live with slow

renders.


  • Chad



    You misunderstood.



    I ASSUME that 0.9.10 is wrong and should not be slow. So if you want to KNOW whether it is a bug or not, compare speed with 0.9.8.



    That’s what we are going to do - if it used to be fast and now it is not, something smells fishy.



    But 0.9.9 had a bug in just that part so it might be artificially faster than it should be.



    Cheers,



    Borislav “Bobo” Petrov

    Technical Director 3D VFX

    Frantic Films Winnipeg

Hmmm… Doesn’t seem so bad with fewer particles. Slow renders are hard to test.



If I run out of memory, would that make things slow, or just not go at all?


  • Chad

If you’re hitting swap space, then things will definitely get slow, but not necessarily crash. You can check the task manager during a slow render to see if it’s hitting swap space.



Cheers,

Mark

A note from the developer:



“For a single light, the lighting pass should be about the same speed as the final pass.

For two lights, it should be about double, etc.

(when motion blur and DOF are off)”



The lighting pass is a form of rendering, but from a different point of view.



How many lights do you have?



Cheers,



Borislav “Bobo” Petrov

Technical Director 3D VFX

Frantic Films Winnipeg

One light. Just the fspot. And the map was 512, which makes it comparable to my final render frame.



I did another test while watching taskman. Memory creeps up to 2.5GB, then drops to 500MB. VM Size went to about 3.3GB. So that may be the problem. Turn off light, and everything fits?


  • Chad

Ack.



Render Selected doesn’t work with PRT loaders, at least in beta 10. All the PRT loaders were rendered.


  • Chad

Yeah, it’s definately a swap issue. When you keep it in RAM, the speed is fine. But when you swap, you have to swap for each light in turn.



Time to break out the max 9 CD…


  • Chad

That seemed to help. Extra couple gigs is nice. 80 million particles rendered OK.



But I think there’s more bugs to find. Had one render where PRT loader visibility was <1 and got no color. I’m moving to beta 12 now, and I’ll keep eyes open.


  • Chad

Ok, now with beta 12, shadows are really slow…



Max 9, VM Size is same as Mem Usage, so I don’t think it is swapping. 4 GB still available.



I have 40 million particles, and one light, map size 100, and I killed it after about 40 minutes.



The shadow generation doesn’t even appear to be multithreaded. Is that normal?


  • Chad

Ok, I’m moving this to the bug reports, as I can now articulate it.