FX freed from Source

[Argh]

As I've said previously, I would like to free all of Spring's "native" FX code from the clunky limitations of being tied to Spring's sourcecode.

The default FX are extremely limiting, and are only really suitable for a technological game design. Getting rid of them entirely, at this time, involves giving up a great deal of functionality- you cannot use a null for the default flame bitmap, for example, without removing that flame from any default animation that uses it. Moreover, many of these animations, while they looked great during the early days of Spring, aren't looking all that hot now, and are hugely wasteful of computing resources in some cases. And, even worse, in my opinion, they don't all use the particle-generator code (some use custom code, probably written by SJ during the hectic run to the first major releases).

So, the goals are:

1. Clean up Spring's code, by compartmentalizing this area into one single area and using one codebase, instead of one codebase for game developers, and another for Spring's native FX.

2. Speed up rendering speed, by producing better default FX that run faster because they use fewer particles or simpler math.

3. Make FX for default events completely customizable by game developers.

4. Make Spring's default FX pretty enough, and efficient enough, that people will want to use them for their projects, instead of laboriously constructing their own. At the very least, they'll have an open-source model to work from.

Needless to say, this isn't just an Argh project- if other people can build really nice, clean particle FX, and want to participate, they're more than welcome to, of course. I occasionally look at other game devs' work, and there are several folks who've been making good use of the various particle-generators over the last few months, and there's no reason not to improve things by taking as many high-quality submissions as we can!

Ideally, we'd create both "stock stuff" for general-purpose use, and many more-esoteric "modeling exercises" (like my nuke script) that may have uses for a particular work, or serve as a basis for new ideas. After all, not every game is going to want realistic flames and smoke, or whatnot.

All I need from the development side, to make this work out, is a developer willing to start the mainly-boring task of un-coupling these FX from the source, pointing them to ExplosionGenerators with fixed names, and once I have the entire list, I will happily donate a chunk of my time to this project, and release the resulting sourcecode, bitmaps, and other media.

So, that's the plan, basically. If everybody agrees this is a reasonably good idea, then the first step, I guess, is to get a complete list of all of the particle-generation events, from nanospray to sub-bubbles, to smoketrails for aircraft, to the fires that start when trees catch on fire, etc.

[Tim Blokdijk]

I know little about the FX system but as I understand it you like to change all the hard coded FX to point to customizable stuff?
Would it not be simpler to keep the code as it is and make it possible to not use the hard coded parts if you don't like it?

So you would just define something like custom_fx = 1 in the mod or unit config file and all the hard coded stuff is disabled.
Then you would "just" create your own effects with "the customizable FX system".

[jcnossen]

Is it practical to discuss this in a semi-closed forum?

[Argh]

I know little about the FX system but as I understand it you like to change all the hard coded FX to point to customizable stuff?
Would it not be simpler to keep the code as it is and make it possible to not use the hard coded parts if you don't like it?

Yes to the first part, no to the second.

Moving from the hard-coded FX to standard ExplosionGenerators will be a lot less awkward than you'd think. All of the hard-coded stuff invokes the same particle classes as the free-form stuff did, actually. The only exceptional areas are a few things that weren't ever made properly accessible through ExplosionGenerator code; however, making them so is relatively trivial, so long as we're not worried about making them fun to work with.

As for why I'm talking about this here... meh, move it, if you'd like. I just don't want it to get clogged with stuff that is irrelevant. A public discussion of the resulting FX is definitely required, just to get a reasonable amount of feedback.

[Tim Blokdijk]

...

Moving from the hard-coded FX to standard ExplosionGenerators will be a lot less awkward than you'd think. All of the hard-coded stuff invokes the same particle classes as the free-form stuff did, actually. The only exceptional areas are a few things that weren't ever made properly accessible through ExplosionGenerator code; however, making them so is relatively trivial, so long as we're not worried about making them fun to work with.

As for why I'm talking about this here... meh, move it, if you'd like. I just don't want it to get clogged with stuff that is irrelevant. A public discussion of the resulting FX is definitely required, just to get a reasonable amount of feedback.

Ok, and with fun to work with you mean more customizable?
What are the effects that are still hard coded? As in do you have a list?

And about Jelmers remark, the idea is indeed to allow the core developers to talk things over without noise from non-contributors - once things have been discussed here you would still need a public discussion but then a topic derailment won't effect development so much.