Vai al contenuto

falcon76

Members
  • Portfolio

    Portfolio
  • Numero messaggi

    180
  • Registrato

  • Ultima Visita


Attività reputazione

  1. Like
    falcon76 ha ricevuto reputazione da Michele71 in Presentazione   
    Ciao a tutti mi chiamo Luca e lavoro come BIM coordinator in una società di ingegneria nell'ambito della progettazione farmaceutica. Uso Revit da un paio di anni ma ho esperienza con altri software impiantistici da una ventina di anni. Purtroppo anche in ambito industriale utilizzare una metodologia BIM è difficile, a causa di alcune grosse carenze di REVIT sulla modellazione piping e la mancanza di esportazione IFC da altri pacchetti. Sono curioso di sentire esperienze diverse!
     
  2. Like
    falcon76 ha ricevuto reputazione da Michele71 in Presentazione   
    Ciao a tutti mi chiamo Luca e lavoro come BIM coordinator in una società di ingegneria nell'ambito della progettazione farmaceutica. Uso Revit da un paio di anni ma ho esperienza con altri software impiantistici da una ventina di anni. Purtroppo anche in ambito industriale utilizzare una metodologia BIM è difficile, a causa di alcune grosse carenze di REVIT sulla modellazione piping e la mancanza di esportazione IFC da altri pacchetti. Sono curioso di sentire esperienze diverse!
     
  3. Like
    falcon76 ha dato la reputazione a Daniele Marelli in Dynamo - Concetti base   
    Dynamo è una piattaforma di programmazione visuale open source per progettisti.

    Prima di iniziare a dare definizioni e spiegazioni vorrei soffermarmi su una caratteristica di Dynamo, l'essere open source. Questo non vuol dire solo gratuito, ma anche la possibilità di studiare, sviluppare e creare versioni alternative a quella ufficiale. Continuando a parlare di software libero, anche la sua guida ufficiale, il Dynamo Primer, è open source e da la possibilità di creare le proprie versioni o collaborare a quella ufficiale. Citando il sito di Dynamo, il Primer è "una risorsa introduttiva per principianti e un riferimento a lungo termine. Una spiegazione strutturata di ogni cosa, dalla gestione dei dati alla geometria computazionale e la collaborazione con Revit". Il Dynamo Primer è disponibile a questo indirizzo: http://dynamoprimer.com/en/ in inglese, tedesco, giapponese e taiwanese. Una buona notizia per quelli che preferiscono studiare argomenti come questi in italiano piuttosto che in inglese (o in taiwanese): qualche anno fa avevo iniziato a tradurre il Primer, purtroppo abbandonando il progetto per mancanza di tempo, ma traducendo comunque i primi quattro capitoli, sufficienti a dare un'introduzione generale ed a capire di cosa stiamo parlando. Lo potete trovare qui: https://github.com/Mareck1996/DynamoPrimer/tree/master/it Non ha la formattazione della guida ufficiale, ma dovrebbe essere comunque fruibile. cercate nelle singole cartelle e aprite i file .md per trovare la pagina che vi interessa. Vi consiglio di seguirlo in simultanea con la guida in inglese per avere un riferimento nella formattazione del testo. 
     
    Riporto qua sotto la sezione 1.1 - "Cosa è la programmazione visuale?". Alla fine trovate un'altra piccola spiegazione di alcuni termini utili.
     
     
    Cosa è la programmazione visuale?
    Progettare spesso richiede stabilire relazioni visive, sistemiche o geometriche tra le parti di un progetto. La maggior parte delle volte, queste relazioni sono sviluppate dal flusso di lavoro, che ci porta dal concept al risultato seguendo delle regole. Forse senza saperlo, noi lavoriamo algoritmicamente - definendo un serie di azioni passo dopo passo che segue una logica base di input, elaborazione e output. Programmare ci permette di continuare a lavorare in questo modo ma formalizzando il nostro algoritmo.
     
    Algoritmi in concreto
    Sebbene offra delle potenti opportunità, il termine Algoritmo può portare a dei fraintendimenti. Gli algoritmi possono generare risultati inaspettati, imprevedibili o fantastici, ma non sono magici. Infatti sono abbastanza semplici di per sé. Usiamo un esempio concreto come l'origami di una gru. Iniziamo con un pezzo di carta quadrato (input), seguiamo una serie di ripiegamenti (elaborazione), ed il risultato è una gru (output).
     

     
    Quindi dov'è l'algoritmo? È la serie astratta di azioni, che possiamo rappresentare in due modi - testualmente o graficamente.
     
    Istruzioni testuali:
    Inizia con un pezzo di carta quadrato, con una faccia colorata. Piegalo a metà e aprilo. Poi piegalo a metà, nell'altra direzione. Gira verso l'alto il lato bianco. Piega il foglio a metà, premi bene e apri. Piega ancora nell'altra direzione. Usando le pieghe che hai fatto, porta i tre angoli del modellino in alto sotto, all'angolo in basso. Appiattisci il modellino. Piega i lembi esterni verso il centro e riaprili. Piega la parte superiore del modellino verso il basso, piega bene e riapri. Apri il lembo inferiore del modello, portandolo verso l'alto e premendo i lati del modellino verso l'interno allo stesso tempo. Appiattisci, piegando bene. Capovolgi il modellino e ripeti i passi 4-6 sull'altro lato. Piaga i lembi superiori nel centro. Ripeti sull'altro lato. Piega entrambe le “gambe” del modellimo verso l'alto, piega molto bene, poi riapri. Ribalta verso l'interno e piega le “gambe” lungo le pieghe che hai appena fatto. Ribalta verso l'interno e piega un lato per fare la testa, poi piega verso il basso le ali. Ora hai una gru.  
    Istruzioni grafiche:
     

     
    Programmazione - Definizione
    Usando una qualunque di queste due serie di istruzioni dovresti ottenere una gru, e se hai seguito il procedimento tu stesso, hai applicato un algoritmo. La sola differenza è il metodo con cui leggiamo la formalizzazione di quella serie di istruzioni e questo ci porta al concetto di Programmazione. La programmazione è l'atto di formalizzare il processo di una serie di azioni in un programma eseguibile. Se trasformiamo le istruzioni scritte sopra per creare un origami in un formato che il nostro computer può leggere ed eseguire, stiamo programmando.
    La chiave ed il primo ostacolo che incontreremo nel capire la programmazione è che dovremo affidarci a una qualche forma di astrazione per comunicare efficacemente con il nostro computer. Questa può essere uno qualunque dei numerosi linguaggi di programmazione, come Javascript, Python o C. Se riusciamo a scrivere una serie di istruzioni ripetibili, come per l'origami della gru, ciò che dobbiamo fare è tradurla per il computer. Siamo sulla buona strada per rendere il computer capace di realizzare una gru, o perfino una moltitudine di gru diverse, con leggere differenze tra una e l'altra. Questo è la potenza della programmazione - il computer eseguirà ripetutamente qualsiasi compito, o serie di compiti, gli assegneremo, senza ritardi e senza errori umani.
     
    Programmazione visuale - Definizione
    Se fossi incaricato di scrivere le istruzioni per piegare l'origami della gru, come ti comporteresti? Useresti la grafica, il testo o una combinazione di entrambi?
    Se la tua risposta contiene la grafica, la Programmazione visuale fa senz'altro per te. Il processo è essenzialmente il medesimo sia per la programmazione che per la programmazione visuale. Utilizzano la stessa struttura e formalizzazione; ciò nonostante, definiamo le istruzioni e le relazioni del nostro programma tramite un'interfaccia utente grafica (o "visuale"). Invece di digitare le istruzioni testuali in una sintassi, ci basterà connettere dei nodi preconfezionati tra loro. Ecco un confronto dello stesso algoritmo - "disegna un cerchio sulla base di un punto" - programmato con i nodi e con il codice:
     
    Programma visuale:

     
    Programma testuale:
    myPoint = Point.ByCoordinates(0.0,0.0,0.0); x = 5.6; y = 11.5; attractorPoint = Point.ByCoordinates(x,y,0.0); dist = myPoint.DistanceTo(attractorPoint); myCircle = Circle.ByCenterPointRadius(myPoint,dist);  
    Il risultato dei nostri algoritmi:
     

     
    La caratteristica visiva della programmazione, in questo modo, riduce le barriere per la comprensione dell'algoritmo e spesso è più apprezzata dai progettisti. Dynamo ricade nel paradigma della programmazione visuale ma, come vedremo più avanti, possiamo anche utilizzare la programmazione testuale.
     
     
     
    Vorrei aggiungere infine qualche altra definizione che potrebbe essere utile usando Dynamo e non solo.
    API - Acronimo di Application Programming Interface (in italiano interfaccia di programmazione di un'applicazione), è l'insieme di procedure che un determinato programma mette a disposizione degli sviluppatori. Ad esempio, se un normale utente di Revit per creare una parete deve cliccare sull'icona "Muro" e cliccare ancora per dare un punto di inizio e fine, uno sviluppatore ha a disposizione un comando del tipo: 
    Wall.Create(Curve curve, WallType type) da inserire nel suo codice per creare all'istante una o cento pareti.
    DesignScript - Il linguaggio di programmazione sviluppato da Autodesk, alla base di Dynamo.
    Python - È un linguaggio di programmazione orientato ad oggetti, si può utilizzare in Dynamo per creare nodi personalizzati, creare estensioni per Revit (collegandosi all'API di Revit), data analysis, e molto molto altro. Ha una sintassi semplice rispetto ad altri linguaggi del suo livello. Vi farà risparmiare più tempo di quello impiegato per impararlo.
    Programmazione orientata agli oggetti (OOP) - Prima della programmazione orientata ad oggetti veniva usata la programmazione procedurale, i programmi erano una serie di comandi lineare. L'OOP ha introdotto il concetto di "oggetti", a cui è possibile  assegnare valori, regole, funzioni. Per fare un esempio un muro in Revit è un oggetto, con le sue regole, a cui è possibile assegnare parametri e valori. "Il BIM implica la rappresentazione di un progetto come combinazione di "oggetti" - vaghi e non definiti" (Chuck Eastman - "What is BIM?").
     
    Per qualsiasi altro dubbio o curiosità potete consultare il Dynamo Primer linkato sopra, o scrivere qua sotto.
  4. Like
    falcon76 ha ricevuto reputazione da AlanZirpoli in Arion 2.0 pricing&licensing   
    Restera' per sempre inutilizzabile, lo hanno definitivamente abbandonato dopo aver PER ANNI promesso un aggiornamento. Hanno deliberatamente mentito ai loro clienti. Avevo una licenza piu' dieci nodi (rimasti largamente inutilizzati per problemi vari al programma) e ora mi ritrovo con il dover ricomprare un'altra cosa. Hanno addirittura eliminato il forum, altrimenti li avrei insultati direttamente.
    Tenete anche queste cose in considerazione quando investite in un software. Io dal canto mio sono passato a Octane, anche loro non sono i migliori comunicatori sulla faccia della terra ma la randomcontrol e' la societa' piu' arrogante che ho trovato sulla mia strada.
  5. Like
    falcon76 ha dato la reputazione a Ivan Paduano in Oggetto animato con 3DSM   
    Ti servono le bones, vedi se questo ti è d'aiuto: http://www.gameprog.it/index.php?resource=1227
  6. Like
    falcon76 ha dato la reputazione a Lio in Visualizzazione strisce nere in vista e rendering   
    Ciao,
    non conosco max2011 ma credo che le strane strisce nere che dici te non sono altro che il risultato di un'illuminazione di default che ha almeno due sorgenti luminose: una dal basso e una dall'alto.
    Credo che dipenda da questo. Prova a mettere una luce nella scena e vedi se cambiano le cose
    Ciao
    Lio
  7. Like
    falcon76 ha dato la reputazione a nicoparre in Mi potete spiegare come mai vengono chiusi tutti i miei post?   
    ciao loky, ti rispondo io perchè credo di essere il diretto responsabile

    guarda, non è un accanimento, tante volte guardo solo il titolo e leggo il messagio, non mi soffermo troppo sull'utente che posta...

    il discorso sul primo messaggio è presto detto, "vorrei imparare..." non mi sembra un titolo molto significativo, che cosa? tieni presente che in generale, per agevolare la fruizione del forum, uno dovrebbe essere in grado col primo colpo d'occhio di capire qual'è l'argomento della domanda.

    oltre al titolo però la tua discussione rientra in una casistica abbastanza classica, se fai delle ricerche sul forum vedrai tonellate di discussioni simili di utenti alle prime armi che chiedono cosa bisogna fare e che programma scegliere.

    sono discussioni che non portano mai a niente, perchè di risposte serie non ce ne sono, uno non può dirti passo passo cosa devi fare, esistono videocorsi, tutorial, e ci si sbatte la testa sopra (cmq ti basta fare una ricerca per vedere anche li che l'argomento è già stato trattato e che molti consigli utili li trovi gà belli che pronti... )

    per l'ultima, "come si raccorda" anche li sinceramente mi lascia perplesso... secondo me puoi essre più chiaro con due parole in più no?

    tieni presente che spesso una discussione chiara ottiene anche più risposte, perchè la gente legge e se sa si sofferma, se deve sbattarsi anche a capire cosa chiedi molto spesso nei pochi minuti che ha tira dritto...

    spero di ave4r chiarito ogni possibile equivoco, buona giornata e buone feste..
  8. Like
    falcon76 ha dato la reputazione a mr uptide in Interni navale   
    l'ipad svolazza !!!!!hai enormi problemi di Aliasing, la mappatura dei legni è alquanto sovradimensionata sopratutto i top dei comodini della seconda immagine, credo che il DMC sampler sia davvero ai minimi storici e si vede tutto il noise che hai nei metalli (faretti incassati), il tutto molto IMHO.
  9. Like
    falcon76 ha dato la reputazione a Ganjica in Suming's awakening   
    Ecco, per l'appunto sono pronte le prime immagini tecniche. Setup delle luci. Ho scritto in inglese (probabilmente maccheronico). Spero si capisca comunque!


  10. Like
    falcon76 ha ricevuto reputazione da papafoxtrot in Macchina Per 600 Milioni Di Poligoni / 900.000 Oggetti   
    Secondo me hai semplicemente sbagliato il software da usare.
    Io lavoro in una societa' di engineering e facciamo tutti i giorni model review anche piu' grossi di quelli che descrivi qui, con macchine decisamente inferiori. Ma per la progettazione utilizziamo software specifici (in particolare PDS,PDMS o Smartplant 3D) ognuno collegato a database dedicati (propietari od Oracle). Oppure autocad o microstation per impianti piu' piccoli.
    I model review sono fatti il piu' delle volte con Autodesk Navisworks che permette di ottenere anche animazioni. NON BELLE come i software di rendering per 3DS Max, ma accettabili nell'ambito ingegneristico. Io non mi imbarcherei in un lavoro come quello da te descritto affidandomi sulla stabilita' di 3DS Max quando si parla di gestire tutti questi oggetti. Io mi arrabbio se i software sopra citati crashano una volta ogni mese.... (escludi autocad)

    Ciao

    Luca
  11. Like
    falcon76 ha dato la reputazione a Stalio in Nicrania, The Necromancer   
    Grazie ragazzi

    Falcon76: gli overlap non sono così dall'unwrap, io ho unwrappato tutto separato, poi però ci sono parti che non sono così invisibili da non texturizzarle, però nemmeno così visibili da sprecarci spazio UV, allora alcune cose molto poco visibili condividono la stessa texture di altre, in pratica sono i pannellini di pelle alla cintura, la parte sotto, in pratica non si vede, ma da varie angolazioni, per la piega etc, si può intravedere anche il sotto, allora non può non essere texturizzato, ma anche se condivide la stessa texture, ribaltata, del sopra, non se ne accorge di sicuro nessuno; stessa cosa per il velo di pelle all'elmo, la parte interna, non posso non texturizzarla perchè comunque un po' in ombra ma si intuisce, però anche se gli assegno la stessa texture esterna, non se ne accorge nessuno ; tutto questo per ottimizzare al massimo lo spazio nelle texture

    Papafoxtrot: ni
    nel senso, sicuramente uno non fa l'unwrap se pensa di cambiare completamente la geometria, ma la geometria per esempio può essere ulteriormente suddivisa, e le UV si suddivideranno anche loro, poi puoi fare dei cambiamenti come quelli di cui si parla, lei resta sempre lì, certo, se fai dei cambiamenti molto grossi e radicali, siccome la geometria si muove e la UV resta ferma, c'è il rischio che si creino le stirature e non sia più a posto come quando l'hai fatta, ma non è il caso di cui si sta parlando e alla peggio puoi sempre aggiustarla

    riky70: sì, ha il painting 3D interno, posso dipingere direttamente sul modello
  12. Like
    falcon76 ha dato la reputazione a c0rrad0 in Arion V1.0 È Stato Rilasciato   
    Tutto dipende se gli scambi di informazioni che ci sono tra gpu e cpu sono sincroni, quello che dici tu e' piu' un discorso lineare che non parallelo, un po' come succede con i timing della ram, se hai tutta la ram con timing di 5ms e metti una ram di 10ms tutti devono aspettare quella piu' lenta.
    La scheda grafica non deve aspettare sempre il processore per ogni scambio di dati, il processore video ha il suo tipo di dati e macina quelli, quando trova quelli cui e' stato istruito di non processarli li salta e li passa alla cpu (o viceversa), altrimenti il reparto video in se non avrebbe molto senso e nessun videogioco sarebbe mai esistito. Il collo di bottiglia avviene quando il processore non riesce a terminare i dati necessari alla gpu e di spedirglieli, in un videogioco di macchine ad esempio e' l'intelligenza artificiale, se il processore non spedisce alla scheda video la nuova posizione della macchina in quel frame, la scheda video non sa che calcoli fare, perche' potrebbe essere partita in aria o e' schiantata, dunque gli ritorna impossibile e aspetta istruzioni dal processore. Similmente a quanto hai detto tu pero', i calcoli della intelligenza artificiale sono inferiori a quelli grafici, dunque se il processore ci mette 1ms per calcolare 1 dato di intelligenza artificiale, la scheda video ci mette 1ms per calcolare 100 dati grafici, dunque il rapporto dei 100x potrebbe avere senso in forma di esempio (slegando tutte le differenze tra un tipo di istruzione e l'altra). In questo caso pero' parliamo entrambi del reparto grafico e abbiamo lo stesso peso e misura, ma prima bisogna specificare che puo' risultare strano che il processore ha una funzione utile, in quanto nell'immaginario collettivo scheda video=grafica, purtroppo la scheda video non e' capace a fare grafica a 360gradi altrimenti si sarebbero usati da sempre negli offline rendering, oltre al fatto che esistevano solo lo scripting e non era possibile programmarli, da qui la necessita' del cuda, ecc.

    Cerco di fare una spiegazione per tutti.

    la gpu e' capace a fare una piccolissima parte di operazioni, ma velocemente
    la cpu e' capace di fare tutte le operazioni lentamente, eccetto alcune sequenze di operandi fisse, che si chiamano estensioni mmx, sse1, sse2, ecc. che le fa piu' velocemente.

    Prima del cuda, riuscire a convertire delle istruzioni in una piccolissima parte di operazioni, era difficile e portava via tantissimo tempo via scripting, mentre per altri tipi di istruzioni erano anche impossibile scriptarli.
    Con il cuda e' diventato molto piu' semplice convertire le istruzioni in modo che il processore grafico le capisca, si usa infatti un linguaggio, non piu' uno sistema di scripting, tanto per rendere un'idea, con il maxscript o il mel non puoi creare un programma audio per dj, sei limitato alle azioni che ti offre lo script, invece col c++ puoi farlo. Ma anche se e' piu' facile farsi capire con la scheda video, non significa che diventa capace a fare tutte le operazioni come la cpu rimanendo veloce, anzi si aggiunge cosi' il problema di cosa fare a chi, perche' potresti matematicamente convertire un tipo di dati in un altro capibile dalla gpu, ma una volta convertito potrebbero diventare dei dati lunghissimi da calcolare nonostante l'estrema velocita' della gpu, a questo punto tanto vale farglielo fare direttamente alla cpu, dunque si scambiano i dati e come qualsiasi scambio di consegne c'e' una perdita di tempo. Ecco perche' esistono soluzioni gpu e gpu+cpu, dipende dall'abilita' dei programmatori, nel saper convertire i dati per la gpu oppure riuscire a combinare il meglio dell'uno e dell'altro senza farli scambiare troppe informazioni da rallentarli (calcolo parallelo).

    Dunque analogamente in riferimento all'esempio dell'intelligenza artificiale, ci sono dei dati grafici che se li fa la gpu e' 100x migliore del processore, ma cio' non toglie che ci sono dei tipi di dati che il processore sia piu' veloce della gpu. Non e' vero che uno deve per forza aspettare l'altro, in quanto se il processore ha 1 dato da fare al ms (che la gpu invece ci avrebbe messo di piu' di un ms) e la scheda grafica ha 100 dati da fare al ms (che invece se lasciati fare al processore ci avrebbe messo di piu' di un ms), a fine ms sono in parita' e nessuno dei due rallenta l'altro, anzi sono perfettamente paralleli. Ovviamente nella realta' non e' cosi' perfetto, come dicevo all'inizio il rallentamento dipende da questo fattore, quello di scambiarsi le informazioni senza essere asincroni e dunque aspettare l'altro, ma un ottimo guadagno di prestazioni ci puo' essere se programmato bene. Tutto dipende da come si specializzano i programmatori e dalla loro intelligenza, piu' e' ottimizzato il programma e sara' migliore di un altro sia esso solo gpu o cpu+gpu, ma questo punto mi pare lapalissiano per tutti.

    In supporto alla mia teoria ti indico il programma seti@home che differenzia i tipi di dati da processare tra cpux86, cell e gpu.

    Per tutto il resto che hai detto nei post seguenti sono d'accordo con te.
×