A couple of Radical Ideas

[Argh]

OK, so y'all know, I'm playing around with FBOs and GPU-powered systems and stuff. Yay, go me, re-creating crap trepan worked on over three years ago.

Couple of things have occurred to me, just based on stuff I've seen, in terms of what works.

1. We can and should build an animation system that interpolates sets of animations and stores the resulting display lists in memory. We can then use a very short CPU sequence to determine which display list to display this render frame, and use a shader to place and orient the model in the global coordinate space. Interpolation of the display list is not that big of a deal (if it's all one object, mind), and most cases can be built before the game state starts and stored beforehand, anyhow. Yeah, yeah, we lose procedural stuff, but it just doesn't matter that much, very few things in a Spring game are actually using real procedurals right now because of the CPU overhead anyhow.

IOW, let's just skip the whole pain of building an IK system into Spring. Fine, that's not ever happening. No problem... just store states with a given piece-name in S3O, for each major state, build the logic linking them, store the states, done.

It's stupid, in this day and age, to use the CPU to perform most of this, when we can use a 'physics' shader and store the result in a FBO. Modern engines clearly don't do that any more, for systems where they need to deal with hundreds of objects on the screen (i.e., CryEngine et al).

The implementation of a agent-based particle system that is mainly run on the GPU, in short, can probably be used to greatly speed up the placement and display of objects in the gameworld. I will probably write an experimental exercise to that effect with Features, just to see it. But I already know that offloading many thousands of calculations establishing position, orientation, etc. to the GPU is 100% doable, and quite cost-efficient, and would greatly speed up the engine. We could almost certainly do point tracking and simple intercept solutions this way, too (i.e., very basic weapon support logic that would at least give us an "in the ballpark" range for doing bigger tests).

2. The same goes double for maps. I am fairly confident that a splat-based format can be built, using FBOs to store splat locations and pre-built display lists. IOW, the "crazy" idea I proposed awhile back can and will work.

What I've figured out, basically, is that polycount is not the problem, neither is it the size of the textures (within some reasonable bounds). GPUs are designed to crunch through both with ease. The major problem is getting the CPU the hell out of the way, mainly. SM3's major defect is that, in the end, it's requiring far too much CPU time, to handle everything. We can and should develop a solution. It will not be something that runs on Intel 945, unless somebody wants to write an old-skool workaround using ReadPixels, et al to do it on the CPU, but whatever.



Only the splat display lists in an Explosion's radius would need to be rebuilt, so even that cost can probably be handled, and almost certainly evaluated on the GPU and returned as a shader result (i.e., I think it's possible to compromise on that one feature, which seems to cause so much of the balking on modernizing how we draw maps).

I do not think that the depth-tests per splat are a significant issue, given how few will intersect each other (and the fact that CEGs perform depth-tests and really are fine, with many intersections).

Again, I intend to test this out. I think I'll start with a simple test, and find out how robust LUPS is, if I adjust its current map-glow to be non-glowing, give it a depth test if it doesn't already, and then populate a map with "splats" via some sort of editing system (getting ahead of myself here, but basically, I don't want to use Units, for obvious reasons). But long term, using a several big textures that coorespond to splat locations, types, orientations (imagine, splats that can be arbitrarily turned, wow... sigh) and a shader that does all of the actual drawing, per-splat, through a display list per splat type (and, obviously, culls all splats not in POV) is doable, and should be done.

At any rate, I may sing a different tune after I've dealt with the issues, but I'm increasingly confident that we can and should start looking at the current state of the art here, and finally break the engine away from CPU limitations where it's not necessary. What I've been finding, in my shader tests, is that it's awfully hard to overload the capacity of a modern GPU. It is possible, but it takes a hell of a lot of computation. And most of this isn't giant shader stuff, it's smaller stuff all put together in a CPU --> GPU patchwork, where they both do what they're good at, and nothing else.

[Auswaschbar]

Are you going to do it?

[Argh]

If you mean, "am I going to write it in C++", no, probably not. In Lua, yeah, if I can. I am pretty excited by the various things I am seeing, messing about with these concepts, basically.

However, I can prototype it in Lua, which gives me a flexible platform for finding a good approach and demonstrating that it works, and porting the algorithms should be pretty straightforward, once they exist.

I know that sounds like half-arsed help, but I don't think there's a better way for me to contribute in a timely fashion... and if nobody picks it up, at least I have a working version in Lua for my own purposes, which others can evaluate at their leisure. Better deal for everybody, imo.

[KaiserJ]

i'd be sad if splatting replaced the current map format; sure, its efficient if you are adding specific features and decals after the fact (a la worldbuilder) but it would remove a lot of control from what you can and cannot make (or at least, thats the impression that im getting)

possibly a solution to the ugly cliff problem... make that underlying texture (the one that appears when you zoom in super close, ive forgotten his name but im good with faces) appear much more prominently according to how vertical a specific surface area is... that way, the ugly vertical lines that you see on a cliff with become individual pixels again, with a minimum of fuss. (perhaps added as a scaleable option in SMD?)

also im working on a mapping script (wasn't going to mention it as its still far off, but seems pertinent to this discussion) called "third day". it will work exclusively using dynamic splattering, and if i can get it to work the way i want, i think it'll even replace WICed as the current most awesome way to make a natural looking map.

[Argh]

Splatting does have some implications for flexibility, yes, although I don't think it'd be too bad. You can run a heck of a lot of textures through the system, after all, providing for a great deal of variety, and if they were able to be oriented freely, I think they'd be just fine. And, in terms of map construction, it'd be easier to build real-time editors for a splat-map approach. People could just import a heightmap directly into Spring, start working, and finish with a script and some special bitmaps.

Oh, and maps could be utterly tiny, too... I guess I should mention that one. I mean... really, utterly tiny. Even if you used a hundred different splats, with normalmaps, 99 of them might be from a common texture set (i.e., mappers could build and share splat designs and concepts), meaning that maps could be 4-5 megabytes in size, even for giant ones.

And lastly... beauty-wise, it'd be a lot nicer, frankly. Splats could, for example, use different settings per definition, and use a different shader to render. I.E., real flexibility, and better overall production value.

Want some glowing, pulsing ooze here? Use this splat, which uses a shader to cycle the RGB values of the fragments, and has a lower shadowmap value. Want highly-reflective metallic here? Use this splat, its shader supports that. Want an area to be team-colored, based on who started there? Want this area to have shader-built grass that waves in the wind? The possibilities are nearly endless, honestly.

They could even have a pre-built main shadowmap "burnt in" to a texture layer used during the process, so that the only things that have to go through the shadowmap process are Units, which would then pass the resulting shadowmap to the splats, for true, double-shadow effects, instead of a single shadow pass.