gen 11
18
I segreti dell’oggetto Matrix
In questo articolo, descrivero' uno degli oggetti piu' usati da chiunque programmi con XNA e directx in generale, le Matrix.
In realtà l'oggetto matrix si compone di alcune prorprietà che sono davvero utili, ma che a parer mio, non sempre sono cosi ben spiegati, in particolare mi riferisco ai vettori che sono appunto esposti dalla classe Matrix e che trove istanziando uno qualsiasi dei suoi oggetti.
Creando un oggetto di tipo Matrix per esempio
Matrix m = Matrix.CreateTranslation(new Vector3(10,10,10));
potremo indagare all'interno dell'ogetto m appena creato e vedere che espone una serie di vettori appunto top,down,left,right,bottom,forward, questi vettori sono davvero utili a patto di capire a cosa servano.
Come sapete un matrix puo' essere il risultato di vari calcoli e la matrice finale (ossia il nostro oggetto matrix finale), è il risultato che determina la posizione,scalatura,rotazione del nostro modello nel world space 3D.
Qundi per esempio quello sotto potrebbe essere un sistema per calcolare la posizione scalatura,rotazione di un modello in maniera coretta ed avere una matrix di ritorno che determina appunto la matrice da applicare al WorldSpace per quel modello
Vector3 Posizione = new Vector3(10,10,10);
Vector3 Rotazione = new Vector3(0,0,0);
Vector3 Scalatura = new Vector3(1,1,1); //1= non scalato
Matrix World = Matrix.CreateScale(Scalatura)*Matrix.CreateFromYawPitchAndRoll(Rotazione)*Matrix.CreateTranslation(Posizione);
Bene supponiamo ora che il nostro oggetto sia posizionato nel mondo 3D tramite la World creata, come in tutti i giochi che si rispettino uno dei nostri scopi principali sarebbe quello di poter far avanzare in una direzione o nell'altra il nostro oggetto semplicemente premendo per esempio la freccia su o giù, e vorremmo che questo avanzasse nella corretta direzione in cui è ruotato.
Se dovessimo fare cio' ricalcolando in continuazione la rotazione, sovremmo sobbarcarci un bel po di lavoro matematico, invece ci viene in aiuto il nostro oggetto matrix risultante che appunto come dicevo espone i vettori che ci permettono di dirigerci in una delle direzioni che saranno già orientate rispetto alla matrice.
Per capirci meglio vogli andare avanti o indietro? basta fare cosi
World *= Matrix.CreateTranslation(World.Forward*1000);
quindi come vedete calcolare un sola volta la matrix e poi spostarsi nelle varie direzioni sarà un gioco da ragazzi usando i vettori della matrice, se associamo lo spostamento forward o bottom ad una delle frecce ci sposteremo sempre in quella direzione indipendentemente dalla rotazione risultante della matrix provare per credere 
nov 10
16
File FBX
FBX una sigla che oramai è sinonimo di interscambio nel mondo CG, ed è anche il formato utilizzato in XNA e di conseguenza nel tengine.
Pero’ non sono tutte rose e fiori, chi infatti si è cimentato con i vari tool di grafica in commercio si è ben presto accorto che non tutti esportano bene e nello stesso modo questo formato, che peraltro è comunque molto articolato al suo interno.
Con il mio team stiamo in questi giorni mettendo a punto un sistema che permette di risolvere uno dei problemi che affliggono i file FBX, e cioè il fatto che normalmente quando si integra una texture molti exporter inseriscono invece di un path relativo un path assoluto, con il risultato che xna non riesce a caricare il modello in maniera corretta, infatti lancia un eccezione in fase di compilazione poichè non riesce ad individuare il path.
Nel nuovo TEditor è presente un tools che si occupa di rimuovere il path delle texture lasciando invariata la mappatura UV, di conseguenza XNA riesce a compilare e potrete usufruire dei modelli in modo da inserire voi da codice o dal tengine la vostra texture.
In pratica nel dettaglio è sufficente esportare il file in formato testo, al suo interno (conoscendo l’estensione della texture da cercare), si cercano tutte le stringhe tra doppi apici che finiscono con l’estenzione desiderata, per esempio il tengine cerca .jpg,.png.tga.bmp.psg.tif e cancella la stringa in modo da rendere neutro il modello mantenendo pero’ la mappatura UV.
Naturalmente potete anche farlo a mano avrete lo stesso risultato.
ott 10
8
XNA Fast Test
Oggi ho effettuato alcuni test su alcune strutture base c#, in particolare mi sono concentrato sulle collezioni.
Il tengine fonda il suo funzionamento su una struttra chiamata modello, che contiene tutti i dati necessari al render nel momento in cui deve disegnare un oggetto.
Questa struttura è il mattone base della lista che viene data in pasto al motore di render.
Volevo capire quale è il sistema più veloce per processare questa lista e mi sono reso conto che effettivamente le list non sono poi cosi prestanti , il test che ho effettuato è stato quello di creare una struttura di base:
public struct Modello
{
public float valore {get;set;}
}
dentro al namespace del mio test, e quindi ho usato questa struttura dentro al progetto xna creando prima una lista e poi un array tra le var globali del progetto
List<Modello> lista = new List<Modello>();
Modello[] arrayes;
dentro al metodo initialize del progetto xna li ho valorizzati
for(int i=0;i<1000000;i++)
{
Modello m = new Modello();
m.valore = i;
lista.Add(m);
}
arrayes = lista.ToArray();
Come si vede dal codice sopra, ho creato un array direttamente dalla lista, cosi adesso ho una lista con un milione di struture ma anche un milione di strutture come array.
A questo punto inserendo nel progetto un contatore di FPS ho messo questo codice nella sezione update del progetto xna
for(int i=0;i<1000000;i++)
{
Modello m = lista[i];
m.Valore = i+0.1f;
list[i]=m;
}
Quindi ad ogni passaggio prelevo e aggiorno ogni elemento della lista…
Sul mio pc questa operazione produce un FPS di circa 15..
Ho fatto poi la stessa cosa su arrays
for(int i=0;i<1000000;i++)
{
Modello m = arryes[i];
m.Valore = i+0.1f;
arrayes[i]=m;
}
Risultato?…
Gli array danno ben 28 FPS…
Praticamente il Doppio ella velocità…
Poi ho fatto una altro semplice test
al posto del for…
foreach (Modello m in arrayes)
{
}
Il ciclo non fa nulla, ma provate a farlo girare…..
Come risultato dei test capiamo che scrivere in un modo o in un altro non è la stessa cosa quando si parla di prestazioni alla prossima….
set 10
20
Un Raggio di Luce…
Finalmente dopo diverso tempo, sono riuscito a far funzionare bene l’effetto Ray Light (o GOD RAYS come lo chiamano in molti..), è indubbiamente un effetto che cambia completamente la percezione della scena da parte dell’occhio, infatti nei miei test attivando o disattivando l’effetto nel teditor la scena cambia in maniera incredibilie.
C’e’ da dire che il Radial Blur (effetto originale) è sicuramente un buon sistema per creare i Ray Light, ma se non ben implementato è talmente peso da rendere praticamente impossibile il suo utilizzo, specialmente sotto XNA..
In questo articolo oltre a descrivere come funziona il Ray dentro al teditor, tentero di spiegare come l’ho realizzato e quali sono i passaggi fondamentali per poterlo riprodurre.
Come prima cosa leggetevi la sezione che tratta il post processo Radial Blur della guida HLSL (il link lo trovate sul portale del tengine), di Koder4Fun, ottima guida..
In poche parole il Radial Blur è un sistema per effettuare uno zoom di un immagine eseguendoci sopra anche un fader sul canale alpha, lungo una retta, che va dalla Telecamera ad un punto preciso nello schermo..
Facciamo un esempio chiarificatore, abbiamo un immagine, per esempio un fondo bianco con una palla nera al centro..
Se applichiamo l’effetto radial blur a questa immagine vedremo la sfera che aumenta di dimenzioni, man mano che aumenta il suo canale alpha diminuisce, percui nell’immagine finale vediamo una strisciata nera sempre più sfuocata andare in una qualche direzione (dipende appunto dalla retta di sfocatura risultante).
Ora detto così sembra impossibile che si riesca ad ottenere l’effetto Ray, eppure la base è questa…
Adesso cerchiamo di capire come implementare nel codice questa soluzione, prelevate il codice dal portale di Koder come lui lo propone, e create con questo un file FX.
Il primo passaggio che dovrete fare è un Render su Texture, cancellate il device con un colore a vostra scelta (che sarà alla fine il colore dei raggi solari…), su questa texture dovete disegnare i modelli del solo colore nero, quindi come tutta una serie di modelli 3d completamente neri…
Il primo passo è fatto..
Ora dovrete applicare l’effetto su quella texture in modo da ottenere la sfocatura radiale, provate a giocare con i vari parametri del codice di Koder per ottenere l’effetto milgiore..
Quindi su una nuova texture disegnate i modelli normalmente, con luci, ombre e quant’altro vi serva..
Alla fine dovrete creare un effetto combinato che esegua una funzione di Lerp tra le due texture…
Per alleggerire l’effetto Radial Blur, si deve diminuire i suoi sample (che nel codice porposto sono 128) ed abbassarli drasticamente (io per esempio ne ho messi 32), l’effetto risulta molto più veloce, ma vedrete una scalettatura prodotta dai meno samples per ciclo, per eliminarla è sufficente effettuare una filtratura gaussiana sulle assi X e Y nella texture che avete usato per il Radial Blur, ossia la prima texture, prima di effettuare la somma finale..
Un po complesso come effetto.. ma i risultati impressionanti costano sempre molto sudore…
Per aiutravi potete fare pratica con il nuovo TEditor (che rilascerò a breve v 1.02), nel quale potete giocare con i vari parametri per capirne l’uso, nel tengie tuttavia è stato aggiunto a questo effetto un estrattore HDR che permette di amplificare o diminuire la differenza che esiste tra colori chiari e colori scuri, con parametri regolabili, così da poter esaltare al meglio le varie colorazioni in gioco, molti dei parametri nel tengine sono gestiti dall’IA ambientale percui non ve ne dovrete preoccupare nel vostro gioco, sarà il motore a seconda dell’orario e della posizione del sole nello skydome ad impostare i paramentri per voi in realtime
Per fare i vostri test tuttavia, dovrete disattivare IA ambientale e settare a manina i parametri dell’effetto per vederne i risultati e capire a cosa servono., nel TEditor potrete inoltre attivare la visione della texture per il primo passo dell’effetto per capire come lavora (Menù PProcess/ShowPass)..
Ma vediamo un po di codice per capire meglio…
continua….
set 10
17
TEditor III – Lighting System
Oggi parlero’ del sistema di illuminazione presente nel tengine, e di come si possa manipolare attraverso il teditor3.
Il tengine supporta per ogni scena fino a 24 luci più quella del sole, tuttavia trattandosi di un sistema di lighting multipass, ogni 12 luci abbiamo un passaggio di render in piu’ che sicuramente diminuisce il framerate.
Quindi se consideriamo il sole, le luci che possiamo inserire senza praticamente perdere nessun fps sono 12.
Quando si apre una scena nuova, viene subito creata una luce di default (che non è il sole), per vedere la sua posizione possiamo usare la funzione del teditor showlightindicator, che troviamo nel menu settings.
Un modello romboidale ci indicherà la posizione della fonte di illuminazione, per precisione la luce 0
Possiamo modificare alcuni sui parametri come il raggio di influenza ed il colore emesso, e possiamo spostarla con i tasti frecce + pagUP e pagDown, quando non siamo agganciati al render.
Per aggiungere una fonte luminosa, dal menu tools del teditor si sceglie AddLIght, il numeratore delle fonti luminose incrementa e si vedrà comparire un nuovo modello romboidale che ne indica la posizione (di norma si avvia vicino all’ultima luce inserita).
In quanto al numeratore del range c’e’ da fare una precisazione, i numeri che vanno da 1 al 25 circa sono numeri che influenzano l’ambiente in maniera globale, e quindi come fa il sole..
Mentre se andiamo oltre avremo un influenza che parte dalla fonte luminosa e si irradia normalmente a tutti gli oggetti.
set 10
16
TEditor III – I Materiali
In questo articolo, cercherò di spiegare come usare attribuire un materiale ad un modello, ed inserire questo nella lista materiali predefinita del teditor.
Come prima cosa teniamo a mente che un materiale è composto da:
Texture Diffuse
Texture Normal
Texture Specular
Texture Emissiva
Texture Cubica Reflective
floatX (ripetizione asse X)
floatY (ripetizione asse Y)
float SpecPower (Potenza Fattore Speculare)
float RefPower (Potenza Fattore Riflettente)
Colore Diffuso
Colore Ambientale
Colore Speculare
Colore Emissivo
Colore Riflettente
Non è ovviamente necessario settare tutti i parametri per ogni materiale, teniamo infatti presente che per esempio un materiale normale non avrà la texture cubica per riflettere e nemmeno se volgiamo al texutre speculare, al contrario per i materiali che non appartengono ad un modello alpha (texture) io consiglio di settare i mariali almeno con
Texuture Colore
Texture Normal
Texure Emissive
più i rispettivi colori, in quanto ai colori c’e’ da dire che il colore Ambientale è totalmente comandato dal sole e quindi non controllabile direttamente dall’utente, mentre lo sono gli altri.
Cerchiamo di capire ora come e quando intervengono i vari parametri e a cosa servono..
La texure diffusa è la texture del colore, senza di essa il materiale non esiste..
La texture Normal è la texture che serve a calcolare il bump del materiale, ma ha una sua influenza anche sul calcolo della luce che investe il materiale, infatti se illuminate un modello che contiene un materiale con Normal settata vedrete la differenza rispetto ad uno che non ha la texture normal.
La texture Specular è la texture che si occupa di distribuire i riflessi speculari che si possono vedere o meno in base alla posizione del sole/modello/telecamera, senza questa texture il canale speculare non sarà calcolato e non sarà visibile nessun colore speculare indipendentemente dal colore speculare scelto.
La quantità di luce riflessa è data dall valore SpecPower, al contrario del valore potenza riflessiva pero’, il valore specPower aumenta con il diminuire del valore, percui la massima potenza speculare si ha impostando ad 1 tale valore, di norma dai 1000 ai 3000 è un range in cui rientrano quasi tutti i materiali.
La texture Emissiva è la texture del colore emesso, normalmente il colore emesso si somma al colore diffuso anche se in maniera più lieve, ma diventa prepotentemente forte man mano che il sole cala, quindi se per esempio settiamo la texture diffusa e gli diamo un colore blu, quando il sole cala vedremo il materiale virare verso il colore blu, in ogni modo il colore del materiale è sempre un equilibirio tra colore diffuso/Ambientale/emissivo.
La texture cubica è la texture che riflette l’abiente, per questo si richede che sia una CubeTexture di tipo .dds, norlmalmente quando si setta questa si imposta il suo colore a bianco o cmq molto chiaro per far ben risaltare la riflessione, e si aumenta di un valore accettabile (fate delle prove caso per caso), il paramentro della potenza riflessiva.
i float della ripetizione sono appunto quante volte la texture viene ripetuta nei due assi X e Y.
Ricordatevi infine che per ogni texture c’e’ anche da regolare il suo colore altrimenti l’effetto non risulta completo e a volte come la texture riflessiva, se non si setta il colore e lo si lascia a 0 non vedremo proprio il riflesso.
Dopo queste prime considerazioni carichiamo un modello, come sapete nel treeview a lato appare la lista dei modelli contenuti nel file caricato, espandiamone uno e troviamo le proprietà sopra descrtte, queste definiscono il materiale di cui è composto il modello.
Se facciamo doppio click su di una texture potremo caricare e compilare al volo file bmp,jpg,png,dds,xnb, ma possiamo (se sappiamo averla gia compilata) cliccare con il dx del mouse e scegliere di caricare dalla lista dei modelli compilati(prima voce menu’), si aprirà cosi una finestra che ci farà anche un anteprima dei materiali già compilati, per selezionarlo basta cliccarlo e chiudere la finestra di anteprima.
Una volta settate tutte le proprietà del materiale (provate ad effettuare cicli giorno notte per vedere come si comporta nei vari stati della giornata), possiamo salvare il materiale nella lista dei materiali, semplicemente selezionando il modello nel treeview e nel solito menu che si apre con il dx del mouse scegliere SaveMaterial.
Se guardate la lista dei materiali a lato SX in basso, vedrete il nome del materiale (che è ripreso dal nome della texture colore che lo rappresenta), adesso lo avrete sempre presente e disponibile quando caricate il teditor questo ci sarà già e lo potrete usare per altri modelli.. come fare?
semplice caricate un modello, selezionate uno dal treeview e dopo, doppio click sul nome del materiale
vedrete il modello assumere il materiale salvato.
I Materiali possono essere esportati, click con il dx sulla lista materiali e scegliere export, il teditor crea un archivio che è possibile scambiare con altri utenti oppure mettere da parte per scopi futuri.
set 10
15
XNA Compilazione Texture
Le texture si sa sono uno dei punti dolenti, quando si parla di pipeline di rendering, infatti il processing delle texture è da sempre uno dei punti piu caldi quando si parla di prestazioni.
Dato che XNA e .NET non sono ancora (e forse non lo saranno mai) alla portata dei motori c++, diventa evidente quanto sia importante prestare la massima attenzione a tutti quei fattori che possono influenzare negativamente la nostra pipeline di render.
In questo articolo vorrei cercare di documentare la sezione di compilazione che xna ci mette a disposizione per le texture e cosa implica la scelta di un tipo piuttosto che un altro, per sezione di compilazione.
Quando trasciniamo un asset di tipo immagine (bmp,jpg,png,etc…) dentro al Content, e clicchiamo con il dx del mouse sopra di esso scelgiendo proprietà, si apre una scheda nel vstudio che ci indica le varie caratteristiche dell asset, tra le quali troviamo la voce ContentProcessor che normalmente è settato a Texture – XNA Framework.
Se espandiamo (tramite la crocetta) l’albero del ContentProcessor possiamo regolare alcuni dei suoi parametri, il significato di questi parametri è molto importante per le prestazioni del nostro gioco…
I parametri che ci interessano particolarmente sono:
GenerateMipsMaps
Texture Format
Il primo parametro ci permette di creare diversi livelli di texture uno per ogni livello di MipMap della scena, per chi non conoscesse il mipmap in due parole posso dirvi che si tratta di un ridimensionamento della texture man mano che questa si allontana dalla telecamera, quindi quando le texture sono tutte lontane dalla camera avremo una risoluzione per queste molto bassa, al contrario mentre queste si avvicinano alla camera la risoluzione aumenta fino ad arrivare a quella originale.
Questo comportamento come è facile intuire porta degli enormi benefici in termini prestazionali, specialmente la dove il numero di texture passato è molto alto.
A noi basta attivare questo parametro e XNA farà tutto il resto.
La seconda opzione permette di specificare il tipo di superfice per la texture da compialre, la texture di tipo Colore è sicuramente una texture con qualità superiori a quella DTXCompressed, ma è anche molto piu’ pesa quando la passiamo al render, al contrario una texture di tipo DtxCompressed risulterà molto più leggera durante il rendering, ed è sicuramente da preferire in quelle scene dove il numero di texture da randerizzare è molto elevato.
Settando bene questi due paramentri possiamo con una semplice operazione ottenere ottimi miglioramenti di performance nei nostri giochi con xna senza nessuno sforzo.
Unico neo del formato DtxCompressed è che un eventuale algoritmo di decompilazione (quegli usati per riportare asset da xnb ad immagine), non sarà in grado di funzionare perchè i dati dell’immagine vengono appunto compressi.
Un altro parametro che può essere utile (ma non sempre) è Resize to power of Two che serve per far si che la texture compilata assuma una dimenzione che sia nel range delle potenze di 2
4,8,16,32,64,128,256,512 etc…
Questo parametro è utile quando la texture non è ben dimensionata, infatti molte schede video richiedono che le dimensioni delle texture siano fissate su potenze di 2, tuttavia io consiglio di dimensionare la texture in manuale e metterla nel progetto già dimensionata correttamente in modo da essere sicuri che la nostra texture non venga scalata eccessivamente già al primo livello di MipMapping, per capirci, supponiamo di creare una texture nn so 500×500, se attiviamo l’opzione la prima texture che vedremo sarà di 256×256, ed il risultato nel render sarà ovviamente molto più scadente.. meglio passare direttamente una 512×512 così che nessun ridimensionamento modifichi la qualita che abbiamo deciso per questa texture.
set 10
14
TEditor III – Geometry
Il Teditor è da sempre strumento indispensabile per creare giochi e applicazioni multimediali con tengine, la versione 3 ha raggiunto un livello di stabilità e velocità di esecuzione notevoli se si pensa che è tutto scritto attraverso una tecnologia di alto livello come xna.
In questo articolo voglio descrivere nel dettaglio il sistema di movimento che viene usato per comandare le geometrie nel teditor, pochè spesso le questioni che mi vengono poste sono, come muovo, come scalo un oggetto e cosi via..
Dunque prendiamo in esame l’interfaccia del TEditorIII. vediamo che nella sua parte inferiore esiste una lista che si popola man mano che carichiamo modelli, a fianco ci sono dei pulsanti X-Y-Z e a fianco dei pulsanti che rappresentano l’azione Posizione/Ruotazione/Scalatura.
Per agire su di una geometria (ossia su tutti i modelli che sono raggruppati in un file FBX caricato), si deve selezionare questo dalla lista dei modelli, poi premere l’azione che si desidera compiere (il pulsante si illumina di Rosso), e quindi l’asse su cui si desidera agire.
Ci sono due modi per comandare l’azione, il primo è spostare il mouse da destra a sinistra (o viceversa) nel riquadro di rendering, quando non siamo agganciati al render (anche perchè quando siamo agganciati il mouse non si muove), mentre l’altro modo è con i tasti del NUMPAD, se usiamo i tasti del NUMPAD non è necessario usare il pulsante delle assi perchè il tutto avviene tramite i tasti 8426 assi X e Z e 93 asse Y.
Il numeratore Incremento indica di quante unità stiamo spostando/scalando/ruotando il modello, in modo da poter regolare la strumentazione per ottenere posizionamenti su grandi distanze o di fino.
La scalatura ha una possibilità in più, infatti tramite il numeratore che si trovva sotto il pulsante delle assi Z, è possibile scalare di una certa quantità il modello selezionato, ma il tutto fatto uniformemente rispetto alla sua dimensione originale.
Vi consiglio comunque di salvare spesso la scena poichè il teditor non dispone ancora (e non so se e quando lo avrà) di un sistema di Undo/Redo, il salvataggio della scena vi permette di tornare ad uno stato precedente.
Un altra funzione molto importante è l’equalizzatore di scalatura, che trovate nel menu dei modelli (click DX sulla lista modelli), sotto la voce EqualizeScale.
La principale funzione di questo è quella di portare la scalatura di due modelli alle medesime misure, per capire a cosa serve faccio un esempio..
Abbiamo un modello FBX di un tronco di albero, e poi ne abbiamo un secondo che rappresenta per esempio il fogliame, carichiamo il primo modello, lo portiamo a scalatura che sia congruente con la scena e poi carichiamo il secondo modello, a questo punto senza una funzione come EqualizeScale, dovremmo scalare il secondo modello a mano, crecando di essere quanto piu precisi possibile, per raggiungere la scalatura del primo modello , invece con la funzione di equalizzazione della scalatura possiamo semplicemente, selezionare il primo modello (quello già a misura), e settarlo come MASTER, quindi selezionare il modello da scalare e premre GO.
IL modello assumerà i medesimi valori di scalatura del MASTER.
set 10
14
BEPU Motore Fisico
Per il mio nuovo progetto demo da inserire nel portale del tengine, sto integrando il suddetto con il motore fisico bepu, questo e altri articoli sono una specie di diario di sviluppo che mi, e spero vi, aiuteranno a capire il motore fisico ed il suo utilizzo.
La documentazione delle BEPU è abbastanza curata, ci sono esempi per iniziare che fanno capire chiaramente quanto sia semplice usare le bepu, tuttavia ci sono alcune funzioni che non sono sempre cosi chiare.
Come primo argomento vorrei affrontare il problema che si pone quando dobbiamo rilevare la collisione tra due oggetti fisici, dato che dobbiamo gestire la collisione nel codice (e quindi per esempio far si che si crei une esplosione o altro quando due specifici oggetti si toccano), dovremo essere in grado di capire quali oggetti si stanno toccando.
Le BEPU ci offrono un modo molto comodo per rilevare la collisione tra due oggetti fisici, un sistema asincrono formato da delegati che intervengono quando un oggetto collide con un altro, ciò che dobbiamo fare noi è solamente creare un metodo con la firma corretta e gestire l’oggetto ritornato dal delegato nella corretta maniera.
Vediamo quindi un esempio, supponiamo che il nostro corpo fisico(prendiamo per esempio una sfera ed un cubo) siano due dei nostri oggetti che per esempio possono essere implementati tramite i seguenti costruttori:
BEPUphysics.Entities.Sphere Sfera = new BEPUphysics.Entities.Sphere(new Vector3(10,10,10), 14, 3f);
BEPUphysics.Entities.Box cubo = new BEPUphysics.Entities.Box(new Vector3(10,10,10), 37, 20, 37, 1);
naturalmente gli oggetti una volta creati vanno aggiunti al gestore della fisica chiamato nelle bepu space (vedere documentazione del portale BEPU per i dettagli di come implementare lo space)
Bene il nostro intento è quello di rilevare la collisione tra i due oggetti, per fare questo dotiamo l’oggetto sfera di un delegato che scatterà quando l’oggetto collide con un altro oggetto (che sia il cubo o no)
sfera.EventManager.CreatingCollisionPair += new BEPUphysics.Events.CreatingCollisionPairEventHandler(Collisione);
Ovviamente dichiarare un delegato di questo tipo implica che dovremo aver creato un metodo con la corretta firma e nel nostro caso con nome Collisione
private void Collisione(BEPUphysics.Entities.Entity A, BEPUphysics.Entities.Entity B, BEPUphysics.CollisionPair pair)
{
}
Per il momento il nostro metodo non fa un bel niente..
Notiamo pero’ che la firma del delegato implica che ci vengono passati tra le altre cose due oggetti A e B che sono appunto i corpi fisici che collidono.
Nei miei test ho potuto rilevare che A è sempre l’oggetto a cui il delegato appartiente, percui nel nostro caso sarà la sfera..
B al contrario è l’oggetto con cui la sfera collide..
Adesso non ci resta che effettuare un controllo tramite l’operatore di uguaglianza equals così
private void Collisione(BEPUphysics.Entities.Entity A, BEPUphysics.Entities.Entity B, BEPUphysics.CollisionPair pair)
{
if(B.equals(cubo))
{
....Codice per Gestire la Collisione
}
}
Il codice funziona, abbiamo il nostro gestore di collisioni asincrono, sicuramente grazie alle BEPU possiamo implementare un robusto sistema.
Unico neo di questa soluzione è che dobbiamo mantenere un riferimento all’oggetto cubo e quindi istanziare questo come oggetto globale, c’e’ però una altra soluzione un po più ingegnosa..
Quando i corpi fisici vengono aggiunti al gestore, si crea una list che contiene pero’, solo tutti gli oggetti dinamici, in sostanza tutti gli oggetti che possono essere spostati e che risentono delle collisioni, (esistono anche oggetti non dinamici nelle BEPU che non fanno parte della lista di cui vi parlo ma sono semplicemente un buffer di vertici, e fungono da ostacoli statici), tramite questa lista possiamo ricavare l’oggetto che vi abbiamo inserito senza mantenere per questo un riferimento globale, dato che abbiamo aggiunto al mondo fisico due corpi (sfera e cubo) la lista delle BEPU interna sarà composta da due oggetti..
quindi…
private void Collisione(BEPUphysics.Entities.Entity A, BEPUphysics.Entities.Entity B, BEPUphysics.CollisionPair pair)
{
if(B.equals(space.Entities[1]))
{
....Codice per Gestire la Collisione
}
}
Ricordate che gli array partono da 0 percui 2 vale 1…
Cosi facendo (oltre ad avere un accesso più veloce all’oggetto che ci interessa), potremo anche non mantenere un riferimento in memoria al corpo fisico..
set 10
14
XNA & FPS
Oggi vorrei spiegare come si puo’ togliere il limitatore di frame ad XNA.
Nativamente XNA impone un limite al framerate di 60 FPS, sicuramente questo limite è una garanzia per il programmatore, ma a volte è utile poter testare la massima velocità raggiungibile come fps dalle nostre applicazioni xna, soprattutto quando dobbiamo verificare la bontà di qualche algoritmo di rendering o di codice hlsl.
Per poter rimuovere il blocco si devono settare alcune proprietà nel costruttore del nostro Game:
this.IsFixedTimeStep = false;
graphics.SynchronizeWithVerticalRetrace=false;
Come vedete è necessario disattivare la sincronizzazione verticale per poter vedere realmente l’effetto della rimozione blocco FPS, questo perchè altrimenti avremmo comunque un limitatore sul render dato dalla sincronizzazione video.
Non tutti sanno che comunque anche lascianto tutto attivo possiamo indicare ad xna a quale frequenza lavorare, il prametro che controlli il fixedTimeStep è il TimeSpan TargetElapsedTime infatti questo TimeSpan indica proprio a quale frequenza fissare la chiamata del metodo update, nativamente è impostato a 1/60 millisecondi, che in sostanza vuol dire se il pc è abbastanza potente chiama massimo il metodo update 60 volte al secondo quindi 60 fps.
Possiamo modificare tale valore per impostare i nostri loop preferiti, questo ci assicura che il nostro gioco sarà visualizzato sempre alla stessa velocità indipendentemente da quella reale del pc che lo esegue.
Tente presente che comunque la frequenza di render non potrà mai superare quella di aggiornamento del vostro monitor che normalmente è fissata sui 60, inoltre provare varie tarature del framerate ci fa capire come si comporta il nostro gioco quando si trova a girare su un pc non prestante, e possiamo quindi regolare le prestazioni di conseguenza.
set 10
14
TEngine III
Finalmente sono riuscito a completare la riscrittura dell’engine, il lavoro tra motore ed editor è durato circa 4 mesi, le novità che sono state introdotte sono davvero numerose, il nuovo motore lavorerà con la versione di XNA 3.1, e comprenderà un editor di materiali.
Il Motore non integra (come la sua precedente versione) un motore fisico, questo perchè mi sono reso conto che nel panorama free dei motori fisici non esiste un motore fisico che sia versatile per tutto..
Quindi meglio avere un sistema che si possa facilmente integrare con vari motori fisici, e cosi ho realizzato il nuovo TEngine (TE da ora in poi), in modo che sia facile da integrare con altri sistemi.
Gli esempi che ho in mente di rilasciare (Progetti completi) mostreranno come fare per usare i vari motori fisici insieme al TE, ecco sotto una lista delle principale feature del motore:
-Editor Visuale
-Editor Materiali
-Caricamento ed autocompilazione di modelli FBX, e Texture non compilate di tipo bmp,png,jpg,tga,dds
-24 luci omnidirezionali per scena della quali le prime 12 a costo fps irrisorio
-8 tipi di influenza del vento
-Materiali Riflettenti
-Materiali Alpha
-Water Shader
-Shadow Map
-Sky Dome con IA ambientale
-Light Shaft come post processo
-Possibilita di esportare/importare pacchetti materiali/modelli/scene
il nuovo TE sarà una sola cosa con l’editor, e come sempre il tutto è scaricabile gratuitamente dal portale del tengine una volta che vi siete registrati.
Il Tengine3 come le sue precedenti versioni è totalmente free ma non open source.
Al momento della stesura del presente articolo esiste già un progetto dimostrativo che integra il Tengine3 con il motore fisico BEPU.
set 10
14
TEngine III
Ciao sono un programmatore di 39 anni e nel tempo libero, quando non programmo per lavoro, mi diverto con la grafica 3D ed il Game Programming che è una passione fin da quando sono un bambino.
Grazie alla tecnologia XNA di Microsoft, ho scritto il mio engine 3D che oggi dopo anni di esperienza risulta essere uno dei modi piu’ facili per scrivere il proprio gioco utilizzando la suddetta tecnologia, il tengine oramai giunto alla sua terza versione, si compone di un editor 3D, e di una serie di librerie che permettono al programmatore di creare scene in maniera totalmente visuale e quindi, richiamare queste dal proprio codice.
Questo pero’ non vuol essere solo un blog dedicato al motore ma a tutto il Game Programming in generale.