Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Dragon on July 09, 2014, 03:36:21 am
-
I've been experimenting with particle thrusters a lot, without that much success. Now I realized why. Looking at KSP's thruster particles, and at actual exhaust physics, brought me a realization of how to do particles properly. Then I found I can't do that in FSO. :)
The idea is that particles represent gases at high velocity. As such, their speed should be similar to the engine's exhaust velocity. That would be something near 3000m/s for a realistic engine, meaning an individual particle would have to have something like 0.001s lifetime to give a 3m trail. While this is a bit excessive (and probably wouldn't work), but the point is, you've got short-living, fast particles. You don't even need lots of them, obviously there'd be a lot per second, but they'd have much shorter lifetime.
So, here's my request:
Allow single-bitmap thruster particles, like for missile trails. Animated ones are not good for what I want to do, they could be used, but it'd seem hacky.
Allow control over lifetime and velocity range of thruster particles. Velocity range would work such that at max throttle, you get max velocity, and at zero (or negative) throttle, you get minimum velocity.
Allow defining "end radius". The particle would shrink to it from the start radius. Would go well with otherwise static particles, but probably isn't very important in the end.
That would allow particle thrusters to compete with modeled ones and with thruster bitmaps, both performance-wise (a small amount of static particles instead of large amount of animated ones) and visual-wise (they'd look like thruster flames, not like smoke trails). They'd look good on fast ships, too. All that without a performance-intensive script (I know there's one, I also know overuse can and will bog down the game). I'd also allow more options for thruster particles, which is good, because they're currently woefully limited on what they can do.
-
Waddabout slow cap ships?
-
Would work just as well for slow ships, due to the particle exhaust being so short-lived and disproportionally faster that it would not matter at what speed the emitter moves. The flame will be pretty much static with regards to it.
-
From my experience, thruster particles only spawn when undergoing movement and the distance they go depends on how fast the ship is moving. An odd occurrence is that thruster particles don't spew forwards when moving backwards.
-
Yes, and I'm proposing changing that. While it works for some very limited applications, there's so much more you could do with features I propose.
-
particles in the freespace engine are weird. different kinds of objects have different emitter code (at least thats the way it was when i screwed with it several years ago). pretty much there is just a function call to make a particle, and its called all over the codebase seldom in the same way.
its hard to make one unified system that works for everything with out breaking something. ksp on the other hand is built in unity which already has particle emitters, everything that uses particles uses the same emitters. it would be nice if freespace used that. it also has a neat way of managing object hierarchy in the game engine. so if i wanted to do a helical emitter for railgun spiral effects, id just stick the object with the emitter inside another object with an offset, and then animate the other object to rotate on a looped animation curve. the end result is a spinning emitter which i could attach to the projectile object and make a neat little railgun. these are the benefits of a highly object oriented game engine. while to do the same thing in freespace i had to write that spawner code, which wouldnt easily port over to engines or any of the other things that use particles.
what needs to be done is wrap all that emmitter code into a unified class, and make it so you can attach an emmitter to any object in the game in a unified way. rather than the hodgepodge of means currently employed. its not something that would break gameplay, but it would be difficult to make everything look the same as it did.