BLOGUI BOULGA

*miam* le blog de Mawwic.

FAIRE DE LA 3D AUTREMENT ?

YouTube Preview Image

Petite vidéo trouvée sur Factornews, sur laquelle je serais curieux de recueillir vos réactions (a fortiori celles de ceux qui s’y connaissent en moteurs 3D). Tout ça est bien sûr à prendre avec des pincettes (qui a dit “vaporware” ?), mais je trouve que ça soulève 2-3 questions qui méritent réflexion.

Notamment, l’auteur de la vidéo - visiblement un peu parano’ - explique que NVIDIA et ATI barrent plus ou moins la route à ce genre de technologies, car eux fabriquent des cartes accélérant le traitement de polygones - ce dont son moteur permettrait de se passer. En réalité, comme me l’a fait remarquer divide via tribunes interposées, c’est sûrement un peu moins manichéen que ça vu que les constructeurs de cartes graphiques bossent aussi sur des méthodes de rendu utilisant autre chose que des polygones (notamment le Voxel et le Raytracing, voir ici).

Il n’empêche que tout cela pose une question intéressante: si survenait une telle technologie, impliquant cependant de tout remettre à plat, serait-elle pour autant adoptée ?
Le coût serait en effet énorme: changements hardware (les GPU devenant obsolètes, à moins d’être des hybrides CPU-GPU comme les générations à venir); nécessité de réapprendre jusqu’aux bases pour les programmeurs, là où la 3D polygonale avait créé un langage de base commun…
Et en face, il n’est pas dit que les avantages seraient si nombreux. Car si la 3D polygonale a ses défauts, elle ne me semble plus aujourd’hui véritablement un facteur limitant: il suffit de voir la taille et la qualité des environnements d’un GTA IV (rien que sur consoles) ou d’un Crysis pour se rendre compte qu’on parvient déjà à de suffisamment bien belles choses d’un point de vue purement technique. Le problème, désormais, me semble surtout être de savoir quoi faire de tous ces mondes et de toute cette technique (comment renouveler des mécaniques de gameplay vieilles de plusieurs décennies ? comment développer des formes de narration propres aux jeux, et non calquées sur le cinéma et la littérature ?) davantage que de trouver une solution technique pour les amener à la vie, comme ce fut la cas avec le développement des cartes accélératrices 3D à la grande époque des Matrox et autre 3Dfx.

11 commentaires pour “FAIRE DE LA 3D AUTREMENT ?”

  1. ng-aniki dit :

    Au final, à force de vouloir rendre sa vidéo accessible, il ne donne pratiquement aucune informations à part que c’est mieux que maintenant, et que c’est ‘le futur’. Pas la première fois qu’on entend ça.

    Je me demande comment sont fabriqués leurs modèles 3D, si ce n’est avec des polygones ?

    Enfin, à voir le truc, j’imagine que ce sont des modèles faits de polygones mais à très haute résolution ? (Genre un mesh bien subdivisé sous ZBrush)
    Ou alors ce genre de mesh transformé en xxxxx (je ne vois pas comment appeler un mesh qui n’est pas fait de polygones), j’imagine. Vu le poids des fichiers que nous sort zbrush par moment.
    A moins que les modèles soient fait de splines ?

    Même problème pour la texture.. Si il n’y a lus de texture ? Vu le système j’imagine que ce sont leurs points qui ont une couleur.

    Donc voilà, reste des problèmes en plus que ceux que tu as cité (hardware):
    -Le poid des fichiers (plus d’infos -> plus lourd, à moins de trouver un super moyen de compression rapide à décompresser).
    -La quantité de travail. Si la totalité des meshs de jeux étaient fait en high poly, ils mettraient bien plus de temps à faire. Je ne sais pas ce que ça donne côté animation par contre, si une animation high poly est beaucoup plus dire qu’avec du low ?
    -Les outils ? Pour les textures, si on utilise des textures: il faudra passer par des étapes inutiles si on veut les réaliser avec un bon soft comme photoshop (il faudra déplier les uvs, etc, alors que le mesh final n’en utilisera même pas). Sinon peindre en 3D comme dans ZBrush, mais je suis pas fan personnellement.

  2. Ze_PilOt dit :

    Comme pour les point cloud en précalculé, tu peux assigner des datas à chaque points : normales, couleurs, …

    Je vois deux principaux problèmes :

    - Il est bien gentil de dire qu’il n’a besoin qu’un point par pixel. C’est vrai, en précalculé, c’est comme ça qu’on fait aussi. Sauf que si tu zoomes, ben soit il y a des trous, soit tu compenses par la taille des points. Dans les deux cas, ca devient vite moche.
    Là où je veux en venir, c’est que dans un jeu 3d ou tu peux te coller à un object, il te faut une tétra-chiée de points par objet, et ca prend LA BLINDE de place.
    C’est pas un problème de mémoire vive ou de loading, en les voxels resolvent ça bien vite en stockant les données efficacement, c’est surtout un problème de place sur le disque dur.
    Ses pyramides de modèles sont instanciés, donc là ça va, mais son décor, je serais pas étonné qu’il prenne plusieurs gigas sur le hd.

    - L’animation. Oui tu peux bouger des points, mais les normales sont encodées dans le point. Ca demanderais donc un processus de calcul bien lourd (bien plus lourd que sur un poly) pour recalculer des normales dynamiquement sur un modèle.

    Donc à moins qu’il ait trouvé une solution magique (et comme on voit que des trucs statiques j’en doute), mort pour les persos..

    “Oui mais les décors ca peut etre génial” oui, sauf que adieu la physique sur les décors. Plus d’arbres qui bougent ou tombent, plus de murs qui éclatent… Bref, un bon bond en arrière.

    Et pour les jeux de stratégie par exemple, un batiment qui pop, ben tu peux meme pas le mettre comme tu veux (m’étonne pas qu’ils se sont fait gicler pour total wars)

  3. __MaX__ dit :

    En tout cas, si ils veulent vendre, même en tant que techno tierce… ils ont interet à se payer des artistes.

  4. skaven dit :

    J’attendais beaucoup de Larabee. Ca aurait pu être 1 révolution au même titre que la 3DFX en son temps. Mais les pipeline de production sont devenus tellement long, avec des années de maturation qu’une révolution me semble compromise.
    Le mieux que je vois, c’est du code spécifique type OpenCL pour certaines parties de rendu qui se généraliseront après.
    Du deffered rendering par exemple, du calcul de fluides/physique. Le rendu par triangle ne devenant qu’une partie du rendu. Après, que ce soit des triangles ou autre chose…
    Sur PS3, 1 partie du lighting de Killzone2 et God Of War3 est faite sur les SPU.
    On est pas pres de ne plus voir de triangles à un moment ou a 1 autre ;)

  5. LeGreg dit :

    NVIDIA et ATI seraient très heureux s’il implémentait sa technique sous forme de shaders (Cuda etc).

    Les GPUs actuels sont déjà pas mal pour le raytracing :
    http://www.youtube.com/watch?v=Cbnv_z6VDj8

  6. Wiz dit :

    Le problème pour l’instant avec le raytracing par gpu, est que la programmation gpu ne permet pas d’écrire un code aussi flexible que sur cpu; branchements et bouclages lents, pas de pointeurs donc pas de généricité possible et il faut décider au moment de la compilation du code tous les cas possibles.
    Parcourir des structures de données optimisées, faire bouger des objets, les animer, pire encore en instancier à la volée ; tout ça c’est encore trop pour des processeurs qui n’ont jamais été prévus pour effectuer ce genre de taches.
    J’attendais moi aussi beaucoup de Larabee qui aurait certainement pu nous permettre de passer outre ces difficultés.

  7. MathieuFROG dit :

    Concernant cette vidéo voilà ce que j’avais trouvé après avoir lu l’article de RPS :

    http://forum.beyond3d.com/showthread.php?t=47405
    Non seulement ca pointe vers une news qui date de 2008 mais il y’a aussi 3 posts pas très encourageants de Bruce Dell dans ce thread (’”Could some one please explain to me what memory cache is ?”).
    Le nom de domaine unlimiteddetailtechnology.com a été créé il y’a 6 mois mais ca pointe tjrs vers un hébergeur low cost… et leur email de contact pointe vers un @hotmail.com
    Pas très crédible.

    Cherchez un peu vous tomberez aussi sur son CV, il a pas un parcours très technique.

    Bref, ca sent le vapoware à plein nez.

  8. divide dit :

    Après faut s’entendre sur le définition de vaporware… Apparement le mec à quand meme un algo fonctionnel; mais comme je le disais dans la tribune factor à Mawwic hier et comme le résume très bien Ze_PilOt, ca ne me semble pas pertinent dans un contexte de JV pour toutes ces raisons, mais plus approprié à de la visualiation de données brutes dans un contexte scientifique ou industriel.

  9. Nafai dit :

    Dans le contexte scientifique/indu on a déjà ce type de technos depuis quelques temps déjà pour tout ce qui est collecte/stockage/visualisation de nuages de points (relevés lidar et autres). Ce moteur “unlimited” semble avoir les mêmes limitations ce qui fait que j’ai du mal à voir sa pertinence pour du jeu video.

  10. Mawwic dit :

    Merci à tous pour les (nombreux) retours.
    Effectivement y a plus d’un doute qui pèse sur la technique - et le type derrière n’inspire pas forcément une grande confiance.

    J’imagine donc que les polygones, on est pas prêt de s’en passer - surtout qu’ils permettent de faire déjà une bonne partie de ce qu’on souhaite dans les jeux aujourd’hui.

  11. LeGreg dit :

    Wiz a dit :
    Le problème pour l’instant avec le raytracing par gpu, est que la programmation gpu ne permet pas d’écrire un code aussi flexible que sur cpu; branchements et bouclages lents, pas de pointeurs donc pas de généricité possible et il faut décider au moment de la compilation du code tous les cas possibles.
    Parcourir des structures de données optimisées, faire bouger des objets, les animer, pire encore en instancier à la volée ; tout ça c’est encore trop pour des processeurs qui n’ont jamais été prévus pour effectuer ce genre de taches.

    C’est parce que tu raisonnes encore en terme de code “sériel”. Bien entendu quand les gens comme Epic ont du passer à la Voodoo 3DFX ils ont sans doute perdu des choses dans la transition et ils n’étaient pas content (et ils le répètent depuis quinze ans). Sauf que tout à coup, la 3D temps réel était devenu viable pour tout le monde.

    Et il ne faut pas brosser un portrait trop négatif, les modèles GPUs évoluent : prédication, coût de la divergence, cache cohérent, généricité (virtual functions et function pointers). Et la performance par watt consommé continue d’augmenter.

Laisser un commentaire

Si vous avez un compte sur WeFrag, connectez-vous pour publier un commentaire.

Vous pouvez, entre autres, utiliser les tags XHTML suivant :
<a href="" title="">...</a>,<b>...</b>,<blockquote cite="">...</blockquote>,<code>...</code>,<i>...</i>