I’m not sure if it’s just the beta, or if it has always been this slow…
I’ve got a scene where the camera is inside the bounding box of some PRT Loaders. So particles are very close to the camera as well as behind it. When rendering without DoF, the sorting/rasterizing (I have LCache on) takes ~2min. When I turn DoF on, with sample rate of .00001 all but the very last “chunk” of the render to the vfb happens fairly fast, but the stuff really close to the camera (and thus very high in blur) takes forever. Well over an hour. Is that normal?
I’m trying to gather more data, but it’s going sooooo slow. Just wondering if I’m expecting too much.
I suspect it is As Designed, but some form of a cutoff to prevent particles too close to the camera from attempting to draw over the whole image might be a good idea. Let’s see what Darcy thinks about it…
That being said, while the new multi-threaded drawing coming your way is not balanced to deal with DOF irregularities, in a test scene with 8.3 MP I got the following numbers:
*Beta 4 (your build):
**Loading, Lighting and Rendering, No DOF: 17.187 sec.
**Rendering only (PCache and LCache on), No DOF: 5.125 sec.
**Rendering only, DOF 0.1: 22.547 seconds
**Rendering only, DOF 1.0: 162.437 seconds
*Beta 5 (our build):
**Loading, Lighting and Rendering, No DOF: 13.937 sec.
**Rendering only (PCache and LCache on), No DOF: 1.906 sec.
**Rendering only, DOF 0.1: 4.969 seconds
**Rendering only, DOF 1.0: 41.969 seconds
Currently the 8 CPUs get equal slices of particles, but if the front or back particles are out of focus, they will have to draw a lot more samples, so this is currently not taken into account by the multi-threading. Most slices would finish rendering and the slowest one will take longer.
I had a KCM that deleted random particles as a smoothstep between some ranges based on nearness to camera. Worked awesome in the viewport… But the render went haywire. Values all over the map, rendered like Christmas lights (the tacky kind). Rendertimes were low, since the near particles were missing, but the render was useless. I’ll try to make a repro case with simple PRTs soon. Just have to get this shot to the farm for the weekend…
I suppose an option for a built-in softclip (you’re sorting to the camera anyway, why not?) would be simpler to use. Either do what I was doing and delete a percentage of particles between the ranges, or fade them off in the density, and delete them when the density gets very close to 0. The first approach was fine in my case, since the fewer particles were turning into larger disks, so you didn’t miss them.