Space Dementia II mod arena v0.2 - Page 6

Bah... comment il organise les points pour former des volumes.

La sphère de dégat est définit par l'ensemble de l'espace dans lequelle les laser doivent se trouvés pour faire des dégats.
Comme elle est définis par les point qui sotnaux extrémité du vaisseaux (donc les panneau solaires pour le tie) et que y a que les panneaux solaires qui sont à 1, j'en déduit que c censé représenter la sphère de dégat.

En ce qui concerne la sphère de dégats, je doute qu'il procède comme ça, parce que jai du mal à voir l'intérêt de la représenter comme ça, surtout que ce n'est pas une shpère.

Pour ce qui est des volumes, chaque sommet est représenté par un point, et chaque face par plusieurs points. Je ne vois pas où est le pb

Pour les volumes, je vient de comprendre. Les chiffres corespondent au N° des sommets.

Pour la sphère de dégat, c comme ça qu'il procède (d'aprés ce que g compris), mais je c pas si c comme ça qu'il la représente.

Ce serait plus simple de simplement pour chaque objet stocker le rayon de la sphère et de calculer la distance entre le missile et le centre de l'objet, et si cette distance est inférieure au rayon, c'est que le missile est dans la sphère. C'est comme ça que je ferais moi.

Il faut quand même que les missiles n'aillent pas trop vite dans ce cas-là, sinon on peut "passer à travers" en allant à contre-sens du missile

Oui.
Je vois difficilement comment éviter ça sans faire avancer le missile d'une unité à chaque fois (enfin, on peut le faire avancer de 15 pas par exemple à chaque frame, mais il faudra quand même tester entre chaque pas s'il n'est pas en collision avec un objet).
Enfin, si je fais un jeu de ce genre, je me débrouille pour que le missile n'aille pas trop vite. De toute façon, c'est mieux comme ça on peut éviter le missile, ça rajoute du fun.
Faudrait faire comment pour résoudre le pb ?

Si le missile va de A à B, alors d(M,[A,B]) = d(M,(AB)) si (MA | AB).(MB | AB) < 0 (produit scalaire), et sinon on peut tester par rapport à d(M,B) (normalement d(M,[A,B]) = min(d(M,A), d(M,B)), mais on a déjà testé pour A, je ne pense pas que ça soit la peine de re-tester même si M bouge).

Je ne comprends pas tes notations, [A,B] représente quoi ?

Le segment qui relie A et B

Ah, au temps pour moi, je croyais qu'on écrivait [AB].
Je suppose alors que (AB) représente la droite passant par A et B, mais dans ce cas, pourquoi la distance entre M et le segment [A,B] est la même que la distance de M à la droite (AB), si d(M,[A,B])=mon(d(M,A),d(M,B))

je croyais qu'on écrivait [AB].

Ben, ça dépend. C'est vrai que dans ce cas précis, ça ne pose pas de problème d'écrire [AB], mais bon, c'est l'habitude des segments dans |R

pourquoi la distance entre M et le segment [A,B] est la même que la distance de M à la droite (AB), si d(M,[A,B])=mon(d(M,A),d(M,B))

Non, ça dépend du signe de (MA | AB).(MB | AB), c'est soit l'un soit l'autre (au passage, j'ai corrigé une petite erreur dans mon premier post ).
En fait, de manière plus détaillée :
- si (MB | AB) <= 0, alors d(M,[AB]) = d(M,B)
- si (MA | AB) >= 0, alors d(M,[AB]) = d(M,A)
- sinon, d(M,[AB]) = d(M,(AB)).

Heureux?

oui

moitib> Tu as environ combien de polygone à afficher par frame ? Et ça tourne à quelle vitesse ?

Mmh... Vous avez soulevé le problématique problème des collisions !!

Vous avez pratiquement tout deviné sur l'édition du vaisseau :
Je récapitule :
- les sommets sont numérotés sur les schéma (les 40 )
- le centre du repère est pris n'importe ou, mais de préférence au centre (de gravité ou pas) du vaisseau... effectivement pour quand le vaisseau tourne sui lui-même...
- Les deux colonnes à gauche sont les coordonnées de tous les points
- La colonne à droite est bien la définition des faces, en un seul tableau avec dans l'ordre, le nombre de sommets de la face, les index des points qui constituent la face, et le 0 ou 1 final indique : 0 face visible que d'un coté (coté direct) et 1 face visible des deux cotés (les ailes !! )
Les faces visibles que d'un coté servent pour le backface culling (ne pas dessiner les faces tournées vers l'arrière)...

Le format de stockage est un seul tableau, mais ca n'est pas du tout pratique pour accéder au sommets d'une certaine face (il faut avancer progressivement grace au nombre de sommets de chaque face). Donc au début du programme, j'alloue de l'espace pour un tableau structures "face" avec un nombre de sommet fixe (une dizaine)...
Le but est évidemment de limiter la taille de stockage des données...

Pour chaque vaisseau, je définis une liste de points, une liste de polys, une liste de points "extrémités" et une liste de points "canons".
Ces informations sont regroupées dans un structure SHIP_INFO pour chaque vaisseau :

/**************************** Définition du TIE Bomber ****************************/

	Vertex tieBVertices[40] = {{80,30,-70}, ...};
	short tieBPolys[]= {6, 9,8,7,2,1,0, 0,
	  			6, 7,6,5,4,3,2, 0,
				6, 10,11,12,17,18,19, 0,
				6, 12,13,14,15,16,17, 0, // Facades avant et arrières
			        
                                4, 0,1,11,10,	0,	// Corps
				4, 2,12,11,1, 0,
				4, 3,13,12,2, 0,
				4, 4,14,13,3, 0,
				4, 5,15,14,4, 0,
				4, 6,16,15,5, 0,
				4, 7,17,16,6, 0,
				4, 8,18,17,7, 0,
				4, 9,19,18,8, 0,
				4, 0,10,19,9, 0,
				2, 20,21,      1,	// Bras
				4, 22,23,27,26, 1,	// Aile
				4, 23,24,28,27, 1,
				4, 24,25,29,28, 1,
    			        2, 30,31,          1,	// Bras
				4, 32,33,37,36,	1,	// Aile
				4, 33,34,38,37, 1,
				4, 34,35,39,38, 1 };

	short tieBEnds[8] = {32,22,25,35,36,26,29,39};
	short tieBCanons[2] = {20,30};

	SHIP_INFO tieBInfo = {tieBVertices, 40, tieBPolys, 22, tieBEnds, tieBCanons, "TIE Bomber", -33, 0.5};

Il y a quelques différences entre ma feuille de cahier et le code au dessus, c'est parce que je m'étais gouré dans les orientations des faces...

La detection des collisions est faite uniquement grace au tableau tieBEnds.
Le temps de faire un ptit dessin et je vous explique comment je fais.

Bon, excusez le dessin à la main mais c'est juste pour expliquer



Au début, je calcule le rayon de la sphère englobante du vaisseau (en bleu).
Ensuite j'ai choisi 8 points "extrémités" du vaisseau (liste tieBEnds, croix rouges sur le dessin), qui correspondent chacun à un secteur de dommages.
Les secteurs sont détruits quand un missile est détecté dans la sphère rouge correspondante ET dans la sphère bleue en même temps.

La méthode est donc celle de Sasume au post 153, mais apliquée en 8 points simultanément...
Cette méthode de detection par sphère est le plus rapide et la plus facile à mettre en oeuvre, mais c'est la moins précise...

Quand les vaisseau ont des formes pas très sphériques (ex : Xwing ou Lambda class shuttle), un tir "dans le vide" à proximité du vaisseau peut se retrouver dans un sphère rouge et dans la sphère bleue...
Par contre le TIE fighter est très compact donc difficile à descendre....

C'est problématique... Si vous avez des suggestions.

Je pourrais peut etre définir certaines faces commes sensibles au passage des missiles à travers (pour ne pas faire les tests sur toutes les faces, même les plus insignifiantes), et voir si le vecteur entre deux positions successives du missile coupe une de ces faces, mais le problème pourrait etre que le missile traverse le vaisseau justment par des petites faces insignifiantes non réactives... et puis ca rallentirait...

44 faces et 56 points, ça passe ??

Et le coup du TIE fighter invulnérable c'est aussi lié à la vitesse du missile ou bien est-ce que même un missile quasi-statique n'arriverait pas à le descendre? (auquel cas ce serait un pb de taille de sphère)

-> Mac : Faut voir, c'est limite (Xwing : 42 points, 37 faces)
Pour l'échelle, il y a 200 entre les ailes du TIE fighter (au fait, les nombres notés sur la feuille du TIE bomber sont ensuite mutipliés par 10)

-> Pollux : Tu as raison, il est possible que des missiles le dépassent sans rien provoquer, je n'y avais pas pensé !!
Car la vitesse du vaisseau s'ajoute à celle du missiles au lancement du missile. Donc à pleine vitesse il est très possible que les missiles "traversent" les sphères sans que ca soit detecté... A rectifier...

du bomber, tu veut dire (celui sur la page précédente) ??

moitib> D'où la méthode dont je parlais avec la distance par rapport au segment parcouru par le missile sur [t0,t0+dt] et pas simplement sur {t0+dt} ...

MacIntoc
: du bomber, tu veut dire (celui sur la page précédente) ??

Non, il parle bien du fighter. Regarde plus en avant.

euh... je vois pas l'endroit en question
Le seul schema représentant un tie fighter, c celui qui est juste au dessus en bleu et rouge.

C'était juste pour te donner un ordre d'idée, la largeur du TIE fighter c'est 200, celle du TIE Bomber c'est 340 : si tu regardes sur la feuille (en multipliant par 10 les coordonnées)
x21 - x31 = 170 - (-170) = 340

Et le dessin au dessu en bleu et rouge, c'est le TIE bomber...

moitib> Tu as oublié le post ./163

En effet
Bon j'ai fait un ptit bench mais c'est pas très représentatif comme résultat parce que la vitesse dépend de la surface à afficher.
A distance proche, une trentaine de polys pour ~7fps, mais bon c'est toujours pareil, il y a du clipping 3D sur 5 plans pour chaque polygone... essentiel pour un bel affichage mais qui rallentit.

Sinon les étoiles sont des points dans l'espace (placés aléatoirement) que je transforme comme les autres (rotations, translations, projection -> 2D), puis j'y dessine une étoile...
En multijoueur, les cieux sont les mêmes (il y a transmission des données "aléatoirement" choisies au début sur la calc hôte).

Ah, c'est surtout le clipping, qui ralentit ?
7 fps, c'est vraiment peu

Comment tu gères ça? Tu fais de chaque triangle 5 polygones?

Sasume :
Ah, c'est surtout le clipping, qui ralentit ?
7 fps, c'est vraiment peu

Oui, ca rallentit pas mal... 7 fps c'est peu mais ca reste jouable...
Ca dépend du nombre de missiles en vol, de la complexité du vaisseau ennemi mais de manière générale le jeu est pas mal jouable...

Pollux
: Comment tu gères ça? Tu fais de chaque triangle 5 polygones?

Le clipping ?
Je clippe sur la "pyramide de vision (4 plans cotés + 1 plan devant) en clippant successivement sur chaque plan. Le clipping est effectué directement sur les polygones à n cotés pour plus d'efficacité.
Un clipping 3D revient à découper les polygones sur un plan (pendant l'opération le nombre de sommets de chaque face peut augmenter ou diminuer, ce qui rend le codage un peu complexe, sinon la position des points créés aux intersections plan-polygone se calculent facilement).

Ah OK je croyais que tu parlais de partitions pour les BSP (ça ne semble pas absurde, 32 ~ 2^5).
Oui, le clipping avec la pyramide de vision est une solution. Ca t'évite de clipper tes routines de tracé de ligne horizontale, ou il y a des petites imprécisions de calcul?
(en même temps il faut tout refaire à chaque frame, aïe...)

Et bien justement pour l'instant j'avais clipping 3D et clipping 2D (clipping des lignes horizontales et non écriture au dessus ou en dessous de l'écran) car je pensais que les imprécisions (car il y en a, tout est fait en virgule fixe) seraient dangereuses...
En fait, comme il y a un cadre autour de l'écran, j'ai resséré un peu la pyramide de vision et supprimé le clipping 2D ce qui accélère franchement le moteur , sans bugs pour l'instant... C'est surtout la suppression du clipping 2D vertical qui peut etre problématique car il peut faire écrire en dehors de l'écran (virtuel). Sur les cotés ca fait juste un rebouclage de l'autre coté de l'écran sur les TI92+/V200 et ca fait rien dans une certaine mesure sur les TI89...

Et sinon, le moteur actuel marche par tri en profondeur et non pas par BSP.