8 replies to this topic

[c1p0]

Hello There!

This is my first topic on mograph.net, so please be patient, and tell me if somethings wrong with this. Lately I've been talking to Chris on the CS-Tools topic about subframe emission, and I couldn't stop until i found a solution. This one is pretty fast and simple, and not using the velocity trick at all. I hope you'll learn something new from this.

The technique helps you to understand the power of xpresso, which is nowadays got into the background because of python, which is of course far more powerful, but xpresso is underrated right now. I think i'm alone with this thinking, but adapting python functions as xpresso nodes would be great. Visual programming is the way programming should go (at least for designers). But to get on topic:

What is happening here, is that xpresso is based on frames, so it is being calculated every frame at once(every frame the nodes are triggered). But nodes can be triggered with inputs as well, so this technique takes advantage of this fact. Based on the current and the last position, a number of positions will be generated, and being inputted (sorry for making up words) to the pstorm node, which will eventually run, and emit the particles, creating a fluid particle emission.

I also show some pyrocluster optimization, but i'll make it a little more deep of you seem to care about this tutorial at all



Best of wished to everyone here, and please don't be lazy, push some buttons on the keyboard and tell me your thoughts. I know I'm new here, but I really like this community. Found some very helpful/nice friends and coworkers here!

Balazs Kerek

[Srek]

Hi Balazs,
using the difference between the previous and the current position of the Null is the same as using the veloctiy. The only difference is that the velocity you calculate is in units/frame while the velocity value is in units/second.
Cheers
Björn

Edited by Srek, 05 January 2012 - 02:59 PM.

[douwe]

Balazs,

I'm not really familiar with the "Previous" Ports,
although it seems you can use them like a Memory Node with a History Level of 1.

I understand that "calculating the difference between previous position and actual position"
gives you a number of "sub" positions, and that the PStorm Node gets updated for each "sub" event,
so you have a fixed and controllable set of updates per frame, or "subframes", right ?

That is an interesting insight that might have a few good uses.

What you're doing with it in the video seems to be a nice addititon to the Position Velocity trick as explained by Tim Clapham ( http://www.helloluxx...king-particles/).

I'm not sure how new this insight actually is, i remember reading srek about this on some forum that i can't seem to isolate from the google index, but it's definitely some nice exploration.

I also like the "Particular feel" you're working on there.

cheers barátom,
Keep up the great research.
douwe

EDIT : ahh, i see bjorn already replied. Balazs, can you do some comparisons between the 2 ?
EDIT 2 : i also found that related post on http://www.postforum...i=90352&t=90317

the position velocity output will give you a vector that represents the movement of the object from the last frame to the current in units/second. A position velocity of (100/-200/300) would be a movement of +100 units on the x-axis, -200 on y-axis and +300 units on z-axis within one second. To calculate the frame to frame speed you have to devide this by the FPS setting you can get from the time node.
Same goes for rotation velocity using radians.

If you want the velocity based on a specific frame base you can use the previous positon/rotation node. History depht has to be set to a greater value then history level to store information on the set number of frames.
By calculating the difference between position and previous position you get the velocity with the set frame number (history level) as base.

Hope this helps
Srek

Edited by douwe, 05 January 2012 - 03:24 PM.

[c1p0]

Hi Balazs,
using the difference between the previous and the current position of the Null is the same as using the veloctiy. The only difference is that the velocity you calculate is in units/frame while the velocity value is in units/second.
Cheers
Björn

Hm. Interesting. I'm going to try out if i can achieve the same results. Basically this technique shows how you can make a lot of points between the previous and the current, and the velocity trick won't make any new particles. Thanks for the feedback, from you it's an honor

[Srek]

A realy interesting approach would be to extrapolate several previous positions to get a curved instead of linear distribution of positions.
Anyone up to the task? it's a bit beyond my math skills.
Cheers
Björn

[ChrisC]

What is happening here, is that xpresso is based on frames, so it is being calculated every frame at once(every frame the nodes are triggered). But nodes can be triggered with inputs as well, so this technique takes advantage of this fact.

This is very nice - I didn't know we could trigger nodes by firing multiple inputs, or maybe I did know it but didn't see the potential... either way - nice technique, definitely good enough to get past the 'puffy space rocket' problem we all know so well...

[c1p0]

A realy interesting approach would be to extrapolate several previous positions to get a curved instead of linear distribution of positions.
Anyone up to the task? it's a bit beyond my math skills.
Cheers
Björn

I was thinking about the same thing, for null objects it can be done, but using a tracer to catch the motion and then emitting from the spline seems easier (since you'll have indexable points instead of frame based calculation.)



I am trying to use the memory node with particles. Here's a simple scene with a very interesting problem:
Scene File

I'm using a ppass node, and i'm connecting it to a memory node (tp particle mode). I'm getting the data from both of the tp particle outputs. When i'm using the memory node to simply pass through the particles, the same particles are being created, (as you can see on the video).

When i switch the memory node to output a previous state, the same particles are born again, bot the one from the memory node will place all particles to the same position. (this means that the pstorm node runs the same, but always get the first particles info only.)

What i'm doing wrong?

Balazs

[douwe]

I never used the Memory Node all that much, so I may be mistaken, but I'm almost sure you can't use it to store information about multiple Objects simultaneously.
I'm afraid you need to come up with another way to store the values.

Maybe Michael's tp+python walkthrough will put you in a useful direction.
He uses custom Data Channels and python to store velocity values for individual Particles, for later use.

[tezuka]

Not sure if this was mentioned already, but the cheapest trick to get rid of the "puffy space rocket" problem is to use the Distance and
Distance Variation Parameters inside the PStorm Node. With a high velocity value no one will see if the particles are emitted
exactly from the Emitters position or a little bit in front of it.

[c1p0]

Not sure if this was mentioned already, but the cheapest trick to get rid of the "puffy space rocket" problem is to use the Distance and
Distance Variation Parameters inside the PStorm Node. With a high velocity value no one will see if the particles are emitted
exactly from the Emitters position or a little bit in front of it.

I created a little xpresso script for subframe emission using thinking particles and custom data channels , i'll send it to you this weekend Of course this is still a linear calculation, the real solution would be to convert the previous positions to spline points, subdivide them, and get the point values from the subdivisions. Sounds like a complicated python script :S