[Naveen Chawla]

Yeah, well, I haven’t researched it thoroughly, but I know that the BBC says the active screen area in widescreen is actually 702 x 576, and not 720 x 576, even though the material is actually 720 x 576, so 18 pixels of the original material is “chopped off” on the TV. So, according to them, your original material needs to be 1050 x 576 before converting to 720 x 576, with 26 pixels of the 1050 being “chopped off” when it goes to the TV. Their calculations are on this site https://www.bbc.co.uk/commissioning/tvbranding/picturesize.shtml

[Naveen Chawla]

Alan, perhaps my question got lost in the big posts. Are you able to tell me the mathematical relationship of the number % property versus actual rate, which I have found not to be linear. Or if you want to save time, to copy and paste the code and I’ll (try to) decipher it?

[Naveen Chawla]

That last result was for point emitters. Ok so here are my results (new number calculation), at number 1%, and they apply for all project frame rates. The values that I was pursuing in my post before last, concluded from the results, are shown in brackets:

Point: 1 particle per number unit every 65 seconds exactly, at any frame rate (therefore value I wanted: 1/65)

Area: 1 particle per number unit every 21.5 seconds exactly per 100 x 100 pixels, at any frame rate (therefore value I wanted: 1/21.5/10000)

Ellipse (“Emit at points”): 1 rotation of the emission point per number unit every 65 seconds exactly, at any frame rate (therefore value I wanted: 1/65)

Circle (“Emit at points”): 1 rotation of the emission point per number unit every 65 seconds exactly, at any frame rate (therefore value I wanted: 1/65)

Line (“Emit at points”): 1 run along the line per number unit every 65 seconds exactly, at any frame rate (therefore value I wanted: 1/65)

Now all I need from you is the mathematical relationship for the number % value, which I have found not to be linear.

[Naveen Chawla]

Ok I’ve found that the number % is not linear, but the number value is, and that the “new” number calculation is simply more accurate than the “old” one. Also, at 1%, at value 1, it is 65 seconds exactly for one particle, at any project frame rate, therefore “1/65 particles” per second per number value at 1%. Does this sound right? I’ll post more info as I find it. Can I please know the mathematical relationship for the number % value?

[Naveen Chawla]

I’ve found, am I right, that the project frame rate does not affect the actual time in seconds between particle creation, or the rate per second of movement of the emission point when using “Emit at points”. Is this correct? Can I ask what the “old number calculation” is? Do both calculations have a linear relationship with respect to time in all cases in terms of both number % and number value? If so I can do the tests myself. But if not (my preliminary tests in the preview stage window suggest not in some cases), it seems too daunting for me to figure out the mathematical relationship! I would need the actual calculations (I can read copy-and-pasted C++ if the variables have understandable names) for point,area,ellipse and line, so I can figure out the exact times I’m getting in each case.
But surely if one of the methods is linear, you would have some constant values you’re using (I’ve found that changing the project frame rate does not affect the actual time between particle creation, right? And I’m not using any number variation)? If so, the specific values I am pursuing, which would be constant throughout your program, but not necessarily explicitly defined:

Point: number of particles per second per number % per number value (e.g. 0.0005)

Area: number of particles per second per number % per number value per pixel (e.g. 0.000000000001)

Ellipse/Circle: number of rotations per second of the emission point around the ellipse/circle when using “Emit at points” per number % per number value (e.g. 0.00000002)

Line: number of repetitions of the emission point moving along the line when using “Emit at points” per number % per number value (e.g. 0.00000002)

Thanks so much,
Regards,
Naveen Chawla

[Naveen Chawla]

Hi Ann there’s 3 ways depending on the type of effect you want. The “visibility” property allows you to fade out and fade in the emitter whenever you want it to. The “active” property (active/inactive) causes the emitter to disappear completely when you make it inactive, and it starts emitting from the beginning again when you make it active again. The “number” property allows you to animate the rate of particle emission, so you can make it zero when you want the emitter to disappear, but it does not disappear immediately like in the “active” property: the remaining particles which have already begun their life continue until their life is done, in this case. You would use whichever of the 3 ways gives you the effect you want at the time.

[Naveen Chawla]

Sorry, I must add that I also need to know the time elapsed between each particle emission per “number” unit “per pixel” for area emitters too, since I need to synchronise area emitters also.

Thank you so much,
Naveen

[Naveen Chawla]

Brilliant!! Thanks!!

[Naveen Chawla]

Alan thanks so much for your post.
May I suggest this for the next particleIllusion coming out, so that you can dynamically animate the points of a line separately, for a small dialog box to come up when you right-click ‘Record Position’ which has two radio buttons ‘Just this point’ and ‘Entire line’, with an ‘OK’ button, which then does the appropriate action.

Can I also second another poster’s call for the ability to produce curved lines for emitters, by interpolating a curve between multiple points, like the last example on https://www.ibiblio.org/e-notes/Splines/Bint.htm, while also allowing those points to be animated seperately by ‘record position’.