Is there a way to parent a particle object to another object so the particles follow the parented object while animating? Becuase i have a jet that i have made and i want the particles to follow the jet while i animate it, but for some reason when i parent the particles i can’t move the object. Any ideas or suggestions are welcome.
nope, particles can’t be moved with something
people have compensated by moving the remainder of the scene in the opposite direction… but this only works with a single particle system.
AH dangit, alright well thanx.
huh, maybe I misunderstand the problem, but when I parent an particles emitting object to another I have no problem with moving them, neither when parenting the object to the particle emitter (and in both cases even the particles move together with the objects).
so it should be no problem to parent the emitter of a jet to its drive, too…
EDIT 2006-04-05: NOW I understood your problem. it comes up while trying to animate the parent/child-combination.
okay, but you can do the following:
JOIN (Ctrl-J) the EmitterObject to the rest of the jet’s body and make these Emitters Vertices a VertexGroup (named e.g. Emit or so). Now you make the whole jet an emitter, but you tell the particles only to be emitted from the VertexGroup “Emit”. See therefore the section “From:” in the Particles Panel and there the “VGroup:” Input Field.
Now the particles emit only from this Group what you have - I hope so - placed somewhere at the jet drive.
And this whole thing is now moveable.
FastEddy
Hmm, seems to be a bug in 2.41 perhaps???
or something changed that I am not aware of.
One work around is to activate ‘Static’ on the Particle emitter temporarily to allow you to move the parented Object.
Or maybe do the parenting after you’ve got the desired object keys inserted.
It seems that you can still add keys in the IPO Curve Editor window to create the movement, but of course, this doesn’t allow for an easy method for placement.
Hi!
I also encounterd this problem with the exhaust of my ship in a recent sequence…
The only ways I found were:
-
To unparent the particle emitter while setting the frame keys of the ship.
-
Setting the Loc and Rot keys of the ship in the Ipo window… not very handy!
okay, but you can do the following:
JOIN (Ctrl-J) the EmitterObject to the rest of the jet’s body and make these Emitters Vertices a VertexGroup (named e.g. Emit or so). Now you make the whole jet an emitter, but you tell the particles only to be emitted from the VertexGroup “Emit”. See therefore the section “From:” in the Particles Panel and there the “VGroup:” Input Field.
Now the particles emit only from this Group what you have - I hope so
[>] When you use particles, you generally apply to them a halo material.
[!] When you apply a halo material to a mesh supporting more than one material, only the first material can be set to halo (in fact you can toggle the halo button on the other materials, but this has no effect!), and all the other materials of the mesh will copy this first material and will be halo.
[!] If you use a mesh as emitter and set only a vertex group and select a material to emit particles (dynamic or static), the other materials are not rendered!
So DO NOT join your emitter to the main mesh, or you may have some bad surprises!
Philippe.
I just think, too, it’s a bug!
today I got an email from another user who has a similar problem. and he sent me a scene file, created with 2.36, where there are parented emitters. and the animation works properly - okay, with just very slow preview (on 2.36 at normal speed).
And I myself also know, that emitters could have been parented (and moved) before 2.40, because I did it more than once within some test-animations.
I posted this problem in developers’ animation forum and actually I am waiting for response. If I don’t get an answer until friday, I’ll post it in the bug tracker, too.
Let’s see…
FastEddy
It looks like this is a known issue and has already been posted in the bug tracker:
http://projects.blender.org/tracker/index.php?func=detail&aid=3901&group_id=9&atid=125
Hi!
In 2.41, you can move the parent of the particle emitter as far as you have not inserted the first Ipo Key.
After it is locked!
I have just checked it in the older version I have on this computer: The 2.37a.
There is no problem, and the parent can be mooved even after inserting Ipo keys… so, it is certainly a bug in 2.41!
Philippe.
yes, it is a bug and it is tracked.
so we can do nothing, except of waiting… (or helping the coders)
I’m typing too slowly… JarellSmith gave an answer while I was doing a test and writing!
Philippe.
@ ROUBAL:
When you use particles, you generally apply to them a halo material.
When you apply a halo material to a mesh supporting more than one material, only the first material can be set to halo (in fact you can toggle the halo button on the other materials, but this has no effect!), and all the other materials of the mesh will copy this first material and will be halo.
If you use a mesh as emitter and set only a vertex group and select a material to emit particles (dynamic or static), the other materials are not rendered!
Thanks for THAT advice! I didn’t know that yet, I’ve never tested that before, because yet I didn’t know this emitter-parenting-bug!
let’s hope this bug will be gone soon…
FastEddy
Try to use a copy location contraint on the emiter object pointing to the jet.
Gilberto
sorry, that’s a less useable solution, because - as the name tells - it copies the location, but it does not apply the rest of a bunch of other translations/modifications to the “child” object like real parenting does.
example: the combination of location AND rotation changes on the cild object while only rotating the parent.
Hi!
I have just made a test, and you can have the wanted result using both Copy location and Copy rotation constraint, but you have to do one thing before:
Put the center of the master object out of the mesh, at the point where will be attached the particle emitter!
Philippe.
“outsourcing” the center is okay (I didn’t mention it, because it is the default for this plan), but this changes the rotation (not only) behaviour of the parent, too. indeed then, if you want the object to turn around another center/axis (e.g. the turnable jet-drive of a harrier-like plane).
normally you set the center to the point, where the joint axis should be, but now you had to parent these objects to an additional empty to simulate this rotation center, and then you have the same problem as before: you key the empty and then you can no longer move the whole thing…
still seems like having to wait for bug-free coded solution…
FastEddy
Hi!
I do not agree at all!
I have tested it, and you can parent the object (ship) to an empty and move it and keyframe the empty at will!
You have no longer the locking problem!
You may have done something wrong, I believe, because it works well here under Blender 2.41!
Philippe.
very strange… :-?
I wouldn’t have written this without testing, and I am sure, yesterday it didn’t work!
But when I tried again just a few minutes ago in the morning, it worked.
so okay, there’s this workaround for the bug.
is only the very little problem of having many (in opposite to normal circumstances) more additional empties which make the anim hierarchy deeper. this could slow down animation preview of deep anim hierarchies.
but it should indeed work very well for animations with “normal” hierarchy tree depth.
I’m still keeping an eye on this one as I’m the one who put it in the Bug Tracker a couple of months ago.
Best advice I can give is this:
Make your emmitter and parent it to the moving object, but save turning on the particles and setting them up until last thing. Get the movement right first.
I think it’s due to the new code that redraws particles in real-time in the 3D window.
Good luck!