Allow particles use custom coordinate space rather than just local and global.

[Skywolf285]

In Godot's current implementation can particle emitters (CPU/GPUParticles2D/3D) either emit using a local coordinate system, meaning the particles "stick" to the emitter, and global coordinates which allows the emitter to move freely without affecting its particles after these are created.

Having only these two option poses a problem however for any situation where you want particles to use a different than global coordinate system while still keeping the expected behavior of having particles move independent of the emitter.

Example:
You play as a hero of Generic Fantasy Setting 4.0. You just got the Epic Sword of 420 Fire Damage which has a cool looking flame effect using GPUParticles3D. You now enter your player-customized bright pink Airship to travel to the destination of your next epic quest. You enter the crew cabin and plot a course for the Town of Endless Waiting where your quest giver, the ever handsome Godette, awaits you.

However as the ship stars moving the particles on your sword suddenly start flying off on their own whim! It's as if the particles aren't aware they are inside an enclosed space where, outside of maybe acceleration if the fire had mass, they shouldn't be affected by the velocity of the ship! They fly against the wooden decor of your cabin, setting the ship ablaze and you brace for the worst.

Fortunately it crashes on the Town of Unity which was already experiencing political unrest due to recent changes in leadership and thus you heroically averted a civil war by accidentally destroying it. But while you and your crew got way unscathed you starts to wonder, How could this be avoided?

Possible workarounds:
You use your hero privileges to get a new airship and start tinkering with the sword. You find a hidden button behind a latch with local_coords written on it. You press it and while the results look promising at first does the sword now no longer leave behind trails of fire as you swing it, something that has wowed many a bystander. This is not acceptable.

So you dig deeper. "Maybe I can simply offset the location of the fire by the opposite of the last change in velocity of my Airship?" You cast a spell to add uniform vec3 vel_offset; and modify the enchantment's process() function to modify TRANSFORM of the fire using this uniform each time the function runs. This would mean that every vehicles that you would ever ride would have to be modified to inform your sword of its current velocity but you are the hero, you can probably use your hero privileges to convince the owners of every vehicle in the world to make these changes for you.

You make a few more tweaks to the sword itself and get to testing. You quickly realize a problem however: the fire gets offset at a different rate than the rest of the world you inhabit. You check the sword again and notice a note with fixed_fps and the number 30 written below it. Now you could change this to something higher than the framerate the universe would ever run at but an old and wise wizard once told you about the risks of changing properties like these and how this could easily result in the complete collapse of the universe's entire performance.

So you look further. "Maybe just write my Airship's current velocity to vel_offset, then adding that to VELOCITY on newly creates particles?" You again make some changes to the enchantment and try again. It actually seems to work this time except that whenever you airship makes a sudden turn the old particles continue to travel in the direction they were before it changed course. This would be fine if fire had mass but it doesn't and should move with the air inside your cabin.

Another issue arises when you attempt to further the enchantment on the sword. In order to make these changes you had to convert the enchantment into a written text (revered into the ancient texts as "Convert to Shader") but by doing so are you no longer able to add any functionality that was previously available prior to this procedure but that was not enabled. You would also have to make these changes to any future enchanted gear you pick up which would be quite a hassle.

To make matters worse: You can no longer reuse enchantments! If you were to reuse the same 420 Fire Damage enchantment on another sword and this sword wouldn't be aboard the same vehicles you are will vel_offset be changed to whatever vehicle changed it last on all swords using this enchantment. Creating an ever bigger fire hazard as the fire now flies into seemingly random directions! You could copy the enchantment to an identical duplicate with only a different name but this would clutter your spell book and could have a potential negative effect on the universe's performance.

Defeated you give up. You ask other adventurers about the same issues but after some Discourse you return empty handed. Seeing no other option you drop to your knees and pray to higher beings. Hoping that one of them is willing to alter the fabric of reality to allow you to have both your Epic Sword of 420 Fire Damage and your bright pink Airship at the same time. Or maybe, maybe they have a better solution than your peanut brain could come up with that doesn't require the altering of reality. You are fine with that too.

TL:DR I can't find a way to get the desired behavior by just modifying the particle shader. From what I can see does something in the engine itself have to be modified for this to work.

Back to reality.
The way I would like to see this implemented is that aside from local and global coordinates the user can select any node2D/3D (or node that inherits from these) and use that local space as if it were the global coordinates. I have no idea how difficult this would be to implement however as I assume GPUParticles use some shader magic to figure out the global and local coordinates. Adding custom coordinate space to this could possible add some overhead that might not be acceptable.

CPUParticles shouldn't have this drawback however. I must admit I haven't been tinkering with this enough to be sure that you can't implement a workaround using these instead as I would prefer to use the more performant GPUParticles but if nothing else I feel like this would be a decent compromise. That said, from what I can find in the documentation is there no way to directly control CPU particles from GDScript so I'm pretty sure that what I want is even less possible in the current implementation compares to GPUParticles.

For completion sake would it ideally also allow for acceleration to be taken into account. As mentioned above does just changing VELOCITY in start() inside the shader achieve this result already. Just with a whole bunch of drawbacks. Most of which are caused by the nature of having to convert the ParticleProcessMaterial to a shader first.

I'm also aware this is somewhat similar to #3649 in that this implementation could allow for what is asked there with a bit of creativity. Although with float=64 being more functional now is world origin shifting no longer required (Aside from maybe running your game on old, 32-bit architectures as the performance impact of double precision could be significant enough there).

[QbieShay]

Would an inherit_velocity property solve your issue?

[Skywolf285]

Guess it depends on how that would be implemented. By the name I figure it would practically do the same as adding the velocity of the parent node to the VELOCITY in start(). Which would work in certain situations and would love to have it as an option but in cases where you just want the particles to "stick" to another node that wouldn't work.

Like if I want the sword to only leave behind trails when swung but when the player moves I want the flames to move with them I would tell it to use the local coordinates of the player character.

Maybe having an inherit_location property as well could allow for both results.

I also assume this would just be a boolean that makes the particles inherit the velocity of only the direct parent. Which if this is the case would just make the flames inherit the velocity of the sword, not the airship as intended. Making it not ideal.

Another potential problem is what would happen if the emitter switches coordinate space/parent during runtime? Do the old particles emitted before changing the coordinate space/changing the parent continue as normal? Or does entering a moving airship suddenly cause the old particles to change direction/velocity the moment the player set foot onto the ship? The more natural result would be the former but again, not sure how feasible this would be to implement.

[TobiasDn]

I am interested in this for 2D particles too, similar situation where I have a game-over pane with some moving particles emitters.

I'd like to pan the pane in and out from the side, but with the current setup they either have to stick to the emitters, or they'll leave a trail behind beyond the borders of the pane when it pans. I can use a viewport and pan that instead, but its a bit cumbersome, and there's a performance penalty as well.