Vittorio scusa ma non capisco.
Ritieni quindi che la McNeel non sia in grado di creare nuove librerie per risolvere il problema?
Scrivi che c’è stato un primo tentativo di fare fuori Rhino, ce ne sono stati altri allora?
Fabio.
Tornando al Topic, uno snap lunghezza pur sempre utile con linee, già un po meno con un arco, a mio avviso, non è molto utile / indispensabile con le nurbs …
Rispondo perchè siamo rientrati nel tema (spero di non parlare di fillet, bloccatemi prima, in tal caso 
).
Una opzione subcurva serve eccome, secondo me. Consideriamo una situazione del genere, voglio stabilire la lunghezza non dell’intera curva, ma da punto A a quello B, oppure dal punto A a quello C, cosa dovrei fare? spezzettare la curva e poi unirla (e se i punti sono molti?). Poco pratico!
Inoltre, ammettiamo volessi stabilire sulla curva data una lunghezza, per esempio di 12cm, da un punto A, e sottolineare tale lunghezza con un punto, come fare? poi voglio, da quel punto, continuare, e fissare una lunghezza di 27 cm, e così via, come fare? moltiplichiamo tutto per decine di punti e di lunghezze diverse… (magari esiste un modo che io non conosco, fatemi sapere). Dimenticavo, script a parte.
Per me questa opzione dovrebbe essere aggiunta nel comando Divide.
Già per le curve chiuse ti chiede di impostare il seam da cui partire a fare la divisione; se lo chiedesse anche per le curve aperte e, inoltre, di impostare il numero di segmenti di data lunghezza da ottenere, allora avresti quello che ti serve (sempre tenendo conto dell’opzione già esistente di marcatura del punto senza split del segmento).
Oppure la inserirei come OSNAP “Distance from point on curve” che ti chiede di impostare (durante un comando tipo copia o disegna) il punto di partenza da cui vuoi calcolare una distanza su una curva:
- Sto eseguendo un comando per cui devo selezionare un punto
- Seleziono “Distance from point on curve” sugli Osnap
- Mi viene chiesta la curva
- Mi viene chiesto il punto
- Mi viene chiesto di cliccare sulla curva il punto finale (con visualizzazione interattiva della distanza) oppure di impostare la distanza voluta.
Il comando Length, pensato solo per riportare un’informazione di un oggetto e non per modficare/ottenere geometrie, non è adatto, a mio avviso, per un’opzione del genere (sarebbe come se si volesse utilizzare il comando quota per ottenere un’intersezione ad una data distanza…).
Non posso che essere d’accordo. Io l’ho pensata per il comando “lenght”, ma credo sia meglio come dici tu. Speriamo non rimangano parole al vento!
A mio avviso, certi potenziamenti che si possono attuare sui comandi, per così dire, di tipo 2D, sono da ritenersi fondamentali tanto quanto talune migliorie effettuate ai comandi per generare forme tridimensionali. La costruzione di un buon 3D spesso passa attraverso gli strumenti ausiliari di disegno 2D.
Sarebbe sbagliato pensare che tali strumenti debbano diventare a forza, quasi in senso dispregiativo, “copie” di comandi alla AutoCAD, quasi come se Rhino dovesse diventare un clone, assumendo le forme di quest’ultimo.
Semmai, noto un avvicinamento di AutoCAD verso certe logiche morfo-costruttive tipiche di Rhinoceros: da strumento completo per lo sviluppo del 2D, si è passati, soprattutto negli ultimi anni, ad un generatore di modelli 3D. In questo AutoCAD è stato capace di evolversi e reinventarsi, sopravvivendo bene nel tempo tra centinaia di CAD, ormai tutti equiparabili.
Rhino, dal canto suo, conserva la sua originaria vocazione, il che non delude mai, però trascurando, secondo me, un comparto 2D, variegato sì, ma che dà l’idea di essere abbozzato e, quindi, poco rifinito e per nulla completo.
Siete d’accordo?
Non sono d’accordo…
A parte il fatto che, in tutti questi anni, non mi sono mai trovato in difficoltà per fare un qualche tipo di 2d (forse il mio lavoro è troppo semplice rispetto agli utenti autocad), credo che la filosofia di Rhino si discosti da quella dei cad con “tutto pronto ma blindato”.
Da sempre la McNeel ha reso il formato .3dm aperto (possiamo definirlo open source?) e fornito Rhino di una piattaforma per gli sviluppatori esterni (a tutti i livelli, non solo per pochi eletti).
Gli utenti, poi, sono sempre stati spronati ad utilizzare macro, script, GH e plug-ins varie per adattare il programma al loro lavoro.
Quindi, di fronte ad un comando assente ma facilmente ottenibile tramite script, non mi sento di dare la colpa a McNeel…
Io ho gli strumenti per fare quella cosa… se poi non la voglio fare oppure non voglio utilizzare l’aiuto di un’altro utente perchè mi sembra una pezza invece di un comando vero e proprio, allora il problema è mio.
Utilizzo normalmente script e macro fatti tanti anni fa e se ti devo dire la verità… li calcolo come fossero comandi interni di Rhino (anche perchè la velocità di esecuzione è pari a quella di un comando standard).
Per fare alcuni esempi di comandi che mi servivano e che ho ottenuto tramite script:
- calcolo dei tempi di taglio dei pezzi
- offset automatico (interno/esterno/entrambi i lati) dei profili chiusi (con selezione multipla)
- raggruppamento automatico di profili racchiusi all’interno di altri
- calcolo del minimum bounding box
- riconoscimento di cerchi uguali (con tolleranza per il riconoscimento) e sostituzione con cerchi di diametro diverso
- creazione di superfici circolari piane
- batch import di file dwg e dxf multipli con raggruppamento ed associazione nome file agli oggetti importati
- estensione automatica di curve multiple (inizio o fine) di un valore dato
…
Senza contare di quanti pulsanti mi sono personalizzato in modo che il comando abbia le opzioni che mi servono già attive.
Ovviamente, al passaggio da una versione ad un’altra, dovrò rivedere vari script o comandi per aggiornarli alle ultime opzioni; ma questo è anche necessario per far si che non rimanga fossilizzato al vecchio sistema (cosa che siamo costretti a fare anche con i sistemi operativi).
Quindi, per concludere, io vedo le limitazioni nel momento in cui non esiste una strada (efficiente) per ottenere il risultato.
Sicuramente il problema è mio, provengo da altri cad (Archicad fra tutti) e sono poco avvezzo all’uso di script, macro e quant’altro, diciamo che preferisco la pappetta pronta!
Ho sempre precisato che non tutto può essere introdotto in Rhino, ogni piccola richiesta e desiderio dell’utente, altrimenti il programma diventerebbe piuttosto pesante, oltre che, ridondante.
Forse mi riferisco a certi miglioramenti che in alcuni comandi 2D, un pochino scarni di opzioni, potrebbero giovare un po’ a molti (non solo agli architetti, da sempre alle prese con piante, prospetti, misurazioni varie, ecc.). In fondo, basterebbe poco, ampliare quello che di buono c’è (a onor del vero, ci sono molte cose che funzionano bene e le trovo nella loro semplicità, geniali, anche solo dover fare un poligono o un cerchio attorno ad una curva: con altri CAD è più laborioso da fare, con Rhino si fa subito)…
Tu per il tuo lavoro sei riuscito ad adattare Rhino alle tue esigenze, attraverso l’uso di script, macro, formule, ecc.(ben vengano), ad integrazione e completamento di ciò che, purtroppo, non è presente per vari motivi; c’è chi vorrebbe usare Rhino per fare altro, tipo automotive, per esempio, in tal caso, come fare a colmare certe carenze? Domando soltanto…
Ciao Lucio e Davide !
Forse sarebbe bello (diciamo curioso) aprire una discussione in cui elencare, come ha fatto Lucio, alcuni dei nostri script. Potrebbe venir fuori qualche buona idea ( procedure utili a cui non avevamo pensato ecc. )
… O forse no … mah …
“Suggerimento per i McNeel:
Credo sia sbagliato pensare che se una cosa può essere scriptata allora sia inutile integrarla. Credo che, anzi, proprio perché facilmente scriptabile vada integrata subito. 3dmax è cresciuto così. (si beh, l’esempio non è dei migliori)”.
Cit. Riccardo Gatti, ottobre 2014
Diciamo che, in soldoni, era quello che cercavo di spiegare io.
Ecco, vedi, anche GatMan ogni tanto spara caxxate… ma non lo flagelliamo mica… gli vogliamo bene lo stesso! 
David scusa, ma non ho saputo resistere… 
Ciao!