Star Wars The Final Battle

[Raptros]

bin oui justement donc c'est déja fait et a moin d'en faire des film je vois pas.....

[picto]

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 ...

[Raptros]

ahaaha et C3PO il est devenu homosexuel



Message modifié ( 26-05-2007 17:00 )

[Papyref]

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

Papyref

[Momo]

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!!!!

[picto]

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

[DanSteph]

picto a écrit:
Je suis sûr qu'il n'y en a pas un ici capable de faire ça

DE QUOI ? 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
mais c'est possible of course.

Dan

[picto]

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 )

[picto]

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





Message modifié ( 27-05-2007 03:10 )

[picto]

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 )

[Well]

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 )

[picto]

Ah merci !

Réponse efficace. 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 )

[Well]

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



Message modifié ( 27-05-2007 08:43 )

[picto]

Thanks

je vais continuer à bricoler ces points...
J'obtiens des trucs, disons, aléatoires...
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

[picto]

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é

[Schimz]

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

[picto]

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.

[picto]

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.





Message modifié ( 27-05-2007 10:27 )

[Papyref]

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.

Papyref

[picto]

:put: de de :bord: de :merd: d'informatique de mes coui ...à la c ...
Fallait des ...... points ..... à la place des ,,,,,,, virgules ,,,,,,,
C'est bon ça fonctionne et c'est logique ! Mais ce genre de subtilités d'écriture  

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 ?
Il est anglais je crois, ça expliquerait bien des choses
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



Message modifié ( 27-05-2007 10:48 )

[Papyref]

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...

Papyref

[Schimz]

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 )

[DanSteph]

...Sans parler de la panse de brebis farcie

Me souvenait même plus qu'il existait un autre systeme que
Left hand avec z en profondeur...

Tu va y arriver pic...

Dan

[picto]

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.

[picto]

Qui a dit que c'était chiant à trouver les touchdown points
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  
D'ailleurs, y'a qu'à voir ce que j'en fais moi des DGIV





Message modifié ( 27-05-2007 15:34 )