It would be HUGELY beneficial to have the ability to spawn particles from ParticleEmitters at specified CFrames, rather than only having the particle emit relative to its parent. And I say CFrames specifically, not Positions because CFrame would allow for the particle to emit in a certain direction according to its speed.
Right now, we have to have many duplicates of the same ParticleEmitter to achieve more complex particle setups (such as emitting a line/path/shape of particles).
If we had the ability to pass a CFrame through :Emit(number, cframe), or have a new method such as :EmitAtPoint(cframe) - the amount of design power would skyrocket for particle systems.
Right now, we have to rely on a set of parameters that define the imaginary shape at which the particles are spawned from a single ParticleEmitter, but these can be a little limiting. And using many ParticleEmitters for one effect takes up more resources to simulate multiple systems.
BONUS SPAWN PARAMETERS
It would be even more powerful if we could have a few more parameters to customise per-particle spawning behaviour.
OffsetVolume (Vector3) - specify a volume in which this new particle that will be emitted will be offsetted randomly within, with the centre at the spawn CFrame.
SpeedMultiplier (float) - speed multiplier at which this new particle will be travelling at respective to the ParticleEmitter’s set speed. E.g. SpeedMultiplier of 2 will double this specific particle’s speed.
So, an example for this new method would look like so:
Support! It would be more optimized and easier to use (aka, less structure) if this feature was added.
I would prefer the api to look like this Particle:Emit(Number:number, Cframe:CFrame?, Volume:Vector3?)
There is a surprising amount of things to unpack here.
Attachments parented to non-physical objects work now. Could be used to emit particles at a point. This solves some usecases that I was imagining. I’m curious to hear what other people are expecting.
I’m scared about overloading the function call with lots of new parameters, as there are a huge amount of other properties/settings of particles that I (or other devs) could request. A table config might be a better approach, but I’m not sure about the efficiency implications. And at what point are individual particles considered instances?
I’m having trouble imagining api or api changes that don’t feel contrived.
Perhaps the best implementation would be for a new ParticleSettings type, which is similar to RaycastParams where you create it with ParticleSettings.new() and then on a new line you dial in the parameters like newParticleSettings.spawnCFrame = CFrame.new(…)
I currently am using ‘floating’ Attachments extensively within my project, however there are still some annoyances I have to work around within my framework. Having the ability to emit particles from multiple source points that constantly change and having all those particles share the same properties (from the same ParticleEmitter) would be a game changer for VFX artists!
You can already do this with attachments, adding more parameters to a function will just confuse most folk using it, it’s significantly better to create something that doesn’t change the code behind particle emitters as a whole.
P.S: Before you say ‘but you need a BasePart to use Attachments’ you don’t, there’s a beta where you can put Attachments standalone in workspace.
Perhaps for you, but for VFX programmers this would be a hugely beneficial thing to have. There’s no nicheness about having more control over our visual effects. Yes, you can do it with attachments like I stated in OP, but it would be more efficient and less clunky to just emit particles under the same ParticleEmitter, so that we don’t need as many cloned instances and so that the particles inherit the same properties from the emitter
You are right under the point of adding parameters to an existing function creating confusion, hence why they should add a new method to pass in these additional parameters if this is to be a feature.
It would be more efficient in that SINGULAR use case.
No offense, but you have to look at the grander picture when you want to change existing functions to see if it’s worth it.
In this case, it isn’t, this is the same as the ‘add debounce to IAS’ post I saw a bit back, it’s an additional feature that shouldn’t be an actual segment of the system.
Adding a new method for this just creates bloat, there’s no reason to rewrite the particle system to add allow arbitrary emit position just for one method, this is why they allow particles to emit on attachments.
If you really want to do this, then make a wrapper class.
