Ram Graphique, la fin d'un mystère ? A LIRE.

Que pensez vous de ma réflection ? Ha, et ce qui semble confirmer ma réflection, c'est cela :
https://www.youtube.com/watch?v=kRWRskYLdno&eurl=http%3A%2F%2Fwww.pcgameshardware.com%2Faid%2C687527%2FCryengine-2-vs-Cryengine-3-or-PC-vs-consoles-Video-comparison%2FNews%2F&feature=player_embedded
Crysis is a very heavy game. A simple grass texture is 1024 x1024 and about 3Mb, so it easy to overload the Vram of a PS3 or 360 which are 256MbVram.
Traduction, Crysis est un jeu très lourd. La simple texture de l'herbe est de 1024x1024 et donc environs 3 Méga octets. Donc c'est facile de dépasser la capacité de la PS3 ou de la 360 qui n'ont que 256Méga Octets.



Résumé de ce qui nous interesse : 1024x1024 pixel = 3Mb=3Mo

Tentative d'explication ?
1024x1024=1 048 576 pixel

Mais "pixel" est en faite incorrect, puisque en réalité, un pixel est sensé être une composante de couleur (RVB = Rouge Vert Bleu = RGB = Red Green Blue) (un pixel est en réalité soit un pixel rouge, soit un pixel vert, soit un pixel bleu en sachant que les 3 peuvent donner une couleur 24bits=3pxl*8bit). Nous avons donc 3x1.048.576=3.145.728 valeur à stocké ayant chaqu'une d'elle 255 intensité possible (1 octet = 8 bit= 1 byte)

3.145.728 (un tier de R un tier de V un tier de B) à stocker coutant chaqu'une d'elle 1 octet = 1 bytes...

D'où une texture de 1024x1024 pixel (chaqu'un RVB) environs égal à 3Mb=3Mo




Je ne sais pas si c'est correct, mais d'après mes moyennes connaissances, ça m'a l'air sacrément correct.

Les PC que vous avez à l'heur actuelles ont probablement tous au moins entre 32mo et 512mo de Vidéoram (certaines carte graphique ont même 2Go, voir 2Go en copie par carte dans le cas de mise en parallèle de plusieurs cartes), bref, on pourrait stocker des textures énormes en mémoire sans avoir peur de saturer ???


Je me permets de vous prévenir que d'après des testes assez simple que j'avais réalisé il y a un peu plus d'un an, un background ou un sprite ne peut pas dépasser 1600 ni en horizontal ni en vertical, ce qui signifie que le max est 1600x1600 par ressource. (1601x50 ne marchera pas, cependant, vous pouvez enregistrer des textures de 1600x1600 beaucoup de fois).





J'attends vos commentaires avec impatience, ceci serait une éxcélente nouvelle, cela veut dire qu'en faite, les limites de textures stockable sont gigantesques et cela me serait vraiment pratique pour mon optimisation de lumière de M@d_Doc et pour mon optimisation de lumière de Bast (qui s'optimisent en enregistrant les résultats des lumières statiques dans une surfaces (les surfaces de GM étant officiellement stockées dans la Vidéoram)).

Moi je me suis toujours demandé si on dépasse la vram il y a t-il un système qui met nos textures dans la ram à la place sinon c'est compliqué personne a la même carte graphique

Le PC "swapp" la ram dans le disque dur quand la ram est saturée.
En ce qui concerne la Vram, je sais que sur PC, avant, il y avait le "turbo cache" qui permettait de piocher dans la Ram pour s'en servir comme Vram (perte de gain, mais moindre que ce que ça devrait).

En ce qui concerne GameMaker, j'ai l'impression que si ta pas assez de Vram et que tu déclares un nouvelle espace qu'il ne peut pas te donner, il se contente de ne pas te l'accepter et quand tu veux t'en servir après, il te dit "surface inéxistante", normal puisqu'il a refusé de la crée puisqu'il y en avait pas de libre... Enfin, il me semble, je ne suis pas du tout sûr. Il faudrait vérifier (ça remonte à loin que j'avais vérifier cela) ...
M'enfin, dans les jeux vidéo, je pense que la carte graphique sait pompée et envoyer en Ram si manque de Vram. Juste que tes performances (nombre d'image par secondes) ont tendance à chuter dramatiquement, genre divisée par deux d'un coup, donc si tu sais que tu en as pas assez, vos mieux ne pas dépasser parce que ça tue les perfs.

Je pense que tes calculs sont faux, parce que : la texture en 1024*1024 fait effectivement 3 Mo sur le disque dur, MAIS tu ne sais pas combien elle pèse une fois dans la Vram (c'est un peu comme si tu disais qu'un .exe qui pèse 2 Mo prendra forcément 2 Mo de RAM, ce qui n'est absolument pas le cas), et si elle est ou non compressée en Vram.

Ensuite, il me semble que les PCs peuvent swapper les textures dans la RAM, explication :

J'avais un PC qui avait 4 Mo de Vram, je pouvais pas mettre de textures en 1024*1024, seules les textures en 512*512 passaient (et en configurant l'écran en 16 bpp), mais je pouvais mettre bien plus de 4 textures en 512*512 (4 textures en 512*512 donnent théoriquement la même chose qu'une texture en 1024*1024).
Bien sûr ce n'est qu'une hypothèse, car peut-être qu'en fait une texture en 1024*1024 est plus lourde en Vram que 4 textures en 512*512.

la cg de la 360 c'es pas 512?
sinon je dirais que l'image est garder en tampon dnas la carte comme un image dnas l'oeuil
si certain truc sont plus gros que le capteur visuel(CG ou oeil) ils sont pas afficher
et comme une CG utilise pas le m^me principe qu'un oeuil il peux simplement pas l'afficher
moyen de défaire cette limite= plus grande CG
ou pas

Wargamer a écrit:

la cg de la 360 c'es pas 512?
sinon je dirais que l'image est garder en tampon dnas la carte comme un image dnas l'oeuil
si certain truc sont plus gros que le capteur visuel(CG ou oeil) ils sont pas afficher
et comme une CG utilise pas le m^me principe qu'un oeuil il peux simplement pas l'afficher
moyen de défaire cette limite= plus grande CG
ou pas

Pourquoi tu parle d'oeil la... aucun rapport.


Je dirait que la texture que tu parle Topazze prendrais 4mo en mémoire si tu ajoute le canal alpha donc RGBA (1024 *1024 * 4 / 1024 / 1024 = 4 mo)

mouai... je doute qu'il faille de l'alpha sur une texture d'herbe quand m^me

WarGamer :
D'après ceux qui parlent de Crysis, la PS3 et la 360 ont une 256Mo, mais tet qu'ils se gourent, je n'ai pas vérifier et ça ne m'interesse pas (cela voudrait juste dire que sur 360, Crysis pourrait avoir enfin des textures plus fines).

Nicoulas :
Sauf que dans le cas de Crysis, la texture de l'herbe plaquée sur le sol n'a pas intérêt à être transparent, donc pas de canal Alpha. Mais c'est vrais qu'avec un Canal Alpha, la logique aurait voulu que du 32bit en 1024x1024pxl fasse 4Mo.
Deplus, avant les textures étaient compressées, mais ça coutait dans les perfs, maintenant, généralement, je pense qu'elles ne le sont plus, et qu'elles vont grâce à DirectX11 et aux Méga textures réapparaître (compressé quasi sans perte de qualité ni de perfs...).
Bref, je pense que dans le cas de Crysis, les textures ne sont pas compressées. Et je ne parlais pas du poids sur le Disque Dur, mais dans la Vram. Car des textures non compressées dans la Vram sont me semble t'il sous une forme très proche du bitmap (3 paquets de 8 bits, chaque paquet pour une composante de couleur (R ou V ou B) et donc intensité entre 0 et 255 pour chaque paquet).



Et oui, les PC peuvent swapper dans certains cas (virtualisée une Mémoire dans une autre), sinon, dans certains jeux, on ne devrait pas pouvoir monter les graphismes à fond sans planter si on est en manque de Vram (alors qu'on peut, mais ça coute très très chèr sur les perfs). Et ton exemple me semble excélent pour l'illustrer, mais dans le cas de GameMaker, je ne suis pas convaincu que ça puisse swapper la Vram dans la Ram (il faudrait faire le teste avec un PC moins puissant que le miens... parce que mes 256mo de Vram risquent d'être dur à démonter XD).


Nicoulas, j'attends ta réponse ^^

Je ne sais pas... d'après moi, une texture a un canal alpha, qu'il soit utilisé ou non, mais bon, tout dépend du format des textures, une fois de plus.
Prenons par exemple le moteur source, qui stocke (dans les vtf et vmt) dans le fichier la texture elle même (R,G,B), un EVENTUEL canal alpha (donc c'est optionnel), des données sur le matériaux, les données du bump map, et j'en passe et des meilleures...
Et la plupart de ces données se retrouvent dans la vram : bah oui, un layer de rouge, un vert, un bleu, un alpha, un bump map, etc, etc...
Je ne sais pas comment marche le cry engine, mais il ne faut pas oublier toutes ces données des textures que la CG doit absolument prendre en compte... ce qui finit par monter le poids des textures au delà de tes estimations, d'après moi.
(et remplir la vram de textures, c'est là aussi théorique... il y a aussi les shaders, modèles divers, masks, etc. qui sont loadés en permanence dans la vram)

Bref, c'est mon point de vue, en pur n00b du hardware :p (enfin presque)

J'avais pensé au bumpmap ect...
Mais je pense que quand il dit qu'une texture d'herbe prend 3Mo, c'est juste la texture en RVB, sans le reste. Après, je me doutais que quelqu'un allait me coincer la dessus. ^^
Mais avec 3Mo en non compressé, je ne pense pas qu'il y ait autre chose de pris en compte (comme le bumpmap), avec Bumpmap, ça doit faire plus, à moins que la texture soit compressée et que du coup, le bumpmap tienne dedans, mais pour une question de performance, je ne pense pas que les textures soient compressées donc si mon calcul est juste, 3Mo, c'est juste la texture RVB.


J'attends d'autres remarques pertinentes encore, je ne sais pas lesquelles, l'alpha et le bumpmapping, c'étaient tout ce à quoi je m'attendais.

Si il y a un pro dans le domaine qui pouvait enfin nous affirmer la solution, ce serait sympa XD

L'exemple que je donnais avec la texture en 1024*1024 et les 4 textures en 512*512 était avec GM.

Sinon pour compléter la liste des trucs qui utilisent la Vram (hormis shaders, etc), tout simplement l'initialisation (et le maintient) de la 3D en utilise plusieurs mégas.

Je pense quand même que 3 Mo de Vram pour une texture 1024*1024 c'est assez peu, je me demande si c'est aussi simple qu'un canal RGB

EDIT : non c'est bien 3 Mo, mais sans les mipmaps, mais je connais pas bien Crysis, je sais pas si le filtrage des textures peut se faire en trilinéaire.

nicoulas a écrit:

J'avais un PC qui avait 4 Mo de Vram, je pouvais pas mettre de textures en 1024*1024, seules les textures en 512*512 passaient (et en configurant l'écran en 16 bpp), mais je pouvais mettre bien plus de 4 textures en 512*512 (4 textures en 512*512 donnent théoriquement la même chose qu'une texture en 1024*1024).
Bien sûr ce n'est qu'une hypothèse, car peut-être qu'en fait une texture en 1024*1024 est plus lourde en Vram que 4 textures en 512*512.

ça doit être nice de programmer un jeu 3D avec une vram aussi limitée :gniah:

Citation :

car peut-être qu'en fait une texture en 1024*1024 est plus lourde en Vram que 4 textures en 512*512.

bah ca dépend du format non?

je crois que c'est comme ça qu'on affiche les sprite dans les vielles consoles non ? plusieurs carreaux de 8/16 pixels pour afficher un sprite

shm31 a écrit:

ça doit être nice de programmer un jeu 3D avec une vram aussi limitée :gniah:

Lol à l'époque je faisais pas trop de 3D, mais j'ai eu l'occasion de tester deux de mes projets en 3D dessus, mais à chaque fois fallait adapter les textures pour qu'elles rentrent dans la Vram :nezrouge:

zebdal a écrit:

Citation :

car peut-être qu'en fait une texture en 1024*1024 est plus lourde en Vram que 4 textures en 512*512.

bah ca dépend du format non?

La taille d'une texture en Vram ne dépend pas du format du fichier mais de la taille de la texture (il doit y avoir d'autres paramètres, comme justement le canal alpha, etc).

shm31 a écrit:

je crois que c'est comme ça qu'on affiche les sprite dans les vielles consoles non ? plusieurs carreaux de 8/16 pixels pour afficher un sprite

Ouais je pense, donc ça doit vouloir dire que les consoles aussi pouvaient swapper les textures en RAM.

Les vielles consoles utilisaient juste des tiles set minuscules et chaque couleur prenait moins de bit donc au final, ça prenait bien moins de place. Et c'était suffisant pour tout le jeu.

SHM : ba 256de Vram, ce n'est pas faible non plus, le soucis, c'est juste que Crysis map avec de nouvelles textures un peu partout donc au final...
Mais je sais que par exemple, Crysis en very high en 1920x1200 avec antialiasingX8, ça pompe dans les 650Mo au moins. Donc il faut laisser un peu de marge pour ne pas risquer la chute fatigue de baisse de perfs et ça nous fait comprendre que dans ce genre de cas 1Go de ram, c'est ce qu'il faut et 2Go, c'est un peu de la foutaise à l'heur actuelle.

Moi j'ai lu quelque part que travailler en 24bits était moins performant que travailler en 32bits c'est pour ca que je pense que la texture d'herbe est sur du 32bits. M'enfin je dis ce que je pense sans trop le savoir vraiment. Mais dans ma tête mélanger du 24bits et du 32bits en temps réel ca coute cher en performance à cause des conversions de 24 à 32 bits ou de 32 à 24 bits récurrentes...

aucune idée, mais c'est possible, je demanderais à Bubu si la conversion se fait au niveau de la carte graphique ou de la puce VGA sur les écrans.
(Mon binhomme en GEII, je comprenais rien à la programmation des ship VGA, lui si, et était tet le seul XD), tet que maintenant, TheDarkTiger peut se douter lui aussi de la réponse (comme il a le même diplôme maintenant) ...



Au sujet du débat sur le swappage ou pas de la mémoire vidéo de GM dans la ram ou pas, je suis tombé sur ça (coup de peau, je regardais l'aide pour les bend mode et non pour ça)


La texture choisie peut ne pas être actuellement en mémoire vidéo. Le système la chargera alors pour vous en cas de besoin mais parfois, vous souhaiterez le faire par vous-même. Pour cela, il existe les fonctions suivantes :

texture_preload(texid) Charge immédiatement la texture en mémoire vidéo.
texture_set_priority(texid,prio) S'il y a trop peu de mémoire vidéo, certaines textures seront temporairement retirées de la mémoire afin de libérer de la place pour permettre le chargement des textures nécessaires. Les textures de priorité la plus basse seront supprimées en premier lieu. Par défaut, toutes les textures possédent la priorité 0 mais il vous est possible de changer cette priorité à l'aide de cette commande (n'utilisez que des valeurs positives !)

Donc oui, GM peut virtualiser la mémoire vidéo des surfaces dans la ram si elle sature.



Maintenant retournons au débat taille des surfaces dans GM = combien de Mo de la VideoRam ?
Réponse que j'ai essayé de démontrer dans le premier post : 1MégaPixel (1000x1000pxl) =3Mo et sans doute 4 avec le canal alpha de GM8.

Des réactions ?


EDIT : codave : si sur GM7, c'est en 24 bits, c'est que c'est probablement stoké en 24bits et converti ensuite, bien que pas sûr !?

Je peux faire du 2047*2047 maximum avec mes 64 mo de Vram.
Lorsque je tente du 2048*2048, ça doit rentrer dans la Vram (la surface est bien créée), mais l'affichage de la surface est impossible.
Au delà, la surface n'est pas créée.

Je te laisse faire tes calculs (pas le temps là). ^^

Je l'ai dis plus haut ^^
D'après mes testes réalisés il y a un bail, tu ne peux pas dépasser 1600pxl en longueur ou en largeur.

1600x1600 ça passe, mais 1000x1601 ne passera pas (tu peux le faire en plusieurs textures mais pas en une seule)

Hmm moi 2047*2047 ça marchait parfaitement, et Bibi675 pouvait atteindre 2048*2048 je crois (avec affichage tout à fait normal).

Topaze22 a écrit:

1600x1600 ça passe, mais 1000x1601 ne passera pas (tu peux le faire en plusieurs textures mais pas en une seule)

Ça me parait un peu petit, je viens de tester une surface de 8192*8192 et je n'ai pas eu de soucis. Au delà, des bugs graphiques apparaissent.

Pour ce qui est de l'estimation du volume qu'occupe une texture dans la mémoire, il faut à mon avis prendre en compte la présence ou non d'un canal alpha ainsi que le mode de compression utilisé (donc la profondeur de couleurs, en bits). Connaissant GM, le canal alpha doit être incorporé par défaut, et la profondeur de bits probablement poussée à son maximum.

Voici un petit lien qui pourrait t'intéresser:

Karl a écrit:

The weight of a texture in video memory is higher than at creation time,
because it is uncompressed before being used.

E.g, a 512 x 512 texture with an 8 bit alpha channel will take :
(512 x 512 x 32) / 8192 = 1024 kilobytes

Prenons un exemple en se basant sur les dires de nicoulas:

Citation :

Je peux faire du 2047*2047 maximum avec mes 64 mo de Vram.

( 2048 x 2048 x 32 ) / 8192 = 16384 kilobytes soit ~16 megabytes, soit un quart de sa mémoire vidéo.

Je ne connais pas toutes les subtilités du fonctionnement interne de GameMaker quant à l'usage et la compression des surfaces, mais ce mode de calcul me paraît digne de confiance.

Non je disais 2047*2047 en taille maximum de surface, pas de texture

En taille de texture, je dois pouvoir aller au delà (théoriquement 4096*4096 d'après ton calcul, mais ça voudrait dire que ça prendrait absolument toute la Vram, ce qui en pratique doit être à peu près impossible).

Question de vocabulaire. Une fois dans la Vram, que les textures soient issues d'une surface, d'une sprite ou d'un background, ce sont bien des textures.

Hmm oui mais je pense que tant qu'une surface est une surface (pas convertie en backgroud ou sprite) elle prend plus de Vram, ce qui n'est pas impossible puisque c'est en quelque sorte une texture dynamique.

Je suis d'accord, mais cette différence de volume provient probablement de la manière dont GameMaker streame différemment les textures selon la nature des ressources, plutôt que du mode de stockage pur qui est en fait certainement toujours le même.

Les données de ce mode de calcul se retrouvent dans pas mal de forums de développement et j'en ai moi même eu l'usage par le passé. Mais le problème est qu'on ignore tout de la manière dont GameMaker gère ses textures, et il est donc difficile de connaître les variables en jeu (pour tout ce qui est streaming, compression des couleurs, etc).

nicoulas a écrit:

Hmm moi 2047*2047 ça marchait parfaitement, et Bibi675 pouvait atteindre 2048*2048 je crois (avec affichage tout à fait normal).

Mince, pourquoi je ne peux pas, moi dépasser des background de 1600x1600 XD, je pensais que c'était GM qui me limitait car j'ai 256de Vram quand même donc bon, très étrange, mais je te crois bien sûr, je me demande juste pourquoi moi je ne peux pas XD
Peut être qu'une surface passe, mais pas un background de cette taille intégrée dans GM7 ?

Bast a écrit:

Topaze22 a écrit:

1600x1600 ça passe, mais 1000x1601 ne passera pas (tu peux le faire en plusieurs textures mais pas en une seule)

Ça me parait un peu petit, je viens de tester une surface de 8192*8192 et je n'ai pas eu de soucis. Au delà, des bugs graphiques apparaissent.

Pour ce qui est de l'estimation du volume qu'occupe une texture dans la mémoire, il faut à mon avis prendre en compte la présence ou non d'un canal alpha ainsi que le mode de compression utilisé (donc la profondeur de couleurs, en bits). Connaissant GM, le canal alpha doit être incorporé par défaut, et la profondeur de bits probablement poussée à son maximum.

Voici un petit lien qui pourrait t'intéresser:

Karl a écrit:

The weight of a texture in video memory is higher than at creation time,
because it is uncompressed before being used.

E.g, a 512 x 512 texture with an 8 bit alpha channel will take :
(512 x 512 x 32) / 8192 = 1024 kilobytes

Prenons un exemple en se basant sur les dires de nicoulas:

Citation :

Je peux faire du 2047*2047 maximum avec mes 64 mo de Vram.

( 2048 x 2048 x 32 ) / 8192 = 16384 kilobytes soit ~16 megabytes, soit un quart de sa mémoire vidéo.

Je ne connais pas toutes les subtilités du fonctionnement interne de GameMaker quant à l'usage et la compression des surfaces, mais ce mode de calcul me paraît digne de confiance.

Je suis d'ac avec ses calcules, mais GM7 et 6 n'ont clairement pas de canal alpha. Le seul moyen de gruger pour avoir un alpha par pixel est de se servir d'un mélange de couleur avec un mask dont le niveau de gris sera interprété lors de l'affichage comme un "pseudo canal alpha", mais ce canal alpha n'existe clairement pas, mais peut être qu'il pompe en mémoire comme si il y avait les bits du canal alpha quand même.




Je pense (à 50%) que GameMaker ne compresse pas les textures qui sont dans la Vram car cela voudrait dire perte de qualité dans certains cas, ou au minimum perte de puissance (car il faut décompresser à chaque boucle pour afficher [pas de doute, DirectX8 ne peut lire que des textures non compressée, pas sûr mais je ne suis pas sûr que ça ait éxister avant DirectX9, donc il faut qu'elles soient décompressé avant l'envoi dans le buffer], par contre avec DirectX11, on pourrait compresser sans aucune perte de perfs et quasi aucune perte visuelle (c'est le pied, m'enfin arrêtons despérer quelque chose que nous ne sommes pas prêt d'avoir, puisque d'après les vents des commentaires du blog, il semblerait plutôt logique à avoir prochainement OpenGL à la place de DirectX, et sachant qu'il y en a de deux sortes, je suppose que ce serait plutôt celle qui est rétrocompatible avec l'avant architecture à la DirectX10 [mais compatible aussi avec l'après, mais n'offrant que les possibilités de DirectX9]))

Citation :

Compression Memory consumption
DXTC1 RGB .5 Bpp (bytes/pixel)
DXTC3 RGBA 1 Bpp
RGB 16bit 2 Bpp
RGB 24bit 4 Bpp
Alpha 8bit 1 Bpp
RGBA 16bit 2 Bpp
RGBA 32bit 4 Bpp

To figure out total texture size: width * height * bpp

Add 33% if you have Mipmaps.

Très interessant Bast !
Ne sachant pas ce qu'est le Mipmaps je suis aller voir là : http://fr.wikipedia.org/wiki/MIP_mapping
Et sur GM, nous n'en avons pas donc pas besoins des 33%.
En ce qui conserne GM6 et GM7, je suppose que nous avons
ceci : RGB 24bit 4 Bpp
ou bien cela RGBA 32bit 4 Bpp
Dur de trancher sans regarder les codes internes de GM6et7, cependant, si GM8 pompe plus à cause du canal alpha, cela signifierait que les GM d'avant ne l'on pas, nous serions donc en ceci : RGB 24bit 4 Bpp sur GM7 et antérieur (et puisqu'ils ont dû refaire des codes, ça m'étonnerait vraiment que l'on ai un canal alpha).

GM8 pas de doute : RGBA 32bit 4 Bpp
Donc GM7 et avant, perso ça ne m'interesse plus trop de savoir maintenant puisque je passerais au 8 et que je sais de sûr pour le 8.
Pour GM8 :
320pixels * 320pixels * 4*4bits = 1,639 Mo de Vram (sauf peut être à l'initialisation), ça au moins, maintenant, ça m'a l'air sacrément sûr non ?


PS : Bon, encore un pavé, je vais encore me faire tirer les oreilles par Morgan :gniah:


EDIT : Bast, on n'ignore presque tout de comment GM gère ses textures, mais on sait juste cela : chaque texture a une priorités et si manque de Vram, le swappage dans la ram de la texture la moins utilisée et ayant la priorité la plus faible.


Ma source : la bible de GM en fr traduire par Xierra54 :
La texture choisie peut ne pas être actuellement en mémoire vidéo. Le système la chargera alors pour vous en cas de besoin mais parfois, vous souhaiterez le faire par vous-même. Pour cela, il existe les fonctions suivantes :

texture_preload(texid) Charge immédiatement la texture en mémoire vidéo.
texture_set_priority(texid,prio) S'il y a trop peu de mémoire vidéo, certaines textures seront temporairement retirées de la mémoire afin de libérer de la place pour permettre le chargement des textures nécessaires. Les textures de priorité la plus basse seront supprimées en premier lieu. Par défaut, toutes les textures possédent la priorité 0 mais il vous est possible de changer cette priorité à l'aide de cette commande (n'utilisez que des valeurs positives !)