Reprise du message précédent :

 là je me demande bien alors comment vas tu faire pour afficher ton jeu a l'écran ! ? peut etre que g zapper un partie du topic mais je ne crois pas. Qu'il n'y est pas de moteur physique je comprend mais pas de moteur graphique(ou 3D) célà me laisse perplexe.
 
egMIX n'a pas tor pour ce qui est de l'espièglerie...

 
Il suffit de demander gentillement à la carte vidéo.
 
Un moteur graphique n'est qu'une bibliothèque qui sert d'interface entre l'application et les bibliothèques graphiques ou API (OpenGL, Direct3D9, etc.) qui dialoguent avec la carte graphique via le driver. Le principal intérêt d'un moteur graphique, en dehors de l'abstraction de la partie technique, c'est par exemple d'ajouter des briques permettant de gérer les différents matériaux, gérer le niveau de détails etc.. de manière la plus transparente possible pour l'application. Pour caricaturer, tu n'as pas besoin d'avoir l'Unreal Engine 3 pour faire un Tetris.

Sans etre arogant biensur
 
Je crois pas que nous ayons la meme conception de la définiton de moteur graphique. Pour ma par un moteur graphique permet d'afficher l'ensemble de tes objets 3d en le projettant sur ton viewport (grossièrement), après libre a toi d'utiliser les librairie graphique que tu souhaite pour dialoguer avec ta carte graphique. non?
 
je suis d'acord pour faire un tetris tu n'est pas obliger d'utiliser l'Unreal Engine mais il existera quand meme un petit moteur graphique pour afficher l'ensemble de tes brique a l'écran (elle ne s'affiche pas miraculesement)
 
Donc comment vas tu, et par quel procédé, lui demander d'afficher gentillement ton univers 3d?
en gros, quand tu vas demander gentillement a ta carte graphique d'afficher ton univers 3d, tu vas créer un petit programme utilisant une bibliothèque graphique (opengl, directx,....) ? soit une moteur graphique
 

 
ça serai pas plutot l'éditeur qui s'en charge? sois une application utilisant le moteur graphique, permetant de parametrer et de grerer une multitude de paramètre.
 
je suis sur la bonne vois ou carrement a coté de la plaque?

J'vais répondre en essayant de rester compréhensible.
 

 
Pour afficher des objets 3D, tu effectues les opérations suivantes:
 
Pour chaque sommet, tu multiplies ses coordonnées par la matrice monde (position, rotation, échelle), puis par la matrice de vue (les paramètres de la caméra en somme), puis par la matrice de projection (la manière dont on projete vers l'espace de l'écran). Cette étape est effectuée au niveau de l'unité des sommets (vertex shader).
 
Ensuite, pour chaque pixel de ton objet, tu calcules la valeur du pixel suivant l'algorithme que tu veux (lambert, gouraud, phong, blinn, qu'importe).
 
Ca s'arrête là, en somme.
 
Un moteur moderne n'effectue pas cette tâche là ou il propose un effet déjà tout fait. Généralement, tu as toujours la possibilité de spécifier tes propres effets. Les moteurs plus anciens utilisent le pipeline fixe de l'API (pas de vertex shader/pixel shader paramètrables) et le style de rendu est beaucoup plus commun.
 
Généralement, un moteur expose certaines fonctions qui évitent au programmeur de faire tout ça "à la main". Il va par exemple demander un fichier contenant la partie programmable du pipeline ainsi qu'un modèle 3D par ex. A l'abris des regards indiscrets, il demande à l'API graphique d'utiliser le fichier d'effet avec le modèle que tu veux dessiner en utilisant les paramètres de vue/projection de la caméra, ce qui revient au même (ça prend légèrement plus de temps car tu ne communiques pas directement avec l'API).
 
L'intérêt d'avoir ces fonctions toute faite, permet d'afficher un modèle en utilisant par exemple la ligne DessineMonModèle(monModèle, monEffet), alors qu'à la main, ça va prendre une dizaine de lignes pour dialoguer directement avec l'API.
 
Un moteur graphique encapsule les bibliothèques de bas niveau et fourni des fonctionnalitées de haut niveau qui ne sont pas présentes dans les bibliothèques de bas niveau. Exemple, OpenGL ne sait que dessiner, rien d'autre. Ca ne sait pas multiplier des matrices ou quoi que ce soit, même pas charger une texture. Un moteur graphique utilisant OpenGL fournira des fonctions comme charger une image bitmap en mémoire, dessiner un torus en une ligne, fournir un objet représentant un vecteur 3D, etc..
 

 
Le terme "moteur graphique" c'est très buzz word. Pour des raisons pratiques, tu n'écris jamais des milliers de fois une dizaine de ligne pour faire la même chose. C'est en faisant une compilation de ces éléments qui reviennent souvent que tu construis plus ou moins un moteur. Après, le terme "moteur graphique" dans le sens Unreal Engine 3 par ex, c'est une encyclopédie de fonctions si tu veux, à l'intérieur, ça discute aussi en utilisant les bibliothèques graphiques.
 

 
Cf au dessus.
 

 
Non, car tu vois la chose comme un graphiste.
 
Si tu dessines un cube dans 3dsmax par exemple, et que tu assignes un matériel à ce cube. Une fois chargé dans l'application, tu es très content car il s'affiche très bien et c'est très rapide. Maintenant, si tu as envie d'afficher 200 cubes avec ce matériel et 200 cubes avec un autre matériel. Si tu envoies ça n'importe comment, le pire cas, c'est que tu dessines une fois sur deux un cube avec un matériel différent que le précédent. Quand tu fais ça, tu dois demander à la carte graphique de changer la texture et éventuellement l'effet que tu utilises pour dessiner le cube comme tu le veux. Un moteur lui, va par exemple trier tout ces cubes, et il va dessiner 200 cubes avec le premier matériel, puis les 200 avec le second matériel. De cette façon, tu vas éviter des centaines de changement de textures et ça va aller beaucoup plus vite. Maintenant, imagine une scène classique d'un jeu AAAA type Crysis. Tu as des millions de polygones, des effets de partout, du post processing, si tu dessines ça n'importe comment, non seulement tu peux avoir des bugs graphiques, mais en plus, ça va être super lent. Il n'y a pas que la gestion des matériaux dans un moteur graphique, ce n'est qu'un simple exemple. Pour un jeu type Crysis, des éléments comme cela, tu en as plusieurs centaines.
 
Si tu as d'autres questions, passe par les messages privés histoire de ne pas détourner le fil. :)

Merci de m'avoir eclaircies les idées ! je reprendrais le temps de relire corectement ce post et tu aurra s'en doutes des nouvelles de moi

J'ai le cerveau qui brûle ...  

---------------

FoxCoon
--------------------
Chibis Bomba Wip

Oouhao , Inverse ! C'est super intéressant et tu as été très clair.  
...
Mais tu nous a tout cramé notre FoxCoon

 
Ca va, il a refroidi assez vite
 
V'la deux screens du programme test:
 
Ecran de présentation:
 

 
Scène contenant les éléments de base:
 

 
Ce programme test sert avant tout à mettre en pratique le workflow artistes -> jeu. Notamment les conventions au niveau des échelles, des formats d'exportations etc..
 
Je mettrai un screen sur le type de rendu (probablement un p'tit toon shader fait maison) que l'on aura défini dans les prochains jours.

Jolie taf Inverse ! ça mets un pied dans la concrétisation au projet.
C'est bien agréable.
Aussi , j'aime bien le titre et la typo.  

Salut les gars !
 
Des nouvelles de votre petit projet?
 

On est toujours vivant !!

Ne vous inquiétez pas, nous étions tous très occupé pendant un p'tit moment et nous revoici, enfin, certains  

Voici un autre niveau, la mare d'après le croquis de Jérémy... Pour le moment, les textures ne sont pas encore créées, mais tous les objets sont déjà unwrappés.

---------------

FoxCoon
--------------------
Chibis Bomba Wip

cool vite vite la suite

Bien cool le design, super que le projet soit encore en vie

le niveau déplié...

---------------

FoxCoon
--------------------
Chibis Bomba Wip

Wouaahhh!!! Je n'avais jamais vu ce post avant (des fois j'ai pas les yeux bien ouverts...) et maintenant que je suis dessus je n'en décrocherais plus!
J'aime beaucoup le style graphique ainsi que l'idée.
Y a t-il eu des choix dans le moteur graphique? langage de développement?
 
Sinon je vous souhaite bon courage et à très bientôt !!!

Ces infos, verbalinsurection, tu les as un peu plus haut et sur la page précédente.  

---------------

FoxCoon
--------------------
Chibis Bomba Wip

Oups désolé...

Après la mare, la renarde (logique... ou pas)
 

trop mimi ^^
Quelques remarques (sinon c'est pas drôle) :  
-la mâchoire inférieure est un peu trop en avant à mon gout (ça lui donne un air un peu rustre....)
-les mèches noires et blanches font un peu "sales". A mon avis il faudrait accentuer les pointes blanches (des bords un peu anguleux) et alléger les noires (le noir ça le fait rarement).  
edit : - la peau fait un peu "plat" une petite texture (des pommettes, des lèvres, les tracé de certains muscles peut être ?)
 
Petite question : combien de poly et quelle est la résolution des textures ? (si possible hein )  
 
Très bonne chances pour la suite du projet et bon courage.

J'aime aussi, dommage que les taches de rousseur du visage ne soient plus là ! Bonne continuation en tous cas, ça donne envie de voir la suite !

je trouves les épaules et sa région très moles, ça manque de structure. Sinon pareil pour la mâchoir ainsi que pour les lèvres, un peu bizzares... sinon vous êtes à combien de poly pour le perso?