Newsgroup: it.scienza.informatica
Titolo: problema (collisioni e spinte)

Chi mi da' una mano a risolvere un problema?
Ve lo espongo:
Ho una serie di blocchi quadrati tutti dello stesso lato, che si
muovono a caso sullo schermo in uno spazio continuo bidimensionale. Ne
conosco le coordinate, ovviamente, e le velocita' vx e vy.
Quello che mi interessa e' riuscire a fare in modo che questi blocchi
si spingano a vicenda quando vengono a contatto, senza mai
sovrapporsi, come se fossero dei cubi che vengono spinti l'uno contro
l'altro su un piano (non possono comunque ruotare sul proprio asse).
Naturalmente gli scontri non avverrebbero solo a due a due, ma
potrebbero crearsi ingorghi di molti blocchi addossati gli uni agli
altri.
E naturalmente, la routine dovrebbe essere efficiente.
Qualcuno ha un'idea?
Ciao,
Anders
-> it.scienza.informatica (Moderated)
%followup-to
it.scienza.informatica

 Qualcuno ha un'idea?
Il proplema non e' specificato in maniera completa.
Non e' chiaro infatti in che senso i blocchi si "spingono".
In pratica devi realizzare una semplice routine che verifica lo stato di
collisione e in tal caso modifica le velocità dei blocchi in base ad una qualche
modello. Il test di collisione non e' difficile dato che si tratta di quadrati.
Il modello "fisico" della collisione e' proprio quello che non specifichi.
Quindi non saprei come aiutarti.
Se il tuo modello deve rispecchiare la fisica reale dovrà tenere conto non solo
delle relative direzioni (velocita') dei blocchi che collidono ma anche del
punto di collisione, delle masse e delle elasticità (ed eventualmente di altri
parametri quali l'atrito etc.). Ma dato che sono quadrati che non possono
ruotare e' evidente che non stai modellando la realtà, e a questo punto non
posso presumere che modello fisico virtuale hai in mente.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556


On Tue, 12 Jun 2001 17:48:53 +0200, "Andrea Ferro"
<And...@UrkaDVD.it> wrote:
...Perdonami, non posso quotare il tuo messaggio perche' il
robomoderatore di questo ng e' particolarmente schizzinoso, rifiuta
righe troppo lunghe e non ho voglia di stare a parlamentare con lui
via e-mail (ovvero inviare il messaggio, aspettare che lo rifiuti,
riinviarglielo, ecc..)
Provo a spiegarmi meglio. Il test di collisione e' a posto, non c'e'
problema per quello. La collisione e' completamente anelastica, quindi
i blocchi non rimbalzano quando si toccano, ma rimangono con i lati
affacciati fino a che non interviene qualcosa (un nuovo urto, una
modifica di velocita') a staccarli. In piu' i blocchi scivolano l'uno
sull'altro senza attrito, percio' l'unica spinta che possono
esercitare l'uno sull'altro e' diretta in senso ortogonale alla faccia
che la esercita.
Il mio problema e' questo: quando ci sono molti blocchi appoggiati
l'uno all'altro, il movimento di uno condiziona o puo' condizionare
quello di tutti gli altri (forse dovrei specificare anche che i
blocchi non si muovono per inerzia, ma hanno un "motore" interno, che
gli permette di cambiare direzione e velocita' in ogni momento) .
Come semplificazione della fisica, ho stabilito che piu' blocchi che
si spingano dovrebbero avere complessivamente la media delle singole
velocita'. 
Quindi non basta verificare le singole collisioni. Bisogna considerare
interi gruppi di blocchi in collisione fra loro. 
Ciao,
Anders


 interi gruppi di blocchi in collisione fra loro.
Intendi in contatto? Ma a me non pare affatto una semplificazione della fisica.
Mi sembra piu' che altro una complicazione. E soprattutto non capisco bene cosa
intendi.
Provo comunque a farti un esempio di come farei io la cosa ignorando il discorso
della "media". Presumendo che esista una qualche classe "Vec" che rappresenta un
vettore bidimensionale (e le relative operazioni fra vettori, ovviamente), ogni
oggetto mantiene la sua posizione attuale (un vettore), la sua velocità attuale
(un vettore) e, dato che lo hai citato, il valore attuale della forza generata
dal motore (sempre un vettore). Supponiamo l'assenza di attrito, urti
anaelastici, impossibilità di ruotare gli oggetti, presenza di inerzia del
movimento (dovuta all'attrito 0) ma assenza di massa nel calcolo degli urti. Ad
ogni "ciclo" eseguiamo in sequenza quanto segue:
1) cambiare il valore di tutti i vettori "motore" in base alla logica che regola
la variazione delle spinte dei motori (se necessario).
2) calcolare i nuovi valori dei vettori velocità
3) verificare eventuali collisioni e modificare i dati in base a queste
4) calcolare i nuovi valori dei vettori posizione
In questo modello la cosa meno banale e' la gestione delle collisioni. Ne
parliamo fra un attimo.
I calcoli sono semplici. Il passo uno dipende da come lo vuoi fare tu.
Il passo due consiste nel sommare, per ciascun oggetto, il vettore velocità ed
il vettore motore. Il risultato e' il nuovo vettore velocità.
Il passo quattro consiste nel sommare al vettore posizione il vettore velocità.
Le collisioni andrebbero verificate non in base alla posizione attuale o futura
degli oggetti ma in base al tratto di spazio percorso. Ovvero data la posizione
vecchia e la velocita' aggiornata ogni oggetto lo puoi rappresentare come un
segmentino. E ciascun segmento con la retta che lo sostiene. Una collisione
avverra' normalmente "in mezzo" al segmentino. Il modo piu' semplice per evitare
questa complicazione e' cambiare la scala del tempo (modificando di conseguenza
tutti i vettori) fino a che l'oggetto piu' veloce del sistema si sposti di una
unità discreta (un pixel, se vuoi). A questo punto esistono due concetti di
"posizione" di un oggetto. Uno e' quello fisico (il vettore posizione) e l'altro
quello discreto (lo stesso vettore convertito ad interi che rappresentano i
pixel). La collisione calcolata nel discreto corrisponde al contatto fra oggetti
nella loro posizione discreta. Dato che un oggetto non si sposterà mai di una
quantità superiore ad un pixel il caso peggiore e' una "compenetrazione" totale
di due pixel. Ovvero due oggetti A e B saranno in uno di questi casi:
1) A e B non si toccano ne prima ne dopo il movimento di entrambe
Questo e' il caso di non collisione.
2) A e B non si toccano prima ma si toccano dopo il movimento di entrambe
Questa e' una collisione.
3) A e B non si toccano prima si toccano dopo il movimento di uno dei due e si
compenetrano (di una unità discreta) dopo il movimento di entrambe.
Questa e' una collisione un pochino piu' complicata.
4) A e B si toccano fin da prima del movimento.
In realtà i tuoi oggetti saranno mantenuti in qualche genere di container ed
esisterà un qualche metodo per enumerarli. Questo crea (anche se
artificialmente) una specie di "ordine" fra gli oggetti. Possiamo sfruttare
questo a nostro vantaggio considerando che la condizione 4 puo' essere in realtà
verificata nel ciclo precedente. In pratica quello che faremo e' verificare le
collisioni non come una condizione fra una coppia non ordinata di oggetti ma fra
una coppia ordinata in cui A precede sempre B nell'ordine di attraversamento. In
altre parole la nostra collisione la collisione fra due oggetti e' verificata in
questo modo (ricorda che A precede B nell'ordine di attraversamento):
A collide B se e solo se A e B si toccano (nelle loro posizioni discrete) prima
del movimento. Questa informazione e' pregressa in quanto valutata nel ciclo
precedente. Con questa informazione possiamo ricalcolare i dati relativi ad A e
poi "muoverlo" senza accedere a B (che e' posteriore nell'ordine di
attraversamento).
B collide A (che si e' già mosso) se i due oggetti si toccano (nelle loro
posizioni discrete) dopo il movimento di A e prima di quello di B. Con questa
informazione possiamo ricalcolare i dati relativi a B e poi "muoverlo"
ricordandoci di verificare se dopo il movimento (quindi dopo il movimento di
entrambe) gli oggetti si toccano (nelle loro posizioni discrete). In tal caso
salveremo questa informazione in A in quanto evidentemente alla prossima
iterazione A colliderà B.
Pensaci e vedrai che una volta limitata la velocità assima di tutti gli oggetti
in una iterazione a non piu' di uno scatto discreto la cosa e' effettivamente
cosi'.
Ora la domanda e' cosa fare in caso di collisione. La risposta non mi pare
complessa:
1) aggiornare il vettore posizione di ciascun oggetto in modo che assuma
l'esatto valore discreto (un po come dire che "x=(int)x;" se x e' reale e
l'unità di misura e' il quanto di discretizzazione).
2) verificare se la collisione e' verticale o orizzontale e azzerare in entrambe
gli oggetti la corrispondente componente del vettore velocità. Infatti l'urto e'
anaelastico e siamo in assenza di massa. Se fosse elastico e se avessimo massa
dovremmo calcolare di conseguenza il nuovo valore dei vettori.
A questo punto possiamo analizzare le inefficienze che abbiamo introdotto e ci
accorgiamo che ce ne sono principalmente due:
1) ogni iterazione prevede cinque enumerazioni complete su tutti gli oggetti (e
uno di questi cicli prevede una enumerazione completa su tutti gli oggetti che
lo precedono).
2) ogni iterazione e' "scalata" in maniera che la velocita' massima sia di un
pixel per interazione. Questo in realtà non e' necessario se gli oggetti sono
(lontani).
Affrontiamoli uno per volta. Per prima cosa notiamo che e' possibile ridurre il
tutto a due sole enumerazioni complete (una per scalare il tempo e aggiornare i
vettori motore l'altra per i calcoli). Ogni elemento conterrà:
-) vettore motore
-) vettore velocità
-) vettore posizione
-) lista elementi in contatto alla posizione attuale
inoltre sapremo dalla iterazione precedente la velocità fisica massima nel
sistema.
La prima enumerazione per ogni oggetto ricalcolerà il vettore motore in base
alla logica scelta e poi aggiornerà il vettore motore e velocità in base al
fattore di scala derivato dalla velocità massima ottenuta nell'iterazione
precedente.
La seconda iterazione farà, per ogni elemento, quanto segue:
1) per ogni elemento nella lista degli elementi a contatto (e per l'elemento
corrente se la lista non e' vuota), aggiornare il vettore posizione facendogli
assume il suo valore discreto e azzerare la componente orizzontale/verticale
corrispondente al tipo di contatto.
2) rimuovere tutti gli elementi dalla lista dei contatti.
3) calcolare in varibili locali la posizione attuale e la nuova posizione
(attuale+velocità) sia per il vettore velocità cosi' come e' sia per il vettore
velocità modificato azzerando una o l'altra componente. Nota che la posizione
attuale corrisponde alla nuova con entrambe le componenti velocità azzerate. In
totale avremo quattro posizioni. Discretizzare tutte e quattro.
4) ciclare gli elementi precedenti nell'ordine di attraversamento verificando
per ciascuno se sono a contatto con noi messi in una qualunque delle quattro
posizioni che abbiamo calcolate. Mantenere quattro liste locali di elementi in
cui inseriremo quelli che danno esito positivo al test.
5) se nessun elemento e' stato inserito nella lista dei contatti alla posizione
attuale non abbiamo collisioni in questo movimento, il vettore velocità e'
valido e la lista relativa ai contatti dopo il movimento non modificato e'
quella che ci interessa. Se invece ci sono contatti alla posizione attuale
scorriamo tale lista e azzeriamo la componente di collisione sia nel nostro
vettore velocità che in quello degli oggetti della lista, inoltre discretizziamo
sia la nostra posizione che la loro. Poi scegleremo come lista che ci interessa
quella opportuna (a seconda se abbiamo azzerato una, l'altra o entrambe le
nostre componenti).
6) la lista scelta nel punto precedente e' la lista dei contatti dopo il nostro
movimento. Inseriamo noi stessi nella dei contatti contenuta in ciascun elemento
della lista.
7) aggiorniamo la nostra posizione sommandole il vettore velocità.
8) aggiorniamo il vettore velocità sommandogli il vettore motore (ricordarsi di
mantenere la velocità massima in una variabile che servirà nell'iterazione
successiva).
Questo schema e' sufficiente e non troppo complesso. Ora non posso ma se ti
interessa ti metto giu' un framework in C++ che lo implementa (poi dovrai
aggiungerci la logica dei motori, tutta la parte grafica e quant'altro ti
serve).
L'altra limitazione e' dovuta allo "scaling". Non tanto nel senso che e'
inefficiente eseguirlo (a meno che gli elementi non siano veramente molti) ma
nel senso che se gli elementi sono veloci (in pixel per ciclo di
visualizzazione) e lontani fra loro ti ritrovi a dover eseguire inutimente molte
iterazioni per ciclo di visualizzazione. Ci sono molti modi per ovviare a questo
problema e tendenzialmente si dividono in due categorie:
1) non eseguire lo scaling e gestire le collisioni matematicamente identificando
gli oggetti che collidono "fra un frame e l'altro" e ricalcolare le traiettorie
e le modificazioni tutto in un colpo. Questo approccio e' valido se gli oggetti
sono comunque pochi o se la precisione non e' importantissima.
2) calcolando l'istante in cui avverrà la prossima collisione. Se e' dopo il
prossimo frame, scalare in base al tempo del prossimo frame, altrimenti in base
a quello della prossima collisione. Questo approccio e' valido soprattutto se la
logica del "motore" interno algi oggetti e' anchessa scalabile e se il concetto
di frame non e' relativo ad una animazione in tempo reale ma ad una precisione
minima richiesta. Ovvero se il tuo scopo finale non e' visualizzare gli oggetti
in movimento ma precalcolare (in offline) l'animazione o gli istanti di
collisione. In tal caso e' evidente che calcolare una "storia" di 10 minuti (250
frame) impiegando 5 minuti di elaborazione di cui 4 per calcolare una sequenza
complicata di eventi che avvengono nell'arco di 8 frame e uno solo per calcolare
tutti i restanti 242 frame e' accettabile (non lo e' se i calcoli devono essere
in real time).
Naturalmente tutto quanto detto presume che a te serva effettivamente una
precisione alta nella gestione delle collisioni (limitata solo da un livello di
discretizzazione che ho chiamato pixel ma potrebbe essere qualunque altro
livello tu voglia). Se invece tale precisione non ti serve (pensa ai cosiddetti
"particle systems" che calcolano per esempio il rovesciarsi di centinaia o
migliaia di biglie su un pavimento a scopi di "effetto visivo") allora la cosa
e' diversa. Persino il concetto di collisione e' diverso (di fatto in quei
sistemi le "biglie" si compenetrano allegramente, spariscono nel nulla,
compaiono dal nulla, collidono anche se sono distanti fra loro etc.).
Comunque se mi dici qualche cosa di piu' sulla dimensione del tuo universo
bidimensionale, su quella degli oggetti, e sulla logica dei "motori", posso
provare a metterti giu' in questo week-end un piccolo framework in c++ (se ti
interessa).
Pero' fammi sapere in fretta. E ovviamente non prometto di avere il tempo (ma
penso di trovarlo, soprattutto domani pome che e' sabato).
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556


 >
Mi replico da solo dato che il post e' arrivato in NG in ritardissimo (dopotutto
anche i moderatori dormono al sabato).
Senza riquotare tutto, di fatto l'algoritmo che ti avevo proposto e' una
modifica di una cosa fatta tempo fa (ricordata a memoria). Ma ripensandoci non
credo che, cosi' come l'ho messo giu', possa funzionare.
Ho fatto alcune pensate e ho qualche idea. Ma mi scontro con il fatto che non ho
compreso fino in fondo il tipo di fisica che vuoi implementare. Soprattutto non
ho capito se l'universo e' finito/infinito e aperto/chiuso, che dimensioni ha
(soprattutto rispetto agli oggetti) e quali sono le velocità (rispetto
all'universo). Poi non mi e' chiaro cosa dovrebbe avvenire esattamente in caso
di collisione.
Posso metterti giu' credo senza troppi problemi un framework in C++ (te lo farei
in VC7 beta 1 ma non dovrebbe essere un problema portarlo su altri sistemi dato
che non usero' nulla di non standard). Su quello puoi poi eventualmente
sperimentare varie leggi fisiche e vari algoritmi. Dimmi se ti interessa.
Pero' per farlo dovresti darmi una idea migliore di cosa ti serve. Il problema a
cui ho pensato e che credo di poter definire in maniera che forse non e' al
massimo assoluto dell'efficienza ma che e' sufficientemente flessibile da
permetterti di sperimentare (puoi sempre ottimizzare dopo) e comunque
sufficientemente ptrestante da gestire il problema cosi' come l'ho pensato io
non e' complicatissimo da risolvere. Se ti interessa dimmelo.
Ecco cosa ti darei (salvo che non capisca meglio cosa ti serve) come framework
di partenza:
Dimensionalità dell'universo: 2D (credo immediatamente estendibile al 3D).
Dimensioni dell'universo: 8/10 metri quadrati (o cubi).
Forma degli oggetti: circolare (o sferica).
Dimensioni degli oggetti: dell'ordine dei 10 cm di raggio.
Numero di oggetti: circa una decina o due.
Velocità massime: circa 1 m/s
Fisica:
Stato iniziale oggetti comprendente posizione, massa, dimensione, velocità.
Calcolo dell'evoluzione del sistema tenendo conto del movimento (per inerzia),
della sua attenuazione (per atrito di movimento e possibilmente anche atrito di
collisione) per un tempo massimo prefissato o fino alla quiete.
Gestione delle collisioni fra oggetti (trasferimento dell'energia cinetica in
caso di collisione secondo la massa, la velocità relativa e la direzione
relativa degli oggetti in collisione). Precisione nel posizionamento (e quindi
della collisione) dell'ordine di 1/100 di mm.
Non gestione degli effetti di spin degli oggetti.
Gestione delle collisioni con eventuali limiti dell'universo.
Possibilità di ridefinire la geometria dell'universo. Io lavorero' su un
universo aperto ma finito (dimensioni vedi sopra). In pratica un rettangolo (o
parallelepipedo) gestendo le collisioni con i limiti dell'universo secondo le
regole di riflessione (con o senza attrito di collisione). Ma non sarebbe
difficile eliminare i limiti per avere un universo infinito o chiudere
l'universo in un hipertoro (o una hipersfera, anche se la geometria si
complica).
Ovviamente dimensione e massa degli oggetti non cambia.
Il framework potra' essere adattato in maniera da esternare su file l'evoluzione
del sistema dal tempo T0 iniziale fino alla fine della simulazione (durata
limitata o test di quieta). Nativamente l'emulazione non sarà persistente ma
asservita al calcolo di una "animazione" del modello quantizzata in un certo
numero di frame (credo che lavorero' a 10 o 20 frame al secondo).
Da questo poi sta a te cambiare le geometrie che ti serve cambiare (e le leggi
fisiche).
Dimmi se ti interessa. (e se si, lasciami un pochino di tempo dato che ci
lavorero' di notte e nel week-end).


>
 :(( mi dispiace, purtroppo il tuo post mi e' arrivato solo oggi
(lunedi). Non so se per un problema del server o del moderatore :)
Ciao,
Anders


>
 :(( mi dispiace, purtroppo il tuo post mi e' arrivato solo oggi
(lunedi). Non so se per un problema del server o del moderatore :)
Ciao,
Anders
-> it.scienza.informatica (Moderated)
%followup-to
it.scienza.informatica

 lunghezza. E' qui che io non riesco piu' ad andare avanti :((
Non e' la lunghezza della catena o la complessita' in se del grafo che mi
preoccupa. Quello che mi preoccupa e' cosa succede nella "tua fisica" quando ci
sono situazioni in cui due blocchi ne "costeggiano" uno dallo stesso lato.
Poi non sono sicuro di aver capito bene cosa succede se le forze non insistono
sul lato in direzioni opposte.
Spiegami cosa succede in questi casi:
Caso A
[--->][->]
Caso B
[->][--->]
Caso C
+------+
|      |
| ---> |
|      |+-----+
+------+|     |
+------+| <-  |
|      ||     |
| ---> |+-----+
|      |
+------+
Soprattutto per il caso C spiegami bene bene il ragionamento che ti ha portato
alla soluzione.
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556


alla soluzione.
Dunque. Se ben interpreto il disegno, siamo nel caso di una
ramificazione da destra a sinistra, con il blocco a destra con vx=-1 e
i due blocchi a sinistra con vx=3. Ora, e' chiaro che ciascuno dei due
blocchi a destra tende a spingere quello a sinistra. Consideriamo il
primo blocco a sinistra in alto. Chiaramente spinge il blocco a
destra, quindi la loro velocita' risultante dovrebbe essere
vx=(3-1)/2=1. Ma a questo punto sarebbe il blocco in basso a spingere
quello a destra (dato che quest'ultimo avrebbe una velocita' minore),
e cosi' via. Percio' in questo caso entrambi i blocchi di sinistra
devono spingere quello a destra, e la velocita' risultante sara'
(dovrebbe essere) una media delle tre velocita'.
Nel caso invece che la media delle velocita' del blocco in alto e di
quello a destra fosse maggiore della velocita' del blocco in basso, i
primi due blocchi si staccherebbero dal terzo, che rimarrebbe indietro
verso sinistra.
Ciao,
Anders


 primo. Percio':
Intuitivamente vero. Ma se fai la velocità media dei blocchi che si toccano
siamo sempre a 2. Se ragioni come dici tu, allora nel caso precedente il
risultato 2 va ricavato come dicevo io. Ovvero il caso A lo possiamo riscrivere:
+-----++----+
| ->  || -> |
| --> || 0  |
+-----++----+
da cui deriva che la prima freccia e' "locale" e la seconda va "mediata". E i
risultati sommati.

Si ma quale velocità? Per esempio in:
+-------+
|       |
| ----> |
|       |+-----+
+-------+|     |
+-------+| <-- |
|       ||     |
|  -->  |+-----+
|       |
+-------+
se consideri il blocco in alto e quello a destra ottieni una risultante di +2
che quindi non influisce sul terzo blocco e tutti si muovono verso destra di 2.
Ma se fai la media di tutto hai +4/3.
Per questo non credo che "la media di tutto" abbia molto senso.
Pensaci.


 Non so se e' chiaro.
Si, chiarissimo. Hai perfettamente ragione. Infatti io intendevo che 
la media si applicasse solo ed esclusivamente nel caso che i due 
blocchi fossero _forzati_ a muoversi l'uno contro l'altro. Per 
esempio, nel caso B la media non si applica, cosi' come non si 
applica nell'ultimo caso che mi hai esposto (piu' in giu' nella mail, 
verso la fine)  per come l'hai prospettato (infatti i blocchi si 
muovono a velocita' 2, ma il terzo blocco non e' _forzato_ ad avere 
quella velocita': non esercita alcuna spinta sul blocco che ha 
davanti). Comunque il tuo ragionamento e' giustissimo (ed e' lo 
stesso mio), solo che io te ne riportavo direttamente la soluzione 
piu' intuitiva. Mi sono chiesto se ci siano dei casi di moto forzato
in 
cui il risultato non sia la media delle velocita', e mi pare di no. 
Comunque, nel caso ci fossero, segui la tua linea di ragionamento, 
che e' sicuramente corretta.


La media di tutto la intendevo solo nel caso in cui la risultante
delle 
velocita' del blocco in alto e quello a destra fosse minore della 
velocita' del blocco in basso, e la risultante delle velocita' del 
blocco in basso e quello a destra fosse anche minore della velocita' 
del blocco in alto. Ad esempio, prend in considerazione questo 
caso:
|----------|
|  --->   |
|----------||----------|
           |     0    |
|----------||----------|
|  -->    |
|----------|
Con la velocita' del blocco a destra nulla.
In questo caso, secondo te, quale dovrebbe essere la velocita' 
risultante? Secondo me, 5/3, per una sorta di "principio di 
conservazione delle velocita'". In questo modo, rimoltiplicando il 
risultato per il numero di blocchi, si riottiene la somma delle loro 
velocita'. Altrimenti, se si ottenesse un risultato diverso, ci si 
potrebbe chiedere dove siano finite le velocita' mancanti o da dove 
siano arrivate quelle in eccesso. Comunque, se tu hai un'idea 
diversa (forse piu' corretta) non c'e' nessun problema (a meno che 
non dia luogo a contraddizioni): l'importante e' che, visivamente, i 
blocchi si spingano gli uni con gli altri anche se disposti in 
configurazioni molto complesse.
Ciao,
Anders

Anders:
Ho ricevuto la tua e-mail.
Avevo pensato anche io di passare in e-mail, ma non volevo creare problemi a chi
eventualmente stesse seguendo il NG.
Ora tu hai risposto sia sul NG che in E-Mail, ma se io devo risponderti allo
stesso modo ci sono problemi.
Primo: i messaggi sul NG non sarebbero "threaded" ma tutti "Thread Masters".
Questo stesso messaggio non posso mandrlo come reply al tuo!
Secondo: con gli attuali tempi di moderazione (lunghetti invero visto la
scarsità di messaggi che passano) rischiamo di aver rimpallato tre o quattro
volte prima di vedere il materiale in NG e se per caso un messaggio (anche uno
solo) viene respinto dal robot, il thread si compromette ulteriormente.
Pertanto, a meno che il moderatore non mi dica entro subito che ci aggiunge,
anche magari temporaneamente, ad una whitelist, propongo una alternativa:
Passiamo in e-mail punto e basta. Lascio questo stesso messaggio (che spero non
arrivi in NG dopo troppo rimpalli fra noi) come ufficiale invito a chiunque stia
seguendo in silenzio questo thread a contattare me o te per e-mail.
A chi lo facesse spediremo tutti i messaggi e-mail nel frattempo intervenuti e
lo aggiungeremo come destinatario CC.
Dubito che il thread si sviluppi al punto di dover gestire una mail-list.
Dopotutto anche eventuali "ascoltatori" hanno già dimostrato di non avere
l'intenzione di intervenire.
