Features, customability and Death

[Argh]

First off... it'd be darn nice, if you could turn a Unit into a Feature.

No, not like we do now, which isn't great, because it resets the COB.

I mean, just plain tell Spring "hey, this is a Feature now, don't move the Pieces, don't change anything, but quit running a Unit thread in COB".

Secondly... when Features die, currently they either change into the next Feature down the line, or they disappear. That's all.

My question is... would it be possible to make it so that we could have any alternatives? I was thinking, if people wanted to keep it really simple, that we could just specify a line like:

featureDeathMode=FALL; where all non-null Pieces then perform a FALL event.

Even better yet, specified actions:

[featureDeathEvents]
{
base = SHATTER;
bigrock = FALL;
}

Which would be great, because then we could have fairly detailed death events for Features. Just thinking out loud here.

[smoth]

or just allow us to use a unit as a feature. :) maybe I am missing your point

[Argh]

Well, yeah. The main differences between a Feature and a Unit, IIRC, in terms of CPU load, is that Features all use exactly one way to handle LOD distances, and they don't run COB threads, and they don't update LOS maps (although I'm pretty sure Units with SightDistance of 0 no longer do- er, at least, they should).

I'd be willing to trade more flexible LOD handling for COB, in a lot of instances, but only after I've placed the Pieces in the scene. That way, I get the efficiency of lower total counts, and the randomness, but I don't have the issues with total efficiency.

[Gnomre]

Attaching a CEG to feature deaths would be better than nothing at all, but more control than that would be nice.

On a related note, I haven't tried lately, but I thought multi-piece features didn't work? They used to only display the root piece and ignore all children, but it's literally been years since I checked that one

[Argh]

Yeah. Y'know, one alternative I thought of is, just have the ability to shut off running the LOS handling for these things entirely, and leave 'em Units. I'll bet that, if the COB is idling, that's most of the load.

[lurker]

What do features do with LOD that you like?

[Argh]

Actually, I don't like how they handle LOD. They're all tied to that global variable governing Unit distance. If I could modify that, so that some things pop in sooner than others, and some never ever pop out, it would be a lot closer to ideal. That's one of several reasons why everything in World Builder is a Unit- I can control it directly, and it has a huge impact on performance. That, and death events, are the main reasons why- after all, most World Builder objects are just doing the work of Features.

[yuritch]

On a related note, I haven't tried lately, but I thought multi-piece features didn't work? They used to only display the root piece and ignore all children, but it's literally been years since I checked that one

They do work now, as in all the pieces are displayed. At least it's this way for unit corpses.

[AF]

Rather, perhaps it would be better to allow specifying null for the cob file and then the engine interpreting that as 'don't run a cob thread for this unit', which would be a much more useful feature.

[lurker]

argh: thought you were saying it was a tradeoff. Is there anything you like about features?
AF: In svn you can specify any cob file you want. Just make a generic one that only has create() {return;} killed() {return;}

[Argh]

Is there anything you like about features?

Yes. Sorry if it seems like I'm only hatin'. Here are the things I like about Features:

1. Chained death behavior. I.E., X dies, become Y (with proper rotation).

2. Shadow treatment. For whatever reason, Features get drawn by the shadowmap code with transparency working, but Units don't.

3. No LOS checks, period, and no COB thread at all.

4. Can be reclaimed automatically if you need to build on top of them.

That's about it, though. With what I'm doing in World Builder, I get much more flexible LOD behavior (from "pop in only if the camera is close" to "never ever hide") animations so that I can procedurally modify the object prior to freezing it (which means that one object repeated many times can end up looking unique every time, adjust to terrain, etc.) death animations, Lua event handling, Yardmap flexibility, animations period, access to sound and CEGs... etc., etc., etc.

Basically, though, what I've been wanting is some sort of middle ground, for the many, many objects where I want to do some stuff with them early, then not do anything unless they're dying.

All that I think that would take is correction of the shadowmap behavior and treatment of sightDistance=0; where the LOS handler never does anything with them (a substantial cost savings- in tests, even when set to 0, the Unit seemed to have the same CPU costs as one set to 1).

I think that (er, and the whole FALL stuff I was ranting about earlier) are the last giant wish-list items I have, for World Builder stuff that's as flexible, fast, and optimized as we could reasonably expect. A COB that does nothing after Create() is not a huge load- the LOS stuff, in particular, is the largest element of load for these objects.

I made things somewhat better, by declaring that *they* are always in LOS, but it'd be really nice if *they* never check LOS themselves.

The rest of the advantages of Features are all Lua-able, and my own laziness is the only obstacle

[jK]

COB will be replaced with Lua someday, so there will be technically no difference between units and features anymore. I am working on the first step into that direction (abstracting 3d model classes) and trepan did the other step with LuaUnitScripts, but it seems he will never commit his stuff, so it will take a bit longer.

[Argh]

That would certainly cure that problem, yes.

However, if you're going to tackle that, instead of writing a COB parser and basically reinvent COBHandler in Lua, I'd suggest that perhaps we should have a mini-confab about this, propose the final feature-set, and have something entirely new instead.

BOS is great, I like a lot of things about it and I'd like to keep a lot of how it works, but it lacks a lot of things, and I think that porting in COBs just locks us into a dead-end model, as there is no serious interest in building a new Scriptor, so we're locked in terms of features.

If you're not interested in that discussion, feel free to ignore me, of course, you're proposing to do a great deal of work... but I think that if you're going to do something that massive, then it might be better to see this not as a port, but as a new animation system that bears some resemblance to the old one, and just let the existing code continue to be available for old Unit support.

[AF]

Argh, when lua replaced TDF, we weren't locked unnecessarily into using only TDFs were we? What makes you think there wont be such a thing as pure lua animation scripts?

[lurker]

Los math already 1. doesn't run if 0, and 2. doesn't run for anything staying still unless there is terrain deformation in range. And a cob instance with no active threads has no cpu load an close enough to no memory impact.

Basically, though, what I've been wanting is some sort of middle ground, for the many, many objects where I want to do some stuff with them early, then not do anything unless they're dying.

break; from the loop. Done.

Death behavior can be done with 10 lines of lua. Reclaim would need fancy engine work. I have no idea about the shadows.

[jK]

@Argh
No one said something of a lua-bosparser, nor of removing cob in a foreseeable time. Also like I said since trepan left spring dev. neither the lua part won't happen in a short period of time ...

@lurker
It is #2 on my todo list.
It is cuz unit rendering deactivates any shaders when rendering in non-onscreen buffer. IIRC there is a note in the source that says it caused glitches when it was wrote. Still the reason doesn't matter anymore, shaders are even faster than FFP today. So I will redo the whole unit rendering system and translate the shaders to glsl.

[Argh]

Reclaim would need fancy engine work.

Nope, I already have area-reclaim of Units implemented in Lua in P.U.R.E., as of RC1. Only "problem" is building a return if-->blocked-by-unit and not-my-unit then reclaim-that-unit and then build. Not a problem, actually. You are correct about the LOS comment, you're right, I was incorrect. It'd been awhile since I actually tested that.

So, pretty much there's no reason to use Features at all, aside from the shadows, which I can live without.

Their only real advantage, ever, was performance-related, and if anything mine perform better under most circumstances already, because of the improved LOD handling. I guess there there are just fundamental limits on how many separate objects one can have Units interact with in terms of their LOS states, and that's that.

I might have to lower the LOS on stuff in P.U.R.E. to make complex scenes perform better (or play with the LOS stuff again, raising the size of the squares); early tests with the newest materials indicate that there are non-negotiable limits imposed, when enough actors are in a gameworld. It's like hitting a wall, CPU-wise. I'll go do some experiments and see if there are any good options, I'd hate to have to cut LOS distances down and rebuild the entire game design over something this basic, but <shrugs> gotta do what ya gotta do.

No one said something of a lua-bosparser, nor of removing cob in a foreseeable time.

Fine, fine, I'm just thinking out loud. The real question, imo, is whether Zpock ever lets us see the MD5 thing, and whether that makes this basically irrelevant.

While I'm on that topic... is there any particular reason why everybody just let my post of that TBN stuff fall off the face of the Earth? From what I was reading, it looked straightforward enough to put into Spring, and it's a necessary step, if we're going to continue to push .S3O until it's replaced by Something Else.

[lurker]

Was it unclear that by reclaim I meant 'the autoreclaim argh just mentioned' and not 'area reclaim that no one has mentioned in this thread'?

Looks like the current LOS mip level in PURE is at default of 1 for normal and 2 for air. Follow CA's settings of 3 for normal and 4 for air and updating the los map could be up to 50x faster.

Edit: Interesting, you made a post once claiming you were changing the mip level, but you have it back to default now. Even if you don't like the resolution of 3 like you said, 2 is still going to be ~8x faster. One quarter the area, half as many updates when moving.

[Argh]

Was it unclear that by reclaim I meant 'the autoreclaim argh just mentioned' and not 'area reclaim that no one has mentioned in this thread'?

Er, I'm saying that auto-reclaim is just a couple more checks- if building is the current order, then check, if reclaimable Unit under, then reclaim. Can't CommandNotify() intercept a build-a-building command at the halfway point, before it's formally an Order? Or am I wrong, and there isn't any method to get that point between hitting a UI button and providing it with the parameters it needs?

Looks like the current LOS mip level in PURE is at default of 1 for normal and 2 for air. Follow CA's settings of 3 for normal and 4 for air and updating the los map could be up to 50x faster.

Yes. I disabled all of that, after having all sorts of major issues with it back... sheesh, that was like, February, or whenever it was.

And I never turned it back on. I guess I'll have to correct that, and see what performance looks like afterwards It'd be hilarious, if that was the only thing holding back the density of practical World Builder scenes.