Why would pCont.getParticlePosition(i) not work? It did for me. Also, wouldn’t pCont.ParticlePosition only work for the first particle of the set? I thought I tested it and switching particles did not show a change in particlePosition.
The particles are being created twice because of the subframe sampeling (I think). The collisions are being called twice before the particles are deleted. It should not be able to happen (it feeds directly to a delete operator) but from what I can see it is. Not sure.
I will have to work out those two issues when I get home. For me, I think that the positioning worked opposite…the method call worked but the parameter check didn’t. I should check the manual about this. And the lights being created twice is odd, but shouldn’t cause problems. I think they are always created within the same frame, so it will not change the display any. I can probably script a check into the particles though.
Why would pCont.getParticlePosition(i) not work?
You are right, must be some strange update issue here.
wouldn’t pCont.ParticlePosition only work for the first particle of the set?
It works for the current particle which is set by index to “i”.
The particles are being created twice because of the subframe sampeling (I think).
I observed the opposite: When I set the intergration step for viewport to 1/8, I get less double lights (although not all doubles are prevented). I know that the doubles cause no trouble because they are deleted. But it is a strange behaviour. It makes the flow of the programm somewhat unpredictable. Or maybe – which is quite likely – I just don’t know enough about the flow of the events. Would like to learn more about this issue.
Boa
It didn’t work because I forgot pcont.usePosition = true. What a stupid mistake. That was probably what caused the different problems for both of us.
That double light thing should be impossible :banghead:. Not sure what is up, probably something to do with the way the method is called. But since it is just the listener, then I can live with it.
That double light thing should be impossible :banghead:. Not sure what is up, probably something to do with the way the method is called. But since it is just the listener, then I can live with it.
Live with that – of course. But to code well it is better to know what happens.
Which method do you mean? The fact that more subframe sampling gives less doubles points to the “flow” of PFlow events, how and when they are executed.
I expected that the operator sequence Script-Delete would be executed in that order. And in fact after the delete operator there are no more particles in the event. Is it deleted? Yes and No: When I put a script operator with a print pcont.getParticleID(i) before and after your script the listener shows that the particle is still there (a little bit less than a frame apart, e.g. at 178.319 and in 179.275). That is true for a 1 frame update interval. But sometimes this double thing happens also with an update interval of 1/8 frame with a time distance greater than 600 ticks.
Boa
Glad you guys are working so hard on this thing… Just, don’t kill each other or anything.
Haha we’re not at each others throats…yet 😈
Live with that – of course. But to code well it is better to know what happens.
I totally agree. I just am not sure I am capable of solving this problem.
I expected that the operator sequence Script-Delete would be executed in that order. And in fact after the delete operator there are no more particles in the event. Is it deleted? Yes and No: When I put a script operator with a print pcont.getParticleID(i) before and after your script the listener shows that the particle is still there (a little bit less than a frame apart, e.g. at 178.319 and in 179.275).
Not sure what you mean. If you are putting a test between the script and the delete, then of course it is still there. It has not been deleted yet. If you try that after the delete, you will find that they are all gone. Just be sure to use the ‘for i = 0 to numParticles()’ in that test, or it will always look like you have at least one particle.
By ‘the way the method is called’, I meant the underlying structure. I was thinking that if it is running threaded, the script could run, but get hung up on something (perhaps the delete, or the try statement itself). Then the next frame’s would run its script, and you would see that it has been run twice with the same particle. I would not be surprised if this was the case, since we have been explicitly instructed to not delete from pFlow.
I am kind of busy this weekend (Indy in Vancouver baby!), but I will try at some point this re-usuable light thing.
Doulbe particles – double post deleted
Glad you are still “in”. I presume that you would simply stop posting in this thread if this kind of basic research gets on your nerves. I’ve learned a lot from this thread and your script already. Without it I probably wouldn’t have thought about the “multiple lifes of particles”.
Let me explain my test setup and my findings:
The setup is as follows:
-script op with print commands
-your CreateExplosionLights script
-script op with print commands
-delete all
-script op with print commands
With Integration step set to 1 Frame most particles seem to have two lifes, sometimes even three, as in the following example:
1.Occurrence
“before light creation there are 1 particles”
“The particle before light creation has the index: 1 and the ID: 17”
“light created at 81.1188From particle 17”
“after light creation there are 1 particles”
“The particle after light creation has the index: 1 and the ID: 17”
“after delelete there are 0 particles”
then no particles seem to be in the event
“before light creation there are 0 particles”
“after light creation there are 0 particles”
“after delelete there are 0 particles”
2.Occurrence
“before light creation there are 1 particles”
“The particle before light creation has the index: 1 and the ID: 17”
“light created at 81.6From particle 17”
“after light creation there are 1 particles”
“The particle after light creation has the index: 1 and the ID: 17”
“after delelete there are 0 particles”
then no particles seem to be in the event
“before light creation there are 0 particles”
“after light creation there are 0 particles”
“after delelete there are 0 particles”
3.Occurrence
“before light creation there are 1 particles”
“The particle before light creation has the index: 1 and the ID: 17”
“light created at 82.3187From particle 17”
“after light creation there are 1 particles”
“The particle after light creation has the index: 1 and the ID: 17”
“after delelete there are 0 particles”
I get the same results even without try&catch and without the creation of lights. And the same doubles or triples when I eliminate all print commands plus the try&catch, so that there is only the create plus delete.
To me this looks like if particles have multiple lifes. Which I find quite strange. I’m not sure where to go from here. Maybe I’ll reread the PFlow help pages to see whether I’ve overlooked something.
Have fun at the Indy festival,
Boa
If I ever do run off, I’ll at least tell you first :wip:
My computer is out for a bit (reinstalling windows, and max isn’t on yet), so I can’t see this. So how did you figure that out? And do we know of a way to stop it from happening, or do we need to put a parameter into the particle that tells it if it has collided before? That could be done, but if it is just a setting in the collision, that would be awesome :bounce:.
And thank you for sticking around in this thread. Especially since you first showed up to help fix my problems :buttrock:. I myself am enjoying this, because it poses a challenge, and forces me to learn pFlow and maxscript better too. Thats never a bad thing.