I want to create a rocket that emits particles like fire, but the particles are leaving a trail. However, I want them to be in local space so the flame is pointing always downwards. Is this even possible? In the attached playground I set up an example of how my particles currently behave.
https://playground.babylonjs.com/#PU4WYI#95
Edit after thread:
It seems as if there is currently not the perfect solution to this, however I was satisfied enough to mark Wingnut’s post as solution.
Hi TS, welcome to the forum. And yes, that is possible. You just needed a few more settings.
https://playground.babylonjs.com/#PU4WYI#96
I added some comments in the code… to tell what I did.
First, I/we set gravity to 0,0,0 to keep particles from falling toward ground.
Then, I/we adjust the min/max emitbox to be located at the wide end of the rocket. Those emitBox settings are positional vector3… emit particles from where to where… on the rocket mesh itself. Therefore, it also sets the “diameter” of the rocket’s thrust nozzle (currently set to 0 by 0). See lines 66/67.
Then, we adjust our direction1/2 to spray particles in the correct direction (these values take a little special directional vector thinking… which is somewhat different than positional vectors.) See lines 60/61.
Also added some particle colors in lines 70-73, just for fun. They “evolve” as the particle ages.
I hope this is helpful. Ask questions as needed, or, maybe mark as solved… your call.
Note to core folk: We MIGHT have a little bug, here. It appears that the emitRate is increasing by itself, over time. It could be a Wingnut mistake, though (common). Concerned folk, give opinions about that, here, too. I’m sure TS won’t mind a little extra talking on his thread. 
Thank you @Wingnut for your help, but I think I wasn’t precise enough with my explanation.
My rocket is in the landing stage and then intersecting with the particles, or I set the emitrate to 30+, but then you can see the pause between the emited particles (seen as lines in the playground). Therefore, I want to use them in local space not world space, so they move with the rocket.
I hope this clarifies my idea, else I’ll try it again in other words.
https://playground.babylonjs.com/#PU4WYI#100
(reduce the emitrate to 5 to see the intersecting)
Hi again. Ok, sorry I misunderstood.
I have an idea… not necessarily a GOOD one, though.
Take a look at this particle demo. https://playground.babylonjs.com/#1PQT7P#27
There are 3 “custom” functions in that particleSystem. They are “installed” into the particleSystem… in lines 84-86. The one you might be interested-in… is ps1.updateFunction = my_updateFunction;
Let’s look at the custom updater func… lines 37-58. You can install this function in YOUR particle system… with an easy paste of function and installer line 86.
The function is currently set to “default”… it is an exact copy of the update function that BJS uses in its core. But you… could hack it. Keep in mind that this updater func runs continuously and VERY fast.
See line 53: particle.position.addInPlace(this._scaledDirection);
Could you somehow add ANOTHER line beneath it… perhaps something like:
particle.position.addInPlace(this.emitter.getAbsolutePosition());
Might work. Might not.
Perhaps it needs…
particle.position.addInPlace(vector3AmountOfChangeInEmitterPositionSinceLastTimeThisFuncRan);
Often called diff… sometimes gotten by subtracting previous emitter position… from current emitter position, or vise-versa.
I dunno. Long var name, eh? I hope I am on-topic. Stay tuned for (likely smarter) comments from others.
I was about to offer the same option 
The custom update function is probably the way to go
Also did you check the velocity over time option? Particles could be faster at start and then slowed down? https://doc.babylonjs.com/babylon101/particles#velocity-over-time
Some of that “layering” can be fixed by setting the emitBox a little taller (into the rocket body a bit).
Change line 70 to particleSystem.minEmitBox = new BABYLON.Vector3(0, 1, 0) …less particle layering. Now our emitBox is 1 unit tall, right? Particles are emitting across a 1 unit vertical height, so the vertical layers are filled with vertical “spread”. With me? If so, you’re doing better than I.
Possibly set that 1… to a 0, for even more layer-gap fill-in.
Hi,
Thank you all for your help.
This idea made it already a bit better.
As I am fairly new to Babylon, I hope someone could explain the particle.position.addInPlace part to me and maybe even link a playground to an example.
It could even be the case, that it’s (still) not possible in Babylon as this link suggests:
Hi again, TS. I think @Deltakosh would have mentioned a flag, if one existed.
There might be something I forgot to tell you. I don’t THINK that GPU particles… allow a custom updateFunction.
I’m not sure that I’m qualified to try to help with this, as I barely understand localSpace and worldSpace as it applies to moving emitters, but just the same… https://playground.babylonjs.com/#PU4WYI#103
I de-parented the rocket, installed the custom update function, and forced this to be CPU particles and NOT GPU particles.
I’m using “diff”… which is the positional “difference” happening on the rocket… at each render frame.
Let’s look at line 123. There, I am recording the rocket’s previousPosition… just before the animation is stepped.
Now let’s head-up to the custom updater func… where I added lines 49/50. Line 49 calcs the rocket’s positional diff, using a subtraction method, and then in line 50, I add that diff to each particle position.
Now, I don’t know if this action is “local-spacing” the particles or not. I figged I would show you what I was thinking about, wrong or not. Maybe others can help-out with this… as I’m unsure of too many things. Sorry.
Correct. There is no local space flag but as @Wingnut it is easy to do with custom function (And he was kind enough to provide a PG :))
Also correct for GPU: no custom function as all the code runs on the GPU
Thx DK. Would you look at my WAY of local-spacing and check it for stupidity on my part. I’m on thin-ice, here, intelligence-wise. (thx) Others welcome to proof-read/debug, too, of course.
Want a BUGS report for that, or… want to consider THIS a report, or… am I doing something wrong there? (thx)
All good to me
I see no problem on the PG. What makes you feel it is not working?
Uh oh, problem is Firefox-specific GPU-particles ONLY. Standard particles works fine, both in FF and
IE 11.0.9600.18097.
Was running: FF 60.7.0esr (32-bit)
Updated to: 60.8.0esr
Same issue. VERY heavy emitRate after 4 minutes running GPU particles. (Wingnut kicks his Firefox and rubs his beard).
hmm. I suppose I better request other FF users to look at it… see if they can verify.
Well the emitRate is still limited by the capacity of the system so it will emit up until the moment the capacity is reached. And then the system will wait until particles are recycled
nod. That doesn’t match symptom. No pauses here… just starts with gentle thrust… not too many particles… like you see it. 2-4 minutes later, HEAVY spray… still no pauses. No abrupt change… just gentle continuous rise in plume thickness. I haven’t watched emitRate with console.log… I doubt it’s changing.
Got a firefox on desktop nearby?
Well I have Firefox and unfortunately I do not repro
Oh goody. Ok, thx for checking. Got a moment to tell us your OS, device, and FF version that you tested-with? thx.
Maybe particles are not disposing for me… so particle queue is ever-increasing, even while emitRate value holds steady. hmm.
TS, sorry for off-topic-ing your thread a little.
Win10 / ff68
The way gpu works is a bit different and you cannot console.log as everything is gpu side
Can you do a video of the problem so I can have a sense of it?
Ok maybe I was unclear we generate 1000 particles per frame with a capacity of 1000000 particles.
The plume will not look dense at the beginning as you will only have a few thousands. Then by waiting you will have more particles (as the older ones gets recycled and added back to the pool while still adding more because of the emitRate)
if you want your plume to look dense immediatly you can use the preWarm option:
https://doc.babylonjs.com/babylon101/particles#pre-warming
Or just emit more particles per frame (like 10000 per frame or something along these lines)
GPU particles are really powerful but a bit more complex due to the pure GPU nature
Yeah, I can do a bad job at that. Fraps to the rescue, I suppose.
http://urbanproductions.com/wingy/box/emit_rise.mp4
This is without pre-warms. Pre-warm PG #104 changed things, mainly sputtering on particle start. Other issue no change… slow increasing emitRate, or Wingnut being faked-out into thinking so.
Fraps recording slowed the scene animation a bit, but issue still easy to see in video. More and more yellow-ness particle density… behind rocket, as time passes. More and more difficult to see-thru the plume… as time passes.