Bonjour.

Je suis en train de créer un simulateur de vol pour un drone.
Pour rendre le vol réel, je souhaite savoir comment faire pour établir une échelle au niveau des distances, du temps et de la vitesse, de telle sorte que lors du vol le drone parcours la bonne distance pour un temps donné et une vitesse donnée, ou qu'il se déplace à la bonne vitesse pour une distance donnée et un temps donné, etc........ En fait je veux que ce soit le plus réaliste possible.

Merci pour vos lumières.

Il te faut modéliser sur une échelle de base, une unité de ton modeleur = 1 mètre sous irrlicht par exemple.
Ensuite il te faut effectuer un calcul du temp écoulé entre chaque boucle (TimeElapsed), et t'en servir de coef de déplacement pour tes objets mobile.

Est-ce que vous ne connaitriez pas des exemples tout faits par hasard ? Pourriez vous également m'indiquer des sites de référence et de qualité traitant du sujet ? Merci.

Attention, cette méthode comportant des variables statique, il ne faut l'appeler qu'une seule fois !

f32 IrrTimeElapsed(IrrlichtDevice* device)
{
    static u32 LastCycle,LoopTime;
    f32 Result=0.0f;
    LastCycle = device->getTimer()->getRealTime() - LoopTime;
    LoopTime = device->getTimer()->getRealTime();
    Result = (LastCycle/1000.0f);
    if (Result > 1.0f){Result=1.0f;}
    if (Result < 0.0f){Result = 0.0f;}
    return Result;
}

dans ta boucle principale tu as un truc du genre :

while(Exit==false)
{
f32 TimeElapsed = IrrTimeElapsed(Mondevice);
//Déplacement de ton objet = MaVitesse * TimeElapsed
}

Sinon, plus facile : le FPS c'est le ratio x images/ 1 seconde.

Nous on veut savoir le temps utilisé pour afficher une image.... x secondes / 1 image

Allez, petite règle de trois...... 1 / FPS !

Une des règles d'or, c'est de ne jamais se baser sur le FPS pour des calculs de mouvement...

Au nom de quoi ?

Je ne vois pas de raison pratique de ne pas utiliser cette méthode...
Ce que tu fais dans ton code c'est juste recalculer l'inverse du FPS... tu refais un calcul qui a déjà été fait

Tout simplement parceque comme sur la pluspart des moteurs 3D irrlicht affiche de l'entier et en convertissant comme tu le préconises, tu perds en précision...Après tu fais comme tu veux, à bon entendeur .

La perte de précision ne pose aucun problème pour 99% des cas.
De plus bon nombre de moteurs calculent le FPS en tant qu'entier, dans ce cas elle est carrément nulle.

Je ne sais pas comment procède Irrlicht cependant, et le problème ne se pose même pas pour moi puisque je fais l'inverse ( FPS = 1 / EllapsedTime )