riposto il codice che migliorato, lo trovo importante sia per la stampa 3D che per i rendering.
Rispiego perché.
In questo tipo di disegni c'è la necessità che i punti usati da questi programmi, se devono essere
uguali lo siano davvero, mentre il cad, dopo operazioni in virgola mobile (tipicamente rotazioni) ne compromette l'integrità.
Anche qui sul forum ho letto topic che segnalava il problema per elementi con coincidenza non perfetta.
Mi spiego,in una mesh STL una
x = 13.7865000 non è affatto uguale a
13.7864999, generato nel CAD da operazioni in virgola mobile, e se il programma di stampa o render li trova giustamente differenti, può tirare conclusioni sbagliate sull'integrità della mesh.
Il mio problema non era però solo questo, ma anche (vedi titolo topic) non avere la notazione esponenziale, che il cad mi propina ogni tanto su file in scrittura, anche quando con RTOS dichiaro che
NON la voglio. (prima opzione dichiarata a "due" (notazione DECIMALE).
L'unico modo per evitarla è stato di spostare provvisoriamente la virgola di tre posti. Se spostavo di 4, con il * 10000 ricondotto poi a / 10000, niente da fare la notazione "E" risaltava fuori.
Io così tronco il float (usando il * e il / solo a 1000) esattamente solo a tre decimali, ma che mi bastano decisamente, sia sui lavori di stampa 3D, dove la mia
unità di misura la assumo al millimetro, sia per l'architettura, dove assumo il metro, e non mi interessa certo il decimo di millimetro.
C'è però un'altra questione, il FIX autolisp tronca, non arrotonda.
Io invece riducendo a tre decimali dopo la virgola voglio approssimare all'arrotondamento
più vicino, e non troncare bruscamente. E ho aggiunto quindi le routine che credo appropriate giacché la funzione ROUND in autolisp classico non c'è.
Questa dunque la funzione... che per ora pare fungere senza errori.
Probabilmente è ridondante, ma preferisco, e tra l'altro non so se ho capito bene il concetto, ma mi tocca "ripescare" l'argomento che ho passato alla funzione da una variabile interna alla funzione, perché (non so se mi sbaglio) ma il defun mantiene solamente
in locale le modifiche che gli faccio fare all'argomento che gli ho passato.
Quando esco dal defun l'argomento me lo ritrovo tale e quale come l'ho passato all'origine. Da qui, ecco perché riprendo dal "tra" nel defun il nuovo valore elaborato localmente. e devo assegnarlo all'argomento.
E' un po' un casino ma non ho capito cosa si possa fare di più elegante. Nel caso ci sia un metodo del tipo più spedito ringrazio....
intendo dire del tipo DEFUN Chiamo(x) ... e in uscita x conterrà il nuovo valore valore che ho calcolato in Chiamo...
io non son riuscito, le variazioni a x mi restano sempre locali alla funzione...
Codice:
(Defun clean(a)
(setq tra a)
(setq tra (* tra 1000))
(setq tra (fix tra))
(setq hh (rtos tra 2 3))
(setq tra (atof hh))
(setq tra (/ tra 1000))
; procedura round
(if (>= tra 0) ; se positivo
(progn
(setq diff (- a tra))
(if (> diff 0.0005)
(setq tra (+ tra 0.001))
)
)
(progn
(setq diff (- a tra))
(if (< diff -0.0005)
(setq tra (- tra 0.001))
)
)
)
); end defun clean
nel main, ogni valore elaborato, dopo la chiamato al DEFUN, lo devo recuperare da "tra", elaborato all'interno della funzione su una copia di Ax, e riassegnarlo all'argomento
(clean Ax)
(setq Ax tra)
mi par macchinoso ma come dicevo non riesco in altro modo, perché l'argomento Ax viene modificato dalla funzione, ma solo come variabile locale.
