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

Utilizzare tutti i processori con il Paarticle Flow in Viewport

Recommended Posts

Guest

Scusate se la domanda può sembrarvi banale (ma dopo un po' di crash sopratutto a fine giornata lavorativa con parolacce incorporate) perché 3D Studio Max non sfrutta tutti i processori della CPU ma soltanto uno in alcune operazioni basi come l'aggiornamento del Particle Flow in viewport?... c'è un modo per sfruttare tutti i core della CPU per tale operazione?...

(3D studio Max 2011 non so sulla 2012...)

ciao e grazie a tutti

Matteo

:hello:

Share this post


Link to post
Share on other sites
Guest

Non credo che tutti i tools di 3dsmax utilizzano tutti i processori.

dipende da cosa, forse le particle non sono state integrate per usarli tutti.

Share this post


Link to post
Share on other sites
Guest

Si, lo penso pure io, ma sarebbe il caso di rimettere mano ad alcuni Tools e magari aggiornarli... non si può lavorare con il conta-gocce e poi bestemmiare perché si pianta tra un refresh ed un autosave. Altro che ribbon, material editor, nuovi tools, interfaccia carina e m*****e varie quanto dovremmo aspettare per vedere un software decente nelle parti che contano?...

Scusate lo sfogo...

l'unica cosa che mi viene in mente è ridurre le particle in fase di view port (che le calcola lo stesso) e togliere alcuni processi (come l'autosave e quindi rischiare) che potrebbero andare in conflitto mentre max ragiona.

Mat

:hello:

Share this post


Link to post
Share on other sites
Guest

si puoi fare come hai detto tu, ma nel pflow non c'è la possibilità di avere la visualizzazione in viewport ridotta e nel render il numero desiderato come le particle di 3dsmax? non mi ricordo, per max si sono sicuro.


Edited by Mak21

Share this post


Link to post
Share on other sites
Guest

si puoi fare come hai detto tu, ma nel pflow non c'è la possibilità di avere la visualizzazione in viewport ridotta e nel render il numero desiderato come le particle di 3dsmax? non mi ricordo, per max si sono sicuro.

Si, come vedi sotto (immagine presa da un tutorial), c'è la possibilità di dirgli quante particles visualizzare in viewport e nel render, c'è anche la possibilità di alzare il limite di gestione delle stesse, ma il problema non è questo.

sea_step_8.jpg

Se te crei un PFlow con un numero elevato di particles (4.000.000 totali per esempio) è possibile che se io sposto lo slider ad un frame diverso da quello in cui mi trovo (sallo 0 al 10 per esempio) lui ci metta 20 minuti per farmi vedere cosa succede anche visualizzando in viewport solo lo 0.1% di particles?

Eppure sotto ho una buona macchina con 8 GB di Ram, una quadro ed un I7 (OS 64bit)... apri il task manager e vedi che sto s*****o lavora solo con un processore e non sta usando neanche tanta Ram... siamo nel 2011 perché su delle operazioni utili mi devo ritrovare a tirare bestemmie perché il software non riesce a sfruttare al 100% tutte le risorse?

vabbè un modo si trovava anni fa, lo si trova anche adesso, però penso tu capisca il giramento di palle che suscita.

Mat

:hello:

Share this post


Link to post
Share on other sites

Non so nel caso specifico a cosa sia dovuto questo problema di 3dsmax, ma devi considerare che non tutti i tipi di calcolo possono essere parallelizzati su più processori... Pensa per esempio ad un processo iterativo, nel quale la seconda iterazione si basa sul risultato della prima: è inutile eseguirle in due core diversi, tanto la seconda deve sempre aspettare la fine della prima... In quel caso è meglio avere una cpu con pochi core ma "veloci" piuttosto che tanti core ma "lenti" (come ad esempio sono fatte le gpu)...

Share this post


Link to post
Share on other sites
Guest

Si, come vedi sotto (immagine presa da un tutorial), c'è la possibilità di dirgli quante particles visualizzare in viewport e nel render, c'è anche la possibilità di alzare il limite di gestione delle stesse, ma il problema non è questo.

sea_step_8.jpg

Se te crei un PFlow con un numero elevato di particles (4.000.000 totali per esempio) è possibile che se io sposto lo slider ad un frame diverso da quello in cui mi trovo (sallo 0 al 10 per esempio) lui ci metta 20 minuti per farmi vedere cosa succede anche visualizzando in viewport solo lo 0.1% di particles?

Eppure sotto ho una buona macchina con 8 GB di Ram, una quadro ed un I7 (OS 64bit)... apri il task manager e vedi che sto s*****o lavora solo con un processore e non sta usando neanche tanta Ram... siamo nel 2011 perché su delle operazioni utili mi devo ritrovare a tirare bestemmie perché il software non riesce a sfruttare al 100% tutte le risorse?

vabbè un modo si trovava anni fa, lo si trova anche adesso, però penso tu capisca il giramento di palle che suscita.

Mat

:hello:

se ti può consolare mi è accaduta la stessa cosa con una animazione di operazioni booleane, tra un frame e l'altro ci metteva una vita, in pratica ci sono condizioni che in viewport fanno collassare le performance.

una volta raggiunte le impsotazioni volute è meglio tentare una visualizzazione box o con un proxy se può essere utile.

per l'incazzattura ti capisco.... :(


Edited by Mak21

Share this post


Link to post
Share on other sites
Guest

una volta raggiunte le impsotazioni volute è meglio tentare una visualizzazione box o con un proxy se può essere utile.

A livello di geometrie ok... anche se in alcuni casi il proxie non conviene, il problema sta sopratutto con le particle che non si possono proxizzare... cmq alla fine oggi ho risolto in parte, cambiando file e ripartendo da un file pulito al 100%... Ora siamo sotto produzione pesante e ci rimarremo per un bel po' quindi niente evoluzione in termine di software, ma con la 2012 hanno veramente cambiato qualcosa a livello di prestazioni o no? oltre sto problema delle boolean hai visto altri problemi simili o no?

grazie ancora (specie per la solidarietà) e buon fine

Mat

:hello:

Share this post


Link to post
Share on other sites
Guest

Non so nel caso specifico a cosa sia dovuto questo problema di 3dsmax, ma devi considerare che non tutti i tipi di calcolo possono essere parallelizzati su più processori... Pensa per esempio ad un processo iterativo, nel quale la seconda iterazione si basa sul risultato della prima: è inutile eseguirle in due core diversi, tanto la seconda deve sempre aspettare la fine della prima... In quel caso è meglio avere una cpu con pochi core ma "veloci" piuttosto che tanti core ma "lenti" (come ad esempio sono fatte le gpu)...

interessante...prossimamente vedo di approfondire...

Mat

:hello:

Share this post


Link to post
Share on other sites

Pensa per esempio ad un processo iterativo, nel quale la seconda iterazione si basa sul risultato della prima: è inutile eseguirle in due core diversi, tanto la seconda deve sempre aspettare la fine della prima

mi sembra una forte semplificazione sei sicuro che tutti i motori di simulazione siano monocore? se io simulo 2 particelle lo posso fare in parallelo e poi unire i risultati ad esempio: imho è un grosso limite di autodesk.

Share this post


Link to post
Share on other sites
Guest Obeso

è una cazzata.

solo se i sistemi sono lineari puoi agire in parallelo altrimenti ti attacchi. e, di solito, Navier-Stokes, non lo sono.

assurda semplificazione la tua.

ciao

Share this post


Link to post
Share on other sites
Guest

A livello di geometrie ok... anche se in alcuni casi il proxie non conviene, il problema sta sopratutto con le particle che non si possono proxizzare... cmq alla fine oggi ho risolto in parte, cambiando file e ripartendo da un file pulito al 100%... Ora siamo sotto produzione pesante e ci rimarremo per un bel po' quindi niente evoluzione in termine di software, ma con la 2012 hanno veramente cambiato qualcosa a livello di prestazioni o no? oltre sto problema delle boolean hai visto altri problemi simili o no?

grazie ancora (specie per la solidarietà) e buon fine

Mat

:hello:

il problema con le booleane lo avevo nella 2011, con la 2102 non ho provato.

ma in linea di massimma se siete sotto produzione intensa non si fanno passaggi senza fare qualche prova almeno con la trial.

Share this post


Link to post
Share on other sites
Guest _Mirko

è una cazzata.

solo se i sistemi sono lineari puoi agire in parallelo altrimenti ti attacchi. e, di solito, Navier-Stokes, non lo sono.

assurda semplificazione la tua.

ciao

Eh la cavolata l'hai detta pure tu Obeso. Algo ha parlato di particelle. Le simulazioni basate sulle Navier pure non hanno a che fare con particelle,ma con spazi discretizzati.

Le uniche particelle che fanno riferimento alle Navier come parentela sono le SPH,ma la' le Navier vengono riformulate quindi ti salta il discorso.


Edited by _Mirko

Share this post


Link to post
Share on other sites
Guest Obeso

risparmiavo ad algo tutta la incomprensibile trattazione.

e nella ritrattazione sono per caso lineari le equazioni? LOL

Share this post


Link to post
Share on other sites

hum nel link che hai fatto si dice "Le equazioni di Navier-Stokes sono in grado di descrivere completamente qualsiasi flusso fluido, anche turbolento. In particolare per un flusso turbolento, dove cioè le traiettorie delle particelle di flusso non sono più costanti nel tempo, un approccio numerico di calcolo è chiamato generalmente simulazione numerica diretta. A causa del fatto che le risorse di calcolo necessarie alla loro risoluzione cresce con il numero di Reynolds (quasi con Re³) e che tale numero può avere valori dell'ordine di 106-109, tale approccio resta tecnicamente impossibile."

quindi di che parli? solito capitan fanfara....

ecco la risposta corretta

http://www.orbaz.com/forum/viewtopic.php?t=2732

"There is no multi-core support for Particle Flow at the moment. We are working on it for the next release of Particle Flow. "


Edited by algosuk

Share this post


Link to post
Share on other sites
Guest Obeso

dai architetto algo, smettila.

pensare che il moto di una particella sia svincolato da quello delle altre e pensare di poter gestire i due problemi ( le due particelle ) in maniera indipendente una dall'altra..... è il primo errore.

aggravato dal fatto di aver dato del semplicistico a stez che invece poneva un esempio sacrosanto.

appurato che non è svincolato, pensare di poter gestire parallelamente le particelle significa supporre che le equazioni siano lineari e questa è un'altra idiozia.

le equazioni di navier stokes è noto siano irrisolvibili. si adotta spesso il metodo semi inverso in cui si suppongono note alcune condizioni al contorno.

ma al di là delle equazioni scelte e del modello adottato rimane assurdo pensare che qualsiasi esso sia, sia fatto da equazioni lineari.

insomma, in un insieme di particelle calcolarne una ad una separatamente e mischiarle è roba da asilo, non da simulazione, per quanto scrausa possa essere.

PS: secondo te perchè non c'è ancora soluzione? governo ladro? autodesk bastarda?

PS: ma poi, alla fine, riesci a capire che il tuo reply non risponde nè ripara alla sciocchezza detta sopra dova hai dato a stez del semplificatore su una sua osservazione sacrosanta. riesci almeno a capire che il tuo reply non ci azzecca per nulla? LOL. non stavamo cercando la risposta che hai trovato googlando ma il perchè a quella risposta.


Edited by Obeso

Share this post


Link to post
Share on other sites
Guest Obeso

turbolento lo hai sottolineato perche ti piaceva? LOL

@mirko: se nell'equazione vedi un integrale come fai a dire 'discretizzato'? è una cazzata. copio e incollo da wiki

Le equazioni di Navier-Stokes sono un sistema di equazioni differenziali alle derivate parziali che descrivono il comportamento di un fluido dal punto di vista macroscopico. L'ipotesi di base è che il fluido possa essere modellato come un continuo deformabile.

continuo. non discreto.

il discorso non mi salta. il discorso è che trattare ogni particella separatamente è una cazzata mostruosa.

chiudo l'ot buonanotte.


Edited by Obeso

Share this post


Link to post
Share on other sites

Mi dispiace di avere avviato un casino del genere :)

Volevo solo sottolineare che la mia affermazione non era riferita in maniera specifica alle particelle, ma voleva essere qualcosa del tipo "alcuni processi per loro natura non possono sfruttare più core, PUO' ESSERE che la situazione della viewport in esame sia legata a questa caratteristica e quindi non migliorabile".

Stez

Share this post


Link to post
Share on other sites
Guest _Mirko

Obeso sei un pochino obsoleto,i metodi numerici per distribuire il calcolo gia' ci stanno e non parlo di simulare una singola particella.Parlo di distribuire l'intera simulazione. Prendiamo l'algoritmo di task chiamato H-Dispatch,per esempio. Grazie a questo,i problemi di simulazione di particelle possono essere decomposti in task ortogonali che possono essere eseguiti in parallelo su macchine multi-core.

Alla base di queste soluzioni ci sta la divisione del problema in più domini non sovrapposti.

Non ci fossiliziamo troppo sulle teorie dei sistemi lineari,non finiremmo più questo OT.


Edited by _Mirko

Share this post


Link to post
Share on other sites

non ti preoccupare taz90 -_- imho obeso ci ha provato perche si sente un po chiuso, per cui è solo un attacco personale :rolleyes:.

direi che la risposta di Oleg B. chiarisce il fatto che è far diventare pflow multicore è fattibile e lo svilupperanno presto. perche non lo abbiano fatto in questo tempo ovviamente non lo dicono.

Share this post


Link to post
Share on other sites

Si, come vedi sotto (immagine presa da un tutorial), c'è la possibilità di dirgli quante particles visualizzare in viewport e nel render, c'è anche la possibilità di alzare il limite di gestione delle stesse, ma il problema non è questo.

sea_step_8.jpg

Se te crei un PFlow con un numero elevato di particles (4.000.000 totali per esempio) è possibile che se io sposto lo slider ad un frame diverso da quello in cui mi trovo (sallo 0 al 10 per esempio) lui ci metta 20 minuti per farmi vedere cosa succede anche visualizzando in viewport solo lo 0.1% di particles?

Eppure sotto ho una buona macchina con 8 GB di Ram, una quadro ed un I7 (OS 64bit)... apri il task manager e vedi che sto s*****o lavora solo con un processore e non sta usando neanche tanta Ram... siamo nel 2011 perché su delle operazioni utili mi devo ritrovare a tirare bestemmie perché il software non riesce a sfruttare al 100% tutte le risorse?

vabbè un modo si trovava anni fa, lo si trova anche adesso, però penso tu capisca il giramento di palle che suscita.

Mat

:hello:

uhmm mi pare strano, io sto lavorando su un progetto con 6.000.000 di particelle e fila tutto liscio, e calcola che ho un i5. La visualizzazione in viewport è settata a 0,01%.

Share this post


Link to post
Share on other sites
Guest

Cavolo... sparisco per un giorno e vi ritrovo a bisticciare. Per prima cosa grazie ad Obeso, Algo e Mirko per i link e le informazioni. Penso che alla fine sia un problema di 3D Studio Max e del suo PFlow perché non è multi-core.

@ Mak21 certo che sotto produzione non si cambia e non si rischia... specialmente se la pipeline non è solo interna, ma anche esterna... ad ogni modo un mio collega la sta provando, ma senza reali vantaggi avendo attualmente in studio una pipe-line basata su V-Ray non ne vediamo le reali potenzialità. Poi certo, bisognerebbe testarlo tutti assieme e vedere le reali potenzialità essendo in 2-3 i reali utilizzatori del software abbiamo 3 necessità diverse. Cmq il discorso è troppo lungo e complesso (p.s.: io diffido delle versioni con il numero pari :lol:;) )....

@ Fillofillo dipende anche dal file da quello che ne so ed il mio era un esempio al volo avendo fatto in precedenza una simulazione con 4 milioni di particles ed avendo riscontrato questo problema... non essendo a lavoro non posso controllare ed ho anche smesso di portarmi dietro il lavoro...

Mat

:hello:

Share this post


Link to post
Share on other sites
Guest

Cavolo... sparisco per un giorno e vi ritrovo a bisticciare. Per prima cosa grazie ad Obeso, Algo e Mirko per i link e le informazioni. Penso che alla fine sia un problema di 3D Studio Max e del suo PFlow perché non è multi-core.

@ Mak21 certo che sotto produzione non si cambia e non si rischia... specialmente se la pipeline non è solo interna, ma anche esterna... ad ogni modo un mio collega la sta provando, ma senza reali vantaggi avendo attualmente in studio una pipe-line basata su V-Ray non ne vediamo le reali potenzialità. Poi certo, bisognerebbe testarlo tutti assieme e vedere le reali potenzialità essendo in 2-3 i reali utilizzatori del software abbiamo 3 necessità diverse. Cmq il discorso è troppo lungo e complesso (p.s.: io diffido delle versioni con il numero pari :lol:;) )....

@ Fillofillo dipende anche dal file da quello che ne so ed il mio era un esempio al volo avendo fatto in precedenza una simulazione con 4 milioni di particles ed avendo riscontrato questo problema... non essendo a lavoro non posso controllare ed ho anche smesso di portarmi dietro il lavoro...

Mat

:hello:

si è vero le versioni pari sono sempre male accolte, per incrementi di velocità del rendering direi di no, è anche vero che qui ad ogni upgrade il motore diventa sempre più raffinato ma al tempo stesso richiede macchine più veloci, è da sempre cosi.

per unwrap direi che è più facile e veloce, per iray è una cosa per studi con alto budget

per la dinamica devo ancora provarla, nitrous si mi è piaciuto e lo trovo utile, i nuovi tools del graphite li vedo più per chi fa personaggi e creature, non per chi fa visualizzazione architettonica, il nuovo render progressivo di mental ray devo ancora provarlo ma penso sia simile a quello della 3.8, la qualità di mr 3.9 in alcune situazioni l'ho trovata superiore, nel senso che in alcune scene vedevo delle macchie dovute alla illuminazione indiretta e nella 3.9 non ci sono.

poi come sempre ci vuole del tempo per capire se tutto funziona o no.

dimenticavo le mappe substace sono molto utili per rappresentare tutti gli effetti naturali, un po pesanti da calcolare ma una volta capite possono evitare di passare ore a fare texturing in photoshop.

quicksilver l'ho trovato migliore per la rappresentazione dei metalli tipo cromature.

altro non ho avuto tempo di provarlo tipo il tools dinamite per la rappresentazione stradale che mi sembra interessante, anche se visto in una demo ha tanti comandi da impostare.

sicuramente nella versione 2013 ci saranno queste e altre novità ad esempio la collisione dei tessuti con la dinamica che già è disponibile per 3dsmax ma che non è stata integrata, forse sarà presene nella 2013 e speriamo che il famoso progetto excalibur sia ultimato.

Share this post


Link to post
Share on other sites
Guest Obeso

Obeso sei un pochino obsoleto,i metodi numerici per distribuire il calcolo gia' ci stanno e non parlo di simulare una singola particella.Parlo di distribuire l'intera simulazione. Prendiamo l'algoritmo di task chiamato H-Dispatch,per esempio. Grazie a questo,i problemi di simulazione di particelle possono essere decomposti in task ortogonali che possono essere eseguiti in parallelo su macchine multi-core.

Alla base di queste soluzioni ci sta la divisione del problema in più domini non sovrapposti.

Non ci fossiliziamo troppo sulle teorie dei sistemi lineari,non finiremmo più questo OT.

come fossilizzarsi sulle tabelline. non si usano più...

vabbuo dai


Edited by Obeso

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