Grazie mille @leopoldomonzani, sei davvero geniale! Spero di diventare abile quanto te con GH un giorno!
Sai se è possibile realizzare il riempimento “seguendo” la superficie?
Ad esempio in questo caso (in foto) li realizza tutti su piani orizzontali, mentre se li realizzo su un piano e poi faccio il flow “seguono” la curvatura della superficie.
Inoltre mi sarebbe utile poter realizzare questa cosa anche con l’altro script “riempimento con hatch” che utilizzava direttamente la definizione di hatch, ma in quel caso realizza il riempimento “proiettandolo” sul piano xy (a differenza del tuo ultimo file “riempimento q.gh” che, non utilizzando la definizione di hatch, lo realizza correttamente).
Te li lascio entrambi in allegato nel caso riuscissi a dargli un’occhiata!
riempimento con hatch.gh (15,8 KB)
riempimento q.gh (45,1 KB)
Esempio.3dm (1,7 MB)
Non credo sia possibile eseguire riempimento direttamente seguendo la superficie.
Anche con la definizione che usa Hatch si possono utilizzare _Flow o _FlowAlongSrf.
È necessario esplodere il riempimento dopo averlo esportato in Rhino.
Però in questo modo si verifica una deformazione quindi sarebbe opportuno portare in “piano” i solidi, eseguire il riempimento/contour e riportarlo sulla superficie curva con i soliti _Flow / _FlowAlongSrf,
Sempre che sia possibile rendere piane le superfici di partenza senza tanti problemi.
prova.gh (298,7 KB)
Non è quasi mai necessario però può capitare che si debba aumentare la tolleranza: ecco un esempio.
Ciao @leopoldomonzani, stavo dando un’occhiata allo script gh che utilizzammo in questi esempi.
Mi chiedevo se esistesse un’alternativa al blocco “Boundary Surfaces” in quanto, nel caso di geometrie complesse, richiede tempi computazionali molto elevati.
In particolare, partendo da delle curve (ossia sezioni _contours) già ordinate, vorrei realizzarne il riempimento senza doverle riordinare nuovamente per ridurre i tempi computazionali.
Ho provato a semplificare/riassumere il tutto così, ma il blocco “boundary surfaces” rallenta tutto, fa da collo di bottiglia a tutto il processo:
Hai qualche idea/suggerimento?
… non sono Leopoldo 
, ma sono curioso.
Prova a disabilitare il parallel computing, in certi casi migliora (attento che se invece stava già migliorando i tempi, disattivandolo potrebbe metterci moltissimo tempo, fai una prova con qualcosa di semplice)
In alternativa, potresti caricare una casistica dove è lento?
Invece di usare Boundary Surface, si possono raggruppare le curve in base alla Z.
Però il problema del raggruppamento era uscito perché in principio c’era questa situazione, ovvero erano diversi solidi.
Sei il solido è unico non c’è nessun bisogno di raggruppare.
Ciao Riccardo,
sto provando disabilitando il parallel computing, ma per ora non sembra migliorare le cose.
EDIT: Confermo, disabilitando il parallel computing le cose peggiorano.
Ti lascio un esempio (in rhino 7 ed 8) di disegno “complesso” che richiede tempi di elaborazione biblici e un alto quantitativo di ram.
L’unico modo che ho trovato per elaborarlo è suddividere il lavoro a soli 2 layers per volta e anche in questo caso richiede molto tempo ad elaborare il tutto.
Ciao Leopoldo,
il problema nasce nella rotazione dell’hatch tra un layer e il successivo, non riesco a trovare un modo di farlo correttamente se non attraverso il boundary surfaces… Infatti mi inserisce più hatch in ogni layer
Inoltre, a differenza di quanto visto mesi fa, stavo valutando di effettuare il _contour e ordinamento delle sezioni a parte e poi dare solo le curve ordinate allo script di gh, in modo da alleggerire il carico computazionale
Per la rotazione.
Per il resto non so a quale definizione ti riferisci.
Ho provato la tua definizione di rotazione, ma ottengo sempre più hatch ruotati su ciascuna fetta:
La definizione di partenza (funzionante ma estremamente lenta) era la seguente:
Definizione rotazione.
Le curve devono essere raggruppate per piano.(linea tratteggiata)
La definizione penso debba essere modificata così.
Perdonami, ho sbagliato a fotografare il codice, quello di partenza (funzionante con la rotazione ma con tempi di elaborazione lunghissimi a causa del blocco Boundary Surfaces) è questo:
Test.gh (7,0 KB)
Lo scopo è quello di “sostituire” il blocco boundary surfaces con qualcosa che computazionalmente risulti essere più leggero e non consumi decine di gb di ram nel caso di geometrie un po’ più complesse…
Per questo motivo non voglio più realizzare il contour e ordinamento delle sezioni nello stesso script ma farlo in 2 fasi distinte:
- prima creo e ordino le sezioni nel primo script (che già posseggo)
- poi invio le curve del primo script al secondo script che ne crea i riempimenti con rotazione
Nella definizione postata dovresti internalizzare le curve perché altrimenti non so come sono messe.
Come già ho detto nel post 66 se il solido utilizzato con Contour è unico si salta il blocco BoundarySurface.
Non credo sposti molto il tempo di elaborazione, comunque è possibile importare/esportare dati con Data Output/Input.
Ho internalizzato le curve:
Test.gh (12,2 KB)
Nel dubbio ti lascio anche il file rhino:
Test.3dm (67,7 KB)
Nell’esempio di un cilindro cavo, le curve sono generate da un unico solido. Per cui potrei saltare la definizione di boundary surfaces, tuttavia non riesco ad ottenere correttamente la rotazione degli hatch tra un layer e il successivo.
Vorrei questo:
Ma ottengo cose del genere, con più hatch su ogni layer
Non ho mai lavorato con le campiture da grasshopper…
A te servono superfici, o curve?
Nel caso di curve, devono essere ordinate in qualche modo? (tipo la prima il perimetro esterno e poi tutti i fori… ad esempio… ?)
Ecco, così.
Test a.gh (14,0 KB)
A me servono entità curve.
Le curve perimetrali le ordino in un certo modo (ad es dal basso verso l’alto) con uno script, poi con questo secondo script per ciascun valore di z voglio realizzare un riempimento con un angolo differente:
ad es z=0 → hatch a 0°
z=0.5 → hatch a 30°
z=1 → hatch a 60°
z=1.5 → hatch a 90°
ecc…
Condivido anche con te lo script di partenza funzionante da cui voglio sostituire il boundary surfaces:
Test a.gh (14,0 KB)
Test.3dm (67,7 KB)
Ok, così fa esattamente quello che voglio, ma nel caso di geometrie complesse il blocco boundary surfaces richiede ore e ore di elaborazione e decine di gb di ram.
Ti lascio in allegato un file “complesso” di esempio per capire quanto blocchi letteralmente tutto:
Per questo motivo volevo sostituirlo con qualcos’altro… è il collo di bottiglia di tutta l’elaborazione
Questo è da usare assieme al file “Test R7.3dm” di wetransfer.
Test R7.gh (450,4 KB)
È il codice che avete fatto Leopoldo e te, un po modificato…
Da me esegue tutto in 50 secondi.
Ok, ho una buona CPU, ma dall’utilizzo sul task manager vedo che nemmeno stava lavorando multithread. Quindi anche con una CPU di dieci anni fa secondo me in un paio di minuti finisce…
Non è che stavi avendo errori di datatree, e si stavano creando millemila duplicati??
1 Mi Piace
Ciao Riccardo, sembra fare esattamente quello che volevo, grazie mille!
Lo testerò nei prossimi giorni con calma!
Onestamente non saprei, tuttavia il risultato finale dopo la lunga elaborazione era corretto.
