I've been playing this game for quite a while with a fantastic computer. however a friend of mine can only barely play with his crappy notebook. I figured that the easiest way to increase the performance would be adding an option so that the game doesn't render models, but rather only uses the floating icons. Perhaps it could use basic boxes for the buildings, but for the units, get rid of the model altogether. Is there any way that someone could create this or has it already been done?
Not to mention that the game uses a lot of cues from the model for things like targeting and what what not, you could make simpler models but I don't think you'll get much of a performance boost if any. Mike
Wait. If one had "client side models removed", but server still used models, wouldn't the server still be able to make weapons function from empty air? Then just modify how icons show up, mainly that they always do. That just reduces the game 2-d. However, that is still limited performance increase client side, might not do much indeed.
It would depend on how the server works exactly, remember this setup isn't the same thing as OnLive and other remote gaming services where everything is done on the server and only the video is sent to player,as far as I can tell from my limited knowledge the Server takes a lot of cues from the Clients and if the client doesn't set bits of info it could fall apart. It all depends. Mike
Server doesn't use models. It only uses the parts of the animation tree related to aiming and apart from that only a cuboid collision box. That's it. Looped animations and model come from .papa-file. Animation tree for aiming comes from .json file. Client does nothing more either. Every animation not related to aiming comes from the model files, empty these and all "unnecessary" animations and models are gone. You also might wanna remove/lessen particle emitters wherever these are used in unit or projectile json files. Probably won't save THAT much though. UI should already be lag free with latest PTE, so...
To my understanding, the aiming stuff listed in the json still relies on the model to some degree as well, the json might specific what bones are using for aiming, but the model still holds the data on where those bones are in relation to each other. Mike
If it is also to be added, that most the "struggle" for a computer to run the game, is universal for every computer, and that is the "serverside". Even godlike computers get 12fps. That is because, the server gets 12 fps. It runs 8 games per server machine, unoptimized. It may be way possible to run 20fps on low end machines and locally, without the cap of serverside as it is currently. A lot of "speed up" isn't client side. People fester on that, and festering is never a good thing, there is no good kind of festering. A lot of the speed up will occur without the need for durastic measures. Unless, you are running 3g ram and integrated graphics, in which case you need a server machine to play on to take the weight off your machine, or you may get by with tweaks like suggested very unlikely but possibly.
I'm not really sure about that. It looks like projectiles don't exactly come from the corresponding bone, that's only where the particle emitter is attached. It appears as if all projectiles come from the center of the collision box for smaller units. And it's not even like the server would need to know about the offset or the hierarchy of the bones either, if you take a look at the anim tree files, you will see that it is specified which bone should be used to aim along a specific axis. So the server can treat the skeleton as a flat list since is does neither need to know about the position nor about parent of any given bone.
Yeah, just tested that myself, and it looks like it isn't the center of the collison box. There is "socket_" stuff where projectiles appear to be spawned. But I don't see any indicator yet that these socket positions would be transformed according to any bone alignments. Projectiles appear to spawn just outside the collision box projected from the untransformed socket position. Very apparent on the commander where the Uber canon is not fired from the either arm when the upper body is tilted.
The projectiles do very much correspond with bones. Other than watching unit such as the Battleship, this was particularly evident prior to server modding, where replacing a model client side wouldn't change where the bone was according to the server, causing the projectiles to still appear where the original models' bones were. What the server doesn't track specifically is animations - factory open/close, aiming (it tracks the bone movement of the weapon, just not any corresponding animation, such as on the Pelter/Holkins). Some of the server's collision and other info is taken from the model, others from the blueprint (there's a field called "mesh_bounds", from memory, that has X & Y & Z values). I'm not sure which is used for which calculation.
The server pulls initial bone offsets and orientations from the skeleton. That data is used to calculate firing trajectories and to create projectiles. However there are no animations of any kind on the server. No walk anim for bots. No aim blend for the commander. And so on. If the server loads a modified skeleton that will impact the unit and it's behavior. A simple client side performance optimization would be to replace all anim trees with a bind pose anim tree. Units now have no animation of any kind. You saved some CPU cycles, hooray! Ballistic projectiles would look almost normal. The projectile will be created in the correct location on the server, it just won't line up with the client side mesh visuals. Some effects would look a little silly, such as the commander fab spray or muzzle flashes. Anything played from a bone will be in the bind pose location. A lot of the units just use a bind pose blend tree with some simple procedural animation. Anim wise the basic T1 tanks just applies turret yaw and pitch. That procedural bit does require some cycles so for extreme optimization turning it off would help. Particularly late game when you have 1000 things on screen animations. One note is that Varrak is working on some client side multithreading code that will help quite a lot in this area. Animation is something that very much can be done in parallel. Once the work is spread across a few cores the benefit from turning it off will be diminishd.
