when I cache PF spawned particles to *.prt ssequence this sequence doesn’t match original particles why this happenes?
Krakatoa
deathstone
#1163
Glacierise: Different viewport/render sampling?
what sampling? in prt loader? there is no such kind of settings…
http://img10.imageshack.us/img10/3681/screenrb.jpg - blue lines - PF particles, black - prt loader
bersu
#1165
i got a black render screen after i get to 5 seconds of animation , at first it renders ok but then it suddenly renders black screen, i checked the stop emmiter , the fume fx stop emitter , it just goes off, ani ideas why ??
Bobo
#1166
If this is a FumeFX problem, you might have more luck posting in the FumeFX thread.
If you feel it is a Krakatoa issue, be sure to check the Log Window and see if the renderer is reporting more than 0 particles on those frames. If you are getting 0 particles, then the problem is not in Krakatoa but somewhere in your setup. At that point some more detail about your setup would be useful…
bersu
#1168
when i render a single frame at the middle or end of the animation , i see the particles but when i do the avi file after a few hundred frames particles slowly dissappear… can it be the lights not rendering? the amount of particles of the system?? i do get 0 particles on the log file when im iafter those frames.
JohnnyRandom
#1169
Kinda sounds like PF Source->Particle Amount is at default of 100.000 particles, who knows, it is hard to say though without knowing more about your scene. Guessing games are fun 
BTW never ever never ever ever ever render to any container format (avi, quicktime, ect.), always always always render to frames 
If/when your render goes bad, you have to re-render everything = not good. The one exception to the rule might be for quick previews.
bersu
#1170
i increased the limit to 100M so i dont think thats it , yeah ill just render to a file sequence and see
bersu
#1171
i set a rate of 5M particles at fumes birth , when it reeches the 100 frames particles reeches the top count , after the 100 frame particles number lowers to 0 in the continiuing frames.
JohnnyRandom
#1172
mmmn, more guessing, does your fume simulation go the duration of your timeline? If your fume sim ends at frame 100 (the default range for fume) pflow nor Krakatoa will see your particles.
Maybe start a new thread so this one doesn’t get polluted with non-krakatoa specific troubleshooting 
friedpixels
#1173
i consider myself pretty much a newbie with pflow and krakatoa, so i’m always doing small animations to figure things out just wanted to share a building debris/dust test.
Bobo
#1174
Great test, James!
I really like the fine grainless quality of the Krakatoa rendering. You know how I hate seeing individual particles (except when they are supposed to be sand, of course )
Keep them coming!
Btw, Krakatoa v1.6.0 is due out next Tuesday!
friedpixels
#1176
thanks bobo! heh yeah I know you appreciate to see non grainy stuff i’m using the latest build - now that i have a decent PRT sequence to play with, I wanted to play in the KCM and see what i could possibly break
Something I also ran into, an older issue… is there a workaround for getting a particles lifespan / age without using a delete operator? I’m using age test and of course get 0,0 - I know people have said using box #3 you can use one of those nodes, but I don’t have that. I found a script on your site for changing the speed with a script operator, was going to see if i could tinker with that, im just not that fluent with scripts. sorry if this has been asked/solved before
Bobo
#1177
The Delete Operator is a requirement of Particle Flow. The Lifespan is otherwise set to infinite (or at least to a very large number), and you have to set it to a finite value for the Age/Lifespan to work.
In theory, you can set it to a value much higher than the length of your animation, and then compensate in the KCM for that. For example, if the animation was 100 frames but you specified 1000 frames to live, your Age/Lifespan will be typically between 0.0 and 0.1 for a particle born on the first frame of your animation. You can always multiply that by 10 to get 0.0 to 1.0 within the active animation without the danger of a particle actually dying within it.
friedpixels
#1178
Hmm maybe its just the current setup I have that is confusing me. I’m sending the particles to another event to get deleted, not adding any lifespan to them, but still wanting to affect their density by how long they were alive in the scene. Sorry i know this is more pflow related than krakatoa, don’t mean to derail the thread.
JohnnyRandom
#1179
You can however cheat and throw a Delete Op in the global node and set it to the oldest possible age of a particle.
Also you can easily set the particle lifespan with a script op in the global using the .useLifespan channel
on ChannelsUsed pCont do
(
pCont.useLifespan = true
)
on Init pCont do
(
)
on Proceed pCont do
(
count = pCont.NumParticles()
for i in 1 to count do
(
pCont.particleIndex = i
pCont.particleLifespan = 100 --the oldest possible age value in frames
)
)
Bobo
#1180
Unfortunately, Pflow cannot predict when a particle will really die without running the whole sequence frame by frame. In your case, the deletion happens when the particle hits the deflector OR when its age exceeds a value with random variation. It is thus not possible to know on frame 0 what will happen 100+ frames later, and the LifeSpan remains unknown. Even if you would run some script to dump the actual age of the particle on the frame it died into some channel, you would have to do that retroactively for all previous frames.
A possible solution would be to do it in two passes:
First run a script that advances the PFlow and collects the death times of all particles into a global array. Then a Script Operator could be set up to read from that array based on the particle ID and initialize the LifeSpan to the value stored in the array. Saving that to PRTs would possibly result in what you need… Unfortunately, if you have millions of particles, this might turn out to be very slow.