# Edited: Evaluate point position on subframe level?

Hello,

Some beginner questions about emitting particles here, and some of the technical details are getting me a bit bogged down. I wondered if anyone could help and give some insight, or pick out errors in my approach?

Coming from an after effects background the type of effect i’m trying to achieve is when you emit a really high number of particles with no velocity from an emitter that is moving along a path. Once the particle count reaches a certain amount it creates a solid line or a streak. But i can’t seem to achieve this in touch. I think it has something to do with birth values, FPS and cook time’s. But the exact combination is eluding me.

As an example…

I have a single point spinning in a circular motion once per second at 25fps. From this point i am emitting particles.

If i birth 32 particles per second with a life of 1 sec each i get an even distribution of particles along a circular path. but only 25 visible points (32 particles in total but some of the particles are double stacked on top of each other)

My time inc is set to 1/\$FPS which equals 1 cook per frame, so at 25fps, i’m getting 25 cooks per second

ok, so i think this makes sense so far.

So i need to adjust the time_inc in order to get 32 cooks per second instead of 25 cooks per second.

So i take the value of 1 (second) and divide it by 32 to get a value of 0.0312…. I add this to the time inc parameter.

Visually things still look the same, still 25 even distributions (32 particles in total, some double stacked)

Very confused. Maybe i’m misunderstanding the time_inc property. But my best guess here is that the time inc value is just too small to be calculated fast enough.

I try increasing the project to 50fps and now i have 32 separate points. Great! (although they are no longer evenly distributed along the circular path - not sure why, my emitter is definitely doing one full rotation per second, and the particle life is 1 sec, so it should do a full circle of evenly distributed points)

anyway sticking to my main problem…i want to crank up the particles until so many are being emitted it forms a solid line along the circular path.

So i increase the particles up to 64 per second, i can see i have 64 particles in the inspector but only 50 of them are now visible (again some particles are double stacked)

So it appears the fps has to be higher than the amount of cooks per second. Not sure if this is correct. If my logic is correct (haha, probaly not) then getting a high number of particles in this setup would require a huge framerate.

At this point i’m hitting a dead end. I think i probaly need around 500 particles per second to create a solid line of particles to achieve my end goal. It seems like the relationship between the time_inc and the fps is key but i’m uncertain if i’m understanding it correctly.

I can get the particles to bunch up closer together by slowing down the circular motion, or i can increase the density by increasing the fps, but i need there to be 1 revolution per second, and there is a natural limit to possible fps.

This is the kind of technique i’ve been using in after effects and 3d software for years, would love to recreate a realtime equivalent. I looked at the trail SOP aswell but it isn’t a good fit for what i’m trying to achieve, as the line needs to be made of particles that can be effected with forces later down the line.

Is this achievable in touch designer? Am i using the right logic and methods? Is there a better approach to achieve what i’m after? Is there anything obvious i’m doing wrong?

Thanks, hope someone can help

Paul

After sleeping on this i realise i might be thinking about the problem backwards.

After testing with some basic particle setups it’s clear that i can get particles out fast enough to form a solid line. So maybe it’s my emitter point which is causing the trouble.

I’m guessing that the position of the emitter that is travelling in the circular path is only being evaluated once every frame, so regardless of the amount of particles this becomes the limiting factor for where particles can appear.

Am i on the right track here?

Is there a way to force the position of the point emitter to be evaluated more frequently? Or am i in the territory some kind of scripted solution?

Thanks,

Paul

Hm Interesting problem.
Can you replace your emitter point with an emitter line the length of which equals the distance the point travels in one frame?

That might be an interim solution i’ll give it a go, i wonder what will happen to various particle attributes that change over life like colour and scale in this situation. If it takes say 20 particles to cover the distance the point travels in 1 frame I guess they would change in blocks of 20 particles, so smooth changes might be out of the picture. Hmmm, will give it a try…

sorry lots of questions!

So am i right in my assumption that the position for all geometry is only calculated one per frame?

If the points were say generated through a script and passed into the particle SOP and therefore skipping the use of geometry as the emitter point do you think it would avoid this issue? Would a script op for example be evaluated per cook rather than per frame?

Thanks,

Paul

As well, you can check your thought about the emitter moving per frame by pausing the timeline and moving forward frame by frame to watch the emitter’s path.

Example project would help greatly though.

Hey Elburz,

Thanks for taking a look. Attached is a really simple patch that shows the problem.

a single point is moving along the x axis over 1 second, from this i’m emitting particles. Wether i emit 60 particles or 600 it makes no difference to the visual distribution.

Cheers,

Paul
particle test.1.toe (3.94 KB)

Script SOPs are only evaluated once per frame as well.
You might consider cranking up your global time frame to something high, and using local time components to bring it back down to 30 for the bulk of your remaining networks.
The Particle SOP network would then cook at the higher (global) frame rate.

Is this what you want, more or less?
particle test.1.toe (3.65 KB)

Thanks Elburz,

your example works great for a fixed path, where I’m trying to go with this is to have the emitter move around dynamically based on some chops, or maybe audio, or mouse input even. So i need to be emitting from a single point that is moving around.

Thanks for the suggestion Rob, i’ll have a play around with that today and see if it helps.

Best,

Paul

One way to get lots of points to emit from:

Create a Constant CHOP set to, say 240 samples per second. Feed that to a Filter CHOP set to .1 second to smooth it out. Then send that to the Particle SOP.

You can send the Filter CHOP to a Trail CHOP to get a recent time-history of points to emit from.

Or try a Mouse CHOP sent to a Resample CHOP set to 240 samples per second, then to the Filter CHOP and so on. (The Resample CHOP should do linear interpolation (not at this time), but it will be able to in an upcoming build.)

Rob:

I tried your suggestion but it seems my whole network needs to run at a high frame rate to get the right result, the chops drive the position of the particle emitter, so if that part of the network runs at 60fps, while the global fps is say 320, the emitter is evaluating it’s position 60 times per second and I get the same visible result, if I run the chops at the global frame rate and the geo/particles at 60 I’m getting enough position data but the particles are only rendering every 60fps so I appear to get the same result again.

Appreciate the input though, am learning a lot about time in touchdesigner atm.

Greg,

That’s really insightful! thanks. Had completely overlooked the idea of CHOP samples as a subframe calculation, am having a play with this now. Really helpful:)

Paul

I’m wondering how you went with this Paul, or Greg could you please post an example?

Never completely solved this as i became really busy with other projects but in theory i realised (after all the advise in this thread) i had to calculate the subframe positions myself and emit from multiple points per frame.

I think if you generate a line segment that connects the emitter position on the current frame, to it’s position on the previous frame, then resample that line to get say 10 points in total - you can emit from those 10 points on every frame and have yourself a x10 linear interpolation method for approximating subframes.

I’m still trying to work out how to do a bezier interpolation. I have a line segment with 3 points sampling the position on current frame, 1 frame ago and 2 frames ago and i’m running some smoothing on those to get a curve but it’s not perfect.

Paul