WISH: piccola aggiunta al comando "lunghezza"

Non so se potrebbe avere senso, una semplice opzione da aggiungere al comando “Length”.

Voglio conoscere non l’intera lunghezza di una curva (o linea), ma un tratto di curva, per esempio, mi serve stabilire una lunghezza (x) dal punto A, e sottolineare tale lunghezza con un punto.
Magari si potrebbe aggiungere al comando una opzione “subcurva” con punto persistente, per conoscere la lunghezza di un tratto di curva, senza dover preventivamente spezzettare la linea.
Magari non serve a nulla, non so…

Per esempio, dal punto A mi serve fissare una lunghezza di 4 cm sulla curva (da un lato o dall’altro del punto), quindi, sottolineare questa lunghezza con un punto. Attualmente, il comando “length” mi permette solo di conoscere l’intera lunghezza di una curva… che ne dite?

Forse questa opzione non servirebbe in questo comando, ma in un altro, non so che dire…

Se usi dividebylength puoi impostere una distanza e a ogni multiplo di essa viene posizionato un punto

simile, ma io cercavo altro. Intanto non posso conoscere la lunghezza di un tratto di curva (a meno di non suddividerla).
Pertanto se volessi partire da un punto interno alla curva?

Ammettiamo volessi conoscere la lunghezza tra il punto A e il punto B. Devo suddividere la curva in tre parti, usare il comando e poi unire il tutto. E se fossero molti punti? un macello!
Inoltre, se dal punto A volessi stabilire una lunghezza X, per esempio, 12,5cm, e fissarne il punto sulla curva?

Io credo che il comando length abbia bisogno di una bella rispolverata (piccole opzioni, niente di che…).

Basta questo semplice script

import rhinoscriptsyntax as rs

def sc():
    rs.Command("_SubCrv _Copy=_Yes _pause _pause _pause ")
    sub_curve=rs.LastCreatedObjects()
    lun=round(rs.CurveLength(sub_curve),2)
    rs.AddPoint(rs.CurveStartPoint(sub_curve))    
    rs.AddPoint(rs.CurveEndPoint(sub_curve))
    rs.AddText(str(lun),rs.CurveMidPoint(sub_curve),3)
    rs.DeleteObject(sub_curve)
sc()

Vittorio

Si’, ma andrebbe esteso a tutti i comandi che usano curve come input.
Ogni volta che selezioni una curva per un comando sarebbe utile poter passare al comando solo la sub-curva voluta.

Grazie Vittorio.
Mi piacerebbe che alcune nostre osservazioni, se ritenute dai più, utili e interessanti, diventassero richieste vere e proprie, e non “parole al vento”, altrimenti sarebbe solo una perdita di tempo.

Emilio, intanto sarebbe già qualcosa che questa opzione venisse aggiunta al comando di gestione della “lunghezza”, poi, come dici tu, potrebbe interessare altri comandi.
Io ho fatto la richiesta nel sito INT, ma non credo verrà presa in considerazione, almeno per ora.

Grazie Vittorio …

Ecco un altro ( _SubCrv ) dei 65.535 comandi di cui non conoscevo l’ esistenza :slight_smile:

Eeeeh … ognuno chiede quello che gli serve … a me servirebbe su altri comandi. :smile:

Premessa: Rhino non può soddisfare ogni singola richiesta, e non può contemplare al suo interno ogni piccola opzione o caratteristica voluta, ci ritroveremmo con milioni di opzioni e sotto-comandi.
Osservazione: il fatto che in Rhino ci sia la possibilità di inserire degli script, da un lato aggiunge potenzialità, è vero, ma dall’altro non “castra” un certo modo di concepire il software?
Mi si dice spesso: “Tanto ci sono gli script… oppure, ti fai uno script facile facile…” e quella caratteristica che tu cercavi viene in un certo senso, messo un po’ da parte. E chi di script non se ne intende?

Ricordo che qualche anno fa chiesi ad uno degli sviluppatori un paio di opzioni utili da aggiungere al comando “Array”, alla stregua di Alias Surface: sì, interessanti, utili, ma alla fine nulla da fare, mi dissero che ci sono due bei script pronti all’uso e quindi pazienza, discorso finito là (i mille script di Pascal, una marea, tutti utili, alcuni un po’ meno).
Per esempio, tra i tanti, avrei voluto vedere nativamente l’editing di una curva su superficie; anche per questo niente da fare: c’è lo script…
Ecco perchè poi Rhino dà l’idea di essere un software “incompiuto”: non si riesce a tramutare una opzione utile, una caratteristica importante in un comando nativo, visibile con la sua bella icona colorata, a cui l’utilizzatore medio è abituato, clicchi e via… (in pochi casi sì, in tanti altri no).
Mi domando come possa un utente ricordare che esiste uno script all’uopo, uno per compiere una operazione, uno per un’altra cosa, e via dicendo! Certamente, non tutto può essere contenuto in Rhino (difatti l’ho premesso), ma alcuni aspetti conseguenziali di un comando, tipo, conoscere la lunghezza di un tratto di curva e non solo dell’intera curva, credo sia un’opzione che scaturisca meccanicamente, appunto, come conseguenza, direi, una inezia da implementare. Questo vuole essere solo un esempio…

Non vorrei essere frainteso, la logica del mio ragionamento non è quella di dover accontentare tutto e tutti, sarebbe da pazzi; piuttosto, è quella di fornire al comando una serie di opzioni utili, quasi imprescindibili, e comunque, conseguenziali.

Faccio un esempio: se esiste il comando per poter eseguire una curva su superficie, ci dovrebbe essere la possibilità, nativa, senza scomodare macro, script e quant’altro, per compiere agevolmente l’editing di quella curva; credo sia più che logico, o no? Sarebbe come se in Rhino ci fosse soltanto il comando per fare il quadrato e se si volesse fare il pentagono, l’esagono, l’ettagono, ecc. ci si dovrebbe affidare ad uno script fatto apposta. Vai poi a ricordartelo! o a dirlo ad uno che di queste cose non ne mastica!

Davide, guarda che e’ normale lanciare un wish senza che questo appaia nella prossima WIP …
Il caso eccezionale e’ quando il wish viene preso subito in considerazione.

Se vuoi e’ anche un fatto statistico … sai quanti wish stanno aspettando pazientemente in coda ? :wink:

E non credo che il fatto che ci sia in giro uno script blocchi lo sviluppo di un certo comando.
E’ solo che, mentre aspettiamo che un wish venga implementato (se mai lo sara’), possiamo provare a metterci una pezza con lo script e andare avanti.

Anche perche’ non e’ poi che con gli script si possa fare chissa’ cosa …
a meno forse di farli scrivere da professionisti con molto tempo a disposizione, e sospetto che sia quello che fanno alcune grandi aziende che utilizzano Rhino (parliamo di script e/o plug-in, ma ormai c’e’ poca differenza), ma certo non vanno poi a rilasciare al pubblico i loro prezioni strumenti.

Gli script (al nostro livello) vanno bene per le personalizzazioni, gli adattamenti, i casi particolari, per velocizzare le operazioni.
Non certo per sostituire un comando mancante o per cambiare il modo di lavorare di Rhino, almeno questa e’ la mia opinione.
E come dici giustamente, non tutti amano dedicarsi agli script.
, E ancora meno sono coloro che hanno il tempo di farlo in ogni caso.

Pero’ Rhino e’ fatto cosi’. Non riesce a fare tutto cio’ che vorremmo (pure noi siamo fatti cosi’: Rhino dovrebbe fare tutto…) … e allora meno male che c’e’ chi come Pascal, ma anche alcuni altri come il nostro amico Vittorio, mette giu’ uno script che con tutti i suoi limiti in certi casi da’ comunque una mano preziosa.

E se questo stato di cose ha i suoi lati negativi, come dicevi tu certo ci sono, mette pero’ in luce il fatto che tra rhinofili, quando si puo’ ci si da’ una mano, o magari semplicemente ci si diverte a provare a imbastire uno script … e magari a imparare qualcosa :wink:

E questo vale ancor piu’ per GH.
In GH mi sembra molto piu’ comodo rintracciare e utilizzare un componente scritto da un altro utilizzatore.
Sara’ per l’impostazione di GH …
Sara’ per la sua comunita’ di utilizzatori (e qui ci vuole un plauso agli architetti …) …
Non so.
Resta il fatto che a me GH per certi versi continua a sembrare il fratello intelligente di Rhino … :smile: :smile:

Peccato che i due fratelli non si parlino gran che’ …

La mia era giusto un’osservazione.
Discorso script a parte, mi sembra di capire che rhino si sviluppi sulla base delle richieste degli utenti… Ma tutta la mole di wish che perviene al quartier generale, dovrà essere per forza di cose filtrata, smistata, valutata…; pertanto, su quali basi poi si stabilisce la fattibilità e lo sviluppo di un certo comando anziché un altro?
Esempio: ci sono volute ben 5 versioni di rhino prima che si fosse deciso di introdurre l’utilissimo comando “Shell”, e sappiamo bene quanto tempo passa da una versione all’altra! Qualcuno magari si sarà chiesto “ma non ci potevano pensare un po’ prima?”.
Sicuramente lo strumento Shell sarà stato voluto a furor di popolo rispetto, che so, ad un comando di superficie.
Non vorrei trovarmi nei panni degli sviluppatori: con tutte quelle richieste c’è da impazzire! Chi vuole i fillet, chi lo Shell, chi il multi blend… Anzi, se fossi al loro posto, sai cosa direi a ciascun utilizzatore? “ma perché non ve lo sviluppate voi Rhinoceros così la finite di rompere i maroni!”. :wink:

Piccolo appunto, alcuni comandi aggiunti erano necessari perché cronicamente assenti (vedi shell) ma non sono così potenti da potersi applicare in tutti i casi, spesso funzionano con geometrie semplici e stop…
Altri che tutt’oggi mancano (multiblend) se implementati sarebbero davvero una svolta perché impiegabili in moltissime situazioni ed estremamente risolutivi

Forse sbaglio ma penso che alla fine tutti noi lavoriamo con un set molto limitato di comandi.
Per questo le mie richieste sarebbero quelle di migliorare l’esistente che mi pare più che sufficiente per fare praticamente “tutto”.
Certo non sarebbero scomode ulteriori funzioni ma a quel punto le esigenze dei singoli sarebbero le più
disparate e trovo corretto che si provveda con plug-in, script e pacchetti software integrati.

Ci sono delle funzioni che secondo me
andrebbero ampliate e perfezionate, alcune danno l’impressione di essere state solo abbozzate e lasciate al proprio destino.
Non mi dispiacerebbe poi che per OGNI comando si aprisse un finestrella con la possibilità di impostare i vari parametri e vedere un preview, la riga di comando con le varie impostazioni non mi è mai piaciuta.
Se proprio devo esprimere un desiderio specifico direi il comando Time per il conteggio del tempo di lavoro.

Fabio.

1 Mi Piace

io riallacciandomi a un altro mio post rilancierei la proposta anche solo all’interno del forum ita di una sezione “forse non tutti sanno che…” tipo la rubrica della settimana enigmistica :slight_smile: in cui in sotto argomenti per comando ciascuno può contribuire postando anedoti e opzioni di utilizzo di comandi che (ribadisco) anche se usati da sempre a volte riservano delle sorprese inesplorate…

1 Mi Piace

Marco, son d’accordo, lo Shell era una grande mancanza. Secondo me funziona anche su geometrie complesse e articolate, l’importante è che i solidi siano ben chiusi e bisogna tante volte agire sul valore di tolleranza, uniche accortezze. Dovrebbero lavorare meglio su certi casi particolari, questo è vero, ma funziona in molti casi (sul sito discourse INT, se cerchi “another Shell failed”, ho postato due casi in cui lo Shell, purtroppo, ancora fallisce… sono solo due esempi).

Il multiblend invece sarebbe una grande novità e devo dire che rhino ne avrebbe bisogno (sopperire la sua mancanza con la patch è davvero una cattiva scelta!). Un multiblend davvero ben fatto permetterebbe di risolvere tanti casi particolari di fillet che tuttora rhino fatica a realizzare. Mi sembra pure strano che un modellatore di superfici free form non contempli ancora tale caratteristica.

Sarebbe una simpatica idea, ma già è tanto che si “dialoghi” qua all’interno del forum…alla fine siamo quattro gatti…
Io invece vorrei che tutte le nostre richieste (wish) venissero raccolte e portate avanti, per quanto possibile…
Non metto in dubbio che ciò venga fatto, ma ho l’impressione che si parli sempre delle stesse cose negli anni, o mi sbaglio?
Vorrei un forum più proficuo…