Vehicles Feel too "Floaty" Missing Details

I agree that's a really strange design discison. Makes me wonder if the lack of other graphical features are design discison as well...

There's even more trouble...

For instance, any form of tracers or trails works only while you are looking at the particle emitter. Move the camera, move back, and the tracks have a gap in them.

That bug was most prominent with the nuke tracers which had clearly visible gaps in them, but it should also affect any other type of comparably long lasting trail or tracer.

Unfortunately, PA's engine isn't made to properly support persistent scorch marks, trails or anything like that. At least not without severe implications for performance and not without relying purely on the client state (what the client has actually seen), rather than on the actual sim.

I thought the engine was able to bake decals into the texture, thereby having no sim impact at all?

We can bake decals, but they still have a cost, mainly in (minor) bandwidth, overdraw costs when re-rendering the virtual texture, and more subtly (though perhaps most impactfully) in history server costs in determining which decals each player can and cannot see. Also because of the nature of virtual textures they are either on or off and can't be faded in or out with out significant rendering overhead. Adding thousands of additional small decals for tread marks was ultimately unfeasible, though it was part of the original intent of the system.

Specifically it's if the unit or projectile is in your view or not. Anything outside of your view is culled for saving bandwidth.

I have to admit, with large armies I did notice a bit of slowdown; my computer is also really quite old, but still pretty average by todays standards - however it kept stuttering, which would cause a break in any of the vehicles tracks in addition to the other issues. So, from that standpoint I can see why it wasn't included! A shame though. I suppose you have to draw a performance line somewhere.
Out of curiosity, is it just that string particles aren't the best way to go about doing that sort of thing? I normally dislike saying this but I swear I've seen that sort of thing in other RTS games?

I imagine there are other ways to create a less 'floaty' appearance to vehicles, (i suggested a bouncy suspension anim), but resource-taxing issues aside consider the look of 20-50 tanks all leaving tracks, trust me it will look hideous especially when the tanks can't even be seen themselves. A small dust trail might be better?

You mean the server needs to tell the client what decal to show where? Cant the client determine that by itself based on the events that create decals? I would have thought stuff like decals is just client side, like animations.
Also on the topic of decals, do the explosion scorch marks count as those?
Long ago I read of the baking of decals and thought "awesome", but currently even explosion scorch marks seem to disappear after a while (I think?) and with no unit wrecks we are pretty far away from leaving lots of traces of destruction everywhere and planets look way too clean to me.

I dunno they are different games. MoW2 is trying to be ultra realstic and has a lot more units. CoH2 trys to find a balance of realism and gameplay (for example hmg's don't fire two screens across the map). CoH2 also feels a bit more polished to me, with much better online play. MoW2 plays a lot like Worlds in Conflict where you can't really build things but has bigger maps and terrain and has larger scale battles. CoH2 has a stronger narrative and single player campaign. MoW2 has horrible voice acting and sound as well. I prefer CoH2 but to each their own I guess.

Yes, it could be done client side, but then we'd have the same problem of the treads only existing for units you're currently viewing. Tread marks handled by the server could show you unit movements after they've disappeared.

And yes, scorch marks from unit deaths, explosions, and nukes are all decals. Basically anything that's on the surface of the planet is a decal. And we originally gave them infinite lifespans, but started seeing problems late game in areas where battles happened frequently due to rendering the virtual texture tiles becoming significantly more expensive late game. The easiest solution was to give them a lifetime rather than some kind of max count per tile.

Before my post I did a rough on the envelope calculation for say 1000 vehicles (since we need to track all vehicles independent of visibility unless we wand gaps within the traces this seems to be reasonable) with an emitter rate equal to the sim rate of 1/10 sec and a life span of 30 seconds. Using transform feedback, which means all particles had to go through the GPU at least 2 times, with 60 fps, and a good margin of unknown factors, I ended up somewhere in the ball park of 1 GB/s for the vertex data alone.
Yes, nowadays 1 GB/s is really unimpressive compared to the 320 GB/s on an AMD R9 290x, but it impressed me a bit (Well, I stopped doing Open GL things somewhere between the time of 2.1 and 3.x)

That said, it would be intressting if you had some numbers on how many particles you can process with your engine on 60 fps until you see a slowdown on some recent graphic cards.

Our particle system is done by calculating all of the positions and movement on the CPU, and storing that data in a shared memory 16 bit float texture that the CPU can write to and the GPU can read from with out having to do explicit OpenGL texture manipulations. Different particles have different data stored, but a basic example would be planet position, 1 axis rotation, size (x and y), and color (RGBA). That uses 3 texels of that 16 bit float RGBA texture. String particles on the other hand need to know the position of three points (beginning and end of each segment, plus one more to line up edges), and the color and size of two points. That's at least 5 texels, plus one more for UV info so a minimum of 6 total. Now we could save some bandwidth by just making sure the particles are stored in order and read the data for the next particle, but that limits how we handle the data a little and requires some special cases on the CPU side that might end up being slower than the memory bandwidth costs.

A question I wanted to ask for a while now (and I can't remember if you have anwsered it yet):

Is visibility towards a certain faction a sticky attribute or is it evaluated every time the replay server is asked to deliver a frame?

If 2nd, why not 1st option? After all, evaluating visibility towards a certain faction appears to be a rather costly process, even with the search tree and bucket lists. And storing up to 3 additional booleans (visible, identified, tracked) per faction in play shouldn't be that costly either, especially since a change of these attributes is actually meaningful and determining visibility towards a certain player at a certain timestamp has now the same cost as a regular lookup to any other attribute.

Plus, there are legit use cases in which visibility of certain objects shouldn't be subject to a purely static analysis. Such as when you already had vision (once!) on a certain object or feature which is known to be static. Or non-static, but you had uninterrupted radar tracking of that feature. Not exactly possible if visibility is stateless.

Right now, even if the server were to store trails, they would be only visible in the client (and persisted in the texture) if, by chance, the client had the right view port WHILE a unit could have seen the tracks. Which makes them somewhat pointless either way.

Right now, your scout could have scouted a nuke explosion, but it you didn't had a viewport open (or used the Chronocam), you wouldn't even see the scorch mark until you had vision on the explosion site again.

PS: Oh, and yes. I'm still hoping that at one point, I can just implement my own intel system as a server side script which may just iterate over the unit base and set those flags by hand every few frames or so. No more hardwired functionality in the replay server...

I feel like a lot of the issues of computing power would be solved if:

a) units built a lot slower (somewhere between TA and SC building speeds)
b) units had more hp (to make up for slower build speeds)

I mean, do we REALLY need huge zergs of units at the cost of all these cool improvements? Does it really add that much to gameplay? I'd argue TA is just as fun and enjoyable if not more so.

Ah... having the client be a stupid "I show exactly only what you can see right now"-kind of program has more consequences than I thought about until now. I already noticed that you only really update the stuff visible to the players viewports when I was trying to reverse pa.exe and get the location of all current units the player owns for my minimap project. I was not pleasantly surprised to see the unit locations stopped updating the moment I moved the camera away and started again once I put the camera over them again. Could not figure out where that was decided. My assembler knowledge is just too bad. Maybe one day I will write a mod that opens a bunch of small pips that make every part of the system "visible" all the time to the player to get rid of your optimizations and get stable data on stuff.

I guess the scorch mark lifetime is a server setting (or probably worse a constant somewhere in the code) that is active for all clients? So it can't be configured? I really hate scorch marks that magically disappear, I was so happy when I read of that virtual texturing stuff for the first time.
Even worse I already know in a few years we'll be all sad that our super "from the future" gpus and cpus are bored with PA and we can't enable scrochmarks to stay forever because it is a hard coded lifetime. Well if it is a single number somewhere in server.exe we might be able to patch it. I hear they patched some crazy things into ta.exe as well...

It's both. Units on your team (or an alliance) are sticky in terms of recon visibility. Enemy units are not fully sticky on the sim, but they have a few states for if you've ever seen a unit or not and in what state the unit was in when you last saw it. The history server is just playing back the data the sim gives it with a set of vision flag masks; ie: "I'm Team 3, what did the sim say Team 3 can see?" So really to the specific question of the "replay server" (history server) it's sticky. There's an additional per tick update on the history server to frustum cull units outside of the client view that is applied to the final list of visible units. The client also does a vision flag pass on the data it gets from the server since in a replay you can switch what team you're seeing, but the data for anything you've already seen is still saved locally.

Well the advantage of the server tracking this rather than purely client side is it could say "here's the tread marks you didn't see happen".
The nuke explosion scorch should actually show up if you recon an area that's been hit by a nuke even if it wasn't on your screen at the time it occurred, but you have to get vision of the center of the nuke impact. While the nuke effect itself is visible to all clients, the scorch mark still requires vision recon.

Scorch marks have a lifetime in their .json file, and is (mostly) controlled by the server. The scorch from burning trees is actually a client decal though, so I think modifying that on the client will just work.

Now I feel like a horrible pessimist. That's really well made then, so I guess we could even make a server mod for it right now xD

Ok, so in theory it should be possible to override the default intel system with a server side mod as soon as the following features and made accessible in the server side API:

• Add externally settable visible flag (precendence over stock sim visibility test)
• Add externally settable radar blip flag (precedence over stock sim visibility test)
• Give public access to method which currently performes the visibility test
• Give public access to an iterator of the entire unit base

Ok, latter one probably already exists somewhere in config.army.sim, but I have no clue where since I can't debug native objects.

I'd be very very interested into that, so if it exists please somebody tell me.
From my understanding it has sim.units which is where it just adds units to cheat spawn them. The commander is also spawned like that. However normal units were not in there last time I checked.

Found it in playing_shared.js at the definition of the spawnUnit method.
That thing is apparently supposed to be a list of references on units. If the unit is gone, the reference turns to "false".

However, I have no clue what attributes units have as they are not used anywhere. Unit controls appear not to be written in JS either.

EDIT:
I would suggest that we ask for another livestream, but this time one which focuses on the server API so that we can finally start the real modding.