Visualizza Versione Completa : OUT MEMORY nooooooooooooo
Ciao mi è apparso un messaggio molto brutto tipo out of memory render buffer .... in pratica LW non riesce a renderizzare però vedendo la scena statistic ho 600 mb di ram ancora liberi...
Poi mi è apparso un altro messaggio sempre dal layout che mi dice che non ho abbastanza memoria per caricare un oggetto poi si chiude lasciamdomi con una finestrella di error...
Volevo sapere se esiste una soglia di poligoni che lw riesce a gestire...
Per ora riesco a renderizzare 3200000 di poligoni quando supero questa soglia si pianta oppure mi da il famoso messaggio... Ho montati 3gb di ram e uso un amd 64 3400+... Se avete qualche consiglio per migliorare le prestazioni lo accetterei volentieri.:yeah:
Solferinom
13-01-07, 21:29
Prova ad abbassare il valore di "segment memory limit" in "camera options"...
oppure è ora di passare ai 64bit :D
vashts
Prova ad abbassare il valore di "segment memory limit" in "camera options"...
Ho provato ma niente bisogna avere un computer della Nasa :D
versione di lw, impostazione di segment memory limits, numero di texture caricate e dimensione.
dimensione del file di swap di win, memoria reale montata sul computer, etc...
per ridurre la memoria richiesta puoi :
usare segment memory limits molto basso, tipo 8 mb in modo che lw faccia più segmenti ma ti permetta di renderizzare.
tutte le texture non colore convertirle a texture indicizzate a 8 bit, tanto verrà vista solo la luminosità e quindi risparmi memoria
usare screamernet che non carica tutta la memoria richiesta dal layou t e utilizza meglio la memoria
riavviare la macchina con il minimo dei servizi richiesti
aumentare la ram della macchina
Solferinom
14-01-07, 17:54
Una domanda...che sistema operativo utilizzi?
oppure è ora di passare ai 64bit :D
vashts
i 64 bit ti servono solo se hai più giga e non te li vede xp, che fino 4 gb te li vede, ma in generale se non li hai, il 64bit ti riduce solo i plugin esterni utilizzabili. ho disinstallato win64bit proprio per questo, e per il fatto che nonostante le promesse varie, ancora diverse periferiche non hanno driver a 64bit, e usare un sistema a 64bit per poi usare i programmi in modalità emulata per ora era un'inutile ridondanza...
versione di lw, impostazione di segment memory limits, numero di texture caricate e dimensione.
dimensione del file di swap di win, memoria reale montata sul computer, etc...
per ridurre la memoria richiesta puoi :
usare segment memory limits molto basso, tipo 8 mb in modo che lw faccia più segmenti ma ti permetta di renderizzare.
tutte le texture non colore convertirle a texture indicizzate a 8 bit, tanto verrà vista solo la luminosità e quindi risparmi memoria
usare screamernet che non carica tutta la memoria richiesta dal layou t e utilizza meglio la memoria
riavviare la macchina con il minimo dei servizi richiesti
aumentare la ram della macchina
Io uso xp pro 32bit, cmq raga non va bene visto che LW mi lascia 600 mb di ram libera fisica fa fatica a renderare :( e mi dice che non c'è memoria... manco dovessi fare render a 4k...uso risoluzioni PAL...
Quello che ho notato è che a volte riesce a renderare scene con + poligoni di una scena con meno oggi è apparso un nuovo messaggino tipo che non riesce a gestire gli array boh...ogni giorno una novità :D Dovrebbero creare un plug interno per gestire oggetti simili senza uso di memoria le famose istanze...forse nella versione 12 z lo faranno.
uhm, puoi dare più info? con la 8 ho renderizzato scene con qualche centinaio di oggetti, per oltre 6 milioni di poligoni, circa 20 personaggi in movimento totale e una ottantini in movimento saltuario con 1 gb di ram per macchina, decine di luci, full raytracing con riflessioni, rifrazioni, ombre area etc...
le statistiche non le ho mai guardate, o meglio non le ho mai prese in considerazione perchè non erano affidabili, da quello che ho visto sono le statistiche di lavoro al momento in cui sei nel layout, non le occupazioni di memoria di quando verrà fatto il rendering.
effettivamente però sembra strana la cosa, maggiori info sulla scena ne puoi dare?
tra l'altro se usi la 9 dovrebbero averla ottimizzata proprio per la quantità di elementi a salire...
se usi invece la beta tutto può essere
i 64 bit ti servono solo se hai più giga e non te li vede xp, che fino 4 gb te li vede, ma in generale se non li hai, il 64bit ti riduce solo i plugin esterni utilizzabili.
a me lw9 x64 suddivide (tramite aps) degli oggetti ke altrimenti lw9 x32 nn fa.. e la macchina è la stessa. inoltre, se fosse come dici, nn vedo perché ho dei discreti margini nel tempo di resa tra la medesima lw9 x32 e x64 (ovviamente a favore di quest'ultima)..
x il resto ti do ragione: il sacrificio di plugin col modeler x64 è notevole, ma si può sempre trovare un compromesso.. :g1:
vashts
ciao Vasht
a seconda del tipo di processore puoi avere incrementi più o meno forti di velocità, con la 9 ho trovato differenze veramente lievi rispetto alle differenze eclatanti che avevo trovato con 8.5 win64, e dato che uso tonnellate di motion modifier esterni, shader, plugin esterne di ogni tipo, mi è quasi impossibile usare lw64. idem con l'ultima beta (ho disinstallato l'altro ieri win64).
io ho ancora (si fa per dire) un athlon 64, magari con i nuovi x2, dual core e mille altre diavolerie a 64 bit le differenze sono più eclatanti, ma non ho avuto modo di provare.
per il discorso suddivisione con aps non ho trovato la differenza, ma dipende dalla ram installata e quanto hai spinto in pesantezza il render, ma dove esageravo sia sulla 64 che sulla 32 mi fermavo.
per i plugin... beh se in newtek prendessero esempio da un'altra casa (maxon per fare nomi) e decidessero radicamente di cambiare il sistema, potrebbero risolvere molti problemi.
se scarichi la demo di c4d hai i diversi eseguibili per mac (già universal), win e win64 e una cartella comune con i plugin realizzati in una compilazione comune, che evita il problema della ricompilazione per piattaforma, le chiamate al sistema vengono fatte tramite c4d, e quindi risolte...
in teoria anche lw avrebbe dovuto fare una cosa del genere, ma purtroppo poi non è proprio così, perchè i plugin li devi adattare da piattaforma a piattarforma riscrivendo delle parti per adattarli.
forse in questo momento potrebbero causare un po' di disagio, ma poi si ripartirebbe decisamente meglio e per chi non è d'accordo e pensa che sia una idea scomoda, pensate a tutti gli altri pacchetti, che ogni release costringono i vari sviluppatori di plugin a riscrivere per la nuova versione i plugin, e allo stesso tempo generano introiti per tutti...
ma forse sarebbe proprio il momento, visto che la chiamano la rinascita di lw ;-P
Ciao ho scoperto che LW può usare SOLO due giga di RAM dovuti alle limitazioni di Window a 32 bit.
Seconda cosa vorrei sapere se aumentando la memoria virtuale si hanno delle agevolazioni oppure conta solo quella fisica...
Cmq ho letto che molta gente si lamenta di sta cosa....
ciao,
quando ho avuto problemi con i due giga e ho messo il terzo e la flag nel boot di xp32, i problemi li ho risolti, quindi a livello di prova pratica ti direi che legge anche i 3gb, anche perchè io sapevo che il limite di win era dovuto a molte impostazioni interne, non solo al limite dei 32bit, e comunque sul 32 bit sono 4gb non 2,
"32-bit processor uses 32 bits to refer to the location of each byte of memory. 2^32 = 4.2 billion, which means a memory address that's 32 bits long can only refer to 4.2 billion unique locations (i.e. 4 GB)."
poi windows è avido e tiene 2gb per il kernel e 2 per le o la applicazione, e questo è un altro discorso, applicando la flag /3gb significa che forzi il sistema a dare solo (si fa per dire solo) 1 giga al kernel e quindi gli altri 3 gb all'applicazione.
da prove fatte aumentare la memoria virtuale non serve molto, lw sembra ignorare la cosa, anche perchè in passato per rendering molto grandi ho provato a dare swap file da 20gb, ma non si risolveva il problema memoria.
la memoria virtuale: meno la si usa, meglio è.
se il problema è di win, cmq, nn vedo come lw possa aggirarlo. alla fine, la naturale evoluzione è passare a sistemi che permettano l'uso di più memoria, ovvero i 64bit, perchè nn si può pretendere di coltivare un campo di 500m² se ne abbiamo solo 100m² (miii.. scusate.. questa mi è venuta così.. :yt: )
io poco fa sono arrivato cmq a 3.5gb tra memoria e swap, e ho solo 2gb disponibili.. lw ce l'ha fatta.
vashts
in generale io usavo entrambe le versioni sotto il 64bit, il modeler ho quasi sempre usato il 32bit, per il discorso plugin e per il fatto che non ho mai avuto problemi di memoria sul modeler, forse un paio di volte anni fa con le booleane, ma a parte in quel caso i miei modelli sono sempre leggeri quindi non avevo il problema.
per il layout ripeto, può essere anche una differenza di processore, io ho un athlon64 prima generazione, quindi possono esserci anche differenze molto eclatanti con processori più recenti, ma non ho modo di verificare.
anche maya 8 non mi ha dato differenze prestazionali tra i due os (tranne una cosa del paint fx, ma credo che sia legato all'allocazione della memoria quando si usa paint fx) per cui mi ritrovavo solo svantaggi con win64, e l'ho tolto per quello.
cinema 4d 10 ha dato differenze ma limitate al 2-3% per cui può essere che sia legato al discorso della gestione della memoria.
per il resto posso darti una casistica limitata.
comunque in generale ho visto poco la differenza (sul mio processore) più che altro è stata la possibilità di gestire la memoria in modo più rapido, la risposta dei pacchetti, e la maneggevolezza dei dati è tanta, ma devi avere anche tanta memoria, ho fatto la prova a spostare da due macchine su una macchina sola tutta la ram, per avere 4gb e la differenza è tanta, mentre sul win32 sembra che comunque il kernel assorba molta più memoria del necessario.
per il discorso aps credo che il discorso sia legato al fatto che il sistema sotto win64 si appropri di meno memoria, quindi di quella totale ne rilascia di più all'applicazione rispetto a win32, però è una cosa che ho letto su una recensione di win64bit on line, quindi da prendere con le pinze.
ciao
p.s. adesso cos'hai come processore?
p.s. adesso cos'hai come processore?
AMD Athlon64 X2 4200+, la ram è una normale DDR-400 in quantità 2GB (2x1GB in dualchannel).
vashts
rispetto al mio vecchio a64 sei già su un altro pianeta...
Io non capisco, ho fatto dei test, io uso molto il preview in wire e open ogni tanto LW mi dice che non ce la fa la ram ok e non crasha ma se faccio un render mi da sorting array. Premetto che uso degli oggetti piuttosto pesanti.
Cmq non esiste che debba ricaricare sempre la scena per fare quello che voglio, questo significa che LW non ha una buona gestione interna della memoria e non esiste nemmeno un tasto per svotare i dati immessi in ram...
Boh ogni giorno scopro cose incredibili...
beh anche a me è capitato di avere scene che potevo fare le preview opengl e non il render e ho risolto facendo più passate di composting, ma è normale
nel momento in cui hai modelli pesanti che dovranno nel rendering creare mille e più informazioni, non vedo la connessione tra la previz wire-opengl e il render, il livello di complessità è molto ma molto più alto.
in realtà programmi che liberano la memoria, o che la puliscano, mi viene in mente after effects e photoshop, perchè la sporcano in modo indicibile e non rilasciano i buffer, un programma di prototipazione e bon, ma gli altri pacchetti che io ricordi non hanno funzioni di pulizia e defrag della memoria
Ciao oggi sono riuscito renderare un file in HD resolution, uno solo still frame, il problema nasce quando voglio rifare un render singolo mi dice frame buffer out of memory o ma che cavolo bisogna fare per ridare memoria a LW...L'unica per adesso è rifar partire il programma, ho settato il segment memory a 1 MB...Se avete dei consigli...
Se avete dei consigli...
formattare? :D
nn so, ma mi sembra molto strano come problema e, sebbene ce ne siano anche in lightwave, questo nn me la sento proprio di attribuirglielo. sembra che il programma sia limitato ad una piccola porzione della memoria disponibile.. boh.
x caso usi il psd exporter con tanti buffer da salvare? nn mi viene in mente altro..
vashts
Non penso visto che capita su 4 computer della ditta...
renderizzare con screamernet? richiede meno memoria del layout e se usi un buon gestore renderizza ogni frame come singolo, richiedendo meno memoria.
altrimenti ti direi che sei sul limite, se hai tante texture riduci i bit di tutte quelle che non sono color e normal map a toni di grigio a 256 colori, tanto i colori non ti servono, escluse mappe da zbrush se ne hai.
fai più passate dividi la scena in più elementi e li renderizzi separatamente.
Non penso visto che capita su 4 computer della ditta...
allora no..
mi trovi spiazzato, perchè sul mio pc un'immagine in full hdtv la renderizza tranquillamente.. poi bisogna vedere quanta roba c'è in scena.. a tal proposito, ci posti uno screen delle statistiche di una scena che ti da problemi? c'è il pannello apposta nel layout..
vashts
Abbiamo fatto un progetto usando sta render farm www.rendercore.com (http://www.rendercore.com) qualche frame l'hanno fallito per poca memoria incredibile...nei log è uscito fuori lack of memory...eppure la scena è composta da 1.700.000 di poligoni...
Boh cmq ho letto su un forum che per liberare memoria tra un frame e l'altro se fai un copia incolla di una linea di testo aiuta a pulire la ram cmq devo ancora testarlo...:confused:
poi x quello screen delle statistiche di una scena? oppure puoi pubblicare (o mandarmi via mail, nel caso ci fossero problemi di copyright) un frame della scena? nn capisco, veramente.. un esempio potrebbe aiutarmi.
2 cose ho cmq in mente:
1) texture enormi;
2) oggetti in subpatch: ce ne sono? l'1.7 milioni sono i poligoni in fase di rendering o prima del rendering? assicurati magari di avere oggetti in subpatch classica, o se hai oggetti in CC attenzione ai livelli di suddivisione, i quali sono terribilmente diversi da quelli delle vecchie subpatch. a volte nn ci si accorge di avere oggetti in CC e si mette una suddivisione a 8 o 10 con oggetti complessi, il che significa decine di milioni di poligoni generati in fase di rendering, mentre fare lo stesso in subpatch vuol dire arrivare solo a qualche centinaia di migliaia.
vashts
red_eyes80
26-01-07, 23:05
Come ti hanno già consigliato credo che disabilitare la visualizzazione opengl quasi del tutto oppure avere in scene molte bounding boxes potrebbe risolvere molti dei tuoi problemi.
Altrimenti postersti eliminare il problema gestendoti il render con i layer.
Per me dovrebbero fare un tasto per pulire il buffer poi inserire le istancing e sarebbe tutto una passeggiata di salute...Cmq raga utto bene era solo per capire se c'erano dei trucchetti per spendere meno ram...+
Cmq vai trah sulle Subpatch ci sto molto attento :D.
Ciao ragazzi,
allora io ho fatto per un paio di anni lavori per la stampa ad high res, si parla di 3000 x 2000 quindi siamo ben oltre il formato hd, e in un modo o nell'altro i limiti di memoria li ho aggirati, renderizzando su macchine con 1 gb di ram, all'inizio con lw7.5 e poi con le diverse versioni della 8.
con la 8 ho realizzato render per un'animazione (formato video pal) con oltre 5 milioni di poligoni, circa un centinaio di personaggi di cui 20 in movimento, tutti in subpatch, più la scena, perchè non ci sarebbero stati i tempi per comporre i diversi layer.
bisogna analizzare le scene, le impostazioni di screamernet etc.
il discorso di pulizia della memoria è semplice basta avere un gestore (butterfly net render) che ha l'opzione che ad ogni frame renderizzato chiude e riapre lo screamernet, in questo modo non ci sono rischi di accumulo di dati negli stack di memoria dello screamernet.
segment memory limits : impostate il minimo che vi permette di fare tutto in un passaggio solo, non di più, se non basta mettete 1, per mal che vada sarà leggermente più lento.
se avete problemi con i plugin di salvataggio salvate in formato flex, che non richiama nessun plugin, sarà più ingombrante, ma è un formato full 96bit, lo potete riesporre, manipolare e gestire a posteriori
controllare le scene e ripulitele da ogni cosa non necessaria
usate screamernet è molto più ottimizzato che il layout, è nato per renderizzare e richiedere meno memoria
valutate sempre la possibilità di renderizzare in più passate. considerate che certe cose come gli effetti volumetrici possono aumentare i tempi di rendering e la memoria se renderizzati insieme alla scena mentre se renderizzati in passate separate potete passare da 30 minuti a 3!
c'è un tutorial su 3d attack di novembre se non ricordo male proprio a proposito di questo.
prima di lanciare un rendering ripetete sempre il mantra : "ho ottimizzato la scena? ho eliminato le cose inutili? ho tolto la spazzatura dalla finestra, altrimenti il gatto mi rompe il sacchetto"
la disponibilità di macchine ultraveloci e di tanta memoria porta allo spreco, e poi ci si lamenta che con 2gb non renderizza una scena da 1.7 milioni di poligoni...
purtroppo c'è newtek che (autocensura preventiva perchè stavo per rivelare una cosa della openbeta) e quindi la gente si sentirà per questo ancora più invogliata a mettere poligoni e magari ad usare il radiosity invece delle area light, solo perchè (ulteriore autocensura, stasera mi sento previdente), e ne saremo grati...
comunque se usate le subdivision usate APS, la suddivisione adattativa in base alla ditanza, utiizza molto meno memoria delle subdiv tradizionali, in proporzione, quindi ottimizzate. e non dimenticate che adesso si possono usare anche le normal map, non è che dovete fare tutto con le displacement, e le bump non sono poi da buttar via...
poi inserire le istancing e sarebbe tutto una passeggiata di salute...
un po' come accade nella scena in allegato? 1 colonna da 8274 poligoni istanziata 1295 volte, per un totale di più di 10.000.000 di poligoni (nn sto a fare il pignolo a contare i triangoli.. che sarebbero di più..), poco più di 300mb di ram occupata durante il rendering (coi buffer allocati), full GI, texture procedurali con world coordinates per dare diversità più mappe bmp fisse; cushion camera coi parametri che vedete in allegato; un po' di bloom aggiunto in post.
eheh :evil: chi mi trova il dettaglio che è anche una bella soffiata? :g1: ah.. ovviamente il renderer è kray 1.7OBxx :evil:
vashts
Grande Tempesta!!!! Vash, prova con LW a fare sto render delle colonne :D
Vash, prova con LW a fare sto render delle colonne :D
con neanche 500 colonne lightwave occupa da solo, senza fare nulla, tutti i miei 2gb di memoria.. pensare di premere F9 mi sembra un suicidio. nn è proprio una scena fattibile con lightwave, almeno che nn abbiate la versione x64 e 8gb di ram.. diciamo che una situazione del genere può essere gestita solo tramite istanze, lightwave le avrà in futuro durante il ciclo 9.x, ma kray le supporta già da ora, ed usarle è talmente banale (bastano dei null con lo stesso nome dell'oggetto che devono istanziare).
ma nn avete fatto nemmeno caso alla soffiata che vi ho fatto? :mmgh: delle istanze si sapeva, ma di un'altra cosa no..
vashts
Istanze MITTTICO :D Come lo hai saputo?
Istanze MITTTICO :D Come lo hai saputo?
:mad: ma delle istanze si sapeva già da tempo..! :memad: guardate (o leggete) meglio.. su su, un po' di spirito di osservazione..
vashts
:mad: ma delle istanze si sapeva già da tempo..! :memad: guardate (o leggete) meglio.. su su, un po' di spirito di osservazione..
vashts
si vashts... volevi farci dire che kray supporta le nuove camere di lw...
(cos'ho vinto???)
:P
bye
:mad: ma delle istanze si sapeva già da tempo..! :memad: guardate (o leggete) meglio.. su su, un po' di spirito di osservazione..
vashts
Marò ti giuro non lo sapevo, cmq se hai un link :D
si vashts... volevi farci dire che kray supporta le nuove camere di lw...
bravo :g1:
Marò ti giuro non lo sapevo, cmq se hai un link :D
c'ha preso happymilk..
modelling tools!?
:noidea: :confused:
vashts
La prospective l'ho provata ma mi ha dato dei casini, non renderava una mappa che era visibile solo con la classic okkio :D
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.