Présentation

Futuremark a été un peu plus avare de détails techniques pour cette nouvelle version qu’il ne l’avait été avec 3DMark03. Pour contrebalancer ce fait toutefois, le développeur a implémenté pour chacun de ses tests « jeux » un outil permettant d’étudier l’évolution de certains facteurs au fil du temps. Les statistiques peuvent être faites sur :

• le framerate
• le temps de calcul de chaque image
• le nombre de polygones par image
• le nombre de vertices par image
• le nombre d’états qui ont changés durant l’affichage de chaque image
• combien de lots (batch) d’affichage ont été exécutés durant l’affichage de chaque image

Ainsi, il est en fait possible d’avoir une étude beaucoup plus fine des performances, puisque par exemple il est en pratique assez difficile de déterminer si un jeu est fluide en ayant comme seule information le framerate moyen ; l’observation du framerate minimum est en revanche bien plus pertinente. Cet outil va donc dans le bon sens. Pour information, les scènes de 3DMark05 comptent en moyenne le rendu de plus de 1 million de polygones par images, ce qui est encore bien supérieur aux jeux les plus gourmands du moment.

Test 1 : Return to Proxycon

3DMark03 incluait un test mettant en scène un combat ayant lieu dans un vaisseau spatial assiégé, ‘Battle of Proxycon’. Ce test avait manifestement pour objectif de se rapprocher du rendu de Doom 3, encore en développement alors. Pour ce faire, il utilisait le Stencil buffer via les Vertex Shaders pour générer des ombres dynamiques, et bénéficiait de la possibilité offerte par DirectX 9 d’exécuter une opération Stencil en une seule passe, même si le test était DirectX 8. Et puis il y avait bien sûr l’utilisation du Normal Mapping.

‘Return to Proxycon’ représente scénaristiquement la suite de ce test, avec l’attaque d’un vaisseau cargo par des pirates dotés d’une puissance de feu supérieure. Cette scène est censée représenter les performances des cartes 3D sur les shoots à la première personne. La scène se passe principalement en intérieur, mais dans des salles assez vastes permettant de recueillir plusieurs joueurs en même temps, à l’instar d’un certain nombre de maps multijoueurs habituellement plébiscitées sur ce genre.

La plupart des surfaces à l’intérieur du vaisseau utilisent une réflexion de Blinn-Phong. Les différentes lumières du plafond du hangar sont simulées via un éclairage directionnel. Il génère des ombres dynamiques en utilisant une ‘depth map’ de 2048x2048, et plusieurs points lumineux sont également implémentés, sans qu’ils ajoutent beaucoup d’ombres afin de limiter la charge. Le couloir utilise en revanche des points lumineux générant des ombres, qui utilisent chacun une ‘cube depth map’ de 512x512x16. Il y a en tout 8 sources lumineuses dans ce test : 2 sources directionnelles et 6 points lumineux.

Test 2 : Firefly Forest

Ce test met en scène une forêt lors d’une nuit de quasi pleine lune, avec des lucioles magiques vertes qui se déplacent dans la forêt. Il représente donc une scène extérieure avec une faible distance de vue (les arbres cachant le reste de la forêt), mais riche d’une végétation dense. Du fait d’une légère brise, les arbres se balancent avec un mouvement indépendant de chaque branche. La végétation au sol est un des points les plus importants de cette scène, puisqu’elle est dynamiquement répartie là où elle est nécessaire, suivant les mouvements de la caméra. Le niveau de détail est également défini suivant la distance de la caméra. Enfin, ce test fait la part belle à un système d’éclairages et d’ombrages dynamiques particulièrement impressionnant, ayant lourdement recours aux ‘perspective shadow maps’.

Les matières du sol sont assez proche à celle du premier test, mais avec en plus des ‘diffuse’, ‘diffuse detail’, ‘normal’ et ‘normal detail’ maps. La surface des pierres bénéficient en outre d’une ‘specular map. Les branches des arbres sont toujours basées sur les matières du premier test, mais sans ‘specular map’ ni bump mapping, mais avec une ‘diffuse cube map’. Le ciel utilise quand à lui une dispersion d’éclairage procédural.

La lumière de la lune est générée via un éclairage directionnel créant des ombres dynamiques utilisant à nouveau une ‘depth map’ de 2048x2048. De même, les lucioles sont des points lumineux masqués utilisant une ‘cube depth map’ de 512x512x16.

Test 3 : Canyon Flight

Ce test est quelque part un hommage à Jules Verne et aux romans d’aventures. Les développeurs de Futuremark n’ont jamais choisis les thèmes de leurs tests au hasard, et ont toujours tenu à exploiter au mieux les possibilités techniques des dernières API et cartes 3D pour créer des univers cohérents et remarquables, dans une optique très fidèle à l’esprit des démomakers. C’est particulièrement visible sur ce test, et c’est un des points qui rapproche ces « Game tests » de l’objectif des jeux, qui n’est pas de simplement utiliser les dernières technologies 3D pour mettre à mal la carte 3D.

Ici, un prototype de ballon dirigeable vol à travers un canyon gardé par un énorme monstre marin. L’équipage se défend avec de gros canons, mais ceux-ci ne semblent pas avoir d’effet sur la bête.

Ici, nous sommes en présence d’une scène extérieure avec une longue distance de vue. Bien que physiquement assez simple et dépouillée, elle se révèle techniquement assez complexe avec de grandes étendues d’eau réfléchissant les murs du canyon. L’eau ne se contente d’ailleurs pas de réflexions et réfractions réalistes, elle bénéficie d’un brouillard de profondeur qui permet de faire en sorte que le monstre paraisse nager beaucoup plus profondément qu’il ne le fait en réalité. On note également la présence d’un brouillard volumétrique dans l’air, qui rend encore plus lointaines les falaises en arrière plan (qui ne sont donc évidemment pas une simple texture).

La surface du canyon est une des matières les plus lourdes utilisées par 3DMark05, remplissant un pixel shader 2.0 jusqu’à la dernière instruction lorsque combiné avec l’ombrage dynamique. Elle utilise deux ‘color maps’, deux ‘normal maps’ ainsi qu’un shader Lambertian. La scène est rendue 6 fois afin d’obtenir les bonnes réflexions, réfractions et ombres sur l’eau. Celle-ci est d’ailleurs une version améliorée de celle que l’on trouvait dans 3DMark03, effectuant plusieurs lectures à partir d’une ‘normal maps’, d’une ‘reflection map’ et d’une ‘refraction map’ avec en plus un Fresnel par pixel. Pour le brouillard de profondeur, une ‘R32F depth map’ est utilisée.

Une seule source lumineuse directionnelle (le soleil) est utilisée pour représenter l’éclairage de cette journée ensoleillée. Cette scène est très complexe au niveau des ombres du fait des grandes surfaces et des formes arrondies des murs du canyon. Même en utilisant deux fois la ‘depth map’ (pour les objets proches de la caméra puis pour le reste de la scène), sa résolution de 2048x2048 semble être limite mais laissée telle quelle afin de ne pas augmenter encore la charge. Le fait que les ombres soient dynamiques permet en revanche un rendu réaliste quelque soit le moment de la journée (phénomène visible lors du générique de fin de 3DMark05).

Score global

Ces trois tests sont comme toujours les seuls à être utilisés pour le calcul du score global :

• 3DMark05 score = (Game Test 1 * Game Test 2 * Game Test 3)^0.33 * 250

Chaque test a donc la même importance, et le score obtenu varie entre 1000 et 5000 avec les cartes 3D actuelles.

Un mot d’ailleurs sur la manière qu’utilise Futuremark pour faire en sorte que chaque test ait globalement la même importance, indépendamment de la valeur élevée ou faible du framerate. Si l’on s’en tient à la parenthèse, on pourrait croire que ce n’est pas le cas, puisque tous les termes sont simplement multipliés entre eux : le test ayant le framerate le plus élevé devrait donc avoir une importance considérable, bien plus que si c’était la moyenne des trois tests qui était prise en compte. L’astuce se situe en fait dans le terme ^0.33 appliqué à la parenthèse : celui-ci fait en sorte que le résultat soit lissé assez indépendamment de la valeur de la parenthèse, la fonction x^0,33 étant quelque part similaire à la fonction √x suivant l’échelle utilisée (le score 3DMark se lit en ordonnée) :

Enfin, le terme * 250 permet de faire en sorte de calibrer les scores sur une plage 1000-5000 plutôt que 4-20, mais augmente également la pente de la courbe sur la plage de valeur x donnée (qui correspond donc au produit des framerates) :

Au final, le résultat de tout ceci est que le score global peut finalement être assez influencé par le test obtenant le plus faible framerate. Si vous obtenez trois scores assez proches, le résultat sera cohérent, mais en revanche si un test se révèle extrêmement lent sur une carte 3D donnée, le score global en sera lourdement affecté, même si les autres tests s’exécutent très rapidement. Cela dit il faut vraiment que le framerate le plus faible soit vraiment très bas pour que le phénomène se fasse vraiment ressentir ; dans le cas contraire la variation sera faible.

La pratique veut d’ailleurs que le test s’exécutant le plus lentement soit en général le deuxième test.

Une dernière remarque : le bon point résultant indirectement de ce choix de tests est qu’une carte ne supportant pas DirectX 9.0 ne pourra pas obtenir de score global, contrairement aux précédents 3DMark qui généraient des scores sans aucune signification si les cartes 3D n’étaient pas capables d’exécuter tous les tests à l’origine du score global (en particulier les cartes DirectX 8 donc). Dans la pratique pourtant, les jeux ne refusent pas de s’exécuter dans le cas d’une carte graphique de niveau technologique non optimal : un path allégé est utilisé.