I myself am enjoying this, because it poses a challenge, and forces me to learn pFlow and maxscript better too.
Great to meet someone like minded :bounce:
I found “the guilty one” by substituting the Collision by a Send Out All operator.
Maybe we have to go the route you proposed. Test speed after collision, setting an flag or something and then sending out …
The problem has shifted from double lifes to double collisions which I find also hard to understand. This is what I would expect: With Integration step set to 1 Frame I would expect the test to miss some hits but where it test true it should send out the particle and this particle should not be in the event any more. With a tighter integration step I would expect the test to register more hits, everything else shoud be the same.
Two things puzzle me:
-
The collided particle isn’t in the Birth event after the collision when tested with a print comand in a script. How can the particle collide twice then? I don’t know whether it is something in the collision operator or caused by the integration step or both.
-
The Integration step seems to be not only depended on the option you choose but also on how much is to do in the event. There is a funny way to prevent the double collision: Put another script operator before the collision operator. With two scripts with print commands in the Birth event PFlow seems to have enough to do …
Here is version of your explosion scene with all the print scripts:
http://www.bitfresh.com/info/explosions02-print.zip
I’ll read all passages about collision and integration step in the manual again. I’ll think I miss something very basic here …
Boa
Even with all the printing, it still has problems. A particle is removed from the event (and the ‘after’ part shows it gone) but the next frame it returns again, so it is now in two places. I would think that is a coding problem with pFlow itself. We can probably make a workaround, but we might want to bring this to Oleg, as it seems to be a genuine bug. I will be able to look at it better tomorrow, so until then, have fun.
And Cryptite: Not sure you even need this anymore, but thanks for bringing up the idea
Ha, yes I still need this… I’m just happily watching along as you guys figure this out and bat out the bugs in it. I’m just trying to keep up with what you guys are talking about. You’re pretty much beyond me now!
I have made a stripped down scene that illustrates the error and posted it on the discreet board. Hopefully Oleg will respond, and we will see what is actually going on.
Hopefully Oleg will respond, and we will see what is actually going on.
He has answered but it looks like he didn’t see the bug. I have posted an reply.
Boa
Well, it looks like he will not be getting to the error, so I will go ahead and start on figuring out a workaround. Oh well, we’re losing out to Particle Flow Tools, so we will still get something ;).
We will have to pay for Particle Flow Tools since Oleg does not work for Discreet any more 🙁
Do you already know which route to take for the workaround? Maybe a scripted collision would work that the operator should?
Boa
I’m not sure what I will do for this workaround. I doubt I could script a new collision, so thats out. I was going to just set a property in the particles themselves (particleInteger) but the problem is the particles are actually seperated into two unique particles from the collision problem, so what I do to one will not affect what I do to the other (just tried it :wip:. I will have to think this through further. And ideas would be welcome.
Sorry, I don’t have a solution yet. I tried to delete particles with Speed == [0,0,0] before collision. This works most the times, but not all :shrug: And pCont.numParticles() isn’t updated after delete …
I used the following code:
on Proceed pCont do
(
if sliderTime.frame != 0.0 do
(
for i=1 to pCont.numParticles() do
(
pcont.particleIndex = i
if pcont.ParticleSpeed == [0,0,0] then
(
pcont.deleteParticle i
)
print (pCont.numParticles() as string)
)
)
)
Have you guys had any luck recently with this? Just wanted to check up…