Hey Everyone!
It’s been about 6 months to a year since I last posted, so it’s nice to be (briefly) back.
I haven’t MaxScripted for about a year, so I’m a little rusty. I’m doing a farly basic “transform particle positions to geometry” PFlow script, just adapting the one in the tutorial, really:
on ChannelsUsed pCont do
(
pCont.useTime = true
pCont.usePosition = true
pCont.useOrientation = true
)
on Init pCont do
(
global boxes = $Box*
boxes.pos = [0,0,-100000]
)
on Proceed pCont do
(
partcount = pCont.NumParticles()
count = amin #(partcount,boxes.count)
for i in 1 to count do
(
pCont.particleIndex = i
local tm = pCont.ParticleTM
local box = boxes[i]
box.position = pCont.position
box.transform = tm
)
)
So, mainly that’s fine. However, there’s a noticable 2-frame or so delay with the boxes to the particles. Also, if I put my finger on the screen to check the “delay” the centers of the objects don’t actually match 100%.
I assume this must be a common problem! Can anyone shed any light on it?
Thanks,
Dave
PS. What is with the forum opening up 2 or 3 “adframe.php” windows in my HTML Editor on EVERY page load!? Is anyone else getting this!? Damn annoying!
First, try adding
pCont.useTM = true
to the Channels Used handler to enable the transformation matrix channel.
Remove the useOrientation as you are not using it.
Remove the usePosition line as position is included in the TM anyway.
Remove the line box.position = pCont.particlePosition for the same reason.
That being said, the script will be called BEFORE the integration step of the PFlow has been performed, thus your positions will be one integration step before the actual particle positions.
Imagine this –
- PFlow updates all operators to set all channel values.
- Among those operators, it sets the box positions based on the current content of the position channel
- Once all operators are done, PFlow integrates the particles by adding their velocity to their current positions, which brings all particles to a NEW position, but the boxes are one step behind.
If you use a very low integration step, the offset will become less noticeable, but will slow down the updates. One option is to read the particleSpeed channel and compensate by adding a fraction of the speed vector to the final position of the box based on the size of the integration step. This will also require checking for viewport vs. rendering and taking into account the corresponding integration step. But if a particle hits a deflector and changes position, your compensated position would be wrong.
Alternatively, you could look into Every Step Update scripting which is executed after the integration step and would thus contain the actual position values for the current frame after the particles have been processed.
Hey bobo,
Thakns for the reply. Yup I realised I had left a few statements in there. I was just playing with the syntax, then rushing out the door to go to a meeting!
But thanks for explaining about the delay – that was the thing that was really foxing me. I’m probably going to go the root of the PFlow script interface now, but it’s good to know.
Cheers,
Dave
Is there any reason “at time” doesn’t work with the PFlow interface commands?
A loop using “at time” returns only the values at frame 1, whereas “slidertime” will return the correct values (albeit more slowly).
I can only assume that this is part of the incremental nature of pflow’s updating?
EDIT: And it has to be visible too…?
If you are running an EXTERNAL script accessing PFlow data, you will have to move the slider to ensure the particle system is updated correctly (it can take a while). You CANNOT use at time() as you have noticed.
Inside of the PFlow scripts, you will have to get the current time of the particle container (as shown in the Birth Script example) because PFlow Operators have their OWN time measurement and can be called by the PFlow integrator multiple times per frame…
Thanks Bobo.
I was delving in the docs and came across…
<void>updateParticles particleSystem time
…which seems to work just fine in the editor! I compared it with an extact-same slidertime function and the splines seem identical. I think I’ll trust it for the time being