Feature Request: S3O/COB Particle FX

[Argh]

I have a feature request that will finally allow us to have customizable particle FX in Spring, WITHOUT adding massive OpenGL coding challenges, big headaches for Zaphod, etc., and will give us modders what we need. So, please put away your point counters, guys- if there are any really nasty flaws with this, let's talk it out, because I think this is the way to get us what we all want here without making the developers go insane

It's really simple.

For FX that look really kewl and are really flexible and useful, all we need is:

1. The ability for any effect call to call one (or more- see below) S3Os, also referencing their COB just like a unit. This mainly means FBIs, but there's also the issue of what GAF was originally being assigned to "smoke"... we could have oil sprays, blood, sparks, dynamic fires, etc. with this. Why more than one? So that we can use multiple (small, low-rez) texturemaps, of course. That would keep speed up.

2. Alpha transparency using the last available RGB color channel in the current S3O specification (I have been assuming that that's what that will be, eventually).

That's it. Two fairly minor technology challenges- S3O's can already be called as weapon objects, so there is no reason why FX couldn't call them, instead of calling the current OpenGL routines.

How would this work? Simple: instead of calling for a stock FX (no, I'm not calling for them to be removed, they're useful for many contexts and look nice) we could call up a S3O. That S3O would have a script that looked like this:

Code: Select all

piece base, explosioncenter, explodepieceone, etcetc;

Create()
{
Do some fancy animated thing here to depict the dynamic effect
}

... Voila! With alpha-channel transparency (through the blue channel, of course) + glow... we could do glowing fires, smoke drifting up in random clumps, dirt chunks lifting from the ground... blood splashes, etc.

And, the best part? Because we'd no longer be tied to a 2D world... we could randomize the movement and timing of the "particles" (really, these would be simple, three square panes for transparent objects) and have truely unique events. Oh yeah, and this one change would allow us to have gunflares that looked really, really pretty, too :)

[IMSabbel]

yeah. that would be nice...
But about gunflares:

Is the odd behavious of the smoke guns make in some mods hardcoded?
Because its REALLY strange: it seems the smoke cloud scales linear in time...
But because its doing so in 3 dimensions, it looks like the expansion is slow in the beginning and getting faster... it should be very rapid the first few frames and slow down as soon as it epands...

[mongus]

yah yah, that is beautifull.

i didnt read shit, but what is a pixel?


e:

no really, i think s3o's for effects is a bit "heavy" i mean, slow.

im guessing SFX are way "ligther" than s3o models...

thinking again.. s3o are not that heavy, but think of houndred units calling for the same "s3o" effect at the same time.. wouldnt that multiply to the sky the resources neeeded?

yet again, souds not that complex, built around the same format spring is already able to deliver.

the transparency and other stuff is most sure included in future riencarnations of the s3o format, so.. its most likely reching those s3o SFX too...

[Argh]

Yes, S3Os are probably going to be "heavier" than pure OpenGL + some textures with alpha channels, which is how things work right now. But... it's worth it. Why?

1. We'd no longer need C++ developers with qualifications coding OpenGL and knowledge of the Spring engine to make nice-looking FX.

2. See above.

3. Unit animations (which is, to be perfectly clear, what we're really talking about here- these would be specialized "units", for all intents and purposes) do not eat that much in the way of CPU. We can watch literally hundreds of animation steps being performed on screen, all at the same time, without any real problems- the CPU load is low, and it has a very minimal effect on a GPU's ability to render the frames, if any.

If somebody wants me to build a test animated model to prove some basics there, I'll be happy to do so- I'm sure that we can have a script moving 1000 sub-parts at once without real framerate problems.

Now, are these sub-parts going to do anything ... erm... complicated? No. They'll just be moving on paths, show, hide, or do things like fall, shatter, etc. No worse than a bunch of units blowing up, and that's in a worst-case scenario- a really complicated event (like, say, a proper nuke animation). Most things will involve maybe twenty particles with transparent textures on them, and they will do some pretty simple things- move out on semi-random paths, decellerating as they go (simulating, very roughly, air friction/gravity) and then will FALL, SHATTER, SMOKE, or whatever is appropriate... or just disappear. There's really no technical reason, other than whatever burdens transperency will add to the engine (which, given how well the water works, I suspect will be just fine).

Now, do I *know* that this will be a piece of cake? No- I don't know if Spring has major problems with its rendering design that would make transparency a really big coding job. But, given that it's OpenGL-based, I'm guessing that it mainly hasn't been put in because other things have been more important. Even without transparency, though, I could make some pretty kewl explosions that just used solid objects and SMOKE, FIRE, SHATTER.

[Guessmyname]

OR...

we can let modellers add sprites to s3o models

[AF]

hmmm, I thought the cob system couldnt handle strings in the ordinary lua/c++/java sense.

Whatever tho, chris han seems to be a hankering for soemthign to do to the engine, mail this to the BerliOS mailing list and ask him specifically. Either that or he'll be busy figuring out stuff related to shadows.

[jcnossen]

Using COB's and s3o to do particles sounds like quite a hackjob to me, and spring has enough hacks already. Why not spend time on connecting a proper scripting language to a particle system instead of connecting it to the COB scripting? I doubt it takes more time than hacking it into the COB system.

[AF]

A lua interface rather than cob would be especially useful. It'd give us nice SupCom support when ti rolls round, a much more modern interface, and if I'm not mistaken, there's a cob->lua conversion tool I saw uploaded to fileunvierse if I recall...

[Argh]

<shrugs> Sorry if that seems like a bad idea... it just seemed, to me, that we already have a working animation system, a working model format, etc... it is a kludge, and I'll be the first to say, that it has certain major disadvantages, such as the fact that it would not be capable of certain kinds of transforms. Scale immediately comes to mind- it was one of the chief flaws in COB/BOS and I can't wait for a replacement, if that's where we're going with this. I know, I know, that was being actively discussed awhile ago, so I'll just shut up and wait

[jcnossen]

For clarity, there is nobody working on this right now :/
However it's always better to choose the proper way than to hack something in. In either case it's not going to be done soon I think, but the linux developers are more and more getting into doing non-porting things, so development of the actual game is going to speed up in the future hopefully.

[Argh]

I agree, it's better to avoid a kludge when possible. That said, a scripting interface and some sort've idiot-proof particle system sounds like a lot of work to me. It's gotta be fairly idiot-proof, too, or idiots like me are never going to figure out how to make neato effects

One thing that has occured to me is that it might be very desirable to incorporate whatever develops into Spring in a way that would make it possible to preview it. I dunno how you folks developed the current particle FX, but I suspect that the answer was, "lots and lots of trial and error".

The second thing that occurs to me is that we're going to need a lot of controls available via scripting if this is going to be all that useful- part of the reason why I brought up using COB in the first place. If COB is going to be replaced with BOS-->LUA, though, and particle FX will obey the same transformations, then it might be all right... although there are a number of issues that come to mind:

1. We need dynamic sprays, both ones that obey and ignore gravity, that will take a vector, or better yet, a vector-over-time.

2. Particle FX need to be able to call a S3O object. This for things like complex explosions, where we're going to want specific greebles to be propelled out from the model at semi-random speeds and trajectories.

3. We need the ability to call RGB values and change them over time.

4. Lastly, we need some sort've parent-child relationship, or certain things will be a royal pain to code. For example... if we want to scale a central explosion up, but have smaller particles in a ring around it, ala the super-kewl nuke animation that Supacom has been showing off, then we're going to need a way to parent things, to keep the effort of building these things in the "reasonably do-able" range.

The more I think about this, the more I think that if the COB/BOS scripting language was just made the language for describing things that move... and if we could remove some of the suck inherited from TA, like the lack of scalar transforms, a non-intuitive way of determining the spatial position/vector/speed of objects, etc... it'd make more sense to build particle FX as a "S3O" that would consist of parent/child points that would spray particles out with various properties while executing a timed animation.

[AF]

Sounds like your just the person to think up a new lua itnerface, then leave it to the rest of the developers to integrate it into luabind and the rest of spring.

That and considering ti could just as well use the same sorta class style itnerface that the lua missions use and the same vm and then you could hand over as a callback function that same callback the misisons get and cross communicate and do things a basic groupAI can do inside a unit script....

[Argh]

That would involve me understanding LUA a lot better than I honestly do. And I'll be the first to say that my advanced math skills are absolutely terrible- when it comes down to nuts and bolts, I'm going to be fairly useless.

At the very least, I think I can do a series of pictorials and descriptions that might lead us somewhere useful. I have some very specific ideas about the kinds of transforms and motion controls I'd like to see available. A few of them are things that ... for lack of a more humble way of putting it... I've been wanting to see done in a simple, straightforward way in a game engine for years, and have ideas about how it could be done simply, but nobody's done it. It may be a waste of time- I suspect that the developers are hard-pressed just getting the code porting done. But what the heck- it all worked out, in the end, with AI, so I might as well put forth some ideas.

<starts new thread>

[AF]

lua style syntax is close enought o c syntax already and the combinations of extra syntax added to the interpreter and #define statements could make it more user friendly for BOS veterans.

But essentially if you know C you could pickup a basic lua script given examples, for example look at how the example mission script is formatted.

Of course you could then go into more complex lua things, things I dont udnerstand, but have not existed in BOS and arent currently used in any lua mission for spring I've seen, and would be too complex to bother with anyways.