Bad allocations?

I’m running out of memory at ~20 million particles without loading color, Is that supposed to happen so soon?

I’m currently seeing similar results here on a 2 GB system. It will vary

depending on how much free contiguous RAM is available, but you probably

won’t get too much more than that within 32-bit 3ds max.



You’ll need 24 bytes per pixel for the framebuffer, and approximately 32

bytes per particle. A 1K render of 20 million particles would approach 0.7

GB. (On my system, with an empty 3ds max loaded and essential computer

utilities, task manager shows about 1.5 GB of available physical RAM, so in

a perfect world, I might be able to push into the 40 million particle

range.) I’ll ask the production guys what sort of numbers they’ve been

pushing through.



I’m not sure of the space used for shadow buffers, so lighting calculations

might add to the memory requirements.



We are looking forward to releasing a version for Max 9 – in particular the

64-bit version – which will blow the lid off the physical RAM requirements.

The biggest reason for that is address space fragmentation within 3ds Max. This problem goes away with the move to 64 bit, where you will be able to use all your RAM. A console-based renderer can also do more particles because it doesn’t share the 3ds Max address space, but we’re planning that for a later update rather than putting that in Krakatoa 1.0

Oh, ok. When do you expect the max 9 version to be ready?



Just to clarify, all of the particles need to be in memory to render? You can’t load the background ones, render, toss, load middleground, render, toss, etc? I guess that’s what I was expecting with “painters algorithm”.