Hey guys!
I am trying to render some particles (5 million), using an animated emitter, that start emitting at frame 5, but everytime Krakatoa reaches frame 5, an error message is being given out with “bad allocation”. What does that mean exactly? Where should I look for the error? Any workaround?
Thank you!!!
Greets
Emil
Would I guess right if I would say you are using 32 bit Max?
“Bad Allocation” generally means that Krakatoa has run out of memory. I have NEVER seen the message in a 64 bit version of Max running on WinXP - when physical memory is used up, 64 bit Krakatoa would use the virtual memory, swapping like crazy but never crashing. As you probably know, a 32 bit application can address only 2GB of RAM in the normal case, 3GB with the special Windows startup switch and 4GB if running under WinXP 64.
If you are rendering straight from PFlow, you are sharing memory with PFlow which has to put all the particles somewhere, and Krakatoa which also has to load the particles in memory to process them.
Thus, the only workaround in Max 32 bit is to save the particles to PRT sequences - Krakatoa does not use up memory when dumping particles to disk, thus all the memory is available to PFlow to process particles and you can get more particles calculated than when Krakatoa is also using memory. Then, you disable PFlow and render from the PRT sequence, eliminating the memory consumption of PFlow and having all the memory for Krakatoa.
Still, if memory is heavily fragmented, a Bad Allocation error might happen.
In short, the only real remedy is to run Krakatoa on 64 bit Max under 64 bit OS - not only does it not run out of memory, but it also renders twice as fast due to the faster allocation of non-fragmented memory space.
Thanks for the answer, Bobo! Burning the midnight oil? Oops, I meant the sunday oil… 
I work on a 64 machine with a 32bit max8. I considered a PRT sequence, but then I don’t think that Script and Mapping Operators from PFlow would work, wouldn’t they?
Thanks!
Greets
Emil
Thanks for the answer, Bobo!
Burning the midnight oil?
Oops, I meant the sunday
oil…
I work on a 64 machine with a
32bit max8. I considered a PRT
sequence, but then I don’t
think that Script and Mapping
Operators from PFlow would
work, wouldn’t they?
Why wouldn’t they? Anything PFlow generates gets written to the PRT File, including colors and mapping (any of the 100 channels, you just have to add them in the Save Channels rollout).
If you are doing the Red/Green age mapping, the color PFlow has calculated would be saved in the PRT and loaded for rendering.
If you want to re-texture your particles AFTER saving the PRT sequence, you would have to make sure the desired mapping channels (or vertex color channel) are added to the set of channels to be saved.
In general, the PRT is meant as an intermediate snapshot of what the particle system looks like. In the past, it was used to move the data from Max to the stand-alone renderer, so it MUST render just like the PFlow would…
As for the oil, I have to fix some shots for a movie we are trying to deliver, so the day of the week plays no role… ;o)
“Bad Allocation” generally
means that Krakatoa has run
out of memory. I have NEVER
seen the message in a 64 bit
version of Max running on
WinXP - when physical memory
is used up, 64 bit Krakatoa
would use the virtual memory,
swapping like crazy but never
crashing.
Yeah, we have a scene with 1.67 Billion points (color, density, and normal) rendering on the farm now. We get a frame done every day or two. We went back and optimized the scene, but left the old one in to see what would happen. Doesn’t crash, just slow.
- Chad
Yeah, we have a scene with
1.67 Billion points (color,
density, and normal) rendering
on the farm now. We get a
frame done every day or two.
We went back and optimized the
scene, but left the old one in
to see what would happen.
Doesn’t crash, just slow.
In Krakatoa 1.0.1, 1.67 billion particles require 60520MB of RAM.
In 1.1.0, the same number of particles would require:
*50964 MB if no velocity channel is needed
*41408 MB if no velocity and no normals are used
*31852 MB if no velocity, normals and lighting are used
*22296 MB if no velocity, normals, lighting are used and a single solid override color is used
Of course, most of the time you would use all channels, but when you don’t need them, memory usage would go down a lot. :o)
Hello Bobo,
I have encountered the problem again: on a max8 32bit installed on a 64bit machine. The error occurs when I try to write the PRT Sequence to disk after already creating some frames from the scene. The PFlow event contains around 150 000 particles with some Age Tests and one Find Target. Is it possible to render out the PRT Sequence using max9 64bit and import it then in max8 32 bit? Any read/write issues?
Thanks!!!
Greets
Emil
Hello Bobo,
I have encountered the problem
again: on a max8 32bit
installed on a 64bit machine.
The error occurs when I try to
write the PRT Sequence to disk
after already creating some
frames from the scene. The
PFlow event contains around
150 000 particles with some
Age Tests and one Find Target.
Is it possible to render out
the PRT Sequence using max9
64bit and import it then in
max8 32 bit? Any read/write
issues?
If you have access to 64 bit Max, you shouldn’t even use Krakatoa in Max 8. The only reason we still support Max 8 is that Thinking Particles is not officially available for Max 9, 2008 and 2009.
There should be no issues when saving PRTs from Max 9 64 bit and loading in Max 8.
Is it possible that Particle Flow causes that error with some difficult-to-process event or operator (like Find Target?). The first frames of my animation (0-33) are being saved very quickly (particles attached to moving object) but after they enter into a new event (starting at frame 34) with Find Target, the process times go up and finally “Bad Allocation” appears (at frame 34). The scene contains 90 000 particles (that should be nothing for Krakatoa!)
Thanks in advance
Emil
EDIT: ok, just tested with 9 000 (nine thousand) particles: Bad Allocation!
Can you render out the scene without Krakatoa without the error?
- Chad
yes, the scene can be rendered out without problems with another renderer… So it seems some Krakatoa Problem maybe in combination with Find Target?
Greets
Emil