Wednesday, December 31, 2008

100


This is the message number 100, and what better day than the last day of the year to post it? :)

I'm just returned from vacation, my life in these days was a little messy due ti a lot of changes. So i'm a little confused, i've tryied to open the source and work on it, but i've not very mental fuel to do something of interesting.

The ships now has their own shadows, but it's still too much glossy. I need to work on maps and understand if there are the right approach.

So, happy new year and i hope to make others steps on 2009.

---

Questo e' il messaggio numero 100, e quale giono migliore dell'ultimo dell'anno per pubblicarlo? :)

Sono appena tornato dalle ferie natalizie, e la mia vita in questi giorni e' abbastanza caotica a causa di una serie di novita' che mi han lasciato davvero poca energia mentale da investire nel gioco. Ho provato ad aprire il progetto, ma ho visto che non riesco a concentrarmi, speriamo nei prossimi giorni vi sia piu' calma.

Per ora le astronavi hanno le loro ombre, che pero' sono ancora troppo imprecise. Cerchero' di lavorarci e capire se si riesce a rifinire, o se le shadow maps sono proprio inadeguate per il motore che mi serve.

Vi lascio augurandovi buon 2009 e chissa' che nell'anno nuovo riesca a fare altri passi avanti.

Wednesday, December 17, 2008

Happy Birthday


Today is the first blog's birthday!
I've some busy days: i'm changing my work, and i'm going for some day in vacation, so not very time (and mind) to dedicate to the developing. I don't know if with my new work i'll be time to continue my hobby but i've done the same question one year ago and.. i'm still here.
So: for now happy birthday Tau Ceti and i hope to see also the second birthday :)

--

Oggi e' il compleanno di questo blog!
Ho avuto giorni convulsi, sto cambiando lavoro e domani parto pure per una settimana di ferie. Cosi' il tempo (e la testa) per dedicarmi allo sviluppo non c'e. Con la mia nuova attivita' non so se avro' tempo per portar avanti questo hobby, ma in fondo le stesse cose le dicevo un anno fa e sono ancora qui.
Cosi', per il momento, buon compleanno Tau Ceti, e chissa' che il 17 Dicembre 2009 sia ancora qui a festeggiare :)

Friday, December 5, 2008

Shadow Maps reprise


Shadow maps are a good tool to display shadows into a scene, but has pro and cons.
Pros:
- are fast: you need to render the scene only twice to obtain it
- are simple: the shaders is not very complex, and it's easy to customize it.

Cons:
- are imprecise: the shadow is obtained with a projection of a 2d texture. This means jagged shadows when you are near to the object. With some filtering you can reduce the aliasing problem but not to eliminate
- are usable only with spotlight lamps. And the sun is not a spotlight, but an omnidiretional light.
- are good only if the light source is near to the object. If the distance grows, some errors appears, due to precision errors.

There's another option: to use a volume shadow, another tecnique to generate more precise shadows, but it's more complex and heavy (it's the same tecnique used in doom3 engine).
For now i'm trying to optimize the shadow maps, and some good result are born.

---

Proseguendo con lo studio delle shadow maps ho scoperto che sono un ottimo strumento per creare ombre ma hanno i loro pro e contro.

Pro:

- Sono molto veloci: basta renderizzare la stessa scena due volte per ottenere le ombre
- Sono di semplice implementazione: gli shaders sono abbastanza snelli ed e' facile mettervi mano

Contro:

- Sono imprecise: essendo il risultato di una proiezione di una texture bidimensionale, se la texture non ha una gran risoluzione si nota molto l'effetto "scalinatura" tipico dei pixel ingranditi. Effetto che si puo' ridurre applicando dei filtri ma non eliminare
- Sono utilizzabili solo con luci a cono (la classica lampada da scrivania). Il sole e' invece una luce omnidirezionale.. posso solo simularne l'effetto facendo si' che il cono di luce sia sempre puntato verso la telecamera dando l'impressione della omnidirezionalita', pero' cio' che sta fuori dal cono verra' erroneamente mostrato in ombra.
- Danno risultati decenti solo se la luce e' vicina all'oggetto.. piu' si allontana e piu' insorgono problemi dovuti alla precisione, con risultati spesso pessimi.

Una seconda possibilita' e' data dalle shadow volumes, una tecnica differente, piu' precisa ma purtroppo piu' complessa e pesante. Per intenderci e' la stessa tecnica usata nell'engine di Doom3.

Ad ogni modo per ora sto provando ad ottimizzare le shadow maps, e devo dire che ho ottenuto qualche buon risultato, come potete vedere dall'immagine e dal filmato.

Wednesday, December 3, 2008

Shadows Map

On 17 December 2007 i wrote my first post into this blog. I was writing some code to display a wireframed grid (the map), i had only some little idea about 3d, shaders and so on. I was not able to draw a flat sphere, i had no idea how to map a texture onto it, and i've never heared about uv coordinates.

Today, 3 December 2008, a year after, i have made my first step into the (very) complex world of shadow maps, and i'm very very proud about it. I know very well that my work will die sooner or later, i've no chanche to finish, alone, a game developed for hobby and with very little time. I knew on 17 December 2007, i know today, but it's a miracle to have reached this "advanced" aspect of a 3d engine.

You can see on this movie my first attempt to add shadows to the game. It's a bit raw for now (the green mesh is only for test), but.. works! I've to work more on it but i'm very happy

----

Il 17 Dicembre 2007 aprii il blog di Tau Ceti. Lo sviluppo era appena iniziato, vi era una griglia in wireframe che si ruotava col mouse, ed io avevo solo vaghe idee su come costruire un mondo tridimensionale. Non sapevo fare una sfera, ne sapevo come avvolgervi una texture, figuriamoci illuminarla. Le coordinate UV manco le avevo mai sentite, gli shader mi erano noti solo come oscuri componenti di una scheda video che piu' ce n'e' e meglio e', tirare una linea e ruotarla col mouse era gia' al limite della mia possibilita'.

3 Dicembre 2008, un anno dopo. Ho fatto i miei primi passi nel complesso mondo delle shadow maps, e sono davvero orgoglioso del percorso fatto in questi 12 mesi. So benissimo che il mio lavoro prima o poi sara' destinato a morire, visto che ci lavoro da solo e soltanto nei pochi buchi di tempo liberi. Lo sapevo anche il 17 Dicembre 2007, eppure mai mi sarei immaginato di arrivare dove sono arrivato oggi. Certo, siamo ancora al 1% del totale, ma va gia' oltre ogni mia piu' rosea aspettativa.
E per ora non ho alcuna intenzione di mollare, anzi sono molto motivato.

Quel che vi mostro e' un primo prototipo di shadow map, ovvero la tecnica per introdurre l'ombreggiatura dinamica nel motore del gioco. Ho creato una mesh semplice e dalla forma particolare in modo da far risaltare bene l'ombra: e' tutto ancora piuttosto grezzo e c'e' da lavorarci su, ma sono estremamente soddisfatto per i risultati

Wednesday, November 26, 2008

1444

1444 is the number of FPS that Tau Ceti made on this system:

- E8500@3.16 GhZ
- 4870x2 Shappire
- 4 Gb RAM
- Vista 64

This executable was compiled with 32 bit version of directx (64 bits gives me some errors..)

---

1444 e' il numero degli FPS che ho ottenuto con Tau Ceti sul seguente sistema:

- E8500@3.16 GhZ
- 4870x2 Shappire
- 4 Gb RAM
- Vista 64

L'eseguibile e' stato compilato con le librerie a 32 bit di directx (Quelle a 64 mi danno alcuni errori...)


Monday, November 24, 2008

Normal Mapping 3


Excuse me, i've forgotten the english part.
To apologize i show you another video :)
I've finished to implement the normal map shader, now the mesh look like more deep, more defined and more metallic.

If you want to ask me some technical details you're welcome


---

...avevo dimenticato la parte in inglese, cosi' ne approfitto per mettere un secondo filmato ed uno screenshot

Normal Mapping 2

Come promesso, eccovi un filmato che ritrae una Luna realizzata con la tecnica del Normal Mapping.
Per chi non lo sapesse il normal mapping e' una tecnica che permette di realizzare oggetti "ruvidi" senza dover aumentare il numero dei poligoni che ne compongono la mesh.
Se vi servono dettagli piu' tecnici fatemi sapere, nel frattempo vi lascio col video.


Friday, November 21, 2008

Normal Mapping


With the pixel shader developing now i'm able to make more complex effect.
For example: normal mapping.
For now a fast screenshot (i'm a little busy), coming soon a video.

---

Studiando i pixel shader sono riuscito a fare effetti un po' piu' complessi.
Ad esempio il normal mapping.
Vi propongo un "veloce" screenshot (sono un po' preso), ma conto di mettere un video al piu' presto

Thursday, November 13, 2008

Gourard Vs Phong











I was missing for a while. For a good reason: i've fight against the pixel shaders, and i've understood a lot of thing.
So, finally, i've implemented a new lighting model using the pixel shaders: the phong lighting.
The previous model was the gouraud lighting: the light is computed for each vertex of the mesh and the color of pixels between three vertexs are interpolated from the color of the three vertex.
With phong shading, every pixel colour is computed using the illumination model. No interpolation, so a more realistic result, as you can see from the screenshots and the video. Gourarud shading has a "segmented" look, the Phong Shading has a more gentile and realistic aspect. (Look at the spotlights on the skull.. the gourard, the first, looks like a sum of triangle, the phong, the second, is better).

--

Sono stato assente per un po'. Per una buona ragione: ho combattuto (duramente) con i pixel sharders, e ho imparato davvero diverse cose.
Cosi', finalmente, sono riuscito ad implementare un nuovo modello di illuminazione, utilizzando i pixel shaders. Precedentemente usavo il classico Gouraud shading, il quale calcolava l'illuminazione solo nei vertici della mesh, mentre per il colore dei pixel compresi tra tre vertici di un triangolo eseguiva una banale interpolazione, veloce ma poco accurata.
Con i pixel shaders invece son riuscito a calcolare correttamente l'illuminazione per ogni singolo pixel della mesh, senza bisogno di ricorrere all'interpolazione. Il risultato lo vedete negli screenshot e nel video: l'illuminazione gouraud appare piatta, spezzettata, mentre quella phong e' molto piu' accurata, gentile, realistica (guardate ad esempio le chiazze di luce sul teschio, nel gouraud shading, il primo, si notano i rettangoli che compongono la mesh, nel secondo teschio invece le macchie di luce sono molto piu' tondeggianti e piacevoli)

Wednesday, November 5, 2008

Tuesday, November 4, 2008

Lord Alucard 2

Two objective for the next steps on developing:

  1. Understand more on shaders under directx. Until now i've used some simplex shaders from the Frank Luna's book. It's time to study, learn, and make more complex effect, understand how pixel shaders works, how to make it time-dependent for animation (i.e.: heat distorsion), and so on.
  2. Implement a new routine thats could write texts on screens using coloured font, aka bitmapped font. It's not easy.. with the previous version of directx there was the directDraw api that manage the 2D world. Now the DirectDraw is no more included on directx so i've to discover the easiest way to display a 2d text on screen using only 3d functions. There's some method that write some string on screen, and i've used to display the name of the planet, and the debug informations, but i need to write multicolored chars, and it seems that it's a hard work.

Anyway here you are my first experiment with pixel shaders.. a shader that give an (ugly) "cartoon style" to the displayed scene.
The behaviour is very simple: it takes the r,g and b components of the pixel, that are float in 0,1 range, multiply by 5, take only the int part, inserting so a "sampling error" due to low resolution of the sampler, then divide the result by 5 to obtain the result.



float4 SkyPS(float3 envTex : TEXCOORD0) : COLOR
{
float4 ret = texCUBE(EnvMapS, envTex);

ret.r = int(ret.r*5.0f)/5.0f;
ret.g = int(ret.g*5.0f)/5.0f;
ret.b = int(ret.b*5.0f)/5.0f;

return ret;
}





---

Ho due obiettivi per gli sviluppi futuri

  1. Capire bene come funzionano gli shader sotto directx. Per ora ho utilizzato alcuni semplici esempi presi dal libro di Frank Luna, ma e' tempo di studiare meglio la materia per cercare di creare qualcosa di piu' complesso, ad esempio come fare in modo che uno shader sia dipendente dal tempo che passa, per creare ad esempio gli effetti di "distorsione da calore".
  2. Implementare una nuova routine per mostrare delle stringhe sullo schermo che preveda l'utilizzo di font colorati e non solo monocromatici. Sembra sia un'impresa tutt'altro che facile: a quanto pare un tempo esisteva l'api DirectDraw che dava strumenti semplici per gestire il 2D (come le scritte) da mostrare. Ora pero' le DirectDraw sono state abbandonate e non sono nemmeno piu' presenti all'interno delle directx, col risultato che se si vuol mostrare qualcosa in 2D, come una stringa, occorre comunque passare attraverso il mondo 3D, e la faccenda sembra tutt'altro che banale. Fino ad oggi ho utilizzato alcune funzioni di sistema per mostrare del testo nello schermo (i nomi dei pianeti, le informazioni di debug..), ma purtroppo a quanto pare tali funzioni non prevedono la possibilita' di usare dei font bitmapped (multicolore per l'appunto), e quindi mi tocchera' far tutto da zero.

Ad ogni modo vi lascio col mio primo esperimento con un pixel shader. Uno che dorebbe dare una (brutta) rappresentazione dell'immagine come se si trattasse di un "cartone animato".
Il procedimento e' semplice: prende le componenti r,g,b di ciascun pixel, che sono numeri float nel range 0,1, le moltiplica per 5, ne prende solo la parte intera, introducendo cosi' una sorta di "errore di campionamento" dovuto a scarsa risoluzione del campionatore, e ridivide quanto ottenuto di nuovo per 5 per ottenere il risultato finale.



float4 SkyPS(float3 envTex : TEXCOORD0) : COLOR
{
float4 ret = texCUBE(EnvMapS, envTex);

ret.r = int(ret.r*5.0f)/5.0f;
ret.g = int(ret.g*5.0f)/5.0f;
ret.b = int(ret.b*5.0f)/5.0f;

return ret;
}




Tuesday, October 28, 2008

Lord Alucard










The extra data management on a .x files is finished.
As seen some days ago, now is possible to insert a cluster of point on a mesh, give to them a special texture name: Tau Ceti will be use it not like standard triangles vertex, but, for example, as strobo light position.
In the pictures you can see the vertex drawned using blender, and the final effect on Tau Ceti, and on the video there's the aspect of the space station with the lights animated.

---

La gestione dei dati speciali nei file .x e' finalmente conclusa.
Come detto qualche giorno fa ora e' possibile inserire un gruppo di punti in una mesh e assegnar loro una texture speciale: Tau Ceti non li interpretera' come classici vertici di triangoli ma, per esempio, come posizioni delle luci stroboscopiche.
Nelle figure che ho pubblicato potete appunto vedere i vertici disegnati tramite Blender, e l'effetto finale in Tau Ceti. Il video poi altri non e' che una dimostrazione di come le luci animate appaiano nella stazione spaziale.

Friday, October 24, 2008

Christmas tree

As wrote yesterday, i'm working on mesh.. the objective is to use blender, the 3d editor, for create the objects like the space station, but also to add, easily, some points of interest that will not be drawed but used like reference instead.
For example to represent the points on a starship hull where i can attach or detach my weapons.
Or to represent the strobo lights positions on the space station.
To do this i've used a trick: when i want to add for example the strobo lights on the space station, i add a cluster of points using blender: each point represent a strobo light.
Then, i assign a special texture to the cluster and export.
When i read the data from Tau Ceti, i scan the mesh, and when i find the "special" texure, i don't draw the cluster but i read each point of it and use it to display a light on the corresponding position.
Look for this example: i've assumed that ALL the space station are made of special points.. the results looks like an christmas tree :)

---

Come vi ho detto ieri sto lavorando sulle mesh, in particolar modo sto cercando un modo comodo per aggiungere delle posizioni "speciali" all'interno degli oggetti 3D, un'insieme di coordinate che rappresentano non i soliti vertici dei triangoli ma bensi' delle posizioni da utilizzare per altri scopi. Per esempio in un'astronave i punti di aggancio nello scafo per le varie armi. Oppure nella stazione spaziale i punti nei quali devono apparire le luci stroboscopiche.
Il metodo piu' comodo e' senz'altro quello di usare blender stesso per posizionare i punti di interesse in maniera visuale mentre disegno la mesh. Il trucco sta nel assegnare poi ai punti speciali una texture particolare, anche totalmente nera, ma che mi permette poi da programma di riconoscere il gruppo di punti dal normale insieme di triangoli che compone l'oggetto.
I punti speciali non li disegno ma utilizzo le loro coordinate per attaccare le armi, visualizzare le luci stroboscopiche eccetera.

Vi lascio con un esempio: ho preso la stazione spaziale e ho provato a marcare tutti i vertici come posizione di una luce stroboscopica.
L'effetto finale e' l'albero di natale che vedete qui sotto :)


Thursday, October 23, 2008

Patience

Some issue at work, some issue at home... but i'm still working on tau ceti, on mesh support.

---

Un po' di problemi al lavoro, un po' a casa, e il tempo (ma anche la voglia) per scrivere codice e' poco.
Ma non sono fermo, sto lavorando sulle mesh, vi raccontero' appena ho qualcosa di pubblicabile

Thursday, October 9, 2008

Target reached!

Another little step for Tau Ceti, another big satisfaction for me!
Finally the autopilot is able to reach the destination!
Yesterday you've read the procedure i've used to implement the set of steps to emulate an autopilot.
Today i've finished the coding and now the starship can reach the space staton from every point of the space.
There's a lot to thing to do, (the autopilot for now is not able to avoid collisions with other object) but it's a good starting point!

--

Un altro piccolo ma importante passo per Tau Ceti, e un'altra (lasciatemelo dire) soddisfazione per me!
Ieri vi ho raccontato tutta la procedura che ho deciso di seguire per implementare l'insieme di passi necessari alla realizzazione di un pilota automatico.
Oggi finalmente ho concluso la realizzazione di questi passi e ora l'astronave e' in grado di raggiungere la stazione spaziale da qualsiasi punto dello spazio.
Ci sono ancora molte cose da fare (ad esempio far si' che vengano evitate le collisioni con altri oggetti) ma e un buon punto di partenza!

Wednesday, October 8, 2008

The autopilot is growing... now i've implemented a state machine, to manage the set of different behaviours that an autopilot must have.. If you're moving into a direction, but your orientation is different, and you want to go to a new target position, the autopilot first of all has to correct your orientation, and align it with your direction, then decelerate ship until 0, turn the ship to point the target, accelerate the ship and travel until your destination.
A state machine is pefect to manage similar situations.. there are some "states" that represents the phases of the voyage, and the program promote o demote from a state to another when some condition are reached.. if you're aligned with the speed position, you can be promoted to the "decelerate the ship" phase, if, during the deceleration, some error occours (i.e. round errors), the state will be demote to the "align the ship" phase, the orientation will be correct and the state will be promoted again to the "decelerate the ship" phase.
When the speed will reach 0, another promotion to "Align with target destination", and so on..

The movie you can see is a demostration of all above.

---

L'autopilota pian pianino cresce, e le complessita da gestire crescono con esso.
La procedura di navigazione da un punto all'altro dello spazio e' tutt'alto che banale, ed e' comunque suddivisibile in tante fasi che si susseguono. Per gestire le fasi ho deciso di implementare una "macchina a stati", ovvero una sorta di flow chart che in base a quel che stiamo facendo ci dice quale sara' la cosa che dovremo fare dopo.
Facciamo un esempio. Vogliamo andare in un particolare punto dello spazio, e in questo momento pero' abbiamo l'astronave che gia' si muove verso un'altra direzione, ed e' pure orientata in maniera sbagliata.
Cosa deve fare l'autopilota?
Cominciamo a dividere il problema in passi:

1) Deve inanzitutto orientare l'astronave in modo che sia allineata con la direzione che sta attualmente seguendo. (Immaginate un carro armato, mentre cammina il cannone ruota per puntare ad un nemico.. avremo quindi il carro armato che si muove verso una direzione, ed il cannone che invece ne punta un'altra.. quel che vogliamo fare e' riportare il cannone allineato in modo che punti nella stessa direzione di marcia).
2) Una volta che e' orientata, occorre fermarla. In questo caso e' semplice: basta accendere i retrorazzi e tenerli accesi fino a quando la velocita' raggiunge lo zero.
3) Da ferma, l'astronave va ruotata fino a farla puntare verso la direzione della destinazione
4) Una volta puntata, si accelera e si inizia il viaggio vero e proprio.
5) Quando si arriva a destinazione, bisogna rallentare fino a quando l'astronave si ferma.

La macchina a stati non fa altro che dirci, ad esempio "siamo nello stato 3? la rotazione e' terminata? Ok, vai nello stato 4".
La possibilita' poi di promuovere uno stato da uno stato precedente da' la possibilita' anche di "bocciare" uno stato, facendo quindi retrocedere il flow chart.
Questa possibilita' e' estremamente utile quando si devono operare correzioni di rotta dovute ad errori di arrotondamento.
Mi spiego: se io decido di puntare un obiettivo che si trova a un milione di km di distanza, per quanto io sia preciso, e' ovvio che anche un errore di pochissimi decimi di grado mi portera' a mancarlo di migliaia di km.
Con la possibilita' di "bocciare" uno stato, ad esempio, quando mi trovo nel punto 2, dove sto decelerando l'astronave, se mi accorgo che man mano che mi avvicino l'astonave si disallinea, posso dire che se l'errore supera una certa soglia, lo stato deve essere bocciato al punto 1. Quindi al punto 1 l'astronave nuovamente si riallinea con la traiettoria giusta, e riprende il punto due. Se ancora una volta dovesse col tempo disallinearsi troppo, nuovamente ritorna al punto 1, corregge lo sbandamento, e riprende la sua frenata.

Il video che segue illustra proprio i punti 1,2 e 3. Sono abbastanza evidenti le correzioni che avvengono un paio di volte, man mano che l'astronave si avvicina alla velocita' nulla.

Ci tengo a precisare che, a partire dalla prima virata che vedere (che mi serve solo a disallineare la direzione dell'astronave da quella di movimento, cosi' da mettermi nella peggiore situazione possibile) e fino alla fine del filmato, l'astronave e' totalmente pilotata dal computer.

Monday, October 6, 2008

Shopping

Just few words to annunce that i've just bought a Fraps licence, the tool that i use to make the videos you can see on Youtube.
What does it means?
That from now i'll be able to publish videos longer than 30 secs.

---

Solo due parole per annunciarvi che ho preso una licenza per Fraps, l'utility che uso per creare i video che poi pubblico su Youtube.
Questo che significa?
Che finalmente i video che pubblicherò non avranno più l'odioso limite di 30 secondi.

Wednesday, October 1, 2008

Little steps..

The pointing routine that we have seen yesterday has a beauty side effect: you can use it to point the ship to the speed direction.
With the inertial behaviour, the ship orientation is not always also the ship direction: if you point to North, and accelerate until a speed of 1000km/h, then rotate and point to West, the ship will move always to North. Now if you accelerate, you don't move in East direction, but into a new direction that will be the vectorial sum of old speed and new speed.
Again, if you're moving and you want to stop, first of all you must point to the speed direction, then decelerate until the ship stops. If you only decelerate, you'll never be able to stop!
So, for the autopilot, but also for manual navigation, it's very useful to have an "utility" that align your ship with the speed direction. And the utility is the same of the autopilot.. the autopilot "points" to a target, but the same routine can be used to align with any vector.
I've also added an indicator in the hud that shows the effective direction of the ship, so you can try to align the ship manually: first of all move the indicator to the center of the screen. Now you're aligned and you can use the retro burner to stop.

---

L'algoritmo di riallineamento che ho implementato ieri ha un gradevole effetto collaterale, ovvero puo' essere utilizzata anche per riallineare l'astronave lungo la direzione di movimento.
Nel moto inerziale non sempre (anzi quasi mai) la direzione di puntamento coincidono con quella di spostamento.
Se accelero un'astronave fino a 1000 km/h in direzione Nord, e poi la ruoto in modo che punti verso Est, questa continua comunque a spostarsi verso Nord.
Non solo: se a questo punto aziono i motori, l'astronave non si muovera' verso Ovest (non e' un'automobile), ma si spostera' lungo una direzione che e' la risultate della somma vettoriale tra la velocita' precedente ed il nuovo "impulso" verso Ovest.
Pertanto: se vi state muovendo e volete rallentarvi fino a fermarvi dovete prima di tutto orientare la nave nella direzione verso la quale si sta spostando, solo a questo punto usando i retrorazzi potrete rallentare fino allo stop completo.
In tal ottica quindi un'utilita' che permetta all'astronave di riallinearsi con la propria direzione di spostamento viene molto comoda quando si vuole semplicemente accelerare o decelerare. La routine e' la medesima dell'autopilota, quindi e' venuta pressoche' "gratis".
Ho inoltre aggiunto un indicatore nell'hud che mostra costantemente la direzione di spostamento. Con questo e' possibile eseguire l'allineamento anche manualmente.. bastera' portare l'indicatore a centro schermo e l'astronave sara' allineata.

Tuesday, September 30, 2008

Autopilot: the beginning

I've delayed and delayed it.. pheraps due to some fear :) but now it's the moment to become brave and fight the monster!
I'm talking about the autopilot, pheraps one of the biggest problem to solve. Space are immense, planets and other objects are far away, they move into their orbits, so is VERY difficult travelling from outer space to an object, especially when the inertial phisic is activated. Imagine: the earth is a million km away, so you need a very big speed to reach it in reasonable time. To reach the travelling speed you need an acceleration, and it's impossible to use too much big acceleration otherwise your body will be destroyed. It means that you need a lot of time to reach the speed... and you cannot decelerate only when you're near earth.. for the same reason: you cannot decelerate too fast. So you need time also for deceleration, and you've to begin the deceleration phase when you're still away from earth.
Now try to imagine that the earth is moving around sun: you need to update always your direction if you want to reach our planet.
So it's near impossible to do it manually. You need a computer help, aka the autopilot.
There are very difficult to realize it, i'll try to list the most important:

- An autopilot cannot compute the route before the travel.. there are a lot of variable that can change during the travel, so it should work in real time and react to all the new condition that could happens. For example: a ship appears in front of us, the autopilot has to recompute new route to avoid it.
- Our autopilot should be consider the time compression. If the time is running 1000 faster, the reaction time of the autopilot should be also 1000 time faster.
- If you want to reach an object you've to consider that that object moves also into the space. Now it's at (100,100,100), a minute after it could be at (200,40,-6). So you cannot simply compute a segment from our position to actually target position: the route should be updated every second.
- Planets, Stars, stations, and so on, are solid, and you cannot pass through them. If i'm in A position, and want to reach the B position, and between A and B there is a big giant star, we need to compute a more complex route A-->point C outside star--> B

Ok, i've begin this BIG work.. for now i think that a route is composed from a set of segment joined toghether to build a complex path. So we start with a simplex sub-problem: move your ship from a fixed point A to another fixed point B without obstacles in the middle. For now we assume that our ship is stopped.
The first thing to do is to locate the B point (the destination) and rotate the ship until B is in front of us. Then we start engine and begin our travel.
In the next movie you can see this first step: there's a station into the space and we want to reach it. The autopilot rotate the ship until the nose is aligned to the point. I'ts not easy because the ship could be rotated around all the tree axis... but it works!

---

L'ho rimandato a lungo, probabilmente perche' in fondo avevo paura :) ma ora e' giunto il momento di essere coraggiosi ed affrontare il mostro!
Sto parlando dell'autopilota, uno dei problemi probabilmente piu' grossi da risolvere. Lo spazio e' immenso, i pianeti e gli altri oggetti sono molto distanti, e si muovono lungo le loro orbite, cosi' e' davvero MOLTO difficile viaggiare dallo spazio profondo fino alle prossimita' di un oggetto, specialmente se si considera la fisica inerziale. Provate ad immaginare: la terra a milioni di kilometri di distanza, avete senz'altro bisogno di una gran velocita' per raggiungerla in un tempo ragionevole. Per raggiungere una simile velocita' vi serve un'accelerazione, che non puo' essere eccessiva (altrimenti il pilota finisce spiaccicato al pavimento), e pertanto deve durare a lungo. E non potete decelerare solo quando sarete quasi arrivati, perche' per lo stesso motivo anche la decelerazione non puo' essere eccessiva, e quindi deve iniziare molto prima dell'arrivo. Non solo: durante il viaggio la terra non resta ferma ma orbita attorno al sole, pertanto la rotta va costantemente aggiornata se la vogliamo raggiungere.
Morale: navigare manualmente e' pressoche' impossibile, cosi' e' necessario ricorrere all'aiuto di un autopilota.
Un autopilota e' molto difficile da realizzare, cerchero' di elencarne i motivi principali.
- Un autopilota non puo' calcolare la rotta prima di partire, ci sono troppe variabili che possono cambiare durante il viaggio, pertanto deve eseguire i propri calcoli in tempo reale in modo da reagire prontamente a qualche nuova situazione. Ad esempio: un'astronave appare all'improvviso davanti a voi, l'autopilota deve reagire e cambiare prontamente la rotta per evitare la collisione
- Il nostro autopilota deve anche tener conto della compressione del tempo. Se il tempo va 1000 volte piu' veloce del normale, l'autopilota deve reagire 1000 volte piu' velocemente
- Se si vuole raggiungere un oggetto bisogna tener conto che questi si muove nel frattempo. Ora potrebbe essere nel punto (100,100,100), tra un minuto potrebbe essere nel punto (200,40,-6). Non possiamo percio' semplicemente calcolare il segmento che congiunge noi con la posizione dell'oggetto in questo istante: la rotta va invece aggiornata continuamente.
- I pianeti, le stelle, le stazione sono solide, e non ci passiamo passare attraverso. Se mi trovo nella posizione A, e voglio raggiungere il punto B, e in mezzo vi e' una stella gigante, dobbiamo dividere il viaggio in due tronconi, da A a un punto C fuori dalla stella, e da C a B.

Ad ogni modo ho iniziato questo grosso lavoro. Credo che riusciro' a domare questo grosso impegno solo suddividendoli in problemi piu' piccoli, pertanto per ora ho deciso di risolvere un problema piu' semplice: muovere l'astronave da un punto A ad un punto B, fermo, assumendo che l'astronave sia ferma al momento della partenza. Una rotta piu' complessa potra' quindi essere suddivisa in tante piccole rotte lineari che unite tra loro formeranno il percorso totale (avete presente il gioco della settimana enigmistica "unisci i numeri dall'1 al 50"? ecco).
Per poter raggiungere il punto B bisogna compiere due fasi, la prima che consiste nel ruotare l'astronave fino a quando il nostro "naso" punta esattamente in direzione di B, dopodiche' accelerare, viaggiare, ed iniziare la frenata per tempo.
Con oggi ho completato la prima delle due fasi: attivando l'autopilota, indipentemente dall'ortientamento della nostra nave, questa iniziera' a ruotare fino a quando avremo di fronte la nostra destinazione. Nel filmato che segue ho usato una stazione spaziale come destinazione. E potete notare che per quanto il nostro orientamento possa essere confuso, alla fine punteremo sempre verso l'obiettivo.
Non e' stato facile, l'astronave puo' ruotare lungo tre assi... ma pare funzionare!

Friday, September 26, 2008

Minor changes

Today new customers, new work, little time to spend on Tau Ceti.
However i've made some adjustment:

- Fixed the dimension of the ship: now il large 40 meters, not 4 kilometers :)
- Re-enabled the inertial motion. It's hard now to drive the ship, and with the planets that moves around his own orbits... argh!
- Outside view, now you can rotate around the ship in two direction: left-right and up-down (and combinations of these)
- Some minor tweaks.

---

Oggi nuovi clienti, nuovo lavoro, quindi poco tempo da dedicare a Tau Ceti
Comunque ho compiuto qualche rifiniura:

- Ho sistemato la dimensione dell'astronave. Ora e' larga 40 metri, non piu' 4 kilometri :)
- Ho riabilitato il movimento inerziale. E' difficile da pilotare la nave, e con i pianeti che orbitano.. argh!
- La vista esterna puo' essere ruotata attorno all'astronave in due direzioni, sinistra e destra, ma anche alto e basso (ed e' possibile combinare i movimenti).
- Qualche piccola ottimizzazione.

Wednesday, September 24, 2008

Rotating ship better than yesterday :)

No, is the same, but i've adjusted also the out-of-cockpit camera, so when i rotate the ship i can see the rotation from inside (the world rotate around me), or outside (the world does not move, is the ship that rotates).

You can see it in this little movie

--

Giusto un'aggiunta a quel che vi ho mostrato ieri. Oggi ho sistemato le rotazioni anche per la visuale esterna, cosi' se ruotate con la visuale interna vedrete l'universo girare attorno a voi, mentre se ruotate con la visuale esterna, l'universo ovviamente sara' fermo, mentre ruotera' l'astronave.

Eccovi un filmatino che vi mostra i due comportamenti

Tuesday, September 23, 2008

Rotating Ship

Back again.
Some problem at work (IT in italy is totally crap) so no time and no motivation to work on the game.
Anyway today i've found some energy and i've powered the ship rotation.
In 3D spaces there are 3 ways to move: up, forward and right (down, back and left are specular), and, obviously you can also rotate around these axis.
It's easy to mess when you starts to combine the rotations, so i've worked a little to find a polish way to do it.
In the next video you can see the three rotations. There's not inertial component for now, but i'll add it later.

---

Rieccomi.
Alcuni problemi al lavoro (L'informatica in italia e' uno schifo), e conseguentemente nessun tempo ne' motivazione per lavorare al gioco.
Ad ogni modo oggi son riuscito a rastrellare un po' di energia, e ne ho approfittato per migliorare i comandi di rotazione dell'astronave.
Nello spazio 3D ci sono 3 modi di muoversi: in alto, in avanti e a destra (in basso, indietro e a sinistra sono movimenti speculari). Ovviamente oltre a spostarsi e' anche possibile ruotare attorno a queste tre direzioni.
Sfortunatamente e' facile entrare in confusione, specie quando si iniziano a combinare tra loro diverse rotazioni (tralascio i dettagli per non tediarvi), cosi' ho dovuto sbatterci un po' la testa prima di trovare una soluzione pulita e semplice.
Per ora non e' abilitato il comportamento inerziale, ma lo aggiungero' senz'altro in un secondo momento. Nel video che segue potete vedere una piccola simulazioni delle rotazioni che e' possibile fare attorno ai tre assi dell'astronave.


Friday, September 12, 2008

True Orbits

Ok, finally i've reached the first step: simulate the solar system.
All the planets are added, now the orbits are ellittic, the dimension of each planet are right.
The orbit size are real, and the orbital period is correct (1 year for the earth i.e.)
In this little video you can see a zoom-out sequence, starting from venus.
When the camera zooms, the time speed is increased a lot so you can see the orbits.

---

Finalmente ho completato il primo passo importante: simulare il sistema solare.
Ho aggiunto tutti i pianeti, ho reso le orbite ellittiche, le dimensioni dei pianeti sono corrette, come lo sono le dimensioni delle orbite ed il periodo di rotazione (1 anno per la terra, ad esempio)
Nel video che segue vedete una zoomata che parte da Venere e si allontana progressivamente.
Quando la camera si allontana lo scorrere del tempo e' accelerato di molto, così potete vedere bene le orbite di ciascun pianeta.

Wednesday, September 10, 2008

[OT] Bad weather forecast...

No good news for the week end... (click to enlarge)

---

Brutte previsioni del tempo per il week end... (clicca per ingrandire)


Tuesday, September 9, 2008

August was a good month...

our customer was on vacation, our boss on the beach, and good time for me to work on the game :)
Now customer are back and are angry, boss are back and are angry, so i've no time. For now.
Be patience.. i hope to back in action in few days... if the world still exists after the LHC experiment ;)

---

Agosto e' stato un buon mese per tau ceti, gente in ferie, ambiente rilassato, son riuscito ad andare avanti. Ora il lavoro, come ogni buon settembre che si rispetti, e' ripreso piu' isterico che mai e quindi non ho tempo in questi giorni da dedicare al gioco.
Abbiate pazienza, spero che tra qualche giorno possa tornare sul "pezzo"... sempre che il mondo esista ancora dopo l'esperimento del LHC ;)

Monday, September 1, 2008

The Cobra

I'm in a hurry, so i'll be short:

I've worked a little on the cobra mk3 you've seen on my last video.
Now it's a little better, but i've to work on it.
I don't like the hull texture, but it gives more depth to the mesh.
The engines now are the original engine of Frontier (and not the ugly cylinders i've used before..).
Do you want to comment? You're welcome





Son di corsa, cosi' saro' breve:

Ho lavorato un po' sull'astronave del giocatore, il cobra mk3, cercando di renderlo un po' piu' decente rispetto a quello che vi ho mostrato nel video precedente.
Ora mi sembra un po' meglio.
Non mi piace molto la texture dello scafo, vorrei trovare qualcosa di meno piatto, comunque rispetto alla versione precedente e' gia' un bel passo avanti.
I motori dell'astronave ora sono quelli usati su Frontier e non piu' quegli orribili cilindri che avevo messo in precedenza.

Ogni commento e il benvenuto ovviamente.


Friday, August 29, 2008

Distance

I've fixed the oustide camera, now i'ts a little up so you can see your starship well.
There was a bug with the up vector (the vector that tells where's the "up" direction), and the rotation around the ship was very odd, but now it works well.
Ok, the camera is near finished (i hope), now is the time to upgrade a little the HUD.
Until today HUD shows the position and the name of every object on the sector, with an hexagon if the object is inside the view area, or with some arrows if it's outside.
Now the HUD display also the distance, and use a confortable measure unit.
If you're near to an object, VERY near, the distance is displayed in meters.
Until 1.000.000 km it's displayed in kilometers.
Otherwise, the AU is adopted (1 AU, aka Astronomic Unit is the distance between the sun and earth).
Down you can see two screenshot that displays objects near and far.
I hope you like it.

----

Allora, ho finito di lavorare alla telecamera, spero quasi definitivamente.. ho sistemato la visuale esterna aggiustando l'altezza, in modo che ora sia possibile vedere la propria astronave da un piano un po' piu' in alto. Inoltre ho risolto un baco che mi sballava il vettore "UP", ovvero quello che, dato un sistema di riferimento, indica dove si trova il "sopra".
Fatto questo ho deciso di trascorrere il poco tempo rimasto prima del week end per aggiornare ulteriormente l'HUD. Da oggi infatti questi visualizza anche la distanza dell'oggetto da noi. E lo fa utilizzando un'unita' di misura conveniente. Per oggetti molto vicini la distanza viene espressa in metri. Per oggetti fino a 1 milione di km, la distanza viene ovviamente espressa in kilometri. Per oggetti ancora piu' lontani infine vengono usate le unita' astronomiche (AU). Ricordo che 1AU corrisponde alla distanza che c'e' tra la terra ed il sole.
Vi lascio con due screenshot che vi mostrano come funziona il tutto.

Buon week end.


Thursday, August 28, 2008

Welcome

Da oggi ho deciso di postare i miei messaggi in duplice lingua. In italiano ed in inglese.
Questo perche', con mia sorpresa, ho scoperto leggendo le statistiche che spesso ricevo visite anche da persone che stanno all'estero. Le quali ovviamente non sapendo l'italiano devono limitarsi a guardar le figure o più semplicemente (e probabilmente), chiudere la pagina per andar altrove.
Premetto che sono davvero scarso con l'inglese, riesco a farmi capire ma chi mi legge sicuramente ha di che ridere per la mia sintassi :)
Pertanto portate pazienza, e anzi se trovate errori madornali e volete segnalarmeli, ben lieto.

Grazie.

---

Hi.
My name is Claudio, i live in italy, and i'm trying to develop a game (my first game) using C++ and DirectX.
First of all: excuse me for my horrible english. Fortunately i code better than i write :) so i apologize for certains syntax-semantic-horror errors. I hope you understand the meaning of what i write, anyway if you want, fell free to write me, and help me to fix my errors.

The objective of this work is one: learn something about the game programming, the 3d graphics, how tool use and so on. I know that, on 2008, writing a game is not anymore a task for single and brave man. The videogame industry is now made of sofware house with hundreds of people, and a AAA game usually needs 100-150 men, and 4 years of develop.
So i know that it will be very very difficult for me to end this project. But i live day by day, i've no scheduled date, it's only an hobby, and (why not?) a dream..

Anyway the goal is to create a "clone" of the great "Frontier" of David Braben. Indeed, there are a lot of space-sim on the market, but no one was able to recreate the same feeling. Static universe, planets freezed on space, no seameless universe, sectors with ridicolous dimensions (i.e. a sector is 100km wide!), no inertial behaviour and so on.
So i want to try to recreate a space-sim that will be a SPACE game, but also a SIMulator.
I'm working on it since December 2007, so the same my blog.
Until now i'we used this blog like a "diary", here i write my progress, my difficult, my problem, and the solutions that i found, and i've used my language: italian.
But i've noticed that there's also a bit of visitors outside italy, and i'm pleased to try to narrate you my little adventure.

The game is obviously only at the beginning. I've not used any pre-builded engine, or existing source. All was done by scratch.
I use Microsoft Visual C++ 2008 Express to compile, Blender for the modeling, and Paint Shop Pro XI for the 2D graphics.
For the documentation i use the wonderful book of Frank Luna "Introduction to 3d game programming with directx 9.0c - A shader approach", and the excellent forum GameDev.net

Actually i've:
  • a prototype of galaxy map.
  • a prototype of engine that manage planet with real dimension and distance, stars with lens flare, camera inside and outside the cockpit, orbits, time acceleration and deceleration, and primitive inertial support.

in the previous post you can see some screenshot and video about it.
You have questions? Write me!

And welcome :)

Wednesday, August 27, 2008

Hud Reprise

In cantiere c'e' la gestione della telecamera. Come detto la volta precedente finalmente è possibile vedere la propria astronave da fuori, e ruotare la telecamera attorno ad essa. Ma il movimento e' ancora un po' impreciso e voglio sistemarlo una volta per tutte.
Nel frattempo, rileggendo il capitolo sugli sprites nel libro di Frank Luna ho scoperto che il mio approccio per la gestione dei medesimi era inutilmente complicato, cosi' ho approfittato per sfoltire e renderlo piu' semplice (ed ottimizzato).
Gli sprites attualmente li uso per le lens flare e per l'HUD e quest'ultimo devo essere sincero non mi e' mai piaciuto graficamente.
Cosi' oggi ho deciso di ridisegnarlo.
Vi mostro la versione vecchia e subito sotto quella nuova: secondo voi qual e' la migliore?
(ingrandite l'immagine clickandoci sopra per vederla a grandezza naturale)


Friday, August 22, 2008

telecamera esterna

Finalmente è stata implementata.
E' quindi possibile ora vedere la scena da un punto di vista detto di "prima persona", ovvero come se si fosse seduti realmente nell'abitacolo dell'astronave (quello che in fondo avete visto fino ad oggi), oppure da un altro punto di vista detto di "terza persona", ovvero da una telecamera montata fuori dall'astronave, la quale telecamera vi inquadra continuamente.
Nella visuale in terza persona, col mouse ruotiamo la telecamera attorno alla nostra astronave, per poterla vedere da dove piu' ci piace, mentre con la visuale in prima persona ruotiamo proprio l'astronave per scegliere la direzione verso la quale vogliamo andare.
Vi mostro un filmatino che ho appena realizzato.
La qualita' dell'astronave e' ancora pessima, non ci ho piu' lavorato, ed è messa li' solo come riferimento per ora. L'importante è che il programma funzioni, per disegnare poi c'e' sempre tempo.

Tuesday, August 19, 2008

Decisamente Blender!

In questi giorni ho voluto studiare per capire quale fosse il tool di modellazione più congegnale ai miei scopi, specie dopo i problemi relativi alle normali di cui vi ho parlato prima di Ferragosto.
Ho provato un pò di tutto, anche per capire cosa offre il mercato freeware.
Val la pena citare un progetto che ha scoperto mia moglie. Si chiama Art Of Illusion, è scritto completamente in java, ed è davvero meritevole. Ha persino un motore di ray tracing integrato con tanto di calcolo dell'illuminazione globale. Lo metto da parte, e non escludo che possa tornarmi utile in futuro.
In ogni caso sono arrivato a darmi una risposta: Blender fa assolutamente al caso mio, è un prodotto eccezionale, in grado di competere (e credo anche sconfiggere) molti software commerciali che costano migliaia di euro. Basta imparare ad usarlo.
Il problema delle normali l'ho risolto grazie ad un apposito modificatore che non conoscevo.
E ho scoperto le meraviglie dell'editor UV!

Val la pena che ne parli un pò, può tornar utile a chi magari ha deciso di modellare mesh per videogiochi (magari il mio, perche' no? :P )

Per rendere decentemente un oggetto 3D sono molto importanti le texture, ovvero le immagini che vengono proiettate sopra l'oggetto tridimensionale. Servono a darci profondità e credibilità, servono a rendere una sfera giove anziche' la terra, eccetera.

La sfida grossa sta nella scelta delle texture giuste e nel modo in cui applicarle all'oggetto 3D.
Per oggetti banali come cubo, sfera, cilindro, esistono delle formule matematiche che fanno il lavoro di "avvolgimento" dell'immagine rettangolare attorno alla mesh, ed è questo il sistema che ho usato per disegnare i pianeti.
Quando però il modello inizia ad avere un aspetto piuttosto complesso l'approccio matematico diventa improponibile. Fino a ieri usavo quindi l'approssimazione di considerare ad esempio la stazione spaaziale come un cubo. Ottenendo discreti risultati ma che non mi davano alcuna possibilità di poter aggiungere dettagli in una posizione da me scelta. Solo la trama ripetuta all'infinito, ad avvolgere l'oggetto.
Con Blender la soluzione diventa semplice, quasi divertente.
In sostanza si prende l'oggetto, e si finge che sia un pelouche (!)
Di questo pelouche si sceglono quali sono le cuciture che uniscono i vari pezzi di stoffa. La libertà è massima, quindi conviene sceglierle in zone dell'oggetto che sono poco visibili (esattamente come avviene nei pelouche).
Una volta definite le cuciture, con un semplice comando Blender provvederà a "tagliare" il nostro pelouche lungo le cuciture e ad appiattirlo sopra un piano.
Otteniamo quindi un'immagine bidimensionale che è possibile quindi dipingere con uno dei tantissimi programmi (PhotoShop, Paint Shop Pro, Gimp, ecc..). Una volta dipinta l'immagine piatta, Blender non farà altro che "ricucire" il nostro oggetto lungo le cuciture, riottenendo quindi la nostra mesh tridimensionale con le texture desiderate.

Utilizzando questa tecnica ad esempio son riuscito a scrivere con ottima precisione il nome "Tau Ceti" sotto il portellone di ingresso della stazione, e son riuscito inoltre ad aggiungere alla trama alcuni punti scuriti, altri schiariti, per renderla meno "artificiale" ma più realistica.
Purtroppo non sono un'artista e non so fare miracoli, però almeno per la stazione spaziale sto arrivando ad un risultato che considero quasi definitivo.

Ecco come su blender la stazione spaziale è stata ritagliata.
A destra potete vedere i vari "pezzi" risultati dalla procedura di appiattimento, con sotto le corrispondenti texture aggiunte con Paint Shop Pro (clickate sull'immagine se volete vederla più grande):


Ed ecco come appare il risultato finale all'interno del gioco (notate la scritta e i punti un po' scoloriti messi in maniera casuale):

Wednesday, August 13, 2008

Buon Ferragosto

Buon ferragosto a tutti i fortunati che hanno ancora ferie da spendere.
Ho letto più di uno di voi che si è dichiarato disposto a darmi una mano coi modelli 3D e mi fa davvero piacere.
Nell'attesa, come avete visto, sto cercando di metterci del mio.
Per poter creare mesh dimensionate in maniera corretta occorre avere un sistema di riferimento. Non posso fare una stazione spaziale con il portellone, per poi scoprire che attraverso quel portellone ci entra sì e no una formica :)
Così vanno fatte due cose:

  1. disegnata la mesh della nostra astronave
  2. va data la possibilità di poter vedere la scena anche da un punto di vista esterno.
Questo mi permetterà poi di creare il resto degli oggetti in scala.
Vi saluto quindi con il primi schizzi di astronave, e ovviamente altri non poteva essere che il Cobra MK III :)

Eccovi l'originale.



Ed eccovi i miei lavori in corso.


Tuesday, August 12, 2008

Blender o non Blender?

I lavori di modellazione 3D continuano, ancora siamo a livello di "pasticci", ma la qualità e' quantomeno migliorata rispetto agli screenshot di qualche mese fa.
Il problema con il quale però sto combattendo attualmente riguarda la qualità degli "smussi", ovvero la tecnica usata per far sembrare tondeggianti anche gli oggetti che invece sono spigolosi.


Una volta esportati con Blender gli effetti sono terribili.




Forse sbaglio qualcosa io ma...

Domanda: avete qualche buon editor di mesh da propormi? Cioe' non vorrei abbandonare blender, ma se non ne vengo a capo devo considerare anche qualche altro tool..

Wednesday, August 6, 2008

Paragone bis


...ovvero un'interpretazione artistica (rendering) della mesh che vi ho mostrato oggi.
(fatta con lo stesso blender)

Paragone

C'e' caldo, il lavoro scalpita, pertanto non c'è tempo per ora per dedicarsi al codice.
Nei buchi di tempo però, tra un import e l'altro, ho iniziato a pasticciare con blender, per cercare di creare delle mesh che non siano solo i 4 rettangoli di prova.
L'idea è quella di rifare la vecchia e famosa stazione spaziale di frontier. In fondo vorrei farne un rifacimento no?
Cosi' ecco i risultati di qualche pasticcio... sopra la vecchia stazione spaziale di frontier, sotto l'equivalente su Tau Ceti.
La gara e' contro David Braben, mi posso ritenere soddisfatto :)

Monday, August 4, 2008

Luci

Con l'implementazione del passare del tempo nel gioco, si può anche iniziare a pensare a gestire le animazioni.
Due ne avete già viste, ovvero la rotazione e la rivoluzione dei pianeti, un'altra semplice consiste nella gestione delle luci di posizione.
Avete presente le ali dell'aereo? Ciascuna ha una luce che lampeggia, per rendere l'aeromobile visibile anche al buio.
Sono sceniche, e portano via relativamente poche risorse, quindi perchè non implementarle?
E' sufficiente uno sprite,sul quale è stato sapientemente disegnato un flare, da far apparire in blend con lo sfondo.
Utilizzando il billboarding poi lo teniamo sempre orientato verso la telecamera, così da dare l'iillusione che sia sferico e non piatto.
Infine, utilizzando l'orologio lo accendiamo un secondo sì e uno no. Basta prendere i secondi e prendere il resto della divisione per due.
Col risultato che la frequenza con la quale pulserà dipenderà dalla velocità con la quale stiamo facendo scorrere il tempo.

Il filmato che segue illustra proprio il risultato. (ho messo una luce sola, siamo ancora a livello di tech demo)

Friday, July 25, 2008

Orbite

Le operazioni per l'implementazione del tempo procedono.
Attualmente ho un orologio, in grado di gestire il passare del tempo, con virtualmente qualsiasi velocita'.
Ovvero posso impostare il calendario al 7 luglio del 3273, e fare in modo che ad ogni secondo trascorso nella realta', nel gioco sia in trascorso un minuto, un millennio, sei millisecondi, eccetera.
Questo è indispensabile per poter poi regolare la fisica dell'universo, ad esempio le orbite dei pianeti.
La terra ruota su sè stessa in 24 ore, e orbita attorno al sole in 365 giorni, mentre la luna orbita attorno alla terra, per tutto ciò ovviamente serve un orologio, e per poterne apprezzare gli effetti si deve poter accelerare anche il passare delle ore.
Quello che segue è il primo esperimento un pò più serio di quanto avete già visto: la terra che per l'appunto ruota attorno al sole, e la luna a sua volta attorno alla terra, mentre la terra ruota effettua le sue rotazioni quotidiane.
Le orbite per ora sono circolari, non ellittiche, ma non è importante, l'importante è che l'orologio funzioni.

Monday, July 21, 2008

Luce solare

Prima di dedicarmi al calendario, volevo sistemare i problemi ancora presenti.
Uno di questi, nato dopo la ristrutturazione del codice, riguardava l'errata illuminazione del sole, ovvero i pianeti venivano illuminati come se il sole si trovasse in un posto diverso da quello effettivo.
Sistemata la faccenda, ne ho anche approfittato per ridurre l'intensità delle lens flares effettivamente troppo appariscenti.


E a costo di sembrare uno spaccone voglio dire che adoro l'aspetto che ora ha il sole, specie quando lo si vede da lontano!

Friday, July 18, 2008

Tempo

Fin'ora l'universo di Tau Ceti è rimasto perennemente congelato in quell'unico attimo indefinito, dovuto alla mancanza di tempo.
Ma il tempo è fondamentale per qualsiasi cosa, in primis per la creazione delle animazioni, ma anche per il calcolo delle orbite, della fisica.
La nostra terra ruota attorno a sè stessa in 24 ore, ad esempio.
Tempo, appunto: è arrivato il momento di implementarlo.

Ora, una delle sfide più grosse sarà quella di riuscire a regolarne il suo scorrere scegliendo diverse velocità: non posso ovviamente farvi giocare per 10 giorni di fila solo per raggiungere la Luna, anche perchè sarebbe un'esperienza molto noiosa.
Molto meglio poter accelerare il tempo nei momenti di calma, magari di 10, 100, 1000 volte, in modo da poter compiere lunghi viaggi in tempi ragionevoli, senza dover rinunciare ad un minimo di realismo.

Non sarà semplice, ci ritorneremo, per ora eccovi un video della terra non piu' immobile, ma che finalmente ruota su sè stessa.

Thursday, July 17, 2008

Lens Flares crescono..

Seguendo la scaletta delle cose da sistemare, che ho pubblicato il mese scorso, tra le varie attività vi era anche la manutenzione delle lens flares.

















































Al di là dell'aspetto grafico, che si risolve con photoshop e pazienza, quel che non andava bene era che la dimensione degli artefatti non dipendeva dalla distanza della fonte luminosa.
Creando cosi' effetti piuttosto brutti quando ci si avvicinava troppo al sole.
Ho sistemato un pò di cose e finalmente sono più soddisfatto del risultato, tanto che a mio avviso per quanto riguarda il sole si può tranquillamente togliere la mesh sferica e lasciare solo la lens.
Che ne dite?
Nel filmato potete anche farvi un'idea di com'e' venuto ora Saturno.


Monday, July 14, 2008

Buco Nero

Uno dei problemi con i quali ho combattuto fino a sabato scorso riguardava la definizione dei piani di clipping.
Tutte le schede video infatti, per guadagnare in prestazioni, permettono di impostare due piani, detti piani di clip, che definiscono la zona entro la quale gli oggetti devono essere considerati visibili o, analogamente, le due zone dello spazio nelle quali NON vanno disegnati tutti i triangoli che vi appartengono.
Il concetto che sta alla base di una simile decisione è abbastanza semplice ed intuitivo: un oggetto molto lontano da noi sarà talmente piccolo che difficilmente sarà anche visibile. Quindi tanto vale nemmeno disegnarlo, si risparmiano energie. E un oggetto troppo vicino idem, tanto vale considerarlo dietro alla nostra nuca e comunque non visibile.
Definiti sia il piano di clip "lontano", che quello "vicino", l'area racchiusa tra di essi, chiamata "frustum", è di fatto l'unica porzione dello spazio che viene considerata dalla scheda video, ed è anche la zona dove viene implementato lo z-buffer.
Z buffer che, mi serve per disegnare quei pianeti tipo Saturno, con l'anello, dove non è sufficiente affidarsi alle normali per evitare i problemi di facce nascoste.
Ora, lo spazio e' immenso, lo z-buffer no. Se, come detto, definisco un unico z-buffer per tutto il settore, esso avra' una risoluzione ridicola, essendo esso a 16 bit.
L'idea è quella quindi di racchiudere solo il pianeta dentro il frustum, e cambiare frustum ogni volta che disegno un altro pianeta. In questo caso le dimensioni saranno non più quelle dell'intero sistema solare, ma bensì del solo anello, e lo z-buffer in questo caso funziona decorosamente.

Fino a sabato ho combattuto come un disperato cercando di far star dentro al frustum il pianeta, con risultati pero' catastrofici, come potete leggere qui se ne avrete mai voglia.
Fortunatamente grazie al forum gamedev ho trovato chi mi ha fatto capire cosa sbagliavo ed ora Saturno non ha più buchi!

Monday, July 7, 2008

Di ritorno da Manhattan...

..in questo sciagurato paese, incapace di pensar ad altro che al calcio e a berlusconi, ancora fuso dal jet-lag, volevo salutarvi e approfittarne per affrontare un argomento.
Più di una persona mi ha contattato in privato chiedendomi se poteva in qualche modo collaborare al mio progetto visto che in effetti da solo le cose vanno molto a rilento.

La risposta è "sì, però".

Il però riguarda le mie promesse. Non posso infatti garantire assolutamente nulla sulla riuscita del progetto e sul mio impegno. Tau Ceti infatti nasce come mio esercizio individuale per studiarmi le directx, motivato da un periodo di forte "depressione professionale", dove di fatto passavo intere settimane in ufficio senza aver nulla da fare. Ed avendo io bisogno di dimostrare piu' che altro a me stesso che non sono solo uno capace di scaldare una sedia, anzichè passare le giornate col solitario ho deciso di investire il tempo libero in qualcosa di quantomeno più edificante.
A partire da Febbraio sono stato (prevedibilmente) spostato dal posto precedente, ed ora ho un'attività parecchio più intensa rispetto alla precedente, pertanto il tempo da dedicare a Tau Ceti è attualmente quasi nullo.
Ora, ovviamente, non posso trascurare il lavoro per il mio hobby, e pur non avendo alcuna intenzione di fermare i lavori, non posso nemmeno garantire che le cose riprenderanno a viaggiare come avveniva ad esempio in gennaio. A meno che qualcuno mi assuma e mi paghi per lavorare a Tau Ceti :), cosa purtroppo fantascientifica in Italia, dove l'informatica e' solo fogli excel, email, "urgente", e query incasinatissime su inutili gestionali.

Pertanto, ogni vostro aiuto è apprezzato e grato, ovviamente mi arrogo la facoltà di decidere se quel che ricevo è adeguato o meno al gioco (ovvero, non ve la prendete se la vostra bellissima mesh non verra' inclusa nel gioco, se mi mandate un drago o un comodino), ma per onestà vi devo avvisare che potrebbe trattarsi di lavoro fatto per niente. O magari con 20 persone che collaborano invece riusciamo a terminarlo.
Non lo so, avevo il dovere morale di avvertirvi, dopodichè grazie in anticipo a tutti coloro che vorranno dedicarmi del loro tempo.

Friday, June 20, 2008

Il punto della situazione

Ho probabilmente fatto l'errore di mettere troppa carne al fuoco, aprendo diversi fronti senza aver la pazienza di consolidarne nemmeno uno come si deve, e mi ritrovo adesso con la necessità di capire dove sono arrivato e dove voglio andare.

La schermata di questo post riassume un pò tutto quello che c'è e che in qualche maniera vorrei chiudere prima di passare ad altro, ovvero:

  1. Enviroment mapping: il cielo stellato e le nebulole di sfondo. Funzionano direi bene e qui l'unica cosa sulla quale val la pena lavoare e' forse la risoluzione del cube mapping, che ora appare un po' sfuocata. Non vorrei però esagerare, il rischio è quello di far diventare il fondale troppo pesante in termine di consumo di memoria della scheda video.
  2. Corpi celesti: Stelle, pianeti, funziona tutto bene. Per i pianeti devo raffinare la generazione dell'anello (vedi saturno) che ho lasciato in sospeso. In futuro ci sara' ancora da lavorare su multitexturing, atmosfera e rotazione-rivoluzione.
  3. Hud: A volte mi sballa un pò la posizione dello sprite, e devo verificare perchè. Per il resto funziona bene, finalmente non si limita a visualizzare solo i pianeti ma tutti gli oggetti che compongono l'universo. Con l'aumentare dei medesimi ovviamente occorrerà fare in modo che solo i più vicini siano visualizzati, altrimenti il caos regnerà sovrano.
  4. Lens Flares: Il meccanismo di base va bene, ma ancora non ci siamo. Il "glow" che racchiude la fonte luminosa deve essere ridimensionato in base alla distanza. Dev'essere quantomeno grande quanto la dimensione apparente della stella, quindi sarà da affrontare il problema del calcolo della dimensione in 2D di un oggetto 3D rappresentato a video. I vari artefatti poi non mi piacciono molto, e vorrei ridisegnarli. Senza contare il grosso problema della lens che appare anche quando la fonte luminosa è eclissata da un oggetto. Tenendo conto che lo z-buffer lo disabilito per buona parte del rendering, saran dolori..
  5. Mesh: Son diventate qualcosina di più di un semplice esperimento. Come si può vedere dalla schermata, anche loro vengono riconsociute da HUD e Radar. Ho messo due stazioni in modo da essere sicuro che non interferissero tra di loro. Ogni mesh puo' avere diversi materiali e texture, ma è ancora tutta da fare la parte relativa alle animazioni. Inoltre rimane irrisolto il problema dell'illuminazione degli oggetti concavi.
  6. Radar: Funziona, rappresenta i medesimi oggetti che sono disegnati dal HUD, certamente è ancora piuttosto grezzo nell'aspetto.
  7. Navigazione: Implementati i fondamentali, il moto è puramente inerziale, assolutamente inusabile nei combattimenti, e che richiede TROPPO tempo per la navigazione da un punto all'altro del settore. Va bene amor di realismo ma non posso ovviamente permettere che per raggiungere marte dalla terra siano necessari 4 anni.
  8. Codice: un po' meglio rispetto al caos che regnava qualche tempo fa. Ho fatto uso di ereditarietà, ho cercato di commentare quanto meglio potevo. Sicuramente si può far di più.

Qualche nota statistica.

  • L'archivio completo del progetto (compensivo di texture, sorgenti, eseguibili, informazioni di debug, e probabilmente anche tanta fuffa che potrei anche togliere) e' di 18 mega. Formato RAR
  • I sorgenti fin'ora sono divisi in 68 files tra headers, classi e shaders. Per un totale di circa 160 kb di puro codice.
  • L'eseguibile ha raggiunto la dimensione di 60 kb (!)


Thursday, June 5, 2008

Radar 2


Non senza qualche difficoltà ho finalmente sistemato il problema del radar che mostrava gli oggetti in posizioni non corrette quando si ruotava la visuale lungo la verticale, rendendolo così di fatto inutilizzabile.
Per la cronaca, la matrice di trasformazione tra coordinate assolute e relative alla posizione ed orientamento dell'astronave non era corretta, o meglio al suo posto andava utilizzata la sua inversa.
Il calcolo matriciale, specie in ambito tridimensionale, spesso è tutto tranne che intuitivo, e non nascondo una mia certa difficolta nell'evitare di far confusione, però devo ammettere che è uno strumento estremamente potente, in poche righe di codice si riesce a fare ciò che con la normale trigonometria diventa invece un pericoloso vortice di lunghe e caotiche forumle, nel quale è davvero facile naufragare.
Sistemato quindi il problema ho deciso di aggiungere l'indicatore di direzione (la freccia rossa che vedete in foto), che rappresenta costantemente la direzione verso la quale la vostra astronave si muove per inerzia, rispetto al vostro stesso punto di vista.
Indubbiamente è comodo, specialmente quando ci si vuole fermare: si orienta l'astronave in modo che la freccia rossa punti verso il "nord" del radar, e si accendono i retrorazzi, fino a quando la velocità non raggiunge lo zero.
Ma ovviamente non basta, la guida è ancora tutt'altro che comoda, e vanno studiati altri accorgimenti affinchè l'esperienza non diventi frustrante.
Un'altra cosa che ho deciso di implementare è la possibilità di cambiare la scala del radar.. quando si combatte ovviamente le distanze tra un'astronave e l'altra sono relativamente piccole, (direi sotto i 100 km), mentre quando si naviga tra un pianeta e l'altro ovviamente le distanze sono milioni di volte piu' grandi. E' chiaro quindi che, a seconda di quel che stiamo facendo, occorre utilizzare la scala appropriata.