[c]opengl

[tglman]

Bungiorno ragazzi, chi di voi sa caricare correttamente un modello 3d in c con le librerie opengl, nel modo più performante possibile??

il modello può venire da tutti i formati che si vogliono, come ad esempio:3ds

io però sono più diretto all'utilizzo dell'unione dei formati obj per la grafica e bvh per i movimenti.

chi più ne sa più ne metta grazie!!!

si accettano tutti i consigli!!

[shinya]

Per il modello di solito si crea una display list, memorizzando in un ciclo i vertici del triangolo che compone una singola faccia.
Per le animazioni non ho esperienza del formato che intendi utilizzare purtroppo

[fek]

Originariamente inviato da tglman

Bungiorno ragazzi, chi di voi sa caricare correttamente un modello 3d in c con le librerie opengl, nel modo più performante possibile??

il modello può venire da tutti i formati che si vogliono, come ad esempio:3ds

io però sono più diretto all'utilizzo dell'unione dei formati obj per la grafica e bvh per i movimenti.

chi più ne sa più ne metta grazie!!!

si accettano tutti i consigli!!

Vuoi partire leggero, vedo.

Ti interessa caricare il modello velocemente o renderizzarlo velocemente? Quanti modelli devi renderizzare? Uno solo? Dieci? Cento? Perche' non scegli un formato solo di input e poi usi uno dei tanti convertitori? Ti semplificheresti un tantinello la vita.

[shinya]

Originariamente inviato da fek

Perche' non scegli un formato solo di input e poi usi uno dei tanti convertitori? Ti semplificheresti un tantinello la vita.

Interessa anche me. Cosa intendi per convertitori?

Forse non interessa a tglman, ma tempo fa lessi un tutorial per utilizzare i file in formato .x senza directx. Ovviamente in directx è tutto molto più comodo (soprattutto in c#).

Eccolo http://www.gamedev.net/reference/pro...tures/xfilepc/

[fek]

Originariamente inviato da shinya

Interessa anche me. Cosa intendi per convertitori?

Forse non interessa a tglman, ma tempo fa lessi un tutorial per utilizzare i file in formato .x senza directx. Ovviamente in directx è tutto molto più comodo (soprattutto in c#).

Eccolo http://www.gamedev.net/reference/pro...tures/xfilepc/

Esistono parecchi programmi di conversione (free e a pagamento) per convertire da un formato 3d all'altro. In generale si sceglie un solo formato, si scrive il convertitore (o il plugin), che converte ad un proprio formato interno per il proprio engine e si carica quello. 3DS e' il formato piu' diffuso ed e' molto semplice da usare, ad esempio. Scrivere un convertitore per ogni formato esistente e' pura utopia.

[ianaz]

[OFFTOPIC]
Conoscete delle guide a OpenGl in italiano oltre a NeHe?
Grazie
[/OFFTOPIC]

[tglman]

Voglio fare un programmino che per adesso visualizza e anima degli oggetti 3d, che possono essere, sia degli ominidi sia qualsiasi altra cosa.

Vi chiedo info per il formato migliore perchè non ho scelto ancora definitivamente il formato che deve usare il mio programma.

comunque io ho gia studiato e più ho meno caricato i file in formato obj e bvh, il problema sta nell'animazione, cioe se una volta caricato creo una display list di un ominide come faccio poi a muoverlo??

se qualcuno sa come modificare una display list con qualche operazione matriciale (anche se non credo sia possibile) me lo notifichi!!

per i formati da scegliere io sono concettualmente libero!!
e nel caso basta convertire!
Grazie!!

[fek]

Se devi visualizzare un solo modello allora non hai grossi problemi di velocita'. Le display list non ti servono e ti complicano solo la vita.

Se il modello e' sotto i dieci mila poligoni, inizia facendo il submit di ogni vertice (trasformato per l'opportuna bone o matrice) via glVertex3f o equivalente.

Una volta che hai il modello su schermo che si anima, e magari avessi la necessita' di modelli con piu' poligoni, puoi ottimizzare la versione che gia' funziona. Come formato scegli 3ds che e' semplice da leggere.

Con un po' di attenzione, anche con skinning in software, puoi mostrare fino ad un paio di migliaia di personaggi animati a 30 fps su un comune PC.

[tglman]

Gli oggetti da visualizzare sono N con N poligoni!

Io vorrei cercare di caricare il modello nel modo più definitivo possibile nelle opengl e manipolarlo dall'esterno!

per esempio un metodo può essere caricare tutti i pezzi statici di un modello, come ad esempio un braccio o un dito, con una serie di display list per poi, chiamarli a catena modificando gli angoli tra i pezzi.

Voi avete qualche idea migliore o simile?

[fek]

Originariamente inviato da tglman

Gli oggetti da visualizzare sono N con N poligoni!

Il problema e' allora insolubile. Non c'e' soluzione al voler visualizzare N oggetti con N poligoni, devi stabilire un tetto per entrambi.

Quali sono i tuoi limiti? 10/100/1000 oggetti? Quanti poligoni? Prima di iniziare a scrivere anche una riga di codice devi sapere questo.

Io vorrei cercare di caricare il modello nel modo più definitivo possibile nelle opengl e manipolarlo dall'esterno!

Il modo piu' definitivo possibile non esiste. Esistono diversi approcci, ognuno con i suoi pregi e suoi difetti. Una volta che stabilisci i numeri di cui sopra, allora puoi scegliere l'approccio migliore nel tuo caso.

Voi avete qualche idea migliore o simile?

Si', quella che ti ho detto. Applica le bone in software ad ogni vertice e metti l'oggetto animato su schermo. Poi deciderai se e come renderlo piu' veloce a seconda delle tue esigenze.

[tglman]

Allora non c'è limite ben definito, logicamente se metti 1000 oggetti di 1 miglione di poligoni l'uno non è possibile!

Cioe io sto cercando di costruire uno strumento, non direttamente vincolato al prodotto finale, che può gestire sia 1,2 oggetti molto pesanti, sia un migliaio di oggetti molto leggeri, logicamente il limite lo impone chi lo usa e le performance.

cercando su internet ho visto che lo skinning è molto interessante, cosa sai dirmi riguardo il suo supporto in opengl??

Io ho gia caricato un modello obj e delle animazioni bvh, semplicemente stampando i dati caricati, adesso volevo sapere cosa c'è di meglio!!

[fek]

Originariamente inviato da tglman

Cioe io sto cercando di costruire uno strumento, non direttamente vincolato al prodotto finale, che può gestire sia 1,2 oggetti molto pesanti, sia un migliaio di oggetti molto leggeri, logicamente il limite lo impone chi lo usa e le performance.

E' quello che abbiamo cercato di fare tutti e tutti abbiamo concluso che il problema e' insolubile

Non esiste un'unica soluzione per fare quello che vuoi fare. Tu immagina che la soluzione dipende anche dalla particolare configurazione hardware, su GPU di famiglie diverse si devono usare tecniche diverse. Anche su GPU della stessa famiglia, bisogna usare tecniche diverse a seconda del tipo di GPU. Un solo modello di tanti poligoni e tanti modelli di pochi poligoni si gestiscono in maniera totalmente diversa.

Inizia a mettere un modello su schermo e fai le cose semplici. Ti stai indirizzando verso un oceano di problemi.

Se vuoi la soluzione (forse) piu' efficiente devi darmi le seguenti informazioni riguardo alla tua situazione:

- numero di poligoni
- numero di bone per vertice
- numero di oggetti
- modello della GPU
- numero di texture diverse (se i modelli condividono le stesse texture o no, le cose cambiano)
- varie ed eventuali

[tglman]

Visto che lo stesso programma deve girare con modelli diversi e macchine diverse non posso darti queste informazioni!
Io fino ad adesso ho caricato oggetti di esempio da file obj, per ogni elemento(ad es un braccio) ho fatto una display list, poi dal file bvh ho preso i valori delle matrici di spostamento, e ho semplicemente fatto un ciclo che prima mi posizionava il "cursore" nella posizione e con l'angolazione giusta, e poi mi chiamava la display list.

Questo pero non da nessun collegamento tra due pezzi contigui, cioe non mi cambia la posizione dei vertici di un braccio a seconda dell'angolo con l'avanbraccio, e logicamente non mi fa ne lo Skinning ne nient'altro!
per farti capire ti scrivo un pezzetto di codice indicativo:

for(i=0;i<n_elementi;i++)
{
	glPushMatrix();
	glMultMatrix(matrici[i]);
	glCallList(elementi[i]);
	glPopMatrix();
}

Indicativamente ho fatto questo, cosa c'è di meglio??

[fek]

Originariamente inviato da tglman

Visto che lo stesso programma deve girare con modelli diversi e macchine diverse non posso darti queste informazioni!

Il tuo problema e' allora irrisolvibile. Mi spiace.

[jappilas]

Originariamente inviato da fek

Il tuo problema e' allora irrisolvibile. Mi spiace.

partendo da un presupposto semplificativo che i modelli numerosi a basso poly count siano la norma e gli high polygon count un caso raro(o magari vicerversa), non si potrebbe sviluppare una soluzione efficiente solo per il caso scelto, con la consapevole e stoica accettazione da parte di tglman, che in quello complementare essa sara' largamente subottima (ad essere ottimisti) ?

o si tratta di problemi la cui soluzione e' effettivamente mutuamente esclusiva?

[fek]

Originariamente inviato da jappilas

partendo da un presupposto semplificativo che i modelli numerosi a basso poly count siano la norma e gli high polygon count un caso raro(o magari vicerversa), non si potrebbe sviluppare una soluzione efficiente solo per il caso scelto, con la consapevole e stoica accettazione da parte di tglman, che in quello complementare essa sara' largamente subottima (ad essere ottimisti) ?

o si tratta di problemi la cui soluzione e' effettivamente mutuamente esclusiva?

Mettila cosi', sto scrivendo proprio ora una soluzione per molti oggetti con pochi poligoni e sto cercando di condividere piu' codice di setup possibile con il codice che gestisce pochi grossi oggetti. Risulato: i due code path che escono sono totalmente differenti

Questo perche' ho bisogno di fare le cose ottimali, altrimenti avrei scritto un solo code path non ottimo per entrambi i casi. E sono su una console. E sto trattando oggetti non animati.

Quando ho fatto la stessa cosa per oggetti animati e su PC immagina che ne e' uscito. Avevo code path differenti anche in base alla distanza dei modelli dall'osservatore. E in base alle schede grafiche.

In sintesi: il problema di avere una sola soluzione ottima per tutti i modelli e in qualunque numero e' irrisolvibile.

[jappilas]

Originariamente inviato da fek

Mettila cosi', sto scrivendo proprio ora una soluzione per molti oggetti con pochi poligoni e sto cercando di condividere piu' codice di setup possibile con il codice che gestisce pochi grossi oggetti.
Risulato: i due code path che escono sono totalmente differenti

immaginavo
non mi sono ancora addentrato nella grafica 3d a parte quel poco che vidi tempo fa su texturing, coordinate UV e quaternioni a livello generale, ma la differenza tra oggetti high e oggetti low polygon count, e' uno dei pochi punti fermi...
stando all' amica sacerdotessa Maya che ho vicino (che vede il problema dal pdv del 3d artist quindi), il problema risiederebbe nelle relazioni reciproche di livello diverso tra gli oggetti (quindi gerarchia, ordine dei vincoli e ordine di grandezza dei gruppi di vertici interdipendenti in una "catena"), il che se non ho capito male porterebbe a problematiche a livello di IK solver, oltre che viewport creation, culling, rendering

Questo perche' ho bisogno di fare le cose ottimali, altrimenti avrei scritto un solo code path non ottimo per entrambi i casi. E sono su una console. E sto trattando oggetti non animati.

seppur non ottimo, un code path unico e' fattibile : intendevo questo
se tglman e' interessato (se non ho capito male a lui interessa solo caricare e visualizzare il modello 3d), lo si puo' aiutare a metterlo insieme facendogli accettare l' idea che appunto sara' subottimo e/o pesantemente limitato e facendo affidamento sul suo stoicismo

Quando ho fatto la stessa cosa per oggetti animati e su PC immagina che ne e' uscito. Avevo code path differenti anche in base alla distanza dei modelli dall'osservatore. E in base alle schede grafiche.

eh, ma perche' sei uno sviluppatore perfezionista e te le vai a cercare
(scherzo )

[fek]

Originariamente inviato da jappilas

immaginavo
non mi sono ancora addentrato nella grafica 3d a parte quel poco che vidi tempo fa su texturing, coordinate UV e quaternioni a livello generale, ma la differenza tra oggetti high e oggetti low polygon count, e' uno dei pochi punti fermi...
stando all' amica sacerdotessa Maya che ho vicino (che vede il problema dal pdv del 3d artist quindi), il problema risiederebbe nelle relazioni reciproche di livello diverso tra gli oggetti (quindi gerarchia, ordine dei vincoli e ordine di grandezza dei gruppi di vertici interdipendenti in una "catena"), il che se non ho capito male porterebbe a problematiche a livello di IK solver, oltre che viewport creation, culling, rendering

Nel caso del 3d real time ha a che vedere con il codice di setup che serve per preparare ogni oggetto al rendering e dipende dal fatto che le GPU lavorano molto meglio quando hanno tanti poligoni da renderizzare tutti con gli stessi attributi, piuttosto che pochi poligoni con gli attributi che cambiano continuamente.

Quindi l'idea per molti 'oggetti' di pochi poligoni e' di "trasformarli" in qualche modo in pochi 'gruppi' di tanti poligoni, in questo modo si riesce anche ad ammortizzare il codice di setup fra molti oggetti. Da qui il code path profondamente diverso. Se metti in mezzo le animazioni, poi, la cosa diventa MOLTO complessa.

seppur non ottimo, un code path unico e' fattibile : intendevo questo
se tglman e' interessato (se non ho capito male a lui interessa solo caricare e visualizzare il modello 3d), lo si puo' aiutare a metterlo insieme facendogli accettare l' idea che appunto sara' subottimo e/o pesantemente limitato e facendo affidamento sul suo stoicismo

Ma infatti gli ho consigliato all'inizio un code path non-ottimale che risolve il suo problema, ma dice di voler la soluzione perfetta, quindi problema irrisolvibile

Se si accontenta, fa semplicemente questo:

matrice_di_trasformazione = peso0 * matrice_bone0 + peso1 * matrice_bone1 ...;

vertice_trasformato = vertice * matrice_di_trasformazione

glVertex(vertice_trasformato)

eh, ma perche' sei uno sviluppatore perfezionista e te le vai a cercare
(scherzo )

No, perche' altrimenti favevamo 3 fps

[tglman]

Emmmm... ragazzi diciamo che non voglio le cose proprio ottime, ma vorrei evitare di moltiplicare io ogni vertice con la matrice, posso delegare il compito a opengl??

Inoltre quelle tre righe scritte da te mi piacciono puoi spiegarmi meglio questo concetto, mettiamo che io devo muovere un braccio di un ominide, come posso comportarmi,

Grazie!!

[fek]

Originariamente inviato da tglman

Emmmm... ragazzi diciamo che non voglio le cose proprio ottime, ma vorrei evitare di moltiplicare io ogni vertice con la matrice, posso delegare il compito a opengl??

Devi scrivere un vertex shader oppure usare delle estensioni strane. Fallo tu a mano prima, cosi' impari come si fa, poi magari in futuro scrivi uno shader, che e' gia' un bel problema di suo. No, non riusciresti a scrivere uno shader adesso, ci vuole qualche mese.

Inoltre quelle tre righe scritte da te mi piacciono puoi spiegarmi meglio questo concetto, mettiamo che io devo muovere un braccio di un ominide, come posso comportarmi,

Grazie!!

Te lo spiego quando sono in ufficio