More human models

Servers Feedback
21

Then with a quick reply.

Possessions server, high res models inside. 125 fps

Mapeadores server, only low res models inside, 90 fps.

Do you really think that FPS results here are due to the polygon count of the models? NO.
Is FPS is more based on client predictions, that have nothing to do with the polycount of models? YEAH.

Only the hitbox and the physic hulls make a difference for the prediction part, and is CPU related. But near all models are using the same! Maybe not Mapeadores one? EDIT: no, samle too.

52 vs 42 players… For that prediction, my screens can’t be taken in account, as many players was already dead on Possession (there was still 25 players alive). But they can be taken in account for polycount, as the graphic card is making a Z-sorting and skip really fast all non visible players. Z-sorting is about 1/10000 of GC performances (even for old and low end GC).

22

Mapeadores zombie model hulls (physic at the left, hitboxes at the right)

Nanosuit hulls

23

About hitbox and physic hulls?

Mapeadores zombie

Nanosuit

So there is no load change on CPU. There are the same.

You will say to me “you have a high end pc, you can’t benchmark for a low end one” about the polycount (+ normal and specular maps). Just wait… I will do benchmarks on my server as i said, with a shitty PC and enough bots to fullfill the server…

Let’s investigate the bones?

For god sake, give me proofs more than words about why i could be wrong…

24

About the skeleton.

CSGO FBI vanilla models have:
71 bones, 61 HW bones, 25 attachments

Mapeaedores ghoul is:
86 bones, 64 HW bones, 18 attachments

Mapeadores zombie is:
86 bones, 57 HW bones, 18 attachments

I understand nothing now when you’re saying you need to port the model skeleton…
What you need to do in fact? Port it to the CSGO vanilla skeleton, or port it to match a ZE specific skeleton?

25

Ghoul and zombie use a terrorist skeleton.

26

How i’m so stupid… -_-
Thx

27

I don’t like going off character and getting upset, but you’re constructing a completely absurd strawman here. First, FPS are, as a metric, nonlinear. This means that a drop of 50 fps give you no real measure of how unperformant something is. You can read more about this here. If we assumed that your fps values are indicative of average fps (and we discounted that you are comparing apples to oranges since you are on two different maps, with different amounts of props, using different amount of plugins that add rendering load and with quite possibly far more playermodels being rendered from the looks of the radar on Mapeadores’ screenshot), we’d have:

  • 1000 / 125 = 8.0ms per frame (Possession)
  • 1000 / 90 = 11.1ms per frame (Mapeadores)

This means that for each frame in Mapeadores you can render 0.72 frames in Possession or that Mapeadores has 38% lower fps than Posession (11.1/8 = 1.388…). However, If we take into account the number of players as a crude metric, and if we thought playermodels are the only thing that matters (why would you?), you’d be expecting a 52 / 40 slowdown, that is, 1.3. Mapeadores seems worse than that, but actually, we simplified the scope so much that it means nothing.

In fact, if we are a little bit more serious and we count the amount of playermodels in Possession we can see that there are actually only 11 playermodels being rendered. CS:GO uses frustum culling, so only geometry contained within the ‘cone’ of the camera is rendered. It is a very inexpensive check, so it makes sense to do it. You can see its effects when a sprite is on the border of the camera, because it will pop off and disappear. This is because they only test sprite centers against the frustum, not the sphere (though they should). At this point the comparison becomes absurd, because we can’t really see how many players we’re rendering on the Mapeadores screenshot. However, judging from the radar it seems that ahead of the player from whose camera the screenshot was taken there are a few human players. If the players are within the potential visibility set, PVS, they will be rendered and, judging by the amount of dots (and considering there are already 6 + arms playermodels in the screenshot) there will be more than in its Possession counterpart. It would take only 10 players that are being rendered but not directly seen for Mapeadores to be performing better than expected (16 / 11 = 1.4545…), when comparing frametime loss to amount of players. If almost all players were alive at the time, that doesn’t strike me as unlikely.

Of course, this ignores:

  • Differences from map to map.
  • Differences, within a same map, from situation to situation.
  • Expensiveness of certain effects and things that Mapeadores uses (using Molotovs vs. nothing, sprays, using particles as round end overlays, all of the supporter cosmetic perks).
  • Differences in the number of polygons on the playermodels.

So from bottom to top, let’s give an estimate of overall complexity polygon-wise. I’ve joined Possession just now, having to wait 30 minutes for the download. Looking at the downloaded assets and the screenshots, I’ve listed the number of polys per model for a few of them:

  • CS:GO’s defaults: ~12K
  • Marine: 3812
  • Combine: 5123
  • Artemis: 6291
  • Unimaid: 10996
  • Octodad: 4766
  • Halo guy: 5102
  • Lightning: 30273

So in your Possession screenshot we actually see playermodels that neither make any thematic sense nor deviate too much from the numbers of polygons we have insisted on through and through during this thread.

Now, of course, that is ignoring Mapeadores’ particular setup too. In detail, Mapeadores makes use of features that may or may not affect performance, but since from the previous analysis (over data that is bogus, but whatever, let’s keep rolling) we seem to probably be fine, let’s also add up our extras:

  • Playermodel tinting, using specific texture masks (on the combine specifically) to allow for tinting + self illumination.
  • Extensive usage of non-predicted cosmetic effects through tempents (basically most of the stuff that supporters use).
  • Sprays (though decals are pretty cheap, but everything adds to the budget)
  • Molotovs, with their associated projectiles, decals and particles (though Mapeadores uses custom, less emissive particles for this and ignited playermodels)

I wouldn’t expect any of these features to eat up more than a measly 2% or 3% of the performance budget. They should be in general pretty optimized, because the target is always to have the server be enjoyable even on old setups or laptops. Beyond this, we are still forgetting map differences:

  • Different visibility setups.
  • Different prop amounts.
  • Different prop complexity.
  • Different amount of effects, cosmetic entities, etc.
  • Different amounts of expensive shaders.

Since we can’t do anything other than telling mappers not to be awful, that’s beyond our scope. Custom Mapeadores stuff doesn’t make much of an impact, as it consists of simple effects tied together to produce reasonable results – and to make the server stand out far more than downloading and installing a model would. As on those grounds the work is done (as much as it can be done without removing features, which won’t happen), looking at playermodels is important. And what do you know! Playermodels in Mapeadores, if we go by your metrics (which we shouldn’t, because they are comparing apples to oranges) are doing mighty fine because other servers agree: they are using mostly models with low polygon counts (though Mapeadores uses slightly lower ones, but without much of a loss in visual fidelity).

NOTE: This overall analysis just goes to prove you that you can ‘’’ show ‘’’ anything with bogus data. I think, however, that my general point stands. Polycounts do have an effect in performance (you can make a reasonably big grid of models and compare fps amounts) and those effects affect older computers the most. Even if GPUs nowadays have a breezy time when doing vertex processing, processing many vertices will have a clear effect. Again, this is about getting as many people as possible to be able to enjoy the servers (1), having reasonable download times for newcomers (2) and a consistent theme (3). It’s why all the human playermodels come from the HL2 universe (marines are from BM:S, Combine/GMan from HL2).

EDIT: I wrote up this post and looked up all the relevant data while trying to join Possession. At the time of this edit, I haven’t finished downloading models and, it seems, I never will. It’s been 1 hour, 15 minutes.

1 Like
28

CSGO FBI vanilla model have: 71 bones, 61 HW bones, 25 attachments. Excepts IDF (74/65/25)
Mapeadores marine model: 81 bones, 58 HW bones, 18 attachments
Mapeadores combine model: 85 bones, 31 HW bones, 18 attachments

All CSGO vanilla models for terrorists have: 71 bones, 61 HW bones, 20 attachments. Excepts Pirate (78/68/20) and Professionnal (72/60/20)
Mapeadores zombie is: 86 bones, 57 HW bones, 18 attachments
Mapeaedores ghoul is 86 bones, 64 HW bones, 18 attachments

So i still don’t understand why you need to port and what you need to do? Can someone explain me in detail?
What’s the usage of scaffold models on your server? It’s a skeletton pattern? (80/1/16 for both t and ct) As they have only one HW bone but no vertices, it’s for static models?

29

Thx for that precise reply Envy. I know that i’m stubborn and i made mistakes, but now you shared your knowledge, i understand and i agree with all you said.
I really apologise, trust me it’s only about being curious that trying to say you’re wrong.

About the frustum culling, so there is no Z-culling? That mean that as mapper, we can only think about viscluster for graphic performance optimisations?
Is it worth possible to tweak with the frustum culling, like using multiple high differences with turns (like a L turn with ladder or stairs), or using many paths?

30

Hi Wan,
Frustrum culling is a client side setting which is dependant on the field of view for the game engine. From a game engine point of view this is only one of the components which would influence the performance of map. Individual components such as collision detection, the vis map, vertex mapping, oculsion etc are influential in how performant individual player interacts with a gameworld. External forces such as additional players, the packet delta from each player as to the game server and the polling rate to the game server has back to the user all plays a part in the performance of a map.

Adding additional walls or view blockages reduce rendering on the vismap level but in turn increases the processing on collision. I haven’t got access to any profiling services from the source engine but a lot of the theoretical knowledge is applicable across gameengine theory. I do not see a reason for source to be any different to the likes of opengl.

-Unorth

31

In fact you’re wrong as i was for a thing: i just understood that view blockages are near useless about rendering performances. As Envy said, the engine is doing only Frustum culling. For doing occlusion culling, mappers have to use areaportals or occluder brush entities. But occluder is worth it comparing to areaportal, in term of performances, but are still required for some usages. I was already thinking about PVS optimisation, but was wrong with view blockages. I will use areaportals now…

The best thing is first to make PVS (visclustering) optimisation as it impact all the engine processes (reducing GPU and CPU costs). Then try to use areaportals for GPU cost. But you need to get a minimum of areaportals in the Field of View of the player, as it adds CPU cost, and think about areaportal leaks (a portal need to separate two distinct areas).

You point out a good thing… I was converting brushes to func_brushes for all details. But for what don’t require collision detection, i’m thinking it’s better to convert them to static props and use “not solid” for the collision parameter… But that can be in detriment of map filesize (cause of model files and VHV file generations), so it needs to be at the end of mapping process to get a good balance.