Dan's Orbiter page
Orbiter Francophone => Création Orbiter Francophone => Topic started by: picto on 14 May 2007, 03:24:09
-
Il est temps de vous dévoiler quelques screens d'un nouveau travail
que nous avons entamé avec Korben. Il est évidemment à la prog.
Etc ... etc ... et ce coup ci, ce n'est pas un poisson d'Avril ;)
Pour l'instant, les Vessels utilisent le Bullet.dll de Korben ainsi que des DLLs propres
à chaque Vessels, deux douzaines de modèles existent déjà mais certains utilisent encore
Spacecraft3.
Nous cherchons à mettre au point des déplacements de type atmo en orbite pour coller
à l'univers Star Wars et tout un tas de petites surprises sympa.
Toutes les contributions à ce projet qui est un projet de longue haleine seront les bienvenues.
Je remercie Papy au passage qui nous a aidé à mettre au point les configs orbitales des vaisseaux.
(http://img02.picoodle.com/img/img02/8/5/13/f_039Starwarsm_3188025.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_037Starwarsm_a4c9a14.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_035Starwarsm_ca2410d.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_036Starwarsm_dee9c9b.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_f001Starwarm_e4ff116.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_f006Starwarm_f8625e8.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_f012Starwarm_b4ff668.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_f018Starwarm_07da4bb.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_f020Starwarm_bc3ed4f.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_040Starwarsm_67e7cc9.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_043Starwarsm_c201ab0.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_053Starwarsm_75ddaf0.jpg)
(http://img02.picoodle.com/img/img02/8/5/13/f_054Starwarsm_79cde14.jpg)
-
Ca arrache diablement ! :hot: :love:
Que d'efforts pour te faire pardonner ton 1er avril foireux ;)
En tout cas bravo à vous deux, c'est un sacré boulot et j'espère qu'il ira loin.
Quand la finale arrivera, si vous avez besoin d'un installateur genre "Mmu"
ou "OS35" je suis pret à mettre à votre disposition. Ca fait plus clean.
Dan
PS: y a pas un vaisseau avec la reine amidala et les acteurs du 1 2 3 ?
je me ferais un plaisir de le descendre.
Post Edited ( 05-14-07 03:50 )
-
Que ça a de la gueule, mais de la gueeeule!!
Pagir
-
C'est géant! Bravo Picto & Korben :beer:
Nous cherchons à mettre au point des déplacements de type atmo en orbite pour coller
à l'univers Star Wars et tout un tas de petites surprises sympa.
Computerex a fait un module qui permet de se déplacer en vol atmosphérique dans l'espace:
http://www.orbithangar.com/searchid.php?ID=2801
-
Merci ;)
No Matter, oui je l'ai essayé, mais comme il le dit, le vecteur reste " proche "
de la direction dans laquelle on veut aller ... et c'est bien là le problème :sad:
C'est presque plus difficile à utiliser que le déplacement réaliste d'Orbiter.
Avec un peu d'entrainement, avec les moteurs poussant doucement, je réussis
à faire des Flybys rapides au travers de la flotte ennemie ... de là à pouvoir viser
sans s'arrêter et devenir à son tour une " cible de choix ", il n'y a qu'un pas
que l'IA, heureusement encore inexistante :badsmile: se refuse de franchir ...
Mais Korben s'attelle au problème, et connaissant son talent, il va réussir.
-
A mon avis faut utiliser addforce, avec ca tu part a la vitesse lumiere dans n'importe quel direction.
mais y a un truc... Tu peux pas pousser ton cailloux n'importe comment:
double F=GetMass()*DeltaSpeed/SimStep;
AddForce(_V(0,-F,0),_V(0,0,0));
Avec ca plus GetAngularVelocity+SetAngularVelocity pour les rotations
c'est control total, a la cool.
Dan
Post Edited ( 05-14-07 04:47 )
-
Message modifié ( 17-12-2009 11:37 )
-
oui mais eux ils veulent un controle du vol de leurs vaisseaux, pas partir à la vitesse de la lumière ;)
Faites iech les gars, maintenant j'ai envie de vous faire ca , je sais comment.
(addforce+SetAngular) mais va falloir vous debrouiller, ...pas le temps :sad:
"Je n'aurais pas le temps, pas le temps" :music:
Dan
-
Oui, je connais ça aussi, mais est ce utilisable sur une scène de bataille ?
Le truc, c'est de pouvoir voler comme un avion. D'avoir des sensations de
contrôle atmo.
Je vais essayer. Mais je connais Korben, il veut arriver à quelque chose par
lui même, pour le plaisir d'apprendre aussi.
Le but ultime, c'est d'arriver à ce que les scènes de combat soit un pur jeu
d'action, un défouloir quoi. Donc comme pour les vrais pilotes de chasse.
Ne pas avoir à penser au vol pour ne penser qu'à dégommer son prochain tout
en évitant de se faire dégommer soi même.
Ah , Dan, tu as été plus rapide que moi sur le coup :)
Message modifié ( 14-05-2007 05:31 )
-
Je ne devrais pas parler à la place de Korben, mais je crois que c'est son idée.
Il appelle ça du vector thrusting et c'est de cette façon, je crois, qu'il imprime
les mouvements avant destruction des cibles touchées.
J'ai trouvé ça dans le code...
//AddForce(_V(0, 15, -15), _V(0, 1, -0.1));
// Reaction appliquée a la cible
Et d'après ce que j'ai compris, le principe est applicable aux vaisseaux pilotés
et même à des missiles auto guidés ( c'est en cours )
Et ça fonctionne sur n'importe quel objet d'orbiter, même ISS, j'adore la truffer
aux pruneaux, ça défoule .... après tous ces rendez vous loupés :)
Et puis, Addforce, c'était logique dans notre cas non ? ;)
Message modifié ( 14-05-2007 07:49 )
-
La saga continue. Beau boulot et bonne continuité dans ce gros projet.
-
ouaaaaah: :trucdeouf::bave::trucdeouf:
-
Mortelle ces photos ;)
-
picto a écrit:
et ce coup ci, ce n'est pas un poisson d'Avril ;)
moi, perso, tant que y'aura pas de confirmation de Korben, moi, perso, j'y croit pas
(http://www.funicone.com/modules/Gallery/images/smouinon/04.gif)
-
Et bien je peux te dire que ce coup là, c'est du vrai, fait moi confiance !! ;)
-
Bon, je confirme alors !!!!! c'est en cours
Maintenant apres le bullet.dll, qui sais toucher et détruire n'importe quelle cible dll ou spacecraft3
il suffit de lui ajouter l'attachement soit:
id : GDAM enemy
id : FDAM friendly
id : CDAM civilian
ou les coordonnées x,y,z correspondront a des niveaux de résistance, "correspondront" car pour l'instant
seul le z est utilisé le bullet etant le niveau de dégradation minimal (-1) une torpille (-10)
Ces attachements on aussi le méme role que l' IFF (Identification Frend or Foe)
(je ne remercierait jamais assez DAN pour cette idée )
Je travaille sur une extention le turret.dll qui utilise le méme algorythme que le bullet "detection de la cible la plus
proche et action" .
une tourelle de tir automatique capable de s'orienter sur la cible la plus proche et de décocher une
rafale de bullets automatique lorsque cette cible entre dans son range.
Qui etant un vessel a part entiére pourras se greffer sur n'importe quel vaisseau dll ou spc3 possédant des
attachement classiques
L'activité/inactivité de cette tourelle sera commandé par un attachement spécifique id : TCOM
en détachant le TCOM au lieux de détacher les tourelles, il les mettra en mode de combat ou repos.
pour ces tourelles l'identification IFF est impérative. (le seul moyen pour permettre a un spc3 de commander quelque
chose).
puis viendras le torpédo.dll pour une torpille a homing toujours le méme algorythme mais enrichis d'une IA
sommaire et surtout des premier pas du vector thrusting
utilisant le méme principe que le bullet
lorsque que le bullet rencontre une cible il se colle à elle par recopie de ses vecteurs, décrémente sa résistance,
génére la serie d'explosion, et l'explosion/destruction finale.
Pour faire cela j'ai utilisé les propriété du vesselstatus2 je compte utiliser le méme principe; car à l'instar
du jeu de chez KRO,dans un futur chasseur il va me permettre d'utiliser un mode "poursuite" ou dans un dogfight le
chasseur égalise sa vitesse à celle de la cible.
Mes premier pas sur les HUD spécifiques (commencé, je découvre juste) et pourquoi pas un mfd pour la gestion de
l'armement
Voila , plus de Preuves ?????:)
-
rho mais allé, si, c'est bon, je vous croit, j'arrete de vous taquiner !!!
-
Ca va être dément ! ;) Korben, tu m'épateras toujours ;) Si tu veux une petite formule pour le suivi, j'en ai une qui
utilise les caps. Mais bon, je suppose que vu l'altitude à laquelle tout se passe je pense que ça ne te servira pas
vraiment ;)
Bref, ça va ncore être du boulot de pro ;)
-
En fait Brain la solution se trouve dans le code de tir du bullet, j'ai un bon feeling sur le truc.
je l'ai déja testé sur le bullet et j'arrive à annuler sa vitesse initiale , il est litéralement stoppé et scotché a sa cible
Puis je récupére ses coordonnées dans le repére de la cible et j'applique a la cible un couple proportionnel
a la masse relative et la vitesse relative d'impact; Exactement avec le méme principe.
pour un autopilote athmo tu utilise les surfaces pour modifier les cap et altitude
dans un autopilote spatial il faudras utiliser les RCS de la méme façon. et cela dans le cas d'un vaisseaux orbiter
classique
comment appliquer cela en vector thrusting
2 solutions:
La 1 ere Celle de DAN qui va fonctionner c'est sur, c'est l' "addforce"
La 2 éme celle que je pressent, c'est modifier directement les vecteurs dans le vesselstatus
Dan je sais pas ce que tu en pense ?
De toute façon les 2 sont a mon avis envisageable et pour avoir un interface utilisateur convivial
(clavier, Rcontrol ou joystick) il faut que cet interface soit de méme type que le standard Orbiter
Il faudras , a mon avis, sur un tel type de vaisseaux, intercepter & rediriger les commandes des RCS standards
vers les commandes similaires de "vector thrusting"
Ce systéme permettras de conserver tel quel l'interface clavier et joystick standard d' Orbiter
-
picto a écrit:
Le truc, c'est de pouvoir voler comme un avion. D'avoir des sensations de contrôle atmo.
(http://img111.imageshack.us/img111/5486/sanstitrefd4.png)
faire avancé en gros, et donc quand ont arete d'accelérer, cette force nous ramene a un vecteur "0" par rapport a
notre balise de reference.
donc dans les grandes lignes, ont gere tout par rapport a cette balise de reference, quand ont accelere, ont est un
tout petit peu au dessu de notre vitesse orbital, quand ont ralenti, un tout petit peu en dessous, enfin ca depent
dans quel direction ont va, si c'est en arriere du vecteur de vitesse de la balise, dans notre réel vitesse (pas celle
aparente-par rapport a notre balise-mais la réel par raport a notre terre, la vitesse pour nous maintenir en orbite,
vous me suiver...) ont ralenti un peu, dans faut limiter, pour pas ce desorbiter et cramer dans l'atmosphere, et si ont
accelere, ont est untout petit peu en avant de notre vitesse orbital, quand se deplace a gauche et a droite , ca chnge
aussi
enfin voila, c'etait mon TILT dans les grandes lignes, reste a améliorer, mais bon, si ca peut donner des idée
PS, ya une image, parce que ca a bugué chez moi, j'ai eu juste le temp d'apuyer sur "impr écran syst", ca m'evite de
tout retape le debut de mon texte; oui je sai j'entant deja les cri "rho la faignasse" je m'en fou !!! :badfinger:
-
Petit problème yoann ... il faudrait autant de balises qu'il existerait d'altitude. Bref, tu peux très bien voler à la même
vitesse sur 2 altitudes différentes et pourtant, l'un dépassera l'autre ... de part leurs orbites différentes ...
Donc, ça n'ira pas .. mais l'idée était bonne ;)
-
et si ont met cette balise, enfin les infos quel renvoie, au niveau de l'ojectif final qui lui, peut ce deplacé, comme ca, ca
fonctionne tout autant, on a un repere pour les programmeur (la je my connai pas...) et comme ca, qu'on se deplace
n'importe ou, en suivant la bataille, ont a pas de limite d'altitude ! bon, reste quelques truc a ameliorer la heu...comme fixé une nouvelle balis quand l'ojectif est detruit. mais si apres ont est a 10 banlieux de la terre ou sur saturne jupiter ou autre, faut modifier tou ca
BREF
bon, aller je reflechi, une bonne nuit de someille, et demain je vous met une idée qui arache et resou tout !!! ( aller
faut etre optimiste dans la vie...)
Message modifié ( 14-05-2007 19:10 )
-
yoann la "balise" existe, c'est la cible
-
korben62 a écrit:
comment appliquer cela en vector thrusting
2 solutions:
La 1 ere Celle de DAN qui va fonctionner c'est sur, c'est l' "addforce"
La 2 éme celle que je pressent, c'est modifier directement les vecteurs dans le vesselstatus
Dan je sais pas ce que tu en pense ?
Si tu vesselstatus tu est en charge de tout et surtout consistance deplacement
en fonction du framerate sans compter que tu va "contre" la nature d'orbiter.
Si tu fait par addforce t'a des super réacteurs et tu laisse Orbiter ce
debrouiller avec le reste.
Perso je partirais en addforce. Plus intteressant et moins compliqué
(faut la formule magique plus haut)
[EDIT] j'ai enlevé les 340 ligne de "self thinking" j'ai la solution voir plus bas :gift:
Dan
Message modifié ( 15-05-2007 06:14 )
-
[EDIT] enlevé aussi voir soluce plus bas :gift:
Dan
Message modifié ( 15-05-2007 06:16 )
-
YESSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS !!!!!
Te casse pas le plot c'et du tout maché, je vole comme un
oiseau autour d'ISS en DGIV a la vitesse constante du réacteur.
Ca fait tout, inertie, leger retard suivant la puissance et le poids
ca s'arrete si tu met le reacteur à zero sinon ca garde une vitesse
constante dans la direction du nez (avec inertie s'il vous plait)
Donc spawn l'objet invisible REF comme j'ai expliqué plus haut
et simplement tu rajoute ca dans timestep de tout tes vaisseaux:
(faudra changer quelques chiffres ca c'est pour un DGIV de 20 tonne)
[demandez le code au comptoire]
Te reste plus qu'a faire le controle d'attitude (RCS) en utilisant SetAngularSpeed
pour pas te faire chier ou avec des RCS comme tu veux et voila.
Elle est pas belle la vie ? :gift:
Dan
Message modifié ( 16-05-2007 04:44 )
-
:hot:
:top:
:beer:
T'es dingue quand même ...
Une chtite release de DGIV, et avant dodo zou ...
Tu sors ça en deux heures !!!
Bravo !!! :top:
Reste plus que l'IA :lol:
Message modifié ( 15-05-2007 06:19 )
-
Une machine... c'est une machine... :wall:
Pagir
-
NOTE:
Pour l'inertie quand tu change de direction (si il prend rapidement de la vitesse sur le nouveau cap ou pas)
il faut que tu tripote les chiffres dans ces deux lignes:
double Fy=GetMass()*max(-0.090,min(0.090,local_vel.y*5))/Data.SimStep;
double Fx=GetMass()*max(-0.090,min(0.090,local_vel.x*5))/Data.SimStep;
Donc tu tripote "PuissancePoussee" + ces deux lignes et tu doit pouvoir controller
tout les vaisseaux et leurs donner des comportements sympa.
(plus rapide pour le tie plus agile pour le x-wings ?)
En tout ca c'est vraiment sympa de voler comme un avion autour d'iss :)
OOOOPS j'ai enlevé l'explication a propos de l'objet "REF" mentionné plus haut.
Donc il nous faut un objet de reference sur lequels tout les autres vaisseaux vont ce baser.
Comme personne ne peut depasser une certaine vitesse EN REGARD de ce point tu évite
la dispersion de la flotte (pas de passage a 10'000 km/h) Chaque vaisseau peut
etre doté d'une vitesse max RELATIVE qui dépend de la poussée reacteur. (100m/s dans
toutes les directions au regard du point de reference par exemple)
Les gros peuvent aller plus lentement, les petit plus vite. etc. etc.
Donc :
-Au premier timestep et une seul fois, chaque vaisseaux scanne tout les autres,
si il trouve un plus lourd, ne fait rien.
-Le plus lourd ne trouvant rien va spawner un vaisseau invisible (meme pas besoin de dll, juste un config et un mesh invisible) a la même position que lui et même vitesse (copie du vesseltatus simple, peut etre une dizaine de mettre de decalage pour eviter le bug de "meme position" dans orbiter)
Cet objet s'appelle "REF" c'est le referent pour tout le monde. Il suis sont chemin, tout les autres
ont des vitesss relative PAR rapport a lui. (pas position, vitesse)
Donc un tie et un x-wing ne peuvent pas s'eloigner a plus de 200 m/s l'un de l'autre
si tu a mis puissance reacteur "100" (100+100=200)
J'ai oublier aussi de mentionner, plus besoin de thrusters, met toutes leurs
puissance a zéro et garde les juste pour les flammes.
Et voila !
Dan
Message modifié ( 15-05-2007 06:55 )
-
Dan, si tu veux casser du Tie avec un Wing, te gêne surtout
pas pour rajouter toi même, tu as les cpp et h dans ta boite !
Allez quoi ... avant dodo ... :badsmile:
Message modifié ( 15-05-2007 06:24 )
-
Et je vais vous chier un FrelonIX surpuissant qui va tout detruire votre flotte AH AH AH AH
("clong" ca y est il a pété un cable :badsmile: )
C'est exxitant votre truc, par contre l'aurtohgraphe en prend un coup
je suis a 240%... désolé ;)
Dan
Message modifié ( 15-05-2007 06:38 )
-
cé pa jainant tan ke sais pa dan l' kod !
-
Une idée comme ça ... :wonder:
Parce que je crois que ça pourrait être sympa pour faire de la stratégie plus tard.
Ca pourrait servir à transférer une flotte entière à la façon classique d'Orbiter ?
-
Et ca marche IMPEC !!!!
Je fait des passes de tir sur ISS :)
Juste les RCS du DGIV sont a chier pour ce genre de truc (je peut pas utiliser killrot sinon ca m'arrete
mon PRO500 NULL SPEED modifé) Moi j'utiliserais setAngular pour les RCS... pour un vol "avion"
pas d'inertie en rotation (tu pousse plus le manche ca s'arette la rotation)
Dan
-
picto a écrit:
Une idée comme ça ... :wonder:
Parce que je crois que ça pourrait être sympa pour faire de la stratégie plus tard.
Ca pourrait servir à transférer une flotte entière à la façon classique d'Orbiter ?
Le truc sympa: si tu bouge le ref tout le monde va bouger avec lui en tout cas toute leurs vitesses
relative vont bouger avec lui. Donc si il accelere dans une direction ben tout les autres aussi.
Si ils allaient tous dans la même direction il vont accelerer tous en même temps
que le REF. Ceux qui s'éloignaient des autres a 100 m/s vont continuer a s'éloigner a 100 m/s
Voila une IA de flotte vite faite ;) Il prennent juste tous la même direction
et on bouge juste le REF (assez lentement sinon les "réactifs" vont semer
les lents a réagir)
Dan
Message modifié ( 15-05-2007 06:59 )
-
C'est dément !!!
Bravo !!!
Ca va être l'éclate ce truc.
Je ne sais pas si tu as jeté un oeil dans le code de Korben, mais il y a
déjà des moyens de reconnaitre amis ennemis et cicils ...
civils, je voulais dire :)
-
J'ai testé ton code DAN 1 mot FABULEUX
c'est exactement ça en plus je vois plein de possibilité
le vaisseaux REF
j'ai testé en utilisant un Wing de 3 xwings quelques tie pour servir de cibles et un vaisseaux REF
dans chaque Wing de chasseur le leader utilise le REF
et chaque wingman utilise son leader en guise de REF ben ça marche nickel
y a plus qu' a programmer une
une selection REF WINGMAN de façon a ce que quand le LEADER est detruits le WINGMAN reviens
au vaisseaux REF ou reprend comme leader, le xwing de d'ordre le plus petit
j'ai inactivé le thruster MAIN et je l'utilise comme effet lumineux, je récupére son level pour
regler la vitesse, quand on appuis sur "numpad+" ça fait un effet de booster à la GALACTICA
-
Ca fonctionne du tonnerre !
Merci Dan ! Pour reprendre les mots de Korben, c'est fabuleux !
On s'y croirait ! :top:
Ce qui m'étonne le plus, c'est que ça ne fusille pas l'orbite en cours.
C'était le seul doute que j'avais sur la faisabilité d'un tel truc.
:down: le MFD SWFS à côté de cette magnifique chose que tu viens de faire!
Même utilisé comme éditeur de scenario ( en local ) c'est beaucoup mieux que celui d'Orbiter !
Message modifié ( 15-05-2007 21:58 )
-
korben62 a écrit:
dans chaque Wing de chasseur le leader utilise le REF
et chaque wingman utilise son leader en guise de REF ben ça marche nickel
Génial ! :hot:
Ca va arracher tout ca !!!!!!
Z'avez pensé a OrbiterSound pour les sons ?
Dan
-
Vi ...
J'ai une chtite banque sympa...
Et ...
plein d'idées. ;)
-
Le code du moteur SW, ce serait dément sur des bots et autres pods (le PSA de Well par ex)
-
Oui Oui pour les sons pas de prob je sais faire j'ai déja utilisé sur le SAN KU KAI
la, je sais pu par quel bout attaquer .
J'etait en train de programmer la tourelle , puis j'ai testé le truc des wingmans alors je me suis lancé
dans l'idée que ce serais bien que le leader du wing pourrais selectionner ses wingmans dans une liste de
wingman potentiels proche. Alors j'ai Picto en MP qui me dis que se serais mieux avec des setangular
et en méme temps je me suis dis que se serais bien que les wingmans recopient leur attitude
sur celle de leur leader, voir se mettent en formation, bref je me disperse et j'ai la téte qui tourne:wall:
Je vais me rassembler et prendre le truc dans l'ordre.
-
ah oui vu que j'etais pas la , j'ai pas bien compris l'histoire de la "formule magique" c'est ton code en fait DAN ??
-
Désolé Pascal :sad: , tu as oublié le bug destruction vessel cible :lol:
Sinon, y'a les gros qui avancent bien faut qu'on leur fasse leur modèle de vol aussi.
La méga avance bien aussi ... pis des idées avec des superpositions de thrusters pour le graphisme.
J'ai du mal sur les specs du Slave1, position bizarre, c'est dur à piloter :badsmile:
Je t'ai envoyé la caméra ...sans radar c'est pas facile quand même ... on se perd vite.
T'as reçu les wavs ? Y'a un ptit bug sur l'anim des ailes du Wing, petit hein :) ...
Je pensais faire un modèle plus détaillé pour le modèle piloté.
Faut pas oublier de pouvoir empêcher de rentrer dans n'importe quel vaisseau par la fenêtre F3.
Je sais pas si on peut faire des fumées dans l'espace pour les missiles.
T'as reçu mon petit topo sur l'IA ? L'est pas mal le Cargo iV pour des missions de récupération.
Les Ties sont un peu mous je trouve. J'ai fait un modèle de tourelle pas mal et trois lasers différents.
Chsais pas si il faut qu'on duplique ces DLLs là ? :wonder:
Un chti canon à ion qui tire sur la scène à partir du sol, c'est faisable avec le bullet ?
Message modifié ( 15-05-2007 23:34 )
-
korben62 wrote:
ah oui vu que j'etais pas la , j'ai pas bien compris l'histoire de la "formule magique" c'est ton code en fait
DAN ??
Je parlais de ca:
double F=GetMass()*DeltaSpeed/SimStep;
AddForce(_V(0,-F,0),_V(0,0,0));
On peut pas pousser sans tenir compte de la masse et du delta time sinon
ca donne saccadé et n'importe quoi. C'est inclu deja dans le code
"star wars" plus haut.
Dan
-
Ouais y a ça en plus
le x-wing ? ah oui les thruster suivent pas le mouvement des ailes
le canon a ion mainant, HELP y veut ma mort
-
korben62 wrote:
Ouais y a ça en plus
le x-wing ? ah oui les thruster suivent pas le mouvement des ailes
le canon a ion mainant, HELP y veut ma mort
Ca c'est picto, non seulement il veut que tu construise la tour eiffel en
allumette mais en plus tu dois le faire seulement avec les dents :badsmile:
M'enfin, faut être exigeant dans la vie ;)
Dan
-
Vi, mais je participe avec mes moyens ... j'ai même mis
le nez dans les cpp pour tripoter des trucs :badsmile:
Et puis, il y a tous les fichiers annexes, meshes, dds, wavs, scn, cfg, ini ...
C'est du boulot aussi :sick:
Et puis, pour le canon à ion, je suis sûr qu'avec ce code intégré au bullet
on peut tirer droit du sol vers une scène à 300 KM de là en ligne droite !
Message modifié ( 15-05-2007 23:58 )
-
leur attitude sur celle de leur leader, voir se mettent en formation
C'est même une nécessité pour le démarrage des scenarios avec des formations de Ties ...
Ils arrivent sur la scène par vagues successives, bien rangés ... et se déchainent quand
ils sont proches de leurs cibles.
Ensuite, deux possibilités, un compteur de temps et ou de destruction pour le déclenchement
de la vague suivante ....
-
Pb de "setangularvel" avec redirection de la commande des RCS réglé, et d'un, mais bon j'chuis pas satisfait
je vais lier le banck avec le virage
-
Level 9 ... avec textures de nuit, spéculaires et nuages.
Manque encore les configs et un config de système.
Ainsi qu'un deuxième soleil pour Tatooine
(http://img03.picoodle.com/img/img03/8/5/21/f_045Starwarsm_f3b315c.jpg)
(http://img03.picoodle.com/img/img03/8/5/21/f_046Starwarsm_bae4609.jpg)
(http://img03.picoodle.com/img/img03/8/5/21/f_047Starwarsm_b66767e.jpg)
(http://img03.picoodle.com/img/img03/8/5/21/f_048Starwarsm_3fbf56a.jpg)
Message modifié ( 21-05-2007 23:40 )
-
ha... la dernière et trop terrible! sa représente bien Hoth!
-
Magnifique ;) Pour le tir du canon à ion, ça doit être gérable mais un peu rapide car n'oublions pas qu'en orbite, bah
les vaisseaux tracent à 7 km/s par rapport au tir du canon ... donc gruger le tir pour donner une impression de ligne
droite par rapport aux vaisseaux ?? à voir ...
-
À partir du sol, si on compte un canon à 300km/s doit viser 7km devant le vaisseau si celui-ci est à 300km d'altitude...
à 300 000km/s, la vitesse de la lumière, il doit quand même viser 7 mètres devant... Évidemment, un ion ne peut aller
à la vitesse de la lumière, parce qu'il aurait alors une masse infini...
Quelle est la vitesse maximale de déplacement d'un ion? :doubt:
Il semble qu'un ion "terriblement rapide" se déplace à quelques milliers de km par secondes...
http://www.iforum.umontreal.ca/Forum/2005-2006/20051121/annee_interPhys_12.html
Disons, pour faire simple, qu'il tire à 3000km/s (ça ressemble à "quelques", non :badsmile: ): il doit encore tirer à 700
mètres devant la cible.
Par contre, dans ces conditions, la cible a peut-être une chance... Parce qu'à la vitesse de la lumière, c'est pas du jeu!
(Qu'est ce que je raconte... je devrais aller dormir...)
Pagir
-
Ah ouf réussi a passer a travers (zont mis des secu au boulot)
oui c'est magnifique
le tir pour donner une impression de ligne
droite par rapport aux vaisseaux
pour ça va falloir monter le canon a ion sur une monture équatoriale
-
C'est compatible avec ton Turret.dll ... je dirais même que c'est un exercice profitable ;)
-
pour l'instant le turret est plutot azimutal
-
Enfin vous m'avz compris je pense. Si le tir est rectiligne par rapport à la terre, il serait transverse par rapport au
vaisseaux, ça va faire bizarre ... il faudrait tricher avec une translation du tir pour donner l'impression que le faisceau
est aligné avec un vaisseau par exemple ... certes, c'est de la gruge, mais on parle bien de réalisme non ? :)
-
C'est un peu obscur ton explication :)
Tu serais pas un peu asthmatique des fois ?
Message modifié ( 22-05-2007 18:31 )
-
Belles planètes!
Le résultat devrait être esthétiquement très intéressant; j'espère que mon PC pourra suivre!
-
wep j'adore naboo et c'est fou comme elle ressemble a la terre!!
quand a corusante on dirait des crop circles sur le coté :badsmile: ou des agroglyphes si vous préférez
si cela ne vous évoque toujours rien (mais cela m'étonnerais) voila une img
http://www.erenouvelle.com/site/images/dosscrop-32.jpg
-
picto a écrit:
C'est un peu obscur ton explication :)
Tu serais pas un peu asthmatique des fois ?
Même pas ! ;) Pour faire simple, si un canon tire vers un vaisseau, même en anticipant de façon à le toucher, d'un
point de vue de ce vaisseau, le tir sera tellement rapide et la vitesse de ce même vaisseau sera telle que l'on aura
absolument pas le temps de voir quoi que ce soit ... ça serait dommage.
Alors que si on triche en faisant "suivre" le vaisseau par le tir et en réduisant sa vitesse, alors en vue aérienne, on
verra le faisceau arriver et traverser le vaisseau. Du coup le réalisme y gagne et ça peut être très sympa. Mais bon,
ça reste de la gruge ...
-
Seb, c'est du Level 9, une planète par une planète ça devrait aller.
Le plus long, ce sera pour le chargement au départ d'Orbiter. Sinon,
c'est un système optimisé d'Orbiter, le dessin est découpé en 1400
morceaux environ et seuls ceux visibles selon le moment sont affichés.
Tu n'as jamais essayé la Terre en Level 9 ?
Raptros, oui, je reconnais même certains coins du Québec ;) Vive Blue Marble !
Brain, ce coup ci c'est limpide... sûr que ça aurait de la gueule, avec le prog de
Dan, ça me parait très facile à faire du coup. Ca a vraiment foutu la physique
d'Orbiter en l'air ce truc là :lol:
-
picto a écrit:
Tu n'as jamais essayé la Terre en Level 9 ?
Si, justement, et chez moi ça rame un peu (bon, mon ordi est vieux, maintenant), alors je parle même pas de la Terre ou Mars
level 10...
-
Oui , bon , mais je pense pas que des vaisseaux de soutiens,de débarquement, ou de bombardement
se baladent a la vitesse de la lumiére quand ils sont proche de leur planete cible. Je doute aussi qu'ils
se mettent en orbite géostationaire a 36000 km , a la rigueur des vaisseaux de soutiens . trop loin pour débarquer
des troupes.
A mon avis ils se mettent en orbite basse , ce qui veut dire qu'un bombardement d'une cible donné ou débarquement
se fait à chaque orbite.
Donc le canon a ion obéis au mémes lois que les lancement classiques , il a une fenetre de tir.
-
Ok, mais je crois que Brain ne parlait pas de ça ... juste d'un effet visuel sympa, comme quand les transports rebelles
quittent Hoth et se font accompagner par deux coups de canon, rapides mais lents en même temps... on a le temps
de les voir... en fait, il faudrait gérer ces coups comme des missiles déguisés pour pouvoir rendre cet effet.
-
Un vessel sans meshe ? Juste un exhaust.
Bah tiens, un peu comme l'exhaust du DGex.
-
Le Bullet.dll offre déjà cette possibilité, exhaust ou pas exhaust.
Pour faire un second soleil aussi c'est pas mal le coup du faux vessel.
C'est surtout pour le mouvement qu'il faudra une mise au point sur un truc tiré depuis le sol.
Tirer en ligne droite sur un objet en Orbite et obtenir visuellement la dite scène !
C'est n'importe quoi SW :ptdr: ... mais c'est marrant à faire.
-
euuuh un second soleil?? comme sur tatoinne? se sera juste une texture parceque sinon les orbite seront plutot chaotique non?
-
Mos Eisley
(http://img01.picoodle.com/img/img01/8/5/25/f_073Starwarsm_a6d2056.jpg)
-
Excellent !
As tu résolu le problème avec une voiture pour qu'elle ne s'enfonce pas dans les faubourgs ?
:sage: Papyref
-
Malheureusement non en ce qui concerne l'élaboration du mesh.
Si j'étais courageux, je ressortirai ma petite calculette et abaisserai les points un par un selon le calcul que tu avais
élaboré pour épouser la rotondité de la terre, mais .... :sick: Trop de trucs à faire, plus tard peut être.
Reste la solution de meshland pour pouvoir faire évoluer un Sandcrawler et quelques droides ou animaux.
Korben connait cet addon. En ce qui concerne, la " vie " sur la base, les animations automatiques ne posent
pas de problèmes, car elles seront situées en centre ville.
Sinon, il n'y aura que des lands speeders et les espèces de barges que l'on voyait dans le troisième volet de la
trilogie., en les calant à une certaine altitude dès le départ sur le modeleur, plus de soucis pour les faire évoluer
n'importe où ! Il n'y a que la marche qui risque d'être un peu haute en centre ville pour les occupants ! :badsmile:
(http://img02.picoodle.com/img/img02/8/5/26/f_074Starwarsm_478acc3.jpg)
-
sublime. Tu nous fais quand le Stars Wars episode 7 ;)
-
un épisode 7? oui se serait bien mais il faudrait trouver une suite au 6 et je ne voit pas ce qui pourait se passe après.
par contre un starwars 0 (avant le 1) pourait etre tres bien
-
Raptros a écrit:
un épisode 7? oui se serait bien mais il faudrait trouver une suite au 6 et je ne voit pas ce qui pourait se passe après.
par contre un starwars 0 (avant le 1) pourait etre tres bien
il existe ne nombreux ouvrages à la suite de l'épisode six ;)
-
bin oui justement donc c'est déja fait et a moin d'en faire des film je vois pas.....
-
L'episode VII .... c'est parti !
R2D2 épouse une droïdette.
Pour s'apercevoir qu'il s'agit en fait d'un Gonk.
Et c'est le drame, il bascule du côté obscur ...
(http://img03.picoodle.com/img/img03/8/5/26/f_075Starwarsm_29a4ee8.jpg)
-
ahaaha :ptdr: et C3PO il est devenu homosexuel ;)
Message modifié ( 26-05-2007 17:00 )
-
Yan Solo ayant été congelé a perdu sa virilité et la princesse Leila qui voulait un enfant va le tromper pour assurer la
descendance.
Malheureusement l'homme de remplacement qu'elle a rencontré par hasard pour ce faire est un fils secret du
conseiller Palpatine qui a d'aussi mauvais instincts que ce dernier.
Yan Solo et Leila vont avoir des problèmes avec l'enfant qui lui aussi est attiré par le côté obscur et comme son
compagnon de jeu va être le rejeton de R2D2 et du Gong ça va fumer ! (du kif d'abord mais ensuite...)
A toi Picto d'imaginer la suite
:sage: Papyref
-
Bravo! superbe! il nous font même l'environnement! sinon Lucas a écrit la trilogie 7,8,9... ya un moment... mais je trouve
pas le titre du livre sur le net... un bouquin de 2000 a 3000 pages dans mes souvenirs de tio...
je le retrouverais un jours!!!!
-
Z'ont fait des ptits :)
Je vais essayer de trouver, si vous trouvez de chouettes images et plans des
barges de Jabba et autres véhicules de Tatooine, je suis preneur.
Un défi aux animateurs, pour le Pit droid .... faut tout replier .... selon les flèches.
Le truc rigolo c'est de faire vite et de donner l'impression que tout se replie
vers la tête dans un premier temps puis seulement après il tombe par terre.
Tout ça en un clin d'oeil ;)
Je suis sûr qu'il n'y en a pas un ici capable de faire ça :siffle:
(http://img02.picoodle.com/img/img02/8/5/26/f_002Starwarsm_69ec24f.jpg)
-
picto a écrit:
Je suis sûr qu'il n'y en a pas un ici capable de faire ça :siffle:
DE QUOI ? :grrr: tu va voir si c'est pas possible !
je te le fait en deux heures.... a tout de suite !!!
Nan, ca marche pas ta combine, je suis comme fonzy en fait :badsmile:
mais c'est possible of course.
Dan
-
Pit_droid.cfg
; === Configuration file for 01_Pit_Droid ===
ClassName = 01_Pit_Droid
MeshName = 01_Pit_Droid
Size = 15.0
Mass = 25; empty mass [kg]
MaxFuel = 1000 ; max fuel mass [kg]
Isp = 10000 ; fuel specific impulse [m/s]
MaxMainThrust = 10000
MaxRetroThrust = 10000
MaxHoverThrust = 10000
MaxAttitudeThrust = 1000
CameraOffset = 0 0 200
LiftFactor = 0.0
CrossSections = 0.020 0.025 0.022
EnableFocus = true
TouchdownPoints = 0 0 1 -1 0 -1 1 0 -1
Message modifié ( 31-05-2007 08:45 )
-
Pourquoi Orbiter fait il ce genre de trucs ?
Est ce à cause de la présence de plusieurs vessels sans DLLs identiques présents ?
Quelqu'un a t'il déjà rencontré ce genre de phénomène d'éclairage ?
Le renderer ne fait ça que sur deux des modèles identiques, pas sur le troisième.
Puis il inverse, ça dépend du vessel que l'on focalise avec la caméra.
Etonnant non ? Zbuffer ? Si quelqu'un connait la réponse à cette lancinante question :badsmile:
(http://img02.picoodle.com/img/img02/8/5/26/f_zarbim_6fa9895.gif)
Message modifié ( 27-05-2007 03:10 )
-
(http://img03.picoodle.com/img/img03/8/5/26/f_005Starwarsm_77a455e.gif)
C'est un drôle de phénomène.
Quand je passe les mêmes meshes en config base, ils cessent de clignoter.
De la même façon, dès que les hovers ou moteurs sont allumés, le clignotement cesse.
Le config, le même pour tous les meshes est celui du post au dessus.
Viblement, c'est un problème de rendu de la lumière ambiante.
Sous certains angles de vue c'est plutôt marqué. Sur cette image, ça correpond au temps
réel d'Orbiter. L'absnce de lissage des couleurs, c'est le gif, pas Orbiter ;)
Bizarre tout ça.
Message modifié ( 27-05-2007 07:06 )
-
Avec Nomatter ont a eu le même soucis avec un truc que l'on fait actuellement...
Je doit dire que nous étions perplexe. C'est Nomatter qui à résolu le probleme, le mieux est de lui demander.
Si je me souviens vien c'est parcque les landing point n'était pas assez haut... ce qui fait qu'orbiter ne savait pas
pour le rendu, si le mesh était côté jour ou côté nuit de la planetes....
Sacré Orbiter, il nous en fera voir de toute les couleurs ^^
Quand c'est configurer en base au sol il n'ya plus de soucis car il n'y a pas de landing point a definir, il n'y a qu'un mesh a placer au sol, Orbiter sachant tout de suite ou se trouve la base par rapport au soleil.
Message modifié ( 27-05-2007 07:50 )
-
Ah merci !
Réponse efficace. :beer: C'est le côté obscur d'Orbiter.
Tu m'étonnes qu'on passe de surprises en surprises quand on fait ce genre de trucs.
Les points sont ceux là, faits au pif ... TouchdownPoints = 0 0 1 -1 0 -1 1 0 -1
sans savoir ce qui est x y ou z.
La seule chose que je sache, c'est que les trois premiers chiffres sont pour l'avant, les trois
suivants pour la roue gauche et les trois derniers pour la droite. Après j'ai bricolé des 0
des 1 et des -1 jusqu'à ce que les bidules tiennent debout. :)
J'ai positionné les meshes dans le modeleur de façon à ce que les points bas soient sur le plan
zéro des Y. ( les semelles des droides par exemple sont sur ce plan dans le modeleur )
Je sais que les vessels ne se font pas comme ça normalement, mais sinon, je ne savais pas
les poser correctement au sol, ne connaissant rien à ces touchdownpoints.
Message modifié ( 27-05-2007 08:08 )
-
Disons qu'il doit certainement falloir toujours des touchdownpoint positif (pour la hauteur) pour eviter le bug du côté obscur.
Je n'ai pas assez d'experience dans ce domaine pour être affirmatif, mais cela semble être la solution.
"Quitte à baisser le mesh dans le fichier 3d, si les touchdownpoint positif le mette trop haut.
En tout cas superbe boulot, j'adore les pitdroids :beer:
Message modifié ( 27-05-2007 08:43 )
-
Thanks ;)
je vais continuer à bricoler ces points...
J'obtiens des trucs, disons, aléatoires... :badsmile:
Parfois c'est allongé et ça flotte au dessus du sol à 1 mètre.
D'autres fois, c'est warp drive dès le lancement d'Orbiter.
Quelle idée d'être allé contre ce qu'on nous a appris à l'école.
X Y Z c'était pas plus simple que _Y x z non ? Bizarre ce Martin :)
-
Point de départ coordonnées réelles XYZ de chaque point
sur le modeleur dans l'ordre avant gauche droite pour
les points.Point A x0 y0 z1 G x1 y0 z-1 D x-1 y0 z-1
Avec le mesh tourné à la façon Orbiter.
Dans le config j'essaye en fonction de ça ...
0 0 1 1 0 -1 -1 0 -1 Bras gauche planté dans le sol
0 0 1 0 1 -1 0-1 -1 allongé
1 0 0 -1 1 0 -1 -1 0 allongé sur le dos
-1 0 0 1 -1 0 1 1 0 le nez dans la poussiere
1 0 -1 0 0 1 -1 0 -1 ça vole
-1 0 -1 1 0 -1 0 0 1 debout mais ça clignote
0 0 1 -1 0 -1 1 0 -1 debout mais ça clignote aussi.
-0 0 -0 0 0 1 -0 0 -0 ca vole allongé
:doubt:
-
Le point d'origine du modeleur sera le centre de gravité du vessel. On peut donc sans problème mettre des valeurs négatives
pour les touchdown points (~ -5m pour le DGex).
X Y Z c'était pas plus simple que _Y x z non ?
Ça dépend des softs 3D :siffle:
-
Ok l'erreur que j'ai faite est d'avoir mis le point zéro
du modeleur sous les semelles des objets donc ...
Je vais essayer en centrant.
-
Coordonnées X Y Z prises sur le modeleur quand le point origine ( 0 0 0 )du modeleur
est barycentré sur le mesh et le mesh tourné à la manière Orbiter.
Les Y deviennent négatifs, logique.
Pointe de la chaussure
0,148 -0,937 0,392
Point le plus à gauche de la chaussure gauche
0,295 -0,937 0,118
Point le plus à droite de la chaussure droite
-0,294 -0,937 0,118
J'écris donc ça sur le config!
TouchdownPoints = 0,148 -0,937 0,392 0,295 -0,937 0,118 -0,294 -0,937 0,118
Et j'obtiens ça !
Et la même chose si je met tous les Y à zéro, il ne bouge pas d'un iota
TouchdownPoints = 0,148 0 0,392 0,295 0 0,118 -0,294 0 0,118
Aucune logique là dedans, c'est vraiment un système à la con !
Il avance dans le bon sens. Mais il décolle de l'altitude du point d'origine.
(http://img01.picoodle.com/img/img01/8/5/27/f_010Starwarsm_4f2230c.jpg)
Message modifié ( 27-05-2007 10:27 )
-
Essayes d'écrire:
LAND_PT1=(0.148,0.01,0.392)
LAND_PT2=(0.295,0.01,0.118)
LAND_PT3=(0.294,0.01,0.118)
en prenant le point 0 de ton mesh sous la chaussure.
Normalement ça doit marcher. Je viens de vérifier avec mon pack Tintin ou il y a le même défaut qui ne devait pas se
produire me semble t-il avec Orbiter 2005
Il faudrait en toute rigueur mettre 0 et non 0.01 pour la valeur de Y mais dans ce cas Orbiter provoque un
clignotement si le mesh n'est pas placé légèrement au dessus du sol. Il se peut que tu sois obligé de prendre un peu
plus de 0.01 mais ça ne se verra pas.
:sage: Papyref
-
:put: de :rant: de :bord: de :merd: d'informatique de mes coui ...à la c ...
Fallait des ...... points ..... à la place des ,,,,,,, virgules ,,,,,,, :worry:
C'est bon ça fonctionne et c'est logique ! Mais ce genre de subtilités d'écriture :doubt:
TouchdownPoints = 0 -0.937 1 -1 -0.937 -1 1 -0.937 -1
Mais Martin est quand même bizarre aussi.
Dans mon monde de tous les jours +X c'est devant moi.
-X derrière +y à ma droite, -Y à ma gauche
+Z au dessus de moi et -Z au dessous !
Quel besoin a t'il eu de changer ça ? :fool:
Il est anglais je crois, ça expliquerait bien des choses :badsmile:
Tous les modeleurs sont comme je le décris d'ailleurs non ?
On postait en même temps ... désolé Papy.
Tous ces jurons n'étaient qu'un défouloir.
Merci pour le coup de main quand même :beer:
Message modifié ( 27-05-2007 10:48 )
-
Martin est bizarre mais il faut aussi être bizarre pour utiliser des points à la place des virgules et vice versa :)
Ah les Anglais ! Et en plus ils conduisent à gauche...
:sage: Papyref
-
Dans mon monde de tous les jours +X c'est devant moi. -X derrière +y à ma droite, -Y à ma gauche +Z au dessus de moi et -Z au
dessous !
Ça dépend du système de repérage :)
Je préfère main gauche, je trouve ça plus naturel (on rajoute la profondeur, Z, aux abs et ordo).
Message modifié ( 27-05-2007 12:20 )
-
...Sans parler de la panse de brebis farcie :badsmile:
Me souvenait même plus qu'il existait un autre systeme que
Left hand avec z en profondeur...
Tu va y arriver pic... :applause:
Dan
-
Mais, j'ai l'impression que ça vous parait aussi naturel que le repère que l'on a
appris à l'école à tous les deux. Moi, pas , mais pas du tout. Sur le modeleur,
à chaque nouveau modèle, je suis obligé d'importer un mesh dont je suis sûr
en ce qui concerne l'orientation Orbiter pour pouvoir orienter le nouveau :)
Et une preuve que ce n'est pas naturel, c'est que c'est beaucoup plus difficile
de manipuler un objet avec l'outil de rotation une fois qu'il est axé Orbiter.
Je veux dire pour arriver facilement sur la vue à travailler souhaitée ....
Papy n'a pas l'air de troucer ça naturel non plus ... et toc. :)
-
Qui a dit que c'était chiant à trouver les touchdown points :siffle:
Celui m'a toujours fait marrer... le truc pratique, utile !
Avec les bras trop courts qui ne peuvent rien attraper à cause du socle
Du bon boulot de concepteur ! On dirait un DGIV ou un DGex :badsmile:
D'ailleurs, y'a qu'à voir ce que j'en fais moi des DGIV :badsmile:
(http://img01.picoodle.com/img/img01/8/5/27/f_011Starwarsm_51d1129.jpg)
Message modifié ( 27-05-2007 15:34 )
-
picto a écrit:
Mais, j'ai l'impression que ça vous parait aussi naturel que le repère que l'on a
appris à l'école à tous les deux. Moi, pas , mais pas du tout. Sur le modeleur,
à chaque nouveau modèle, je suis obligé d'importer un mesh dont je suis sûr
en ce qui concerne l'orientation Orbiter pour pouvoir orienter le nouveau :)
ben perso, j'utilise toujours le même axes pour mes modèles, je configure mon 3ds2msh en fonction et sa bouge plus...
pour la hauteur des msh au sol, je modifie les valeur sur shipedit, et voila, un msh (modulesol ou robot et autre) se pose au
sol sans rien retouché!
au debut je faisais comme toi, je reglé le niv au sol via mon modeleur (Meta) mais une foi au sol, la camera etais excentré
du msh... (cela dis, j'en ai profité pour crée une focus sur les points essentiels de mes modules)
donc; si tes msh sont bien orienté, ta plus besoin de config TouchdownPoints, tu fais la manip sur shipedit est fini la prise
de tête... (façon de parlé)
sinon sur ta config je vois sa:
Pit_droid.cfg
; === Configuration file for 01_Pit_Droid ===
ClassName = 01_Pit_Droid
MeshName = 01_Pit_Droid
Size = 15.0
Mass = 25; empty mass [kg]
MaxFuel = 1000 ; max fuel mass [kg]
Isp = 10000 ; fuel specific impulse [m/s]
MaxMainThrust = 10000
MaxRetroThrust = 10000
MaxHoverThrust = 10000
MaxAttitudeThrust = 1000
CameraOffset = 0 0 200
LiftFactor = 0.0
CrossSections = 0.020 0.025 0.022
EnableFocus = true
TouchdownPoints = 0 0 1 -1 0 -1 1 0 -1
donc suivant l'orientation du droïd, + fais avancé le droïd et - le fais reculé
et 0 fait monté le droïd via les hovers?
de plus, si le droïd avance, il ne s'arrête pas de suite! il glisse, sur sa course!
Je me trompe ou pas?
-
Oui, c'est ça ... c'est un peu ridicule d'ailleurs.
On peut faire autre chose via ces configs ?
-
(pour les bras trop court du droide ridicule... en fait c'est un droid pour faire du tricot, c'est pour ça! )
-
picto a écrit:
Oui, c'est ça ... c'est un peu ridicule d'ailleurs.
On peut faire autre chose via ces configs ?
tu peux le faire en spc3, sa reglerais les prb... mais :
- pour les animations, c'est pas le top... il peut y avoir des décalages (animations pas complete a 100%) si les fps sont
trop faible (je sais de quoi je parle)
- obligé de crée 1 ini pour chaque Doïds m^me si le msh est le même!
de plus, pour pas surchargé le dossiers Config/spacecraft/ tu peux crée toi même un dossier Config/Droïds avec le spacecraft3
dans 1 seul condition:
- ne pas avoir de playloads sous tes ini dans le dis dossier! et/ou qu'il ne soit du coup un playload d'un autre
spacecraft... sinon CTD garanti! (je sais aussi de quoi je parle)
sa donnerai donc sa pour ton ini Droïd:
[CONFIG]
MESHNAME="01_Pit_Droid"
SIZE=15
EMPTY_MASS=25 <= prb! FUEL=1000kg, donc une foi a 100Kg ton droïd va fusé! comme un ouf! conseillé par exp 1000
FUEL_MASS=1000 <= du coup conseillé par exp 100
MAIN_THRUST=10000 <= faible du coup, donc conseillé 20000 voir 30000
RETRO_THRUST=10000 <= sa fais pas mal de recule! divise par 1/3 donc pour 30000 en MAIN sa ferai 20000
ATTITUDE_THRUST=1000<= voir plus pour les rcs, 1200 ou plus au mininum
ISP=190000 <= fuel specific impulse [m/s]
PMI=(600,0.6,600) <= en X,Y,Z donc Y sont les rcs de monté ou descente (8-2) et 0.6 en stop les effets
CROSS_SECTION=(0.020, 0.025, 0.022)
PITCH_MOMENT_SCALE=0.000001
BANK_MOMENT_SCALE=0.000001
COG=1 <= je crois...cog c'est pour la hauteur au sol sur l'axe Z /EDITE
[LANDING_GEAR] <= pour le "freinage" un foi les Mains coupé
WHEEL=0.04
BELLY=0.4
BRAKE=400000 <= ou plus
et pour ton scénario:
Pit:ton_dossier_droïds/spacecraft3 <=Pit est le nom du ini dans le dossier :xxx
Je pense que c'est la base qui peu te donné quelles que éléments si tu envisages cette solution... elle peut même du coup
evité que ton droïd s'envol si tu piques du nez avec une vitesse trop elevé (un peut comme la voiture du CSG)
si ta besoin de plus d'info... je suis là...
Message modifié ( 27-05-2007 19:22 )
-
ouiiiin je veu encore des photos!! c'est trop beau :( :( :(
-
Sympa ta proposition, :beer: je vais tenter de réaliser une anim avec Spacecraft 3,
ça m'aidera à comprendre les principes. Ensuite, je transformerais les choses
en DLL, il serait plus intéressant de ne pas pouvoir prendre les commandes de
ces droides.
Au final, je souhaiterais qu'ils soient des animations automatiques de la base,
comme le train du KSC quoi.
Well le tricot :lol: Et il chope les pelotes comment ?
C't'un autre droide spécialisé dans le passage de pelotes qui le fait ?
Message modifié ( 27-05-2007 21:28 )
-
Yes !!!
Ca marche !
C'est rigolo à faire ... c'est du basique là, mais ça marche !
Par exemple là, il fait une translation mais resaute à sa position d'origine.
Je vais voir si on peut enchainer translations et rotations sur la même séquence.
En mélangeant les différents mouvements il y a de quoi s'amuser.
; ===01_Wed_Droide ===
[CONFIG]
MESHNAME="01_Wed_Droide"
SIZE =10
COG=-1.159
VISIBLE=1
CAMERA=(25,-10,-50)
FOCUS=0
;===Animations
[ANIM_SEQ_0]
KEY=0
DURATION=100
REPEAT=1
[ANIM_COMP_0]
SEQ=0
TYPE=TRANSLATE
GROUPS=0
RANGE=(0.,1.)
SHIFT=(10,0,100)
-
Bon, j'ai essayé plein de trucs, pas possible de faire du réellement automatique avec Spacecraft.
Je pensais qu'il était possible d'enchainer, une translation, une rotation, une autre translation dans une autre
direction, que la tête tourne sur son axe en même temps, mais sans avoir à prendre le contrôle.... etc... etc...
et ce sans aucune intervantion au clavier. Le REPEAT s'adresse au clavier en fait, je pensais au départ qu'il
s'adressait aux animations à proprement parler.
Reste le C++ ;)
-
mais si... c'est possible... même au lancement du scn!
exp:
ton droid ce deplace en faisant un carré:
[ANIM_SEQ_0]
INIT_POS=0
Key=XXX
DURATION=200
REPEAT=50 l'anime se relancé 50 fois automatiquement
[ANIM_COMP_0] va vers le bas
SEQ=0
GROUPS=XXX
RANGE=(0,0.2)
TYPE=TRANSLATE
SHIFT=(10,0,0)
[ANIM_COMP_1] tourne sur lui meme
SEQ=0
GROUPS=XXX
RANGE=(0.21,0.25)
ROT_PNT=(X,X,X)
ROT_AXIS=(X,X,X)
ANGLE=90
[ANIM_COMP_2] va vers la droite
SEQ=0
GROUPS=XXX
RANGE=(0.26,0.45)
TYPE=TRANSLATE
SHIFT=(0,0,10)
[ANIM_COMP_3] pivote
SEQ=0
GROUPS=XXX
RANGE=(0.46,0.5)
ROT_PNT=(X,X,X)
ROT_AXIS=(X,X,X)
ANGLE=90
[ANIM_COMP_4] va vers le haut
SEQ=0
GROUPS=XXX
RANGE=(0.51,0.7)
TYPE=TRANSLATE
SHIFT=(-10,0,0)
[ANIM_COMP_5] pivote
SEQ=0
GROUPS=XXX
RANGE=(0.71,0.75)
ROT_PNT=(X,X,X)
ROT_AXIS=(X,X,X)
ANGLE=90
[ANIM_COMP_6] va vers la gauche
SEQ=0
GROUPS=XXX
RANGE=(0.76,0.95)
TYPE=TRANSLATE
SHIFT=(0,0,-10)
[ANIM_COMP_7] pivote et se retrouve a la position du départ
SEQ=0
GROUPS=XXX
RANGE=(0.96,1)
ROT_PNT=(X,X,X)
ROT_AXIS=(X,X,X)
ANGLE=90
dans l'absolu, tu peux le faire...
-
Il ne tourne pas sur lui même avec ta séquence.
Les translations se font bien, mais aucune rotation.
Et quand je marque ça pour la première rotation, c'est comme si il prenait son point de référence hors de lui même 0 0
0 pour moi, c'est son centre de gravité et 0 1 0 l'axe vertical. Il fait bien une rotation, mais pas sur lui même, il décrit
un grand arc de cercle sur le sol.
[ANIM_COMP_0] va vers le bas
SEQ=0
GROUPS=0
RANGE=(0,0.2)
TYPE=TRANSLATE
SHIFT=(10,0,0)
[ANIM_COMP_1] tourne sur lui meme
SEQ=0
GROUPS=0
RANGE=(0.21,0.25)
ROT_PNT=(0,0,0)
ROT_AXIS=(0,1,0)
ANGLE=90
Je vais étudier le PDF :badsmile:
Je me rend compte qu'il y a pas mal de trucs à étudier, je croyais que de regarder les .ini des autres suffirait ;)
Par exemple, pour ce qui concerne les Range, je ne sais même pas ce que c'est ;) Ok, c'est simple, c'est un marqueur de temps en proportion de 100 dont les valeurs s'écrivent sur une base de 1, de 0 à 1 quoi ....
Message modifié ( 28-05-2007 12:06 )
-
ha oui pour la rotation sur lui même, faut rentré la valeur suivant sa position... j'ai pas testé, je tes fais sa de tête...
donc si la translation est de 10m la rotation doit etre de +10 sur ton axe de ref...
faut tâtonné, faire des tests, tes en bon chemin!
-
C'est presque au point, le seul truc qui m'étonne, c'est qu'il commence par une rotation sur cette séquence ou
pourtant le premier truc indiqué est une translation, les translations ne se font donc pas selon l'axe du mesh que je
souhaite ( perpendiculaire aux roues :badsmile: ) sans doute une histoire ou il faut indiquer une initialisation de
position ou autre à Spacecraft. Mais j'ai compris le principe. Si je veux le faire déambuler dans la ville et que ça ai l'air
aléatoire, il faudra faire un dessin vu de dessus pour ne pas s'y perdre, si l'anim fait cinquante
composantes :badsmile:
Le REPEAT c'est 0 1 ou 2
0 elle ne se répète pas
1 elle se répète indéfiniment.
2 elle se répète en s'inversant.
Message modifié ( 28-05-2007 14:16 )
-
YES !!!
Ca fonctionne parfaitement !!!
Ca donne envie de faire de la prog toutes ces bêtises :)
Le plus drôle est de définir le type de comportement de chacun.
Un petit GIF en illustratiion, mais c'est plus souple sur Orbiter en réalité.
(http://img03.picoodle.com/img/img03/8/5/28/f_016Starwarsm_7d627be.gif)
MERCI MOMO pour le coup de main, il suffit d'être organisé, faire chaque composante de l'animation une par une
pour ne pas se perdre dans les valeurs indiquées et faire très attention au Range, et là tout va bien ... avec ça, il fait
un carré en accélérant de temps en temps, en marquant des pauses et en tournant correctement sur lui même.
Comme les meshes droides sont très optimisés, je vais tout regrouper en un seul mesh et considérer que ce sont des
groupes à animer indépendement. Ce sera plus facile à gérer pour l'utilisateur ( en fait, il n'aura rien à faire :) )
C'est juste pour donner un peu de vie à la base.
C'est très marrant à faire en tout cas !
En prenant des références très éloignées de lui, il décrit de grands arcs de cercles autour de bâtiments sans que le
désaxage se remarque... bref, il commence à se ballader en ville :)
Je vais te demander un coup de main sur les animations enfant par PARENT.
Par exemple pour faire bouger les bras du droide pendant qu'il avance et faire bouger sa tête verticalement sur son
axe télescopique.
Une fois que je saurais faire ça, je pourrais tout faire
Voici le .ini inspiré du tien et qui fonctionne.
Ce qui est génial, c'est qu'il n'y a aucune llimite au nombre de composantes d'une séquence
( lu sur le PDF de Vinka )
Pour lancer automatiquement il suffit d'ajouter ça sur le scn pour le vessel concerné SEQ 0 1 0.0
;===Animations
[ANIM_SEQ_0]
INIT_POS=0
Key=0
DURATION=5
REPEAT=1 l'anime se relance en s'inversant indefiniment
[ANIM_COMP_0] va devant lui
SEQ=0
GROUPS=0
RANGE=(0,0.2)
TYPE=TRANSLATE
SHIFT=(0,0,10)
[ANIM_COMP_1] tourne sur lui meme
SEQ=0
GROUPS=0
RANGE=(0.2,0.3)
ROT_PNT=(0,0,10)
ROT_AXIS=(0,1,0)
ANGLE=90
[ANIM_COMP_2] va devant lui
SEQ=0
GROUPS=0
RANGE=(0.4,0.5)
TYPE=TRANSLATE
SHIFT=(10,0,0)
[ANIM_COMP_3] tourne sur lui meme
SEQ=0
GROUPS=0
RANGE=(0.5,0.6)
ROT_PNT=(10,0,10)
ROT_AXIS=(0,1,0)
ANGLE=90
[ANIM_COMP_4] va devant lui
SEQ=0
GROUPS=0
RANGE=(0.6,0.7)
TYPE=TRANSLATE
SHIFT=(0,0,-10)
[ANIM_COMP_5] tourne sur lui meme
SEQ=0
GROUPS=0
RANGE=(0.7,0.79)
ROT_PNT=(10,0,0)
ROT_AXIS=(0,1,0)
ANGLE=90
[ANIM_COMP_6] va devant lui
SEQ=0
GROUPS=0
RANGE=(0.8,0.95)
TYPE=TRANSLATE
SHIFT=(-10,0,0)
[ANIM_COMP_7] tourne sur lui meme
SEQ=0
GROUPS=0
RANGE=(0.95,1)
ROT_PNT=(0,0,0)
ROT_AXIS=(0,1,0)
ANGLE=90
Message modifié ( 28-05-2007 19:24 )
-
alors pour faire bougé les bras du droid:
[ANIM_SEQ_1]
INIT_POS=0
Key=0
DURATION=X
REPEAT=1
[ANIM_COMP_8]
SEQ=1
GROUPS=Bras droit
RANGE=(0,0.3)
ROT_PNT=(x,x,x) l'épaule
ROT_AXIS=(1,0,0) de tête, le bras va vers l'avant
ANGLE=35
[ANIM_COMP_9]
SEQ=1
GROUPS=l'avant Bras droit
RANGE=(0.3,0.45)
ROT_PNT=(x,x,x) le coude
ROT_AXIS=(1,0,0) de tête, le bras va vers l'avant
ANGLE=10
PARENT=8 l'avant bras suivra le bras (normal)
[ANIM_COMP_10]
SEQ=1
GROUPS=l'avant Bras droit
RANGE=(0.45,0.6)
ROT_PNT=(x,x,x) le coude
ROT_AXIS=(1,0,0)
ANGLE=-10
PARENT=8 l'avant bras suivra le bras (normal)
[ANIM_COMP_11] le bras remonte derrière le dos
SEQ=1
GROUPS=l'avant Bras droit + le bras
RANGE=(0.6,0.8)
ROT_PNT=(x,x,x) l'epaule
ROT_AXIS=(1,0,0)
ANGLE=-15
[ANIM_COMP_12] le bras revient a la position initial
SEQ=1
GROUPS=l'avant Bras droit + le bras
RANGE=(0.8,1)
ROT_PNT=(x,x,x) l'epaule
ROT_AXIS=(1,0,0)
ANGLE=15
ensuite de 13 a 17 pour le bras gauche et 13 ne va pas vers l'avant du corp, mais vers l'arriere
sa devrais marché...
-
Momo, le roi de l'anim !! ;)
-
Ok, je comprend mieux ces histoires de PARENT. Merci Momo, je teste ça ce soir.
De la même manière, si je fais bouger les bras tout en faisant avancer le droide, il faut que je
déclare comme PARENT le socle du droide à partir du bras j'imagine, sinon, le socle va avancer
et les bras rester sur place.
-
:)
pour comprendre le role du PARENT faut voir sa:
[ANIM_COMP_8]
SEQ=1
GROUPS=Bras droit
RANGE=(0,0.3)
ROT_PNT=(x,x,x) l'épaule
ROT_AXIS=(1,0,0) de tête, le bras va vers l'avant
ANGLE=35
[ANIM_COMP_9]
SEQ=1
GROUPS=l'avant Bras droit
RANGE=(0.3,0.45)
ROT_PNT=(x,x,x) le coude
ROT_AXIS=(1,0,0) de tête, le bras va vers l'avant
ANGLE=10
PARENT=8 l'avant bras suivra le bras (normal)
sur l'anim comp 9 je declare un parent 8, donc en faite l'anim 9 suit la 8 sur sont point de rot.
je pourrais faire comme sa aussi:
[ANIM_COMP_8]
SEQ=1
GROUPS=Bras droit
RANGE=(0,0.3)
ROT_PNT=(x,x,x) l'épaule
ROT_AXIS=(1,0,0) de tête, le bras va vers l'avant
ANGLE=35
[ANIM_COMP_9]
SEQ=1
GROUPS=l'avant Bras droit
RANGE=(0,0.3)
ROT_PNT=(x,x,x) l'épaule
ROT_AXIS=(1,0,0) de tête, le bras va vers l'avant
ANGLE=35
[ANIM_COMP_10]
SEQ=1
GROUPS=l'avant Bras droit
RANGE=(0.3,0.45)
ROT_PNT=(x,x,x) le coude
ROT_AXIS=(1,0,0) de tête, le bras va vers l'avant
ANGLE=10
sa marche aussi sans PARENT!
Message modifié ( 28-05-2007 19:50 )
-
brainstorm a écrit:
Momo, le roi de l'anim !! ;)
tu m'as refilé le virus! le roi c'est toi pas moi...
-
Je bloque là dessus :sad:
L'idée de la carotte, c'est un groupe d'un poly placé dans le corps du droide , Pour être libre sur les oscillations du
corps principal à chaque pas.. J'ai essayé de faire translation et oscillations sur le corps directement, soit je m'y suis
mal pris soit c'est impossible, mais je n'obtenais rien de satisfaisant... la carotte donc.
Sur le Gif, les mouvements sont à peu près ceux que je cherchais à obtenir
Je me disais aussi que ce serait pratique de ne pas avoir à recommencer la série de mouvement des pattes à chaque
changement de direction du droide. On suit la carotte, et les jambes et le corps continuent à faire les mouvements de
marche.
Deux problèmes, à chaque boucle, Spacecraft réinitialise la position des jambes, d'ou cet effet de léger recul et glissé.
Et plus chiant, dès que je rajoute une comp à la séquence zéro les mouvements s'arrêtent.( les jambes continuent de
marcher mais le droide ne bouge plus. La raison m'échappe totalement.
La carotte ne fonctionne bien que sur la première séquence.
Si je rajoute un COMP 8 rotation du groupe 5 ( la carotte ) puis une nouvelle translation, il ne se passe rien. :sad:
Si tu as une idée là dessus, merci d'avance.
[ANIM_SEQ_0]
INIT_POS=0
Key=0
DURATION=270
REPEAT=1
[ANIM_SEQ_1]
INIT_POS=0
Key=0
DURATION=0.45
REPEAT=1
[ANIM_COMP_0] la carotte avance
SEQ=0
GROUPS=5
RANGE=(0,1)
TYPE=TRANSLATE
SHIFT=(0,0,180)
[ANIM_COMP_1] le corps avance en suivant la carotte
SEQ=1
GROUPS=0
RANGE=(0,0.45)
TYPE=TRANSLATE
SHIFT=(0,0,0.025)
PARENT=0
[ANIM_COMP_2] avance la jambe droite en suivant le corps
SEQ=1
GROUPS=1,3
RANGE=(0.1,0.5)
TYPE=TRANSLATE
SHIFT=(0,0.10,0.3)
PARENT=1
[ANIM_COMP_3] le corps penche a droite
SEQ=1
GROUPS=0
RANGE=(0,0.5)
ROT_PNT=(0,0.288,0) centre du corps
ROT_AXIS=(0,0,1)
ANGLE=-6
[ANIM_COMP_4] avance jambe gauche en suivant le corps
SEQ=1
GROUPS=2,4
RANGE=(0.6,1)
TYPE=TRANSLATE
SHIFT=(0,0.10,0.3)
PARENT=1
[ANIM_COMP_5] le corps penche a gauche
SEQ=1
GROUPS=0
RANGE=(0.5,1)
ROT_PNT=(0,0.288,0) centre du corps
ROT_AXIS=(0,0,1)
ANGLE=12
[ANIM_COMP_6] repose jambe droite en suivant le corps
SEQ=1
GROUPS=1,3
RANGE=(0.5,0.75)
TYPE=TRANSLATE
SHIFT=(0,-0.10,0)
[ANIM_COMP_7] repose jambe gauche en suivant le corps
SEQ=1
GROUPS=2,4
RANGE=(0.75,1)
TYPE=TRANSLATE
SHIFT=(0,-0.10,0)
(http://img03.picoodle.com/img/img03/8/5/28/f_002Starwarsm_06ff5d1.gif)
Message modifié ( 29-05-2007 04:23 )
-
Je pense qu'à comp 7 tu es au bout de ton Range et le temps de séquence est écoulé, alors tu reboucles au début
sans passer par Comp 8.
Essayes en modifiant le range pour comprendre comp 8 et la suite
:sage: Papyref
-
je vois des turcs qui vont pas trop...
[ANIM_COMP_6] repose jambe droite en suivant le corps
SEQ=1
GROUPS=1,3
RANGE=(0.5,0.75)
TYPE=TRANSLATE
SHIFT=(0,-0.10,-0.3)
[ANIM_COMP_7] repose jambe gauche en suivant le corps
SEQ=1
GROUPS=2,4
RANGE=(0.75,1)
TYPE=TRANSLATE
SHIFT=(0,-0.10,-0.3)
deja les jambe reviennent a leurs positions 0 avant la boucle (plus de recule visuel)
le pire:
[ANIM_COMP_5] le corps penche a gauche
SEQ=1
GROUPS=0
RANGE=(0.5,1)
ROT_PNT=(0,0.288,0) centre du corps
ROT_AXIS=(0,0,1)
ANGLE=12
ton droïd est penché a gauche (6°) et revient brutalement a 0° donc
et:
[ANIM_COMP_1] le corps avance en suivant la carotte
SEQ=1
GROUPS=0
RANGE=(0,0.45)
TYPE=TRANSLATE
SHIFT=(0,0,0.025)
PARENT=0
et la le corp refais un recul a l'initialisation donc (0.025)
si tu fais des bouches sans fin, faut toujours prevoir d'annulé toutes les animes pour quelles soit a 0 avant la boucle,
sinon sa saute!
[ANIM_SEQ_0]
INIT_POS=0
Key=0
DURATION=270
REPEAT=1
[ANIM_SEQ_1]
INIT_POS=0
Key=0
DURATION=0.5
REPEAT=1
[ANIM_COMP_0] la carotte avance
SEQ=0
GROUPS=5
RANGE=(0,1)
TYPE=TRANSLATE
SHIFT=(0,0,180)
[ANIM_COMP_1] le corps avance en suivant la carotte
SEQ=1
GROUPS=0
RANGE=(0,0.4)
TYPE=TRANSLATE
SHIFT=(0,0,0.025)
PARENT=0
[ANIM_COMP_2] avance la jambe droite en suivant le corps
SEQ=1
GROUPS=1,3
RANGE=(0.1,0.5)
TYPE=TRANSLATE
SHIFT=(0,0.10,0.3)
PARENT=1
[ANIM_COMP_3] le corps penche a droite
SEQ=1
GROUPS=0
RANGE=(0,0.25)
ROT_PNT=(0,0.288,0) centre du corps
ROT_AXIS=(0,0,1)
ANGLE=-6
[ANIM_COMP_4] avance jambe gauche en suivant le corps
SEQ=1
GROUPS=2,4
RANGE=(0.6,1)
TYPE=TRANSLATE
SHIFT=(0,0.10,0.3)
PARENT=1
[ANIM_COMP_5] le corps penche a gauche
SEQ=1
GROUPS=0
RANGE=(0.25,0.75)
ROT_PNT=(0,0.288,0) centre du corps
ROT_AXIS=(0,0,1)
ANGLE=12
[ANIM_COMP_6] repose jambe droite en suivant le corps
SEQ=1
GROUPS=1,3
RANGE=(0.5,0.75)
TYPE=TRANSLATE
SHIFT=(0,-0.10,-0.3)
[ANIM_COMP_7] le corps penche a droite et revient au centre
SEQ=1
GROUPS=0
RANGE=(0.75,1)
ROT_PNT=(0,0.288,0) centre du corps
ROT_AXIS=(0,0,1)
ANGLE=-6
[ANIM_COMP_8] le corps revient a la position initial doucement
SEQ=1
GROUPS=0
RANGE=(0.4,1)
TYPE=TRANSLATE
SHIFT=(0,0,-0.025)
[ANIM_COMP_9] repose jambe gauche en suivant le corps
SEQ=1
GROUPS=2,4
RANGE=(0.75,1)
TYPE=TRANSLATE
SHIFT=(0,-0.10,-0.3)
sa devrais marché!
si ya un prb d'anime pas lancer, modifies les lignes RANGE=(0.4,1) en 0.99 sauf sur la dernière.
si les pattes ne suivent pas tous le corp, rajoute les parent=0 sur toutes les lignes
-
C'est plus fluide. Merci Momo :beer:
Je commence à voir les écueils à éviter.
Je vais essayer de trouver un mouvement plus
convaincant pour les jambes sur ce principe.
Papy, tu as raison, tout est une question de proportions,
j'ai mis ces ranges là pour l'anim des jambes et l'oscillation
du corps pour qu'ils correspondent à la première translation.
Mais croyez vous que ce soit possible ?
Si je fais tourner la carotte tout va tourner
ou faut il réécrire la séquence des jambes et
oscillations du corps sur la nouvelle translation.
Le but étant de pouvoir le faire déambuler en ville comme
les autres droides.
-
Si tu fais tourner la carotte une nouvelle fois, la nouvelle rotation est un comp x qui n'est plus le parent de référence
du départ et tes bras et jambes ne suivront pas je crois.
Il faudrait récrire les séquences bras et jambes attachées à ce nouveau parent.
:sage: Papyref
-
C'est bien ce qui me semble aussi, je pensais à ça dans un soucis d'optimisation.
Je ne sais pas si ça joue sur le FPS, d'écrire des ini avec 200 Comp.
Je vais faire des tests.
-
Et ben, décidemment, c'est problèmes sur problèmes.
Vu que les scenarios limitent à 10 Spacecraft maximum,
j'essaye de regrouper des animations sur un seul vessel.
J'ai envie de mettre trois éoliennes sur la scène.
Je fais la première comme d'habitude, et je la pose au sol.
Tout va bien elle tourne correctement avec ce ini
[ANIM_SEQ_0]
INIT_POS=0
Key=0
DURATION=4
REPEAT=1
[ANIM_COMP_0]
SEQ=0
GROUPS=0
RANGE=(0,1)
ROT_PNT=(0,9.903,2.366)
ROT_AXIS=(0,0,1)
ANGLE=360
Je retourne sur le modeleur pour ajouter une seconde éolienne.
(http://img01.picoodle.com/img/img01/8/5/29/f_050Starwarsm_df43779.jpg)
Je note bien l'axe de rotation et les nouveaux groupes créés.
Et je modifie le ini en ajoutant çà, -52.007 correspond à la translation
de la nouvelle éolienne qui fait partie du même vessel.
[ANIM_COMP_1]
SEQ=0
GROUPS=3
RANGE=(0,1)
ROT_PNT=(-52.007,9.903,2.366)
ROT_AXIS=(0,0,1)
ANGLE=360
Et là j'obtiens ça ... :doubt:
L'hélice décris un grand cercle autour du premier point.
Et j'ai beau tourner le problème dans tous les sens, je ne vois
pas ou est l'erreur de logique dans ce que j'ai fait... à moins
que ce ne soit très évident mais que la fatigue m'empêche de la voir.
(http://img01.picoodle.com/img/img01/8/5/29/f_051Starwarsm_05d4966.jpg)
Message modifié ( 29-05-2007 17:01 )
-
Je crois deviner que c'est le pivot à zéro du groupe qui est pris en considération par Spacecraft
mais c'est à peu près tout.
-
Et ben, dédidemment, c'est problèmes sur problèmes.
Vu que les scenarios limitent à 10 Spacecraft maximum,
j'essaye de regrouper des animations sur un seul vessel.
non! c'est pas sa!!!!!!!
J'ai posé la question a Vinka, sur la limitation des 10 Spacecraft sur un scn, car moi j'en utilises pas mal (moins
maintenant via les DLL)
mais il m'as dis, la limitation n'est pas sur le nombre, tu peux en avoir autant que tu en souhaites sur un scn!
ya juste une limitation a 10 spacecraft pour les modèles aérodynamique!
donc te préoccupe pas de sa je te le garantis! fais tes animes, sa marchera!
-
Ok, mais dans l'absolu, on peut faire ce que je j'essaye sur les éoliennes ?
Vois tu ou se trouve l'erreur ?
Imagine que je veuille faire un quadrimoteur à hélices, ce doit bien être possible non ?
-
:p:
J'ai trouvé !!! :wall: Left hand !!! :wall:
[ANIM_COMP_1]
SEQ=0
GROUPS=3
RANGE=(0,1)
ROT_PNT=(52.007,9.903,2.366)
ROT_AXIS=(0,0,1)
ANGLE=360
Fallait enlever le moins !!!
Saletés d'Anglais !!! :wall:
En tout cas, je suis content, ce sera plus propre quand même sur les scenarios
d'avoir un seul Vessel pour toutes les anims de la ville, et si ça se trouve, meilleur
en ce qui concerne l'optimisation.
Message modifié ( 29-05-2007 17:09 )
-
oui c'est possible, je peux pas te dire ou est le prb... faut rentré les bon point de rot au 0.0001
utilise MeshWizard.exe pour sa... sa te donneras les points exacts
sinon l'axe Z dans ton cas (la profondeur sur le MSH) n'est pas utile... 0 sa marche mieux
ROT_PNT=(-52.007,9.903,2.366)
si c'est bien le bonne axe... je sais pas comment tu les orientes...
-
C'est bon Momo, j'avais trouvé le problème, regarde juste au dessus de ton post.
C'est juste la référence de coordonnées d'Orbiter qui est inversée par rapport au modeleur.
Et j'avais oublié d'inverser les X, c'est pas naturel du tout pour moi ce système de Martin.
Ca fonctionne très bien, petit à petit, je vais regrouper toutes les anims sur un seul Spacecraft. Ce sera mieux pour la
lisibilité des scenarios. Et plus facile à modifier pour les petites configs. Si le FPS s'écroule à cause des anims, zou,
juste un Vessel à virer de la liste sur les scenars et c'est inzepocket.
Message modifié ( 29-05-2007 17:40 )
-
ha vi... ta posté juste avant moi... je prend mon temps pour posté... suis trop lent...
-
Les animations fonctionnent bien là dessus. merci Momo ;)
C'est du très low poly et très low texture, gros boulot.
La barge fait 2900 polys, le sand crawler 500, l'esquif 1500 et le jawa 1400.
Les textures et couleurs sont encore à ajuster.
(http://img02.picoodle.com/img/img02/8/5/30/t_003Starwarsm_cf4374d.jpg)
Petite question que je me pose en ce qui concernes les sons.
Vu qu'il est possible de détecter les vessels proches d'un vessel en déplacement,
pourrais t'on imaginer tester au fur et à mesure des déplacements de faire jouer
des sons différents en fonction du type de vessel le plus proche ?
Ceci pour créer une ambiance même en vue extérieure...
(http://img02.picoodle.com/img/img02/8/5/30/f_001Starwarsm_c037607.jpg)
(http://img02.picoodle.com/img/img02/8/5/30/f_002Starwarsm_42d37c2.jpg)
Message modifié ( 30-05-2007 23:03 )
-
Les animations fonctionnent bien là dessus. merci Momo ;)
Merci :)
on s'entraide en Francophone :)
Petite question que je me pose en ce qui concernes les sons.
Vu qu'il est possible de détecter les vessels proches d'un vessel en déplacement,
pourrais t'on imaginer tester au fur et à mesure des déplacements de faire jouer
des sons différents en fonction du type de vessel le plus proche ?
là... je dirais "je sais po" sur les animes, la base du dit "vessel" reste sur place... comme les autres...
est le son... sa reste un mystère pour moi...
dsl...
-
Va falloir sortir la doc d'OrbiterSound.
Dommage que Korben soit débordé par les DLLs des vaisseaux.
Il sait se servir des sons sur Orbiter. Bah, chaque chose en son temps.
Ca pourra t'intéresser aussi ... plus tard.
Je pensais dispatcher des vessels qui ne bougent pas sur la base mais
avec de petites anims locales pour que la base ai l'air plus vivante.
Un vessel échoppe, un autre, bar, etc ... et faire jouer des sons quand
on passe à côté soit avec un UMmu soit avec un vessel.
-
:)
-
Ben ouais, méme pas dans la programmation, dans la trigo encore une fois.
Encore sur mon probléme de tourelles.
Comment l'orienter, l'oapigetrelativeposition me donne bien les coordonnées d'un vaisseaux / a un autre.
mais cela ne suffit pas.
Les tourelles sont azimutales (2 axes) et non equatoriales (3axes) et sont montées sur un vaisseau dont
l'orientation varie.
Cela complique les calculs il faut corriger avec le pitch, le bank et le yaw du vaisseau porteur
La je remonte les calcul en partant des latitudes et longitudes du porteur et de la cible, obtenues dans le repére
equatorial de la planéte la plus proche.
C'est pas facile !!!!!! méme pour un astronome amateur
-
C'est du niveau seconde :badsmile:
Bon, soit c'est un peu lointain, mais quand même ....
Ca devrait pas te prendre plus de 15 minutes .... :siffle:
nnnaann .... j'rigoleuhhh .... Bon courage.
-
Sous les sunlights des tropiques ...
(http://img03.picoodle.com/img/img03/8/5/31/f_006Starwarsm_260660f.jpg)
(http://img02.picoodle.com/img/img02/8/5/31/f_005Starwarsm_2de6913.jpg)
Message modifié ( 31-05-2007 13:55 )
-
ça fait quelque chose de magique ! :applause:
Bravo les gars continuez ;)
-
Merci Jim ;)
J'ai un petit problème.
J'essaye de poser un vaisseau invisible et sans puissance sur le second soleil, une planète en fait.
Je lance le scenario, c'est pour essayer de faire un second soleil avec une texture alpha.
Sur le scenario, j'écris ça...
Soleil:spacecraft\spacecraft3
STATUS Landed Second_sun
POS -6.9942370 32.0005810
HEADING 328.31
NAVFREQ 0 0
RCS 1
CTRL_SURFACE 1
CONFIGURATION 1
CURRENT_PAYLOAD 0
END
Il ne se passe rien alors que mon config est bon.
Impossible de déclencher les moteurs.
Et je regarde le Current State et je vois ça :lol:
Soleil:spacecraft\spacecraft3
STATUS Landed Sun1
POS -6.9942370 32.0005810
HEADING 328.31
NAVFREQ 0 0
RCS 1
CTRL_SURFACE 1
CONFIGURATION 1
CURRENT_PAYLOAD 0
Sans que j'ai rien touché !
:hot:Je dois bien être le premier ici à me poser sur le Soleil avec un Spacecraft3 :hot:
Message modifié ( 31-05-2007 18:45 )
-
Bon alors, cette fois c'est sur on va pouvoir remplacer Bach par Williams !!!
:bave:
-
Ce coup ci oui ;)
Momo, tu es sûr de ton coup pour Spacecraft3 et le coup du dossier appellé dans le scenar ?
Orbiterlog après CTD :sick:
Finished initialising world
>>> ERROR: No vessel class configuration file found for:
>>> ERROR: Star_Wars_KP/Spacecraft3
>>> [C:\Source\Orbiter\Vessel.cpp / 248]
>>> TERMINATING <<<
Les .ini sont placés dans D:\2_ORBITER_TEST\Config\Star_Wars_KP
et j'ai pourtant écrit ça sur le scenario comme tu le conseillais pour les vessels
Jawa_Droids:Star_Wars_KP\spacecraft3
Et c'est pareil si j'écris comme ça
R2D2:Star_Wars_KP/spacecraft3
entre autres... ;)
Message modifié ( 01-06-2007 06:00 )
-
Pour préciser le problème, dès que je fais un simple copier
coller des ini dans le dossier Spacecraft je n'ai pas de CTD ...
Et ce sont de simples .ini sans payload, sans rien, avec juste des anims.
Ils fonctionnent d'ailleurs très bien dès qu'ils sont placés dans le dossier spacecraft.
Je t'en montre un ... On ne peut pas faire plus simple :)
; === Jawa_Droids ===
[CONFIG]
MESHNAME="Star_Wars_KP\Droides\Jawa_Droids"
SIZE =10
COG=-0.457
VISIBLE=1
; === Animations ===
[ANIM_SEQ_0]
INIT_POS=0
Key=0
ETC ...
ETC ...
Message modifié ( 01-06-2007 06:34 )
-
picto a écrit:
Ce coup ci oui ;)
Momo, tu es sûr de ton coup pour Spacecraft3 et le coup du dossier appellé dans le scenar ?
Orbiterlog après CTD :sick:
Finished initialising world
>>> ERROR: No vessel class configuration file found for:
>>> ERROR: Star_Wars_KP/Spacecraft3
>>> [C:\Source\Orbiter\Vessel.cpp / 248]
>>> TERMINATING
Si tu as ça, il est probable que le nom du spacecraft que tu mets dans ton scénario n'est pas le même que celui du
fichier ini que tu as placé dans le dossier de Spacecraft.
Il faut qu'en suivant le chemin que tu donnes dans le scénario, Orbiter trouve un ini qui ait le même nom que ton
spacecraft. C'est impératif, sinon CTD puisqu'il ne trouve pas l'ini du spacecraft désigné.
Il faut aussi que si tu spécifies Spacecraft 3 tu ais bien le dll et le cfg de Spacecraft 3 là ou il doit être, sinon CTD
puisqu'il ne trouve pas le module dll à appliquer pour le traitement.
CTD imparable également quand une animation fait appel à un numéro de groupe n'existant pas, ce qui arrive quand
on fait une modif sur le 3D et qu'on réapplique le convertisseur car on peut avoir alors moins de groupes
:sage: Papyref
-
Oui, je sais bien tout ça, mais tu as éludé cette partie du deuxième post.
Pour préciser le problème, dès que je fais un simple copier
coller des ini dans le dossier Spacecraft je n'ai pas de CTD ...
Ils fonctionnent d'ailleurs très bien dès qu'ils sont placés dans le dossier spacecraft.
C'est quand même étonnant !
J'ai vérifié ça aussi, j'ai bien les configs spacecraft 0 à 3 et les modules.
Pour les exports j'utilise le mesh header de Dan, impossible de se tromper avec ça.
Au moment de l'export en msh un fichier Mesheader.h est systématiquement créé.
Dès que je fais une modif, je copie ce fichier en annexe du ini
C'est très pratique et vraiment .... impossible de se tromper.
Ca donne des choses comme ça ...
#define GRP_Shuttle 0
#define GRP_Right_wing 1
#define GRP_Exhausts 2
#define GRP_Black 3
#define GRP_Left_Wing 4
Où les chiffres en bout de ligne sont les numéros de groupes créés par l'exporteur.
Je ne m'en servais pas auparavant, mais maintenant que j'essaye les anims, c'est très pratique.
Et ça donne des trucs comme ça ... les ailes se replient au moment de l' atatooinissage :)
Tyridium et Landing Shuttle, les Sandtroopers ne devraient plus tarder à débarquer ;)
(http://img01.picoodle.com/img/img01/8/6/1/f_007Starwarsm_b14b1fc.jpg)
(http://img01.picoodle.com/img/img01/8/6/1/f_010Starwarsm_ca6d1fa.jpg)
Puisque j'en suis aux petits problèmes à régler.
C'est également la première fois que je rencontre ce type de problème.
L'aile gauche est une copie en miroir mais pas en instance de l'aile droite.
Comme je n'avais jamais réalisé d'animations auparavant j'avais pris l'habitude de regrouper
tous les groupes en un seul par Material. Ce qui donnait souvent, un groupe, une texture.
L'idéal de l'optimisateur. :siffle:
Mais, animations veut dire conserver des groupes distincts... et là, surprise, dès que je détache l'aile gauche, les
normales s'inversent, si je la rattache, elles reviennent à la normale ! Etonnant non ? Je vais trouver une parade
mais c'est agaçant !
Certains ici ont ils déjà rencontré ce genre de surprises ? Illustration ici en dessous .... et également sur la première
photo,
(http://img01.picoodle.com/img/img01/8/6/1/f_009Starwarsm_6985b74.jpg)
Message modifié ( 01-06-2007 11:33 )
-
Pour le coup des normales inversées à cause d'un miroir c'est simple en fait ...
Il suffisait d'y penser.... :) Marrant ces trucs ...
1 miroir
2 attach
3 on sélectionne les polys d'origine d'avant le miroir et c'est ceux là qu'on détache comme nouveau groupe et pas
Lycée de Versailles
4 On regarde le Meshheader de Dan :)
Et on s'aperçoit que les groupes ont été inversés .... mais que les normales sont revenues à la normale...
#define GRP_Shuttle 0
#define GRP_Left_wing 1
#define GRP_Exhausts 2
#define GRP_Black 3
#define GRP_Right_Wing 4
5 On oublie pas de modifier le .ini sinon les anims font une drôle de tronche .... :badsmile:
6 On poste ici au cas ou ça pourrait servir à quelqu'un d'autre ...
7 On arrête de dire des conneries :)
Message modifié ( 01-06-2007 12:12 )
-
8 Ca fait tres scolaire tout ca...
-
pour les normale inversée, d'abord jamais d'instance of course ca marche pas.
Une fois la copie faite:
1-selectionner l'objet copié
2-tout a droite dans "utile" faire "reset x-form" (on voit les normale qui sont inversée en fait)
3- edit mesh->face selectionner *toutes* les faces
4-tout en bas faire "flip" (normal)
C'est bon
Dan
-
Merci Msieur, c'est plus pratique effectivement. ;)
Je ne m'en sors pas sur les configs, c'est une cata.
Ca se pose bien par scenarios mais c'est une autre paire de manche dès que c'est par des actions sur Orbiter.
Au moment du posé, les touchdownpoints ne sont pas détectés, le mesh traverse le sol et c'est seulement une fois
totalement à l'arrêt que le mesh se repositionne correctement et encore, pas à chaque fois.
Idem au démarrage, dès que je touche un moteur, ça donne ça. :sad: ( voir le Gif )
Ca passe sous la surface du sol :sick:
J'ai pourtant fait attention que les points soient sous le mesh ailes dépliées avec même de la marge.
( comme sur le modeleur ) Mais rien à faire. Ca ne fonctionne qu'en mettant des moteurs surpuissants mais ce n'est
pas chouette, impossible de faire des posés et décollages en douceur et relativement lents pour que ça ait un peu de
gueule.
Voici le .ini
Peut être que l'explication va sauter aux yeux de certains ici, mais là, je sèche :sad:
[CONFIG]
MESHNAME="01_navette_Irridium"
COG=-20
TouchdownPoints = 0 -20 1 -1 -20 -1 1 -20 -1
SIZE=30
CAMERA=(30,30,30)
VISIBLE=1
FOCUS=0
EMPTY_MASS=2000
FUEL_MASS=500
MAIN_THRUST=250000
RETRO_THRUST=250000
HOVER_THRUST=250000
ATTITUDE_THRUST=20000
ISP=400000
PMI=(20,15,10)
CROSS_SECTION=(68,20,20)
PITCH_MOMENT_SCALE=0.000001
BANK_MOMENT_SCALE=0.00001
ROT_DRAG=(0.05,0.05,0.03)
CW_Z_POS=0.5
CW_Z_NEG=0.5
CW_X=0.5
CW_Y=0.5
(http://img03.picoodle.com/img/img03/8/6/1/f_002Starwarsm_16fcd63.gif)
-
Bon, .... :doubt: J'ai trouvé un truc qui marche, mais c'est bizarre,
c'est l'inverse des configs utilisés pour les droides.
J'ai inversé le signe du COG, puis défini les Touchpoints en fonction. Et là le mesh
ne passe pas au travers du sol. Mais je trouve la manip bizarre car totalement
indépendante du mesh.
En mettant ça, et pourtant le mesh va plus bas je n'ai pas le défaut d'éclairage observé sur les droides.
MESHNAME="01_navette_Irridium"
COG=9
TouchdownPoints=0 -2 1 -1 -2 -1 1 -2 -1
Bref, je ne comprend rien mais ça fonctionne. :)
Message modifié ( 02-06-2007 04:14 )
-
ROOOOOOOH, Picto, tu es dans un ini spacecraft et les "TouchdownPoints" ne sont valide que pour un .cfg
traditionnel. Ils sont donc ignorés, tu peux effacer la ligne. Ce sont les LAND_PT par défaut (car non précisés dans
[CONFIG]) qui s'expriment.
Dans un .ini sp3 les points de contact avec le sol s'écrivent sous la forme:
LAND_PT1=(x,y,z), LAND_PT2=(x,y,z), LAND_PT3 = (x,y,z)
Bref, seul ton COG est valide.
Un COG=x ("center of gravity of the vessel above ground when landed") place ton centre de gravité au-
dessus du sol de x mètre. Si tu mets -20, il y aura forcément un résultat aléatoire car ce COG rentre en coflit avec
le LAND_PT par défaut (qui doivent être du genre (0,0,1) (-1,0,-1) et (1,0,-1) )
-
no matter a écrit:
ROOOOOOOH, Picto, tu es dans un ini spacecraft et les "TouchdownPoints" ne sont valide que pour un .cfg
traditionnel. Ils sont donc ignorés, tu peux effacer la ligne. Ce sont les LAND_PT par défaut (car non précisés dans
[CONFIG]) qui s'expriment.
Dans un .ini sp3 les points de contact avec le sol s'écrivent sous la forme:
LAND_PT1=(x,y,z), LAND_PT2=(x,y,z), LAND_PT3 = (x,y,z)
Bref, seul ton COG est valide.
Un COG=x ("center of gravity of the vessel above ground when landed") place ton centre de gravité au-
dessus du sol de x mètre. Si tu mets -20, il y aura forcément un résultat aléatoire car ce COG rentre en coflit avec
le LAND_PT par défaut (qui doivent être du genre (0,0,1) (-1,0,-1) et (1,0,-1) )
harf voila... je voulais pas dire de connerie, mais c'est sa! j'ai déjà eu le prb...
Perso, quand je veux posé un "msh" au sol orienté normalement (XYZ) le COG suffit sur un spc3...
si tu souhaites conservé le TouchdownPoint traduit par LAND_PT1, 2 et 3 faut que ton Y soit négatif... sinon il tombe comme
sur ton GIF
sa va de même pour les DLL... j'ai remarqué...
-
Ah ben oui :sad:
Pour ça que je ne voyais rien sur la Doc Spacecraft, et pourtant, j'avais bien vu ces histoires de touchpoints qui se
transforment en landpoints avec un choix sur une autre valeur de 0 à 2 ... enfin bref... un
J'ai honte :sad:, un peu, mais pas trop en fait, c'est comme ça qu'on apprend :)
Bon allez tant que je vous tiens.
Il y a plein de trucs auxquels je ne comprend rien et où ni la doc Spacecraft ni la doc Orbitersdk
ne m'éclaire plus que ça. J'utilise Shipedit et j'obtiens les valeurs Cross section ... j'en suis heureux !
Mais pour le reste .... :sick:
Quand par exemple pour PITCH_MOMENT_SCALE je lis dans la doc the pitchmoment scale in npar Kg m2, je ne suis
pas plus avancé. J'essaye donc toutes les valeurs à 0 pour voir .... puis à 1 pour voir ... puis j'en bouge juste une pour
voir ce qui se passe, mais je rame.
Par exemple, un truc que je n'arrive pas, mais pas du tout à régler c'est le cabrage de l'appareil.
Vu que c'est du SW, c'est quand même plutôt musclé question moteurs. Et bien si je lance les moteurs à fond et que
je ne touche à rien d'autre, l'appareil parcourt un cercle parfait d'environ 1500 mètres de diamètre, c'est joli mais
pas vraiment agréable à piloter pour grimper en Orbite. Ca pitche trop on dit je crois.
Bref, je ne comprend rien à tout ce qui se passe dans cette section du config ... sauf pour le cross section, encore que
je ne vois aucune différence notable dans le comportement du vaisseau quand je ne change que ces valeurs
là :badsmile:
PMI=(20,15,10)
CROSS_SECTION=(68,20,20)
PITCH_MOMENT_SCALE=0.000001
BANK_MOMENT_SCALE=0.00001
ROT_DRAG=(0.05,0.05,0.03)
CW_Z_POS=0.5
CW_Z_NEG=0.5
CW_X=0.5
CW_Y=0.5
Et puis, tant que je vous tiens aussi, des réglages atmo même si le mesh ne présente pas de particularités du type
ailes et ailerons peuvent peut être aider à améliorer le comportement d'un vaisseau au moment de l'atterrissage et
décollage ... puisque j'en suis dans le totalement réaliste :badsmile:
En tout cas, je vours remercie, ça commence à rentrer.
Pour l'instant, je maitrise, puissance, exhausts, positionnement
à peu près, animations un peu mieux, reste juste .... le reste ....
C'est bien que je comprenne tout ça pour aider Korben, ça dégrossit le travail pour les DLLs, une fois qu'on a un SP3
qui fonctionne, on aura le choix de faire une release avec quelques vaisseaux en DLLs, et les autres en SP3, il y en a
une trentaine en tout, ça fait beaucoup de DLLs donc pour l'instant il y aura pas mal de SP3 dans les scenarios.
avec ce rajout là ou GDAM peut être FDAM et CDAM, c'est pour être reconnu comme ami, ennemi ou civil et ça permet
à un SP3 d'être détruit par le bullet.
[PARENT_ATTACH_0]
NAME=DAMAGE
POS=(0,0,6)
DIR=(0.0, 0.0, 1.0)
ROT=(0.0, 0.0, 1.0)
LOOSE=1
ID="XS :GDAM"
RANGE=1
Message modifié ( 02-06-2007 15:34 )
-
Comment trouver le PMI:
(http://img502.imageshack.us/img502/9059/shipedithx5.jpg)
Les valeurs entourées sont celle qu'il faut attribuer au pmi.
CROSS_SECTION a normalement un assez grosse influence lorsque tu te sers des rcs en orbite, c'est moins evident à
voir sur le vol atmo (en tout cas il me semble).
PITCH_MOMENT_SCALE & BANK_MOMENT_SCALE, là je suis dans le flou, je ne sais pas exactement ce que c'est.
ROT_DRAG rend plus ou moins facile les mouvement du vaisseau sur son axe.
CW, pareil que pour PITCH_MOMENT... je ne sais pas trop ce que c'est exactement, mais je sais une chose: si tu défini
des "airfoils" et donc un modèle aérodynamique. Il ne servent à rien! Bref, les CW ne sont actif que pour le modèle de
vol par défaut.
Tout çà ne dois pas t'éclairer beaucoup plus, à vrai dire l'aérodynamique et moi çà fait deux ^^
Et puis, tant que je vous tiens aussi, des réglages atmo même si le mesh ne présente pas de particularités du
type ailes et ailerons peuvent peut être aider à améliorer le comportement d'un vaisseau au moment de l'atterrissage
et décollage ... puisque j'en suis dans le totalement réaliste
La majeure partie du comportement atmosphérique d'un engin se configure dans la section [AERODYNAMICS] et pas
dans la section [CONFIG]. c'est complexe, décourageant quant on s'y connait peu comme moi. une seule solution,
trouver un âme charitable qui est expert ou faire comme moi, tester, tester et retester. Pour une capsule, je m'en suis
sorti mais çà a été long.
Pour ton histoire de cabrage, là je ne peux pas t'en dire plus comme çà il me faudrait tatouiller l'engin en live. Faut
voir comment tu décolle entre autre, main? hover? hover+main? rcs éteints et attitude avec les surfaces de contrôle? trim?
Message modifié ( 02-06-2007 15:02 )
-
PITCH_MOMENT_SCALE & BANK_MOMENT_SCALE définissent en quelque sorte la résistance au changement de Pitch
et de Bank quand on veut modifier l'attitude du vaisseau en mouvement.
C'est un moment gyroscopique à vaincre.
Ces valeurs sont en général de l'ordre de 0.00001 à 0.00005
ROT_Drag= x,y,z est la résistance à la rotation autour des 3 axes quand le vaisseau vole en atmosphère.
C'est la force résistante qui va stopper les rotations. Les valeurs de x,y,z dépendent de la géométrie du vaisseau
CW_X et CW_Y sont les coefficients de trainée qui s'opposent au mouvement en athmosphére suivant les axes X et Y
CW_Z_NEG est le coefficient de trainée sur l'axe Z quand le mouvement se fait en arrière
CW-Z_POS est le coefficient de trainée sur l'axe Z quand le mouvement se fait en avant
Ces coefficients dépendent de la géométrie du vaisseau.
La trainée (résistance au déplacement) sur un axe dépend du coefficient de trainée, de sa vitesse au carré et de la
densité de l'atmosphère à l'altitude ou il évolue suivant la formule:
Trainée=0.5*coefficient de trainée*densité atmosphérique*cross section*vitesse^2
La densité atmosphérique varie suivant l'altitude et la température de l'atmosphère.
En général le coefficient CW sur l'axe Z sont bien plus faibles que sur les deux autres axes puisque la cross section
suivant Z est bien plus petite que celles suivant X et Y puisque le vaisseau est profilé pour avoir une bonne
pénétration dans l'atmosphère.
Le mieux pour choisir ces valeurs est de s'inspirer de vaisseaux existants et de procéder à des tests pour faire les
ajustements.
:sage: Papyref
-
hou hou!!! il va me servir ce post! :)
-
hum, au fait, quite a faire l'astroport de totooine, (mos espa...) autan le faire le plus réel possible (un petit plan ?) :
(http://img505.imageshack.us/img505/7206/mosespaxs1.jpg)
-
oui... ce réel reste une image... une vision d'une personne... perso Picto fera a sa façon, et sa lui donnera son charme!
-
Si, ça aide merci Nomatter :beer:
Quand toutes les petites cases seront comprises les unes après les autres ce sera bon.
Ca en fait trois ou je suis moins dans le flou grâce à ton aide.
D'après ce que tu viens de dire, ce doivent être les CW qui font cabrer puisque je n'ai pas défini de modèle aéro
car dès que j'ai passé l'atmosphère, le vaisseau cesse d'avoir ce comportement de cheval fou :)
Pour le cercle parfait, c'est touche + une fois puis Ctrl pour bloquer et je ne touche plus à rien, quand je fais ça avec
le DGIV, il ne se cabre pas, en tout cas pas violemment comme ce que j'ai ici. Remarque, c'est assez drôle, il repasse
exactement par l'endroit ou il était posé avant de mettre la gomme.
Si tu as un peu de temps, je peux t'envoyer l'un des mesh avec le .ini qui le concerne, tu verras ce qui se passe
quand on fait cette manip. Par contre, j'ai perdu ton mail dans le crash des disques durs. Autre exemple de
comportement délicat: les hovers. Le vaisseau bascule très très vite sans intervention, ça ça doit avoir affaire avec la
cross section je pense.
En fait, je voudrais réussir à faire des vaisseaux très stables pour qu'on puisse être un peu spectateur sur certaines
scènes. Hop, tu lances les moteurs, tu passes en vue externe et tu peux profiter des animations.
Tu vois l'idée. C'est du SW, le réalisme et le pilotage pointu c'est pas trop l'idée de départ.
Ce pourrait être sympa pour pouvoir rejouer des scènes des films; pour les fans.
EDIT
Oups, le temps d'écrire ce post, et paf ... Merci Papy.
Il faut étudier.
Yoann, pour l'instant, c'est une évocation, on verra. Il y a tellement de choses à faire donc comme dit Momo.
Et il faut quand même faire gaffe sur les sceneries, les moyens mis en oeuvre deviennent vite très très lourds.
Rien que pour les cinq planètes Level 10 Cinq ou six lunes et planètes en 4096 et Mos eisley c'est 570 MO
Tu vois ce que je veux dire ;) D'ailleurs les sceneries et planètes seront des addons à part avec leur propres scenarios et juste un ou deux vaisseaux.
Libre à chacun de relier l'ensemble ensuite avec les scenarios plus complexes des batailles. On en est pas là pour l'instant.
Pour te dire, quand je règle les ini des vaisseaux, je me suis fait un scenario banc d'essai sur Terre avec rien, pas une texture, pas une texture level je ne sais quoi pour la terre, non, rien, ça se lance plus vite :)
Chez moi, le Système SW met bien 25 secondes à se charger sur Orbiter alors que le banc d'essai à peine 2.
Message modifié ( 02-06-2007 16:23 )
-
Au fait, Momo, tu es sûr de ton coup pour les dossiers propres à un addon à l'intérieur de Spacecraft ?
Je n'y arrive toujours pas et j'ai d'ailleurs lu ça sur la doc SP3 ....
"The spacecraft module will search a ini file with the name of the vessel defined in the scenario
file ONLY in the config\spacecraft directory."
Message modifié ( 02-06-2007 16:34 )
-
Wow !
Rien que le PMI ajusté par ship Edit a déjà bien fait évoluer le cabrage, ça commence
à ressembler à quelque chose !
Merci NoMatter ! Reste à affiner tout çà grâce aux éclaircissements offerts par Papy !
-
j'ai tenté de retrouvé comment j'ai pu bien faire... sa seul chose que j'ai réussie a faire c'est rien...
j'ai du faire des tests avec des copies du spacecraft3 pour ne pas avoir de CTD... donc j'ai dis une connerie en la croyant
car j'avais toujours mes fichiers de base dans le dossier spacecraft3...
dsl... je vois que sa comme excuse... si un coup de baton... comme piqure de rappel...
-
Bref, à éviter pour ne pas créer de Spacecraft dans tous les coins des Orbiters des copains :)
Pour le comportement des vaisseaux
Ca fonctionne du tonnerre. En réglant PMI et trainées, on fait ce qu'on veut, merci papy !
Pour vous donner une idée de la motorisation réaliste des bestiaux, mise en orbite circulaire à 240 Km, consommation
0%, on a oublié ses clopes, pouf, rétrograde, on remet la sauce, une fois l'orbite cassée, on vise la base, level
horizon, on remet un peu de sauce pour conserver un peu de finesse. Et on se laisse porter comme une plume.
Z'ont une finesse incroyable vu le profil des bestiaux :lol:, je n'ai pas calculé, mais j'ai l'impression que je fais 10000
mètres par kilomètre d'altitude à 25 m par seconde., un coup de Killrot pour rester bien en ligne et on se fait un
atterrissage majestueux en repliant les ailes juste avant de se poser.
Ca commence à avoir de la gueule :)
-
Très utile le post de Papyref, çà meriterait un sticky!!! Merci en tout cas, bien que j'imaginai à peu près ce à quoi tout
çà correspondait, maintenant je comprend parfaitement ;)
Picto a écrit:
Merci NoMatter !
Au plaisir de voir tout ces addons starwars!
Pour tes vaisseaux, tu peux bien sûr te passer de la section [AERODYNAMICS] mais je pense qu'essayer de mettre:
[EARODYNAMICS]
MODEL=dglider
et regarder si çà convient n'est pas stupide.
Pour faire mieux, il faudra passer par tous les paramètres (VAIRFOIL, HAIRFOIL, ELEVATOR, AILERON, TRIM...) c'est là
que c'est complexe!
Message modifié ( 02-06-2007 17:17 )
-
Je vais essayer ça pour l'aérodynamisme, ça pourrait être sympa pour piloter
les trucs qui vont moins haut, comme les barges, motos et autres landspeeders.
L'idéal étant même de pouvoir limiter leur altitude maximum d'évolution...
Ce doit être possible j'imagine.
Je crois que Brainstorm maitrise bien tous ces paramètres. :siffle:
Sinon, je suis content, c'est bien du n'importe quoi question vol.
Ca fait bien SW, un exemple, petite montée verticale aux hovers à 1000 Km.
On pointe un endroit sur la planète. Un petit coup de poussée pour
amener le vecteur de vitesse sur la cible, on coupe tout, on laisse faire,
ça chauffe dur, le pitch moment amorce l'horizontalisation en même temps, à trois
kilomètres de la surface, on est à l'horizontale, on enclenche Horizon Level
et on a plus qu'à se poser comme une fleur ou on veut gentiment sans
avoir besoin de se préoccuper de quoi que ce soit, sans moteurs, les RCS suffisent
avec l'autopilot à ne même pas avoir besoin de se préoccuper de sa vitesse verticale ....
c'est même presque trop lent sur la fin :badsmile:
Pas mal pour faire de superbes atterrissages bien ridicules mais tellement Starwarsiens :)
Message modifié ( 02-06-2007 19:05 )
-
sa avance?
si non on peu encore avoir des screenshoots svp c'est tellement beau :bave:
-
C'est un peu au ralenti en ce moment ...
Korben règle des problèmes de boulot et s'y remet ensuite.
Pour ma part, j'ai un peu fait le tour de la question en ce qui concerne
meshes et textures et Spacecraft3 pour le moment ;
Une cinquantaine de modèles et décors.
J'essaye donc de me mettre à la prog pour aider Korben sur les DLLs ...
Ca risque de ralentir sérieusement mais le jeu en vaut la chandelle et en tous cas, c'est passionnant ;)
-
et pour les screen?
-
Bah, c'est bon pour le moment ... il y en a eu une bonne dose déjà
Et puis, meshes et textures, c'est spectaculaire, mais ça fait pas un addon ... ;)
Ca va prendre du temps avant d'avoir un truc potable :sad:
-
oooooooooooh
mais plus on attend mieux ce seras donc je vais prendre le torau par les corne!
-
aaargh plus de nouvelle depuis des mois !!!! il en est ou leprojet??? a la poubelle?
rebonjour tout le monde, et oui je suis revenu ^^''
-
ca c'est du necro-post ! :lol:
pas de nouvelles ? normal, pic est deja sur un autre addon....rhaa la la, ces jeunes, y finissent jamais rien...
-
Mais non ... enfin ... oui ... bon ... :sad:
On essayera de finir ... un jour ... C'est pas mort.
C'est juste que Korben est très très pris.
Irridium, c'est pour apprendre la prog.
Après, quand j'aurais fini la Corse, puis les bases, je pourrais finir Metropolis.
Comme ça je serais tranquille pour terminer les sondes automatiques.
Et hop y'aura plus qu'à finir Boulinium , puis les planètes pour passer à SW ...
Ca s'appelle de l'organisation ...
Par contre faut que je finisse la démo sur Ogre, pis le moteur 3D en DX9 entre deux.
-
On te laisse jusqu'au nouvel an pas plus !
Faut pas déconner quand même ! :badsmile:
-
c'est pas dutout du nécro-post, le fait est que je suis partit assez longtemps et je m'intérèssais beaucoup a cet
addon voila c'est tout ^^
-
C'est sublime votre travail. J'en reviens pas. Picto.... c'est quoi tu prends pour faire d'aussi belle chose. Un pro... OUF...
En passant tu me fais honneur
(http://img02.picoodle.com/img/img02/8/5/30/t_003Starwarsm_cf4374d.jpg)
L'origine réelle de Coussini viens de ce personnage, car quand il émet un son, cela sonne comme Coussini ;)
Message modifié ( 27-10-2007 21:06 )
-
Coussini a écrit:
C'est sublime votre travail. J'en reviens pas. Picto.... c'est quoi tu prends pour faire d'aussi belle chose. Un pro... OUF...
En passant tu me fais honneur
(http://img02.picoodle.com/img/img02/8/5/30/t_003Starwarsm_cf4374d.jpg)
L'origine réelle de Coussini viens de ce personnage, car quand il émet un son, cela sonne comme Coussini ;)
Pas possible ! :trucdeouf: Figure toi qu'a chaque fois que je regarde l'épisode IV et que j'entends les Jawa, ca me fait
toujours pensé a ton pseudo...sans savoir qu'il venait réellement de là !
au fait tu savais que Jawa est une marque de moto tchèque ? :)
Message modifié ( 27-10-2007 23:28 )
-
// désolé picto mais je continue dans le jawa off topic //
J'ai toujours pensé ou entendu "Outini!" .
Mais ma compagne m'affirme (dans un dédain notoire car elle n'aime pas star wars....) que c'est oukini !
Bah, on peut dire que les langages dans starwars sont assez sympa, souvent repris de plusieurs langues existantes
et mélangées entre elles.
Message modifié ( 28-10-2007 00:32 )
-
Moi j'entendais "houdini" :badsmile:
Dan
-
Et moi je ne sais pas de quoi vous parlez ! :badsmile:
Mais Coussini, j'étais certain que ça venait de Cassini.
Message modifié ( 28-10-2007 00:57 )
-
j'ai toujour entendu outsini moi
mais bon c'est pas facile a comprendre, moi je prefere les Ewoks sont mignon eux :turning:
-
DanSteph a écrit:
Moi j'entendais "houdini" :badsmile:
Dan
Moi j'avais compris "Cousin", les québécois sont décrits comme nos cousins d'amérique.
Message modifié ( 30-10-2007 12:52 )
-
Moi aussi, c'est Houdini que j'entendais...
...reste plus qu'à vérifier dans le script ;)
Pagir
-
M'um m'aloo! Lançons nous dans l'apprentissage de la langue Jawaese:
Jawaese-Basic:
Ashuna (ah shoo nah) v. 1. Go.
Ayafa (ay yaff fuh) n. 1. Clan.
Baba (bah bah) n. 1. Days.
Bazzok (bazz zok) v. 1. Cook.
Bok (bock) adj. 1. Far.
Bom’loo (bomm loo) n. 1. Bargain.
Bopom Kova (boh pom koh vah) n. 1. Mountain.
Buja (boo jah) 1. How.
Chikua (chik oo ah) n. 1. Them.
Cirkoza (seer koh zuh) n. 1. Encampment.
Dikwass (deek wahss) n. 1. Cliff.
Dooka (doo kah) n. 1. Junk.
Dook'wab (duke wahb) n. 1. Scanner.
Eyeta (ee yett ah) n. 1. Friend.
Gomjam (gomm jamm) adj. 1. Always.
Ha'mfoo (ha muh foo) v. 1. Burn.
Hazamuzee (hahz ah moo zee) v. 1. Chant.
Hkeek nkulla (he keek nu kuh lah) n. 1. A particularly disparaging Jawa curse. (8)
Hunya (hunn yah) n. 1. Enemy.
Ibana (ih ban ah) 1. Yes.
Ikee (ick kee) 1. I.
Jar k’osa (jar koe sah) adj. 1. Large.
Jubinloo (jubb in loo) n. 1. City.
Kebee'oto (keh bee oh toh) adj. 1. Long ago.
Keeza (kee zah) n. 1. Weapon.
Kiizci (keez see) n. 1. Cave.
Kiluyak (kill yu yak) n. 1. Cloud.
Ko lopo (koh loh poh) adj. 1. Broken.
Kurruzza (kuh ruh zah) v. 1. Repair.
Lika (lee kah) n. 1. Sea.
Lopima (loh pee mah) n pl. 1. Stars.
Lo'wassa (loh wahss ah) n. 1. Sail barge.
Mambay (mamm bay) 1. Okay.
Meeglay (mee glay) v/n. 1. Clean.
M'nuta (ma noo tah) n. 1. Hole.
M'tuske (muh toosk) v. 1. Steal.
M'um m’aloo (mum mah loo) 1. Greetings. 2. Hello.
Nekkel juuvar obwegadada (nek kil ju vahr ob we gah dah dah) n. 1. Jawa curse. (8)
Neng ooka (neng oo kah) n. 1. Yesterday.
N'lappu (nah lah poo) n. 1. Water.
Nufuzu (noo foo zoo) adj. 1. Below.
Nyeta (nee yett tuh) 1. No.
Ogo (oh goh) adj. 1. High.
Okka (Ahk ah) adj. 1. Up.
Oko (oh koh) adj. 1. Cold.
Ookwass (ook wahss) 1. Where.
Opakwa (oh pak wah) n. 1. Spare parts.
Opawi (oh pah wee) v. 1. Give.
Perupa (peh roo pah) v. 1. Pray.
Pibboz (pih bahz) adj. 1. Warm.
Ratapa (rat tap ah) n. 1. Knife.
Rillo (rill loh) n. 1. Dune.
Rubac (roo bak) n. 1. Rust.
Sabioto (sah bee oh toh) v. 1. Stop.
Shanay (shah nay) v. 1. Sleep.
Shootogawa (shoot oh gah wah) v. 1. Shoot. 2. Blast.
Sooga (soo gah) n. 1. Food.
Speeda (spee dah) n. 1. Speeder.
Taa baa (tah bah) 1. Thank you. 2. Thanks.
Takiik (tah keek) adj. 1. Tomorrow.
Tando (tan doh) v. 1. Fix.
Tilba (till buh) adj. 1. Above.
Toineepa (toy nee pah) n. 1. Credit.
Ton ton (tahn than) n. 1. Sand.
Ubanya (Oo bann yah) 1. Good day. 2. Good-bye.
Ugama (yu gah mah) n. 1. Bantha.
Umka (um kah) v. 1. Walk.
Umpee (um pee) n. 1. Empire.
Upezzo (yu pezz oh) n. 1. Market.
Utinni (oo tee nee) 1. Wow. 2. Battle cry. 3. Alert to other jawas.
Vapoosza (vapp oo zhuh) n. 1. Vaporator.
Waff’mla (wahff mlah) n. 1. Desert.
Wass (wahss) adj. 1. Hot.
Yaytah (yay tah) adj. 1. Later.
Ysas (ee sas) adj. 1. Equal.
-
Au moins, c'st clair ;)
-
:lol:
C'est fou comme on peut entendre ce qu'on veut avec 3 syllabes.
No Matter a gagné (d'une manière douteuse, puisque c'est lui qui fournit le dico :badsmile: ), suivi de près par
Raptos. Mention spéciale à la copine de No Matter.
Pagir
-
Ouais :badsmile:
Je me demande bien ce qu'on aurait pu croire entendre sur celui là ! :siffle:
Dikwass (deek wahss)
-
Pagir a écrit:
:lol:
C'est fou comme on peut entendre ce qu'on veut avec 3 syllabes.
No Matter a gagné (d'une manière douteuse, puisque c'est lui qui fournit le dico :badsmile: ), suivi de près par
Raptos. Mention spéciale à la copine de No Matter.
Pagir
c'est Raptros :sad:
-
bave : bave : bave
Plus de nouvelle de ce merveilleux développement ?
Allez courage :)
-
En stand by pour le moment ;)
-
Dac merci brainstorm !
@+
-
:up: Ou en es cet add-on qui prévoit du super cool?:)
-
A mon triste avis, il n'est pas prêt de repartir
-
Mince:(