I am familiar with that test, but what it really demonstrates is that the computation of the motion is faster when done in native code. That is only natural, and that was my plan as well.
The actual drawing of the sprites happen in the Godot engine and should not change in speed depending on whether the initial "create sprite" call came from script of native code.
In my test, I only instantiate the sprites. I do not move them. I then look at how quickly the engine is able to simply draw them, and apparently, that is not very fast. To be fair to the engine, you should generally not make and render 10.000+ 3d sprites. I only did that, though, because the particle system would not let me control the motion, which is something I would need for the project to work.
Seems like I will be stuck with unity a bit longer.
There I render a large number of 3d points with the current particle positions, feed that through a geometry shader which generates quads billboards, at current calculated point location, that I texture with a fragment shader and that works just fine.
A lot of other things about Unity works less fine, though, so I am a bit sad that Godot does not have that final piece of the puzzle ready just yet.
