Mesurer la charge des modèles dans/sur le simulateur

Vous avez des astuces pour rendre ORTS plus agréable. Venez les poster ici.

Modérateur : Modérateurs

Avatar du membre
BB25187
Administrateur
Messages : 15057
Enregistré le : 09 mai 2004 1:07
Localisation : Grenoble
Contact :

Mesurer la charge des modèles dans/sur le simulateur

Messagepar BB25187 » 17 mai 2016 20:53

Hello,

Comme cela a été soulevé dans le fil consacré aux X73500, la conception d'un modèle (textures, formes, matériaux, ... ) influe directement sur la consommation de ressources au niveau de la carte graphique (mémoire, nombre d'appels à la CG ou au processeur généraliste, ...).
Du temps de MSTS, on avait eu l'occasion de débattre de la manière de quantifier ou au moins d'estimer ces impacts. Les outils à disposition étaient cependant limités. On pouvait bien compter les polygones et la taille des textures, mais sans être capable d'établir un lien formel, précis et direct entre ces éléments du modèle et ce qu'on pouvait estimer de son impact sur l'efficacité du jeu.
ShapeViewer intégrait une mesure empirique de "Kujus", qui découlait du nombre de polygones, multiplié par la racine carrée du nombre de primitives, prises sur tous les sous-objets. Le tout était ensuite ramené à la valeur ainsi trouvée pour la "Flying Scotsman"!
Bref, au final, on en était souvent réduit à constater la perte de FPS une fois le modèle mis en situation.

Avec OpenRails, on dispose de mesures de différents paramètres, relevées directement par le simulateur. On y accède en vue F5/Maj+F5. On y trouve notamment, pour une "scène" donnée:
- La mémoire consommée
- Le nombre de textures, de matériaux, de formes, de tuiles, ...
- Le nombre de primitives utilisées pour les ombres
- Le nombre de primitives utilisées pour le "rendu"
Bon, d'accord. Mais vous allez me dire - et vous aurez raison - que l'on a a accès ici à des métriques sur la scène complète. Or, ce qui nous intéresse, ce sont plutôt les métriques pour un modèle précis. La bonne nouvelle, c'est que si l'on connaît les unes, il y a moyen de connaître les autres.
Pour cela, on peut utiliser un modèle trivial de référence, constitué de seulement quelques polygones et n'ayant recours qu'à une unique petite texture. ON relève alors les mesures pour la scène contenant ce modèle trivial.
Puis on reconduit l'opération avec le modèle qui nous intéresse, et on soustrait les mesures du modèle de référence. On obtient alors les mesures spécifiques du modèle considéré, sans tenir compte de l'impact des autres éléments de la scène. Vous suivez?

J'ai passé plusieurs engins à la moulinette, et le résultat n'est à mon sens, pas dénué d'intérêt. Ah oui: il ne faut pas changer le point de vue: on garde celui de la vue F2 au lancement du jeu.

Modèle de référence (on peut le réduire encore, mais j'ai pris ce que j'avais sous la main):
Image

Un premier X2400, donc un modèle conçu uniquement pour ORTS
Image

Un second, juste pour voir...
Image

Un X73500, au sujet desquels ce sujet des ressources a justement été abordé. Là encore il s'agit d'un modèle conçu pour ORTS
Image

Bon on a vu des autorails, voyons une loc, avec une BB25500 de Frog, là encore conçue pour ORTS
Image

Et pourquoi pas une DU84 de 20100, elle aussi conçue pour ORTS
Image

Bon, voyons quelques modèles conçus à l'origine pour MSTS, mais également aptes à un usage sous ORTS. Un autorail, d'abord, et plus précisément un Picasso
Image

Et puis un "poids lourd", une crocodile suisse. Mais il faut noter qu'ici on affiche trois "modèles" et non un seul...
Image

Et une seconde, pour voir...
Image

Voilà, pour le moment ce sont les modèles sur lesquels j'ai jeté mon dévolu pour conduire ce petit test rapide.
ET après? Ben après, on peut consigner les mesures dans un tableur, et sortir une jolie figure, pour avoir une idée graphique de l'effet de la conception de ces modèles sur le jeu.

Les deux figures ci-dessous représente les mêmes mesures, mais ordonnées par mesure sur la première, par modèle sur la seconde. Attention: comme il y a une unique échelle et que les valeurs absolues ne sont pas affichées, il ne faut leur accorder qu'une valeur comparative entre mesures comparables!

Image

Image

Que peut on en déduire?

On voit que la charge en mémoire des modèles conçus pour ORTS est plus importante que celle de ceux conçus pour MSTS. Pour une large part, cela provient probablement de l'usage plus ou moins intensif de textures 2048. Et puis MSTS était tellement capricieux et restreint sur ce plan qu'on était contraint à la prudence...
IL faut noter aussi qu'à taille égale, deux textures peuvent avoir des volumes très différents. Des textures très "lisses" sont moins lourdes que des textures très "bruitées".

On observe aussi une certaine disparité dans le nombre de textures utilisées (ce nombre demande à être vérifié, mais pour le moment on peut au minimum lui attribuer une valeur relative). Ce nombre peut influer sur le temps que mettra le modèle à se charger si les textures ne sont pas déjà présentes en mémoire. On risque des à-coups temporaires qui nuisent à l'impression de fluidité. Pour un même type d'engin, l'écart entre les modèles conçus pour ORTS et pour MSTS n'est pas systématique. Il faut dire qu'avec ORTS, on peut assez facilement limiter le nombre de textures en jouant avec un plus petit nombre de plus grandes textures.

Le nombre de matériaux est lui aussi très lié au type d'engin et en partie à la conception, plus qu'au simulateur visé.

Enfin, les nombres de primitives d'ombres et de rendu sont très intéressants. Ils traduisent le nombre d'appels à la CG qui seront nécessaire pour afficher le modèle. On note un très fort écart entre les modèles conçus pour ORTS et pour MSTS, au détriment des seconds. Mais là, l'écart est facile à comprendre, puisque que pour faire passer des modèles lourds sous MSTS, on était amené à bloquer la fusion entre les différentes parties du modèle au moyen d'artifices. ce faisant, on maintenait artificiellement élevé le nombre de primitives, avec un impact direct sur l'efficacité dans le jeu.
En tout cas, les figures illustrent s'il en était besoin pourquoi il n'est plus logique de concevoir des modèles qui "passent" dans MSTS, si l'on veut qu'ils soient en même temps efficaces dans ORTS!

Que les modèles soient conçus pour ORTS ou MSTS, on note évidemment une charge bien supérieure pour les engins qui intègre un aménagement intérieur. Logique...

Bon maintenant, si on regarde engin par engin, on note que la charge en mémoire des X73500 des amis du rail n'est pas significativement supérieure à celle des X2400 de votre serviteur. En revanche le nombre de textures mises en jeu par les premiers est effectivement bien plus important, comme l'a relevé Olivier. Il en résulte aussi un nombre plus élevé de primitives de rendu (normal: on a plus de textures).
En revanche, les championnes de la consommation mémoire sont les DU84 de 20100. En y regardant de plus près, ce sont les modèles qui mettent en jeu le plus grand nombre de textures 2048. Donc on reste dans la logique des choses. En contrepartie, ces draisines induisent un plus nombre de primitive relativement réduit que pour les autorails précédents. On est au même niveau que pour les BB25500 de Frog sur ce plan, probablement parce que les aménagements intérieurs ne sont pas éclairés comme sur les autorails.
Pas de jugement de valeur dans tout ça. Juste des constats, et peut-être un moyen de se faire une idée de ce qui peut "peser" le plus dans un modèle et comment il impacte la consommation de ressources, et comment on peut améliorer les choses.

Ces bases étant posées, il va falloir creuser un peu, et passer d'autres modèles à la moulinette. On pourra aussi ajouter le nombre de polygones ou de sommets à ces mesures.

Z'avez lu jusqu'au bout? Bravo!
"Er ist ein Unmensch, ein Tyrann!" - Tamino - Erster Akt - Die Zauberflöte.
____________________________________________________________

Image

Avatar du membre
Groquik
Messages : 94
Enregistré le : 15 nov. 2005 1:20
Contact :

Re: Mesurer la charge des modèles dans/sur le simulateur

Messagepar Groquik » 18 mai 2016 13:15

Bonjour

Merci pour ces investigations.
Je souhaite préciser que je n'ai pas dit que les X 73500 posaient des problèmes de performances palpables. Mais seulement qu'une utilisation plus efficace des textures pouvait, à rendu égal, largement diminuer le nombre de textures, de primitives, et de mémoire vidéo utilisée. Je n'ai pas de chiffre précis, mais 50% ne me semblerait pas idiot. Et c'est dans un scène chargée en décor ou en trains croiseurs que la limite pourrait devenir palpable.
IL faut noter aussi qu'à taille égale, deux textures peuvent avoir des volumes très différents. Des textures très "lisses" sont moins lourdes que des textures très "bruitées".

Faux, en tout cas pas tout à fait vrai.
J'ai récemment pas mal étudié les formats de textures et les shaders (ça sera aussi l'occasion de pondre un article technique sur le sujet). Et il faut distinguer la taille d'une texture sur le disque dur ou en RAM système de la taille qu'elle occupe en mémoire vidéo.

Pour faire simple, il existe deux types de compression radicalement différents, que sont la compression zlib et la norme S3TC (formats DXT1, DXT3 et DXT5). Ils sont même cumulables. ACE-it permet de "surcompresser" une texture DXT1 en zlib.

La première est comparable au ZIP et, là effectivement, une texture bruitée sera moins facile à compresser qu'une texture lisse. Il s'agit d'une compression non destructive, mais la texture est obligatoirement décompressée avant le transfert en mémoire vidéo.
La seconde est destructive mais impose une taille fixe des textures car elle opère par indexation de couleurs.
Pour chaque bloc de 4*4 texels, une texture DXT1 utilise 64 bits. Une texture DXT3 ou DXT5 utilise également 64 bits pour l'information de couleur, codée de façon identique au DXT1, plus 64 bits pour la couche Alpha.
Donc, par rapport à une texture opaque décompressée 24 bits par texel, DXT1 offre un ratio de compression fixe de 1 pour 6.
Par rapport à une texture semi-transparente 32 bits par texel, DXT3 et DXT5 offrent un ratio de compression fixe de 1 pour 4.

La taille d'une texture sur la carte graphique, et son impact sur les performances lors du transfert sur le bus mémoire dépend donc de sa taille en texels, du poids de chaque texel (en général 24 ou 32 bits) et de sa compression (décompressée ou DXTn). Mais le contenu n'influe pas.

Petit détail qui a son importance. MSTS réduisait l’échantillonnage des textures en 16 bits, qu'elles soient opaques, transparentes ou semi-transparentes (dans ce cas, alpha codé sur 4 bits et chaque canal RVB également sur 4 bits).
En revanche, je ne sais pas bien si le rendu de la scène après illumination diffuse était également en 16 ou en 32 bits.

Avatar du membre
damien2212
Messages : 1192
Enregistré le : 15 juin 2011 18:12
Contact :

Re: Mesurer la charge des modèles dans/sur le simulateur

Messagepar damien2212 » 19 mai 2016 18:50

Hello,
Merci Vincent pour ce topic ?2?
Va falloir que je réduise pour les prochaines fois le nombre de textures employées ! =, forum41

Damien
Membre de l'APSFI et des Compagnons du Rail
http://compagnonsdurail.wix.com/creations
Créateur polyvalent
Image
Image

Avatar du membre
tonton2800
Messages : 532
Enregistré le : 05 févr. 2010 21:43
Contact :

Re: Mesurer la charge des modèles dans/sur le simulateur

Messagepar tonton2800 » 19 mai 2016 19:54

bonjour Vincent,

Merci pour ce grand tuto qui me sera très utiles surtout pour le beilhack RGP TEE et la Z6100.


A+

Avatar du membre
BB25187
Administrateur
Messages : 15057
Enregistré le : 09 mai 2004 1:07
Localisation : Grenoble
Contact :

Re: Mesurer la charge des modèles dans/sur le simulateur

Messagepar BB25187 » 20 mai 2016 21:23

Hello,

De rien pour le tuto. Honnêtement c'est juste un premier essai rapide. Comme le souligne les propos d'Olivier (merci Olivier!), il y a encre pas mal à creuser et à compléter. Il y a un truc que je ferais bien, ce serait de supprimer la structure d'un modèle pour MSTS afin d'en faire un modèle uniquement utilisable sous ORTS, et de voir la différence. Les crocos sont de bons candidats. Par contre du fait justement des contraintes qu'imposait MSTS, je n'avais pas poussé jusqu'au bout du possible l'optimisation qui consiste à mapper sur un minimum de textures des éléments dont on sait qu'ils seront fusionnés au moment de l'export de TSM vers le fichier de forme (un point sur lequel il faudra revenir et insister). Donc on ne se fera qu'une idée pessimiste du gain induit par le passage d'une structure "MSTS" à une structure "ORTS".

A+
"Er ist ein Unmensch, ein Tyrann!" - Tamino - Erster Akt - Die Zauberflöte.
____________________________________________________________

Image


Retourner vers « ORTS: Trucs et astuces »