Tau Ceti

Cockpit, Bloom (again), and better ship movements

2012-02-13T17:57:00.000+01:00

I have to decrease the bloom's strenght, and obviously the cockpit should be more refined but.. now the screen appears more rich :)

Laser, explosions and fleet

2012-01-30T17:39:00.000+01:00

100 starships trying to reach me.. But i've an AWESOME laser and i kill them! :)

(no sure that there's anyone reading this blog, so sorry for the short message...)

Seek and destroy

2011-12-14T17:07:00.000+01:00

The ship now rotates well to the right direction so i can implement a "seek and destroy" behaviour: the enemy ship follows me and tries to reach me despite of my movements.

It's not perfect but.. it works

Alignment

2011-12-05T17:21:00.000+01:00

In my few spare time i've tried to consolidate one big task that i wasn't able to finish in the previous years: a way to align, softly, an object to any direction.
I need this for a lot of different situation: my ship has to align to the station, when i activate the autopilot, an enemy ship has to align to my position for reach me, an homing missile has to follow my target, and so on.
Previously i tried to solve it using normal euler rotations but it was a mess, and i've left this way.
The solution is: quaternions and SLERP.

It's not my intention to boring you with maths details (but you can ask me if you want), i prefer to show you the result: a ship floating into space try to align with my position:

you can notice that when i move, the ship follows me, in all positions.. also when i go up or down.

..and you can see also (for a brief moment) my ship firing a laser :)

Slowly...

2011-10-06T17:34:00.000+02:00

Work, healt and other things are against me & tau ceti so no more news since june.
But no news is not no progress...
In these periods i've worked for improve the consistency of the engine.

Here the most important news

- Now coordinates of the universe are the same of the 3d engine. This means that i cannot use anymore realistic large scale for the universe, but i've seen that the "real thing" is for now too big (and boring). To reach a planet from another you needs lots of minutes, and i'm developing a game, not a simulator. The pros are that now shadows are more accurate.
- The internal structure of the object now is totally hierarchical, so Sun has 9 child, one of this is Earth. Earth has one child, Moon. Moon has one child: Space station (i.e.). If i move the Sun, i move also earth/moon/station automatically.
- I've started to update the look'n'feel of the gui.
- Now your starship can shoot, and i've implemented the collision detection. So if you hit another ship with your beam, the program can tell you "boom" and give the distance of the collision. It works also with complex object, and not unsing only AABB (bounding box) but with geometry.. so if you shoot at the center of a torus, the function return "false".
- You can attach a camera to any ship, so in future you'll be able to say the point of view of a enemy.
- Space station now has a (primitive) tunnel to help you in landing operations.
- LOTS of cleaning up.

System Map again

2011-06-14T16:59:00.000+02:00

I've work a little inside the map's code and now the system map is more usable.

You can see the Sun! In the previous video it was missing ;)
Every moon now is displayed with it's own orbit (in the video, you can see our moon)
Now there's also your ship position showed.
With the mouse wheel you can zoom in/out the map, with the right button you can rotate it, and with the left button you can translate your view position inside the map.
The map has his own GUI, for now only + and - button. When you switch from cockpit view to map view, also the GUI switches.
Planets are smaller than into the previous video.

Next step is to made the map interactive: when you left click on a planet, the camera points on it and the target for autopilot is setted.

June 2011

2011-06-06T16:32:00.000+02:00

Ok dude, i'm starting to work to the system map. Solar system is huge, and it's easy to lost in. I cannot display on hud all the planets because tere's a lot (moons, asteroids and so on..) so it will be a mess.
Solution: if you want to drive until "Callisto" (i.e.): open the map, select it and then activate the autopilot!
It's just the beginning but you can see now the orbits, the planets, and a different background. You can switch from map to cockpit with a gui button.

May 2011

2011-05-26T08:16:00.000+02:00

<br><br><br>ddd

A messy month for me: work, home and so on, so not too much time to develop my hobby.
But "not too much" != "no" so, something was done.

- A less raw stardust effect: the dust now are made by sprite, not by pixel, so there's transparency and the result is pretty. (see the previous video...)
- I've started to work to some classes for handle the "other ships" (enemy, friend and so on). But it's just the beginning
- I was (finally!!) able to use a bitmap font for the text on the hud. So, now we have a outlined font, more readable when text overlaps with another text.
- Worked a lot into shadow code. Now self shadowing seems to works: here a short video

- last, but not least, now the gui has also images, so i can make icons and not only text button.

Stay tuned for news.

Autopilot and Stardust.

2011-04-22T17:00:00.000+02:00

Now the autopilot works well: you select your destination with the mouse, then the autopilot aligns your ship with the target, thrust the engine until you've made an half of the voyage, and finally brake near the destination... there's something to refine but it works!
I've also added "stardust" to give more depth to the starship speed.. the dust is white for now: i've choose this colour so you can see it into the low-resolution video :). Now it looks like the old Braben's game "Frontier"
I'm thinking how to brake the ship.. using the inertial behaviour is a bit annoying: you've to align the ship to the current speed direction and brake.. if you brake too much the ship moves backward (you can see it at the end of the video), and if you do not align well you create some side movement. In one phrase: it's very difficult to stop a ship manually using an inertial engine.
So it should be less realistic but more usable a brake that doesn't changes the speed direction but his lenght. If i divide the x,y,z component of speed by i.e. 1.01, i don't need to align the ship to brake and i can make some more complex maneuvers...

Happy easter to everybody.

2011-04-18T10:48:00.000+02:00

Time to improve (and rewrite) the autopilot.. now i can select an object using the mouse, the next step is to move my ship to the selected destination.
The autopilot is a state-machine that has a lot of step, but you can summarize it into two big "macros":

align the ship to a selected direction
move the ship (or stop it).

This is the first step: the alignment phase. I need to align to a specific direction regardless of the initial orientation of the ship.
I need a function that give me the thrust power of the engine from the angle between direction and final orientation: the more distant i am, more power the engine should provide. Otherwise, when the angle is small, the engine should provide less energy.
A good solution is to use the dot product between destination vector and right/up vector. The dot product between u and v is defined like |u||v|cos(angle) where angle is angle between u and v. If u and v are unitary, the cross product give me the angle.

For yaw, the cross product between destination and right is a function that is = 0 when right is normal to direction (and it's true when direction is equal to destination..), is > 0 when direction lies left to the destination, <0 when direction lies right. Perfect for my needs!
Finally, i've to normalize for angles > 90 degrees:

if (angle > 90)
{
   if (dotproduct > 0)
      dotproduct=1;
   else
      dotproduct=-1;
}

For pitch is the same, but i use the up vector instead right.
The result is shown in the video.
There's some "freeze": is an issue of my laptop (i've some problem with vista and the hard disk drivers..), not of the game :)

Camera roll and mouse gesture

2011-04-11T11:20:00.000+02:00

At least the camera control is almost finished: now you can pitch, yaw and roll, so you can do almost all movement into space.
So i've started to work to the mouse gesture: i've a GUI, and now is time to create some interaction between the mouse and the 3d world.
In this video you can see the ineractions between pointer and mesh.. when you left click in any mesh, its bounding box is displayed. Notice: when two mesh are aligned (i.e. the station and the planet) when you click on both, the engine selects the nearest.

A message for Yombo (but also for all who can help me)

2011-03-23T20:44:00.002+01:00

I write here because i've no way to put all into twitter :) and because i haven't your email address.

I'll talk about my issue with quaternions.

So, i've changed a lot the code, hoping that it solves my problem but nothing changes.

Now the "lookAt" function doesn't receive a vector, but two angles: pitch and yaw. First i compute the pitch rotation (Quaternion q), then the yaw rotation (Quaternion r), and last multiply the two quaternions and rotate the camera using the result.

void MyCamera::lookAt(Ogre::Real pitch, Ogre::Real yaw) {

Quaternion q(Degree(pitch), Vector3::NEGATIVE_UNIT_X);
Quaternion r(Degree(yaw), Vector3::NEGATIVE_UNIT_Y);
q=q*r;
mCamera->rotate(q);
}

This is what happens.

in the upper-left panel now i display the "right" vector of the camera. Ok?

First i rotate around Y axis (yaw), keeping pitch==0 all the time: you can see that right vector has his y coords always = 0. It's correct: the y component of right vector defines the "roll" rotation. If it's always 0, camera does not rolls.
Next i rotate around X (pitch), keeping yaw==0 al the time. Now the right vector is = (1,0,0), always. In the video you can see not properly (1,0,0) because of the Ogre::Real resolution, but it's something like (1,0.00000001,0.00000001). And it's correct; when i pitch changes the look at, changes the up vector, but the right vector remains normal to plane YZ. Again: the y component of right vector is always = 0, so no "roll" of the camera. Perfect.
Finally i unlock both rotation and start to combine it: the camera starts to roll, and you can see tha the y component of right vector grows... if it's > 0 camera rolls left, if it's <>

My questions now are: WHY!?!? What's wrong? And what is the correct way?

Thank you for the patience. I'm a noob about rotation.

Solution not found :(

2011-03-22T12:14:00.002+01:00

Hi guys.
I've follow your suggestion about use quaternions to rotate my camera into the space and the upside/down problem that i had using the lookAt method of the Camera class, seems to be fixed
(here the previous video to show you)

Before i've used the spherical coordinates.. when you move the mouse in x direction i change the yaw angle, and when you move in y direction i change the pitch angle.
After modified the angles, i compute the unitary vector that represent the orientation of the camera:

   direction.x=sin(yaw)*sin(pitch);
   direction.y=cos(pitch);
   direction.z=sin(pitch)*cos(yaw);

Finally i use the "lookAt" method to orientate the camera along the "direction" Vector3.
But the side effect is that, when pitch angle go outside the interval (0,PI), the camera flips upside down.

So, i've changed the approach.. no more lookAt but quaternions.

void MyCamera::lookAt(Vector3* dir) {

  //no more used
  //mCamera->lookAt(dir->x,dir->y,dir->z);

   Vector3 src =  mCamera->getDerivedOrientation() * Vector3::NEGATIVE_UNIT_Z;      // Orientation from initial direction. Camera points to (0,0,-1)
   Quaternion quat = src.getRotationTo(*dir);
   mCamera->rotate(quat);
}

And this is the result:

i've changed the starship mesh with a more clear xyz axis mesh: x is in red, y in green and z in blue.
First i try to do a yaw rotation, around the Y axis... it works fine.
Then pitch rotation and.. well! it works! no more upside-down.
But.. when i combine both and give freedom to camera move something strange happens: moving it cause a side effect: some roll rotations starts to appears and the more i rotate clockwise my mouse, the more the roll appears... and rotating the mouse in other direction changes the roll direction too..

Why??

And how can i remove it?

Find a solution?

2011-03-21T20:41:00.000+01:00

Pheraphs yes...
Using the quaternions.

Stay tuned :)

I need a little help.

2011-03-19T18:42:00.003+01:00

I'm just stucked inside a small but annoying issue and i'm tired and unable to find an elegant solution.
So i'll post here my problem to see if there's someone could help me..

I'm working on orientation of our spaceship.
The ship has two vector (Vector3): the position and the orientation. The first is the position of the ship in space, the second should be a unitary vector that represent the "lookAt" orientation (in local coordinates).
If you're sitted on the cockpit, this represent the direction you're looking to.

To implement this i've used the spherical coords, so, to obtain the vector:

orientation.x=sin(fi)*sin(theta);
orientation.y=cos(theta);
orientation.z=sin(theta)*cos(fi);

where fi is the yaw angle, and theta is the pitch angle.

It works fine for yaw, but.. for pitch, when the angles become less below zero or greather than PI, the screens flips! (look at 0:17)

I think that the issue should be that when theta is outside (0,PI), sin(theta) is <0, and both x and z become negative, and in some ways it invert the up-right vectors.
You can see it into the video: on the upper-left panel there's the ship position and ship orientation (you should use 720p resolution to see the numbers)
For now i've limited the rotation from 0 to PI but it's ugly.. i'd like to pitch and yaw without restricts, i'd like to make loops with my ship without this glitch.
Any idea?

Thank you.

Spaceship adrift near the sun

2011-03-15T14:16:00.001+01:00

I've taken a mesh from a 3ds model and tried to import it into my game.
Sorry for the glitches: i've some problem with the hard-drive drivers...

GUI - updated

2011-03-08T16:38:00.003+01:00

A screenshot just to show you how appears the widgets: you can see a vertical slider, a checkbox, a combobox, a text field, a static text area, a button. And there are LOTS more..

GUI

2011-03-08T10:36:00.002+01:00

It was a complicated year. My job goes well, but this kill any spare time about Tau Ceti
Anyway, after a long pause, i've restarted (again!) to work on it and i've inserted, finally, a good GUI engine.
It's the CEGUI project, that is a "free library providing windowing and widgets for graphics APIs / engines where such functionality is not natively available, or severely lacking. The library is object orientated, written in C++, and targeted at games developers who should be spending their time creating great games, not building GUI sub-systems!".
There's a visual editor and you can insert LOTS of widgets: buttons, checkbox, dropbox, text area, and so on.. i've integrated it into Tau Ceti and it works.
For now i've added a single button: "QUIT" :) but works well and is very easy to manage, and it integrates perfectly inside the 3d scene.
When i've a more complex scene, i'll show you some examples.

News are incoming...

2011-03-07T15:59:00.001+01:00

Stay tuned...

Asteroids Field

2010-07-01T16:23:00.002+02:00

Time to load the engine a bit.
So, ladies and gentleman... a 1500 asteroids field.

May 2010

2010-05-12T10:52:00.002+02:00

In these days i've little time, but i've regained my motivation.
So no exciting news, but im going deeper in ogre to learn how to use it.
I've bought some books, and it looks like very interesting!

Pro OGRE 3D Programming, by Gregory Junker. It's an introductional guide to the engine. There's no "hardcore" sessions, but it's essential to learn about all the philosophy behind ogre. Ogre webpage is full of informations (wiki, documentations, forum).. but it's a bit difficult to learn how to use it starting from scratch, a book imho is essential.
Game Coding Complete, 3rd edition by Mike McShaffry. A wonderful guide about how to write a game, the right steps, tips, common mistakes, and a lot of algorithms. Mike was a game developer of "Ultima" series and "Thief" series. So he KNOW how to do it.
Real Time Rendering by Tomas Akenine-Moller, Eric Haines, Naty Hoffman, a wonderful Bible about the real time tecnique, and all state-of-the-art algorithms.

Anyway, i've rearranged all my code, rewriting all from scratch. And i've reintroducted the HUD that was not present on previous video

Camera

2010-04-20T22:53:00.003+02:00

Previous video was affected by an ancient issue: the camera is too much "nervous", so when you see it you could suffer some headache!

So i've implemented a tracking option (with previous version there was no "built-in" solutions), and i've tracked the camera to the moon..

This is the result, and i think that it's nicer.

First Ogre Video

2010-04-20T14:29:00.002+02:00

Just to show you Ogre3D in action.
Don't look to distance, dimension, time, it's only a demo tho show you how ogre works, especially with shadows....

Ogre again

2010-04-19T09:49:00.002+02:00

Ok, despite to lack of time, i've finally choose to adopt the Ogre enviroment.
It's robust and enough powerful for my needs.
I'm making little steps to learn how to use it. It's quite simple, but it has some little lack, especially on the 2D side.

Anyway, until now, i've recreate sky doom, lens flares, planets and shadows.

Here a screenshot..

First Screenshot using Ogre3D

2010-03-24T10:32:00.004+01:00

Ok, you' ve seen this a lot of time, but there's an important difference: this screenshot was made using the Ogre3d engine to render the scene.
The source is very small, so small that i post it here!
And, if you examine the image you can see two important news:

- Shadows are in hi-res and very realistic.
- Anti-Aliasing is implemented

The source?


#include "ExampleApplication.h"

class TutorialApplication : public ExampleApplication
{
protected:
public:
 TutorialApplication()
 {
 }

 ~TutorialApplication() 
 {
 }
protected:
 void chooseSceneManager(void)
 {
  mSceneMgr = mRoot->createSceneManager(ST_EXTERIOR_CLOSE);
  ResourceGroupManager::getSingleton().initialiseAllResourceGroups();

 }

    virtual void createCamera(void)
    {
        mCamera = mSceneMgr->createCamera("PlayerCam");
        mCamera->setPosition(Vector3(0,10,500));
        mCamera->lookAt(Vector3(0,0,0));
        mCamera->setNearClipDistance(5);
    }

    virtual void createViewports(void)
    {
        Viewport* vp = mWindow->addViewport(mCamera);
        vp->setBackgroundColour(ColourValue(0,0,0));
        mCamera->setAspectRatio(Real(vp->getActualWidth()) / Real(vp->getActualHeight()));   
    }


 void createScene(void)
 {
        Entity *ent;
        Light *light;

   mSceneMgr->setAmbientLight( ColourValue( 0.1, 0.1, 0.1 ) );
           mSceneMgr->setShadowTechnique( SHADOWTYPE_STENCIL_ADDITIVE );

    
        mSceneMgr->setSkyBox(true, "Examples/SpaceSkyBox2");

        ent = mSceneMgr->createEntity("Station", "Mesh.001.mesh");
        ent->setCastShadows(true);
        mSceneMgr->getRootSceneNode()->createChildSceneNode()->attachObject(ent);

 light = mSceneMgr->createLight("Light1");
        light->setType(Light::LT_POINT);
        light->setPosition(Vector3(30, 150, -250));

        light->setDiffuseColour(1.0, 1.0, 1.0);
        light->setSpecularColour(1.0, 1.0, 1.0);



 }
};

#if OGRE_PLATFORM == PLATFORM_WIN32 || OGRE_PLATFORM == OGRE_PLATFORM_WIN32
#define WIN32_LEAN_AND_MEAN
#include "windows.h"

INT WINAPI WinMain(HINSTANCE hInst, HINSTANCE, LPSTR strCmdLine, INT)
#else
int main(int argc, char **argv)
#endif
{
 // Create application object
 TutorialApplication app;

 try {
  app.go();
 } catch(Exception& e) {
#if OGRE_PLATFORM == PLATFORM_WIN32 || OGRE_PLATFORM == OGRE_PLATFORM_WIN32
  MessageBox(NULL, e.getFullDescription().c_str(), "An exception has occurred!", MB_OK | MB_ICONERROR | MB_TASKMODAL);
#else
  fprintf(stderr, "An exception has occurred: %s\n",
   e.getFullDescription().c_str());
#endif
 }

 return 0;
}

Nothing more.

---

Eccovi la prima immagine ottenuta usando il motore Ogre3D. Lo so, e' uguale a un sacco di altre che ho postato in precedenza, pero' la novita' fondamentale e' che e' stata ottenuta implementando il mio materiale dentro al nuovo engine.
E la cosa sorprendente e' che e' stato davvero facile! Il sorgente che potete leggere qui sopra e' tutto cio' che serve per ottenere una telecamera mobile, uno skybox, una mesh e delle ombre.
Tra l'altro le ombre sono molto piu' precise di quelle che ho ottenuto io con l'approccio "fai da te". E tra l'altro e' arrivato "gratis" anche l'antialiasing.

Tau Ceti is dead?

2010-03-17T23:28:00.003+01:00

Briefly: i've received a lot of question about the Work-in-progress status. The answer is: i've no time, unfortunately. So i cannot spend hours per day into it.
So i've understand one thing: it's impossible to write all by myself.. i need an help for the engine part.
So i've searched for a 3d engine freeware-open source.. i've tried UDK but it's too complex and too much fps oriented. Not suitable for a spacesim.
Then i've tried ogre3d and... it's ok! Simple and powerful, in few hours i've made the same thing i've made by myself in one year!
So Ogre3d is become my engine for the game so i'll can spend my time only into the gameplay!
I need some days to undestand the basics, to convert all the meshes or skydome and then i hope to really make some other steps!

---

Probabilmente si', si sapeva del resto.
Pero' c'e' una speranza.
Preso atto che da un anno a questa parte non ho quasi mai tempo da dedicarci, e che quindi l'idea di scrivere un engine da zero e' pura follia, ho deciso di appoggiarmi ad un engine di terze parti.
Ho provato udk ma, onestamente, non fa al caso mio: estremamente complesso, si sposa sicuramente bene con gli fps-tps classici, ma per farci il "gioco qualsiasi" c'e' talmente tanto lavoro di sviluppo che probabilmente si fa prima a scrivere tutto in C++. Molte attivita' vanno fatte attraverso l'editor dei livelli, che mi serve a ben poco vista la natura procedurale del mio gioco.
La documentazione e' poi quella che e', essendo un prodotto commerciale solo in seguito rilasciato freeware non ci si possono aspettare gran tutorial ed esperti online pronti ad aiutarti se non ci capisci un accidente.
Pertanto l'ho accantonato.
Ho provato Ogre3D e... in mezza giornata ho ottenuto gli stessi risultati che ho ottenuto in un anno di sviluppo!
Il suo e' un approccio parecchio old-style: una serie di librerie e dll da linkare al proprio sorgente per chiamare i vari metodi.
Questo mi mette a mio agio nella scelta di come organizzare il lavoro, e contemporaneamente mi libera dal "fardello" di dover occuparmi di tutto cio' che riguarda il 3D.
Posso insomma concentrarmi di piu' sulle meccaniche di gioco piuttosto che sul rendering.
Inoltre ho visto che ha diverse belle features. Le ombre si fanno in un attimo, effetti nebbia, landscape, sky dome, e tante altre cose si realizzano con UNA LINEA.
Cosi' ho deciso di farlo mio ed e' diventato ufficialmente l'engine del gioco.

FPS

2009-10-04T11:54:00.002+02:00

After the BIG disappointing with the last games on PC (NFS, Risen) with a framerate under the 20, i need some smooth movements on my screen ;)

Back Again

2009-10-01T11:14:00.002+02:00

Wait please...

2009-02-25T19:08:00.002+01:00

I've just changed my job, i'm waiting for a new laptop and i'm working hard.
No time for now to dedicate to the game.
Be patient :)

--

Ho appena cambiato lavoro, e sono in attesa di un nuovo laptop. E comunque ci sto dando parecchio dentro quindi anche volendo il tempo da dedicare al gioco non ci sarebbe.
Abbiate pazienza :)

Long Trails into the Outer Space

2009-02-04T08:59:00.002+01:00

I should refine a bit, the trails are exaggeratedly long and they not fade out, because i want show you well the effect.
The trails do not follow well the ship when it rotates, there's a lot to do, anyway i like it!
It's intresting to notice how the bloom effects improve the illumination of the scene: you can see some red reflection on ship hull, due to the engine trails.

---

Devo sistemarle un po', le scie sono esageratamente lunghe e non si spengono via via che si allontanano dall'astronave, ma e' un effetto voluto, volevo si vedessero bene nel video, ovviamente non e' cosi' che dovranno essere nel gioco.
Inoltre le scie fanno fatica a star dietro all'astroanve quando questa ruota, quindi c'e' ancora un po' di lavoro da fare, ma il risultato mi pare gia' interessante!
Da notare come l'effetto bloom contribuisca a rendere l'illuminazione piu' realistica (si notano i riflessi rossi sul corpo dell'astronave)

My Wife

2009-01-28T11:32:00.006+01:00

My wife gave me a suggestion, and i try that it's better than the previous effect.
What do you think about it?

--

Mia moglie mi ha dato un suggerimento su come implementare la scia, ed in effetti mi sembra decisamente meglio ora rispetto a prima.

Che ne dite?

Engine Trails: what do you think about it?

2009-01-27T17:02:00.004+01:00

I'm working now to the starships engine trails, an effect that i love (on Homeworld i've seen the best trails of ever!), and i've finished the first prototype.
But.. i'm not sure about it.
So before continue i want to show you the effect and ask you if you like it, if you change something, and any comment that you want to make.
It's difficult for a developer to be objective on his work, so i need some critics ;)

Tell me!

---

Sto lavorando alle scie che vengono lasciate dai motori delle astronavi, un effetto che personalmente adoro (su Homeworld ho visto le migliori in assoluto), ed ho appena terminato un prototipo.
Pero'... non son sicuro del risultato.
Cosi', prima di continuare, avrei piacere se mi deste un vostro parere, se vi piace, se cambiereste qualcosa, e qualsiasi cosa vi passi per la testa.

E' difficile per me essere obiettivo riguardo al mio lavoro, cosi' ho bisogno di un po' di critiche :)

Time to try

2009-01-23T10:51:00.004+01:00

A lot of people asked me to try a demo of my work.
So... why not?

Download from here

(if it doesn't works, try to copy the address: http://pdg.altervista.org/Tau_Ceti.rar and paste into another browser window-tab" option)

But... there's some problem that i was not able to solve: when i compile, it works on my pc, but when i try to run on others, i obtain an error like "d3dx9_37.dll not found".
I've discovered that you need to install the latest version of direct, i hope you need only the redistributable version of directx, but pheraps you need the sdk archive.
If you've time and enough speed on your line, download the archive here.

To use the demo:

extract the archive where you want
launch tau ceti.exe
if you obtain errors like "dll missing", update your directx using the link above.

The demo has a lot of key to press

move the mouse while keeping the right mouse pressed: rotate the camera
WASD move the ship. W and S accelerate and decelerate (inertial) , A and D rotate around the Y axis
PLOK rotate around X and Z axis
8246 on numpad: move the ship (no inertial)
5 on numpad: stop the ship (if it's moving by inertia)
F1 to F10 select the time compression.
1 to 10 select the speed compression (works only with the numpad moving)
F fullscreen mode (ESC to back to window mode)
V inside-outside view. In outside view, key + and - of numpad zooms out and in.
BN adjust the display size

It's obviously only a tech demo, there's no game and for now only 2 or 3 planets.

---

Me l'avete chiesto in tanti, e pur essendo il tutto ancora un cantiere e non certo un gioco, ho deciso di provare a rilasciarvi l'eseguibile, cosi' che possiate pasticciarci.
E' ovviamente un semplice tech demo, non c'e' gioco, e tra l'altro alcune mesh che avete visto in passato sono momentaneamente disabilitate causa lavori in corso.
Non aspettatevi chissa' che, ma se siete curiosi eccolo qui:

Scarica demo Tau ceti

(se non vi funziona provate a copiare l'indirizzo http://pdg.altervista.org/Tau_Ceti.rar e ad incollarlo in una nuova finestra o tab del browser)

A quanto pare per girare richiede l'ultima versione delle directx.. ho provato invano a litigare col compilatore affinche' possa girare su un qualsiasi sistema che abbia le directx 9.0c, ma a quanto pare invece vuole proprio l'ultima versione, altrimenti vi da un errore tipo "manca la dll d3dx9_37.dll".
Io spero che installando l'ultima versione vi funzioni, altrimenti, se avete tempo e banda, installatevi la sdk di microsoft che trovate qui

L'installazione e' semplice:

Scaricate la demo
Decomprimete l'archivio in una directory qualsiasi.
Lanciate "Tau Ceti.exe". Se vi da l'errore "manca la dll" di cui sopra, scaricatevi l'sdk dal link che vi ho dato.

Se il gioco parte (vi appare la terra in una finestra) ci sono un po' di tasti che potete usare

Tasto destro del mouse, tenuto premuto, e muovendo il mouse: sposta la telecamera
WASD per il movimento: WS per accelerare decelerare (inerziale), AD ruota attorno l'asse Y
PLOK ruota attorno gli assi X e Z
8246 del tastierino numerico sposta l'astronave (movimento non inerziale)
5 del tastierino numerico annulla l'eventuale inerzia (se vi state muovendo, si ferma di colpo)
da F1 a F10: compressione del tempo
da 1 a 0: selezione della velocita' di spostamento quando si usa il tastierino numerico per muoversi
F passa a tutto schermo (ESC per tornare a finestra)
V seleziona le visuali interna o esterna dell'astonave. Se siete fuori dall'astronave con i tasti + e - del tastierino numerico ingrandite o rimpicciolite l'astronave.
BN regola la dimensione dello schermo.

Insisto: e' tutto un cantiere, e' pieno di schifezze qua e la, e non sarebbe dignitoso nemmeno come screen saver, ma ovviamente ho piacere se mi date il vostro feedback una volta che siete riusciti a farlo partire
(E se mi spiegate come riuscire ad eliminare la dipendenza da quella ddl mi fate un piacere!)

Bloom inside the Game

2009-01-20T13:22:00.002+01:00

Ok, now is time to implement the bloom effect inside Tau Ceti engine.
There's no more to say: implementation was easy, and you can see the result on next video.
There's some imperfection on bloom dislocation, it seems that it is a little shifted on right, anyway do you like it?

The bloom is exaggerated intentionally due to the low quality of youtube so you can notice it.

--

Bene, e' tempo di implementare quanto visto nei giorni scorsi all'interno del gioco vero e proprio.
C'e' poco da dire: il lavoro e' stato per fortuna semplice e ne potete vedere il risultato nel video che segue. Ci sono ancora alcune imperfezioni, gli aloni sono un po' spostati a destra rispetto alla posizione che dovrebbero avere, ma mi sembra che il risultato sia comunque soddisfacente. Ovviamente cerchero' di limare questi problemi.
Ad ogni modo che ve ne pare?

Ah il video mostra una luminescenza un po' esagerata, questo per permettere che si possa notare anche con la bassa qualita' di youtube.

Bloom: finished!

2009-01-16T17:34:00.004+01:00

Ladies and Gentleman...

The bloom shaders!

Was obtained with 9 different post-process effects!

I'm very happy :)

--

Signore e signori...

Ecco l'effetto bloom!

Ottenuto con 9 differenti passaggi di post-processing!

Sono molto contento :)

Bloom: first steps

2009-01-14T17:00:00.002+01:00

I've made some other important steps into the bloom implementation, using pixel shaders. I've discovered how to make a "pipeline" of pixel shaders, a necessary tool to make complex effect like Bloom or HDR.
We have seen, last time, that to make a bloom effect it's necessary to execute more than one shader in sequence.
The effect is obtained:

scaling down the original picture by 16 times
isolating only bright parts of the reducted image
blurring orrizontally and vertically the bright parts
scaling up the result
merge the scaled result with the original frame.

The problem was: how can i use the shader output like input for the next shader step?
I've found a trick:

I draw the entire scene and i render it into a texture. I'll call it TexA.
I draw a rectangle that fills all the screen, and i apply the texture TexA on it. Then i render it using the first shader. I'll call it ShaderA. The result is not drawed into back buffer (the screen), but into another texture. I'll call it TexB.
I draw another rectangle, idendical to the previous, and i apply the teture TexB on it. Then i render it using the secon shader. I'll called it ShaderB. Now if there's no more shaders on the pipeline i'll put it into the back buffer, otherwise i'll iterate the procedure using other textures (TexC, TexD and so on...) one for each shader. To optimize the memory usage i can use only two texture and swap it every cycle.

It works! In the next video you can see a result of applying two pixel shaders to the same scene: a blur effect, then a simple light effect. It's not the final result that i want to obtain but it's essential to make all the trip.

---

Ho fatto alcuni importanti passi nella realizzazione dell'effetto bloom usando i pixel shader. Risultato che non serve esclusivamente ad ottenere l'effetto bloom, ma anche per la realizzazione di molti effetti complessi come ad esempio l'HDR, il motion blur e tanto altro.
Abbiamo visto la volta precedente che per ottenere l'effetto "bloom" e' necessario eseguire piu' di uno shader in sequenza.
Nello specifico l'effetto e' ottenuto:

rimpicciolendo di 16 volte l'immagine originale
isolando le parti luminose dall'immagine rimpicciolita
sfuocando orrizontalmente e verticalmente le parti luminose
ingrandendo di 16 volte l'immagine sfuocata
fondendo assieme l'immagine appena ingrandita all'immagine originale.

Il problema che mi bloccava fino ad oggi era: come puo' l'output di uno shader essere usato come input per lo shader seguente?
E mi e' venuta un'idea:

Disegno la scena intera all'interno di una singola Texture anziche' sullo schermo. Chiamo per semplicita' questa texture TexA.
Disegno un rettangolo che riempia l'intero schermo e vi applico la texture TexA. Dopodiche' lo elaboro con il primo shader, che chiameremo ShaderA. Il risultato non lo mostro a video ma lo metto in una seconda Texture, che chiamero' TexB.
Disegno un altro rettangolo, identico al precedente, solo che a questo applico la texture TexB. Dopodiche' lo elaboro con il secondo shader, che chiameremo ShaderB. A questo punto se vi sono altri shaders da elaborare continuo con la logica precedente utilizzando altre textures (TexC, ecc..), altrimenti mostro il risultato a video, risultato che sara' quindi la somma degli effetti degli shaders applicati uno alla volta all'immagine iniziale

Funziona! Nel video che segue potete vedere ad esempio il risultato di applicare due shader alla medesima scena: un effetto di sfuocamento, e poi un effetto "abbagliamento". Non e' proprio il bloom, ma e' un banco di prova necessario per ottenere il risultato al quale voglio arrivare.

Post Processing

2009-01-09T11:37:00.002+01:00

I've tried to learn how to obtain a bloom effect like that you've seen on previous post, and i've understand that the procedure is:

- render the scene not into the back buffer but into a texture.
- for each pixel of the texture: if the bright is major than a value, increase it. else leave it black. Then blur the result, and add to the original source.

Anyway all is made using pixel shaders, so i've started to learn how to apply a pixel shader not only to a mesh but to the whole scene.

In this video you can see my first experiment, a simple "underwater" shader (i've used not tau ceti but a more simple project to do the job quick and dirty). It's just a first step to make a more complex post processing procedure.

--

Ho cercato di capire come ottenere l'effetto bloom che vi ho illustrato nel post precedente.
Studiando ho capito che la procedura da seguire e' la seguente:

- Renderizzare la scena non a video ma in una texture.
- Tramite pixel shaders, prendere la texture e per qualsiasi pixel: controllare la luminosita', se e' maggiore di una certa soglia aumentarla ancor di piu', altrimenti lasciar nero, eseguire un blur gaussiano e aggiungere il risultato all'immagine sorgente.

Quindi bisogna modificare la procedura di rendering e creare dei pixel shaders per eseguire il post processing.

Vi mostro un esperimento.. e' un effetto "subaqueo" che ho creato giocando un po' con le coordinate uv della texure.. non c'entra con tau ceti, ma e' la base per poi costruire effetti complessi.

I need your help

2009-01-07T14:31:00.002+01:00

I'm tired about the "1990 style" of my graphics, i'd like to implemente a more realistic light model.
And i think that the solution could come from the bloom model. I've played a lot with Mass Effect and i love it's bloom effect.
But... i need some tutorial for starting, so have you any link/material to read? I need some tutorial that uses the directx framework.
For now a bloom effect applied to the cobra mk3 created with an hdr demo.

Thank you

---

Sono stanco dell'aspetto "anni 90" che ha la grafica del gioco, vorrei fare un passo in piu' ed implementare un modello di illuminazione piu' realistico. E credo che questo passo possa essere l'implementazione del modello "bloom". Se avete giocato un po' a Mass Effect (gioco che adoro), avete capito a cosa mi riferisco.
L'effetto che mi piacerebbe ottenere e' quello ma.. mi serve qualche tutorial o articolo da studiare. Che spieghi come implementare il tutto sotto directx ovviamente.
Per ora vi lascio con un effetto bloom applicato alla mesh del cobra mk3, creato con un piccolo demo HDR che ho trovato su internet

Atmosphere

2009-01-05T16:53:00.002+01:00

I'm starting to make some atmosphere effect using the blending equation.
It's still raw, but it works.
To make it more realistic i'll try to use a noise texture on atmosphere and see it how it works.. the best should be to apply the noise to the alpha value, not to the color, but it's not very simple, i need to create a shader ad hoc.

If you're some ideas...

---

Ho cominciato ad implementare qualche effetto atmosferico utilizzando l'equazione di blending.
E' ancora grezzo ma funziona. Per rendere l'atmosfera piu' realistica pensavo di utilizzare una texture casuale, sarebbe bello riuscirla ad applicare al valore alpha anziche' ai colori, e probabilmente con gli shaders si riesce pure.

Se avete idee..

100

2008-12-31T15:46:00.002+01:00

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.

Happy Birthday

2008-12-17T20:50:00.003+01:00

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 :)

Shadow Maps reprise

2008-12-05T10:09:00.002+01:00

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.

Shadows Map

2008-12-03T13:03:00.002+01:00

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

1444

2008-11-26T11:40:00.003+01:00

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...)

Normal Mapping 3

2008-11-24T16:23:00.002+01:00

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

2008-11-24T13:26:00.002+01:00

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.

Normal Mapping

2008-11-21T17:33:00.003+01:00

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

Gourard Vs Phong

2008-11-13T16:56:00.005+01:00

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)

!

2008-11-05T23:07:00.003+01:00

Lord Alucard 2

2008-11-04T14:57:00.003+01:00

Two objective for the next steps on developing:

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.
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

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".
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;
}

Lord Alucard

2008-10-28T11:16:00.002+01:00

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.

Christmas tree

2008-10-24T13:43:00.002+02:00

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 :)

Patience

2008-10-23T13:16:00.002+02:00

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

Target reached!

2008-10-09T14:43:00.003+02:00

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!

2008-10-08T16:38:00.003+02:00

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.

Shopping

2008-10-06T15:01:00.003+02:00

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.

Little steps..

2008-10-01T19:13:00.002+02:00

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.

Autopilot: the beginning

2008-09-30T18:32:00.000+02:00

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!

Minor changes

2008-09-26T21:41:00.002+02:00

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.

Rotating ship better than yesterday :)

2008-09-24T16:55:00.002+02:00

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

Rotating Ship

2008-09-23T15:54:00.002+02:00

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.

True Orbits

2008-09-12T17:58:00.002+02:00

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.

[OT] Bad weather forecast...

2008-09-10T14:37:00.002+02:00

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

---

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

August was a good month...

2008-09-09T10:22:00.003+02:00

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 ;)

The Cobra

2008-09-01T17:42:00.004+02:00

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.

Distance

2008-08-29T17:11:00.006+02:00

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.

Welcome

2008-08-28T14:39:00.002+02:00

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 :)

Hud Reprise

2008-08-27T16:18:00.003+02:00

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)

telecamera esterna

2008-08-22T17:41:00.002+02:00

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.

Decisamente Blender!

2008-08-19T16:43:00.004+02:00

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):

Buon Ferragosto

2008-08-13T17:27:00.003+02:00

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:

disegnata la mesh della nostra astronave
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.

Blender o non Blender?

2008-08-12T16:41:00.003+02:00

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..

Paragone bis

2008-08-06T22:43:00.001+02:00

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

Paragone

2008-08-06T17:39:00.004+02:00

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 :)

Luci

2008-08-04T17:44:00.002+02:00

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)

Orbite

2008-07-25T15:49:00.002+02:00

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.

Luce solare

2008-07-21T12:09:00.003+02:00

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!

Tempo

2008-07-18T13:22:00.002+02:00

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.

Lens Flares crescono..

2008-07-17T12:09:00.012+02:00

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.

Buco Nero

2008-07-14T16:32:00.004+02:00

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!

Di ritorno da Manhattan...

2008-07-07T09:26:00.002+02:00

..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.

Il punto della situazione

2008-06-20T17:20:00.004+02:00

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:

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.
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.
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.
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..
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.
Radar: Funziona, rappresenta i medesimi oggetti che sono disegnati dal HUD, certamente è ancora piuttosto grezzo nell'aspetto.
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.
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 (!)

Radar 2

2008-06-05T16:12:00.003+02:00

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.

Radar

2008-05-27T15:56:00.002+02:00

Un pò a rilento (con mio sincero rammarico), ma la creazione del radar prosegue.
Con oggi finalmente posso farvi vedere un piccolo video, visto che qualcosa inizia finalmente funzionare.
Come detto più e più volte, non ho nessuna presunzione di voler rivoluzionare un genere o inventare qualcosa di nuovo, pertanto ho deciso di affidarmi ai vecchi e collaudati sistemi di rappresentazione tridimensionali tipici dei giochi spaziali.
Il concetto e' semplice: l'ellisse rappresenta l'area del radar, su di essa, perpendicolare, un segmento identifica un qualsiasi oggetto rilevato dal medesimo. La lunghezza del segmento indica la distanza tra l'oggetto e il piano ove siete posizionati. Se il segmento e' bianco, l'oggetto sta SOPRA di voi, se e' grigio sta SOTTO. Se l'oggetto e' alla medesima vostra altezza, il segmento diventa un punto.
Inoltre il radar utilizza un sistema di riferimento solidale con l'astronave, quindi se ruota l'astronave (come potete vedere dal filmato), e' la stazione spaziale che da l'impressione di girare all'interno del radar, questo per aiutare il pilota ad orientarsi: se in macchina girate in una rotonda, la vostra impressione sara' quella degli alberi che girano attorno a voi, e non gli alberi fermi e voi a girare.

Ancora purtroppo non funziona bene, quando si compongono due rotazioni (pitch e yaw) i risultati sono completamente sbagliati, e devo capire il perchè, ad ogni modo, superati questi problemi, sarà relativamente semplice espanderne la funzionalità affinchè visualizzi tutti i corpi presenti nello spazio e non solo la stazione spaziale, messa lì per test.

Il Radar

2008-05-14T17:07:00.002+02:00

Come detto la volta precedente, un buon tool per la navigazione potrebbe essere un vettore che rappresenti costantemente la direzione di movimento relativa all'orientamento dell'astronave.
Per far cio', c'e' poco da fare, occorre iniziare a lavorare al radar, che tanto prima o poi avrei dovuto affrontare.
Per ora, come potete vedere (meglio se clickate sull'immagine) ho definito l'"armatura" del radar e ho pasticciato un po' con le coordinate.
Per ottenere l'effetto simil-3d ho disegnato con Paint Shop Pro un cerchio grande, ci ho fatto un bel buco in mezzo, ed ho applicato l'effetto "bevel".
Infine ho preso il risultato e vi ho applicato una proiezione prospettica per dargli l'inclinazione che vedete nella schermata, ridimensionato il tutto a 256x128 e dato in pasto ad uno sprite che lo visualizza costantemente.

Manovre 2

2008-05-06T14:10:00.003+02:00

Un'altra utilità che dovrebbe migliorare la manovrabilità del nostro mezzo è il radar.
Il quale, a differenza di quanto avviene nei giochi di Braben, potrebbe a sto punto mostrare anche il vettore di movimento dell'astronave rispetto al suo attuale orientamento. Nell'immagine vedete una bozza dell'idea: le due linee diagonali tratteggiate rappresentano il campo visivo del giocatore, le linee bianche gli oggetti che stanno sopra il piano dell'astronave, e quelli grigi quelli che stanno sotto.
Inoltre la freccia rossa indica la direzione attuale dell'astronave, senz'altro piu' precisa delle classiche "stelle che ci vengono contro", senza contare che le stelle ovviamente se ne stanno belle ferme.
Che ve ne pare come idea?

[OT] Ei fù

2008-05-05T15:18:00.002+02:00

Oggi è il 5 Maggio, auguri a tutti gli interisti, che tanto vinceranno SICURAMENTE questo scudetto ;)

Manovre

2008-05-05T14:51:00.003+02:00

Come avete potuto notare dal video del precedente articolo, la manovrabilità dell'astronave è decisamente ostica, al punto che il nostro veicolo è di fatto non pilotabile.
Ho aggiunto oggi un primo aiuto. Che non sarè la soluzione di ogni male ma almeno rende le manovre un pò più semplici.
In sostanza, premendo DESTRA o SINISTRA, si accende il razzo di manovra opposto, e la nostra astronave inizia a ruotare nella direzione scelta. Il guaio è che una volta che si smette di azionare il razzo, il corpo continua a ruotate su sè stesso fino a quando non viene applicata una forza contraria, grazie all'inerzia (avete presente gli asteroidi che ruotano sempre su sè stessi? Ecco.)
Ovvero, per ruotare diciamo di 90 gradi ad ovest, dovete premere ad esempio SINISTRA, e prima di raggiungere i 90 gradi di rotazione, premere DESTRA fino a quando la rotazione non si arresta. E se lo tenete premuto un pò troppo, una volta fermatasi, l'astronave inizierà a ruotare verso est.
Irritante.

Così ho implementato un sistema di bilanciamento automatico che funziona così: tenendo premuto sinistra o destra si accende il razzo corrispondente, e l'astronave inizia a ruotare, ovviamente piu' lo tenete premuto e maggiore diventera' la velocita' di rotazione.
Pero', non appena spegnete il razzo/rilasciate il pulsante, si accendera' automaticamente il razzo opposto, che rallentera' la rotazione fino a quando arriverà a zero. Raggiunto l'arresto, automaticamente il razzo si spegne, e la vostra astronave a questo punto rimane immobile.
Rimane chiaramente l'effetto dell'inerzia, quindi una volta che smettete di premere un tasto, l'astronave non si fermera' all'istante, ma gradualmente. Quindi se dovete ruotare di 90 gradi, dovete azionare il razzo fino a 45 gradi, dopodiche' lasciare che gli altri 45 gradi siano a carico del razzo opposto che frena la rotazione. Ma questo non è Quake, è uno spacesim :)

I "dolori" verranno per la gestione del propulsore principale. Il comportamento attuale è fisicamente corretto, ma poco pratico: se l'astronave si muove diciamo verso nord, e, mentre è in movimento, la si ruota, l'effetto non è come nell'automobile quello di cambiar direzione di movimento, ma bensì verrà cambiato senz'altro l'orientamento di prua-poppa, ma la direzione di movimento rimarrà sempre verso nord. Se una volta cambiato l'orientamento si accendono i razzi o i retrorazzi allora la direzione varierà, ma ancora una volta non nella direzione di orientamento, ma bensì nella risultante della somma vettoriale tra orientamento e spostamento.

Insomma, un macello, del tutto inusabile quando si tratta di dover far manovre di "fino", tipo un attracco od un combattimento.
Devo trovare un modo per rendere la guida più immediata, senza rendere di contro la simulazione troppo irrealistica.

Inerzia

2008-04-28T16:34:00.002+02:00

Finalmente qualcosa si muove... con un certo realismo.
Lavorando con la gestione dei motori di manovra e di propulsione si inizia ad avere un movimento che non e' piu' quell'obbrobrio mosso dal mouse che avete visto fin'ora, ma un movimento piu' armonioso che tiene conto dell'inerzia del mezzo.

Come temevo la cosa e' assolutamente non manovrabile per ora, saranno necessari tools o trucchi per rendere il tutto piu' usabile, pero' il tutto per lo meno e' piu' fluido ed armonioso.

Vi lascio un piccolo video di quanto vi ho appena raccontato

Ricominciamo?

2008-04-22T12:11:00.002+02:00

Non lo so, mi piacerebbe, ma come detto in sto periodo son piuttosto preso con il lavoro che, a differenza di Tau Ceti, mi da da mangiare.
Ad ogni modo oggi son finalmente riuscito a ritagliarmi un po' di tempo, e devo confessare che dopo tanto tempo ho fatto fatica nel riprendere in mano i sorgenti e capire dove diamine ero arrivato :)
Detto questo comunque sto sviluppando il sistema di propulsione dell'astronave, pensavo di fornirla di un motore principale per l'accelerazione, e, con un po' di fantasia, anche per la decelerazione (altrimenti per amor di realismo diventa un po' troppo complicato pilotarla), e 4 motori laterali piu' piccoli per le manovre (virate dx,sx, beccheggio).
In tale ottica diventa piuttosto vincolante la forza di inerzia. Per ruotare ad esempio aziono il motore di sinistra, la nave inizia a girare verso destra.. ma in teoria per fermarmi dovrei ad un certo punto spegnere il motore di sinistra ed azionare quello di destra fino a quando l'asse della nave non e' fermo. Tutto molto bello, e nemmeno di difficile implementazione, quel che mi lascia perplesso e': poi il tutto diventa ingovernabile? L'idea e' quella di fare un gioco, non un simulatore di space shuttle, eppure da un lato non vorrei nemmeno trasformarlo in un ufo al quale ogni manovra e' concessa.

Se avete idee, vi ascolto.

Abbiate pazienza...

2008-04-03T11:37:00.002+02:00

Lo so che non scrivo da diverso tempo, ma devo completare un lavoro importante entro fine Aprile. Questo, unito alla mia decisione di dedicare finalmente un po' di tempo libero alla cura del mio fisico (che ne aveva davvero bisogno), mi ha purtroppo costretto a mettere per ora Tau Ceti nel cassetto.
Questo non vuol dire che sia finita qui l'avventura, anzi.
Solo che per ora mi manca il tempo per andare avanti con gli sviluppi.

Ci risentiamo pertanto non appena avro' un po' di tempo.

Tools di sviluppo

2008-03-11T14:17:00.003+01:00

Oggi ho scoperto che sono uscite due importanti novità per lo sviluppo di progetti 3D che usano directx.

- Visual Studio 2008 Express (C++ nel mio caso). Assieme al compilatore è possibile installare anche una libreria che si chiama Dark Games, che a quanto pare permette la realizzazione di giochi in maniera semplice. Dubito mi servirà in quanto non mi è mai piaciuto appoggiarmi a librerie di terze parti per lo sviluppo, ma è comunque interessante darci un'occhiata anche perchè ha un sacco di esempi, textures, modelli ecc.. Non appena ci riesco visto che fin'ora l'installazione ha sempre dato esito negativo nonostante abbia tutto cio' che necessita per farla girare.

- DirectX SDK di marzo 2008. A quanto pare, oltre a contenere le dx10.1 che non mi interessano, han migliorato PIX, utility per eseguire il debugging, specie degli shaders (anche questa, non appena capiro' come funziona...), e immagino sistemato un po' di bachi.

Entrambi i prodotti, ricordo, sono gratuiti, quantomeno per uso personale.

Tributo a Elite

2008-03-10T15:39:00.002+01:00

Prima di chiudere però permettetemi un piccolo tributo al grande Elite di David Braben.
Fatto tutto con l'engine di Tau Ceti.
Non farà urlare al miracolo ma è tutta roba genuina

Mesh 2

2008-03-10T14:22:00.003+01:00

Questi ultimi giorni son trascorsi nel tentativo di fare un pò di pulizia nel codice, ma soprattutto nella battaglia contro un paio di bachi parecchio infidi che mi mandavano in crash il gioco.
Ho combattuto parecchio, perchè i malefici erano visibili solo quando attivavo le directx di debug, mentre nel normale funzionamento pareva andare tutto bene. Alla fine trattavasi di classico "puntatore" che andava dichiarato invece come "puntatore di puntatore", ma la caccia è stata piuttosto faticosa.
Inoltre ho ridisegnato per l'ennesima volta lo sfondo spaziale, utilizzando una bella nebulosa blu, eliminando spero una volta per tutte tutti quelle brutture derivanti dalle unioni dei vari lati del cubo. Ringrazio a tal proposito chi mi ha consigliato dei plug-in davvero validi per paint shop pro.
Ho fatto un pò di pulizie perchè ora si apre un capitolo che sarà lungo e doloroso, ovvero la gestione delle mesh. Lungo perchè le mesh compongono il 90% del motore grafico, doloroso perchè è sicuramente una fase molto complessa (basti pensare la gestione delle animazioni, delle luci, degli effetti bump-map), che richiede anche tutta una serie di tools per la modellazione, l'esportazione in formato directx, e temo dovro' costuirmi qualcosa di ad hoc per gestire quelle informazioni che i programmi normali ovviamente non considerano (ad esempio: un'astronave ha una luce rossa alla posizione 0,0,3 .. come la gestisco con un normale tool di modellazione 3d?)
Andrà anche iniziato a lavorare sull'interfaccia utente, ovviamente prima o poi bisognerà inserire icone, bottoni e quant'altro, ma la priorità è più bassa; ho nel frattempo preso un libro che tratta l'argomento, tutt'altro che banale, e me lo studierò con calma.
Vi lascio nel frattempo con uno screenshot, con la stazione spaziale (ancora molto grezza) in orbita attorno alla terra. A differenza dell'immagine che vi ho fatto vedere nel post precedente, questo è uno screenshot reale e non "ritoccato", ovvero proviene da una schermata in-game.

Mesh

2008-03-06T16:24:00.002+01:00

Prima o poi bisognerà pur iniziare a disegnare gli oggetti che comporranno il gioco, i pianeti son belli senza dubbio ma non sono attori fondamentali.
Non ho certo la superbia di pensar di poter tutto da solo disegnare spettacolari astronavi spaziali, scrivere innovativi motori 3D e comporre musiche degne da MTV Award, specie lavorando saltuariamente.
Pertanto devo scendere a dei compromessi, per forza.. uno di questi è l'ispirarsi alla produzione di Braben, come già detto a Dicembre, l'altro è ovviamente la qualità, non aspettatevi capolavori, faccio quel che posso.
In ogni caso ho iniziato a disegnare una mesh, che sicuramente non sarà affatto nuova per chi, come me, ha ormai una certa età :)
Vi dice niente?

Anelli e texture

2008-03-05T17:15:00.007+01:00

Stanco di vedere sempre i soliti 2 pianeti, ho iniziato con oggi ad inserire tutti i pianeti del sistema solare.
Ovviamente quello che mi ha fatto penare di più è stato Saturno coi suoi anelli, in quanto non e' una semplice sfera, ma qualcosa di piuttosto complesso.
Alla fine ho realizzato gli anelli con un toro estremamente piatto, al quale ho aggiunto una texture fatta a mano, e resi semitrasparenti.
Ancora non ci siamo, ma quantomeno ci assomiglia un poco. Devo capire se per migliorare il risultato e' sufficiente rendere la texture più credibile, se devo giocare un po' con i vari effetti blend, o se devo invece far diventare più sofisticati gli shaders. Vedremo..
Per ora vi lascio con tre immagini: Marte, Saturno, ed un Giove appena illuminato dal sole.

Lens Flares reprise

2008-03-04T17:14:00.004+01:00

Avevo bisogno di riflettere, e la soluzione è arrivata da sola.
Eccovi la lens che sparisce gradualmente dallo schermo, senza piu' effetto on-off.
Ovviamente posso regolarne la velocita' di decadimento, questo e' solo il classico esempio cinque-minuti-prima-di-tornare-a-casa-manco-ho-il-tempo-di-leggere-che-ho-scritto-che-è-tardi ma l'importante e' che si possa fare (ed è pure semplice!)

Atmosfera (ho bisogno di qualche dritta)

2008-03-04T16:43:00.002+01:00

Mentre attendo di capire se si riesce a risolvere il problema della sfumatura delle lens flare, un altro problema si affaccia alla porta: l'atmosfera dei pianeti.
Pensavo di utilizzare uno sprite semitrasparente, come ho fatto in fondo per le lens flares, un cerchio azzurrino da sovrapporre al pianeta ma...

1) lo sprite non sembra minimamente essere influenzato dalla luce, pertanto l'atmosfera risulta tutta dello stesso colore, anche nel lato non illuminato del pianeta.

2) a differenza dei triangoli, lo sprite non viene "deformato" come avviene invece per i pianeti a causa dell'apertura focale un po' a grandangolo (in sostanza, al centro gli oggetti son perfettamente sferici, man mano che si avvicinano al bordo tendono a diventare un po' ellissoidali), e quindi la sovrapposizione non e' perfetta.

Pertanto non credo che la strada dello sprite sia percorribile. Percio'... cos'altro potrei usare per simulare l'atmosfera di un pianeta?

Vi lascio con uno screenshot dell'effetto ottenuto, sottolineando il fatto che non mi piace manco un po'.

Tormento blend

2008-03-04T15:03:00.003+01:00

Forse finalmente riesco a trovare un po'di tempo per il gioco, come detto purtroppo nei giorni scorsi, complice anche influenza, non ho avuto modo di starci dietro.
Con oggi ho sistemato un paio di cose relative alle lens flares, ovvero lo spiacevole effetto degli artefatti che apparivano dietro ai pianeti, e la duplicazione della medesima flares quando si trovava esattamente dietro all'osservatore.
Rimane pendente lo sfumar della lens quando si avvicina al bordo dello schermo (e ovviamente quando la fonte luminosa viene oscurata ad esempio da un'astronave). Come fare non mi è ancora chiaro, nel senso che mi sembra del tutto inverosimile dovermi creare un sacco di immagini degli artefatti via via sempre piu' evanescenti, come mi sembra del tutto assurdo dover modificare via cpu la luminosita' della texture. L'equazione per definire il blending, nelle directx e'

colore = colore sorgente*blend sorgente + colore destinazione * blend destinazione

quindi via via che ci si avvicina al bordo, dovrebbe diminuire il fattore blend sorgente, mentre rimane a 1 il valore di blend destinazione, fino ad arrivare a 0 per blend sorgente non appena varca il margine del bordo.
Di fatto perciò basterebbe passare alle directx un fattore di blend compreso tra 0 e 1, ed il gioco sarebbe anche fatto.. se non fosse che non ho trovato nessuna funzione in grado di venirmi in aiuto.
Per settare il blend si interviene nel render state, e quello accetta solo valori predefiniti.
Se qualcuno ha una buona idea...

Il lavoro nobilita l'uomo....

2008-02-26T14:19:00.002+01:00

...ma non di certo lo sviluppo di Tau Ceti.
Settimana densa, tra lavoro e altro, e ben poco tempo per dedicarmi al gioco, ma comunque son riuscito a sistemare un po' le lens flares (anche se ancora occorre lavorarci, specie per eliminare l'effetto on-off), e per dare una ritoccata al fondale, che ora mi sembra migliore del precedente.
Vi lascio quindi con uno screenshot appena fatto, dopodiche', terminate le lens flares vorrei provare a passare all'atmosfera dei pianeti.
L'idea che ho avuto e' quella di utilizzare la stessa tecnica usata per le flares, ovvero prendere uno sprite semitrasparente e sfumato, e sovrapporlo al pianeta.
Il punto è però che questo sprite, a differenza di quelli della lens flares, dovrà essere sensibile alla luce, il lato buio della terra deve avere un'atmosfera buia, non un alone azzurro.