Ok, questo DevLog è un lungo e corposo recap di quasi un mese di lavoro, ci sono un sacco di contenuti interessanti ma per leggerlo tutto dovrete armarvi di un po’ di tempo e di pazienza. Pronti? Via!

Già che sono in ballo con la review degli asset per cercare di ottimizzare e ridurre il carico complessivo di sistema nella scena completa, ho iniziato anche a sistemare man mano tutte le discrepanze e le anomalie che incontravo.
Siccome gli asset sono stati fatti a più mani, attraverso un arco temporale abbastanza lungo, utilizzando uno strumento che stiamo imparando a conoscere un pochino alla volta, è abbastanza naturale che non risultino omogenei tra di loro.
Ad esempio nella scelta dei nomi o nella struttura dei dati e delle collezioni oppure nell'utilizzo di una particolare convenzione per il setup di scena o cose del genere.
Una delle attività di cui mi sono incaricato in queste settimane è proprio di uniformare e standardizzare tutti gli asset sistemando tutte queste cose e tutti piccoli inconvenienti che incontro man mano, non ultima l'ottimizzazione di ogni modificatore e shader.
Stando così le cose ho deciso di affrontare diretto un problema che ho notato già da parecchio tempo ma che per pigrizia non mi sono mai deciso a risolvere: il problema della texture della finitura superficiale dei mobili della cucina.

Il problema della formica

Sapete tutti che cos'è la formica? È quel materiale (laminato plastico) che viene applicato come strato superficiale di finitura di molti mobili e da cui ne dipende l'aspetto estetico finale.
Il materiale che volevamo realizzare è ispirato (come tutto il modello di cucina) ad una cucina esistente. Il materiale reale presenta una rugosità superficiale molto caratteristica e ci tenevo che riuscissimo a replicarla perché credo possa essere di impatto nelle riprese ravvicinate.
Il buon @Wulfgar è riuscito a realizzare un ottimo shader procedurale che si avvicina moltissimo al campione reale.
Il problema però è che questo materiale è apprezzabile a distanza molto ravvicinata mentre da lontano appare semplicemente come un materiale completamente bianco uniforme.
Per questo motivo quando ho realizzato i mobili della cucina ho applicato un po' a casaccio questo shader, senza minimamente preoccuparmi di utilizzare una mappatura UV sensata e coerente tra un mobile e l'altro, e senza neanche preoccuparmi di applicare il fattore di scala degli elementi dei mobili prima di applicare lo shader procedurale...
A prima vista in realtà andava tutto bene e non si notavano anomalie di sorta, fino a quando abbiamo iniziato a realizzare i primi render test a distanza ravvicinata e ci siamo accorti immediatamente che la rugosità, la finitura superficiale della pannellatura dei mobili, cambiava drasticamente tra un pannello ed un altro affiancato, se non addirittura tra due facce dello stesso mobile orientate diversamente.
Mi sono tenuto questo scheletro nell'armadio negli ultimi mesi e a questo punto mentre sto sistemando tutti gli asset credo sia il momento opportuno per sistemare che questo problema.
Pensavo che mi sarebbe costato un sacco di tempo e di lavoro, in realtà ho trovato un approccio e un metodo di lavoro molto semplici. Il mio approccio è stato il seguente:

• innanzitutto ho realizzato un paio di shader di materiali che mi consentissero di visualizzare la mappatura UV e quindi la distribuzione della texture sui miei modelli. A questo scopo Blender aiuta molto perché incorpora già nativamente due mappe, due griglie pensate appositamente per testare le mappe UV e queste mappe sono accessibili dal pannello di inserimento di una texture di tipo immagine scegliendo New Image ed in Generated Type:  UV Grid oppure Color Grid

• una volta realizzato lo shader ho selezionato uno qualsiasi dei mobili importati nella scena poi tramite il comando SHIFT+L ho selezionato tutti gli oggetti e condividessero lo stesso shader quindi sono andato a sostituire la formica con il mio materiale di test

È bastato questo per capire immediatamente a colpo d'occhio che gran pasticcio ho combinato nella distribuzione delle texture, infatti la griglia era palesemente deformata, non uniformemente scalata in quasi tutti i mobili.
Per fortuna con l'aiuto di questa griglia è stato relativamente facile porre rimedio a tutto, utilizzando un'altra volta l'editing contemporaneo di più oggetti: ho selezionato tutti gli oggetti che condividevano lo shader con la griglia di test, ho applicato a tutti questi oggetti un UV unwrap con una mappatura di tipo proiezione cubica (perché i mobili che ho realizzato sono oggettivamente dei parallelepipedi di varie dimensioni orientati per lo più come gli assi principali xyz) e ritengo che la mappatura più semplice possa darmi il miglior risultato con il minor sforzo.
Inizialmente l'approccio non è sembrato funzionare correttamente, ma mi sono accorto di non aver applicato tutte le trasformazioni di scala agli oggetti selezionati, quindi con CTRL+A ho applicato tutte le trasformazioni legate alla scala ad ogni oggetto e ho ripetuto l’UV Unwrap con la proiezione cubica. A questo punto mi sono trovato con tutti i mobili mappati con la stessa proiezione coerente e uniforme tra tutti.
In realtà per un motivo che ignoro uno solo dei mobili ha ottenuto una mappatura uniforme e coerente ma apparentemente con un fattore di scala differente rispetto agli altri, ossia la griglia UV sembrava decisamente più grande rispetto ai mobili vicini… ma è bastato correggere la scala della texture localmente.

Una volta completata questa procedura e una volta soddisfatto della distribuzione della griglia su tutti i mobili della cucina, mi è bastato ripetere la selezione di tutti gli oggetti che utilizzano lo stesso shader e poi ri-applicare lo shader formica a tutti e salvare la nuova cucina.
Questo procedimento è finito a notte fonda e non ho avuto il tempo di “spippolarmi” con i rendering per far risaltare la qualità della nostra formica virtuale, tuttavia sono ottimista sul fatto che finalmente tutti i mobili della cucina abbiano un aspetto omogeneo e coerente!

La review della scena

Procede l'opera di ottimizzazione degli asset e grazie ad una prima scrematura, una prima pulizia superficiale limitata alla semplice riduzione dove possibile (senza perdita di qualità) nel modificatore subdivision surface, ho ottenuto lo spazio (nel senso di memoria libera) necessario all'inserimento tutti i nuovi asset realizzati da luglio ad oggi. Un risultato discretamente positivo tuttavia non sufficiente, in quanto mi trovo ancora nella situazione di circa 6Gb di memoria video e circa 20Gb di memoria RAM occupati durante il rendering.
Si passa quindi alla fase successiva: mentre è ancora da completare un lavoro di fino su tutti gli asset verificando dove è possibile recuperare ulteriori risorse (ad esempio lavorando sulle texture o sul modello stesso) ho provato a fare prima un controllo grossolano di dove fossero concentrate le maggiori richieste di risorse all'interno della scena.
A questo proposito credo che potrebbe essere estremamente utile avere un tool diagnostico in grado di rendicontare all'utilizzatore di Blender l'effettivo utilizzo delle risorse di sistema da parte degli oggetti di scena e la relativa ripartizione. Non ho avuto ancora modo di verificare se esiste qualcosa del genere già integrato in Blender o anche nella forma di addon terze parti, tuttavia penso possa essere un importante strumento per ottimizzare in maniera semplice veloce le scene complesse.
In ogni caso non disponendo per il momento di questo strumento magico ho deciso di procedere molto semplicemente analizzando per aggregati logici il nostro progetto, partendo quindi dalla cosa più ovvia: le collezioni in cui abbiamo suddiviso tutti gli asset presenti nella scena.
Il risultato è stato molto interessante poiché spegnendo e disattivando tutte le collezioni tranne una, ossia tranne l'involucro che rappresenta la stanza e contiene tutto l'ambiente, risultavano in fase di rendering già 3Gb di memoria video occupati… inspiegabile?!?
Apro una parentesi: non ho la più pallida idea di come interpretare i valori disponibili nella status bar di Blender in basso a destra dove intendo essere la memoria video il valore indicato, tuttavia non ho ancora avuto modo di informarmi per capire a fondo come è ottenuto quel valore. Da dove viene fuori? Da quali calcoli? Che cosa rappresenta esattamente? Tirando a indovinare sembra essere la quantità di memoria video occupata dalla scena visualizzata nella 3D view..
Quello che trovo essere interessante è il fatto che appena carico il progetto, sia esso sulla viewport in modalità wireframe o in modalità solid (che dovrebbero essere le più leggere) occupa già di partenza 2,2Gb per poi salire a 3,1Gb mettendo la viewport in modalità rendering con Eevee.
Sembra quindi che la mia scena composta solo ed esclusivamente dalle pareti, dai pavimenti e dalle luci ambiente (escludendo il bake della luce indiretta) occupi davvero troppo e credo sia abbastanza strano, dato che oggettivamente si tratta di geometrie semplici ed un quantitativo basso di facce e triangoli (stando al conteggio).
Tirando ad indovinare, la cosa più ovvia è che fossero le texture a occupare tutta quella memoria quindi ho iniziato a passare al setaccio tutti gli shader presenti in questa collezione. E da qui ho tratto l'insegnamento: passato un certo quantitativo di tempo dall'inizio dei lavori è bene tornare a controllare cosa si è fatto mesi prima. Soprattutto in un caso come il nostro dove siamo partiti con conoscenze scarse (rasenti lo zero) e quindi dove la curva di apprendimento nel tempo è stata abbastanza ripida.
Quando mi sono messo a guardare gli shader mi sono “messo le mani nei capelli” perché ho trovato una situazione disastrosa che non ricordavo assolutamente di aver lasciato... trattandosi dei primi elementi realizzati ed i primi shader mai fatti prima in Eevee, abbiamo commesso evidentemente un sacco di errori ed abbiamo lasciato in sospeso un sacco di situazioni che ovviamente in questo frangente stavano pesando su tutta la scena.
Ad esempio: ho trovato in diversi shader numerose texture importate (come nodi) ma lasciate scollegate da tutto, abbandonate. Anche se queste texture probabilmente non avessero un peso sul calcolo del rendering indubbiamente lo avevano sulla pesantezza della scena caricata in memoria, quindi ho iniziato dal togliere tutte le texture attualmente non utilizzate la maggior parte delle quali erano delle mappe per il displacement che non abbiamo utilizzato.

Inoltre questa review generale degli shader ha portato a trovare e correggere numerosi errori, anche se non palesemente visibili, indubbiamente influenti sulla qualità finale della scena, ad esempio: ho trovato numerose texture delle normali agganciate al nodo normal dello shader, gestite erroneamente come “color data” e di conseguenza con una lettura errata dei valori delle normali.
Un ulteriore passaggio è stato verificare la qualità delle texture utilizzate in base al soggetto visualizzato e ci siamo accorti che molti materiali che risulteranno solo ed esclusivamente di sfondo e mai inquadrati da vicino, utilizzavano texture in alta risoluzione (o altissima) e sono state di conseguenza sostituite con texture a risoluzione 2k.
Grazie a questa manovra e ripulendo la scena di tutti i file ed i nodi orfani ho ottenuto che il progetto appena aperto in Blender occupasse circa un giga di memoria video e che questa memoria salisse solo fino a un giga e mezzo attivando nella viewport il rendering, ovviamente con la sola collezione dell'involucro e delle luci attivate, in ogni caso un miglioramento pazzesco rispetto a prima!
Ho ripetuto la stessa procedura per gli elementi di scena che compongono l'ambiente, ossia: infissi, modanature, arredamento ed ho ottenuto un incredibile risultato passando complessivamente in rendering nella viewport a soli 2,5 giga di memoria video occupata!
Ricordo che a fine serata ho fatto solo una prova veloce di riattivare tutte le collezioni e sono rimasto davvero sorpreso di constatare che con questa manovra sono tornato ad avere “solo” 4,6Gb di memoria video complessivamente occupata per il rendering della scena completa e tutto questo senza aver ancora finito di passare in rassegna con la stessa procedura tutti gli asset (che non sono pochi).

Il diavolo è nei dettagli

L'ultima settimana è stata all'insegna della pulizia e della ottimizzazione di tutta la scena e di tutti gli asset.
Dopo aver ripulito il file di base contenente essenzialmente i muri o più genericamente l'involucro dell'ambiente ed il setup di telecamere e luci, sono passato alla pulizia e alla ottimizzazione di tutto l'arredamento e di tutti gli elettrodomestici che sono incassati nei mobili della cucina.
Il turno successivo è stato quello degli asset che potremmo definire minori o opzionali ossia tutti quei modelli che abbiamo realizzato e stiamo continuando a realizzare per popolare la scena, arricchirla, renderla credibile e realistica come dovrebbe essere una cucina vissuta quotidianamente.
Il lavoro sugli asset opzionali non è troppo differente da quanto fatto finora sul resto, quindi sono partito dal rinominare file e collezioni (abbiamo iniziato a creare utilizzando parole in italiano, ma abbiamo finito ultimamente per utilizzare invece terminologia inglese, in vista di eventuale distribuzione).
Dopo aver rinominato file, collezioni ed eventualmente anche alcuni modelli, ho verificato qualora fossero presenti dei modificatori, come ad esempio subdivision surface, che non fosse utilizzato in maniera eccessiva. Dove possibile ho ridotto l'entità della mesh ovvero il conteggio dei poligoni delle facce e dei triangoli, cercando di mantenere lo standard qualitativo definito in partenza.
In alcuni casi la riduzione del subdivision surface ha causato delle alterazioni nella distribuzione della texture (mappatura UV) e quindi si è reso necessario rimettere mano al “unwrap”.
Per concludere ho fatto una review generale di ogni asset per capire se ci fossero minimi semplici miglioramenti qualitativi possibili partendo dal presupposto che molti asset sono stati fatti all'inizio di questo progetto, quando non avevamo ancora preso confidenza con gli strumenti, mentre a distanza di diversi mesi di attività e con le conoscenze acquisite fino a questo momento è ipotizzabile che sia possibile migliorare (anche di poco) il modello senza appesantirlo.
Spesso e volentieri queste migliorie sono state inserite in punti o elementi non palesemente di primo piano, o di primaria importanza, quindi è possibile che la maggior parte non vengano nemmeno percepite tuttavia come si suol dire: “il diavolo è nei dettagli” e io credo che anche elementi secondari in secondo piano, fatti in un certo modo, possano arricchire la qualità visiva del prodotto finale.
Per questo motivo inserire una leggera spaziatura tra i pulsanti della lavastoviglie, smussare la cinghia della tapparella e inserire il tendicinghia, o sostituire alcune texture non soddisfacenti come quella della griglia della cappa di aspirazione della cucina con altre PBR molto più realistiche, ha richiesto sicuramente del tempo aggiuntivo non previsto inizialmente ed il lavoro di review degli asset ha occupato un discreto quantitativo di tempo.

Sebbene la mole di lavoro da fare su ogni asset fosse già sufficientemente elevata mi è sembrato il momento giusto per fare un ulteriore passo avanti.
Man mano che ripulivo gli asset e li passavo in rassegna ho cercato di valutare quali tra quelli già preparati fossero papabili per essere pubblicati sui marketplace. In questo caso si è reso necessario importare questi asset in un file template che abbiamo predisposto allo scopo di generare i contenuti accessori per la pubblicazione.
A quanto sembra però questo passaggio deve essere migliorato ulteriormente, perché parlando internamente con il team sono emerse delle perplessità.
Sebbene abbiamo realizzato al momento più di una cinquantina di asset e siamo molto soddisfatti di ognuno di essi, la realtà dei fatti è che la maggior parte di questi modelli sono relativamente banali, sono oggetti di uso comune in una cucina (o in un scena di visualizzazione architettonica) e ne esistono già decine su vari marketplace e probabilmente fatti anche meglio...
Da qui la perplessità e le domande che ci siamo posti su quanto senso avesse pubblicare questi asset individualmente, oppure se avesse senso studiare combinazioni differenti per renderli più appetibili, ad esempio: invece di pubblicare un asset di una mela, uno di una pera e poi di una banana, si può pensare di accorparli in un asset solo con un cesto di frutta.
Un'altra alternativa che stiamo valutando è quella di pubblicare comunque tutti questi asset che presi individualmente potrebbero non essere appetibili, in forma completamente gratuita.
Al momento abbiamo provato solo con pochi asset, un po' più particolari, per i quali abbiamo ritenuto sensato pubblicarli sui marketplace così come sono individualmente. A parte questi pochi asset, per tutti gli altri invece abbiamo sospeso l'attività di confezionamento e una volta finalizzata l'operazione di pulizia e ottimizzazione abbiamo preferito lasciarli così come erano ed importarli nella scena finale.
In ogni caso questa parte di attività e la pianificazione della distribuzione è ancora fortemente in divenire e finora abbiamo solo condotto alcuni esperimenti per iniziare a fare esperienza, di conseguenza è presto per trarre le conclusioni vedremo nei prossimi giorni come si evolverà.