J'approuve totalement DeusXL !

C'est une bonne démo qui convaincra les indécis !

Dernière modification par diOxy (08-02-2007 13:44:01)

Je vous remerci pour ses commentaires très positif, ça fait plaisir .
Je pense que les dernières petites saccades que l'on peut voir proviennent de mon cameraToFollow, j'ai un léger petit bug dessus qu'il faudra que je corrige (je sais pas encore comment).

Pour l'instant voici la liste des ordinateurs sur lequel je l'ai testé avec succès:

Core2duo E6600 + 7600 GT
AthlonXP 2600+ + 7600 GS
PIV 3Ghz + 7300 GS
Celeron 2.8Ghz + Chipset Intel
Pentium D531 + Radeon 9600 Pro

Voilou encore merci.

Tu peux rajouter :
Athlon 3700+ x64 + ATi 9700M (portable)

Et aussi :
Intel P4 3Ghz
Nvidia FX 5600

Au passage, sa marche superbement bien. J'ai un peu de mal côté jouabilité (La voiture vire trop rapidement) mais le reste est impeccable.

Dernière modification par diOxy (12-02-2007 14:09:12)

Bon boulot, moi ça tourne très bien sur Dual core 6600 + Radeon 1900 GTX

Personnellement, je vais bientôt attaquer les tests sous ODE.NET et Irrlicht CP .NET alors si tu postes un des 4 les sources, je suis preneur et je posterai en retour la version .NET

Concernant les geom et les bodies, tu les codes en hard dans le programme ou tu les importes du modeleur ? Les geom, je suppose que tu utilises les fonctions d'Irrlicht qui renvoient les boites qui entourent non ? Dans ce cas, tu as dû découper la voiture en carosserie + roues,ce qui donnent 5 geoms et 5 bodies.

Salut,
Pour les Geom et Body, ils sont programmés en Hard dans mon code sur cette démo.
Le top serait d'avoir comme on en avait déjà parlé avec Duke, un format 3D personnalisé pour les meshs contenant les informations des Geoms et Body Ode directement défini dans un modeleur, mais c'est un sacré boulot à mon avis pour développer quelque chose de propre.
Sinon pour la voiture, j'ai tout d'abord essayé d'utiliser les TriMesh pour la carrosserie et les roues, mais sur le circuit qui lui même est un TriMesh, le résultat était catastrophique niveau stabilité (les roues tremblaient, sautillaient et finissaient par s'envoler dans le vide intersidéral).
Donc j'ai utilisé des Geom standard de Ode,4 Cylinder pour les roues et 1 Box pour la carroserie.
Le tout est inclus dans une classe que je me suis programmé "OdeVehicle" qui me permet maintenant de créer une voiture entièrement parramétré sur une 10 aines de ligne de code.
J'ai encore quelques fonctionnalités à y rajouter car elle ne répond pas à 100% de mes besoins.
Dans mon cas, j'ai choisi de détacher le rendu Physique dans un thread, car après plusieurs tests sur diverses machines, cela s'avère plus stable.C'est cependant plus dur à programmer car comme tu à pû le constater dans les posts précédent, j'ai eu pas mal de soucis de saccades en partie dû à ça.(J'ai lu sur le forum d'Irrlicht qu'il n'était pas Thread Safe je n'ai pas bien compris, mes problèmes pourraient-ils être lié à ça....)
Voilà, si tu as d'autres question n'hésite pas .
@+

Oui, ça répond à ma question postée dans l'autre thread.
Je comprends le problème par lequel tu passes : La gestion du temps est un aspect assez complexe. C'est en effet à la charge du programmeur de gérer le "World Stepping" : l'avancée du temps dans le monde. Il faut, à chaque image, expliquer au moteur physique de combien d'unités de temps il doit avancer les objets. Et là, ça se complique... Tu as choisis de passer par un thread, ce qui peut le rendre "moins contrôlable", mais cela simplifie les choses. A savoir maintenant si tu gères en fonction du Framerate avec un timestep fixe ou en passant par le temps système (plus facile pour la synchro réseau)... D'après ce que j'ai lu, c'est le premier choix que tu as fait - l'autre n'est peut-être pas possible d'ailleurs.
Ce que je ne pige pas trop c'est qu'on dirait que tu as synchronisé l'aspect affichage et calculs physiques ? A ma connaissance, si on veut éviter les saccades, il suffit d'appeler moins souvent le moteur physique et plus souvent l'affichage, quitte à rencontrer de légères incohérences dans les collisions. Tu es certain qu'il y a un problème avec ton thread ? C'est un problème de vitesse différente de calcul du moteur physique ?

Dernière modification par benicourt (13-02-2007 12:47:56)

A savoir, pour le World Stepping Il est absolument indispensable qu'il soit fixe car si tu utilises une variable qui change selon le temps de boucle "TimeElapsed" ode ne sais plus comment calculer sa physique, ça parrait d'ailleurs logique.
Pour le Thread, je n'ai pas choisi de syncrhoniser les deux, ça aurrait été la pire des choses à faire, pour ce qui concerne le nombre des appels du rendu physique et du rendu graphique, il faut bien différencier les deux.En règle générale, un ordinateur sera plus rapide à calculer la physique que le rendu graphique.A moins d'avoir un P75 avec une GEForce 8800 GTX, mais ça parrait surréaliste comme config.
En programmation 3D,j'estime qu'un jeux commence à parraitre moins fluide en dessous de 60 Fps (c'est une base perso) pour d'autre ça sera 30 Fps, ou encore 100 Fps.
Tout dépend le programmeur et le type de jeux.
Donc à partir de là, j'ai utilisé une syncro de 65 Fps pour la physique et limité la boucle graphique en VSync.
Je n'ai pas encore réussi à trouver exactement d'ou provenait les saccades, mais il semblerai qu'en rendu OpenGL ça le fasse beaucoup moins voir plus du tout, donc je mettrai plus en cause une optimisation d'irrlicht au niveau du rendu sous DirectX ou bien quelque chose m'échappe.

As-tu utiliser un mutex pour éviter d'interrompre la partie affichage ? Peut-être que tout cela vient de là : tu applles peut-être les calculs physiques en plein milieu d'un traitement d'affichage et ça plait pas trop à DirectX ?
Remarques tu une différence sur les core 2 duo ?
Au fait, le calcul physique peut prendre beaucoup plus de temps que l'affichage, ça dépend de ce qui est fait derrière, mais je crois que c'est plus souvent le cas dans les jeux vidéos où l'on fait beaucoup appel à cela.

Dernière modification par benicourt (13-02-2007 13:31:03)

Oui j'utilise le mutex.j'ai utilisé dans mon cas les Thread Posix mais d'abord essayé avec les thread normaux.
Sur les core 2 duo c'est très Fluide, ainsi que sur les Pentium Celeron 64 et les PIV HT.
Probablement grace à l'hyper threading.
Sinon je ne vois pas pourquoi le rendu physique prendrai plus de temps que le rendu graphique étant donné que le graphique lui est envoyé au GPU et la physique elle au CPU sauf cas exceptionnel PhysX d'aegia.
As-tu une explication, ça pourrait être interressant ?
Si je limite le rendu physique plus bas genre 40 Fps c'est trop limite et les mouvements d'objets ne parraissent pas assez fluide donc 65 Fps me parrait une limite tout à fait raisonnable.Tu en pense quoi ?

Une explication pourquoi le rendu physique peut-être plus important ? Hé bien cela arrive si les données à afficher sont peu nombreuses et si par contre il y a beaucoup de calculs à effectuer. Comme tu le sais, beaucoup d'opérations sont effectuées par le CPU, même encore aujourd'hui - Si tu dois déformer par exemple un objet no-rigide, la plus grosse partie des calculs sont laissés au moteur de rendu, mais via le CPU. De plus en plus, on permet de charger les GPU avec des programmes mais ça reste encore assez rare (principe des shaders). La gestion de la physique, c'est plus que la simple gravité et la gestion des collisions. Mais même dans le cas des collisions, ça peut prendre du temps, tu t'n es rendu compte déjà quand on calcul la collision de deux formes complexes plutôt que d'utiliser les formes de base (cubes, spheres, etc.)
Maintenant, si ta mutex est au point, je vois pas trop ce  qui se passe et n'ayant pas le problème chez moi, j'ai du mal à imaginer...
Il faudrait que tu logges les différents appels et les chronométrer pour comprendre ce qui se passe et être aussi certain que le traitement n'est pas interrompu.  Dans ton cas, le système physique doit vraiment pas beaucoup pomper. Normalement tu devrais pouvoir l'appeler plusieurs fois entre chaque affichage...

Si je limite le rendu physique plus bas genre 40 Fps c'est trop limite et les mouvements d'objets ne parraissent pas assez fluide donc 65 Fps me parrait une limite tout à fait raisonnable.Tu en pense quoi ?

A la rigueur, il est possible d'appeler 2 fois le système physique (d'affilée, mais en modifiant le timestep) pour 4 trames d'affichage et de calculer le mouvement intermédiaire par interpolation.

Je vois pas trop l'intérêt d'appeler le moteur d'affichage plus souvent que le moteur physique si tu n'utilises pas de système d'interpolation de mouvement... Tu n'as pas d'animation non plus qui demanderaient "à tourner"... tout dans ton système est géré oar la physique (à part les roues qui tournent sur elle même, mais là, c'est pas ça qui gêne).

A mon avis, l'effet de sacade doit être dû au fait que le timeStep est avancé de façon irrégulière. Si le jeu tourne à 100 FPS, il affiche une image toutes les 0,01s donc entre chaque image il suffit de faire avancer le temps d'une unité (un step). Si le jeu ralenti à 10 FPS et qu'il ne calcule plus qu'une image toutes les 0.1s, il faudra par contre faire avancer le temps de 10 steps entre deux images. Est-ce bien ainsi que tu gères l'avancée du temps ? D'après ton premier message, il est fixe, mais c'est pas possible car il faudrait alors avoir un nombre de FPS fixe aussi ! Je crois que leproblème vient de là et pas d'un problème lié au thread.

Quand je parle de synchroniser physique et affichage, je ne veux pas dire les appeler en même temps ou le même nombre de fois, je veux dire : gérer le timestep du monde physique de façon dynamique en fonction du nombre de FPS.

Dernière modification par benicourt (13-02-2007 14:17:48)

Non, un rendu physique sous Ode ou Newton doit utiliser un Step identique à toute les boucles sous peine de grand délire par le moteur physique et là dessus je suis sûr de moi.
Pour te donner une idée, j'ai utilisé exactement la même méthode que l'on a employé en .Net avec Duke sur le post :
Index » Tutoriaux » Tutoriaux .NET / .NET CP » [C# - Irrlicht.net - ODE.net] Intégrer de la physique dans Irrlicht !
Si tu y vois une erreur, je t'invite à y poster une correction afin que d'autre ne refasse pas les même bétises et t'en remerci par avance .

On s'est mal compris, j'utilise le même mot "World Stepping" pour deux utilisations différentes.
Oui ODE doit avoir le même stepping, mais ça n'empêche rien !
L'important est de synchroniser correctement l'appel du moteur physique et celui du rendu

Prenons un World stepping de ODE constant 0,0025 - on doit appeler 400 fois par seconde le moteur physique.
Si on a un FPS de 100, alors on affiche 1 image et on appelle le moteur physique 4 fois - Evidemment, on doit pas changer le world stepping à 0,01 pour l'occasion et n'appeler qu'une seule fois le moteur physique. Si tu passes à 70 FPS alors tu appelles 5 à 6 fois le moteur de rendu entre chaque image théoriquement. 

Dans ton cas, tu appelles 65 fois par seconde le moteur physique. C'est pas assez - passes à 400 par exemple, l'erreur sera beaucoup moins forte. Mais ton problème de saccade ne doit pas venir de là. Je serai curieux de voir comment tu as implémenté l'appel du thread et la mutex.

Moi, personnellement, je n'utiliserai pas un thread pour cela. C'est bien plus facile en fonction du nombre de FPS d'appeler x fois d'affilée le moteur physique et ça évite ce genre de choses, non ? Ca doit pas être difficile à modifier cela ? Pourquoi vouloir passer par un thread ?

Dernière modification par benicourt (13-02-2007 15:46:14)

Je suis entièrement d'accord avec toi qu'il est nettement plus simle de ne pas utiliser de Thread.
Si avec Duke on a utilisé cette technique, c'est parcequ'on c'est apperçu que rendre la physique dans la boucle principale était très lent voir instable sur des machines ayant un petit chipset graphique, et il semblerai que de cette méthode résoud les choses.
Sinon pour les mutex, voici en gros ma boucle de rendu, j'ai peut-être comis une/des erreurs, je suis novice dans le monde du C++.

alors ici :
oMut = PTHREAD_MUTEX_INITIALIZER;

et ensuite ma boucle trhead :

//Boucle du Thread
while(oStopThread==1)
{
    pthread_mutex_lock(&oMut);

    //Ici tu retrouves le même code qu'en C# sur le post de tout à l'heure

    pthread_mutex_unlock(&oMut);
}

Je pense que si il y a erreur dans mon code, il se situ plus au niveau position des mutex qu'au niveau code lui même, mais je ne vois à se moment pas ou les mettre.

Voici mes remarques :

1) Je suppose que tu utilises ici le mutex pour éviter de rentrer en conflit avec le rendu. Donc tu as utilisé le même mutex dans ton rendu, c'est ok ça ?

2) Où est ton code sleep pour faire dormir la tâche au delà de X cycles par secondes ? Car si pas présent et mutex bien placé à l'affichage, le PC va avoir du mal à faire du rendu vu que la physique est beaucoup plus courte.... 

3) Je ne comprend pas l'argument pour utiliser le thread. Si le chipset graphique est lent alors, le nombre de FPS chute, il suffit ensuite de réiterer autant de fois que nécessaire le calcul physique ? Exemple: on tombe à 0.5 FPS et on a un timestep  de 0.0025 alors on exécute 800 fois le calcul physique avant la prochaine opération d'affichage. Ca fonctionne pas ça ???

Dernière modification par benicourt (13-02-2007 16:29:00)

1) Je suppose que tu utilises ici le mutex pour éviter de rentrer en conflit avec le rendu. Donc tu as utilisé le même mutex dans ton rendu, c'est ok ça ?

Là tu m'interresses!!Je n'ai pas utilisé un thread pour le rendu graphique, j'ai utilisé la même méthode que les exemples fourni avec Irrlicht... donc le thread graphique si on peut l'appeler comme ça, c'est l'application qui le gère pas moi.
Le même mutex devrait être utilisé d'après ce que tu dis, ou ça? comment? par qui? fin bref détaille, parceque si ça se trouve le problème vient de là !!

Comme précisé, le code entre les mutex est le même que celui en C# dans le while. j'ai bien un sleep et une fonction de calcul du temps écoulé pour la physique et tout le toutim, tout ça encadré par le mutex à l'intérieur de la boucle du thread physique.

Sinon à parament la méthode de rendu que tu préconises ne fonctionne pas du moins sur le portable à Duke, car ma machine étant suffisament puissante, je n'ai malheureusement pas pû le tester moi même.

1) Ben disons que si tu veux utiliser le mutex pour empêcher que le calcul physique ne se fasse pendant autre chose, oui il faut l'utiliser là bas aussi. Sinon, il ne fait que protéger ton code ici entre lock et unlock contre une autre tâche ayant le même code. Ca pourrait être une autre tâche physique lancée en // mais c'est pas ton truc ici.
Je crois que dans le projet en .NET, y-a pas eu du tout de protection mutex d'après ce que j'ai lu. Il me semble pourtant que pour éviter tout parasitage entre les animations, les déplacements et les calculs physiques, il faut s'arranger pour qu'ils ne puissent pas bosser au même moment.

2) Ton attente SLEEP doit être en dehors de l'encadrement par le lock et unlock (après le unlock donc). Sinon, il bloque pour rien ! Mais le problème ne doit pas venir de là, car ton lock et unlock ne servent à rien utilisés ainsi.

3) je reste perplexe sur le fait d'utiliser un thread. Je me demande vraiment s'il n'y avait pas un problème dans le code même...

Dernière modification par benicourt (13-02-2007 16:58:02)

Ok, mais comment expliquerais-tu que cela ne saccade plus en OpenGl par rapport à directX ? Il doit forcément y avoir une explication rationnelle mais je vois pas ou.
Si tu veux la boucle complète là voilà, mais je doute qu'elle t'apporte un grand regard sur le pourquoi des saccades, elle ne contient que 3 fois rien :

//Render The Physic
void *OdePhysic::RenderPhysic(void* ptr)
{
    OdePhysic* Physic = (OdePhysic*) ptr;
    
    static u32 oActualTime=Physic->oDevice->getTimer()->getRealTime();
    static u32 oLastTime=Physic->oDevice->getTimer()->getRealTime();

    while(Physic->oStopThread==1)
    {
        pthread_mutex_lock(&Physic->oMut);

            oActualTime = Physic->oDevice->getTimer()->getRealTime();

            for (s32 i=0;i <= Physic->oNumIterations;++i)
            {
                dSpaceCollide (Physic->oSpace,(void*)Physic,&nearCallback);
                dWorldQuickStep (Physic->oWorld,Physic->oTime);
                dJointGroupEmpty (Physic->oContactGroup);
            }
            
            oLastTime = Physic->oDevice->getTimer()->getRealTime();
            f32 oElapsed = ((f32)oLastTime-(f32)oActualTime);
            if(16.66f - oElapsed > 0)
            {
                Sleep((DWORD)(16.66f - oElapsed));
            }
        pthread_mutex_unlock(&Physic->oMut);
    }
    return 0;
}

Syncro à ~60 FPS ici mais ça change pas grand chose.
Physic->oNumIterations = 1

1) Il faut placer le pthread_mutex_unlock(&Physic->oMut) avant le sleep, mais ça changera pas le problème de saccade.
2) Tu as pensé à les virer (les lock et unlock) pour voir s'il y a un changement ? (vu qu'ils ne sont pas utiles ici)
3) Teste aussi en mettant à 400Hz le moteur physique (60 me parait trop juste avec ODE - c'est pas le le moteur UNREAL non plus ;o)

La différence OpenGL/DirectX viendrait du fait que l'un consomme peut-être plus de temps que l'autre... Je me demande si une sémaphore sur toute la partie "coordonnées/rotation" des vertex n'est pas nécessaire - c'est là qu'il  faut  le mutex je pense.

suis d'accord avec benicourt, le sleep dans le lock/unlock est a proscrire (tu impeche les autres de faire, mais tu fait rien)

pour openGL directX, peut etre que directX est pris en compte différemment au niveau noyau, et (peut etre, pas spécialiste du noyau windows, d'ailleur qui le pourrai ..) que directx peut par exemple quand meme faire des opérations selon son implantation (un chargement différé, un truc de sous processus interprété différemment par le noyau .., la encore qui peut dire comment c'est fait)


Bon je prendrai pas ca comme une explication exacte, mais si le fait de sortir le sleep regle le probleme, alors c'est de ce coté que ce trouve l'explication

Ok, pour la syncro à 400 c'est testé déjà et ça fait pareil donc ça c'est exclus.
Virer les Lock et Unlock j'ai déjà essayé et j'ai droit à un jolie crash au moment des mise à jour position/rotation si je me souviens bien.
Peut être le mutex ailleurs je test dès se soir, ça pourrait être la solution.
Merci !

[EDIT] ok je sors le Sleep aussi, je pensais qu'il était necaissaire au temps pour le unlock justement, je n'avais pas compris son fonctionnement.Encore merci !

Vous pourrez retélécharger l'archive et me dire si éventuellement ça va mieux, que se soit sur mon athlon, mon PIV ou mon core2duo je ne vois plus aucune saccade hormis celle provoqué par mon camerafollow mais uniquement quand on se trouve pret du véhicule donc on arrive à les identifier facilement.merci

crash au moment des mise à jour position/rotation --> là, je comprends pas, si tu ne le fais pas ailleurs, y-a pas de raison que cela change quoi ce soit  ! Tu n'as bien qu'un seul thread pour la gestion de  la physique ?
Sinon, oui, c'est bien ce que j'imaginais comme comportement, mais uniquement si tu fais un lock avant de faire tes rotations et autres mises à jour, puis un unlock après...

Alors, finalement, tu as changé quoi pour que cela fonctionne ?

benicourt :

Je crois que dans le projet en .NET, y-a pas eu du tout de protection mutex d'après ce que j'ai lu. Il me semble pourtant que pour éviter tout parasitage entre les animations, les déplacements et les calculs physiques, il faut s'arranger pour qu'ils ne puissent pas bosser au même moment.

Je pense que c'est un faux problème ; seuls les accès concurrents en écriture sont problématiques. (pour .net en tout cas, je ne maitrise pas c++)

C'est très intéressant de vous lire, continuez !! (Copland je n'ai pas ma daube de portable ce soir mais dès que je l'ai je teste ton exécutable)

J'ai déplacé les mutex et le sleep comme convenu. Je sais pas ce que ça peut donner chez vous ?
J'ai remarqué que sans VSync le problème revenait sous Directx, donc il ne semble pas résolu à 100%.
Duke, si mes souvenirs sont bon en C# tu n'avais pas pû tester sous DirectX ?

Pour le crash, j'ai oublié de préciser, c'est dû à une modification de Body, donc oui je modifais à se moment là les positions/rotations, mais depuis mon code à changer, il semblerai que sans mutex cela ne pose plus de problèmes particuliers, donc je me pose la question de savoir si ils sont absolument indispensable ?