-
.Mi propongo di risolvere, in maniera migliore di quanto non abbia già fatto in passato, il problema di tener conto di spigoli 'smussati' presenti in un poligono, al fine di determinare, al solito, le caratteristiche geometriche o altro del poligono (non bisogna andare tanto lontano, basta pensare ad un profilo IPE/HEA/UPN).
In pratica, così come in Autocad utilizziamo il comando 'fillet' (o 'raccorda' in italiano), dovremmo ottenere dal vertice 'puntuto' del nostro poligono, una cosa del genere:
Ora, siccome siamo abbastanza bravi a manipolare poligoni 'puntuti', in realtà non voglio sobbarcarmi l'onere di determinare aree, inerzie, ecc. considerando il raccordo circolare vero e proprio.
Mi accontento di 'discretizzare' l'arco di cerchio in un numero finito di segmenti (magari definibile dall'utente, anzi senza il magari), così:
Diciamo che in partenza ho un paio di idee da inserire in questo topic, ma non sono ancora del tutto sicuro di riuscire a 'finalizzare' il tutto. Vedremo........
. -
.
Quale deve essere l'input? . -
.
L'input dovrà essere 'per forza' il raggio del raccordo.
Poi a mio avviso, anche per eseguire qualche controllo (tipo raggio troppo grande, ecc.), dovremmo indicare almeno i due segmenti di 'convergenza' al vertice, oppure le coordinate di tre punti: precedente al vertice da smussare-vertice da smussare-successivo al vertice da smussare.. -
UncleJack .
User deleted
La struttura dei dati prevede un insieme di coordinate consecutive che rappresentano il poligono ?
[Non ho ancora studiato le varie procedure presenti in questo forum, magari avete già delle convenzioni "assodate" - anch'io programmo da quando ho memoria, magari posso contribuire in qualche modo]. -
.La struttura dei dati prevede un insieme di coordinate consecutive che rappresentano il poligono ?
[Non ho ancora studiato le varie procedure presenti in questo forum, magari avete già delle convenzioni "assodate" - anch'io programmo da quando ho memoria, magari posso contribuire in qualche modo]
Nel caso dei poligoni, zax ha definito una sua struttura che include il numero dei vertici e due vettori contenenti le coordinate dei vertici. Poi ha esteso la struttura in esame includendo anche i campi relativi alle caratteristiche geometriche.
Io invece uso una struttura composta da un unico vettore di dati strutturati. Il dato strutturato ingloba in se le due coordinate del generico punto.
In VB io uso:CODICEPublic Type TipoPunto
x As Double
y As Double
End Type
eCODICEdim Poligono() as Tipopunto
Naturalmente tu potrai usare qualsiasi struttura a te pù congeniale.
é anche naturale che il tuo contributo in qualsiasi discussione è più che gradito. Magari fossi arrivato prima!!!. -
.
Uncle, diciamo che nel passato ci siamo divertiti a creare qualche procedura proprio sui poligoni.
Avendone fatte di cotte e di crude, possiamo pensare a tante alternative.
Ad esempio afazio aveva creato la struttura dato 'segmento' a sua volta costituita da due strutture 'punto' annidate.
Io dal canto mio ho sempre lavorato su queste cose con una struttura 'poligono' che contiene di fatto due vettori con le coordinate x,y di ogni vertice, ed il numero complessivo di vertici cui il poligono è costituito.
Quindi sarà possibile passare alla funzione, semplici numeri che rappresentano le varie coordinate, strutture 'punto' ognuna delle quali rappresentante un vertice, strutture 'segmenti' (il precedente ed il successivo al vertice da smussare), oppure infine l'intero poligono e l'indice di quale vertice andrà smussato.
Io ad esempio preferirei passare alla funzione l'intero poligono. La funzione a sua volta mi restituirà il poligono con un numero di vertici maggiorato e con i nuovi vertici del raccordo al posto giusto.
Ma questi saranno poi dettagli implementativi, diciamo, successivi.
Adesso devo prima sviluppare il ragionamento matematico.. -
UncleJack .
User deleted
[OT - piccolino]
Ho iniziato tempo fa a costruire la mia libreria sulla geometrica computazionale, è ancora embrionale ma usabile. Mi chiedo se abbia un senso estenderla, vista la presenza di librerie come la GPC (General polygon clipper).
Avevo anche implementato l'integrazione di una funzione lungo la frontiera mediante Green. Poi mi sono occupato di altro, magari è ora di rispolverare un po' di materiale.
[/OT]. -
.[OT - piccolino]
Ho iniziato tempo fa a costruire la mia libreria sulla geometrica computazionale, è ancora embrionale ma usabile. Mi chiedo se abbia un senso estenderla, vista la presenza di librerie come la GPC (General polygon clipper).
Avevo anche implementato l'integrazione di una funzione lungo la frontiera mediante Green. Poi mi sono occupato di altro, magari è ora di rispolverare un po' di materiale.
[/OT]
Vedi Uncle, stiamo ripercorrendo sentieri battuti, anzi battutissimi.
E' vero che è possibile trovare dovunque tutto quello che ti serve, e materiale a bizzeffe....ma vuoi mettere??? Riuscire a fare tu quello che anche altri sono riusciti a fare?. -
.Ad esempio afazio aveva creato la struttura dato 'segmento' a sua volta costituita da due strutture 'punto' annidate.
E' vero. Quando la cosa rende piu' agevole lo sviluppo del codice posso fare ricorso ad altre strutture come per esempio:CODICEPublic Type TipoSegmento
start As TipoPunto
end As TipoPunto
End Type
ed in questo caso, dato che il raccordo sarà un arco di cerchio, potrebbe tornare utile la struttura:CODICEPublic Type TipoCerchio
centro As TipoPunto
R As Double
End Type
oppure altra struttura, da definire meglio, che oltre ad avere il centro ed il raggio del cerchio abbia anche l'angolo di partenza e l'angolo di arrivo (o l'estensione angolare) dell'arco di raccordo.. -
UncleJack .
User deleted
Troviamo in quale dei due semipiani individuati dal primo segmento giace il secondo vertice del secondo segmento, lì si troverà il centro del raccordo.
Dovremmo riuscirci facendo il prodotto vettoriale dei due vettori, se è positivo sta a sinistra, se negativo a destra. Se è zero niente raccordo, i due vettori sono paralleli.
In generale io preferisco lavorare con gerarchie di classi piuttosto che con strutture di dati più semplici, ma in effetti il codice prettamente algoritmico non cambia.. -
.[OT - piccolino]
Ho iniziato tempo fa a costruire la mia libreria sulla geometrica computazionale, è ancora embrionale ma usabile. Mi chiedo se abbia un senso estenderla, vista la presenza di librerie come la GPC (General polygon clipper).
Avevo anche implementato l'integrazione di una funzione lungo la frontiera mediante Green. Poi mi sono occupato di altro, magari è ora di rispolverare un po' di materiale.
[/OT]
In merito al clipping dei poligoni, ci siamo occupati anche noi, in un topic di cui non ricordo il titolo, della questione.
Non siamo pervenuti a nulla di utilizzabile perchè stanchi ci siamo ritirati prima. Il semplice uso della libreria GPC (di cui ho pure trovato una versione in Delphi), non ci avrebbe fatto capire tante cose sul problema ed anche quando non abbiamo alla fine creato nulla di nostro, personalmente e penso anche zax, è bastato lo studio e l'approfondimento della problematica.. -
UncleJack .
User deleted
Sono daccordo con te, sembra di rileggermi :-) . -
.Troviamo in quale dei due semipiani individuati dal primo segmento giace il secondo vertice del secondo segmento, lì si troverà il centro del raccordo.
Dovremmo riuscirci facendo il prodotto vettoriale dei due vettori, se è positivo sta a sinistra, se negativo a destra. Se è zero niente raccordo, i due vettori sono paralleli.
In generale io preferisco lavorare con gerarchie di classi piuttosto che con strutture di dati più semplici, ma in effetti il codice prettamente algoritmico non cambia.
E se il raggio del raccordo è pari alla metà della distanza tra i due segmenti paralleli?. -
UncleJack .
User deleted
Se ho capito bene la domanda, se sono paralleli e consecutivi non c'è motivo di raccordare. Se non sono consecutivi non si tratta di un poligono chiuso o perlomeno di una polilinea.
Io sto interpretando che si possa semplicemente indicare un vertice e un raggio di raccordo, mi pare tu la stia vedendo più in generale.
Sbaglio ?. -
.Troviamo in quale dei due semipiani individuati dal primo segmento giace il secondo vertice del secondo segmento, lì si troverà il centro del raccordo.
Dovremmo riuscirci facendo il prodotto vettoriale dei due vettori, se è positivo sta a sinistra, se negativo a destra. Se è zero niente raccordo, i due vettori sono paralleli.
In generale io preferisco lavorare con gerarchie di classi piuttosto che con strutture di dati più semplici, ma in effetti il codice prettamente algoritmico non cambia.
E se il raggio del raccordo è pari alla metà della distanza tra i due segmenti paralleli?
Non dimenticare afazio che c'è sempre un vertice tra due segmenti consecutivi del poligono. Ed il caso di vertice all'infinito non lo abbiamo mai affrontato.
Invece se ricordi abbiamo trattato diffusamente il problema del 'peduncolo' (due segmenti consecutivi e sovrapposti)..
Smussiamo i poligoni |
