Et oui. On y songe.
Même moteur de physique (Newton), mais nouveau moteur graphique (OGRE).
Quelques premiers essais actuellement, histoire aussi de se remettre au C++ (OGRE oblige). Ca fait longtemps que je n’y avais plus touché...
Et pour patienter, une petite vidéo :
A bientôt...
Bravo ! Une belle fluidité (en acquisition video en plus !)
J’ai rêvé ou bien il y a des effets de caméra dans les rotations de jantes : on voit la roue tourner dans le sens inverse de son mouvement. Saisissant dans les décélérations vers 1’02".
C’est tout aussi impressionnant que le passage d’Unreal à Unreal Tournament ;-)
Merci pour le feedback ;-)
La rotation inversée des roues n’est pas un effet de caméra, mais le classique effet stroboscopique qu’on voit dans tout Western avec les roues de diligence. Ca se produit quand la vitesse de rotation de la roue s’approche de la fréquence d’obturateur de la caméra (au nombre de rayons près).
Pour ce qui est de la fluidité, le FPS est locké à 25 par FRAPS lors de l’acquisition (en fait au nombre d’image/seconde que tu veux obtenir pour ton film). Si je libère totalement l’appli (en stoppant l’acquisition et en désactivant également le VSynch), je tourne à 300 FPS environ :-)
Ceci étant, pour améliorer le rendu de la vidéo, j’ai appliqué un motion blur au moment de la compression. Tu es obligé de faire ça quand tu travailles à partir d’animations de synthèse, car sinon, les images étant parfaitement nettes (à l’opposé de vrais images de caméra, dans lesquelles il y aura un flou naturel de bougé), ça donne des résultats visuellement saccadés sur les mouvements rapides.
Voilà. J’ai dévoilé tous mes secrets :-)
La classe !
Je me serais attendu à un accident un peu plus violent en frappant le rocher (mais peut-être n’était-ce pas vraiment un rocher mais plutôt une grosse balle ?), mais j’imagine déjà les empilements de pneus à l’extérieur des virages pour la prochaine course, qui volent au premier raté :-)
Ca doit être pour ça aussi que malgré l’absence de route, les dérapages au milieu des broussailles secouent aussi peu que sur de l’asphalte :-D
Le thème de l’année prochaine : tournoi de foot à la balle en pierre ponce, mode stock-car.
Disons qu’on a passé le terrain vague au bulldozer avant les essais, pour ménager la mécanique. Mais le terrain n’est plus du tout plat. C’est d’ailleurs cela une des grandes nouveautés fonctionnelles : un circuit en 3D, avec montées, descentes, virages relevés ou en dévers, bosses,...) En plus des arbres comme actuellement, on pourra même ajouter divers obstacles plus ou moins inertes (blocs de rocher en granit, bottes de foin, pneus,...)
Du coup, le paramètre d’altitude des waypoints et du véhicule, ainsi que les orientations dans l’espace des vecteurs vitesse et direction prendront toute leur importance. Effectivement, je pense qu’au début on aura pas mal de cartons dans le décor dans les virages en bas des descentes :-)
Pour le coup, je crains que les machines qui ont quelques difficultés avec la V2 actuellement ne soient complètement à la rue s’il faut gérer plusieurs modèles physique de véhicules. Le problème est autrement plus gourmand que de gérer des corps simples, tels que les exemples cités. Quoi qu’il en soit, je ferai l’essai, car ça fait partie de mes centres d’intérêt, à titre de curiosité.
D’autre part, il faut savoir que la gestion des objets additionnels est déjà présente depuis la première version : les arbres, bordures et autres éléments de décor sont actuellement des objets physiques, mais statiques. C’est nécessaire pour avoir une gestion globale des collisions. Les rendre dynamiques se résume à leur attribuer une masse et une matrice d’inertie. Ce n’est pas le plus difficile à faire :-)