Drastic CPU usage drop (Memory issue?)

Sorry for the rather unspecific title, but I really can’t figure out what is cousing this problem, but someone here might know the answer.

In certain scenes when using displacement, or heavy amount of proxies (many unique proxies) the cpu usage starts to fluctuate on a quite high frequency. The overall averaged usage drop to about 25-30% on all cores, and the rendertime goes sky high. This happened once on a quite complex scene hitting our memory limit, so we figured out than that the problem was that our memory couldn’t keep up with the cpu, but now it’s happening again on a simple secene, and it’s quite frustrating because of the fact that memory usage this time seldomly reaches 1GB, and there is 4 in those nodes.
Normally, without displacement, the scene renders quite fast (4-5 mins with GI) turning on displacement pushes it up to 1,5h… :expressionless:
The method (maps, amounts, ect…) used to do the dispalcement is frequently used here in various projects, and I also tried to render the scene witout any reflections, or glossies. Same happened.

Regards,

A.

How much RAM do you have in the machine. If you have a good amount have you tried increasing the VRAY:SYSTEM:smile:ynamic Memory?

I think I read somewhere that setting is used for proxies and displacement even if the memory setting is set to static.

That node has 4GB, problem is present in 32 and 64 bit environments too. tried to do it with both static, and dynamic memory, and also tried to play with the raycaster settings.

Is the memory limit still at 400M? Ifr so increase this to 1200 and see if it still occurs.

All the nodes have the default 400MB set to 1500 by default. :slight_smile: But I’ve tried it at 2000, and even at 3000, (approx 3GB ram is free atm of rendering), but this changed nothing.

i’ve seen this problem occur too - and it was on a system with 8gb of ram so i increased that setting to 6000 (it ended up using 4.5 or so for the scene) and basically fixed the problem… or at least improved it there was defiantly still some file swapping (unloading geometry it says) but the render times were much better.

The wierd thing is, that this is a small scene, just a family home, few objects, not a really big background, etc… We had this problem before, but back that was a huge scene with many objects, and a memory usage of aroung 3GB. This one, however only uses around one, in static, or in dynamic modes, never goes above that, and nothing would suggest it will ever do that.

How large are the rendered image?

How big are the displacement maps and what type of disp. do you use?
Are you using adaptive AA sampling?

/Jon

Map is several procedural noises combined, and I’m using 3D displacement with view dependent subd, set to 2px. Problem persists when using a bitmap for dispalce map, and with or without any AA.

Crashes

Is it an old scene? I had this same thing happen so I merged everything, except sun/sky into a new scene and converted everything to proxies… all went well after that.

What version of vray are you using at the moment?

Perhaps try raising your edge length abit. 2px could well be killing your render.

I’m having this same problem. We’re running Vray 1.5 Sp 1 with Max 2008 x64 on Windows XP 64 (SP 2). Dual quad core, 12 GB of RAM.

The scene is exclusively displaced muddy sand that stretches from one horizon to the other. one of the maps used is 6400x4800 px. The material itself uses layers of mix materials and procedurals, so it is fairly large but even after increasing the dynamic memory limit to 6000 MB I’m only using about 15% of the CPU and I have 10 GB of available RAM. Any suggestions/ideas? I’ve got to animate this so I’m desperate to optimize this.

It seems as though having a series of mix maps for displacement somehow affects the multithreading. I baked the chain of displacement textures into one 6400x4800 tiff file and increased the dynamic memory limit to 4000MB and knocked render times from roughly 16 minutes to just over 2 minutes… still only uses about half the available processing power, if I could sacrifice the resolution I’d probably scale the bitmap and I’m sure that would help, but it works for me now.