Deprecate ParticleEmitter.EmissionDirection; Add ParticleEmitter.CFrame

#The Problem:
Scenario A: I want to make sparks come out of a metal part where it’s hit by a sword or bullet

To accomplish this, I have to create an invisible, dummy part at the hit location and parent the emitter to that to tailor to one of ParticleEmitter’s idiosyncrasies.

Scenario B: I want to emit a muzzle flare from a single-part mesh weapon

Since this weapon is a single part, it has no part for a barrel to emit from. I have to again create an invisible, dummy part at the barrel position to get the emitter to emit from the correct location. Even if I was using a weapon comprised of multiple parts, the barrel may be a long cylinder rather than a small box at the tip of the gun.

Scenario C: I want to have dazed “stars” spin around above a character’s head

I don’t want them to emit at the center of the head, so I have to create another invisible dummy part above the head for the particles to emit from.

#The Solution:

ParticleEmitters should have a CFrame property, similar to HandleAdornments. If I have a CFrame value of <0,1,0>, the particles’ origin would be 1 stud above the parent part. I could also apply angles to that CFrame value to make the particles emit at an angle. This would resolve all of the scenarios above and make particle emitters less awkward to use.


For the ease of transition, just have it that setting the direction to “Top” sets the CFrame to <0,1,0> etc.
That way, both can be used, and the CFrame property will always be correct.

1 Like

I believe you mean CFrame = CFrame.Angles(). EmissionDirection = Top would be the equivalent of CFrame =,0,0) * CFrame.Angles(0,0,0). EmissionDirection = Bottom would be CFrame =,0,0) * CFrame.Angles(±math.pi,0,0).

As for backwards-compatibility, there’s no issue. Particle emission origin would be calculated as * Angles(EmissionDirection) * Angles(CFrameProperty). Emitters would not change where they were emitting to/from with this update.

If you’re implying we should keep EmissionDirection to be used alongside of CFrame, there’s no need. Anything you could make with EmissionDirection you can replicate with CFrame – having two properties that do virtually the same thing is dumb.


Yeah, I meant <0,1,0> angle wise. (I always saw people using (), so your <> seemed for angles I thought)

Just for backwards compatibility

1 Like

Yeah, no need then. This update wouldn’t change existing emitters.

Notation we use for vectors in my physics classes

1 Like

At this point would we be able to decouple the need for parenting the emitter to a child at all? Given that we could just parent it to an object resting at the Origin and manipulate the CFrame offset and angle for world space

1 Like

If you wanted to, yes.

Ironically, every emitter already has a CFrame internally. The hardest part is the UI once again, because unparented emitters will need some viewport icon to indicate its position/rotation, pretty similar to what you can see in 3DS Max or Maya. And they will need dragger support as well, which is a little bit problematic for the time being…

Sounds like a perfect job for an intern, btw :slight_smile:



1 Like

I find the interface for moving Attachments absolutely wonderful if that’s something that would be appropriate for particles as well.

1 Like

It would be interesting to be able to link PEs to Attachments, and Attachments allowed to be directly parented to the Workspace.
(although we can just parent it to the Terrain for a static 0,0,0 thing)

1 Like