50% CPU usage

[richard_rosenman]

Hello;

I've been testing the latest release (we are still using 1.45.70) and one thing I can't seem to figure out is why my HT CPU's (in the task manager) show them working at 50%. There are occasional 100% peaks but for the most part they remain at 50% during both the irradiance map calculation and the rendering. When I switch back to 1.45.70 the CPU usage stays at a solid 100%.

I wonder if anyone else is experiencing this? I still should try it with a standard file as the one I'm using is one which was setup with 1.45.70. I think I did render a sphere and I think the cpu stayed at 100%. But I thought I would check anyways and see if anyone else had this problem?

-Richard

[vlado]

Richard, do you have any dynamic geometry in your scene (proxies, displacement, subdivision surfaces)?

Best regards,
Vlado

[richard_rosenman]

Hi Vlad;

Yes, it is a ZBrush scene so it is using extensive 3D displacement with heavy meshsmooths. I'm not using the adaptive subdivision feature in the new build, just the 3d displacement with the old fashioned meshsmooths in 3dsmax 6.

Umm, let's see if there's any other info I could give you. Textures are massive (4K). I've also noticed, with both builds (old and new) that as the image renders the ram progressively increases until I get an exception error. Is this a memory leak? I've followed your suggestions on lowering memory use by collapsing geo, reducing bucket size to 16x16, changing to Adaptive QMC sampler from the Adaptive subdivision which I always use, and using dynamic memory. Also turned on bitmap pager. This certainly has helped and I can get more than half od my 4K image rendered but the memory still continues to increase (more slowly now) until it crashes. I'm assuming it could be garbage built up in the file because I haven't noticed this problem before.

-Richard

[gafl]

Hi all !

Yes I do notice that "problem" too.
It seems coming from displacement.More in 3D mode.
The image size has also an effect on it. Memory ...!

I did notice it with not so much intensive 3d displacement map.
Bye
Gaël

[vlado]

Some parts of the 3d displacement are not multithreaded (e.g. the generating of the displaced geometry itself). This may take some time if the displacement map is a slow procedural map, or if there is a lot of geometry to displace.

Best regards,
Vlado

[gafl]

Of course !
I can understand it
Thanks

Gaël