pflow not rendering entirely with krakatoa

#1

i got a 450 frame animation with fume fx and krakatoa applied to it , at frame 100 the particle count starts dropping to 0 on the next frames, i have the start of fume birth at 0 , end 450 , the fume fx grid also has start 0 and 450 end , so i see the preview on fume fx , i exported the velocity channel , and thats it , i see hte particles in viewport with krakatoa, ( i set it to 5 M, which reeches that number at frame 100 and then it starts loosing particles in render, i see them in viweport…)
im i missing sth ??
also on particle view i have the empty flow >>>>>fumefx birth>>display>>>fumefxfollow>>>delete. at 60 frames for particle age.

#2

Here is an example, that works, granted I wasn’t going to wait around for a large particle count to cache, save, and render but this is basically what your scene should be based upon. Look and see if the settings you have are similar to these.

Feel free to post an example file that demonstrates the issue you are having, it is certainly a lot easier than having me (or someone else) guess what is going on. :slight_smile:

#3

to jpegs of what happens in time in render., i tried your file but it happens the same thing. , btw max 2011 x 64 , fumefx 1.2e

#4

What does the fume preview look like for the frame that has dissipated particles?

#5

, actually emitting voxels till the end , nothing like that , i see the smoke 100 % visible.

pd if i set the fume birt rate to 1M it renders more frames, if i set it to 10M it renders much less till the particles dissipate anf fade away

#6

You are definitely hitting a limit then, what limit, as I mentioned earlier could be the PF Source count limit, that is exactly what it sounds like. If that is not it, I am not sure, Have you tried saving the pflow to PRT?

#7

Sounds like the PFlow limit to me.
The PFlow emitter has an internal limit to the number of unique IDs it can assign during an animation. Even if particles are being deleted, new particles added to the flow must have new IDs, so after a while you could run out of possible IDs.

The solution to this is hidden in Krakatoa - reduce the birth rate to something that lets you generate particles during the whole 450 frames (half a million, or 100K or whatever works), then generate several partitions of the same simulation and load the resulting sequences in a PRT Loader to combine into a multi-million particle cloud.

#8

thanks both , i did what u said and it works , is that a ram limit im having , cause of the ids?? or it can be fixed changing a parameter??

#9

Oleg knows the exact details, but if I remember correctly, when PFlow was originally developed, there was an internal limit to the total number of particles that could be created in a single emitter. The number 100 million kind of comes to mind, but I might be remembering incorrectly. I was under the impression it was lifted in later updates of PFlow, but I am not sure what the exact story is. You might want to post on the Orbaz forums to find out the details.

So it is not memory related, just 10 years ago 100 million particles sounded like an impossible count.

On the other hand, Krakatoa can handle as many particles as the memory allows (see the calculator in the Channels rollout). Typically you can fit around 600 million particles in 16 GB of RAM (more or less, depending on what channels you are using).

#10

i take it back , i tohugh it was working , at least the dissipating particles was fixed , it was rendering good but now i got an error “Zlib call for inflate” error code -3 , and i only have 5 more days of demo…

#11

The Zlib error means a file is corrupted, it is unrelated to the PFlow problem you were having.
If the corruption is in a single file of a partition sequence, you can either remove that partition from the Loader, or regenerate that frame only.

You can run Krakatoa in Evaluation mode forever and render up to 480x360 without a watermark even after the license expires (that should be good enough for YouTube demos). And of course you can still save particles to PRT files without a license. Of course, if you intended to produce a production-quality rendering at a higher resolution, that would be a problem. You could ask for an extension of the evaluation period in that case.

#12

I asked Oleg…

Quite curious myself, although I never really bother going any higher than 20 or so million (depending on complexity) simply because it take way to long to update.

PRT’s are your friend :slight_smile:

#13

IF its 1 billion then why am i having that problem :frowning: how do i fix the corrupted files , caus im getting quite a few , dont i loose particles if i delete the loaders?

#14

Good question. Assuming you are running Max 64 bit 2010 or 2011, I wouldn’t expect PFlow to hit the limit within 100 frames. But it is possible that the FumeFX Birth operator has a similar issue - might be worth it asking Sitni Sati whether they have imposed their own limitation to avoid going over the old 50MP limit of PFlow…

#15

dont i loose particles by deleting loaders?
pd for example i get that the prt 38 of 100 _ 0048 is corrupted ( zlib error)
how exactly do i fix that one in that sequence??

pd2 is that my systems error or krakatoas error , why do i get corrupted files anyway?

pd3 if i delete 4 of 100 loaders , does that mean i loose in this case 400k out of 10 M particles?

#16

If you are using Krakatoa as intended, you would need only one PRT Loader and all sequences would be loaded in it. So you could disable the sequence that has missing / bad frames, or remove it from the PRT Loader. If you have 20 sequences with 1 million particles each and disable one partition sequence, you will still have 19 million particles to render. If every sequence has bad frames, then you are screwed. In any case, it would be a good idea to resave those frames that refuse to load. While the pre-rolling of PFlow could take a while, not saving all good frames will reduce the total processing time significantly. In fact, if you can figure out which frames are bad, you could delete them and then run the partitioning with >Skip Existing Frames checked, thus saving only the frames that were deleted.

How many partitions have you created? How many particles do they contain? How long does it take to process one partition?

Btw, if you run the Particle Analyzer tool (found in the Krakatoa category of Customize User Interface), does it report any frames as bad? The info it reads is uncompressed in the header, so it might not catch those, but if it does, it would be useful to detect the bad ones.
The same functionality can be found in the last rollout of the PRT Loader by switching to Particle Count Graph mode - does that show red vertical lines for the bad frames?

#17

I hope you did not actually make 100 PRT Loaders in the scene. If you did, than I have failed completely with the documentation of Krakatoa :cry:

Obviously, if you remove 4 partitions with 100K each, you will have 400K less particles, but the overall look of the cloud won’t be that different.

Why exactly a frame is bad is difficult to answer, all I know is that some frames were written incorrectly and since they are in a ZIP stream, the Zlib cannot decompress them. Could be a disk issue, OS issue, Krakatoa issue, or if the file is on a network, a network issue.

#18

im sorry, i meant sequences not loaders hehe, my mistake :slight_smile: i started deleting sequences as u said and it works even though i loose particles , i see the particle count u mentioned and i chose dont render missing files , so i went and deleted that specific one instead of the whole sequence, does that make any difference?

#19

The “Don’t Render Missing Files” button in the PRT Loader tries to detect missing frames in the sequence (actually missing from disk), and will disable a sequence if it has missing frames. So if you deleted the bad ones and pressed the button, the bad sequences would be unchecked, and you could remove them from the PRT Loader after that if you want, or resave them if you have time.

The “>Ignore Missing Particles” option in the Main Controls rollout on the other hand would suppress the error messaging of the renderer and ignore the fact that some sequences might be missing a frame. This is mainly for quick test renders while waiting for all partitions to be generated. It is a bad idea to use because it could produce flickering frames.

I don’t think that anyone would be able to tell the difference between 9.6 and 10 million particles…

#20

ur gonna luagh abt this, now that i ahve the entire animation , foolish of me i deleted all the prt files, cause i hadd all the png files to post edit , now i have a png error , in after effects cs5 , i think its a corrupted png file xD so now i have to wait fot particles to load in order to re save that frames specifically :D… i think its my destiny not to be able to make a krakatoa demo XD XD XD

btw i think iv been helped alot by you bobo and random , thanks :slight_smile: no way i could have done this by my self.

and i still get the dissipating particles , only god knows why !! why isnt it constantly emitting the particle count i set , and decides to fae away the particles , haha its driving me crazy.

ok somehow it has to do with the time that particles are emitting , i managed to get a good quality , actually the total amount of particles i wanted , in a specific frame at the middle of the animation, i only changed the emitter start to 120 to stop at 150 , and it seems that solves the problem for now, maybe my pc couldnt handle 10 M x 450 frames , cause as u said 16 gb can take 600 million , and as i have only 4gb , maybe thats the reason, that in time i cant handle 450 million particle ids ??