Stop gradually and vortex don't appear to work together

#1

Hi there,

I’ve got a vortex with no radial pull, which is just making particles go round in a vertical circular tube.

I’m trying to make them stop gradually as they orbit around the center of the vortex using the Orbaz Stop Gradually operator, however it doesn’t seem to want to play ball with the Orbital Speed of the vortex. It’s either moving at the rate specified by the Orbital Speed, or stopped as it reaches the end of the operator’s testing phase.

Has anyone come across this before and has a solution?
If not, I’m going to need to think of a workaround, such as:

  • scripting the rotational movement (will Stop Gradually work with a scripted position operator in the same event?) using trigonometry.
  • keyframing non-particle objects to look like particles.

Any more ideas?

Thanks!
Dave

#2

i don’t know the actual solution, but if you would go for scripting, i wouldn’t do it trough all the trygonometriy.instead simply devide the velocity by a variable…should work aswell alsong the vortex still is on and before the scriptoperator. and this devider variable is a value that is frame depndent, and not fix.
so each frame rises by 0.1, and then the new particlevelocity/variable should change the magnitude of the vector.

tell me if it works for you :slight_smile:

#3

Interesting solution Capitan, good idea:)

Works fine here, you may not be giving the particles enough time to appear to be slowing down.

Attached a file explaining what I mean.

EDIT:Added a little better visual explanation.
Max2k8-32

#4

Hey Guys,
Thanks for chiming in, Johnny in pparticular for the file; yes - it does seem to work in your demonstration.

CaptainRed, yeah - I suspected that there might be a way to harness the velocity to do this after posting! I’m looking forward to getting my hands dirty with the scripting operator.

I’ve actually worked around it in the meantime by just animating the vortex to a stop, which the client is happy with, but I’ll check out your solutions over the weekend as I’m keen to improve my PFlow skills.

The client’s file is Max9 - I’ll check to see if this has something to do with it as well.

I’ll post back with results anyway!

Thanks so much again,
Cheers,
Dave

#5

Hey Johnny,
Actually, checking again, your file does the same as mine does. If you look at each particles’s velocity - it doesn’t actually slow to a stop at all. Sure, it stops at the end, but the easing is not actually apparent in its path.

Check the attached image, and you can also check with this script:

function arrayToSpline arr =
 	(
 	-- spline
 		local ss = SplineShape pos:arr[1]
 		addNewSpline ss
 		
 	-- knots
 		for i = 1 to arr.count do
 			(
 			addKnot ss 1 #corner #line arr[i]
 			)
 		updateShape ss
 		
 	-- return
 		ss
 	)
 
 
 function particleTrajectoryToArray pf pIndex =
 	(
 	local arr	= #()
 	for t = 0 to animationrange.end do
 		(
 		pf.updateParticles pf t
 		append arr (pf.getParticlePositionById pIndex)
 		)
 	arr
 	)
 
 arrayToSpline (particleTrajectoryToArray $ 20)

What do you think?

#6

Heh, cool script:)

The easing is there, but it is so miniscule. It seems to be porptional. LOL, I measured the distance between verts it does change just not how you might think it would.

Try only generating 20 particles and replacing the speed test with a spawn “Per Second” with inherited speed of “0.0”.

hehe Started looking pretty cool with it set to a rate of 200, emitt3e for 200 frames of the time line:)

Yeah maybe a scripted solution would be better. At least you would have more control over the deccelaration.

#7

Yeah… the easing is negligible. I’ll do some tests over the weekend and will report back.

Yeah - the script is pretty helpful! Try it on a mental particle system … very pretty!

#8

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.