I need to freeze a sprite system...

[rusty]

Hi,

 

It's me again. I need to freeze a sprite system so a camera can move though it. Searching I found:

 

"Set initial velocity to zero."

 

Hmm... seems to me like in the chor you'd let the sprite system form then at some frame you'd 'set the initial velocity to zero' and maybe 'rate of emission' and 'spin' and ???? as well but this isn't working for me. Of course if I set these values in the material section... nothing happens in the chor (as one would suspect). However, sprite systems are tricky devils and I haven't played with them for many years.

 

Is there a way to do it? And pretend I'm a complete idiot and assume I know nothing (I need where, how, when and why). Are there any tutorials on this?

 

I've attached the prototype I'm working with: a zip with the project and the image (which may need relinking in the project).

3D_Universe.zip

 

Thanks for any help!

Rusty

[Fuchur]

Hi,

 

It's me again. I need to freeze a sprite system so a camera can move though it. Searching I found:

 

"Set initial velocity to zero."

 

Hmm... seems to me like in the chor you'd let the sprite system form then at some frame you'd 'set the initial velocity to zero' and maybe 'rate of emission' and 'spin' and ???? as well but this isn't working for me. Of course if I set these values in the material section... nothing happens in the chor (as one would suspect). However, sprite systems are tricky devils and I haven't played with them for many years.

 

Is there a way to do it? And pretend I'm a complete idiot and assume I know nothing (I need where, how, when and why). Are there any tutorials on this?

 

I've attached the prototype I'm working with: a zip with the project and the image (which may need relinking in the project).

3D_Universe.zip

 

Thanks for any help!

Rusty

 

I am quite sure that "Set initial velocity to zero" cant work.

Each particle gets some sort of property when it is created. If you change the initial properties, these will only effect new particles which are created, but the old once still remain in there state they were fired with.

In general this is a good behaviour.... otherwise you could not make a nice transition, etc. But you dont want a transition... so this will very likely not work, but only hold the new once back from getting up at all.

What you would need would be a lifetime-based velocity-value. I dont think there is one...

 

It could however work with forces. If you set a force up and one downwards and the one poiniting down is set to 0, while the other one is set to 100 it should go up. Then you can activate the one pointing down (same power) and the particles should sooner or later come to an hold. But I doubt that they stop spinning around. (keep in mind too, that a force is an acceleration, that means: They will not stop immidelty if you slow them down from the other direction by just setting the same force-power.

 

I'll test a little with the second solution to see if this can help.

*Fuchur*

[Fuchur]

Hi,

 

It's me again. I need to freeze a sprite system so a camera can move though it. Searching I found:

 

"Set initial velocity to zero."

 

Hmm... seems to me like in the chor you'd let the sprite system form then at some frame you'd 'set the initial velocity to zero' and maybe 'rate of emission' and 'spin' and ???? as well but this isn't working for me. Of course if I set these values in the material section... nothing happens in the chor (as one would suspect). However, sprite systems are tricky devils and I haven't played with them for many years.

 

Is there a way to do it? And pretend I'm a complete idiot and assume I know nothing (I need where, how, when and why). Are there any tutorials on this?

 

I've attached the prototype I'm working with: a zip with the project and the image (which may need relinking in the project).

3D_Universe.zip

 

Thanks for any help!

Rusty

 

I am quite sure that "Set initial velocity to zero" cant work.

Each particle gets some sort of property when it is created. If you change the initial properties, these will only effect new particles which are created, but the old once still remain in there state they were fired with.

In general this is a good behaviour.... otherwise you could not make a nice transition, etc. But you dont want a transition... so this will very likely not work, but only hold the new once back from getting up at all.

What you would need would be a lifetime-based velocity-value. I dont think there is one...

 

It could however work with forces. If you set a force up and one downwards and the one poiniting down is set to 0, while the other one is set to 100 it should go up. Then you can activate the one pointing down (same power) and the particles should sooner or later come to an hold. But I doubt that they stop spinning around. (keep in mind too, that a force is an acceleration, that means: They will not stop immidelty if you slow them down from the other direction by just setting the same force-power.

 

I'll test a little with the second solution to see if this can help.

*Fuchur*

 

 

Just tried it... it is too tricky to get the right settings with that. The other possibility I tried was to use Gravitional Force and set it too -100% after a certain time. (for the same time) but this is not working neighter.

What exatly is it, what you are trying to do?

- If you only need a static "cloud"-like particle-cloud you can just set the initial velocity and all the forces to 0 and move the emitter around like you need it.

- If you need it to develope, but your camera is static, you can use a post-program to just stop the clouds at a specific frame (keep the last frame after the animation).

- If you need it in A:M (3d-space) you can render the sequence out and use several layers to simulate a 3d-behaviour.

 

...etc.

 

It highly depends on what you are after.

 

See you

*Fuchur*

[robcat2075]

Set velocity to will only work if you want the sprite to remain at its place of origin. I did that for these clouds:

 

http://www.hash.com/forums/index.php?showt...5&hl=clouds

 

 

One way to "freeze" sprites that have been swirling around might be to temporarily render at much higher fps. If you want the sprites to freeze at 4:00, render at a normal fps up to 3:23, then in a new render set the fps to some high rate like 240 and arrange your camera move to happen in the next half second (120 frames). Render all this to an image sequence and play it at the normal 24 fps and the high speed section will be slowed down to appear time has stopped.

[robcat2075]

I've been testing out the high fps idea and I haven't been able to get the different fps sections to match without the jump in the particle system at the change over. Baking it hasn't helped yet either.

[largento]

Can your shot be done like bullet-time?

 

Set up a fleet of cameras (one for each frame) in the path you want to move through the particles and have them all render the same frame. Then compile those frames in order.

 

You could use a moving camera, to figure out the position of each frame's camera.

 

Admittedly, not as easy as changing a setting, but if it's a really short shot...

[robcat2075]

Baking particles at high frame rates has turned out to behave very oddly.

 

Sidestepping that problem...

 

with the PRJ set to 24 fps I made a camera move that went from 02:00 to 04:00 then squished that down to fit in 02:00 to 02:03

 

I set the PRJ to 480 fps and rendered from 00:00 to 04:00. That's 1920 frames

 

I took the image sequence into AfterEffects as 24 fps footage and used Time Remapping to speed up the part that wasn't supposed to be slow

 

FreezeH450.mov

 

Using "Step" to avoid rendering frames i didn't need didn't work, i got jumps in the particle system where the time change happens.

 

It's possible that further R&D with baking step might solve the need to render all the frames.

 

But it can be done in a fashion, at least.

[robcat2075]

I looked at your universe PRJ. you just need a cloud of those particles to hang motionless?

 

Set the velocity to zero and move the emitter to leave a trail of stationary particles behind it, then move your camera through it. No time tricks needed.

[robcat2075]

Just going back to the highspeed fps idea... here's 80 frames of footage shot in your original PRJ at 960fps and slowed down to 24 fps

 

UniverseH900.mov

[rusty]

THE PEOPLE ON THE AM FORUM (YOU) ARE TOTALLY AWESOME! LOOK AT ALL THE EFFORT AND TIME FREELY GIVEN. l am in bed using my wifes new Nook Tablet (amothers day gift) which is new and still awkward--can not view mov , bummer. When pain pills hit l will go to my deskutop to see them and respond properly!

 

R

[rusty]

Very awesome stuff!! I see three different ways to go... probably rendering at high speed will be the ticket... if I can piece together what robcat did in universeH900.mov this will work. After that I just need to ace the effect (going from galaxy clusters to super clusters to... well see below image).

 

Thanks so much!!

Rusty

 

(view of 3D universe)

[johnl3d]

at work so cannot see quicktime but did this with an explosion

 

http://www.hash.com/forums/index.php?showt...mp;hl=explosion

[rusty]

at work so cannot see quicktime but did this with an explosion

 

http://www.hash.com/forums/index.php?showt...mp;hl=explosion

 

That's pretty cool!

 

r

[rusty]

Just going back to the highspeed fps idea... here's 80 frames of footage shot in your original PRJ at 960fps and slowed down to 24 fps

 

UniverseH900.mov

 

robcat:

 

So what you did here is to bump the frame rate to 960fps then animate a camera moving through the sprite system in say a 100 frames (far less then a second), render then take the output (say tga files) and process them at 24fps... is this the idea?

 

Thanks,

Rusty

[robcat2075]

robcat:

 

So what you did here is to bump the frame rate to 960fps then animate a camera moving through the sprite system in say a 100 frames (far less then a second), render then take the output (say tga files) and process them at 24fps... is this the idea?

 

Yes. However, to make keyframing the camera easier, I first animated it to move over a several second span, then squeezed the keyframes down to a fraction of a second.

 

Tip: when ever you squeeze or stretch keyframes, go into the curve editor, select them all at once, then use the cursor keys to nudge them up once and back down. Sometimes the spline magnitude thru the CPs doesn't immediately scale with the squeeze and this will remind it to do so.