Ciao a tutti, è la prima volta che mi accade questo problema:
volendo sezionare dall’alto verso il basso la polisuperficie che lascio in allegato mediante il comando _contour , il processo parte correttamente nel primo tratto superiore della sfera, ma poi si blocca totalmente una volta arrivato in corrispondenza delle lettere.
La stessa problematica mi si è verificata in disegni analoghi.
Qualcuno sa perché questo si verifica e come si può risolvere?
P.S. Non sono particolarmente interessato alla conversione in mesh e poi _contour. Ho visto che così si risolve, ma in alcuni casi mi da origine a strane autointersezioni che mi causano problemi nelle fasi successive di riempimento.
questa era una versione “semplice” fatta al volo per mostrare la problematica… Nel caso specifico non sono scritte “test” ma più complesse e da venerdì a lunedì ancora non aveva terminato!
P.S. Lo hai fatto a 0.005mm? Perchè a me ci mette davvero tanto tempo!
Vorrei capire se esistesse qualcosa per semplificare/alleggerire il processo…
Ciao Marco.
Con la distanza impostata penso sia normale mettere in conto un tot di tempo di calcolo.
Se poi le geometrie sono più complesse la cosa non può che peggiorare.
Ok per la distanza contour di 5 micron … ma posso chiederti come mai lavori con questa tolleranza?
le tolleranze basse sono perchè lavoro spesso con stl e con tolleranze alte il processo di contour genera delle autointersezioni che poi non mi fanno generare correttamente i riempimenti in ogni strato…
Probabilmente in assenza di stl posso provare ad aumentarle per alleggerire un po’ il processo
Premesso che non mi metterei mai a lavorare con quelle tolleranze e con sezioni a 5 micron su oggetti così grandi, per velocizzare alcuni comandi (come ha giustamente già fatto notare il buon Leopoldo facendo la prova in GH) si può disabilitare il redraw della scena (praticamente si toglie il preview del comando che si sta completando che in questo caso sarebbero le varie sezioni che si generano).
Il comando per disabilitare il redraw è _SetRedrawOff e per riabilitarlo è _SetRedrawOn
Quando il redraw è disabilitato non vedrai più nulla di aggiornato nelle tue viste (si procede alla cieca) ma Rhino continua a ricevere gli imput (quindi potrai selezionare l’oggetto, lanciare il SetRedrawOff, lanciare il comando Contour, cliccare nella vista per settare l’asse del contour, impostare la distanza delle sezioni e, una volta completato il comando, riabilitare il redraw con il comando _SetRedrawOn).
Inutile dire che un pulsante con una macro o uno script/definizione GH potrebbero velocizzare la procedura e renderla anche più semplice.
In presenza di un numero di sezioni molto fitte, poi, converrebbe fare le operazioni a step perchè, come per tutte le operazioni di un computer, se un processo impiega molto tempo ad essere completato può diventare indigesto al sistema operativo e venir interpretato come un’errore del programma (con conseguente allungamento dei tempi).
Non sapendo da quale altezza partiva il tuo Contour, ho pensato che forse partiva da Z=5.
In questo modo una sezione finisce esattamente sul bordo superiore delle lettere.
Da quanto ricordo, questa di solito non e’ una situazione che Rhino ama …
Per evitarla ho provato a partire da Z=5.0025 (con Rhino 6).
In questo modo il Contour e’ partito e continuava a scendere anche oltre il bordo delle lettere …
Poi ho interrotto perche’ qui il PC e’ molto lento. Avra’ lavorato per un’ora o poco piu’.
A occhio aveva gia’ sezionato un terzo abbondante delle lettere. (allego immagine)
Presumo (ma ovviamente non lo so) che in circa 3 ore finirebbe il lavoro, ma qui ho un Core 2 Duo …
Ma ovviamente non so se a te servono delle sezioni che partano da una quota precisa …
Altra considerazione: non so se questo valga anche per i file che devi effettivamente sezionare, ma in quello che hai postato le pareti delle lettere sono verticali, quindi Contour fara’ delle sezioni uguali.
Non so come devi utilizzare le sezioni, ma forse si potrebbe farne una sola e poi copiarla.
Eseguendo il Contour solo per la sfera.
Altra prova:
Ho scorporato la superficie inferiore, in pratica invece di una unica polisurf, ora ce ne sono una cinquantina.
In questo modo qui completa le sezioni (da Z=5.0025) in circa 6 minuti.
Capita che alcuni comandi preferiscano lavorare su diverse (poli)superfici piuttosto che su una unica.
Pensandoci, direi che ha senso.
Rhino non cerca piu’ di unire le varie curve della sezione in un’unica curva.
Forse quello che porta via tempo non e’ la sezione ma il Join delle curve … chissa’.
Ciao Emilio, si in questo esempio si potrebbe procedere anche con una copia, ma si tratta solo di un esempio per capire la problematica, cercavo qualcosa di “generico”.
Si questa cosa la avevo notata anche io, tuttavia mi chiedo perchè accada questa cosa nonostante nelle opzioni del _contour abbia disabilitato il join delle curve, chissà…
Credo che il sistema migliore sia di lavorare con script o grasshopper: si decide quante sezioni si vogliono fare alla volta (tipo 100 sezioni per step) e si fa ripetere il comando fino al raggiungimento dell’altezza prestabilita.
Ovviamente, più è grande l’area che il nostro piano andrà a sezionare e più sarà lungo il calcolo.
Un’altra strada potrebbe essere quella di fare il contour di ogni singola superficie; in questo modo il calcolo non deve tenere conto di una polisuperficie complessa (inoltre si potrebbe valutare superficie per superficie l’effettivo ingombro in Z e calibrare il contour per fare il calcolo solo dove ci sono effettive intersezioni).
Ci sono varie strade che si possono percorrere ma il concetto rimane sempre quello di dividere tutto in operazioni semplici in modo da non chiedere a Rhino di fare “ragionamenti” non voluti.
Altro vantaggio è che tra una operazione e l’altra è possibile fare dei controlli sull’avanzamento del comando oppure avere la possibilità di interrompere il calcolo senza dover aspettare ore perchè il sistema non risponde…
Vero.
Da una rapida prova, e’ molto piu’ lento con la polisurf unica e Join=None rispetto a molte polisurf con Join attivo.
Forse l’algoritmo di Contour non si adatta bene al primo caso … mah.
