tyflow wizards.. constant velocity along a spline?

[super gnu]

im trying to illustrate a data-link, using packets travelling along two splines. one "uplink" and the other "downlink"

i need the packets to travel at a constant velocity.

frustratingly the path-follow has no combination of settings which allows constant speed (that i can see)

adding a "speed" operator allows setting of specific speed, but then i have some strange behaviour.

if i change the length of the splines, the particles/packets bunch up or spread apart.

they are being emitted at a fixed rate-per-second, and have a fixed speed assigned, so surely their spacing should stay constant irrespective of the spline length?


its bugging me because as far as i understand it, my setup -should- work



i actually get more "correct" behaviour, disabling the speed operator and allowing the path-follow to accelerate the packets.... in this case, making the spline longer means more particles along the spline,and their spacing remains constant.. however the "accelerating" movement is not suitable for this project.


my ideal is a robust setup which will send packets, at a constant speed, evenly spaced, aligned along the path, on any path.. straight or bendy, animated length, shape, or angle..however this throws up loads of issues with particle orientation and speed changes, as spline is animated changing, and goes beyond my skills in tyflow.

-and yes, i did consider path-deform on a string of geometry "packets" , but its ungodly slow and some of the links will need to be very long... i was getting some huge filesizes and max was getting very flaky.



In the end id be happy with something that works on non-vertex animated straight splines of arbitrary length at least. (i need lots of scenes where splines are short/long, inbetween, and the look must be consistent.. The only essential is these "datalinks" must be capable of being linked to moving objects, and the packets remain on the line perfectly) .

ive attached a file with my setup... there are two splines, and some small spheres linked to the ends.

if you grab the yellow or purple spheres and move them, they will modify both splines, and you will see the packets bunching up or spacing apart.. this is the undesired behaviour.

tyflow dataline.rar

[fixeighted]

It is possible that adding a particle physics operator might do it, although I'm only just now looking at it and though it seems to work like a 'keep apart' fucntion I can't be sure it'll suffice.
Give it a go.


EDIT: indeed it does appear to work, if I understand the issue correctly. It's a bit slow on my machine but it keeps the packets separated as far as I can see

[super gnu]

It is possible that adding a particle physics operator might do it, although I'm only just now looking at it and though it seems to work like a 'keep apart' fucntion I can't be sure it'll suffice.
Give it a go

cool. the wierd thing is, without the speed operator, it works, the particles stay the same distance apart as the spline length changes.. but i dont have constant speed, since the path follow only has velocity and acceleration controls. (id also have assumed that setting acceleration to 100% and then setting a target velocity id be able to accelerate the particles to the given velocity in a single step/frame.. however whatever acceleration/velocity is chosen, they still ramp gradually up to speed. )



also, if i remove the path follow operator, and use something like "surface force" to set the initial velocity/direction, then the speed operator works as expected.

seems like a bug to me, but im not expert enough to rule out some tickbox i missed. id hope that it would not be necessary to bring particle dynamics into play to do something so simple.

[fixeighted]

To be honest I have barely looked a Tyflow at all and so know almost nothing about it...it was just a problem solving hunch I had.
I just used default settings, dropped the operator in randomly below the path follow, got it to display a graphic of influence and randomly set the radius to 4m in this case.
Maybe there is another way and someone else knows the plugin better but if it works for you then all good :~)

[fixeighted]

Actually it still has issues...like a pulsing effect, so something not quite right.

Could you not do this without using particles?
So e.g. create a string of cylinders of varying lengths then attach them all into one piece and then path deform it, booleanning it off at wherever it needs ?

[super gnu]

Actually it still has issues...like a pulsing effect, so something not quite right.

Could you not do this without using particles?
So e.g. create a string of cylinders of varying lengths then attach them all into one piece and then path deform it, booleanning it off at wherever it needs ?

yeah that was my first attempt, but it gets very laggy trying to do the loong connections i need ( some of them disappearing off to a point basically, from a satellite down to earth) ... boolean/vol select to delete the ones above and below the ends makes it even more chuggy... - (can use distance tex to make unwanted ones invisible in-render too) the scenes are already pretty heavy so im looking for a lighter weight solution.

there is also the fact that i need to animate variations of uplink/downlink speed/ packet density to match shot/voiceover.. hard to do with path deform!

in any case, i decided that since ill likely also need to scale this whole rig up and down too , to fit various scenes, its gonna be best to have a setup like i have, but keep it seperate, and use it to render out animated textures and map them to planes facing the cam in the final scenes. adds an extra step, but keeps master scenes light. in that case i can just set this setup as long as i might need it, then render sections of it , at a length to fit whatever shot im doing. still like to know why its not doing as expected, but ill live with it

[fixeighted]

Ah ok, well whatever works best and is as you say more scaleable is likely going to be simpler, once the glitches are hopefully ironed out.
I'm sure someone will come along who knows where that 'fix it' checkbox is

[super gnu]

Just to note, the wonderful Tyson showed me what the issue was. To get predictable motion along a spline when you have the particles "locked" to the spline, you need to increase the "spline interpolation" in the path-follow operator very high. the default of 500 is fine for short splines, but the longer they are, the higher the number needs to be, otherwise the particles jump around or stick at the beginning, especially if they are moving slowly.

turning it up to 50,000 fixed all the odd behaviour, at the cost of slower sim times. i might be able to go lower, depends on the final spline length i need.

[fixeighted]

Hehe, well bizarrely that was initially going to be my very first suggestion, or rather to do a normalise spline and then increase the knots.
I forgot about it as Isubsequently opened the scene and got lost with other methods

Glad it got sorted in any case

[super gnu]

Hehe, well bizarrely that was initially going to be my very first suggestion, or rather to do a normalise spline and then increase the knots.
I forgot about it as Isubsequently opened the scene and got lost with other methods

Glad it got sorted in any case

yeah as tyson explained, tyflow has its own internal spline interpolation, independent of the interpolation of the spline object.. its this internal setting that needs cranking.

[fixeighted]

Aah, I see - it makes more sense actually. He is a clever dude that Tyson....and also luckily very helpfully present to bail people out