Add overrides for CFrame and Size to Particle Emitters

As a Roblox developer, it is currently too hard to work with ParticleEmitters and Attachments.

A big caveat with using attachments is the loss of spread; when you parent a particle emitter to a part you get particles emitted from the whole volume of the part, but this comes with the overhead of having to manage the part. Using attachments eliminates the part, but also you lose the useful spreading behavior.

I often do not want to have a big invisible part to apply a particle effect to e.g. a character, because this part will trigger .Touched, raycasts, etc. Cleaning up after this requires either extra code or collision group juggling. Moving the part outside of the character model to the correct position on RenderStepped is also really dirty. I would much prefer to simply use an attachment here.

Particle emitters would be much more powerful if there were a set of properties that allowed you to override the parent’s CFrame and size, and provide your own CFrame and size independently. I.e. UseBoundsOverride, BoundsCFrame, BoundsSize.

This would also allow the new procedural particle emitter shapes to work with attachments. Currently, they simply do not work at all because they require a huge part to provide the bounds for the particle volume. I left a reply about this on the announcement thread to no response. As mentioned, huge parts are horrible to work with.


Can this not be avoided using CanQuery, CanTouch and CanCollide?
I understand your post but this specific reason I feel like can already be solved.


This theoretically works, but is dreadfully messy in Studio; it necessitates making huge parts that overlap their intricate models, which makes it impossible to select anything through these emitter parts because the bounding box is in the way. There is no (supported) way in Studio to hide certain parts from the selection tools (you have to use a collision group hack, which is tedious). Also, CanQuery is still in beta last I checked?

Parts are not currently suitable as volumes for abstract developer concepts without CanQuery and without being able to disable selection of them.

Further, the new procedural shape features not working with attachments is inconsistent API. Attachments already work for particle emitters. Them not working in this one specific mode without any communication why is terrible UX.


I can agree with that. The new features being pushed through don’t seem to be very well thought out or documented anymore.

Support. Removing parts also means less memory bloat and less the game has to stream in.

On the flipside, all the additions lately have made for a rather complex set of interactions and use-cases that have to be taken into account, and it’s difficult to consider what minutiae would affect a developer’s decision in using one feature over another and how they’d expect two features to interact.