[résolu] Problème pendule

Bonjour,

je bosse sur un système de corde ninja et je galère a faire un effet de 'pendule' réaliste.

Actuellement j'utilise un truc tout bête:
v = - lengthdir_x(1, angle)
vitAngulaire += v / 10
rotate(vitAngulaire)

Mais le soucis, c'est quand je change de 'repère', bah la corde passe du très rapide (corde longue) au très lent (courte), et vice versa.

Le pendule est très rapide:


Mais après raccourcissement de la corde, sa vitesse se réduit (vu que la vitesse angulaire ne change pas) au lieu de s’accélérer:


J'ai tenté un truc du genre v = - lengthdir_x(1, angle) * r/10 mais ça ne change pas grand chose (toujours aussi bof comme rendu).

Si quelqu'un vois comment faire
Merci d'avance.

Yho,

Il y avais ce sujet qui parlais un peut de la chose : https://cbna.forumactif.com/t11554-object-balancier, mais sinon je peut pas t'aider plus sorry.

Pwet,
vais tenter avec ça peut être qu'avec quelques ajouts j'arriverais a prendre en compte la taille de la corde

Par contre, faut que tu m'expliques un truc, le sin pour x et le cos pour y, c'est fait exprès oO?
x = base_x+(rope*sin(angle/57.3));
y = base_y+(rope*cos(angle/57.3));

Alors ça remonte un peut tout ça j'avais réussi à sortir un truc potable en tâtonnant avec les infos de calcule chopés sur Wikipedia (je n'ai pas du tout eu de cursus scientifique) du coup je me rappel plus trop comment ça marche mais en tout cas ça marche bien.

D’après mes souvenirs il faut effectivement un SIN et un COS pour ajouter un effet de vitesse de balancier, par-contre le mouvement sur ce script reste constant, va falloir que tu décrément les valeurs pour réduire la vitesse.

Je pense que Dz est le plus calé sur ce forum sur ces calcules-ci, faudrait voir avec lui à mon avis.

Après raccourcissement de la corde, ta vitesse angulaire devient fausse car la longueur du fil a changé. Il suffit donc de la recalculer à ce moment-là :
vitAngulaire *= longueurDeLaCordeAvant/longueurDeLaCordeApres;

Ouai mais ça reste bizarre niveau calcul, en principe définir le mouvement d'un pendule c'est juste définir les variations de son angle en fonction de la taille de la corde. Du coup on est en coordonnées polaires et pour l'affichage on passe juste en coordonnées carthésiennes:
x = centre_x + cos(angle en radiants)
y = centre_y + sin(angle en radiants)

D’ou mon étonnement du sin pour les abscisses
Sinon j'ai testé, je me retrouve avec le même problème.
Jvais aller relire mes cours de physique du lycée ><


GrandeLangue>
Vais tester ça, merci :p

Ça marche nickel, merci beaucoup!

Content d'avoir pus aider le Grand Oni  

De rien, je dirais la même chose que Caly, vu le nombre de choses que j'ai apprises avec tes tutos et tes exemples, c'est toi que je devrais remercier

Des vitesses angulaires, mais comment un fan d'optimisation tel qu'onilink_ peut-il utiliser des vitesses angulaires...

L'astuce que j'utilise pour les pendules est d'appliquer la gravitation au perso, puis de rectifier la distance entre lui et le point d'accroche, avec un bête calcul vectoriel. Et ça marche bien tout simplement parce que c'est ce qu'il se produit réellement, moyennant une intégration d'Euler ;)

A vrai dire ça fait un bail que j'ai pas trop appliqué ce genre de trucs du coup jsuis parti sur du simple.
Cette année en maths on a fait que des stats, imaginez un peu le coup que je me suis pris, je sais plus rien faire x)
Puis bon en C++ je pourrais avoir 50000 pendules qui utilisent des coordonnées polaires, ça ramerais pas

En tout cas ton truc m’intéresse, ça peut toujours être utile. Quand on rectifie la distance, tu gères ça comment pour la vélocité horizontale?
Tu ajoutes l'écart supprimé entre le point d'accroche et l'objet?
Car j'avais fait quelques tests a coup de calcul vectoriel, ça me donnais plus des élastiques que des pendules x)

En gros tu effectues tes déplacements comme si le pendule était absent, en particulier la gravité.
Puis tu calcules le ratio C = longueurMax / longueurEtirée.
Si C < 1 (la corde dépasse sa longueur max), petite homothétie centrée sur le point d'accroche A et de ratio C, et ta corde retrouve sa longueur.
Pour rappel l'homothétie consiste à prendre la position de ton personnage dans le repère du point d'accroche (P' = P - A), à multiplier ses composantes par C et à repasser dans le repère original.

Je suppose ici que tu as une classe vec2 (ou vec3) qui stocke un vecteur et peut être additionnée, soustraite, être multipliée par un scalaire et donner sa norme, avec les surcharges d'opérateurs qui vont bien.

Code:

// ...modification de la vitesse par la gravité, les entrées clavier...

_pos += _spd * dTime(); // Intégration d'Euler

if(_hooked) {
    _pos -= _hookPoint; // Changement de repère, _hookPoint est dès maintenant l'origine (ça simplifie le calcul de distance juste en-dessous)

    float etirement = _maxHookLength / _pos.norme();

    if(etirement < 1.0f) // Tu peux virer ce test pour obtenir une tige incompressible plutôt qu'une corde. Du coup pas besoin de stocker etirement.
        _pos *= etirement;

    _pos += _hookPoint; // Changement de repère inverse
}

Ah ouai ok, c'est tout bête en plus, merci :b

Vais tester ça sur mon ptit moteur de corde ninja voir si c'est moins ****** a utiliser x)

C'est bien sûr pas testé, mais normalement c'est correct :p

Yep j'ai testé ça fonctionne, par contre faut penser a récupérer les coordonnées avant l'homothétie afin de calculer l’accélération de l'objet après avoir appliqué la contrainte de la corde. Sinon l'objet tombe direct et s'arrête x)


Vu que t'es dans le coin, je me permet de demander 2 ou 3 trucs :b

Quand je fonctionnait en vitesse angulaire, je faisait comme ça:

Ma corde, et les obstacles:


Je récupère l'angle minimum:


Je change les coordonnées du hook si mon angle + vitesseAngulaire > angleMinimum



Avec la méthode du produit vectoriel, ça m'obligerais a passer mes coordonnées en coordonnées polaires pour récup l'angle a l'instant t, l'angle a l'instant t+1, et vérifier s'il y a collision.
Plutôt moche comme ça ...
Tu verrais pas une meilleur solution?

La solution serait justement le produit vectoriel, noté ^. Il s'agit d'un moyen de mesurer l'angle relatif entre deux vecteurs : nul si les deux sont colinéaires, positif si ils sont en sens direct, négatif en sens indirect.

Code:

inline float operator^(vec2 const& other) const {
    return x * other.y - y * other.x;
}

Soit A l'accroche, P et P' ton perso aux temps t et t+1, O ton obstacle. Donc :
- Tu calcules et tu stockes p1 = AP^AO
- Tu mets à jour le perso
- Tu calcules p2 = AP'^AO.
- Si p2 * p1 <= 0, le produit a changé de signe lors du déplacement, donc ta corde et ton obstacle se sont croisés :
    - Ton point d'accroche est déplacé en O
    - Tu soustrais ||AO|| à ta longuer max.

Mais là du coup la corde "colle" au obstacles. Il te faut donc tenir une pile des points d'accroche successifs, pour pouvoir les décrocher et récupérer le précédent.

Ah ok nickel, c'est bien plus simple du coup. Merci.
Pour la liste de point oui ça fonctionne comme pour les angles, normal :b

Sinon, vu qu'il y a plusieurs obstacles, pour détecter le premier qui entre en collision avec ma corde, je pensais a cela:
Pour chaque point:
-je regarde s'il est bien du bon coté de la corde
-je calcule la distance droite/point et je garde la minimale (et l'instance liée)

Ensuite j'utilise le produit vectoriel pour avoir le point d'accroche, et je réitère tant qu'il le faut.
Ça parait good comme ça?

Je pense qu'un calcul de distance ne suffira pas dans certains cas, par contre tu peux trier par valeur absolue du produit vectoriel : plus elle est élevée, plus les vecteurs divergent (donc plus l'obstacle est éloigné de la corde). Et il faut effectivement traiter les plus proches en premier.

J'étais sur les graphismes du jeu pendant un moment donc j'avais mis ma corde de coté.
J'ai fait les points d'accroches la, avec le tris par valeur absolu du produit vectoriel et ça marche nickel.
Donc encore merci Deezee

Par contre pour que les points se décrochent, je bloque un peu car y a deux cas, mais j'arrive pas trop a saisir comment savoir si l'on est dans l'un ou l'autre.

Code:

if(hooks.size() > 1)
{
    uint n = hooks.size()-1;
    double p = crossProduct(hooks[n].x-x, hooks[n].y-y, hooks[n-1].x-x, hooks[n-1].y-y);
    
    if(p < 0) // cas 1
    // if(p > 0) // cas 2
    {
        len = hooks[n].len;
        hooks.pop_back();
    }
}

Ce que donne le cas 1:

Pour la première image (sens anti horaire) pas de soucis, ça s'accroche et ça se décroche très bien.
Pour la deuxième image (sens horaire) bah la corde traverse (logique, elle est dans le cas ou p>0)

Pour le cas 2 c'est l'inverse.

J'ai fait quelques essais mais y a toujours des bugs :s
Je sait qu'il faut trouver un moyen pour savoir dans quel sens l'accroche se fait (genre horaire ou anti horaire) afin de faire ensuite une bête comparaison de signe... Mais je vois trop comment calculer ça.
Si quelqu'un vois comment faire, merci a lui

Je suis une daube en maths ( Je suis en 4° faut comprendre ) mais je vais essayer de comprendre et de répondre à ta question.
Est-ce que tu connais quel est l'angle de la corde? Si oui, ça serait plutôt simple, non?

Code:

if angleprecedent > angleactuel { direction = 0; /* Sens contre-horaire */ }

Et quand il tape contre l'obstacle, il te suffirait de stocker la direction?

Edit : Pourquoi tu laisse le sujet en résolu? Tu as toujours un problème donc ça ne l'est pas :p

Tout bête : lors de l'accrochage tu stockes aussi le côté par lequel tu es arrivé sur le point (std::pair est ton amie).
Tu peux stocker ça avec -1 ou +1, et avoir comme comparaison (hooks[n].second * p > 0).
Par contre bidouille un peu avec les signes, je suis pas sûr s'il faut stocker la position avant ou après croisement, mais ça devrait être vite fait de tester :p

Note que dans ton code, il peut être plus judicieux d'utiliser une référence sur hooks[n] plutôt que d'appeler 3 fois operator[]. Et je vois au pop_back() que tu n'utilises pas un std::stack :p

Soundii>
Yep justement le soucis c'est que j'utilise pas des angles, mais bon si je trouve rien d'autre je ferait chaque step une conversion pour l'obtenir...

Deezee>
Le soucis c'est que le coté par lequel j'arrive bah ça veux pas dire grand chose vu que la corde peut aussi bien être a la verticale ou a l'horizontale :/
J'avais testé en horizontal mais c'était buggé dans certaines situations.
Après peut être que je me complique trop la vie, comme souvent x)

Pour le coup de la référence yep mais bon la j'essaye déjà d'avoir un code qui marche avant de l'optimiser (vu que je le bidouille pas mal).
Et la std::stack je peut pas l'utiliser étant donné que pour l'affichage de ma corde il me faut l'accès a tous les éléments.

Bah pas besoin de calculer l'angle au pire, tu peux faire ça à partir des cordonnées x/y... M'enfin je crois

Ouaip bah ça justement, je vois pas trop comment faire sans passer par des coordonnées polaires.

Quand je dis "de quel côté" c'est "de quel côté du segment reliant le point d'attache précédent au nouveau point d'attache lorsqu'un croisement a lieu".
Et cette valeur c'est p1, l'angle direct de la corde avec l'obstacle avant croisement, qui change de signe selon le côté par le quel on croise.

Je me fends même d'un copier-coller-corrigé :

Soit A l'accroche (haut de pile), P et P' ton perso aux temps t et t+1, O ton obstacle. Donc :
- Tu calcules et tu stockes p1 = AP^AO
- Tu mets à jour le perso
- Tu calcules p2 = AP'^AO.
- Si p2 * p1 <= 0, le produit a changé de signe lors du déplacement, donc ta corde et ton obstacle se sont croisés :
   - Tu empiles O et le signe de p1
   - Tu soustrais ||AO|| à ta longuer max.

Ah okey :b
Bah merci, ça fonctionne bien  
Je peut virer les angles du coup x)

Les angles c'est le mal :p