[Tutorial] Izrada 3D/scenegraph enginea

Svaka čast na tutu... predobro....

samo ja tako ne volim raditi s klasama...
Sto ces... ja sam ipak "starudija" :) C :)

  Pa cjelokupni moj projekt je u c-u radjen... mozda je malkice teze, ali sve to mozes lijepo srediti...

  Pa ne bih se baš slozio s tobom... ali dobro... to je tvoje misljenje, a ako "aplikacija" u koju je ulozeno nesto vise od 2 mil eura nije ozbiljan projekt onda ne znam...

 

:)

 

Pozdrav i jos jednom DEUS, oprosti za ovaj offtopic i predobar thread...

Entaro Adun,

danas pocinjemo sa scenegraphom.
Scenegraph, kako mu samo ime govori, je podatkovna struktura koja predstavlja nasu scenu u formi grafa. Graf je vrlo korisna matematicka struktura koja predstavlja kolekciju objekata i definira njihove medjusobne veze, no unatoc (pogresnom) imenu, podatkovna struktura koja najefikasnije predstavlja scenu je stablo. Graf, za razliku od stabla, ne poznaje koncept parent/child vec samo svoje 'susjede' (o boze kako mrzim hrvatske nazive za ovo). Stablasta struktura je odlicno rijesenje za 3D engine, iz vise razloga:
1. 'kompresija' podataka. Djeca normalno nasljedjuju svojstva svojih roditelja.
2. jednostavnije optimiziranje necega sto se zove 'state change'
3. u buducnosti, jednostavniji streaming podataka
4. jeftiniji occlusion
5. jednostavno segmentiranje kalkulacija, odnosno, kalkuliranja unutar lokalnih dijelova stabla da bi se sacuvala preciznost
6. ... dosadilo mi je razmisljati o dodatnim razlozima....

Ideja naseg scenegrapha sastoji se od tri komponente:
1. Geometrija, tj. Mesh, tj. klasa koja sadrzi stvarne lokalne podatke o nekoj geometriji - vertexe, normale, UV, indekse, etc etc etc...
2. Parametri, odnosno klase s kojima opisujemo kako ce se neki mesh renderirati - tekstura, materijal, shader, blending, etc etc etc...
3. Node, genericki clan stabla koji moze imati parent-a i moze imati djecu, te moze biti anotiran parametrima

Danas cemo srediti rudimentarni Mesh, koji cemo s vremenom obogacivati. Nas bazicni Mesh mora prije svega sadrzavati:
- pozicije vertexa u lokalnom prostoru mesha
- lokalnu translaciju samog mesha u odnosu na svoj parent u scenegraphu (tj. tretirajuci parenta kao izvoriste koordinatnog sistema)
- rotaciju u odnosu --||--
- skaliranje u odnosu --||--

Vertex je skup 3 koordinate. S obzirom da nad vertexima planiramo izvoditi razne operacije - rotiranje, skaliranje, projiciranje, i sto god jos ne, nasa Vector klasa je savrsen kandidat za opisivanje vertexa. Lokalna translacija je sama po sebi skup od 3 koordinate, i takodjer, Vector je savrsen kandidat. Skaliranje se izvodi u 3 osi, dakle, opet Vector. Rotacija je malo zeznutija stvar.
Za pocetak, potrebno je znati da se sve ove tri transformacije unutar konkretno OpenGL-a pretvaraju u matrice (jednostavno se na wikipediji pronadju matrice za translaciju, sve 3 osi rotacije i skaliranje). Multiplikacijom tih transformativnih matrica dobijamo finalnu matricu transformacije, te onda mnozimo svaki vertex unutar mesha s njom, da bi izracunali finalnu poziciju vertexa. Mnozenje matrice i vertexa je u nasem engineu predstavljeno, logicno, kao mnozenje matrice i vektora, jednostavna (i za procesor podosta jeftina, mnozenje i zbrajanje) matematicka operacija.
E sad, u cemu je problem s rotacijom? Postoji problem koji se zove 'gimbal lock', odnosno, koristeci eulerove kuteve, gubi se transformacija po jednoj osi. Ovo ne moze doci do izrazaja u ne-stablastoj strukturi jer ne postoji koncept nasljedjivanja rotacije. Sad, iako vam se moze ciniti da je stablasta struktura onda problem sam po sebi, dovoljno je zamisliti 'rig' - stablastu strukturu jointova koji opisuju neki skelet za animaciju. Primjerice, zamislite ruku - ona se sastoji od ramena, lakta i zgloba sake. Koristeci eulerove kuteve, moguce je postaviti rotaciju ramena na taj nacin da se lakat ogranici na rotaciju po samo dvije osi, to je nusprodukt kalkulacije rotacijskih matrica.
Tom problemu se moze pristupiti na vise nacina, u zadnje vrijeme, popularano je koristiti Quaternion, odnosno skup brojeva koji prosiruje imaginarni skup. Na rotaciju quaterniona moze se gledati kao na 3D ravninu smjestenu u 4D hiperprostor - dakle, komplicirano :-D
Ono sto je nama bitno su ove cinjenice:
- jedan quaternion (4 floata) predstavlja punu 3D rotaciju
- quaternione mozemo bez problema mnoziti bez bojazni od gimbal-locka i kao rezultat dobiti quaternion
- SLERP (sfericna linearna interpolacija) je jeftina operacija sa quaternionima


Sad, nakon sto sam sve ovo ispisao (tudum), maknut cemo se od quaterniona cisto da se mrvicu udaljimo od matisa, i predstaviti nase kuteve na nacin na koji ih OpenGL moze prihvatiti, a to je jedan malo intuitivniji prikaz rotacije - os i kut oko te osi. Dakle, iskoristit cemo jedan vektor za definiciju osi, te jedan float za definiciju kuta (u radijanima, naravno) oko te osi.

Takodjer, obavezno cemo rastaviti Mesh na header i implementaciju, jer ga necemo cesto mijenjati, ali cemo ga koristiti na mjestima koja ce se cesto mijenjati.

Pocnimo s novim namespaceom, i posljedicno, novim direktorijem u nasem projectu - model, te dodajmo Mesh.hpp i Mesh.cpp. S obzirom da je nasa cmake build skripta 'pametna', ne moramo podesavati apsolutno nista:
.
|-- CMakeLists.txt
`-- src
    |-- main
    |   `-- cpp
    |       |-- Tutorial1.cpp
    |       |-- general
    |       |   |-- Object.cpp
    |       |   |-- Object.hpp
    |       |-- math
    |       |   `-- Vector.hpp
    |       `-- model
    |           |-- Mesh.cpp
    |           `-- Mesh.hpp
    `-- test
        `-- cpp
            |-- TestSuite.cpp
            |-- math
            |   `-- VectorTest.hpp
            `-- skunkworks
               `-- BaseTest.cpp

E sad, jedna 'arhitekturalna' odluka :-)
Ono sto znamo za cinjenicu jest da ce Mesh pristupati svojim podacima cesto (tj. na svaki 'render'), no ti podaci se nece cesto mijenjati - jednom ucitan mesh generalno _nece_ mijenjati broj svojih vertexa, UV mapping i slicno. To znaci da bi bilo idealno spremiti podatke tocno tamo gdje se Mesh alocira, sto znaci da unutar Mesh-a _necemo_ spremati pokazivace na nase vektore, vec kopije vektora koje predajemo kroz konstruktor.
Takodjer, s obzirom da se podaci nece cesto mijenjati i da cemo im vrlo cesto pristupati at random (tj. kod svakog rendera :-)), std::vector je odlican izbor za kolekciju.
Takodjer, ne zaboravimo da smo implementirali zanimljive stvari unutar Object.hpp, pa bi bilo korisno naslijediti tu klasu.

Nakon sto smo sve to odlucili, krenimo prvo sa interfaceom:
#ifndef MODEL_MESH_HPP_
#define MODEL_MESH_HPP_

#include <general/Object.hpp>
#include <math/Vector.hpp>
#include <vector>

namespace model {

class Mesh: public general::Object {
private:
    std::vector<math::Vector3f> vertices;
   
    std::string name;
    math::Vector3f localTranslation;
    math::Vector3f rotationAxis;
    float rotationAngle;
    math::Vector3f scale;
   
    math::ColorRGBA defaultColor;

    void ApplyTransforms() const;
    void ApplyDefaultColor() const;

public:
    Mesh();
    Mesh(const std::vector<math::Vector3f>& vertices);
    virtual ~Mesh();

    std::vector<math::Vector3f> GetVertices() const;
    void SetVertices(const std::vector<math::Vector3f>& vertices);

    virtual void Render() const;

    std::string GetName() const;
    math::Vector3f GetLocalTranslation() const;
    math::Vector3f GetRotationAxis() const;
    float GetRotationAngle() const;
    math::Vector3f GetScale() const;
    math::ColorRGBA GetDefaultColor() const;

    void SetName(const std::string& name);
    void SetLocalTranslation(const math::Vector3f& localTranslation);
    void SetRotation(const math::Vector3f& axis, const float angle);
    void SetRotationAxis(const math::Vector3f& axis);
    void SetRotationAngle(const float angle);
    void SetScale(const math::Vector3f& scale);
    void SetDefaultColor(const math::ColorRGBA& color);

    virtual std::string GetClassName() const;
    virtual std::string ToString() const;
};
}

#endif

U startu se vidi da ova klasa ima gomilu koda. Imajuci na umu da cemo kasnije prosirivati nas model scenegrapha, ovaj kod se moze izvuci u superklasu, ali _necemo_ to raditi _sada_. Ova odluka je bitna: uvijek prvo krenite s necim JEDNOSTAVNIM, a onda kompliciranim. Izvlacenje superklase iskljucivo zato da bi imaginarno ustedjeli na citljivosti koda je LOS potez, zato jer ta superklasa nema osnova za svoje postojanje. Tek onda, iskljucivo, kad se pokaze da dvije klase unutar iste logicke domene zatrebaju jednake mogucnosti, ONDA treba pristupiti refactoriranju. Zasada, mi cemo se drzati jednostavnosti i ostaviti to ovako.
Dodali smo, takodjer, ime objekta - obican string, koristan parametar.
Mislim da od gornjeg koda jedino metode ApplyTransforms() i ApplyDefaultColor(), te polje defaultColor (oznaceno kao hack) nisu razumljivi.
Dakle, ApplyTransforms je privatna metoda koja ce aplicirati transformacije u OpenGL (ili kasnije u neki drugi renderer), prije nego ispisemo vertexe. Default color je boja s kojom cemo obojati nagurane vertexe, cisto da vidimo da smo nesto uopce napravili. Oznacena je kao hack jer obicno, ukoliko zelimo boje, trebali bi procitati boje za svaki vertex, no to znaci da nas parser u startu postaje kompleksniji - zelimo se pokusati ograniciti na parsiranje sto je moguce manjeg skupa podataka, i cim prije prikazati nesto u prozoru.

Render metoda ce jednostavno aplicirati transformacije da bi modificirala OpenGL matrice, te potom unutar loopa naizmjenicno aplicirati boju i 'gurnuti' vertex u OpenGL.
Kasnije, obogatiti cemo render metodu postavljanjem normala, shadera, ili cime god drugim. Takodjer, u buducnosti render metoda morat ce primiti Renderer interface, koji ce biti nas apstraktni prikaz rendering API-ja.
Dakle, od svih ovih silnih mutatora i accessora, najzanimljiviji dijelovi (ie. OpenGL) se nalaze unutar ApplyTransforms, ApplyDefaultColor i Render metoda.

Primjetite jos jednu dobru praksu - bilo koji mutator _kopira_ podatke u mesh.
Ovo ce se mozda ciniti kao trosenje prostora ili sporost, ali postoji argument koji ubrzano dobiva na vaznosti, koji pobija te obje premature optimizacije - multithreading ;-)

Evo napokon i implementacije:
#include "Mesh.hpp"
#include <algorithm>
#include <GL/gl.h>
#include <sstream>

using namespace std;
using namespace math;
using namespace model;

Mesh::Mesh() :
    name("UNNAMED_OBJECT"),
    localTranslation(0.0F, 0.0F, 0.0F),
    rotationAxis(0.0F, 1.0F, 0.0F),
    rotationAngle(0.0F),
    scale(1.0F, 1.0F, 1.0F),
    defaultColor(1.0F, 0.0F, 0.0F, 1.0F) {
}

Mesh::Mesh(const vector<Vector3f>& vertices) :
       name("UNNAMED_OBJECT"),
       localTranslation(0.0F, 0.0F, 0.0F),
       rotationAxis(0.0F, 1.0F, 0.0F),
       rotationAngle(0.0F),
       scale(1.0F, 1.0F, 1.0F),
       defaultColor(1.0F, 0.0F, 0.0F, 1.0F),
       vertices(vertices) {
}

Mesh::~Mesh() {
}

string Mesh::GetName() const {
    return name;
}

Vector3f Mesh::GetLocalTranslation() const {
    return localTranslation;
}

Vector3f Mesh::GetRotationAxis() const {
    return rotationAxis;
}

float Mesh::GetRotationAngle() const {
    return rotationAngle;
}

Vector3f Mesh::GetScale() const {
    return scale;
}

ColorRGBA Mesh::GetDefaultColor() const {
    return defaultColor;
}

void Mesh::SetName(const string& name) {
    this->name.assign(name);
}

void Mesh::SetLocalTranslation(const Vector3f& localTranslation) {
    this->localTranslation.Set(localTranslation);
}

void Mesh::SetRotation(const Vector3f& axis, const float angle) {
    this->rotationAxis.Set(axis);
    this->rotationAngle = angle;
}

void Mesh::SetRotationAxis(const Vector3f& rotation) {
    this->rotationAxis.Set(rotation);
}

void Mesh::SetRotationAngle(const float rads) {
    this->rotationAngle = rads;
}

void Mesh::SetScale(const Vector3f& scale) {
    this->scale.Set(scale);
}

void Mesh::SetDefaultColor(const ColorRGBA& color) {
    this->defaultColor.Set(color);
}

void Mesh::ApplyTransforms() const {
    glMatrixMode(GL_MODELVIEW);
    glRotatef(rotationAngle, rotationAxis[0], rotationAxis[1], rotationAxis[2]);
    glTranslatef(localTranslation[0], localTranslation[1], localTranslation[2]);
    glScalef(scale[0], scale[1], scale[2]);
}

void Mesh::ApplyDefaultColor() const {
    glColor3f(defaultColor[0], defaultColor[1], defaultColor[2]);
}


string Mesh::GetClassName() const {
    return "model::Mesh";
}

string Mesh::ToString() const {
    ostringstream oss;
    oss << GetClassName() << "{vertices={";

    vector<Vector3f>::const_iterator it = vertices.begin();
    vector<Vector3f>::const_iterator nextToLast = vertices.end();
    nextToLast--;

    for (; it < nextToLast; ++it)
       oss << it->ToDebugString() << ", ";

    vector<Vector3f>::const_iterator last = vertices.end();
    last--;

    oss << last->ToDebugString();
    oss << "}" << "}";
    return oss.str();
}

vector<Vector3f> Mesh::GetVertices() const {
    return vertices;
}

void Mesh::SetVertices(const vector<Vector3f>& vertices) {
    this->vertices.assign(vertices.begin(), vertices.end());
}

void Mesh::Render() const {
    ApplyTransforms();
    glBegin(GL_TRIANGLES);

    for (unsigned int i = 0; i < vertices.size(); ++i) {
       Vector3f vertex = vertices[i];
       ApplyDefaultColor();
       glVertex3f(vertex[0], vertex[1], vertex[2]);
    }

    glEnd();
}


Eto, to je to za danas.

Slijedeci put cemo (napokon!) probati iscrtati obican trokut na ekran, ja trenutno inicijaliziram XWindows prozor, ali probat cu srediti i Windows build. U medjuvremenu, za zabavu, mozete procitati http://rampantgames.com/blog/2004/10/black-triangle.html i mozete poceti razvijati zdravu mrznju prema managerima i njihovoj ignoranciji ;-)
Ako slucajno puca build, napisite ovdje jer sam morao malo secirati svoj kod da to mogu pomalo objasniti ovdje, te je moguce da mi je promakla neka greska.

Cheers!

Mogu ti reci da si ti jedan od malobrojnih forumasa koje s uzitkom citam...

Normalno i naxeem spada tu...jednostacno elokvetno i prilicno argumentirano objasnjavate... Iako se nekada ne slažem, opet je lijepo pročitati :)

A gle... mozda dises na usta dok tipkas a to ni ne primjecujes...

Inace budem te uskoro malo konzultirao posto vidim da znas dosta o 3d enginima i slicno... posto mislim jedan mali pilot projetkic (entuzijasticni) napraviti... I mozda bi mi mogao pomoci u vidu tutova, clankova i slicno... Normalno oko svega se dogovorimo...

S obzirom da je OGL x-platform, zašto uopće ići na neke druge API-je? DirectX je jedini još, a OGL radi i na Windowsu, pa...

Ovo ima logike Programko, recimo render ako ostane unutar mesh klase definitivno ograničava neke stvari, ima rješenja gdje se za svaki pojedini grafički api izvodi drugi mesh, tj render mesh-a . Sam API se detektira prije main-loop funkcije dal preko odabira korisnika ili preko detekcije grafičkog adaptera te na taj način odredi " najbolji" render API za mesh. recimo radio sam s jednim SDK-om koji je imao tako definirano DX mesš, GL mesh, zatim skinned mesh i solid mesh. Znaći ono što ja predlažem da se izvuće render klasa, koja preko verticesa mesha radi rednder nad meshom, jer manje više i DX i GL barataju kroz vertices arrayeve, ispravite me ak sam u krivom jer već dugo nisam radio direktno na razini Grafičkog API-a.
Znaći ukratko moja ideja je ostaviti mesh klasu kakva je umanjenu za render funkciju, napraviti klasu render , trenutno implementiranu za GL API , te menađer mesheva ili pretraživać stabla mesh-eva koji sadrži arry listu, na način da isti poziva prosljeđene pokazivaće na polja mesheva . S druge strane mislim da je ovo i brži način izvođenja koda. Drugo u mesh klasu ubaciti boolean vrijednost za render ili not render, tako recimo nam to može kasnije poslužiti za neke efekte ( OC ili LOD ) tipa da kada renderirat mesh, to recimo izvedemo preko super klase za slanje poruka, message sistem.
Kažem ispravite me ako sam u krivom.

Mislio sam na bitne i one koji nekoga uopće interesiraju. OpenGL ES nije previše različit od "običnog" OpenGL-a.

Ovo je izvrsno! Svaka čast. 

Jesi možda razmišljao da cijeli projekt pretvoriš u open-source engine i da mu daš neko ime, pa da bude konkurencija Irrlicht-u, OGRE-u ili OpenSceneGraph-u?

Dobra poanta od oboje, sve sam ja to razradio u tekstu tutoriala kroz nekoliko prakticnih naputaka:

- ne razmisljati unaprijed - tek kad se problem pojavi. Sad je primarni fokus iscrtati sto god na ekran.

- maleni naputak o tome kako ce Render metoda primati Renderer interface, tocno kako je woodgamesfx predlozio

 

Samo pogledajte tekst :-)

Ma, ne bas, jer razviti nesto sto bi bilo pandan tim engineima bi bio totalni overkill. Pazi, vec smo na lekciji 6, a nismo niti iscrtali nista na ekran. Do neke lekcije 100 bi mozda dosli na pola puta do nekog od tih enginea, tako da se stvarno ne isplati. Kod cu staviti na neki opensource repozitorij kako je Programko predlozio (na kraju krajeva copy pasteam ovdje sve :-D), no u praksi, cilj tutoriala je napraviti maleni, reusabilni, prosirivi framework za scenegraph, koji kasnije bilo tko moze prosirivati svojim idejama i funkcijama (i, uz dobru volju, postati u ovaj topic 'nastavak' tutoriala)

 

Zapravo, na vrhu hijerarhije ide vrlo jednostavni IRenderable interface, sa jednom metodom:

void Render(IRenderer& renderer) const;ali o to cemo dodati kad stignemo do dijela da trebamo virtualno rendati cijelo stablo :-)

 

 

Kao i uvijek, hvala na konstruktivnim komentarima, prijedlozima i idejama.

 

@Woodgamesfx,

hvala puno na WinMain cpp-u! Spasio si mi posla kopanja po WinAPI-u da sastavim nesto svoje :-D

 

Edit:

Um... nestalo. Mozes li dodati opet, molim te?

Nema problema, ali pošto sam sad na Mac-u ne mogu doć do koda , kod mi trenutno nije dostupan :( , nego ako nije kasno mogu sutra ujutro staviti kod. Mada nije ništa spektakularno več je rijeć o bazičnom GLUT templateu za Win forms . 

PS.

Kad uhvatiom vremena probat ču , naravno uz pomoć kolega s foruma, portat ovaj Deusov projekt na Objective C sa OpenGL ES API-jem jer osobno meni bi bio korisniji u tom obliku  :) , mada upozoravam u posljednje vrijeme ne radim direktno s C-om niti C++ tako da očekujte "glupa" pitanja. Kažem probat ču ali ne garantiram uspjeh jer jedino i zadnje što sam radio u Objective C-u je bila igra puzzle za iPhone, projekti na kojema trenutno radim koriste skriptne jezike JS i C# , i moje programiranje trenutno i zadnjih više pola godine je najviše vezano uz njih, što je svima jasno da je velika razlika od nativnog C++-a ili C-a.

 

 

Nema glupih pitanja!

 

Ako moze neki topic ovdje na forumu, sa zanimanjem bi pratio jer nisam bas nikad radio s objective-c om.

U pravu si, nema smisla razvijati novi 3D engine, ima ih puno boljih vec gotovih i to u opensourceu.

 

Pa, prvi blizi fokus ce biti na prosirivanje samog scenegrapha da se dodaju osnovne mogucnosti teksturiranja, vertex-normala, blending, materijale i ostale stvari koje cine jedan fixed-pipeline renderer. Onda treba dodati kamere i svijetla.

Kad budemo mogli zrendati jedan model iz Collade ravno u engine, onda mozemo dalje jer je onda nekakva baza gotova.

Onda bi trebalo napraviti proof of concept i implementirati neki drugi renderer, spominjao se softwareski raytracer koji je meni zanimljiv iz vise razloga, primarno zato jer ne moram switchati u windowse, pa onda zato jer je softwareski (nema pilane s driverima), pa onda zato jer nije rasterizator nego drugacija tehnika.

 

Ima netko tko bi proucio photon mapping? :-D

 

Onda cemo to refactorirati tako da bude prijemcljivije shaderima. Pa onda malo prtljati sa shaderima, recimo dodati per-pixel lighting, uv parallax mapping... pa dynamic ambient occlusion (tako da lijepo ubijemo graficku na koljena :-D), pa onda deferred shading pa onda mozda deferred lighting (potonji nisam jos probao napraviti :-\), pa onda mozda screen space ambient occlusion.

 

Pa onda nesto postprocessing efekata, recimo HDR, tone mapping...

Ima materijala ko u prici, a u biti ono sto mene najvise interesira je proceduralna generacija (geometrija, animacija, teksture a i content) tako da brijem da cu jako brzo, nakon sto rijesimo osnovne shadere, odcijepiti novi topic u to...

 

Nisam planirao nista u vezi newtonian fizike, ali planirao sam 3D collision detection preko boundarya i preko triangleova.

 

Da siguran sam da koristim sintaksu C# za skriptiranje :)