Guida struttura file .prm

In questa zona vengono raccolte le discussioni che riguardano lo sviluppo di nuovi progetti per ARM e per Re-Volt

Moderatore: Michelangelo

Rispondi
Maximvs
Messaggi: 402
Iscritto il: sab 14 giu 2008, 11:27

Guida struttura file .prm

Messaggio da Maximvs » dom 28 lug 2013, 10:38

Guida della struttura dei file .prm
Bene ho voluto scrivere questa piccola guida per tutti quelli che vogliono sapere come sono strutturati o come si
può strutturare un file .prm, adesso prendiamo come esempio il file Body.prm (è una piramide), se noi apriamo il
file troveremo tanti byte, che per ora sono senza senso, ma incominciamo a dare un senso a tutti i byte.
Apriamo il file in questione:

08000F00000000000200000001000000
FFFFFF00FFFFFF00FFFFFF00FFFFFF00
E5A6DF3E940EBFBF000EE0B8940EBFBF
001AE0B8582187BF0000000000000000
000000000500030004000000FFFFFF00
FFFFFF00FFFFFF00FFFFFF005F7EF6BF
D253603F5F7EF6BF00E91E3B2691BEBF
D253603F000000000000000000000000
0100000006000000FFFFFF00FFFFFF00
FFFFFF00FFFFFF00001AE0B8582187BF
000EE0B8940EBFBFEEC2DFBE940EBFBF
00000000000000000000000007000300
05000000FFFFFF00FFFFFF00FFFFFF00
FFFFFF00CE3517C0D253603F5F7EF6BF
00E91E3B5F7EF6BFD253603F00000000
00000000000000000600000008000000
FFFFFF00FFFFFF00FFFFFF00FFFFFF00
EEC2DFBE940EBFBF000EE0B8940EBFBF
000AE0B8CEFBF6BF0000000000000000
000000000B0009000A000000FFFFFF00
FFFFFF00FFFFFF00FFFFFF00E07B863E
C586033FE07B863E2871753F3086203D
2871753F000000000000000000000000
0800000002000000FFFFFF00FFFFFF00
FFFFFF00FFFFFF00000AE0B8CEFBF6BF
000EE0B8940EBFBFE5A6DF3E940EBFBF
0000000000000000000000000E000C00
0D000000FFFFFF00FFFFFF00FFFFFF00
FFFFFF00F4E6F83EC5B7753FE07B863E
AE4C033FE07B863EC5B7753F00000000
00000000F00A2F3B68F94FBB00B664BD
0FF5D0C49706B044FF499B4250142F3B
68F94FBBA1E02D41AFEBD0C49706B044
5E1FD2BE63BA2EC168F94FBB00B664BD
9C45D13E9706B044FF499B42F00A2F3B
D6CBAEC100B664BD0FF5D0C42934513E
FF499B4263BA2EC168F94FBB00B664BD
9C45D13E9706B044FF499B4250142F3B
68F94FBBA1E02D41AFEBD0C49706B044
5E1FD2BE4AD02E4168F94FBBC8B664BD
B52FD1BE9706B04437499B424AD02E41
68F94FBBC8B664BDB52FD1BE9706B044
37499B42D0072F3B68F94FBB0CAA2FC1
2FF8D0C49706B044F355D03EF00A2F3B
D6CBAEC100B664BD0FF5D0C42934513E
FF499B424AD02E4168F94FBBC8B664BD
B52FD1BE9706B04437499B42D0072F3B
68F94FBB0CAA2FC12FF8D0C49706B044
F355D03EF00A2F3BD6CBAEC100B664BD
0FF5D0C42934513EFF499B42D0072F3B
68F94FBB0CAA2FC12FF8D0C49706B044
F355D03E63BA2EC168F94FBB00B664BD
9C45D13E9706B044FF499B4263

notiamo subito una cosa familiare il file incomincia con 2 byte 0800 seguiti da altri due byte 0F00, bene la prima
serie di byte non è altro che il numeo di poligoni o facce, mentre la seconda è il numero di vertici quindi calcolatrice alla mano 0800=8 poligoni e 0F00 = 15 vertici, troviamo 4 byte a zero ( questi byte tralasciamoli, o meglio sarebbe porli sempre a zero) subito dopo troviamo 0200;0000;0100 cosa vorranno dire? Sono il numero dei
vertici che compongono il poligono 0 (V2,V0,V1) bene adesso troviamo 12 byte FF:FF:FF:00 per 3 volte cosa sarà?
Niente altro che il colore B=FF=255:G=FF=255:R=FF=255 Alfa=0 questi 4 byte sono ripetuti 3 volte, per i tre vertici (V2,V0,V1) che compongono il pioligono 0 subito dopo troviamo altri 4 byte identici ai precedenti FF:FF:FF:0
(Re-Volt non li usa anche se li ponete tutti e 4 a zero non succede niente è il colore del poligono).
Adesso arriva il bello ora troviamo 24 byte che non sono altro che le cordinate UV della mappatura del poligono 0 composto dai 3 vertici V2,V0,V1 quindi troviamo V2 cordinata U=E5A6DF3E=0.43682018 essendo un valore di tipo float con virgola, poi troviamo V2 V=940EBFBF=-1.4926324 e così via sia per V0.U,V0.V,V1.U,V1.V adesso troviamo 8 byte a zero è poi si ricomincia per per i rimanenti 7 poligoni.

Adesso ci troviamo in questo punto del file con altri byte che vorranno dire??

F00A2F3B68F94FBB00B664BD
0FF5D0C49706B044FF499B4250142F3B
68F94FBBA1E02D41AFEBD0C49706B044
5E1FD2BE63BA2EC168F94FBB00B664BD
9C45D13E9706B044FF499B42F00A2F3B
D6CBAEC100B664BD0FF5D0C42934513E
FF499B4263BA2EC168F94FBB00B664BD
9C45D13E9706B044FF499B4250142F3B
68F94FBBA1E02D41AFEBD0C49706B044
5E1FD2BE4AD02E4168F94FBBC8B664BD
B52FD1BE9706B04437499B424AD02E41
68F94FBBC8B664BDB52FD1BE9706B044
37499B42D0072F3B68F94FBB0CAA2FC1
2FF8D0C49706B044F355D03EF00A2F3B
D6CBAEC100B664BD0FF5D0C42934513E
FF499B424AD02E4168F94FBBC8B664BD
B52FD1BE9706B04437499B42D0072F3B
68F94FBB0CAA2FC12FF8D0C49706B044
F355D03EF00A2F3BD6CBAEC100B664BD
0FF5D0C42934513EFF499B42D0072F3B
68F94FBB0CAA2FC12FF8D0C49706B044
F355D03E63BA2EC168F94FBB00B664BD
9C45D13E9706B044FF499B4263

Bene sveliamo l'arcadipo F00A2F3B,68F94FBB,00B664BD questi 12 byte a gruppi di 4 non sono altro che le cordinate X,Y,Z dei vertici chiaramente in sequenza dal vertice 0 al vertice 15, seguiti da altri 12 byte dalle cordinate
per i riflessi delle macchine

Avatar utente
TheFactor82
Amministratore
Messaggi: 7987
Iscritto il: gio 4 mag 2006, 21:26
Località: Torino
Contatta:

Re: Guida struttura file .prm

Messaggio da TheFactor82 » mar 30 lug 2013, 15:32

Ho aggiornato il Manuale STRUTTURA FILES di Arm aggiungendo le informazioni che hai trovato Maximvs. Grazie per il tuo contributo! :appl:
My Gp's:
10 Settembre 2000: Monza - ITA (F1)
24-25 Aprile 2004: Imola - RSM (F1)
07 Ottobre 2007: Monza - ITA (WTCC)
31 Agosto 2008: Misano - ITA (MOTOGP/250/125)
05-07 Settembre 2008: Spa Francorchamps - BEL (F1)
20-22 Luglio 2012: Hockenheimring - GER (F1)
07 Settembre 2014: Monza - ITA (F1)
14 Aprile 2018: Roma - ITA (FE)

My ARM Card

Maximvs
Messaggi: 402
Iscritto il: sab 14 giu 2008, 11:27

Re: Guida struttura file .prm

Messaggio da Maximvs » mar 30 lug 2013, 15:58

Bene sono veramente contento :festa: , vedevo che nessuno rispondeva sui topic che ho pubblicato e mi chiedevo che forse non interessava... per tornare alla sezione dei file.prm ho letto un po di cose è ho visto che c'è una parte diciamo di 2 byte che fa riferimento alla strutttura dei poligoni o alla possibilità di farli vedere a specchio/traslucuido ho provato a sostituire i byte in questione con il programma che ti ho mandato del plug-in, ma non si vede la differenza chiaramente intendo sulla parte inerente alle vetture perchè per le piste l'effetto in questione si vede, come anche la parte dove c'è scritto che il byte impostato a 2 rende i poligoni grandi il doppio sulle auto non funziona la macchina è sempre uguale, più tardi provo a dare un occhiatina al file revolt.exe per vedere effettivamente se risolvo la questione così posso scrivere due righe più precise. Non so se hai provato il plug-in che ti ho mandato, il calcolo dei riflessi delle macchine l'ho cambiato rispetto a quello fatto da zmodler o dall'aclaim e puoi notare che i riflessi si notano di più, adesso vorreri implementare nel plug-in anche la possibiità di convertire da .prm a .3ds

Linkinf22
Messaggi: 1144
Iscritto il: sab 25 ago 2007, 19:07

Re: Guida struttura file .prm

Messaggio da Linkinf22 » gio 1 ago 2013, 11:27

Maximvs ha scritto:come anche la parte dove c'è scritto che il byte impostato a 2 rende i poligoni grandi il doppio sulle auto non funziona la macchina è sempre uguale
Questo lo avevo già fatto notare io in un post del MIB e so anche il motivo per cui l' auto "è sempre uguale":
Quel tutorial è stato tradotto da un tutorial in inglese, dove in quella parte viene scritto che il poligono è "double sided" (e non "double sized") che significa che il poligono è a "doppia faccia" (e non "grande il doppio").

In pratica, non so se sapete cosa sia il Backface Culling (forse chi ha a che fare con la modellazione 3D lo sa). Il Backface Culling è una tecnica con la quale la parte posteriore del poligono rispetto alla "telecamera" (con "telecamera" intendo il punto e la direzione dalla quale si sta osservando la scena 3D) viene ignorata durante il rendering, in quanto proprio perchè è nella parte in cui la telecamera "non la vede". Questo consente di evitare di effettuare calcoli che non servirebbero a nulla per il risultato finale del rendering.

Il Backface Culling si può anche disattivare (in generale se si sta programmando la grafica 3D, non dalle impostazioni di Revolt!).
Il Backface Culling funziona perfettamente con i modelli 3D chiusi (scatole, auto, eccetera, ad eccezione se si entra nel modello 3D stesso) in quanto la parte interna del modello 3D non ci interessa renderizzarlo e se lo facessimo sprecheremmo tempo a fare calcoli inutili.
Con i modelli 3D aperti (come ad esempio le piste) se si osserva dalla parte opposta una parte di modello 3D che solitamente non si dovrebbe osservare da quella parte, il Backface Culling fa sparire quella parte di modello 3D anche se noi in realtà la stiamo osservando.
Provate ad esempio ad entrare in Toys In The Hood con il Make It Good ed andate con l' editor al di sotto dell' asfalto: lo vedrete sparire (succede anche con le varie pareti o parti di esse). Questo avviene perchè in teoria chi sta giocando non dovrebbe mai finire al di sotto dell' asfalto o dietro una parete, quindi il Backface Culling ignora il rendering di quelle parti della pista.
Girando per la pista sempre tramite editor, potete notare invece che alcune parti delle pareti (soprattutto quelle in legno) nella parte più alta si vedono anche se osservate dalla parte opposta.
Vengono fatte vedere anche dalla parte opposta perchè se colui che sta giocando fa un salto tanto alto da vedere oltre la parete (ad esempio con un esplosione, colpito dal razzetto di un fuoco d' artificio o magari salta sulla rampa dell' auto rossa con la stella) al posto dell' altra parete vedrebbe la parte che sta dietro di essa (l' asfalto, il marciapiede, la casa etc.).
Per ovviare al problema i programmatori non hanno disattivato il Backface Culling (aumentando di molto la quantità di calcoli inutili), ma hanno semplicemente messo nei loro file dei modelli 3D quel famoso bit che indica se la faccia è "double sided". Se il bit indica che è "double sided" Revolt in runtime calcola una seconda faccia che utilizza gli stessi vertici, ma ne inverte il senso in modo da farlo vedere anche dalla parte opposta nonostante il Backface Culling.

Ho scritto un po' di fretta quindi non so quanto sono stato chiaro e quanti errori grammaticali abbia fatto. Spero che comunque il concetto si capisca.
Ultima modifica di Linkinf22 il gio 1 ago 2013, 11:31, modificato 1 volta in totale.
Ai creatori di piste ed auto potrebbe interessare il progetto MIB, c'è il topic nella sezione "Sviluppo" del forum.


Maximvs
Messaggi: 402
Iscritto il: sab 14 giu 2008, 11:27

Re: Guida struttura file .prm

Messaggio da Maximvs » gio 1 ago 2013, 12:41

Si infatti mi sono reso conto ed è come hai detto, grazie Link. Speriamo allora che TheFactor corregga anche nella sezione tutorial dove vi era scritto quella cosa della grandezza doppia, ho verificato che vi è un bit che più in la commenterò che aumenta la luminosità della macchina, adesso non ricordo quale sia...
Ultima modifica di Maximvs il gio 1 ago 2013, 12:42, modificato 1 volta in totale.

Rispondi

Chi c’è in linea

Visitano il forum: Nessuno e 7 ospiti