(Aide) Attention: virage dangereux

Répondre
Partager Rechercher
Salut les loulous,

Voili. Depuis pas mal de temps, quand je reviens sur SL, j'essaie de faire avancer une voiture toute seule en mode physique. Il y a quelques mois, vous m'aviez donné quelques pistes pour la faire suivre d'une espèce de carriole.
Le problème actuel qui se pose (qui me ronge, lol, c'est vrai en plus), c'est de la faire tourner smoothement dans les tronçons de virage. Jusqu'à présent, j'utilisais des petits parallélépipèdes transparents comme cibles successives que je semais dans les virages. Mais le problème, c'est que non seulement c'est très fastidieux à poser (surtout quand on veut changer le circuit ou qu'on déménage), mais c'est aussi "coûteux" en prims, puisqu'il en faut bien 5 par virage.

L'idée, c'est que lorsque le sensor de la voiture détecte le tronçon de virage d'un certain type (mettons virage à droite, 10m, 90°) et avec un certain nom, celle-ci suive une liste de points (positions/rotations) "virtuels" (et non des prims réels) calculés à partir du root détecté de ce virage. De sorte que la feignasse que je suis n'ait pas à ré-enregistrer à chaque fois un itinéraire ou à disséminer des prims comme des cailloux: tout serait dans le nom du tronçon.

Avec l'aide d'une "scripteuse" américaine que j'ai rencontrée sur un forum, j'ai fini par obtenir un script provisoire, qui ne marche pas. Elle s'obstine à vouloir travailler là dessus, mais j'ai le sentiment qu'elle ne maîtrise pas complètement le sujet (et elle me soutire à chaque fois 1500L pour une ou deux lignes de code modifiées sans que ça marche, ). Le voici:

Code PHP:

integer target_id;
string   CibleduSensor "virage90";// ici, c'est le nom du virage qui déterminera le comportement de la voiture
float    scandistance                  20.0;
float    scanangle                     PI
list 
offsets = ["<-0.990,-0.40,0.0>","<-0,84.2,-0.62,0.0>","<-0,67,-0.830,0.0>""<-0.34,-0.83,0.0>" ];// liste des offsets successifs calculés à partir du root
integer count;

move()
{
    
vector new_target llGetPos() + (vector)llList2String(offsets,count);
    
llSay(0"Je me dirige vers le point suivant " +(string)new_target);
    
llRotLookAt(llRotBetween(<1.0,0.0,0.0>,llVecNorm(new_target-llGetPos())),1.0,0.4);
    
llMoveToTarget(new_target4.0);
    
target_id llTarget(new_target0.5);
}

default
{
    
state_entry()
    {
        
llSetStatus(STATUS_PHYSICS,FALSE);
//        llSetRot(ZERO_ROTATION);
        
count 0;
    }

    
touch_start(integer total_number)
    {
        
llSetStatus(STATUS_PHYSICS,TRUE);

        
llSetBuoyancy(1.0);
        
llSensor(CibleduSensor,"",ACTIVE PASSIVE,scandistance,scanangle);
    }
    
    
sensor(integer num)
    {
        
vector START llDetectedPos(0);
        
llSay(0,"Le point de départ détecté est" + (string)START);
        
llMoveToTarget(START,4.0);
        
//llRotLookAt(llRotBetween(<1.0,0.0,0.0>,llVecNorm(START - llGetPos())),1.0,0.4);
        
target_id llTarget(START,0.5);
    }
    
    
no_sensor()
    {
        
llSay(0,"yé pas trouvé le point de départ");
        
llResetScript();
    }
    
    
at_target(integer tnumvector targetposvector ourpos)
    {
        if (
tnum == target_id)
        {
            ++
count;
            
llTargetRemove(target_id);
            if (
count >= llGetListLength(offsets))
            {
                
llStopMoveToTarget();
                
llResetScript();
            }
            else
            {
                
move();
            }
        }
    }

Résultat:
- La voiture bouge un peu mais fait n'importe quoi et s'arrête au premier point/offset je crois bien.
- J'ai l'impression que la ligne llRotLookAt ne permet pas de bien calculer les rotations successives. Enfin, elle me paraît bizarroïde.
- De plus, si je modifie la position du circuit, comme les offsets sont calculés globalement et non par rapport au local du root, toutes les données seront fausses, j'imagine, alors quel intérêt?

Bref, si vous aviez des solutions, ce serait cool, car je crois que je vais me crasher avec ma voiture contre un mur en prims.
Salut^^,

Oui, je l'avais essayé avec une espèce de train. Dans ses deux versions (au début, il était no modify). D'ailleurs, quand j'ai pu regarder les scripts, je me suis dit comment un être humain peut concevoir tout cela: c'est d'une telle complexité que c'en est déprimant (pour moi en tout cas), ça laisse rêveur. C'est assez magique d'ailleurs au moment de l'installation, avec le système de bornes et de balises, et les beaux arrondis "magnétiques" que l'on obtient dans les virages.
L'inconvénient, c'est que si le circuit doit changer, il faut tout recommencer. Je ne sais pas pourquoi tu le considères comme bêta encore, car il marche très bien. Le seul truc que j'avais noté, c'est que le véhicule, au bout d'un certain nombre de tours, se met à pencher sur le côté (axe X) mais j'en avais déduit que c'était moi qui avais mal installé les bornes.
Citation :
Publié par Poisson.Soluble
L'inconvénient, c'est que si le circuit doit changer, il faut tout recommencer.
Oui c'est sûr, mais c'est le choix que j'avais fait pour limiter le nombre de primitives utilisées puisqu'au final il n'en reste qu'une qui sert de repère spatial. Mais la mise en place est assez rapide et on ne change pas de circuit tous les jours... si ?
Citation :
Publié par bestmomo
Oui c'est sûr, mais c'est le choix que j'avais fait pour limiter le nombre de primitives utilisées puisqu'au final il n'en reste qu'une qui sert de repère spatial. Mais la mise en place est assez rapide et on ne change pas de circuit tous les jours... si ?
Non, et effectivement, assez simple d'utilisation, il faut juste suivre les instructions/illustrations dans les pages pdf. Je ne sais pas quels retours tu avais eus par les testeurs. Moi, j'avais eu ce problème de véhicule qui penche au bout d'un certain nombre de tours, sur un terrain pourtant parfaitement plat (une large prim dans le ciel): j'aurais mal posé les balises?
Bon je vais m'y ré-atteler, c'est probablement la solution la plus efficace.
Citation :
Publié par Poisson.Soluble
Non, et effectivement, assez simple d'utilisation, il faut juste suivre les instructions/illustrations dans les pages pdf. Je ne sais pas quels retours tu avais eus par les testeurs. Moi, j'avais eu ce problème de véhicule qui penche au bout d'un certain nombre de tours, sur un terrain pourtant parfaitement plat (une large prim dans le ciel): j'aurais mal posé les balises?
Bon je vais m'y ré-atteler, c'est probablement la solution la plus efficace.
J'ai eu une fois un retour concernant un comportement tel que tu le décris. Je n'ai jamais réussi à le reproduire, donc aucune idée sur son origine. J'avais commencé à modifier le code pour sortir du mode physique avec les fonctions fast. C'est beaucoup plus stable mais il faudrait que j'adapte la longueur des étapes élémentaires de mouvement en fonction de la vitesse pour avoir quelque chose de vraiment fluide. On pourrait alors avoir des véhicules non limités en nombre de primitives (enfin, la limite normale ).
Oui, enfin, je ne partage pas ton enthousiasme pour la fonction FAST, je trouve ça laggy et pas toujours très fluide. Mais effectivement, c'est bien par rapport au dépassement de prims et je ne sais pas si dans l'avenir les meshes seront physico-compatibles.
Je vais réessayer pour voir si ce problème de véhicule qui penche demeure. Il faudrait peut-être rajouter un script qui par intermittences rétablisse l'objet à 0 dans la rotation X.
PS: avoue que ce serait cool que par le nom du tronçon, le véhicule puisse déterminer son itinéraire automatiquement, tout comme tes bornes s'alignent magiquement entre deux balises.
En fait, je n'avais pas enlevé le circuit bestmomotien (de taille réduite, en gros un rectangle de 40m sur 30m) que j'ai retrouvé sur une des nombreuses plateformes qui peuplent le ciel de mon terrain. J'ai retenté l'expérience.
Deux trucs strangeoïdes:

1. L'effet "Tour de Pise" dont on a parlé plus haut: j'ai pris les mesures sur 12 tours accomplis. La rotation X (les autres ne varient pas) réglée sur 0 au départ devient: 1e tour: 3.15° 2e tour 5.65 3e 7.65 4e 9.25 5e 10.65 6e 11.40 7e 12.05 8e 12.55 9e 12.95 10e 13.30 11e 13.45 12e tour 13.65. Sur un véhicule haut du type locomotive, ça se voit pas mal. Effet de collision? Pourtant le véhicule est "phantom".

2. Sur la moitié du parcours environ, le cheminement est très lent, comme si le véhicule était entravé, avant d'aller super vite jusqu'au point d'arrivée.

Par contre le "tracé" des virages est parfait.

Il faut sans doute que je reprenne l'installation.
Citation :
Publié par Poisson.Soluble
1. L'effet "Tour de Pise" dont on a parlé plus haut: j'ai pris les mesures sur 12 tours accomplis. La rotation X (les autres ne varient pas) réglée sur 0 au départ devient: 1e tour: 3.15° 2e tour 5.65 3e 7.65 4e 9.25 5e 10.65 6e 11.40 7e 12.05 8e 12.55 9e 12.95 10e 13.30 11e 13.45 12e tour 13.65. Sur un véhicule haut du type locomotive, ça se voit pas mal. Effet de collision? Pourtant le véhicule est "phantom".
Je ne me l'explique pas non plus. Le script calcule chaque fois la position et la rotation à atteindre et commande le mobile. Mais les voies (et les lois) de la physique dans SL sont parfois impénétrables. C'est d'ailleurs une bonne raison pour s'affranchir du "physique".


Citation :
Publié par Poisson.Soluble
2. Sur la moitié du parcours environ, le cheminement est très lent, comme si le véhicule était entravé, avant d'aller super vite jusqu'au point d'arrivée.
Là je ne vois qu'un effet de lag. Si c'est un passage où la vitesse est plus rapide la charge de calcul est plus importante et peut expliquer paradoxalement le ralentissement. J'ai aussi constaté cet effet selon les moments et les sims où j'ai fait mes tests.

Citation :
Publié par Poisson.Soluble
Par contre le "tracé" des virages est parfait.
Un échantillonage sur un pas de 40 cm permet en effet de donner une impression de courbe parfaite. On peut encore faire mieux en "non physique" puisque le repère change pour devenir celui du pas temporel et l'échantillonage se fera forcément sur des pas plus courts. Et c'est d'ailleurs indispensable pour cette fois ne pas avoir des effets de saccades. Par contre la charge de calcul va augmenter. Il faut placer dans la balance cette charge plus importante au niveau du script avec la charge du moteur qui gère le physique. Seuls des tests pourront répondre à cette question.

Dès que j'ai un moment pour modifier le script du mobile dans ce sens je te donne les résultats. Pour le moment j'ai encore pas mal de lignes de code à écrire pour le projet "Change Link" avec Sandrine.
Citation :
Publié par bestmomo
Pour le moment j'ai encore pas mal de lignes de code à écrire pour le projet "Change Link" avec Sandrine.
Salut,

Pour le moment, rien de pressé, don't worry, du moins pour moi, je ne viens que très peu sur SL depuis quelque temps. Ah oui, si tu publiais une 3e version: pour te signaler que le script dans les petites "bornes" jaunes n'est pas ouvrable, mais peut-être est-ce volontaire, je ne sais pas. Bon travail et bonne journée.

PS: pour le ralentissement à certains endroits, comme ce sont toujours les mêmes zones du parcours où le véhicule ralentit, peut-il s'agir du lag? J'avais pensé que c'était peut-être lié au moment de l'installation, à des choix (via le menu) de mesures différentes entre deux bornes.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés