XNA - Frattali

Tutto ciò è colpa di un mio professore dell'università...
E' lui che ha fatto accadere tutto ciò ?_?
Non ve la prendete con me ?_?

Seguendo il corso di Costruzione di Interfacce il nostro professore ci ha fatto vedere un'applicazione che fatto lui: si tratta di un programma che permette di calcolare e visualizzare il frattale di Mandelbrot.
Il frattale di MandelBrot è uno dei più famosi frattali (lo so dire ora, ma prima che ce lo facesse vedere lui manco sapevo chi fosse XD), e devo dire che con i frattali ci si può "divertire". Tutto ciò mi ha fatto tornare alla mente quando, da piccolo, mio padre mi fece vedere un programma per calcolare queste strane immagini, dove io potevo selezionare una parte piccola piccola, e l'immagine non "perdeva di dettaglio"... Ah beata innocenza XD

Sta di fatto che dopo aver visto questo programma fatto dal nostro professore mi sono deciso a farne uno mio. Dato che sto lavorando con XNA ho deciso di farne uno che utilizzasse XNA per calcolare e visualizzare i frattali.
Ci sto ancora lavorando, e devo implementare alcuni particolari, ma direi che il grosso è fatto.
Quindi se vi chiedete che fine ho fatto, o sono dentro un frattale(XD) o sto studiando per un esame (che voglia eh XD).

Intanto vi lascio con qualche immagine ottenuta da questo generatore di frattali che ho fatto ^_^
Spero vi piacciano :)
Quando sarà finito posterò qualcosa del codice che ho fatto!











A presto :)

Continua a leggere!

The Xna-Way: Tutorial 8: Screen Shots del nostro gioco!

Aggiornamento al 16/04/2011:
con l'aggiornamento alla versione 4 di Xna questo codice non è più funzionante, dato che alcune delle classi ed oggetti che vengono utilizzate sono state eliminate o è stato rivisto il loro funzionamento.


Quale è una cosa di cui oggi come oggi non si può fare a meno in un videogame?
Bè una delle tante è la possiibilità di salvare la schermata di gioco, di farne una foto e di conservarla, in modo da mostrare ai nostri cari amici (nerd anche loro come noi) le nostre peripezie XD
Questa cosa oltre ad essere una chicca che oramai cerchiamo in quasi ogni gioco mi tornerà utile anche per catturare schermate di gioco per i piccoli tutorial che farò.

Mi sono quindi messo di buzzo buono, e studiando degli esempi che ho trovato su Xna-club, esempi che tra l'altro trattavano effetti di post processing come bloom, e ho tirato fuori il mio piccolo componente.

L'idea su cui mi sono basato è questa: XNA ci fornisce un ciclo di esecuzione nel quale vengono invocati in continuazione i metodi Update e Draw dei components che fanno parte del nostro gioco.
Ora uno screen shot va salvato quando la scena è stata completamtente renderizzata. Quindi, ragionevolmente, dovremmo salvarla dopo che sono stati eseguiti tutti i metodi Draw dei nostri componenti.
Ma come possiamo essere sicuri o controllare questa cosa?

La cosa più semplice ed immediata da fare è capire che la scena che noi vogliamo salvare, è "completa" quando siamo nel metodo update. Cioè saremo "indietro" di un frame quando andremo a salvare l'immagine, gli oggetti non saranno stati spostati, ma nel contempo il rendering della scena non sarà ancora incominciato, e quindi avremo (da qualche parte in memoria) il render completo della scena al frame precedente!
Quello che dobbiamo fare è semplicemtente recuperarlo e salvarlo.

Ecco la classe, il component, che fa questo:
Show/Hide


Al costruttore gli viene passato il percorso della directory in cui salvare le immagini, oppure solo il riferimento alla Game, ed in questo secondo caso la directory di default per il salvataggio delle immagini è la cartella immagini dell'utente.
Come si vede si recupera anche il riferimento al servizio per l'input.

In Initialize creo un ResolveTexture2D delle stesse dimensioni e formato del backBuffer del gioco.

Nel metodo update controlliamo se il tasto Stamp (o printScree, dipende da come lo si vuole chiamare) è stato premuto.
In caso positivo tramite ResolveBackBuffer recupero il backBuffer del frame precedente (e quindi il render completo della scena precente) e lo metto in resolveTarget.
Dato che resolve target è un tipo particolare di Texture2D posso forzare con un cast il suo tipo ad essere Texture2D appunto, ed usare quindi il metodo save per salvare su disco l'immagine.

Tutto qua. Così possiamo salvare semplicemente gli screen del nostro gioco.

Nel costruttore di Game1 si deve aggiungere le seguenti righe:

screenShot = new ScreenShots(this);
Components.Add(screenShot);

ed siamo veramente alla fine!

Non allego questa volta il file con il codice, dato che la classe è piccola e completamente inserita nel post.

Spero vi sia utile.
Alla prossima!
Continua a leggere!

The Xna-Way: Tutorial 7: Collisioni con BoundingSphere

Dopo molto, troppo, tempo eccomi di nuovo qua a parlare di qualcosa inerente ad XNA.
Questa volta voglio un po' parla delle collisioni, cosa che fa impazzire ogni programmatore di Video Giochi.

Anche io sono impazzito (più di quanto non fossi prima) quando mi sono addentrato in questo campo, e devo dire che ne sono rimasto un po' spaventato.

Come si possono calcolare oggi come oggi le collisioni tra 2 oggetti?
Bè un esempio di ciò l'ho usato per calcolare quali oggetti erano intersecati dal bounding Frustum della telecamera e quindi filtrare quelli da renderizzare da quelli che non lo erano.
Questo è un esempio di collisioni fatto con i VOLUMI: ho usato un sfera (per la precisione una BoundingSphere) per approssimare il volume degli oggetti presenti nella scena (ci dovrà essere una sfera per ogni oggetto, o nel caso di oggetti replicati una sola sfera che verrà riposizionata e aggiornata per ogni oggetto di cui voglio calcolare la collisione).
Come qualcuno potrà pensare, calcolare le collisione di 2 oggetti approssimando il loro volume con delle sfere può portare a delle approssimazioni tali da avere un grosso grado di imprecisione del calcolare l'effettiva collisione tra due oggetti.
Se il nostro oggetto è una sfera allora la sua BS (abbreviazione di BoundigSphere) coinciderà esattamente con l'oggetto, ma già nel caso di un cubo esso verrà contenuto per intero all'interno della sfera, così con oggetti più complessi!
Ecco un esempio di quando ho detto:

Come possiamo vedere la navicella e il meteorite sono completamente contenuti all'interno delle loro sfere, anche se buona parte delle sfere non sono occupate dal volume del modello.

Come si fa per calcolare le collissioni? La collisione viene calcolata controllando se le due sfere si toccano o si intersecano l'una con l'altra. Ho una collisione anche se una sfera è contenuta interamente in un'altra.

XNA ci offre la classe BoundingSphere la quale è caratterizzata da una posizione e da un raggio. Le BS sono comode perchè anche se muoviamo o ruotiamo l'oggetto esso sarà sempre contenuto all'interno della stessa sfera, cosa che non accade con i BoundingBox (altro tipo di volumi per approssimazione), i quali sono dei parallelepipedi. Nel caso di una rotazione dobbiamo ricalcolare il rettangolo che contiene il nostro modello.
L'unico caso in cui dobbiamo modificare la sfera è quando scaliamo il nostro oggetto, dato che dovremo anche aumentare/diminuire il raggio della sfera.

In tutto questo tempo ho cercato a giro metodi "semplici" per il calcolo della collisione tra due oggetti nel modo più preciso possibile, cioè del tipo poligono contro poligono, vertice su poligono, etc, ma come potete immagianare con scarsi risultati.
Ho provato a farne uno di mio, ma non funzionava bene ed il calcolo era talmente peso che già per modelli a basso numero di poligoni il frame rate si abbassava enormemente.
Ho decico quindi per ora di dedicarmi a qualcosa di meno complicato e di continuare a scrivere qualcosa. Poi quando avrò maggiori conoscenze continuerò in seguito ad approfondire questo argomento.

Quello che mi sono proposto di fare è quanto segue: alla creazione del modello ho deciso di estrarre dalle informazioni la boundingSphere caricata, e di tenerla aggiornata secondo le trasformazioni dell'oggetto. Esporrò poi un metodo per permettere di controllare se due dati modelli stanno collidendo con le boundingSphere. Forse non è proprio il caso di utilizzare una classe, ma utilizzare un'interfaccia che esponga queste proprietà comuni agli oggetti di cui vogliamo controllare le collisioni.

Quello che ho fatto è stato definire la seguente interfaccia:

public interface CollisionI
{
BoundingSphere _BoundingSphere { get; }
bool CheckSPhereCollision(CollisionI obj);
}

Questa interfaccia contiene una proprietà e un metodo: la proprietà ritorna la boundingSphere relativa all'oggetto, mentre il metodo controlla se per due oggetti che implementano l'interfaccia ci sia o meno collisione.
Da notare che in questo modo non vincolo il tipo degli oggetti tra cui posso calcolare la collisione, basta che implementino l'interfaccia e posso calcoare tutto.
Certo è un poco spoglia, ma nessuno ci vieta in futuro, quando ne avremo bisogno, di aggiungere nuove funzionalità a questa interfaccia (aggiornando poi naturamente le classi che le implementano).
Ho deciso di utilizzare un'interfaccia anche per dare libera scelta di implementare in modo diverso le funzionalità da una classe all'altra.

Vediamo le modifiche fatte nella classe Ship:
Codice da aggiungere a livello di classe->

//dati per le collisioni
BoundingSphere sphere;
float radius;
public Color colore = Color.Yellow;
public BoundingSphere _BoundingSphere
{
get { return sphere; }
}

public bool CheckSPhereCollision(CollisionI obj)
{
return sphere.Intersects(obj._BoundingSphere);
}


Codice da aggiungere nel costruttore->

sphere = new BoundingSphere();

foreach (ModelMesh mesh in this.myModel.Meshes)
{
foreach (ModelMeshPart mp in mesh.MeshParts)
mp.Effect = currentEffect;
sphere = BoundingSphere.CreateMerged(sphere, mesh.BoundingSphere);
}
radius = sphere.Radius;


Codice da aggiungere nel metodo update (in fondo prima di base.Update(gameTime);)->

sphere.Center = position;
sphere.Radius = radius * scale;


OK!
In questo modo abbiamo aggiunto nella classe i campi necessari a gestire le boundingSphere, abbiamo implementato i metodi richiesti.
Nel costruttore creaiamo la boundingSphere come la sfera più grande che può contente tutte le boundingSphere di ogni singola parte del nostro modello (per ora non mi interessa di calcolare possibili sottocollisioni con le singole parti del modello, mi accontento di un calcolo più grossolano, se volete specializzare fate voi, io mi per ora mi accontento di capire il concetto ^^).
Mi salvo anche il raggio iniziale delle sfera.
Nel metodo update riposiziono la sfera in base alla posizione del modello e riaggiorno il raggio (nel caso sia stato scalato il modello).

Come faccio a disegnare la sfera e a farla visualizzare?
Ho usato una classe statica trovata qua:
Rendering Bounding Spheres
Passando al metodo render la sfera (più altri parametri) essa sarà renderizzata per noi. Certo è un po' pesante quando si deve disegnare molte sfere, quindi non esageriamo! (o se proprio volete renderizzare tutte le sfere vi consiglio di abbassare la risoluzione delle stesse: nel metodo render della classe statica andate a cambiare il valore 30 presente nella chiamata a InitializeGraphics da a 0, le sfere saranno leggermente più spigolose ma ne guadagnarete in prestazioni!).
Quindi nel metodo draw della nostra classe Ship, dopo che abbiamo disegnato il modello aggiungete la seguente riga:
BoundingSphereRenderer.Render(sphere, this.Game.GraphicsDevice, myCamera.View, myCamera.Projection, Color.Yellow);

Ora se lanciate il gioco dovreste vedere una sfera approssimata da due cerchi, di colore giallo.

Ora c'è da fare delle modifiche alla classe MeteorManager:
Codice da aggiungere a livello di classe->

BoundingSphere sphere;
float radius;

public BoundingSphere _BoundingSphere
{
get { throw new NotImplementedException(); }
}

public bool CheckSPhereCollision(CollisionI obj)
{
int val = 1;
for (int i = (cameraR - val); i <= this.cameraR + val; i++)
{
for (int j = (this.cameraC - val); j <= this.cameraC + val; j++)
{
for (int k = (this.cameraP - val); k <= this.cameraP + val; k++)
{
int r = i % cells;
int c = j % cells;
int p = k % cells;
if (r < 0)
r = cells + r;
if (c < 0)
c = cells + c;
if (p < 0)
p = cells + p;
foreach (Trasformation tras in gameWorld[r % cells, c % cells, p % cells].myList)
{
sphere.Center = tras.position;
sphere.Radius = radius * tras.scale;
if (sphere.Intersects(obj._BoundingSphere))
return true;
}
}
}
}
return false;
}

Cosa fa il metodo CheckSPhereCollision?
Prende l'indice della cella in cui siamo, scorre le celle adiacenti a noi, e controlla (riposizionando la sfera e riscalandola) se c'è una collisione con uno degli elementi. Se ne trova uno con cui ho collisione ritorna true, altrimenti se dopo aver controllato tutti gli elementi possibili non ho trovato nessuna collisione ritorno false.

Il costruttore va modificato con le stesse righe aggiunte nel costruttore di Ship.
Il metodo update non va cambiato, dato che per ora i nostri meteoriti devono star fermi.
Andiamo al metodo draw: questa riga va aggiunta nel ramo più interno, all'interno del IF che fa la verifica se la sfera è o meno intersecata dal frustum della telecamera->
BoundingSphereRenderer.Render(sphere, this.Game.GraphicsDevice, myCamera.View, myCamera.Projection, Color.Purple);

Da notare che ora la sphere a cui faccio riferimento non è più quella creata localmente nel Draw, ma quella a livello di classe. In questo modo non andremo a creare un nuovo oggetto ogni volta che viene eseguito il metodo Draw, con un miglioramento dell'utilizzo della memoria direi (su pc non si noterà, ma credo che sulla 360 forse si...).

Per rendere le cose un po' più "carine" ho deciso di fare ciò:
- nel metodo draw del MeteorManager ho diminuito la variabile val a 5
- nel LoadContent di Game1 ho portato il numero di meteoriti per cella da 5 a 3 (per alleggerire il calcolo)
-nella classe Ship ho aggiunto:
public Color colore = Color.Yellow;
-> nel metodo Update di Game1 ho aggiunto:

if (mman.CheckSPhereCollision(myShip))
myShip.colore = Color.Red;
else
myShip.colore = Color.Yellow;

In questo modo quando si rileva una collisione il colore della sfera della nostra nave diverrà rosso, mentre tornerà giallo quando non collidiamo con nulla!

Dovrebbe essere tutto! :D
Se qualcosa non va c'è sempre il file allegato!
E se trovate qualche errore fatemelo notare così correggo ^__^

XNA-tut7.rar

Argomenti trattati:
> Collisioni con BoundingSphere

Se leggete o scaricate i sorgenti lasciate un commento plz, almeno mi rendo conto di come vanno le cose ^^

Alla prossima!

Continua a leggere!

The Xna-Way: Tutorial 6: Orientare oggetto nella direzione in cui si muove e telecamera che lo insegue

Questa volta il compito che mi sono proposto è stato un po' più difficile:
avendo creato un decente MeteorManager questa volta volevo muovermi attraverso questo fitto campo di meteoriti con una navicella spaziale.

Sono partito col pensare a ciò:
- per ora non mi interessa calcolare le collisioni con i meteoriti
- la telecamera sarà in 3° persona, quindi ci troveremo alle spalle della nostra astronave (altrimenti avevamo già la telecamera in prima persona per muoverci)
- la telecamera dovrà seguire il nostro vascello spaziale
- dovremo far muovere nello spazio il nostro mezzo di trasporto

tutto questo ci porta a dover modificare la nostra telecamera per implementare "l'inseguimento" della nostra astronave. Avremo quella che chiamo Follow Camera.
Anche per il nostro vascello avremo il nostro bel da fare: non dovremmo solo farlo muovere e ruotare nel mondo 3D, ma dovremo farlo muovere nella direzione in cui "guarda", quindi movimenti e rotazioni dovranno essere fatti in modo particolare lavorando sulle direzioni, cosa un po' complicata e astrusa ma fattibile.

Per prima cosa è meglio fare la modifica alla classe Camera in modo da implementare l'inseguimento di un determinato bersaglio. In questo modo quando poi andremo a far muovere il nostro oggetto nello spazio la telecamera gli starà dietro e noi non avremo problemi ad osservarlo ^_^

Preso il progetto dell'ultimo post, andiamo nella classe Camesa.cs e sotto il metodo UpdateFreeCamera() andiamo a mettere il seguente metodo:

private void updateFollowCamera(GameTime gameTime)
{
float delta = (float)gameTime.ElapsedGameTime.TotalSeconds;
//creo la matrice temporanea
Matrix tmp = Matrix.Identity;
//imposto la direzione di osservazione, la direzione dell'alto e la direzione della destra
tmp.Forward = direction;
tmp.Up = up;
tmp.Right = Vector3.Cross(up, direction); //questa è calcolata come prodotto tra due vettori

Vector3 t;
//trasformo la distanza (offset) dal punto di osservazione con la matrice calcolata
Vector3.Transform(ref offset, ref tmp, out t);

Vector3 positionTmp;
//calcolo la posizione che vogliamo far avere alla nostra telecamera sommando al punto che siamo osservando
//la posizione trasformata lungo la matrice
Vector3.Add(ref target, ref t, out positionTmp);
//aggiorno la posizione finale
position = positionTmp;
}


Per non avere errori dovremo aggiungere le seguenti variabili di classe:

//variabili per l'inseguimento del target
protected Vector3 offset = Vector3.Zero;
protected Vector3 direction = Vector3.Forward


Cosa fa il metodo?
Il metodo crea una matrice identità e ne imposta i valori per le direzioni che rappresentano il davanti, l'alto e la destra.
Direction e up da dove vengono? Sono dati e assegnati tramite l'oggetto che vogliamo inseguire: cioè direction rappresenta la direzione in cui si sta muoveno il nostro oggetto, mentre up è la direzione che il nostro bersaglio considera come l'alto. In questo modo potremmo mantenere costati le rotazioni!
La destra viene calcolata come prodotto tra i due vettori.

Dopo trasformo l'offest usando la matrice, e sommo questo offest alla posizione del punto osservato e assegno il risultato alla posizione.

Quello che manca da fare ora è la classe per gestire la nostra navicella spaziale.
Ecco il file Ship.cs, comunque presente nell'archivio allegato:
Ship.cs Show/Hide


Il file va inserito nel progetto Meteor e non nella libreria, dato che, come il MeteorManager, questo oggetto è specifico per questa applicazione.

Il pezzo saliente è il metodo Update, il resto è roba già vista!
Cosa fa questo benedetto metodo?
Prima di tutto riazzera il valore della rotazione per yaw e pitch, e anche val.
Val indica se la barra spaziatrice è premuta o meno, e quindi se dobbiamo muoverci o no.
Con la pressione delle frecce direzionali imposto i valori per le rotazioni, e con R riporto il tutto allo stato iniziale.

Con

if (up.Y < 0)
yaw = -yaw;

faccio in modo che se mi trovo a testa in giù e premo verso destra, continuo a girare ancora verso destra non verso sinitra.

Dopo di chè calcolola matrice di rotazione (nota: l'angolo per pitch è calcolato passando l'asse di rotazione), e uso tale matrice per trasformare la direzione e l'up.

Ho poi il calcolo della forza applicata all'oggeto.
Sono formule fisiche. Forza = massa * accellerazione.
So che la formula per calcolare la velocità è sbagliata (anche se quella giusta è riportata come commentata). Ma ora come ora non mi interessa la correttezza delle fisica.

Alla fine poi ho la creazione della world matrix per la nostra navicella, fatta in modo molto simile a come abbiamo costruito quella per la telecamera.

Cosa manca da fare per far funzionare il tutto?
Aggiungere il file per il modello 3D e la texture al progetto, creare la nostra astronave, aggiungerla ai components e disegnarla.
Poi dobbiamo modificare leggermente le impostazioni della telecamera.

Cominciamo: nel costruttore di Game1.cs modifichiamo il codice per la telecamera come segue

myCamera = new Camera(this);
myCamera.FarPlane = 100000;
myCamera.Offset = new Vector3(0, 100, 500);
myCamera.Mode = CameraMode.Follow;
Components.Add(myCamera);

Impostiamo la distanza dal punto di osservazione e cambiamo il tipo di telecamera.

Nel metodo LoadContent() aggiungiamo questo:

myShip = new Ship(this, @"Models\p2_wedge", @"Textures\wedge_p2_diff_v1", defaultEffect);
myShip.Scale = 0.1f;
Components.Add(myShip);

Dove myShip è l'oggetto per la nostra astronave, che dobbiamo aver definito nella classe. Lo scalo ad un fattore 0.1 perchè altrimenti sarebbe troppo grande.

Nel metodo Draw dopo il render per il meteorManager aggiungiamo questo:
myShip.Draw(gameTime);

E nel metodo Update questo:

if (myCamera.Mode == CameraMode.Follow)
{
myCamera.Target = myShip.Position;
myCamera.Up = myShip.Up;
myCamera.Direction = myShip.Direction;
}


In modo che se la telecamera è di tipo follow, si aggiorna il suo target alla posizione della nostra navicella (ma potrebbe essere benissimo qualsiasi cosa!), e settiamo up e direction con i valori provenienti dal nostro oggetto myShip.

Dovrebbe essere tutto! :D
Se qualcosa non va c'è sempre il file allegato!
E se trovate qualche errore fatemelo notare così correggo ^__^

XNA-tut6.rar

Argomenti trattati:
> muovere un oggetto lungo la direzione che sta osservando
> telecamera che insegue il nostro oggetto

Alla prossima!
Continua a leggere!

The Xna-Way: Tutorial 5: Meteor Manager & Free Camera

Eccomi dopo un po' di tempo con un altro post sull'XNA e un suo utilizzo.

Questa volta mi sono detto: "voglio avere una scena con tanti, ma tanti oggetti!"
Ah, quando il masochismo non ha limiti...
Qualcosa ho comunque fatto, anche se non è proprio un granchè...

Quello che mi è venuto in mente, in modo da poterlo poi riusare anche in futuro per una qualche demo simile ad un Asteroid, è di avere un gestore di meteoriti!
Cioè questo gestore ci deve la possibilità di renderizzare a schermo tanti meteoriti.
E vogliamo pure dare la possibilità di muoversi in questo mondo no?
Quindi dovremo fare delle modifiche alla telecamera, in modo che ci pemetta di spostarci in questo universo popolato unicamente da meteoriti!

Allora per il metorManager creremo un file in un progetto per un gameWindows a se stante, mentre il file della della telecamera che andremo a modifcare è sempre quello della myLibrary.

Prima di tutto vediamo come strutturare questo fantomatico MeteorManager. Io l'ho pensato in questo modo:
-il mondo sarà visto come un cubo, dove all'interno potremo mettere i nostri meteoriti
-il mondo sarà diviso in celle: ad ogni cella sarà assegnata una sezione del mondo, e dentro ogni sezione ci sarà la lista degli elementi che sono contenuti dentro tale sezione

Perchè le sezioni? Perchè se ho un mondo molto grande potrei dover renderizzare tanti troppi elementi a schermo, e questo rallenterebbe di molto il numero di frame per secondo. Dividendo in sezioni il mondo potremmo decidere di renderizzare solo quelle adiacenti a noi.
Inoltre se poi in futuro dovremmo calcolare la collisione di una fantomatica astronave con un meteorite, invece di controllare le collisioni con tutti i meteoriti della scena (cosa veramente masochistica, che poterebbe via tantissimo tempo) potremmo semplicemente farlo con quelli adiacetni alla sezione in cui ci troviamo.
Pensante a quanto tempo occorre scorrere un cubo in cui ogni lato è diviso in 20 sezioni!
Cioè ci sono 20*20*20 sezioni da controllare! Ognuna con più elementi!

Avendo suddiviso un mondo cubico in sezioni ho deciso di usare un vettore a 3 dimensioni per gestire il gameWorld.
MeteorManager.cs Show/Hide


Diamo una spiegazione di quello che ho fatto nei vari punti!

public MeteorManager(Game game, Effect effect, int num, float xRange, float yRange, float zRange,
string myModel, string texture)
: base(game)
{
this.currentEffect = effect; //assegno l'effetto usato per il rendering
this.myModel = Game.Content.Load<Model>(myModel); //carico il modello
foreach (ModelMesh mesh in this.myModel.Meshes)
foreach (ModelMeshPart mp in mesh.MeshParts)
mp.Effect = effect; //assegno l'effetto ad ogni parte del modello
this.text = Game.Content.Load<Texture2D>(texture);//carico la texture che voglio usare
//assegno le variabili per la dimensione del mondo
this.xRange = xRange;
this.yRange = yRange;
this.zRange = zRange;
myCamera = (CameraI)game.Services.GetService(typeof(CameraI)); //recupero il servizio per la telecamera
inputDevice = (InputI)game.Services.GetService(typeof(InputI));//e quello per l'input
gameWorld = new Sezione[cells, cells, cells];//creo la matrice del mondo
makeWorld(num); //vado a creare i mondo
}

Quello che fa il costruttore è questo:
assegna al currentEffect l'effetto passato (gli effect sono usati per caricare e gestire codice HLSL, che serve per renderizzare gli elementi della scena, ottenere effetti particolari etc; in questo esempio ho usato un mio piccolo effect che non fa altro che prendere la texture ed applicarla all'oggetto da renderizzare, senza calcolare nessuna luce, questo perchè è più veloce e semplice del basic Effect standard, e qui voglio andare ad ottenere più FPS possibili. Il file è allegato nella soluzione, ma qui non darò spiegazione di come funziona).
Poi carica il modello e la texture passate. Assegna il valore alle variabili che mi dicono quanto è grande il mondo.
Si recupera poi i riferimenti ai servizi della telecamera e del gestore dell'input.
GameWorld è la matrice cubica che andrà a contenere il mondo: ogni cella rappresenta una sezione, e ogni sezione avrò la sua lista di elementi.

Il metodo makeWorld, per quanto possa disorientare, non fa altro che creare e posizionare in modo radom num elementi per ogni sezione. A voi il compito di guardarlo o di chiedere qualcosa che non vi è chiaro qui.

Concentriamoci un attimo sul metodo checkCameraPosition invece, che è più curioso secondo me...

private void checkCameraPosition()
{
float var = (xRange + xRange) / cells;
cameraR = (int)(myCamera.Position.X / var) + cells / 2;

var = (yRange + yRange) / cells;
cameraC = (int)(myCamera.Position.Y / var) + cells / 2; ;

var = (zRange + zRange) / cells;
cameraP = (int)(myCamera.Position.Z / var) + cells / 2; ;
}

Questo metodo prende la posizione della telecamera e memorizza in 3 variabili l'indice di riga, colonna e profondità in cui si trova la telecamera.
Come si fa ad otterere tale risultato?
Prendo la variazione relativa ad ogni cella (cioè quanto spazio sulla dimensione X, per esempio, copre una cella). Poi prendo la posizione X della telecamera, la divido per questa variazione, e a tale risultato ci sommo la metà delle celle. La somma è necessaria perchè voglio che la posizione 0,0,0 sia il centro del mio mondo cubico!
Se non facessi così sarei invece posizionato ad un vertice del mondo.

Il metodo draw adesso, che non sto a riportare perchè è lungotto :O
Allora: nelle prime righe si assegna all'effetto usato per il rendering i valori opportuni, quindi la viewMatrix della telecamera, la projectionMatrix della telecamera, la texture dell'oggetto, e un colore.
Poi cominciamo a scorrere le mesh che compongono il nostro oggetto da renderizzare, in questo caso il nostro meteorite, che dovrà essere replicato tante volte.
Si crea una nuova BoundingSphere con centro e raggio presi dalla BoundingSphere della mesh in esame.
Le BoundingSphere sono usate per calcolare le collisioni tra volumi sferici, ma qui le userò per una cosa diversa ma molto utile ^__^

Poi cominciamo a scorrere le celli adiacenti alla posizione in cui si trova la telecamera: più val è grande maggiore è il numero di celle che considero adiacenti.
Poi riassetto gli indici, in modo che non vadano fuori dai limiti consentiti.
Scorro poi la lista di elementi della sezione data dagli indici r,c,p.
Modifico il centro ed il raggio della BoundingSphere, e calcolo se la sfera o contenuta o interseca il BoundingFrustum della telecamera e solo se lo è renderizzo il meteorite.

Perchè faccio ciò?
Perchè anche se renderizziamo solo le celle vicine a noi, eseguo di solito il draw anche per oggetti che mi sono alle spalle e che io non vedo. Facendo questo sprecherei tempo in rendering inutili, che vengono calcolati, ma il cui risultato non è visualizzato a schermo.
Il frustum della telecamera lo possiamo vedere come un cono che parte dal nostro punto di osservazione, o meglio un tronco di cono, che comincia alla distanza nearPlane e termina a farPlane.
Dato che prima di giungere a questo risultato ho fatto diverse prove, se non usassi il boundingFrustum otterrei con val = 8 qualcosa come soli 5 FPS. Con invece riesco ad arrivare a 70 FPS più o meno stabili! Un buon risultato!
Insomma quello che facciamo è controllare se il volume dato dalla boundingSphere adeguatamente settata è contenuto completamente o in parte nel cono visivo della telecamera, e solo se lo è renderizzo l'oggetto. E' molto più conveniente fare questo controllo che fare un rendering inutile!
E poi perchè usare le BoundingSphere? Perchè è un metodo comodo, semplice ed economico per calcolare il volume di un oggetto, perchè calcolarne il volume esatto controllando i poligoni/vertici è troppo oneroso secondo me (e poi non lo so fare XD).

E come lo calcolo il frustum?
Per questo bisogna andare a modifcare la telecamera!
Ecco il file della telecamera con tutte le modifiche apportate
Camera.cs Show/Hide


Le parti importante da considerare sono:
l'enumeratore CameraMode: questo contiene i vari tipi di telecamera che mi sono venuti in mente. Per ora noi useremo solo Free, ma nulla vieta di implementare anche gli altri o di aggiungerne di nuovi!
Come si può vedere ho anche aggiunto alcuni campi all'interfaccia CameraI.
Aggiunta importate è la CameraBoundingFrustum, che verrà calcolato nel metodo Update.

Ora passiamo al metodo Update: per prima cosa andiamo a controllare il tipo di telecamera, e se è di tipo Free adiamo a chiamare il metodo per aggiornarla.
Poi si calcola la view e la projection matrix ed infine il boundigFrustum, dato dal prodotto delle view per la projection.

Vediamo il metodo updateFreeCamera:

private void updateFreeCamera(GameTime gameTime)
{
movimento = Vector3.Zero;
float delta = (float)gameTime.ElapsedGameTime.TotalSeconds;
if(inputDevice.actualKeyboardState.IsKeyDown(Keys.Up))
pitch -= rotationRate * delta;
if (inputDevice.actualKeyboardState.IsKeyDown(Keys.Down))
pitch += rotationRate * delta;
if (pitch > 89)
pitch = 89;
if (pitch < -89)
pitch = -89;
if (inputDevice.actualKeyboardState.IsKeyDown(Keys.Right))
yaw -= rotationRate * delta;
if (inputDevice.actualKeyboardState.IsKeyDown(Keys.Left))
yaw += rotationRate * delta;
if (yaw > 360)
yaw -= 360;
if (yaw < 0)
yaw += 360;
if (inputDevice.actualKeyboardState.IsKeyDown(Keys.W))
movimento.Z -= movementRate * delta;
if (inputDevice.actualKeyboardState.IsKeyDown(Keys.S))
movimento.Z += movementRate * delta;

Matrix rotation = Matrix.CreateFromYawPitchRoll(MathHelper.ToRadians(yaw),
MathHelper.ToRadians(pitch), 0.0f);
Vector3.Transform(ref movimento, ref rotation, out movimento);
position += movimento;
Vector3 transformedReference;
Vector3 dir = new Vector3(0, 0, -1);
Vector3.Transform(ref dir, ref rotation, out transformedReference);
Vector3.Add(ref position, ref transformedReference, out target);
}


MovementRate e RotationRate sono due variabili definite nella classe e ci dicono quanto velocemente si muove e ruota la nostra telecamera.
A seconda dei tasti che premiamo andiamo a modifcare i valori di Pitch e Yaw (che stanno rispettivamente per l'angolo sull'asse X ed Y), oppure a spostare la posizone della telecamera.
Usando yaw e pitch creo una matrice di rotazione, che uso per trasformare (cioè per spostare lungo la direzione data dalla matrice) la posizione della telecamera.
La stessa cosa la faccio per la posizione del punto che sto osservando, cioè per il target.
Come possiamo vedere in questo metodo non c'è il calcolo per la creazione della view e della projection: qui si aggiorna solo il valore della posizione e del target, la creazione viene fatta nel metodo update.

E questo è tutto.
Ora si deve solo andare in Game1.cs e mettere questo nel metodo Initialize:

defaultEffect = Content.Load<Effect>(@"Effects\Default");

mman = new MeteorManager(this, defaultEffect, 5, maxX,
maxY, maxZ, @"Models\asteroid1", @"Textures\asteroid1");
Components.Add(mman);

Le due variabili vanno naturalmente create prima ^^
Questo ci dice di caricare il file Default.fx, e di creare il MeteorManager che avrà 5 elementi per ogni sezione.

Dato che il MeteorManager è un GameComponent e non un DrawableGameComponent bisogna dirgli noi quando renderizzarlo!
Quindi nel metodo Draw di Game1.cs va messo questo:
mman.Draw(gameTime);

Ma veramente serve tutta questa palla del CameraBoundingFrustum, delle collisioni e tutto il resto?
Fate una prova:
Andate nel file del MeteorManager, nel Draw(..) mettere val = 8 e commentate la riga dove fate il controllo sul risultato del CameraBoundingFrustum.Contains(..).
Io riesco ad ottenere soltanto 5-6 FPS.
Facendo il controllo passo a circa 70.

Voi che dite? Serve?
Per me si ^___^

Poi almeno così si è visto come creare un manager per un insieme di oggetti, e come cominciare a buttare giù una semplice struttura per un gioco... qui il compito è..... contatare tutti gli asteroidi XD Sai che spasso XD
Scherzi a parte, potrebbe comunque essere un'idea di base per la struttura di un semplice gioco!

Ci dovrebbero essere altri metodi per semplificare il rendering di istanze multiple dello stesso elemento, ma ancora non sono in grado di applicarli.
Spero vi sia stato utile tutto questo.

Se ci sono cose che non tornanto o sbagliate o che si possono fare meglio (il che è molto probabile) ditelo please :)

Alla prossima!

Intanto ecco i file allegati!
XNA-tut5.rar

Argomenti trattati:
Free camera
Camera Bounding Frustum
Continua a leggere!

Fast Modelling 9 - Mecha

Quando sono preoccupato per qualcosa e non trovo modo di distrarmi o pensare ad altro (non posso studiare perchè le cose non mi resterebbero in testa) mi metto a lavorare a qualcosa.

Questa è l'ultima fatica (ancora incompleta) data dalla mia disperata mente!

Può darsi che sarà il nuovo lavoro per un bel WIP.
Si vedrà come va avanti.
Cosa ne pensate? Vi piace? Oppure come "stile" non va bene?

Sarà comunque servito a distrarmi?
No, affatto...
Il problema di riuscire a fare più cose contemporaneamente è che anche i brutti pensieri permangono. Solo il sonno forse mi darà pace, e ora mi sta venendo una grande voglia di dormire...

Alla prossima...
Continua a leggere!

Seifer Gunblade

In questi giorni proprio non so cosa fare per ternemi occupato.
Ho tanti troppi pensieri per la testa, ma al contempo tanta troppe cose che vorrei fare...
Non mi succedeva da tanto tempo, e devo dire che è frustrante non avere la possibilità di realizzare tutto quello che si vorrebbe nell'arco di un solo giorno.

Comunque proseguendo sulla retta via cominciamo a descrivere cosa ho fatto.

Ho notato che parecchi degli accesi al blog sono stati fatti ricercando "Gunblade" o come costruirne uno (magari fossi in grado di farne uno vero XD).
Quindi ieri sera (mentre guardavo qualcosa alla tv... mi pare aspettassi Wasabi :P) mi sono detto "Cosa potrei fare come lavoro sempre in tema Gunblade?".
Eh purtroppo di Gunblade ce ne sta solo uno!
NO INVECE! C'è anche quello di quel maledetto ed antipatico di Seifer -.-

E allora non ci ho pensato troppo su, ho trovato una cavolo di immagine (a bassa risoluzione -.-) e mi sono messo a modellarlo!

Come forma è certamente più semplice rispetto al Revolver di Squall, con meno dettagli direi.
Poi avendo un'immagine a bassa risoluzione non ho potuto mettere tutti i dettagli che avrei voluto ?_?
Il risultato però non mi dispiace (per averci lavoraro al massimo un'oretta).

Come si può vedere è molto più semplice.
E mi chiedo come facesse Seifer a tirare quelle pizze tremente impugnando questo affare a mo di pistola e con una mano sola :O
Almeno quello di Squall lo si poteva usare a 2 mani e aveva una forma più a spada che a pistola...
I misteri della vita! :O

Poi devo dire che il modello "pistola automatica" mi piace poco, poi come ho detto, non ho potuto particolareggiare molto: anche così sono andato abbastanza a fantasia.
E anche usando una foto di una pistola automatica non posso mettere troppa roba che non "esiste" nel progetto gunblade, anche perchè dopo non tornano forme e posizioni.

Poi mi sono detto "E a metterli assieme entrambi come rende il tutto?"
Ecco a voi :)

Diaciamocelo....
Il gunblade di Seifer a confronto con quello di Squall sembra un coltellino svizzero XD
Dai quello di Squall è troppo più bello e massiccio!
Credo che l'unica arma che ispira più potenza sia la Buster Sword di Cloud :P

Bè come al solito spero vi piaccia, e se avete delle critiche da fare, anche sulla forma e sui dettagli dei modelli ditelo che provvedo a cambiare e a modifcare!

Inoltre una piccola richiesta: se qualcuno trova delle foto ad alta definizione del gunblade di Seifer me lo può dire? In questo modo potrò aggiungere altri dettagli :)

Eccovi i link per le immagini ad alta risoluzione :)
Seifer's Gunblade
Both Gunblade
Continua a leggere!

Donazioni

My Menu'