Jump to content
Jagware
Sign in to follow this  
Fredifredo

Et si on parlait de 3D ?

Recommended Posts

Fredifredo    0

La 3D sur jaguar c'est toute une histoire qui commence avec Cybermorph et se finit avec Iron Soldier 2

 

J'ai fait quelques recherches et pour faire de la 3D selon Atari , il fallait simplement 3Ds Max et leur convertisseur maison 3DS2JAG qui convertissaient les meshes au format pour la jaguar, comme d'hab le soft est tout pourri et en version beta ...

 

 

 

CTS notre ancien confrère, avait débuté quelques expériences en 3D, avec l'aide d'un certain Symmetry of TNG

 

et bossait avec le soft Blender sous Linux, il avait fait son propre logiciel pour convertir ses objets 3D.

 

 

 

Aujourd'hui Gorf, donne quelques leçons sur le forum de Jason Smith pour ceux que ça interesse.

 

 

 

Il y a quelques codes sources de l'époque d'Atari qui trainent sur des CD ou ils utilisent bien sûr 3DS Max ( tiens au fait il coûte combien ? ),parmi ceux-ci il y a tout de même le code source de Fight for life ! Sinon il y a Doom avec sa pseudo 3D mais le problème rencontré avec le fichier WAD spécifique à la Jag freine un peu les developpeurs

 

 

 

Mais ce qui serait le top c'est le moteur de Iron Soldier 2 ! Là les possibilités en matière de jeux 3D seraient quasi infinies tellement ce moteur semble supérieur aux autres ...

 

 

 

Comme ici on ne discute pas trop et qu'on préfère agir , voilà tout simplement une question :

 

 

 

Qui veut faire de la 3D sur jaguar ?

Share this post


Link to post
Share on other sites
GT Turbo    4

Pour des routines 3d tout court, je dois pouvoir adapter notre routine 3d 68000 au Dsp sans trop de soucis. Par contre après pour ceux qui est mapping pur, on a encore du boulot. Pour le gouraud mes connaissances du blitter ne sont pas encore arrivés la.

 

 

 

GT Turbo ;)

Share this post


Link to post
Share on other sites
GT Turbo    4

Petit hors sujet :

 

 

 

Fredifredo :

 

Comme ici on ne discute pas trop et qu'on préfère agir , voilà tout simplement une question :

 

 

 

 

Ca change quand meme des forums ou on fait que parler!! Jagware Power !! :yes:

 

 

 

Retour a la 3d, personnellement j'ai toujours pensé que réutiliser un code d'un autre pour 'refrabriquer' avec était un peu aléatoire. Car quand on veut rajouter une bricole sur un moteur 3d comme celui de I.S., vu le niveau des codeurs le code est ultra optimisé donc le moindre rajout peut générer plus d'emmerde qu'autre choses, alors que quand on devellope son moteur soi meme, tout est autorisé.

 

 

 

On peut utiliser 3ds, si il faut un outil de conversion, je le fais cela n'est pas un problème, car souvent quand on veut optimisé (Ce mot revient souvent trouvez pas ?), leur format de fichier ne collera peut ètre pas avec notre moteur, donc une modification sera nécessaire.

 

 

 

GT Turbo ;)

Share this post


Link to post
Share on other sites
Azrael    0

Avant de se lancer dans des convertisseurs de format, j'aimerai savoir quels sont les processeurs capables de faire des calculs 3D rapides, en entiers ou en virgule flottante, avec des accès mémoire pas trop lents. J'aimerai savoir s'il y a des tracés de ligne et du remplissage de polygones rapide. Comment se comporte aussi la déformation d'images bitmap (morphing, rotation...).

 

 

 

S'il y a de la 3D, j'en discutait avec RaZ, il serait bien de faire aussi un moteur son 3D où on peut localiser une source au moins droite-gauche avec un effet Doppler s'il y a du mouvement. Ca serait plutôt un job pour le DSP, mais si lui est occupé, quel processeur se chagera de la 3D ?

Share this post


Link to post
Share on other sites
SCPCD    0

Le seul processeur qui serait capable de faire ca, je pense, serais le GPU car lui, il a un accés 32bits voir 64 dans la RAM (utilisation des instructions loadp et storep) et il a un accés direct au blitter (donc sans utilisation de la bande passante de la RAM) qui lui posséde des fonctionnalités pour la 3D (Zbuffer et aussi je crois du remplissage) mais je n'ai jamais fait de 3D polygoné donc je ne sais pas trop comment il faut faire pour utiliser le blitter pour le faire.

 

 

 

Pour l'histoire des float, il faut faire une petite librairie.

 

Mais il y a une seul instruction GPU/DSP : MTOI qui permet d'extraire la 'mantissa' d'un float signé IEEE 32 bits et de le convertir en entier signé.

Share this post


Link to post
Share on other sites
Azrael    0

J'avais vu qu'il y a une fonction Zbuffer dans le blitter, mais je ne sais pas trop comment elle fonctionne. Si c'est du tri pour faire un affichage d'objets 2D dans un environnement 3D et s'il est possible de récupérer le liste triée, alors on pourra faire du tri sur les polygones.

 

 

 

J'ai demandé a GT s'il pouvait faire un récapitulatif des fonctionnalités de la Jag dans un article. Les docs des différents processeurs sont-elles disponibles dans un format électronique ?

 

 

 

Pour les flottants, pas besoin de faire de librairie, je pense ça ralentirait trop les calculs. Autant tout implémenter en entiers dès le départ.

Share this post


Link to post
Share on other sites
SCPCD    0

Pour ce qui est des docs pour les processeurs, il existe en fait qu'une qui les regroupes tous (sauf le 68000) et en pdf. Mais le hic c'est qu'elle est mal fichu et donc on passe le plus clair de son temps a lire, relire, rerelire ... toute la doc pour trouver ce que l'on cherche. Et généralement, il faut aussi faire des tests a la main car il est écrit un truc du genre : 'avec ce processeur on peut faire ca, et ca et puis ca' mais aucune explication sur la configuration a faire....

Share this post


Link to post
Share on other sites
GT Turbo    4
Azrael :


J'avais vu qu'il y a une fonction Zbuffer dans le blitter, mais je ne sais pas trop comment elle fonctionne. Si c'est du tri pour faire un affichage d'objets 2D dans un environnement 3D et s'il est possible de récupérer le liste triée, alors on pourra faire du tri sur les polygones.







Apparement cette fonction permet juste en cas de copie de bloc, tracé de lignes, etc.. de comparé ton Z avec celui présent en dessous, d'après ce que j'ai pu comprendre.



Mais j'ai l'impression qu'il va falloir utiliser par contre la meme technique que sur micro, balayage des lignes du polygone puis remplissage ligne par ligne, ce qui fait peur avec de genre de technique c'est le calcul des valeurs du blitter mais plus de temps qu'a remplir avec un peu de code, sinon il y a peut etre une autre technique, on remplit entierement chaque ligne, enfin on calcule les valeurs pour remplir a chaque fois la ligne complete et on joue avec les registres de clipping, on clippe a gauche et droite avec les X, X1 de notre polygone , est ce que cela serait assez rapide ? Car on aurait pas beaucoup de registre a modifier d'une ligne a l'autre



GT :wacko:

Share this post


Link to post
Share on other sites
SCPCD    0

Il faut faire attention, je ne sais plus trop mais je crois qu'il y a des bugs dans le blitter pour le clipping dans certains cas.

Share this post


Link to post
Share on other sites
GT Turbo    4
SCPCD :


Il faut faire attention, je ne sais plus trop mais je crois qu'il y a des bugs dans le blitter pour le clipping dans certains cas.





J'arrete pas d'y penser, mais pour l'instant je cherches surtout la manière la plus rapide de faire du remplissage et pour l'instant je voies que cela.





A MORT LES DOOM LENTS OU EN BASSE RESOL !!!






GT en train d'optimisé sans écrire de code !! :wacko:

Share this post


Link to post
Share on other sites
Fredifredo    0

J'ai découvert parmis tous mes dossiers un nouveau convertisseur qui existe à la fois pour Atari et PC , ça semble être une version amélioré de 3DS2JAG par contre j'ai zappé le nom ( c'est sur l'autre PC ) 3DSCONV ou un truc comme ça ... il date d'avril 1995 , je n'ai pas vu le code spurce avec par contre ...

 

 

 

la dernière demo 3D en date qui va avec est à 80% en language C... :P:o

Share this post


Link to post
Share on other sites
GT Turbo    4
Fredifredo :


J'ai découvert parmis tous mes dossiers un nouveau convertisseur qui existe à la fois pour Atari et PC , ça semble être une version amélioré de 3DS2JAG par contre j'ai zappé le nom ( c'est sur l'autre PC ) 3DSCONV ou un truc comme ça ... il date d'avril 1995 , je n'ai pas vu le code spurce avec par contre ...



la dernière demo 3D en date qui va avec est à 80% en language C... :P:o





Je crois avoir vu un truc comme cela, mais tant qu'on aura pas de moteur 3d, on pourra rien voir.



De la 3d 100% Dsp et remplissage 100% Gpu, c'est le genre de duo qui fait des étincelles !!



GT Turbo ;)

Share this post


Link to post
Share on other sites
Azrael    0

Interrogation :

 

 

 

Pour faire de la 3D le moyen le plus simple est de passer par une matrice de rotation. Pour les non matheux il s'agit grosso-modo de faire 9 multiplications pour faire un changement de repere. Après la projection sur l'ecran coute deux divisions.

 

 

 

On peut remplacer les multiplications et divisions par des additions et soustractions avec un les logarithmes et exponentielles.

 

 

 

La question :

 

 

 

Une multiplication de D0 par D1 coute-t-elle moins chere que

 

 

 

 

add.l D0,D0

 

add.l D1,D1

 

move.l log(D0),D2

 

move.l log(D1),D3

 

add.l D2,D3

 

move.l exp(D3),D0

 

 

 

 

l'ecriture log(D0) est à remplacer par l'instruction qui va bien pour accéder au tableau log en position D0...

 

 

 

Ou bien on a des calculs en virgule flottante et alors on ne se pose plus de questions...

Share this post


Link to post
Share on other sites
GT Turbo    4
Azrael :


Une multiplication de D0 par D1 coute-t-elle moins chere que





add.l D0,D0

add.l D1,D1

move.l log(D0),D2

move.l log(D1),D3

add.l D2,D3

move.l exp(D3),D0









Estimation a l'oreille, j'ai pas de table de cycles 68000 sous la main :



add.l d0,d0 (4 ou 8)

add.l d1,d1 (4 ou 8)

move.l 0(a0,d0.w),d2 (aux alentours des 20 cycles)

move.l 0(a1,d0.w),d3 (aux alentours des 20 cycles)

add.l (4 ou 8)

move.l 0(a2,d3.w),d0 (20 de nouveau)



Ceci est une estimation (Tentative de souvenirs) d'ou mes 4 a 8. Ce soir je prendrais les cycles exacts, mais cela devrait etre un truc pas trop loin !! :wacko:



Ce qui ferait un total de 84, la multiplication signé est (de tete encore une fois !) aux alentours des 70, donc !! Enfin tout cela est a vérifier. Mais le calcul serait plus très juste si on applique cela sur le Dsp, ou une multiplication fait 3 cycles, et je vais voir pour t'envoyer la doc concernant la multiplication matriciel hard du Dsp, mais cela a l'air 'funky' quand meme. Donc dans le cas du Gpu ou du Dsp autant faire une multiplication.



GT En train de compter !! ;)

Share this post


Link to post
Share on other sites
cts    0

Une multiplication point*matrice ça donne ça en GPU:

 

 

 

        store   rmat,(rd_mtxa)   ; 

 

129 moveta r0,r3

 

130 moveta r1,r4

 

131 nop

 

132 mmult r3,r8 ; (x.Vx+y.Vy+z.Vz+1*Tx)<<14

 

133 sharq #SCL,r8

 

134 nop

 

135 nop

 

136 mmult r3,r9 ; (x.Ux+y.Uy+z.Uz+1*Ty)<<14

 

137 sharq #SCL,r9

 

138 nop

 

139 ;nop

 

140 mmult r3,r10 ; (x.Dx+y.Dy+z.Dz+1*Tz)<<14

 

141 sharq #SCL,r10

 

142

 

143 add xcenter,r8

 

144 add ycenter,r9

 

 

 

Bon, bien sûr faut calculer la matrice caméra avant, mais ç'est pas mal rapide.

 

En gros, trois MMULT pour les 3 colonnes de la matrice (pour la 4ième on s'arrange ;))

 

Le calcul de la matrice caméra donne à peu près ça:

 

 

 

[code]cam2mat:

 

tx equr r5

 

ty equr r6

 

tz equr r7

 

dx equr r8

 

dy equr r9

 

dz equr r10

 

ux equr r11

 

uy equr r12

 

uz equr r13

 

vx equr r16

 

vy equr r17

 

vz equr r18

 

 

 

movei #pos,r14

 

load (r14),tx ; translation vector

 

load (r14+1),ty

 

load (r14+2),tz

 

neg tx

 

neg ty

 

neg tz

 

 

 

movei #look,r14

 

load (r14),dx

 

load (r14+1),dy

 

load (r14+2),dz

 

add tx,dx

 

add ty,dy

 

add tz,dz ; lookat vector

 

 

 

; normalize

 

imultn dx,dx

 

imacn dy,dy

 

imacn dz,dz

 

resmac r4 ;dx^2+dy^2+dz^2

 

 

 

if DEBUG

 

;BRKGPU

 

endif

 

 

 

CALL sqrt ; lookat vector length

 

shlq #SCL,dx ; before div

 

shlq #SCL,dy

 

shlq #SCL,dz

 

IDIV r4,dx ; lookat (Z) vector normalized (S.15)

 

IDIV r4,dy

 

IDIV r4,dz

 

 

 

; guess an up vector

 

; (temp hack, no roll )

 

movei #0,ux ; UP vector

 

movei #1<<14,uy ;

 

movei #0,uz

 

 

 

; guess a RIGHT vector

 

; cross(d,u)

 

move dy,vx

 

imult uz,vx

 

move dz,r0

 

imult uy,r0

 

sub r0,vx

 

sharq #SCL,vx

 

move dz,vy

 

imult ux,vy

 

move dx,r0

 

imult uz,r0

 

sub r0,vy

 

sharq #SCL,vy

 

move dx,vz

 

imult uy,vz

 

move dy,r0

 

imult ux,r0

 

sub r0,vz

 

sharq #SCL,vz

 

 

 

; re-cross product lookat & right

 

move dy,ux

 

imult vz,ux

 

move dz,r0

 

imult vy,r0

 

sub r0,ux

 

sharq #SCL,ux

 

move dz,uy

 

imult vx,uy

 

move dx,r0

 

imult vz,r0

 

sub r0,uy

 

sharq #SCL,uy

 

move dx,uz

 

imult vy,uz

 

move dy,r0

 

imult vx,r0

 

sub r0,uz

 

sharq #SCL,uz

 

 

 

; store (part of) the matrix

 

; we store only the 3*3 matrix (normalized(.14 values))

 

movei #cmat,r14

 

store vx,(r14)

 

store vy,(r14+1)

 

store vz,(r14+2)

 

store ux,(r14+4)

 

store uy,(r14+5)

 

store uz,(r14+6)

 

store dx,(r14+8)

 

store dy,(r14+9)

 

store dz,(r14+10)

 

; then we compute the 4th column (not normalized)

 

; must be added to results of MMULT 'by hand'

 

; translation values can overflow the 1.14 scheme.

 

;( T max=+/-32767 )

 

imultn vx,tx

 

imacn vy,ty

 

imacn vz,tz

 

resmac r0

 

sharq #SCL,r0

 

store r0,(r14+3)

 

imultn ux,tx

 

imacn uy,ty

 

imacn uz,tz

 

resmac r0

 

sharq #SCL,r0

 

store r0,(r14+7)

 

imultn dx,tx

 

imacn dy,ty

 

imacn dz,tz

 

resmac r0

 

sharq #SCL,r0

 

store r0,(r14+11)

 

 

 

RET

 

 

C'est plutôt foireux mathématiquement parlant, mais ça fonctionne à peu près.

 

Juste pour avoir une idée quoi !

Share this post


Link to post
Share on other sites
GT Turbo    4

Azrael a déjà tout le nécessaire en stock, actuellement cela va etre plus le choix de la routine pour qu'elle tourne très vite sur la Jag que le problème du noyau ou autres. L'optimisation et le choix de la routine est assez a l'opposé d'un 68000

 

 

 

GT En train de discuter avec Azrael ;)

Share this post


Link to post
Share on other sites
Azrael    0

Bah, euh, oui et non, j'ai pas non plus envie de réinventer le fil a couper le beurre, donc si la theorie est la je suis preneur aussi :) Creer un moteur 3D gerant les faces cachees par exemple c'est pas de refus.

Share this post


Link to post
Share on other sites
GT Turbo    4
Azrael :


Bah, euh, oui et non, j'ai pas non plus envie de réinventer le fil a couper le beurre, donc si la theorie est la je suis preneur aussi :) Creer un moteur 3D gerant les faces cachees par exemple c'est pas de refus.





Tu fais comme tu veux t'est assez grand ;) Moi j'ai trouvé ma routine qui me va bien !!





GT Heureux :yes:

Share this post


Link to post
Share on other sites
Azrael    0

Ouais, ben je suis incapable de te dire a quoi correspondent tous les parametres, pas envie de me replonger dans du code non commente qui date d'il y a 10 ans ou j'avais un niveau math prepubere.

Share this post


Link to post
Share on other sites
Azrael    0

CTS, au lieu de faire un trois MMULT il n'est pas plus judicieux de faire trois (IMULTN, IMACN, IMACN et RESMAC) ? En oubliant bien sur les translations.

 

 

 

Je vois aussi que tu as un calcul de racine carree, tu utilises quelle sorte de routine ? Pour ma part je fais une table de precalcul.

Share this post


Link to post
Share on other sites
Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×