Discussion :

[I_Pnose]

Mais 10k de polys par modèle ça me semble beaucoup.

Non c’est la norme. Pour t’en convaincre tu peux, via un petit viewer, jeter un œil sur les meshs des jeux auxquels tu joues (si tant est que tu joues sur PC et que les jeux en question ne datent pas du siècle dernier).

Pour ton histoire de sprites, généralement il vaut mieux un gros mesh que plusieurs petits. Je ne sais pas comment tu les gères, mais fut un temps où j’avais la même problématique et je fusionnais mes sprites dans un seul et unique mesh et j’envoyais ce dernier à la CG. C’était le stade zéro de l’optimisation, après il y a des techniques plus modernes (et efficaces) de batching.

[LittleWhite]

Je doute fort qu'un moteur de jeux puisse afficher 95 000 poly avec un FPS correct, je ne connais d'ailleurs pas le nombre maximum de poly que peut afficher un moteur de jeux sans que ça saccade mais en tout cas, moi, avec plus de 10 000 polys par frame ça commence à ramer.

Avec l'UDK, on pouvait monter à 500 000 triangles sur des 6800 GT. Mais bon, là, le jeu était tout de même à optimiser Mais il tournait bien tout de même.

[guitz]

Avec l'UDK, on pouvait monter à 500 000 triangles sur des 6800 GT. Mais bon, là, le jeu était tout de même à optimiser Mais il tournait bien tout de même.

Bon 500000 triangles ça correspond à environ à 250000 polys (bon ok 1/10e de mes polys sont des triangles avant que UDK ne convertisse le tout en triangles mais jai la flemme de faire le calcul, on va pas chipoter, si x nombre de poly 2x = nombres de triangles)

Donc en effet mon perso cest environ 200 000 triangles et à lui seul il occupe la moitié de la scène !
Par contre j'ai une mauvaise nouvelle les gars, la dernière sauvegarde lowpoly que j'ai de ce modèle c'est celle ci



Là j'ai déconné ! Et pourtant c'est pas mon premier modèle déstiné à un jeu vidéo, jusqu'à présent pour mon projet j'ai modélisé vaisseau, et scooter futuristes de mon héros et j'ai pensé à conserver plusieurs versions (low, mid, et highpoly).
J'étais pris dans mon élan hélas. Je sais pas si j'ai le courage de retravailler le maillage. tant pis je vais éventuellement essayer de vendre ce modèle sur internet, car je doute que l'auteur de ce topic veuille d'un maillage aussi dense

[guitz]

Ton High Poly est très bien (et nécessaire) pour en extraire une normal map, mais le modèle à intégrer dans le jeu devra idéalement être 10 fois moins dense que ça.

Un petit article intéressant montrant le workflow de création d’un perso de jeu vidéo : http://www.paultosca.com/makingofvarga.html

Merci , article intéressant.

toutes les étapes du processus sont encores d'actualité ? Car l'article date quand même de 2007

[honosstoa]

je viens de regarder avec l'option "stats" de unity et j'ai 2,5M vertices et 2,5M tri pour le village ( pas terrible ) avec un maximum de 850 drawcalls
Il n'y a aucun matériaux particuliers genre normal map ou autre, juste des textures .(sauf pour le perso principal)
Sinon pour ma map où je teste les combats j'ai du 200k poly et 200k tri

à guitz:

je doute que l'auteur de ce topic veuille d'un maillage aussi dense

non désolé un perso avec 200k poly je peux rien en faire.
Bon courage pour le vendre

PS: je me souviens d'il y a 3~4 ans quand je m'amusais avec l'opengl je faisais tourner un générateur de particules avec 1M de triangles sur mon ordi qui date de 2004 (compaq R4000 CPU 800 mhz et ~750 mo de ram). Donc en 2014 je m'inquiète plus trop du nombre maximum de poly... (même si c'est clair que je dois réduire le polycount du village)

Edit:
euhh... oui je voulais dire 200k triangles désolé

[guitz]

il a 100000 poly et donc 200000 triangles

Utilises tu le LOD pour ton village ? Si tu veux optimiser ta scène ça fait partie des bases

[honosstoa]

Non j'en avais jamais entendu parlé, tu parles bien de ça? (parce que j'ai que la version gratuite d'unity donc c'est mort)

[guitz]

Oui je parle de ça et c'est ce qui m'a (entre autre) fait migrer de Unity non pro vers UDK.

Je m'auto cite depuis http://www.developpez.net/forums/d13...uter/cpp-jeux/

Salut Skeud,

C'est ce que je voulais faire au début, mais je ne peux louer unity pro uniquement un mois, car c'est minimum un an, soit 70 * 12 = 840 euros, alors que pour Unreal Engine 840/19 = 3.68 ans !
Je pense qu'il n'y a pas photo d'autant plus que je voulais tout de suite un terrain (landscape) de très bonne qualité pour ma première map en extérieur, donc si j'avais choisi Unity il me fallait tout de suite la version pro (car le superbe asset "terrain composer" nécessite cette version ).
Autre arguments en faveur de Unreal Engine : le rendu est potentiellement de meilleure qualité qu'avec Unity pro et la communauté bien que numériquement inférieure à celle de Unity est tout de même consistante (pas mal de tutos sur youtube, un forum pas mal fréquenté, etc ...).

Donc je conseille à toute personne qui veut se lancer sérieusement en "autodidacte" dans le dev de jeux vidéos 3D de se prendre Unreal Engine 4

[I_Pnose]

je viens de regarder avec l'option "stats" de unity et j'ai 2,5M vertices et 2,5M tri pour le village ( pas terrible ) avec un maximum de 850 drawcalls

Oui, c'est un peu beaucoup ^^
Je t’avais déjà fait la remarque il y a quelques mois de ça que tu avais modélisé bien trop de détails sur tes maisons. Des détails qui auraient très bien pu se retrouver sur une normal map. Tu aurais ainsi économisé 99% de ton budget maillage (surtout que de souvenir tu avais même poussé le vice jusqu’à modéliser les tuiles de tes maisons... ce qui doit multiplier les drawcalls si tu n'as pas le batching d'activé).

Il n'y a aucun matériaux particuliers genre normal map ou autre, juste des textures .(sauf pour le perso principal)

Attention, ce n’est pas parce que tu n’utilises pas un shader "avancé" que tu n’utilises pas de shader tout court, le matériau "Diffuse" de Unity permet de plaquer une texture sur un modèle, mais ça reste un programme qui s’exécute autant de fois qu’il va y avoir de sommets sur ton modèle (pour la partie vertex shader). Donc sur un modèle de 100 triangles et sur un modèle de 100000, ton simple placage de texture ne va pas avoir le même prix. C’est d’ailleurs pour cela qu’un shader plus complexe (type diffuse map + normal map + specular map + height map) sera toujours moins gourmand sur un maillage léger qu’un shader simple (diffuse map) sur un maillage beaucoup plus dense (en d’autres termes, même si le traitement du pixel shader est plus complexe, la boucle est plus courte car il y a moins de sommets à traiter).

toutes les étapes du processus sont encores d'actualité ? Car l'article date quand même de 2007

L’article date, certes, mais le workflow est toujours valable ^^
Cela dit, en 2014, on peut encore complexifier le truc ; en plus d’extraire la normal map (qui va donc permettre de calculer, au texel prêt, les rebonds de la lumière sur un modèle et donc simuler une topologie qui n’existe pas), on peut aussi extraire une height map qui va permettre d’extruder les texels à la perpendiculaire de la normal (et donc rajouter encore davantage de réalisme). Cette technique s’appelle le parallax mapping, elle est très largement utilisée dans les jeux vidéo, et représente le minimum syndical à l’heure actuelle.

Après il y a le displacement mapping (épaulé par de la tesselation) pour encore davantage de réalisme... mais globalement le workflow ne change pas beaucoup.

Pour te donner une idée voila la technique du parallax mapping sur un quad (deux triangles) :


La même technique en situation réelle :


Bref, voila comment on se passe de détails sur un maillage et comment on délègue tout ça aux textures (via les shaders) ^^.

[Dabou Master]

Je prends pour base qu'un moteur normal (c'est à dire un vrai moteur qui est solide et encore sans être extraordinaire) peut afficher 300k polys (mais bon dans le sens triangles, ce sont des polygones aussi ^^ c'est juste pas des quads), si Unity ne peut pas faire ça c'est qu'il y a un gros souci avec ce moteur tout de même.
Après la version gratuite est bien là pour pousser à acheter la version pro donc ça me surprend pas que ça soit inutilisable dès qu'on veut faire un truc un minimum chiadé.

@Lolilolight : non c'est vraiment pas grand chose 10k poly, les devs sont vraiment en retard sur ce forum ^^, mais peut-être es-tu un rétro-gamer dans l'âme ? 10k c'était le "next-gen" mais ... il y a plus de cinq ans, malheureusement ça reste la norme mais c'est surtout à cause de la montée en puissance (uniquement sur le plan économique) de la console de salon, qui elle galère facilement sur le plan graphique. Du coup on reste sur des maillages assez pauvres, mais on est souvent dans le 30k pour un gros jeu fait par une vraie équipe. 10k c'est raisonnable pour un jeu indépendant, mais si c'est un moteur fait maison qui ne peut pas afficher des modèles à 10k (+ la scène + les autres persos et accessoires etc.) alors c'est que ce moteur est trop bas de gamme pour du graphisme actuel. Après les moteurs, si j'ai bien compris, c'est pas le truc le plus facile à coder ^^.

@honosstoa : Bon le temps que j'écrive I_Pnose est passé par là et je suis encore obligé d'appuyer ses dires (il m'éneeeeerve !!!!!! ^^), 2,5M c'est pas gênant pour une scène, mais celle-ci devrait être sacrément plus chargée pour un polycount pareil, avec des graphismes beaucoup plus fouillés, et donc les maisons pompent en effet un énorme budget en polygones. Après c'est pas grave, c'est vite récupéré ça, faut juste simplifier les maisons et le plus compliqué est déjà fait, par contre la normal map d'après mes expériences ... j'ai peur que ça se finisse dans les larmes et le sang, surtout niveau tuiles ^^. C'est pas évident de faire de bonnes normal maps avec des éléments de décors et du hardsurface, vraiment pas facile. Que la scène soit lourde c'est pas un problème seulement si t'as des options de culling et LOD c'est sûr ... mais apparemment là c'est pas possible ^^, mais de là à faire un village couloir pour palier ce souci, je trouverais ça dommage ... Il va falloir des compromis là mon vieux.

@I_Pnose : Alors là merci ! Je crois que tu viens de m'expliquer pourquoi on me donne la possibilité de plaquer ma texture sur un plan ou sur un plan subdivisé, j'imagine que c'est pour tester le temps que la texture met à s'afficher sur un modèle plus lourd en polygones ... Enfin je reste dans l'hypothèse, j'ai pas assez d'une vie pour comprendre tous ces foutus logiciels ...
Par contre t'es sûr pour ton parallax mapping ? Je suis pas du tout convaincu que ça soit fréquemment utilisé, et le displacement c'est pareil, c'est une technique largement utilisée en high-poly (donc pas pour du temps réel) mais c'est beaucoup plus lourd que la tesselation et ça me surprendrait qu'on utilise les deux (qui ont au final le même but mais j'avoue que je suis peu renseigné sur comment utiliser tout ça).
C'est juste que les height maps c'est tellement gourmand en polygones (enfin on m'a compris) que ça me paraît juste suicidaire de mettre ça dans du temps réel ...
Mais après c'est aussi tordu les cartes graphiques de nos jours, une unité de calcul rien que pour la tesselation, même si ça reste du triangle, c'est cette unité qui va faire tout le boulot là dessus mais ... pas le rasterizer ? J'ai essayé plusieurs fois de comprendre ces sales bêtes mais je crois que les ingé des cartes graphiques resteront toujours pour moi des savants fous ^^.

[I_Pnose]

Par contre t'es sûr pour ton parallax mapping ? Je suis pas du tout convaincu que ça soit fréquemment utilisé, et le displacement c'est pareil, c'est une technique largement utilisée en high-poly (donc pas pour du temps réel) mais c'est beaucoup plus lourd que la tesselation et ça me surprendrait qu'on utilise les deux (qui ont au final le même but mais j'avoue que je suis peu renseigné sur comment utiliser tout ça).

Affirmatif, le parallax mapping est une technique de rendu qui s’est démocratisée il y a presque 5 ans maintenant. Même mon petit tower defense en use et en abuse ^^ (sauf que comme je suis mauvais en modélisation, ça ne se voit presque pas =P).

Pour le displacement mapping c’est effectivement plus récent (et encore... on en voyait déjà dans Crysis 2 et les jeux de la même génération), le principe est le suivant : le GPU va subdiviser le maillage de base (c’est cette étape qu’on appelle la tessellation) puis va déplacer les sommets fraichement créés en fonction de la height map fournie. Comme tout est géré directement par le pipeline programmable du GPU c’est beaucoup plus rapide que si un véritable modèle high poly avait été bufferisé par le CPU puis envoyé au GPU (mémoire, latence due au transferts et drawcall sont économisés).
Ca reste tout de même plus gourmand que le parallax mapping ; cette technique ne déplace (et ne crée) aucun sommet, elle se contente juste de déplacer des texels en fonction du niveau de gris de la heigh map fournie.
Un exemple de displacement mapping sous le Cry Engine



Une petite vidéo (en français) illustrant le principe avec Unity :

[guitz]

@honosstoa : Que la scène soit lourde c'est pas un problème seulement si t'as des options de culling et LOD c'est sûr ... mais apparemment là c'est pas possible ^^, mais de là à faire un village couloir pour palier ce souci, je trouverais ça dommage ... Il va falloir des compromis là mon vieux.

C'est pour ça que je lui ai conseillé de se mettre sur UDK qui ne coute "que" 19 euros par mois (3 fois moins qu'Unity Pro !) Pour un rendu graphique supérieur...
Si à terme il veut rendre son jeu commercialisable bien sûr...

[Invité]

J'utilise le sprite batching dans mon moteur en regroupant tout les polys utilisant la même texture et le même type de primitive pour limiter au max les drawcall, mais bon il y a sans doute quelques autres optimisations à faire, je pourrai peut être essayer d'effectuer les transformations côté CPU plutôt que côté GPU en faisant un update des vbos... (J'utilise glLoadMatrix et glMultMatrixf là pour le moment sans savoir vraiment ce qui est le mieux)

Maintenant je n'ai jamais vraiment essayer avec beaucoup de poly à vrai dire, vu que je n'ai fais que d'afficher des sprites en 2D pour l'instant, il faudra sûrement que j'optimise encore un peu lorsque j'afficherai de vrai objets 3D.

J'utilise aussi beaucoup de shaders (normal mapping, heightmapping, etc...) ce qui me permet d'éviter de devoir faire du z-sorting ce qui est plutôt galère à faire surtout lorsque on a des entités semi-transparents qui sont en intersections, il faut alors découper les entités et recalculer les zOrder ce qui est lourd.
Et puis je pense que avec des shaders il y a largement moyen de réduire le nombre de poly.

[I_Pnose]

C'est pour ça que je lui ai conseillé de se mettre sur UDK qui ne coute "que" 19 euros par mois (3 fois moins qu'Unity Pro !) Pour un rendu graphique supérieur...
Si à terme il veut rendre son jeu commercialisable bien sûr...

Avant de parler de changer de moteur il convient déjà d’adopter les bons réflexes quant à l’optimisation de ses scènes. Quel que soit le moteur, s’il est mal utilisé, ça ne donnera rien de bon ^^

Ensuite, UDK est gratuit (et repose sur la version 3 de l’Unreal Engine), le produit vendu à 19€/mois c’est l’Unreal Engine 4.

UE4 est une référence dans l’industrie et représente très certainement ce qui se fait de mieux en termes de rendu (pour un moteur à dimension studio et indie j’entends). Maintenant il n’a pas que des avantages sur Unity. Lorsque j’ai fait ma veille pour déterminer quel moteur correspondrait le mieux à mon besoin, j’ai écarté (à contre cœur) UE4 pour plusieurs raisons ;

• Il faut une machine de malade pour faire tourner correctement le bousin (un petit laptop dans le train pour continuer à bosser c’est très compromis avec ce moteur).
• Certaines plateformes ne sont pas accessibles avec UE4. Qu’il ne soit pas dispo sur Xbox One je m’en fiche un peu, par contre que Windows Phone soit évincé c’est déjà plus gênant pour moi. Plus globalement Unity garde son avance sur le mobile.
• Enfin, Unity c’est 1500$ (soit 1200€) une seule fois, alors que UE4 c’est 19€ + 5% des revenus générés. Avec ce dernier on peut très allègrement dépasser la barre des 1200€ de charges (à titre d’exemple écœurant, si Flappy Bird avait été développé avec UE4 les royalties auraient représenté dans les 60000$... par mois).

Bref, le choix du moteur est parfois un débat sans fin, mais là, une chose est sûre, il y a des choses à faire en amont déjà.

[guitz]

Avant de parler de changer de moteur il convient déjà d’adopter les bons réflexes quant à l’optimisation de ses scènes. Quel que soit le moteur, s’il est mal utilisé, ça ne donnera rien de bon ^^

Je n'ai que très peu d'expérience dans le développement de jeu vidéo (à peine un mois) donc je peux me tromper, mais il me semble que dans une grande scène ouverte comme la sienne (village), le premier reflexe d'optimisation (en dehors d'améliorer ses meshes, de mettre des normals map là où ou doit économiser des polygones), c'est je pense le LOD. Mais sa version free d'Unity ne le permet pas.

[guitz]

Ensuite, UDK est gratuit (et repose sur la version 3 de l’Unreal Engine), le produit vendu à 19€/mois c’est l’Unreal Engine 4.

Au temps pour moi je parlais bien de Unreal Engine 4, je pensais que UDK = UE4

Enfin, Unity c’est 1500$ (soit 1200€) une seule fois, alors que UE4 c’est 19€ + 5% des revenus générés. Avec ce dernier on peut très allègrement dépasser la barre des 1200€ de charges (à titre d’exemple écœurant, si Flappy Bird avait été développé avec UE4 les royalties auraient représenté dans les 60000$... par mois).

Certe, mais la probabilité qu'un autodidacte indie "amateur" arrive à percer sur le marché des jeux vidéo avec son jeu est très mince, UE4 permet donc de tenter sa chance à moindre à frais

[I_Pnose]

Je n'ai que très peu d'expérience dans le développement de jeu vidéo (à peine un mois) donc je peux me tromper, mais il me semble que dans une grande scène ouverte comme la sienne (village), le premier reflexe d'optimisation (en dehors d'améliorer ses meshes, de mettre des normals map là où ou doit économiser des polygones), c'est je pense le LOD.

Je ne remets pas du tout en cause ce que tu dis, je soulignais simplement qu’en l’état un changement de moteur ne réglerait pas grand-chose, au pire il masquerait des défauts d’optimisation (or on en voit déjà bien trop dans des projets soi-disant pro).

Mais sa version free d'Unity ne le permet pas.

Oui et non. Je n’ai pas rebondi sur le fait qu’Unity free ne proposait pas de LOD par défaut, mais il est à noter que sur le store -pour 5$ en moyenne- il y a des solutions pour Unity Free parfois meilleures que celle proposée par défaut avec Unity pro (même chose pour l’occlusion culling dynamique, les effets post-process et un tas d’autres choses).

Certe, mais la probabilité qu'un autodidacte indie "amateur" arrive à percer sur le marché des jeux vidéo avec son jeu est très mince, UE4 permet donc de tenter sa chance à moindre à frais

Tout à fait. J’ai été très subjectif dans les inconvénients que j’ai énoncés (là en l’occurrence, je donne déjà 30% de mes revenus à Microsoft, je n’avais pas forcément envie d’en donner 5% de plus à Epic). Pour d’autre ça pourrait être le fait que UE4 ne propose que le C++ pour scripter leur jeu, là où Unity propose le C#, le JS et le Boo. Ou alors la relative complexité de UE4 par rapport à Unity ; le néophyte sera peut-être affolé à l’idée de recompiler le moteur à partir des sources fournies (le jour où un patch sort, par exemple, ce qui arrive souvent vu que UE4 est relativement jeune).

Bref, tout ça pour dire qu’à un certain niveau, Unity et UE4 permettent de faire la même chose, et que pousser un changement de moteur à ce stade n'est pas justifié AMHA (du moins, si l'OP trouve des avantages certains à Unity sur la concurrence).

[Invité]

Il n'existe pas de moteur parfais répondant à tout les besoins, car, il y a beaucoup trop de besoins à l'heure actuelle vu le grand nombre de plate formes différents et de contraintes, (je ne ferai pas mon propre moteur si c'était le cas), m'enfin bref, la difficulté est parfois tel dans le choix des moteurs qu'on peut se retrouver bloqué à un moment donné si on ne fais pas le bon choix, et quand il faut commencer à chipoter dans le code source du moteur. :aïe.

Je préfère en refaire un dans ce cas là.

Maintenant bien sûr le choix dépend fortement surtout de la plateform sur laquelle on veut faire tourner le jeux.

Pour les plateformes microsoft je pencherai plutôt pour un framework microsoft, pour les plateformes libres, je pencherai plutôt pour un framework opensource, maintenant, pour les système portables ça dépend, mais dans le domaine du libre, ou peut souvent hésiter entre unity, unrealengine et un tas d'autres moteur qui existe, si tu as de la chance tu ne dois pas changer de moteur ou bien changer le code source du moteur.

[honosstoa]

Salut,

Oui, c'est un peu beaucoup ^^
Je t’avais déjà fait la remarque il y a quelques mois de ça que tu avais modélisé bien trop de détails sur tes maisons.

Ouaip, ça fait partie des choses à faire. Oui j'avais modélisé chaque tuile et chaque pierre de la maison, donc elles font dans les 25 k triangles chacunes. C'est vrai qu'il y pas mal de gaspillage mais c'est pas le pire, mon gros problème c'est les arbustes qui font 13 k tri chacun et j'en ai une centaine dans la scène.
(En plus de ça le village est trop grand, et avec un ordi faiblard les meshs éloignés de la caméra apparaissent vachement crénelés, donc là aussi je vais devoir faire quelque chose...)
Bref j'ai un paquet de choses à améliorer ^^

Attention, ce n’est pas parce que tu n’utilises pas un shader "avancé" que tu n’utilises pas de shader tout court, le matériau "Diffuse" de Unity permet de plaquer une texture sur un modèle, mais ça reste un programme qui s’exécute autant de fois qu’il va y avoir de sommets sur ton modèle (pour la partie vertex shader). Donc sur un modèle de 100 triangles et sur un modèle de 100000, ton simple placage de texture ne va pas avoir le même prix. C’est d’ailleurs pour cela qu’un shader plus complexe (type diffuse map + normal map + specular map + height map) sera toujours moins gourmand sur un maillage léger qu’un shader simple (diffuse map) sur un maillage beaucoup plus dense (en d’autres termes, même si le traitement du pixel shader est plus complexe, la boucle est plus courte car il y a moins de sommets à traiter).

J'me coucherais moins c*n ce soir

à dabou:
Perso je pense que c'est faisable avec une normal map: je modélise le plus gros avec 50~100 polys et je fais les détails avec la normal map.(faudra que j'essaye tout ça)
(après relecture: je parlais bien sur des tuiles ^^)

à guitz:
C'est sympa de me le proposer, mais j'ai pas besoin d'UDK ou de UE4 ou de n'importe quoi d'autre pour l'instant. Déjà parce que même 20€/mois avec mon budget étudiant je vais le sentir passer, et ensuite parce que je trouve qu'unity est vachement bien foutu.

Bon sinon j'ai enfin réussi à charger un fichier .obj avec webgl page de test (j'avoue que j'aurais du commencer par lire un tuto php/js, mais bon ^^)
(Merci à ceux qui ont traduit les tuto de learningwebgl.com, j'ai déjà du mal à comprendre ce machin en français alors si en plus ça n'avait pas été traduit... )
Bonne soirée/nuit!

[Dabou Master]

à dabou:
Perso je pense que c'est faisable avec une normal map: je modélise le plus gros avec 50~100 polys et je fais les détails avec la normal map.(faudra que j'essaye tout ça)
(après relecture: je parlais bien sur des tuiles ^^)

Oula, toi ... tu t'es pas encore assez cassé les dents sur les normal maps pour dire ça !

Non plus sérieusement j'espère pour toi que ça se fera sans mal mais... Moi perso j'ai jamais réellement réussi à obtenir ce que je voulais avec des cas comme ça alors je te souhaite de réussir du premier coup et de pas tomber en dépression comme moi ^^.

@I_Pnose : Merci pour toutes tes précisions sur le parallax et autres, va falloir que je potasse tout ça, plus j'en apprends ... plus il y a à apprendre ...