La spiegazione di tutto potrebbe essere il fatto che Rhino è nato come modellatore versatile e flessibile, e s’è imposto rapidamente nel settore del Product Design.
Successivamente qualcuno ha imposto una radicale scvolta a favore dell’Architectural Design (e in questo campo con Grasshopper eccelle) solo che, distrattamente, nel passaggio tra i due ambienti ha finito per impiccarsi ad un trave BIM in cui s’è impigliata una zip disegnata nel vecchio ambiente ID.
Il problema delle tolleranze, in ambiente di ID, è di antichissima data.
Io ricordo quando usavo I-DEAS (che con Rhino interscambiava dati senza il minimo problema), con Pro/E proprio non voleva sentir ragioni.
Andando a fondo della question, trovai delle circolari di BOEING e di FORD ai fornitori, in cui si intimava di adeguarsi o di cambiare cliente, perché loro non intenbdevano certo sostituire migliaia di postazioni I-DEAS per adeguarsi alle bizze di Pro/E.
Non ho avuto interazione con UG, ma posso dire che sia NX che SolidEdge sembrano digerire piuttosto bene i file di Rhino.
Non posso dire lo stesso di SolidWorks. Anzi, esattamente il contrario.
Una soluzione che pare funzionare abbastanza bene, nel caso di esportazione da Rhino, è quella di salvare in formato nativo Rhino V3.
Gli STP da Rhino a SW invece sembrano produrre risultati dubbi.
Soprattutto, quel che mi lascia perplesso, è la casualità, random, degli errori generati dallo stesso file in momenti diversi. Cosa che lascia presupporre seri problemi di tolleranze tali da indurre in errore l’algoritmo di conversione in SW.
Ai tempi di I-DEAS vs Pro/E, al contrario, c’era una matematica sistemicità nel riproporre il medesimo errore. Sovrapposizioni nei fillet, con errori di 0.15/0.25mm. Pro/E pareva non trimmare correttamente le superfici raggiate. So che in ambiente automotive avevano trovato il modo di adeguare le tolleranze in Pro/E, io non ne sono mai uscito.
Tra Rhino e SW non pare funzionare in questo modo. Sembra che ad ogni importazione si generi una sequenza di incertezze e di risultati casuali, ogni volta diversi. Come se per “aggiustare” una superficie, il programma tiri una volta di qua o si allarghi una volta di là.
Una possibile soluzione, sperimentata più volte con successo, è quella di passare attraverso MoI 3D.
Tra l’altro uno dei risultati apparenti, sia in 3DM che in STP, è quello di dimezzare il peso del file (quello generato da MOI3D pesa circa la metà di quello originale di Rhino) e le superfici hanno uno span più pulito. Questo era anche risultato ai tempi del passaggio dalla V2 alla V3, tra Rhino ed I-DEAS, quando m’era stato chiesto di fare da beta tester per la conversione IGES tra i due ambienti.
Ho parlato prevalentemente d’esportazione da Rhino in quanto è in quel caso che storicamente ho riscontrato le maggiori criticità.
Per quel che mi riguarda ho l’abitudine d’importare piuttosto che aprire i file STP o altri formati nativi, per cui generalmente non incontro grossi problemi.
E’ indubbio che una maggiore libertà nel decidere i valori di tolleranza nelle operazioni di IMPORT/EXPORT sarebbe la benvenuta.
Soprattutto mi lascia sgomento l’idea che il parametro base di default sia stabilito in METRI e con una tolleranza tanto stretta. Significa proprio volersi far del male. Con determinazione.