Alors me voilà parti pour un petit message fleuve, je médite ces questions depuis bien longtemps maintenant, et ayant parcouru votre forum dans tous les sens, il arrive un moment où il faut se lancer.

Je suis actuellement en école d'ingénieur en informatique, 1ère année, avec deux anées de C++ derrière moi. J'y ai découvert Java qui m'as complètement dégouté de C++. Avec plusieurs amis, nous avons décidés de nous lancer dans un bon gros projet, plus ou moins dans le cadre de nos études. Connaissant déjà un peu Irrlicht (réchapé de ma période C++), je me suis tourné bien vite vers ce moteur de rendu. Réticent à utiliser à nouveau le C++ et ses environnements de développement qui font tâche comparé ne serait-ce qu'a Eclipse, je me suis tourné finalement vers IrrlichtCP. Je découvre donc le C#, ce qui ne change pas des masses de java. Maintenant, plusieurs questions me taraudent.

1. (Question déjà vu 100 fois je suppose) le jeu que je souhaiterais développer serait un jeu de course 3D futuriste (ne riez pas) très rapide. Pour celà, il me faudrait la possibilité d'afficher des (très) grands circuits, quelques vaisseaux et quelques effets à un framerate suffisant(>60 fps), avec si possible une qualité sympas (disons niveau Quake 3 si possible). Irrlicht de base sera-t'il suffisant pour celà ? Si oui, sera-t'il possible au terme du développement de toucher directement au code du moteur pour tenter de l'accélerer encore plus (par exemple en limitant l'affichage à OpenGL) ?

2. Je me doute que la réponse à la question 1 sera du type "ça dépend de ce que tu veux afficher", d'où ma seconde question. Selon vous, un mesh agréable à l'oeil, c'est combien de polygones ? ça se compte en centaines ? milliers ?

3. Je me perds un peu lorsque l'on s'attaque à la modélisation des vaisseaux. En regardant les logiciels de modélisation, énormément de fonction sont présentes, dont certaines devraient être gérées par Irrlicht à la base. Je me pose donc cette question, jusqu'où faut-il aller au niveau de la modélisation ? Par exemple, je suppose que les shader ne sont pas à définir dans maya directement non ? A priori, je dirais que les modèles 3D devraient contenir les meshs, les textures, et les animations. Quelque chose à rajouter ?

4. J'ai été assez déçu de ne pas trouver des articles de bases sur la représentation physique des éléments de irrlicht. Un exemple tout bête, j'ai du écrire un code à la main pour me rendre compte que le vector3d de rotation contenait les angles de rotation en degrés (d'ailleurs qui as eu cette idée lumineuse ? ). Auriez-vous un lien ou un livre expliquant les bases soit de Irrlicht, soit des moteurs 3D en général, avec si possible les maths qui vont avec ?

5. Histoire d'avoir des mouvements fluides et "réalistes", nous avons décidés d'intégrer un moteur physique (ODE dans notre cas). A priori, d'un point de vue physique, notre projet devrait être relativement facile (collision d'une boite englobant le vaisseau avec le niveau, application de forces prédéfinies au niveau des moteurs), voir même que ça simplifierai fondamentalement le code (par exemple, appuyer sur une touche ne revient qu'a allumer les moteurs, et donc à appliquer une force). Mais après avoir parcouru votre forum, notamment le post traitant de la voiture et des joints, je me rends compte que le tableau idyllique que je m'en faisais ne sera peut-être pas si joyeux. Pensez-vous que c'est du suicide à mon niveau de me lancer là dedans ?

Je sais que j'avais beaucoup d'autres questions à vous poser, mais l'heure tardive n'aidant pas, je vais déjà en rester là. Comme vous l'avez compris, nous en sommes encore au niveau de la spécification du projet, mais j'ai déjà l'impression d'avoir appris énormément (que ce soit au niveau code, c#, irrlicht, ODE, de la gestion de groupe, qu'au niveau des outils de travails, visualStudio, SVN...).

En tout cas, si vous avez des conseils pour un débutant...

Dracul86 :

Alors me voilà parti pour un petit message fleuve, je médite ces questions depuis bien longtemps maintenant, et ayant parcouru votre forum dans tous les sens, il arrive un moment où il faut se lancer.

Bienvenue !
Personnellement je me suis lancé dans Irrlicht il y a moins d'un an, et je ne le regrette pas, bien que j'ai des lacunes en C++

Dracul86 :

1. (Question déjà vu 100 fois je suppose) le jeu que je souhaiterais développer serait un jeu de course 3D futuriste (ne riez pas) très rapide. Pour celà, il me faudrait la possibilité d'afficher des (très) grands circuits, quelques vaisseaux et quelques effets à un framerate suffisant(>60 fps), avec si possible une qualité sympas (disons niveau Quake 3 si possible). Irrlicht de base sera-t'il suffisant pour celà ? Si oui, sera-t'il possible au terme du développement de toucher directement au code du moteur pour tenter de l'accélerer encore plus (par exemple en limitant l'affichage à OpenGL) ?

Irrlicht est a mon avis suffisant pour faire un affichage de niveau Quake 3 avec quelques petits effets en plus (a 60 fps),
Au niveau des grands circuits, je pense que oui, mais Irrlicht a quelques faiblesses pour tres grand terrains (vraiment grands), mais je ne détaillerai pas plus, parce que je n'en sais pas beaucoup plus a ce sujet

Toucher au moteurs ? ben pas mal de gens le font avec succes, donc je pense qu'on peut dire que oui ^^

Dracul86 :

2. Je me doute que la réponse à la question 1 sera du type "ça dépend de ce que tu veux afficher", d'où ma seconde question. Selon vous, un mesh agréable à l'oeil, c'est combien de polygones ? ça se compte en centaines ? milliers ?

euh .. ca dépends (pour faire une voiture ou un marteau, pas besoin de millions de poly)
pour t'apporter un élément de réponse, je me rappelle avoir fait un petit jeu de fourmis ou chaque fourmis comptait en gros pour une centaine de polygones, et ca rendais tres bien, (ya des images dans la partie screenshots de vos projets)

Dracul86 :

3. Je me perds un peu lorsque l'on s'attaque à la modélisation des vaisseaux. En regardant les logiciels de modélisation, énormément de fonction sont présentes, dont certaines devraient être gérées par Irrlicht à la base. Je me pose donc cette question, jusqu'où faut-il aller au niveau de la modélisation ? Par exemple, je suppose que les shader ne sont pas à définir dans maya directement non ? A priori, je dirais que les modèles 3D devraient contenir les meshs, les textures, et les animations. Quelque chose à rajouter ?

Non c'est exactement ca,
Selon tes besoins, dans certain formats tu peux aussi définir un squelette qui permet d'associer des meshs par ces points

Certains logiciels de modélisations ont des fonctions supplémentaire pour faire du dessin de scenes, voire des mini videos, et du coup on peut mettre des shaders dans la partie modélisation, mais ca ne s'applique pas a irrlicht

Dracul86 :

4. J'ai été assez déçu de ne pas trouver des articles de bases sur la représentation physique des éléments de irrlicht. Un exemple tout bête, j'ai du écrire un code à la main pour me rendre compte que le vector3d de rotation contenait les angles de rotation en degrés (d'ailleurs qui as eu cette idée lumineuse ? ). Auriez-vous un lien ou un livre expliquant les bases soit de Irrlicht, soit des moteurs 3D en général, avec si possible les maths qui vont avec ?

euh, j'ai des tas de bouquins, mais aucun la dessus
sans aller jusqu'au livre, pour faire une rotation de x degré, j'utilise ca (code fourni par exedor qui la lui meme trouvé sur le forum):

void rotate(vector3df rp) //rp is angle to turn, pitch or roll
{
   vector3df r = nodeSydney->getRotation(); //get current rotation (euler)

   matrix4 m;
   matrix4 mp;
   m.setRotationDegrees(r); //set matrix to current rotation
   mp.setRotationDegrees(rp); //set second matrix to rotation to add
   m *= mp; //multipy them

   r = m.getRotationDegrees(); //get rotation vector from matrix (euler)
   nodeSydney->setRotation(r); //rotate node
}

et voila, pas besoin de quoi que ce soit d'autre

Dracul86 :

5. Histoire d'avoir des mouvements fluides et "réalistes", nous avons décidés d'intégrer un moteur physique (ODE dans notre cas). A priori, d'un point de vue physique, notre projet devrait être relativement facile (collision d'une boite englobant le vaisseau avec le niveau, application de forces prédéfinies au niveau des moteurs), voir même que ça simplifierai fondamentalement le code (par exemple, appuyer sur une touche ne revient qu'a allumer les moteurs, et donc à appliquer une force). Mais après avoir parcouru votre forum, notamment le post traitant de la voiture et des joints, je me rends compte que le tableau idyllique que je m'en faisais ne sera peut-être pas si joyeux. Pensez-vous que c'est du suicide à mon niveau de me lancer là dedans ?

Du suicide non, rien n'est dangereux dans Irrlicht ... au pire tu apprendra beaucoup de choses en essayant,
tu n'a rien a perdre essaie et vois si ca te convient
Apres, la physique, je pense que c'est quand meme bien plus qu'une boite en collision avec un circuit, il faut des roues, et une gestion du temps tres complexe, bref, c'est plus complexe qu'une boite et un circuit
C'est Copland qui planche sur la voiture physique, et je vais le laisser exprimer une meilleure opinion que la mienne

un lien passionnant sur la question (merci Copland) :
http://www.nofrag.com/2004/oct/23/14529/

Dracul86 :

En tout cas, si vous avez des conseils pour un débutant...

euh, éclates toi bien ?

Je ne peux pas te répondre car je suis debutant aussi , mais il me semble que pour une mettre un tres grand circuit il suffit de le decouper et d'afficher que les morceaux nécéssaires auquel cas tu peux le faire immense ( comme pour les trains a léviation electomagnetique   )

juste une petit question a JerryKan , elle sert a quoi la fonction rotate ? ( si c'est une simple rotation   pourquoi pas faire node->setRotation( core::vector3df(...)) )

Merci pour ces réponses qui me rassurent bien.

En fait, lorsque je parlais de "boite avec un circuit", je disais surtout ça car c'est une chose que l'on a posé tout de suite. Etant dans un contexte futuriste, nous allons englober chacun de nos vaisseaux dans un champs de force pour simplifier les détections de collision, tout du moins dans un premier temps.

Pour la fonction rotate, une bonne partie des calculs simples peuvent être gérés par des procédures de Irrlicht. Mais dès que l'on touche à quelque chose d'un peu plus compliqué (comme une caméra à la 3ème personne... et oui....), il faut alors savoir exactement qu'est-ce qui correspond à quoi. Si déjà avant de commencer à coder je pars dans l'optique de prendre du boulot de quelqu'un d'autre sans le comprendre, je serais assez mal barré...

Pour Firnafin, la fonction setRotation change le vecteur de rotation sans se soucier de la rotation du départ si je ne m'abuse. La fonction que JerryKan nous a refilé cacule le nouveau vecteur en fonction de l'ancien. Bref c'est une rotation "relative".

Enfin, pour l'idée de découper le circuit en morceaux, je vais regarder de ce côté. Dans ce cas là, il faudrait séparer le circuit en de multiples mesh, les charger tous et en afficher que certains c'est celà ? Quid de la gestion de la collision dans ce cas là ?

c'est bien ce qui me semblé , alors pour a ma part j'utilise pour faire une rotation relative cette simple fonction :

void rotate(core::vector3df v,scene::ISceneNode* node)
{
         node->getRelativeTransformation().rotateVect(v);
         node->setRotation(node->getRotation()+v);

}

qui fait a apparament la meme chose ( j'ai fait 3-4 testes et les deux fonctions donne la meme chose ).Elle est moins gourmante en calcule.
Pour ce qui est des collisions un double teste au moment ou le vaisseau et sur la frontiere entre les differents morceaux permettrai un passage correcte.

Je ne sais pas si tu as vu mais il y a un jeu de course de vaisseau presenté sur le site officiel ( et un lien sur ce forum que j'ai croisé je ne sais ou ) qui pourra peut etre te donner un idée des performances que peut atteindre le moteur.
( pour pas te donner de mal voici le lien  ici )

Oui, je l'avais déjà téléchargé, trop lent à mon gout, mais jolie effectivement. Le soucis de ce jeu, c'est que les niveaux sont assez "simples", un chemin dans un espace vide, je ne sais pas si les performances qu'ils ont eu là dessus seraient représentatifs de ce que je veux faire (courses dans un ravin, ou d'autres environnements naturels). Mais l'idée de séparer le tout en plusieurs "salles" pourrait régler ce soucis je suppose, à voir s'il y a moyen de faire ça dans un mouvement fluide, sans que ça ne perturbe le jeu, quitte à faire ça dans un thread à part sinon.

Dracul86 :

En fait, lorsque je parlais de "boite avec un circuit", je disais surtout ça car c'est une chose que l'on a posé tout de suite. Etant dans un contexte futuriste, nous allons englober chacun de nos vaisseaux dans un champs de force pour simplifier les détections de collision, tout du moins dans un premier temps.

j'ai pas une grosse expérience de la physique, mais dans ce cas, que penses tu de l'idée suivante : tu modélise ton vaisseau par une bille, et tu ne fait coincider les mouvement de ton vaisseau qu'avec la coordonnée position, sans tenir compte des rotations,
parce que j'ai peur que ta boite ai un véritable comportement "de boite"

Dracul86 :

Enfin, pour l'idée de découper le circuit en morceaux, je vais regarder de ce côté. Dans ce cas là, il faudrait séparer le circuit en de multiples mesh, les charger tous et en afficher que certains c'est celà ? Quid de la gestion de la collision dans ce cas là ?

sais pas, pas assez d'expérience pour te répondre correctement

Je crois que tu n'auras pas assez de vitesse, j'ai fait un tout petit map maker et des que j'arrive a 3 modeles de charger ma radeon 9600 pro 256mo me rend que 30fps...
De plus il y a deja un jeux de vaisseau, essaye le et tu veras que les fps ne suivent pas...

J'ai arrete Irrlicht a cause de ca...
J'ai voulu faire Ogre mais j'ai trop la fleme, donc je suis entrain  de coder mon propre moteur 3D. Pour le moment seulement OpenGL mais ca marche tres bien !
On a pas encore demarer le code pour charger les modeles car on fait les bases.

SI quelqu'un est interesser par Ouragan3D --> http://maitrelame2.kilu2.de/
Pour le moment a peine demarer.
Mais en 4 lignes de code n'importe qui peut ouvrir une fenetre gerer / une connexion a un serveur / afficher les FPS / afficher un triangles ou un carre...
Vous pouvez en 16 ligne de code gerer les evenements...

Personnellement je passe qu'irrlicht est tout a fait adapté pour ton projet,il ne pose pas de probleme de performance si tu ne lui demande pas trop en nombre de vertex a afficher.Quelques vaisseaux en low poly (ca depend de leur nombre , si 10-20- ou 30 font la course) et une map bien gérée  passeront facilement car il n'y a ni anime ni grande etendu a afficher pas de Bump ni de parallel ,et puis c'est pas a son rendu graphique qu'un jeu amateur est apprecié : je joue encore a ExtremG et StarWars Racer (Premier du non) qui sera noter a 5/20 point de vu graphisme (style de jeu de course rapide).Irrlicht c'est pas le moteur de Oblivion mais de la dire qu'il n'est pas capable de faire tourner un petit jeu sympathique avec quelques effets/shaders/particules c'est le sous estimer .
Et puis comme ca vas tres vite ,(avec pourquoi pas un glow) tu peux mettre un decore low poly aussi

PS a maitreLame: la vitesse dont parlait le vampire est celle du jeu pas celle du moteur.

firnafin :

PS a maitreLame: la vitesse dont parlait le vampire est celle du jeu pas celle du moteur.

La je t'arrete tout de suite, c'est completement la meme chose, hein
tu peut toujours faire avancer ton vaisseau de 300 mètres entre de frames, si le joueur a pas assez de FPS, il maitrisera pas l'engin, ce sera pas agréable

dans un jeux ou la vitesse de l'engin est élevé, tu a besoin de d'autant plus de FPS pour avoir une bonne jouabilité,

Pour moi, jouer a moins de 80/100 fps dans un jeux de type course ou first person shooter est totalement impossible, tu sens immediatement les saccades des que tu te mets a jouer (meme si un observateur exterieur ne va pas les sentir, le joueur recent beaucoup mieux la fluidité, parce qu'il est en prise directe avec le jeux)


La vrai qestion c'est est ce que irrlicht peut faire du 80 fps sur jeux de course, a mon avis, oui, tant qu'on est pas trop gourmant sur les effets de fou (style alpha, reflexion, shaders couteux, particules etc ..)

J'avoue qu'entre temps, je suis tombé sur XNA, sur les quelques vidéos qui circulent, sur les démos téléchargeables et sur quelques codes sources. J'ai testé le tout premier tutorial, ça m'a beaucoup plûs, plus dur à gérer que Irrlicht, mais autrement plus ouvert niveau de la représentation. J'y perds en portabilité et en simplicité apparente ce que je gagnes en vitesse, qualité graphique et en connaissances. Je m'explique, sous XNA (et sous DirectX en général), plus question d'avancer sans trop savoir ce que l'on fait. Libre à nous d'accélérer ou non notre primitive d'affichage, selon des règles qui sont propres à chaque jeux. C'est beaucoup plus ouvert car une bonne partie des fonctions de bases de DirectX sont à refaire. Un livre m'a été nécessaire, mais j'ai l'impression d'avancer beaucoup plus vite que sous Irrlicht, et surtout je comprends mieux ce que je fais (je suis obligé celà dit...). Il lui manque juste un peu matûrité (pas de livres sur le sujet précis, pas encore de moyen de charger de bsp d'écris...) et XNA sera parfait pour ce que je souhaites en faire.

Effectivement, comme Jerry Kan l'a dit, je ne conçois pas trop mon jeu en dessous de 60 images par secondes. J'ai eu peur de me retrouver bloqué plus tard par des performances moyennes du moteur, je suis donc passé sur un moteur (en est-ce vraiment un ?) un poil plus porté sur l'avenir.

Dracul86 :

C'est beaucoup plus ouvert car une bonne partie des fonctions de bases de DirectX sont à refaire.

Qu'en j'entends Microsoft et ouvert, j'ai du mal a comprendre de quoi tu parle, ..
sans troller, on peut dire que a chaque fois que Microsoft crée une techno, ils s'arrangent pour se réserver un controle clef a un endroit ou un autre (et c'est normal, c'est leur approche du buiseness informatique). Donc les specs sont ouvertes, ok, mais fait attention, ca n'a rien "d'ouvert"

Dracul86 :

J'ai eu peur de me retrouver bloqué plus tard par des performances moyennes du moteur, je suis donc passé sur un moteur (en est-ce vraiment un ?) un poil plus porté sur l'avenir.

a ce niveau, tu a pas trop de souci a te faire, il te suffit de réduire ta gourmandise, enlever quelques effets, et ca repart,
sinon Irrlicht évolue aussi, dans l'avenir c'est un moteur qui va connaitre de gros boosts de performances


maintenant si tu te plait sur XNA, libre a toi

Dernière modification par Jerry Kan (15-04-2007 15:40:44)

En fait je disais ouvert plutôt dans le sens "tu n'es pas bloqué par des choix faits par les créateurs du moteur". C'est à toi de dire comment chaque objet s'affiche, à toi de faire la projection de ton mesh 3D sur l'écran 2D, à toi de définir ton propre repère, à toi de dire quel effet sera utilisé plus tard. Si tu décides que l'axe Z sera dans un autre sens que prévu, et que tu t'y tiens pendant tout ton programme, l'axe Z sera effectivement dans l'autre sens. XNA est plus abstrait en fait. Un autre exemple vient du fait des terrains. Pour dessiner un mesh de terrain, tu ne pourras pas faire comme dans Irrlicht, taper une ligne de code et pouff avoir un terrain formé via une heightmap, c'est à nous à redéfinir ce que nous souhaitons obtenir. C'est un mal comme un bien, du coup on est obligé de savoir comment tout fonctionne, qui affiche quoi et comment, comment est faite la caméra...

Sinon, XNA n'est pas ouvert comme on l'entends en général, les spécifications ne sont pas ouvertes, pas comme .NET par exemple. Celà ne me dérange pas personnellement car sans vouloir troller non plus, les joueurs jouant sous linux se font rares.

Après ce post risque de dévier, et ce n'est peut-être pas le sujet de ce forum, quoique le débat pourrait être intérressant.

ps : Je ne suis pas venu pour troller ni rien, j'essaye juste de poser les avantages et inconvénients de chaque "formule". Je pense que pour MON jeu, avec MA façon de programmer et de voir les choses, XNA semble à première vue plus adapté

Dracul86 :

Sinon, XNA n'est pas ouvert comme on l'entends en général, les spécifications ne sont pas ouvertes, pas comme .NET par exemple. Celà ne me dérange pas personnellement car sans vouloir troller non plus, les joueurs jouant sous linux se font rares.

ah ? pourtant depuis wine, avec CS et War 3 qui passent sur Linux, j'en voit de plus en plus dans les LAN ^^

Dracul86 :

Après ce post risque de dévier, et ce n'est peut-être pas le sujet de ce forum, quoique le débat pourrait être intérressant.
ps : Je ne suis pas venu pour troller ni rien, j'essaye juste de poser les avantages et inconvénients de chaque "formule".

a mais moi j'aime bien troller

Vous allez pas commencer, Linux c'est de la merde et Windows aussi voilà na lol.
Na sérieusement !! Y'a des joueurs sous linux faut pas croire, j'en fais partie occasionnellement mais je suis pas un grand joueur tout court.
Sinon pour recadrer un peu le sujet, Irrlicht c'est pas de la daube hein ça marche fort si on sait programmer et optimiser et qu'on a envie de passer un peu de temps à remouler le moteur à l'image de son projet.
Le seul hic c'est que dans les dernières versions, il y a pas mal de bugs mais je compte sur l'équipe d'irrlicht pour y remédier et nous pondre un moteur qui déchire du slip ^^.
Bon aller treve de bavardage, tout les moteurs sont bien mais chacun à sa spécialité je dirais.
@++

Un jeu de course futuriste ? Dans la veine du génialissime F-Zero ?

Je n'ai qu'une chose à dire :





http://www.irrgheist.com/games.htm

Donc oui, Irrlicht peut s'en occuper !

Je ne réponds pas forcémment à une question mais plutôt à ce que j'ai pu lire :
Arrêtez de nous dire que votre programme était lent sur votre machine et que c'était la faute d'Irrlicht...
Moi, avec Irrlicht .NET CP 0.8 (Irrlicht 1.3), en DirectX 9 (plus rapide que l'OpenGL sur Windows avec ma carte il semblerait... au moins avec Irrlicht en tout cas), j'ai pu afficher un terrain très vaste (cf je sais plus quelle section où j'avais posté mon truc de terrain), soit 90 000 polygones, avec en plus les bâtiments de la cité impériale d'Oblivion (pour ceux qui ne connaissent pas, cliquez ici), soit 300 000 polygones... Le tout à 45 fps avec Anti-Aliasing et sur une Radeon 9700 Mobility... Et ce sans aucun changement apporté à Irrlicht (le core hein... j'ai rajouté plein de trucs mais en C#) et sans aucune connaissance en DirectX.
Je ne peux pas poster l'exécutable malheureusement (faute d'avoir les 8 GO que prennent Oblivion et les autorisations de le distribuer ) mais j'essayerai de vous faire des screenshots...
[EDIT]Voilà j'ai recodé le programme en vitesse car je l'avais viré, voilà quelques petits screens adresse
C'est moche mais ça montre qu'on peut afficher des trucs complexes en optimisant le polycount et les calculs, et donc à fortiori le framerate.[/EDIT]

Le tout est d'être intelligent, d'essayer de résoudre ses problèmes, ne croyez pas que parce qu'un moteur 3D vous mâche le travail il vous aide hein...

PS : Framerate supérieur à 60 fps c'est pas suffisant, c'est excessif ! Pour l'affichage en soit, 24 suffirait, le seul ennui c'est que ça entraîne des lag au niveau de la logique de jeu si tu gère ça dans la même boucle... Mais si tu gère ça bien, un 30 fps à la Oblivion (quoi ? encore lui ? ) peut être amplement suffisant.

PPS : Désolé pour les articles de base, il y en a quelques uns sur le wiki d'irr.NETCP mais c'est léger léger... Moi ce que je te conseille c'est de lire quelques articles sur les API 3D classiques (DirectX, OpenGL) pour mieux comprendre, puis ensuite tu verras tout Irrlicht paraîtra logique... Il faut savoir que ces moteurs sont faits par des gens qui prennent les habitudes de leurs APIs... Oui ça veut rien dire cette phrase, j'en ai conscience, mais ça fait *space*.

Dernière modification par DeusXL (16-04-2007 13:00:51)

DeusXL :

PS : Framerate supérieur à 60 fps c'est pas suffisant, c'est excessif ! Pour l'affichage en soit, 24 suffirait, le seul ennui c'est que ça entraîne des lag au niveau de la logique de jeu si tu gère ça dans la même boucle... Mais si tu gère ça bien, un 30 fps à la Oblivion (quoi ? encore lui ? ) peut être amplement suffisant.

euh euh, 30 FPS a Counter tu te fait aligner dessuite, j'ai joué a Quake 4 avec l'affichage du FPS, quand le FPS tombe tu sens tres bien les sacades, ya quand meme une impression de fluidité minimale qui est utile sur un jeu d'action

Jerry Kan :

[quote=DeusXL]PS : Framerate supérieur à 60 fps c'est pas suffisant, c'est excessif ! Pour l'affichage en soit, 24 suffirait, le seul ennui c'est que ça entraîne des lag au niveau de la logique de jeu si tu gère ça dans la même boucle... Mais si tu gère ça bien, un 30 fps à la Oblivion (quoi ? encore lui ? ) peut être amplement suffisant.

euh euh, 30 FPS a Counter tu te fait aligner dessuite, j'ai joué a Quake 4 avec l'affichage du FPS, quand le FPS tombe tu sens tres bien les sacades, ya quand meme une impression de fluidité minimale qui est utile sur un jeu d'action[/quote]
C'est pour ça que j'ai précisé "si tu gère bien".
Le problème quand tu joue à Counter c'est que chaque fps tout est recalculé, autrement dit une baisse du fps entraîne une baisse de la fréquence de la logique du jeu... Et du coup ta visée devient moins précise, puisque c'est mal synchronisé avec le temps. Mais visuellement ton oeil ne captera pas plus de 20 images par secondes... Ensuite il y a des techniques pour atténuer le lag, le motion blur par exemple (sais plus trop si c'est ça le nom)... Pour moi un maître dans la matière reste Oblivion (oui je sais, je cite là le plus beau jeu actuellement sorti ) puisqu'il tourne assez lentement sur beaucoup de machines sans que ça se sente réellement.
Mais là on dérive un peu, non ?

c'est assez faux de dire que l'oeil capte 20 images secondes, puisque de toute facon, le cerveau est capable de voir des images subliminales avec du 100 FPS, c'est donc bien que l'oeil peut les voir

Je suis d'accord avec toi sur le motion blur, ca aide beaucoup a la sensation de fluidité, mais je trouve qu'on perd pas mal en précision, et le montion blur est assez couteux en terme de calculs,

pour égayer ce débat un peu stérile, je suis tombé sur cet article, qui dans le fond peut nous mettre assez d'accord
http://www.nofrag.com/2003/nov/24/8629/

Jerry Kan :

c'est assez faux de dire que l'oeil capte 20 images secondes, puisque de toute facon, le cerveau est capable de voir des images subliminales avec du 100 FPS, c'est donc bien que l'oeil peut les voir

Je suis d'accord avec toi sur le motion blur, ca aide beaucoup a la sensation de fluidité, mais je trouve qu'on perd pas mal en précision, et le montion blur est assez couteux en terme de calculs,

pour égayer ce débat un peu stérile, je suis tombé sur cet article, qui dans le fond peut nous mettre assez d'accord
http://www.nofrag.com/2003/nov/24/8629/

Pardon je me suis mal exprimmé en effet, je voulais juste dire que l'impression de mouvement est donnée par 20 images par secondes (d'où le cinéma, impression de mouvement parfaite et 24 fps).
Par contre après lecture de ton article il est très intéressant, surtout pour balayer certaines idées reçues (que j'avais, youpi !) et j'ai l'impression qu'il a des sources solides.
Par contre j'ajouterai que le framerate "idéal" dépend énormément de la quantité d'actions qu'il y a... Je m'explique : comme il le dit, au cinéma, si on met en pause, l'image est floue, mais uniquement si le personnage (ou la caméra) vient d'effectuer un mouvement brusque... Voilà pourquoi dans des jeux comme Counter, où on passe son temps à bouger la caméra à toute vitesse, il faut un FPS assez important... Alors que dans un RPG, où les choses vont plus lentement, le FPS élevé n'est pas si nécessaire... Et je rajoute aussi ma fameuse logique puisque les choses évolues souvent beaucoup plus vite et il y a plus d'intéractions dans un jeu où il y a plus d'action... Le jeu vidéo en 3D temps réel s'est rajouté une complexité très grande.
Enfin tout ça pour revenir à ce que j'avais dit initialement : dépasser 60 fps (dépasser la synchronisation verticale de l'écran) me semble inutile, et on peut même baisser cette limite selon les nécessités pour travailler l'image à la place.

Dernière modification par DeusXL (16-04-2007 17:48:52)

je pense qu'on est d'accord maintenant