How to make particles emit attached an object

[Pete]

Hi there,
I would like to emit a bunch of particles from an object (at frame 01) and have them be stuck to the object that they came from. I'm attempting to make a bit of a feather setup. so I want to get a bunch of instance 'feather' geometry to be attached to the mesh. I know there's a 'stick to surface' node but that seems to work more if the particle has colided with another surface.
Thanks
Pete

[ThE_JacO]

if you use total amount instead of particles per second or per frame, and give them velocity 0, they will basically be N samples of the surface stuck to it.
You can then wrap them on the mesh or set their position to their emit location's pointposition to make them follow the mesh.

[ximage]

Hey Pete

I'v been trying to do some sort of feather system with ice too. i was gonna start a thread and try and get a few peoples input, see what features people would want and if i had the knowledge to do it.

with mine i have just used the Add point node, with a unsimulated ice tree and they stick to the area you specify. polygons or points or whatever.

il post something later to show ya.

cheers

Ximage

[Pete]

Yeah, well I guess I was thinking of eventually being able to control the size and density of feathers by wieghtmaps and probably their angles by a tangency map or something...

Thanks Jaco, they are now sticking to the surface but their orientation doesn't seem to follow the object as it moves. If I plug the normal into the direction it does't seem to have an effect. I'm guessing it's because it isn't calculated every frame, but if I plug a set oriantation node in to the ICE tree, I'm not sure how to plug an objects normal into the set orientation node...

http://www.peterleary.net/forumfiles/2008-08-20_110815.gif

[ThE_JacO]

Orientation requires a transform, not just a single vector like a normal. You could build one out of the normal, but it would be superfluous.
You should have nodes to align particles by several parameters though, one of which is by the emit location's normal.
Said that, you should also be able to do it with a toggle par somewhere in the default emit node if you use that.

[Pete]

Yes you could align to surface as an option in the emit node, but as the emit object rotates the particles keep the same world space rotation and don't follow the object.

[ThE_JacO]

I'm not sure that's by design... although it might be lazy eval at work.
What happens if you deform the object? like rotating the points instead of the object.
If that works it's an evaluation issue because the ice op is only called by activeprimitive changes, and you might be able to make it work by pulling the emitter's kine global into the graph, and use it to set a custom attribute (to make sure it's pulled but doesn't have any effects beside forcing evaluation on a transform).

[CiaranM]

Yes you could align to surface as an option in the emit node, but as the emit object rotates the particles keep the same world space rotation and don't follow the object.
If I understand your problem correctly...
You need to use an 'align particle to surface' or more suitably for your situation an 'align to emit location' node. Plug this into an execution port so that the orientation is updated each simulation step.
This should take account of transforms and mesh deformations.

http://www.blackredking.org/Images/Junk/emitAlignToSurface.jpg

[Pete]

Sweet, that works! Thankyou

[ThE_JacO]

I'm not sure that's by design... although it might be lazy eval at work.
What happens if you deform the object? like rotating the points instead of the object.
If that works it's an evaluation issue because the ice op is only called by activeprimitive changes, and you might be able to make it work by pulling the emitter's kine global into the graph, and use it to set a custom attribute (to make sure it's pulled but doesn't have any effects beside forcing evaluation on a transform).

for some reason I was assuming you weren't using a simulated ice tree...
nvm, just align to emit location like Ciaran said.

[CiaranM]

To be fair, it would be a better solution if it weren't reliant on playback.

[Pete]

Ah yes, I kept it simulated because I was hoping to do some other things to it down the track with state changes etc. Thanks for the help :)

I have this other thing I am having a little trouble with now though, I wanted to shake the particles off the emitter. So I tried to do a test particle velocity on them as the emitter is moving but it doesn't seem to work. Would this be because the particles themselves don't think they are moving through the scene because they are locked to the object?

Sorry for hassling you guys so much but i seem to be having trouble with everything I try here, there's a bit of a curve with this ICE stuff, I hope the bring out some good tutes soon.

[CiaranM]

Would this be because the particles themselves don't think they are moving through the scene because they are locked to the object?

Could be. Try calculating the velocity manually and test that. You've got all the nodes there to make a close approximation (pointPosition, Get Data at Previous Frame, Simulation Step i.e. v=dx/dt)

I'm in the same boat as yourself, just learning my way around. I've found it hardest to have to re-learn how to do things that would be simple to code, but require a different approach with this visual programming lark (arrays, mostly!). Wish I had more time for this stuff...
Good luck!

[ThE_JacO]

I have this other thing I am having a little trouble with now though, I wanted to shake the particles off the emitter. So I tried to do a test particle velocity on them as the emitter is moving but it doesn't seem to work. Would this be because the particles themselves don't think they are moving through the scene because they are locked to the object?

In ICE you have visual debugging of different types, read about it and start using it for things like this, so you can display what the velocity is.
As for the problem, if they are stuck to the emitter moving the particles themselves don't have any velocity.
You can still work out the speed of their emission point, since from what I understand of what you want to do that would be what you actually need.
Just get emit location > point position at the current frame (normally) and at the frame before (with get data at previous frame). Subtract the previous frame from the current frame, and you have the velocity at the previous frame, get the length of that vector and you have the speed, a single scalar that's convenient for comparisons to make the particles do something else.

[ximage]

The way i have been doing it for my feather system attempt, is the way in the attachement.

with a non simulated ice tree i just used the add point node instead of the emit compounds. one makes points per poly and another per point position. i did it this was as i have to have seperate align to surface compounds for each as i have to change the way it works inside from surface to per knot or vertex for the feathers emitted per point. if this is not done the ones on the points start to flip out and go wild.

but yeh this doest stick the points if you just move you object, they only stick if the point are manipulated, like with an envelope.

il try and start a thread about the compound im making for the feather system, see if we can get a community effort on it to make its awesome, as i am still learning. at the moment i have got:

- the scale to modulate by a weight map
- randomize scale
- randomize rotation with rotation limits
- use rotation from controller to make a local area react with a fall off (need to find out how to do multiple controllers)


things that I would like to put in it:

- wind simulation
- multiple control inputs
- feathers to be able to drop out by weight map controls
- control size by contollers with local falloff
- multiple feathers distributed either by random or by a weight map


hope you dont feel i ahve high jacked the thread pete but i though if people are gonna do feather systems why not learn from each other.

:)

Ximage

[Pete]

ximage, thankyou, this is great! Looks like your work is coming along pretty well.
and JaCo, I'll definitely check out those debugging tools (i forgot about them actually) Thanks.
So does using an unsimulated ice tree enable it to update a little better?

[ThE_JacO]

simulated and not are very different things.
Simulated ICE trees calculate things based on the previous frame, so things like accumulation and updating values are possible, but the power of the system also relies on an initial state, which means at the first simulated frame the stack below gets ignored, the sim env takes over from there, and the evolution over time is entirely dictated by the ice tree.
Not simulated trees cannot do things like accumulation etc because every frame they evaluate inputs, not what happened to the values the frame before, but on the other hand they are interactive and can fit anywhere in the stack without ignoring it, but working in tandem with the rest of it.

[T.I.M.]

but yeh this doest stick the points if you just move you object, they only stick if the point are manipulated, like with an envelope.


You can simply take the global position of the object and use "add" node to add it with point or poly position.If you want to have position and rotation , you can enable the Kinematics in ICE and set pos and rotations in separate port.

[ThE_JacO]

but yeh this doest stick the points if you just move you object, they only stick if the point are manipulated, like with an envelope.
There is a good chance that is the case because the op is on the activeprimitive, and only the AP getting dirtied will trigger a pull. Kine might not trigger it.
Read me a few posts above, this part might help:

you might be able to make it work by pulling the emitter's kine global into the graph, and use it to set a custom attribute (to make sure it's pulled but doesn't have any effects beside forcing evaluation on a transform).

That way you don't need to enable or use any untested features.