Ciao Giulio, complimenti sempre per il tuo lavoro. Ciò che ho implementato è conseguenza anche del tuo lavoro, quindi grazie.
Ma… vengo alla domanda. Se le mesh sono più complesse da gestire (e capisco quanto dici), mi aiuti a capire perché per fare operazioni booleane tra brep GH prima converte queste in mesh?
Ultimamente mi sono accorto che spesso apro topic perché penso di avere un problema “stupido” e poi intervenite voi, uno più bravo dell’altro che non solo mi aiutano a risolvere il problema, ma mi permettono di imparare altre centomila cose😎
2 Mi Piace
Ebbene, non vorrei far passare il messaggio che solo le maglie/mesh sono difficili. Però hanno davvero molte combinazioni. Questo può facilmente influire sulla robustezza dei vari comandi simili a dividi/taglia.
A guardare il codice, non sembra succeda questo. Che cosa te lo fa pensare?
Tempo fa ho provato ad animare con GH un albero motore con tanto di manovellismi di spinta e una persona mi disse: “va lento perché GH fa il continuamente il remesh delle brep. Trasformale in mesh e andrà più veloce”. Ed effettivamente è stato così, il movimento era fluido con le mesh.
Inoltre ho sentito che le operazioni booleane sono molto onerose in termini ci calcolo, e ho associato questo costo alla conversione. Mi chiedo allora: cosa rende le booleane tra nurbs così onerose in termini di tempo/computazionali?
Non saprei commentare senza un esempio in mano. E forse neanche con quello. Posso dire che ci sono funzioni per quasi tutti i tipi di geometria, con quasi tutti gli altri. Quindi ogni cosa si dirama in diverse direzioni, seguendo un percorso per ogni coppia di tipo geometrico. Riscrivere un pezzo di queste “strade” non ne riscrive automaticamente un altro.
1 Mi Piace
pare sia un dato di fatto e riscontrato che le booleane in GH creano problemi e rallentamenti notevoli, quindi il perché dovrebbe essere noto a chi conosce il codice. Tu riesci a dirci qualcosa in merito?
Per le booleane il mio codice impiega anche 30 minuti per generare il disegno e in particolare il quadremesh.
per carità, il risultato è interessante e 30 minuti (e anche meno spesso) a fare quello che chiunque (tra gli aeromodellisti) impiega da 1 a 6 mesi… è nulla.
PS domanda sciocca, ma la faccio comunque: il codice dei componenti nativi GH non si può vedere (senza trucchetti/decompilatori…) vero?
Non credo che alla McNeel come qualunque altra software house metta a disposizione il codice nativo del suo software.
si si la risposta era quasi scontata, ma pensavo a GH come ad un altro ambiente, ma si certo alla fine siamo li.
A quanto ne so GH per la geometria usa RhinoCommon.
… Che a sua volta usa OpenNurbs e altro software non open source di RMA 
1 Mi Piace
Ciao Luca, ti ha risposto Emilo: rhinocommon.
In generale, per aumentare in modo rilevante la velocità di calcolo devi analizzare bene il codice e togliere i calcoli “inutili” e/o duplicati.
Se per esempio, come nel tuo caso, hai una figura simmetrica, ripetere lo stesso calcolo per le due parti il tempo di calcolo raddoppia. Elementi estrusi vengono generati più velocemente rispetto ad elenti ottenuti tramite booleane.
In generale il codice più veloce è quello che riesce a sfruttare al meglio il multithread. Se non sfrutti in contemporanea tutti i core della CPU ogni ottimizzazione avrà limitata rilevanza.
Non posso sostituire una booleana con una estrusione, nel senso che se uso l’una piuttosto che l’altra c’è un motivo.
Sarebbe bello vedere il codice con qualcuno esperto per migliorarlo, ma non so quanto si possa spremere ancora.
È ancora un mondo sconosciuto.
Prima che te lo dica Giuseppe, te lo anticipo io … 
Il codice e’ stato scritto gia’ in origine da qualcuno MOLTO esperto.
Intendo le routine che cercano le intersezioni, costruiscono le Brep ecc.
( E suppongo che quel codice li’ si chiami ‘Kernel Trout Lake’ … )
RhinoCommon si limita a richiamare quelle routine, e noi, a nostra volta, possiamo richiamare le routine di RhinoCommon. Qui sta il margine di ottimizzazione a mio parere.
Semplice consiglio da scriptomane :
se vuoi ottimizzare, cerca di usare operazioni semplici.
E’ quello che ti ha gia’ detto Sergio parlando di estrusioni, il concetto e’ sempre quello.
A te serve una booleana, ma forse un tipo particolare di booleana.
Rhino/GH calcola la booleana in modo che funzioni in ogni caso, quindi in un certo senso il calcolo e’ piuttosto complesso.
Forse nel tuo caso non serve tutta questa flessibilita’.
Forse la tua booleana si puo’ calcolare piu’ velocemente, cercando una via diversa.
O forse puoi dare alla booleana superfici piu’ semplici su cui lavorare.
Non so, ovviamente, parlo in generale, non conoscendo il problema specifico.
Per me la via migliore per ottimizzare e’ cercare il modo di utilizzare calcoli piu’ semplici e quindi piu’ veloci.
Come sempre la cosa principale da ottimizzare e’ l’algoritmo …
Quanto a RhinoCommon, se (quando hai tempo) vuoi provare a vedere qualche piccolo esempio,
posta il problemino (per meglio dire un semplice esercizio) e proviamo a mettere insieme le istruzioni.
Anch’io ho problemi di tempo (e soprattutto energie), in pratica riesco a fare qualcosa solo nel weekend, e poi sono arrugginito col C#, dato che per gli script di Rhino non posso usarlo.
Ma forse nel frattempo ti rispondera’ qualcun’altro … speriamo. 
1 Mi Piace
Penso di esserci, su questo punto. Il problema dei tempi per le booleane lo leggevo sul forum inglese.
Quindi non credo sia solo una questione di errata ottimizzazione del codice.
Ecco forse invece quello che dovrei fare (avevo postato in merito) è vedere di spezzare in più file, ma mi viene difficile per motivi che non sto qui a spiegare, dovrei mostrarvi il codice.
Ciao Luca
se nel generare il modello gh aggiunge e modifica le entità nel database di rhino ad ogni istruzione i tempi aumentano in modo esponenziale.
In c++ o in net le entità risiedono in memoria ed una volta completato le aggiungi come entità. Nel mentre puoi farle visualizzare ma non sono entità con cui puoi interagire (per quello ci devi pensare tu o in alternativa le devi aggiungere).
Ciao Sergio.
Non so come funziona la definizione di Luca,
pero’ per portare gli oggetti da GH a Rhino di solito ci vuole un Bake.
Finche’ non usi il Bake, GH lavora indipendentemente dal database di Rhino.
… Il quale, tra l’altro, non mi sembra neanche cosi’ lento a patto di non aggiornare le viste, ma e’ solo un’impressione, OK. Bisognerebbe fare delle prove …
Piuttosto non so quanto si guadagnerebbe a usare dei componenti script al posto di sequenze di componenti classici in GH.
Certo dipende da cosa ci fai, ma forse sarebbe piu’ semplice cercare di ottimizzare i calcoli … mah. 
sicuramente già l’avrai fatto, cioè di attivare i widget per individuare le operazioni che richiedono più tempo?
Ciao Emilio
come ho detto non conosco gh. L’unica è provare come dici tu.
1 Mi Piace
Signori, se vi va possiamo organizzare un incontro online e vi mostro lo script gh in modo da poterne parlare meglio. Lo mettiamo alla prova, facciamo i test che desiderate (così ve la presento) e vediamo come si può ottimizzare. Potrebbe essere una occasione di scambio e conoscenza che dimostra come internet e un sano forum possa creare relazioni e socialità concreta. Magari un giorno ci incontreremo anche, con qualcuno di voi. Gli interessati mettano un cuore e vi giro un link la prossima settimana.