IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

FAQ Programmation 3D

FAQ Programmation 3DConsultez toutes les FAQ

Nombre d'auteurs : 7, nombre de questions : 67, dernière mise à jour : 14 juin 2021 

 
OuvrirSommaireRendu 2D / 3DProblèmes

La plupart des problèmes visuels liés à la profondeur sont dus à un mauvais paramétrage de la matrice de projection.

L'erreur classique est de mettre le plan proche (near plane) à zéro : cela aurait pour conséquence des divisions par 0 en interne, et donc des résultats incorrects. Choisissez plutôt comme valeur 1, ou 0.1.

Une autre erreur courante est d'avoir un rapport far-plane/near-plane trop élevé (near-plane beaucoup trop proche, ou far-plane beaucoup trop éloigné). N'oubliez pas que les valeurs de profondeur ne sont pas distribuées de manière uniforme dans le Z-Buffer : avec un ratio far/near de 1000 par exemple, 2 % de la scène (les plus proches) rempliront 98 % du Z-Buffer. Ainsi peuvent apparaître des artefacts visuels non souhaités, notamment sur les objets lointains.

Créé le 22 janvier 2006  par Laurent Gomila

Pas de panique ! Il existe trois raisons principales à ce comportement :

  • vous avez activé la synchronisation verticale, ou faites tourner votre application sur un ordinateur qui l'a activée. Il suffit dans ce cas de la désactiver (voir https://jeux.developpez.com/faq/3d/?page=problemes#PROBLEMES_vsync), ou plus simplement de la laisser et de se dire que ce n'est pas grave !
  • vous affichez très peu de triangles, mais couvrant la totalité de l'écran. Dans ce cas, faites attention au fillrate, n'oubliez pas qu'il ne faut pas forcément des milliards de triangles pour mettre à genou votre carte graphique (voir https://jeux.developpez.com/faq/3d/?page=techniques#TECHNIQUES_goulots) ;
  • la perte que vous croyez énorme est en fait minime. N'oubliez pas qu'une chute de 900 fps à 200 fps est plus « petite » qu'une chute de 50 fps à 40 fps. En fait, pour convenablement juger de la perte de performances, il vaut mieux mesurer le temps perdu sur une frame, que la différence de fps qui n'est dans ce cas pas du tout représentative.
Créé le 22 janvier 2006  par Laurent Gomila

Si votre framerate semble bloqué à une valeur entre 60 et 100, alors vous avez certainement activé la synchronisation verticale (V-Sync) ; dans ce cas votre framerate correspond simplement à la fréquence de rafraîchissement de votre écran.

La synchronisation verticale est généralement désactivable très facilement selon l'API utilisée. Elle est également réglable dans les options de vos drivers, mais ceux-ci laissent généralement par défaut l'application la contrôler. Dans le doute, vérifiez tout de même de ce côté !

Créé le 22 janvier 2006  par Laurent Gomila

C'est un piège courant : parfois lorsque l'on active l'éclairage, nos modèles deviennent noirs ou prennent des couleurs inattendues. Cela est bien souvent dû à des normales non définies, ou mal calculées. En effet, le calcul de l'éclairage effectué en interne a besoin de la normale de chaque sommet. Si vos vertices n'en possèdent pas ou si celle-ci n'est pas correctement calculée, alors les résultats à l'écran seront erronés.

Et si vous ne souhaitez tout simplement pas utiliser d'éclairage, alors n'oubliez pas de le désactiver si vous ne voulez pas voir vos modèles apparaître noirs !

Créé le 22 janvier 2006  par Laurent Gomila

Cela arrive lorsque le filtrage de texture est activé. Les pixels transparents (souvent d'une couleur flashy du genre RGB(0, 255, 0)) viennent se mélanger au contour de votre sprite lors du filtrage, et provoquent ainsi cet effet indésirable.

Afin de s'en débarrasser, il suffit de désactiver le filtrage de texture lors de l'affichage de vos sprites.

Créé le 22 janvier 2006  par Laurent Gomila

La cause principale à ce problème est une mauvaise correspondance entre les pixels (du back-buffer) et les texels (de la texture). En effet, en interne l'origine des texels (au coin haut-gauche) diffère de l'origine des pixels (au centre), créant ainsi un décalage d'un demi-texel et affectant le rendu.

Pour obtenir un résultat correct, il suffit donc de décaler d'un demi-texel (0.5 / taille_texture) les coordonnées de texture de votre sprite. Par exemple pour un sprite de 64x64, il faudra avoir les coordonnées de textures suivantes : (-0.5 / 64, -0.5 / 64) et (64.5 / 64, 64.5 / 64).

Une autre cause à ce problème, moins fréquente, est l'utilisation d'une texture dont les dimensions ne seraient pas en puissance de 2, sur une carte ne supportant pas cette fonctionnalité. Dans ce cas il suffit de corriger les dimensions de votre texture, quitte à ce qu'elle soit plus grande que votre sprite. Voir https://jeux.developpez.com/faq/3d/?page=techniques#TECHNIQUES_textures_puissance_2.

Créé le 22 janvier 2006  par Laurent Gomila

Il arrive que les textures appliquées sur les polygones scintillent à l'écran lorsque celles-ci sont réduites (sur des polygones lointains).
Cet effet indésirable est provoqué par la carte graphique qui, lorsque la texture est affichée sur une surface plus réduite que sa résolution, oscille entre quelques pixels proches les uns des autres et les affiche chacun à leur tour.

Pour éviter cet effet de scintillement, il faut générer plusieurs textures de résolutions plus petites en plus de la texture originale, et activer le mip-mapping (voir https://jeux.developpez.com/faq/3d/?page=definitions#DEFINITIONS_mipmap).

Créé le 22 janvier 2006  par shenron666

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2009-2017 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.