y'a-t-il dans la salle des personnes travaillant actuellement ou ayant travaillé sur des moteur 3D destinnée au temps reel pour les jeux video?
 
si oui, j'aurai quelques questions a poser en private (pas s'inquieter c'est pas des infos specifiques)

C'est pas un pléonasme ça ?

 
Non (un moteur 3D utilisé pour la CAO aura des besoins différents. On se fout (un peu) des fps, mais on veut pas le moindre pixel d'écart par rapport a la position de l'objet).
 

pourquoi en MP ? T'as des infos confidentielles ?
Non, parce que moi, je connais quelques trucs, mais de la, a m'engager dans une correspondance ...
a moins que tu ais tes raisons ...

Je sais bien, mais on parle pas de moteur 3D de CAO mais de moteur 3D de jeux video ...

ouai posez vos questions en public !
 
LeGreg

 
c'est plutot des question generale d'un mec qui s'est pas vraimlent penché sur certain truc en n'ayant pas a eu bosser pour du temps reel...
donc les question vont peut etre paraitre bien evidentes pour certains
 
1) pourquoi est-il preferable d'utiliser des format tel que le tga, le raw, plutot que tu jpeg ou du pgn, hormis le facteur quatilé, quel est la difference dans les temps de traitement des fichier, decompression, des formats comme le jpeg ou le gif demandent-ils plus de place en ram que leur equivalent raw (je parle d'occupation autre justement que chaque pixel de l'image avec leurs couleurs)
 
2)pourquoi le morphing demande plus de temps cpu que l'animation par bones (question conne)
 
3) l'animation par spline est-elle une bonne methode en terme de temps cpu pour remplacer le morphing par exemple pour les animations faciales?
 
 
desolé, ca fait tres nOOb, mais quand on est formé pour la 3D precalculé et l'imagerie de synthese pour les metrages, on y fait pas attention
 

Sous Q3, la différence de temps entre un screenshot TGA et un screenshot JPEG est assez importante, voir même trés élevée. Enfin il compresse aussi. En decompression, ca doit etre moins flagrant, mais quand même ... 30 fois par secondes, ca doit faire mal.

 
Dans un jeu, tu ne décompresses une texture qu'a son chargement sur le disque. Après, tu la manipules toujours comme surface, et donc décompressée (ou compressé par un format connu par la carte, style S3TC ou DXTC).

C'est vrai. Puisque maintenant que j'y pense, le même Q3 utilise le JPEG pour certaines textures, et tout ça dans un zip en plus ...

 
Ce sont des utilisations differentes:
- le tga (dans sa forme basique non compressée) est le plus simple a manipuler et il permet d'inclure un canal alpha ce qui n'est pas le cas du jpg. Comme il n'est pas compresse il est particulierement gourmand en place disque.
- le jpeg est l'un des formats les plus compacts pour les images en millions de couleur. Seul probleme il encode de maniere destructive (dans sa forme la plus agressive) et il entraine une grosse perte de sensitivite sur la teinte. De plus il ne peut pas stocker de couche alpha et il entraine des artefacts qui se voient lorsqu'il y a zoom sur la texture.
- le gif est tres limité: seulement 256 couleurs par palette ce qui le limite a des utilisations specifiques (pages web). On peut egalement profiter de la couleur transparente mais en pratique tous les hardware modernes emulent la couleur transparente par le canal alpha.  
- le png peut-etre compresse sans perte en millions de couleur et il inclut un canal alpha. par contre il necessite comme le gif et le jpeg une librairie externe pour le decompresser. Il peut encoder des images en millions de couleur mais comme il est non destructif par defaut il encode moins bien que le jpeg.
 
Conclusion ?
Il n'y a pas de conclusions: a toi d'utiliser le format qu'il te faut en fonction de tes besoins.
 
Au niveau de l'efficacite: les formes compressees sont le plus souvent plus compliquees a charger (plus de code, utilisation du CPU plus intensive), ce qui fait que si tu as vraiment de la place disque a revendre, il peut etre interessant de charger les textures dans un format natif a la plateforme :
tu peux meme inclure les niveaux de mipmaps precalcules avec un algorithme meilleurs que celui disponible au runtime, ou precompile dans un format compresse mais directement interpretable par le hardware (VQ, DXTC etc..) et tu n'as pas a faire tous les traitements lies a la plateforme (formats swizzled, changement dans l'ordre des lignes et des colonnes, changement dans l'ordre des canaux).
 
Note: je rajouterais le format DDS (si tu bosses sous DirectX),
le format OpenEXR (pour les images HDR) etc..
 

 
Affirmation hautement gratuite et non argumentée. J'aimerais que tu précises le domaine d'application : algorithmes utilises, nombres de bones, traitement des vertex en software ou hardware etc..
 

 
Tout depend de ce que ton moteur d'animation temps reel est capable de faire. Si tu as un mapping parfait logiciel de modelisation -> moteur de rendu temps reel, c'est parfait  
mais la plupart du temps ce n'est pas possible et donc tu limites tes exports a ce que supporte ton moteur (ca peut t'amener a sampler tes animations pour faire du morphing ou bien a ajouter des cles en interpolation linéaire pour tes bones).
C'est la meme chose si ton moteur ne connait pas l'IK, les moteurs physiques du solide, fluide ou de vetements etc..
 
A+
LeGreg

 
on parle de morphing pour des personnages avec une nombre de vertice depassant les 5000. il y a pour manipuler le meme personnage 23 bones. le morphing se faire par le CPU principal, le mouvement des bones aussi, mais le replacement des vertices par rapport aux bones se ferait sur la CG. donc je parle d'un morphing pour animer le personnage tout entier, pas simplement des petites zones

 
 
quand je parle d'animation par spline, c'est coller quelques splines sur un modele polygonal . Les control point de ces spline serviront de deformers sur la zone du maillage ou elle se trouvent, genre avec une spline, la leve inferieure.
 
regarde cet exemple, les points en rouge fonce sont les points de controles des splines (attention divx 5):
http://durandal2.free.fr/kop.avi

 
Y'a quoi comme carte qui gere le VQ ??

 
si je te dis PowerVR ca te dit quelque chose ?
 
LeGreg

 
tu peux faire un morphing de base sur la carte graphique (ca s'appelle du tweening).
 
Ceci dit, le morphing c'est un peu pourri par rapport au skinning, le seul intérêt c'est qu'il est justement très léger en utilisation du processeur hôte, mais en contrepartie il faut dupliquer beaucoup plus d'informations.
Donc si tu compares les oranges avec les oranges, c'est à dire un traitement sur le processeur hôte, alors le morphing (ou tweening) est le plus rapide.
 
LeGreg

 
rah crotte, fallait que ca tombe sur une carte de faible diffusion
 
Rien de prevu chez ati/nvidia de ce cote la ?

 
Je ne connais pas tout mais je ne crois pas que des moteurs du marche le supporte.
Ce que j'ai vu d'animation faciale utilisait des bones (tendance haute).
 
Tu ne peux pas être plus spécifique sur ton projet?
Ce que tu fais, de quoi tu disposes, si tu cherches a programmer un moteur ou je ne sais quoi?
 
LeGreg

 
Faible diffusion, tout est relatif
mais riche en technologies exotiques
ca c'est sur.
 

 
La compression est un peu le parent pauvre de la course au bandwidth j'ai l'impression.
Le probleme c'est qu'il faut un algorithme qui soit
de faible latence, parallelisable et a debit constant.
Et vu qu'on s'oriente vers des textures avec des floats de 16 bits par canaux, glps..
 
<reveur>cette course folle va bien finir par s'arreter un jour..</reveur>
 
LeGreg

compression/decompression des textures flottantes..
 
Non rien..
 
LeGreg