Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Ciacia

Render In Real Time

Recommended Posts

Ciao,

questo è un messaggio generato automaticamente.

Se hai ricevuto questo messaggio è perché la tua discussione è stata spostata e messa nella sezione più appropriata.

Quando crei una discussione ti preghiamo di far attenzione ad inserirla nella sezione corretta in modo che sia più facile per tutti consultare il forum.

grazie per la collaborazione

lo staff di Treddi.com


"la spada è l'estensione dell'anima"

Share this post


Link to post
Share on other sites

viewpoint/enliven

cult3d

quest3d

shockwave

questi son quelli che conosco, quest3d è il piu bello ma devi scaricare un eseguibile per vederlo, mentre gli altri sono plugin per browser

Share this post


Link to post
Share on other sites

O_O Ulp! La concorrenza!!

Ciao a tutti. Sarei interessato a studiare un pò il mondo dei render in real time. Qualcuno può suggerirmi software che siano tali? Saluti a tutti.

Dovresti essere un po' più specifico e dire cosa vuoi fare. Il rendering 3D va dai video giochi / simulatori, alla visualizzazione architettonica, alla visualizzazione di modelli su web... e non esiste un programma universale che fa tutto. :P

Share this post


Link to post
Share on other sites

Hai ragione. mi serve per la visualizzazione architettonica di interni. Devono essere fotorealistici al massimo e navigabili in tempi reali in modo che il cliente veda gli arredi e ci possa girare.

Share this post


Link to post
Share on other sites
Hai ragione. mi serve per la visualizzazione architettonica di interni. Devono essere fotorealistici al massimo e navigabili in tempi reali in modo che il cliente veda gli arredi e ci possa girare.

Non so quanto sei preparato sull'argomento quindi parto dalle basi.

Con rendering in real time si intende che l'immagine visualizzata venga calcolata sul momento, questo per quanto banale possa essere presuppone che se l'immagine deve essere in movimento (quindi navigabile o interagibile) bisogna rispettare dei tempi strettissimi per ingannare l'occhio umano. Sotto i 30 frame al secondo infatti si notano degli scatti. Equivale a dire che l'immagine deve essere calcolata al massimo in 33 ms.

Considerando che un render normale ad alta qualità impiega minimo 20 minuti per essere eseguito bisogna precalcolare la maggior parte delle infomazioni. In particolare tutte le informazioni sul ray tracing devono essere precalcolate, sia perché richiedono molto tempo, sia perché sono difficilemente parallelizzabili.

Ci sono diverse limitazioni:

-La prima limitazione è il contenuto numero di poligoni della scena. Con le schede video attuali inizia ad essere difficile gestire una scena con più di un milione / un milione e mezzo di poligoni, inoltre se fai una rappresentazione del tuo modello e la vuoi distribuire a giro non puoi pretendere che tutti abbiano un computer ultra performante. Quindi una scena completa non dovrebbe superare i 400k / 500k poligoni.

-Altra cosa importante, è che ho parlato di poligoni, mentre nella grafica 3d "off-line" possono essere usate curve parametriche come le NURBS. Cosa che attualmente è improponibile nella grafica real-time. La tassellizzazione è una procedura non troppo complessa, e ci sono delle demo in cui vengono visualizzati dei modellini fatti con curve parametriche, ma creare un intera scena in NURBS non è proponibile.

Per questa ragione ci sono pochi motori grafici che le supportano.

-Il raytracing non è fattibile attualmente, il motore grafico di quake 4 fa una specie di global illumination, ma non è una tecnologia di largo uso e non viene usata nei motori per la visualizzazione architettonica. L'illuminazione di solito viene precalcolata per gli oggetti fissi, e con l'ausilio di ombre tramite shadowmap si riescono ad ottenere buoni risultati. Per le riflessioni si può fare in due modi, possono essere "precalcolate" e si usa una speciale texture che rappresentano gli oggettti riflessi applicata in un modo particolare. Per oggetti in cui vuoi l'effettiva riflessione deve essere eseguito un ulteriore render per la riflessione.

Per esempio se c'è uno specchio, vanno fatti due rendering, uno dal punto di vista della telecamera, e uno dal punto di vista della telecamera specchiata, questo render verrà usato come texture da applicare allo specchio. Per fare la riflessione su una sfera o un qualsiasi oggetto non piatto vengono fatti diversi render e viene usato una particolare tecnica per calcolare la riflessione corretta. Se ti interessa -> http://en.wikipedia.org/wiki/Reflection_mapping

Come detto prima se hai uno specchio devi fare due render... questo implica che per avere l'immagine finale ci impieghi il doppio. Quindi di solito non è fattibile di fare una scena con 20 specchi, vetri e luccinichi tutti calcolati in modo preciso, e ci si affida alle riflessioni correte per gli specchi piatti, mentre per le superfici curve si usano delle reflection map statiche.

-tutto il resto è una questione di texture e di shaders. Il limite delle texture da usate è dato dalla memoria della scheda video e dal livello del filtro asintropico . Mentre sugli shader dipende dalla potenza della scheda video (da che tipo di shader supporta e dalle unità addette al calcolo).

Senza andare troppo nel tecnico lo shader è un programmino che gira sulla scheda video e decide come "colorare" gli oggetti. Prende le varie texture e le informazioni sulla geometria e fa i suoi calcoli, per esempio uno shader che usa la texture per il colore e la lightmap fa un calcolo semplicissimo, in cui moltiplica la prima texture per la seconda. Però se si vogliono effetti complicati come il parallax mapping gli shader possono diventare complicati e pesanti da calcolare.

Riassumendo, non puoi prendere il tuo modello che ci ha messo 10 ore a renderizzare e buttarlo in pasto ad un programma e sperare che te lo renderizzi in real time, devi fare un modello dedicato rispettando determinati limiti (di poligoni e di texture). Esistono vari programmi che ti calcolano da soli le riflessioni e hanno degli shader già fatti in modo che tu debba fare il minor lavoro possibile.

Alcuni girano come plugin per i browser web (e ti permettono di far vedere i tuoi lavori su internet) altri creano applicativi stand alone che puoi mettere su un CD e far vedere ai tuoi clienti.

Se li fai scaricare da internet hai restrizioni sulla grandezza... texture e modelli occupano un sacco di spazio, e anche una cosa semplice arriva ad occupare più di 5 mega, un modello complicato anche 100 e magari uno si scoccia a stare mezz'ora a scaricare un modello. Pensa che in un videogioco su 3 giga di roba almeno 500mb sono di texture.

I programmi sono diversi con costi e prestazioni diversi.. di solito quelli che costano di più sono quelli più semplici da usare (ma non è sempre detto).

Oltre a quelli consigliati da Fr3ak aggiungo Virtools e XVR.

Quest 3d è spettacolare però costa un accidente. O_O

Se usi V-ray si vocifera che ci sia anche la versione per il rendering realtime -> http://www.treddi.com/forum/index.php?showtopic=45609

Altri motori specifici per la programmazione in real time come Ogre, irrltch o panda 3d non te li mensiono neanche perché bisogna sapere programmare. :P

Ciaoo!! e benvenuto in un mondo di malati della matematica e taccagni di poligoni :lol:

edit: O caspita, mi ero dimenticato di fare propaganda a Blender..

Blender permette di fare applicativi navigabili in realtime!!! \ò/ (la nicchia vincerà)


Edited by ilmale

Share this post


Link to post
Share on other sites

Ciao ho letto una tua esaurientissima risposta su una discussione riguardo il rendering real time, volevo chiederti alcune info, io programmo il c++ e java, e da un po ho iniziato a lavoricchiare con 3dsmax, volevo chiederti cosa mi consigliavi per quanto riguarda la realizzazione di un videogame, cioè puoi consiglairmi dei siti o tutorial che parlano di questo? mi conviene muovermi nel campo della programmazione con l'ausilio delle librerie opengl , oppure usare altri programmi? più semplici e veloci? se si cosa mi consigli grazie

Non so quanto sei preparato sull'argomento quindi parto dalle basi.

Con rendering in real time si intende che l'immagine visualizzata venga calcolata sul momento, questo per quanto banale possa essere presuppone che se l'immagine deve essere in movimento (quindi navigabile o interagibile) bisogna rispettare dei tempi strettissimi per ingannare l'occhio umano. Sotto i 30 frame al secondo infatti si notano degli scatti. Equivale a dire che l'immagine deve essere calcolata al massimo in 33 ms.

Considerando che un render normale ad alta qualità impiega minimo 20 minuti per essere eseguito bisogna precalcolare la maggior parte delle infomazioni. In particolare tutte le informazioni sul ray tracing devono essere precalcolate, sia perché richiedono molto tempo, sia perché sono difficilemente parallelizzabili.

Ci sono diverse limitazioni:

-La prima limitazione è il contenuto numero di poligoni della scena. Con le schede video attuali inizia ad essere difficile gestire una scena con più di un milione / un milione e mezzo di poligoni, inoltre se fai una rappresentazione del tuo modello e la vuoi distribuire a giro non puoi pretendere che tutti abbiano un computer ultra performante. Quindi una scena completa non dovrebbe superare i 400k / 500k poligoni.

-Altra cosa importante, è che ho parlato di poligoni, mentre nella grafica 3d "off-line" possono essere usate curve parametriche come le NURBS. Cosa che attualmente è improponibile nella grafica real-time. La tassellizzazione è una procedura non troppo complessa, e ci sono delle demo in cui vengono visualizzati dei modellini fatti con curve parametriche, ma creare un intera scena in NURBS non è proponibile.

Per questa ragione ci sono pochi motori grafici che le supportano.

-Il raytracing non è fattibile attualmente, il motore grafico di quake 4 fa una specie di global illumination, ma non è una tecnologia di largo uso e non viene usata nei motori per la visualizzazione architettonica. L'illuminazione di solito viene precalcolata per gli oggetti fissi, e con l'ausilio di ombre tramite shadowmap si riescono ad ottenere buoni risultati. Per le riflessioni si può fare in due modi, possono essere "precalcolate" e si usa una speciale texture che rappresentano gli oggettti riflessi applicata in un modo particolare. Per oggetti in cui vuoi l'effettiva riflessione deve essere eseguito un ulteriore render per la riflessione.

Per esempio se c'è uno specchio, vanno fatti due rendering, uno dal punto di vista della telecamera, e uno dal punto di vista della telecamera specchiata, questo render verrà usato come texture da applicare allo specchio. Per fare la riflessione su una sfera o un qualsiasi oggetto non piatto vengono fatti diversi render e viene usato una particolare tecnica per calcolare la riflessione corretta. Se ti interessa -> http://en.wikipedia.org/wiki/Reflection_mapping

Come detto prima se hai uno specchio devi fare due render... questo implica che per avere l'immagine finale ci impieghi il doppio. Quindi di solito non è fattibile di fare una scena con 20 specchi, vetri e luccinichi tutti calcolati in modo preciso, e ci si affida alle riflessioni correte per gli specchi piatti, mentre per le superfici curve si usano delle reflection map statiche.

-tutto il resto è una questione di texture e di shaders. Il limite delle texture da usate è dato dalla memoria della scheda video e dal livello del filtro asintropico . Mentre sugli shader dipende dalla potenza della scheda video (da che tipo di shader supporta e dalle unità addette al calcolo).

Senza andare troppo nel tecnico lo shader è un programmino che gira sulla scheda video e decide come "colorare" gli oggetti. Prende le varie texture e le informazioni sulla geometria e fa i suoi calcoli, per esempio uno shader che usa la texture per il colore e la lightmap fa un calcolo semplicissimo, in cui moltiplica la prima texture per la seconda. Però se si vogliono effetti complicati come il parallax mapping gli shader possono diventare complicati e pesanti da calcolare.

Riassumendo, non puoi prendere il tuo modello che ci ha messo 10 ore a renderizzare e buttarlo in pasto ad un programma e sperare che te lo renderizzi in real time, devi fare un modello dedicato rispettando determinati limiti (di poligoni e di texture). Esistono vari programmi che ti calcolano da soli le riflessioni e hanno degli shader già fatti in modo che tu debba fare il minor lavoro possibile.

Alcuni girano come plugin per i browser web (e ti permettono di far vedere i tuoi lavori su internet) altri creano applicativi stand alone che puoi mettere su un CD e far vedere ai tuoi clienti.

Se li fai scaricare da internet hai restrizioni sulla grandezza... texture e modelli occupano un sacco di spazio, e anche una cosa semplice arriva ad occupare più di 5 mega, un modello complicato anche 100 e magari uno si scoccia a stare mezz'ora a scaricare un modello. Pensa che in un videogioco su 3 giga di roba almeno 500mb sono di texture.

I programmi sono diversi con costi e prestazioni diversi.. di solito quelli che costano di più sono quelli più semplici da usare (ma non è sempre detto).

Oltre a quelli consigliati da Fr3ak aggiungo Virtools e XVR.

Quest 3d è spettacolare però costa un accidente. O_O

Se usi V-ray si vocifera che ci sia anche la versione per il rendering realtime -> http://www.treddi.com/forum/index.php?showtopic=45609

Altri motori specifici per la programmazione in real time come Ogre, irrltch o panda 3d non te li mensiono neanche perché bisogna sapere programmare. :P

Ciaoo!! e benvenuto in un mondo di malati della matematica e taccagni di poligoni :lol:

edit: O caspita, mi ero dimenticato di fare propaganda a Blender..

Blender permette di fare applicativi navigabili in realtime!!! \ò/ (la nicchia vincerà)

Share this post


Link to post
Share on other sites

Ciao a tutti, desideravo soltanto fare qualche appunto alla risposta, peraltro esauriente, data in precedenza, in quanto mi sembra che alcuni punti possano essere precisati forse un po' meglio:

Considerando che un render normale ad alta qualità impiega minimo 20 minuti per essere eseguito bisogna precalcolare la maggior parte delle infomazioni. In particolare tutte le informazioni sul ray tracing devono essere precalcolate, sia perché richiedono molto tempo, sia perché sono difficilemente parallelizzabili.

E' vero che in generale il raytracing non e' adatto alle applicazioni realtime (se non altro perche' manca completamente il supporto hardware), ma non e' vero che non e' parallelizzabile: anzi, per sua natura il raytracing e' almeno tanto parallelizzabile della rasterizzazione usata per esempio nei videogiochi (e forse ancora di piu')...

Ci sono diverse limitazioni:

-La prima limitazione è il contenuto numero di poligoni della scena. Con le schede video attuali inizia ad essere difficile gestire una scena con più di un milione / un milione e mezzo di poligoni, inoltre se fai una rappresentazione del tuo modello e la vuoi distribuire a giro non puoi pretendere che tutti abbiano un computer ultra performante. Quindi una scena completa non dovrebbe superare i 400k / 500k poligoni.

In realta' credo che il limite sia nettamente superiore. A occhio e croce direi che se il rendering non e' limitato dalla cpu, dalla banda (i.e. tante texture di grandi dimensioni), da rendering multipli (per esempio per postprocessing o altri effetti simili) o da shader eccessivamente complicati, il limite possa essere aumentato di due o tre volte (credo che 5 milioni di poligoni non dovrebbero assolutamente costituire un problema). In realta', spesso la scena deve essere renderizzata diverse volte (per le shadowmaps o per effetti di riflessione ad esempio) quindi il limite deve tenere conto di questo.

-Altra cosa importante, è che ho parlato di poligoni, mentre nella grafica 3d "off-line" possono essere usate curve parametriche come le NURBS. Cosa che attualmente è improponibile nella grafica real-time. La tassellizzazione è una procedura non troppo complessa, e ci sono delle demo in cui vengono visualizzati dei modellini fatti con curve parametriche, ma creare un intera scena in NURBS non è proponibile.

Per questa ragione ci sono pochi motori grafici che le supportano.

Effettivamente non vengono molto utilizzate. Il primo gioco dove ricordo superfici curve era Quake 3...

-Il raytracing non è fattibile attualmente, il motore grafico di quake 4 fa una specie di global illumination,

In realta' non tiene conto della luce diffusa dalle altre superfici, quindi non puo' essere definito di global illumination (e', in un certo senso, l'equivalente del vecchio raytracing classico). Le ombre usano la tecnica degli shadow volumes...

Tutto qui, ciao!

Per quanto riguarda i consigli su cosa usare, OpenGL e DirectX sono pressapoco equivalenti per quanto riguarda il 3d (oddio, con la versione 10 le dx sono un po' piu' avanti, ma le OGL possono nel frattempo usare le estensioni, fio a quando non verra' rilasciata la nuova specifica...).

Pero' non sono un programma, ma una libraria: se vuoi scrivere il tuo programma di visualizzazione e desideri il supporto HW non ci sono alterantive a una di queste due librerie.

Per avere un buon aiuto riguardo la programmazione 3d (in particolare per tecnologie collegate a videogiochi e visualizzazione in tempo reale), le due migliori fonti sono a mio avviso www.gamedev.net e www.devmaster.org. All'interno di questi forum troverai sicuramente l'aiuto che ti server...

Share this post


Link to post
Share on other sites

Ich.. 5 milioni di poligoni vuol dire che hai poligoni più piccoli di un pixel (quindi inutili). Ho dato una cifra approssimativa, una scena completa può andare ben oltre quel limite ma visualizzarne contemporaneamente più di 500.000 secondo me è inutile. Si usa il LOD appunto per questo motivo. Per il resto concordo e hai fatto bene a precisare, però per dare un limite preciso entrano in gioco troppi fattori.

Aggiungo una cosa, visto che recentemente mi è capitato di convertire un modello architettonico in un modello real-time.

Non usate facce che si sovrappongono.

I motori di rendering usano numeri double (a 64 o 80 bit) per fare i calcoli quindi riescono risolvere i problemi di Z-fighting. I motori in real time usano la precisione float (a 32-bit) e i problemi di z-fighting fioccano ovunque, senza considerare che i piani sovrapposti non servono a niente.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...
Aspetta! x

Ti piacerebbe rimanere sempre aggiornato sulle ultime novità nel campo della computer grafica?

Iscrivendoti alla Newsletter riceverai subito una mail con le indicazioni per scaricare gratuitamente:

  1. Le immagini HDRI presenti su HDRI pro
  2. Una sequenza di 300 immagini HDRI generata da Luca Deriu tramite il programma Real HDR