ZBrush 3.1 - Win Vista x64 - over 4GB RAM - compact memory question

[Rodin]

I’m hoping someone can help me out with a couple of ZBrush 3.1 memory questions.

I’m running ZBrush 3.1 on a Windows Vista Ultimate x64 machine.

I recently upped the RAM from 4GB to 6GB. After doing so, I also upped ZBrush’s compact memory to 4096.

Even though I’ve added more RAM and upped the compact memory size, ZBrush still begins compacting the memory at about the same number of Active Points it did when I had 4GB of RAM and a lower compact memory setting (around 3000).

Shouldn’t the added RAM and increased compact memory size have increased ZBrush’s ability to handle more active points/polygons before compacting memory?

My second question is that when I up the MaxPolyPerMesh setting from say 12 to 20, ZBrush isn’t preserving my change the next time I open ZBrush. ZBrush has perserved every other change I’ve made to the UI, but not this one.

I greatly appreciate any help/insight you can give me on these two issues.

[aurick]

Your first question stems from the belief that point count is the sole factor in determining when ZBrush has to compact memory. It’s not. There are many, many factors. The additional memory won’t necessarily make a significant difference in how often ZBrush has to compact. It will, however, make a difference in overall performance and the size of the models that you can work with.

As for the second question, I would have to check with the development team to be sure, but I think you’re bumping into a safeguard mechanism. In other words, ZBrush is letting you set this value higher on a session basis so that you can work with models of that size. But at the same time, what you’re doing is not recommended and so ZBrush isn’t allowing you to save the setting. You will ALWAYS get better performance by splitting a mesh up into multiple parts. So four 5 million poly SubTools will give better performance than a single 20 million model.

[feureau]

Shouldn’t the added RAM and increased compact memory size have increased ZBrush’s ability to handle more active points/polygons before compacting memory?

ZB is still, only a 32 bit app. When running under vista ultimate x64, (like I’m running) it will still run on 32 bit emulation. I think that means it will only get 3gb max. However, if you use readyboost, it’ll help the compact memory problem a bit, I find.

My second question is that when I up the MaxPolyPerMesh setting from say 12 to 20, ZBrush isn’t preserving my change the next time I open ZBrush. ZBrush as perserved every other change I’ve made to the UI, but not this one.

I’m having this issue as well. Sometimes you can get lucky when you save the UI config and the config. Be forewarned though, it would also oftenly destroys your tablet pressure settings.

[Rodin]

Your first question stems from the belief that point count is the sole factor in determining when ZBrush has to compact memory. It’s not. There are many, many factors. The additional memory won’t necessarily make a significant difference in how often ZBrush has to compact. It will, however, make a difference in overall performance and the size of the models that you can work with.

As for the second question, I would have to check with the development team to be sure, but I think you’re bumping into a safeguard mechanism. In other words, ZBrush is letting you set this value higher on a session basis so that you can work with models of that size. But at the same time, what you’re doing is not recommended and so ZBrush isn’t allowing you to save the setting. You will ALWAYS get better performance by splitting a mesh up into multiple parts. So four 5 million poly SubTools will give better performance than a single 20 million model.

Thanks for your response aurick. As you mention, I have begun to notice that there are a number of factors that effect when ZBrush compacts memory. As one example, I’ve noticed that I can divide two different meshes to similar poly counts, but only one of those divided meshes triggers ZBrush to compact its memory. Your hunch on the second question sounds right too. I’ll check it out.

I do agree that dividing a large model into smaller more manageable parts is the way to go too.

Thanks again.