CegTag!

CegTag!

Discuss the source code and development of Spring Engine in general from a technical point of view. Patches go here too.

Moderators: Moderators, Moderators

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

CegTag!

Post by Argh »

Ok, so, how do we use this?
enable weapon-projectiles able to spawn CEGs (makes most sense
for missiles, cegTag still needs to be added to WeaponDef)
I mean, do we have a timing function, whereby we can call the CEG over and over again? What about vector control? Is dir == normalized dir of the weapon projectile?

Obviously, this is giant great news, and I'd like to know what we're going to be able to do to control the behavior of this code!
0 x

User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

Look at KP Div Zero. The CEG is spawned once per frame, dir is the dir of the projectile.
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Ok, but what if, for optimization purposes, we just want it to be once per 3 frames, or whatever?

And is there now a method whereby we can tell Missiles to not draw their tails at all, replacing them with a per-frame CEG?
0 x

tombom
Posts: 1933
Joined: 18 Dec 2005, 20:21

Post by tombom »

actually not sure
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Also, now that I've looked at the example, it uses the syntax: cegTag=experiment_trailS; whereas, for consistency's sake, it should probably be cegTag=custom:experiment_trailS; imo...
0 x

User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

Argh wrote:Ok, but what if, for optimization purposes, we just want it to be once per 3 frames, or whatever?
I doubt you can do anything about that.
And is there now a method whereby we can tell Missiles to not draw their tails at all, replacing them with a per-frame CEG?
Look at the KP Div Zero experiment units: smoketrail=0;
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Ok... in a perfect world, I'd like to have millisecond, unsynced timing models for this stuff... but I've already explained why elsewhere.

Basically, this works OK, so long as whatever you're doing is designed very specifically to be small on particle-count- because this causes a new system to be spawned at the weapon's origin every frame (instead of moving/turning a system's origin every frame to match the weapon's origin and vector, which I personally think would work a lot better)... you need to keep everything low on particle-count, and use some tricks to cover up the obvious gaps caused by the frame delay.

All of that said, once I got it working, it makes for absolutely gorgeous, fully controllable smoketrails for missiles, and other stuff. I think it could be a lot more efficient if it moved a single system around, but I'm totally sold on the eye-candy value- while low-end users are probably going to curse me, PURE just got the best-looking missile trails you're going to see in Spring for a little bit ;)
0 x

User avatar
rattle
Damned Developer
Posts: 8278
Joined: 01 Jun 2006, 13:15

Post by rattle »

I agree, a method to attach a CEG to the projectile would be much prefered, perhaps seperated because I can see uses for both of them.
0 x

User avatar
Snipawolf
Posts: 4357
Joined: 12 Dec 2005, 01:49

Post by Snipawolf »

PURE just got the best-looking missile trails you're going to see in Spring for a little bit
Give me about 30 seconds. :wink:
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Image

Bring it 8)
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

Whoa! I came up with another use for this... I'll make a movie when it's ready, muahaha...
0 x

Warlord Zsinj
Imperial Winter Developer
Posts: 3742
Joined: 24 Aug 2004, 08:59

Post by Warlord Zsinj »

What sort of processing hit are you looking at with that sort of particle count, argh?
0 x

imbaczek
Posts: 3629
Joined: 22 Aug 2006, 16:19

Post by imbaczek »

Argh wrote:Image
:shock:

win!
0 x

User avatar
Snipawolf
Posts: 4357
Joined: 12 Dec 2005, 01:49

Post by Snipawolf »

Alright, as soon as I get back we'll see what I can make! :twisted:
0 x

Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Post by Kloot »

Argh wrote:...this causes a new system to be spawned at the weapon's origin every frame (instead of moving/turning a system's origin every frame to match the weapon's origin and vector, which I personally think would work a lot better)...
That isn't possible without more invasive surgery,
CEG's do not keep track of particles after they're
spawned (so slaving their positions to that of the
projectile during subsequent frames requires a
bit of administration code that I wasn't interested
in writing ;)).
0 x

User avatar
AF
AI Developer
Posts: 20671
Joined: 14 Sep 2004, 11:32

Post by AF »

However if you're worried about the specifics and need uber fastness, I'm sure a lua version could outperform and out visualize that sfx while providing you with what you wan't, and only what you wan't. Of course we'll need to be able to see projectiles in lua first before thats possible.

That pictures pure win though ^_^
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

That isn't possible without more invasive surgery, CEG's do not keep track of particles after they're spawned (so slaving their positions to that of the projectile during subsequent frames requires a bit of administration code that I wasn't interested in writing Wink).

@Kloot:

Yeah, but I'm pretty sure that, in terms of efficiency, it'd be well worth it. The big CPU hit with these systems is the number of systems that are "alive" per game frame... not the particles who are acting out their deterministic math per frame. I don't know why this is- I assume it has something to do with reading all of the data into the system and creating the initial model in memory, but I'm too stupid to know how that works at the deeper levels- I just know that I can create hundreds of particles from one system, and it's significantly faster than a series of co-existing systems which together produce fewer particles. I don't have firm math on that, or anything, but it's roughly 2/3 to 1/2- it's a big hit, in terms of performance. So, if the CEG stayed "attached", it'd run significantly faster, even with the same total particle-count.

Lastly, while I have your attention, I should also mention two more things that favor a millisecond, desync timing model:

1. People could de-syncronise their particle systems by a millisecond or two, so that the CPU hit would be distributed over larger amounts of time... while Spring is using the CPU between game frames, it's probably using far fewer cycles at the tail ends, frankly.

2. I've had to do a bunch of funky, mathematically-complex stuff with that missile trail, to make it work that well, forcing me to use a CSimpleParticleSystem. If I could call the CEG every 5-10 milliseconds instead, I could just use a HeatCloud, which has maybe half the CPU impact... oh, wait, duh, HeatCloud doesn't support ColorMap <slaps self>


@Warlord:

The CPU hit is significant- you don't get eye-candy like that for free. It's not awful, mind you, but I wouldn't want to see 50 of these all firing at once.

How nasty it is depends on a lot of factors, however, which is why I keep talking about the issue of timing- like far too many things in Spring, everything in CEGs happens exactly every 1/30th of a second, and there aren't any ways for game designers to spread that out and distribute the load. In COB, we're allowed to do that, which is why most of the animation code I write has small randomization, even in cyclic stuff, like walk-cycles- even a millisecond is practically forever, for a modern CPU, and why make everything pile onto the first millisecond of a 33-millisecond slot of time?
0 x

User avatar
KDR_11k
Game Developer
Posts: 8293
Joined: 25 Jun 2006, 08:44

Post by KDR_11k »

You should make those smoke particles move around randomly a bit to make the smoke fan out more.

Personally I think that smoketrail is overkill, looks more like burning debries than missiles.
0 x

User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

Problem is that if you make it attachable to projectiles, you get a lot more z-order problems as well. This is probably also why you get a large slowdown with more systems: the systems are z-sorted but the particles aren't.
0 x

User avatar
Argh
Posts: 10920
Joined: 21 Feb 2005, 03:38

Post by Argh »

@KDR:

Actually, I tweaked their lateral acceleration in the final version I made, so that they do, and added more randomness to their growth and changed the lifetimes as well, to add more funk to the code... simulating complex systems like that is too much fun ;)

As for the aesthetics... well, I could go for more of a flat gray, I suppose. It was just so nicely dramatic the way it was written...

@jcnossen:

Yeah, I figure that the z-order issue is probably a major problem. I've already said, though, that I think that having non-z-sorted CEGs, for some situations (iow, allowing for constant overdraw) is not a bad thing... the only time it's a problem is in situations where one type of particle's alpha-blend is going to produce really ugly results with particles that are drawn before or after it, frankly...
0 x

Post Reply

Return to “Engine”