Re: PvvMud

[Werner Lindgard <wernerl@cs.ucsb.edu>]

hei igjen !

> Serveren har et hirarki av objekter. Klienten vet ingen ting om verdnen.
> 1. Serveren lager en frame som den sender til klienten. 
> 2. Klienten viser denne framen.
Dette er ogsaa litt av det vi har tenkt paa. Det vi i tillegg har tenkt aa
gjoere for aa faa ting litt mer skalerbart, er at en maskin ( host ) som
kjoerer en client ogsaa kan ta over og starte opp en ny server dersom
belastningen paa en server blir for stor. Det er veldig mye dette vi skal
proeve aa teste om fungerer i vaar modell.

> Denne framen er f.eks en UDP pakke som inneholder informasjon om
> posisjonen til viewpointet til brukeren og posisjon og id til potensielt
> synlige objekter. Klienten henter så 3D/mesh informasjonen fra fil eller
> en server som leverer grafikk ved å bruke id feltet. De grafiske objektene
> chashes på klienten slik at når neste frame kommer så ligger de fleste
> objektene i chashen.  
Igjen mye av de samme tankene vi har gjort oss. En annen ting vi har tenkt
for aa spare litt baandbredde er at en del standard objekter ligger lokalt
hos client hele tiden. Dette gjoer det mye enklere med overfoering og
henting av statiske ( evt. dynamiske ) objekter som skal vises. I tillegg
haaper vi at dersom det kan bli flere servere som etterhvert styrer
"verden" saa vil ogsaa ting tilsynelatende gaa relativt fort. Hvordan en
verden skal oppdateres har vi ogsaa tenkt en del paa, men noen av ideene
vaare her ( dvs. de andre sine ) vet jeg ikke helt om vil fungere for en
MUD, men i vaart "chat" tilfelle vil det antakeligvis fungere.

> Frame            = ViewPoint + FrameObjectList 
> FrameObjectList  = {FrameObject}                # En tabell
> ViewPoint        = Transformation 
> FrameObject      = ObjectGeometryId + Transformation + FrameObjectList
> Transformation   = Position + Rotation 
> Position         = x + y + z + w
> Rotation         = x + y + z + Angle
Dette har ikke vi satt opp saa mye paa enda, men vi maa sef. ha det i
tankene......

> ObjectGeometryId  4b
> Transformation  = 4F + 4F = 4*4b +4x4b = 32b
> FrameObjectList  1b  som gir et maks antall children nodes = 256.
> ------------------------------------------------------------------
> Et objekt gir da 37b. Kansje en scene normalt består av ca 100 objekter
> dvs ca 3.7Kb per pakke. 
Hmmm...... Har vi noen muligeter til aa forkorte ned dette. 

> Noen ide om hva en kan anta av bånbredde?
Nope.

> På siden www.pvv.org/pvvmud/work/client_steps.html så har jeg skissert 2
> versjoner til av denne protokollen. Den første inkluderer 1. deriverte dvs
> hastigheten til objektene noe som vil gi en maks størelse per objekt på 37
> + 32 = 69. Den andre inkluderer informasjon om animasjoner som vil gi enda
> større pakker.
Animasjoner har vi ikke tenkt til aa ta med i vaar oppgave for oyeblikket.
Som jeg tror jeg nevnte saa kommer vi til hovedsaklig aa basere oss paa aa
teste ut skalerbarheten til systemet. Stoerrelse paa pakkene vil variere
etter hvor mye som skal overfoeres, og sef. hvor detaljert verdenen er.

> For et objekt så vil det oftes være flere felt i trasformasjonene og
> hastighetsvektorene som er null så en ide vil være å inkludere et bit felt
> for hvert tall som forteller om de er med i pakka eller ikke. Posisjon vil
> nesten alltid være satt så den må med, men for rotasjon og hastigheter vil
> ofte mange verdier være null. En rotasjon i z og bevegelse i y kan f.eks
> kodes som 001010. Der de tre første bitene er rotasjon og de siste 3
> bevegelse men henholdsvis xyz rekkefølge.
Hoeres ikke helt dumt ut. 

> Et annet spørsmål er jo om en trenger float nøyaktighet på posisjon og
> rotasjon?
Det er vel mulig og kode et og annet i en "non-float" type og paa en eller
annen maate transformere dette paa client maskinen, og deretter faa en og
annen floatnoyaktighet. Kodingen vil jo da foere til noen unoyaktigheter.

> Dette er de tankene jeg har gjort meg. 
Virker som vi har tenkt litt i samme baner. Da har jeg i alle fall
mulighet til aa fortelle litt om hvordan ting fungerer dersom vi faar
programmene opp aa kjoere her borte etterhvert. Vet ikke om det blir helt
som du har tenkt, men jeg faar i alle fall gjort meg en del erfaringer med
hvordan ting kan fungere, og gi litt tilbakemelding om dette.

Ok, snakkes !

______________________________________________________

 Werner Lindgård  <wernerl@cs.ucsb.edu>
 Computer Science, Santa Barbara, California 

 6689 El Collegio, Apt. #101
 Goleta
 CA 93117
 USA
 Phone: (805) 562 8623
______________________________________________________
Newton was wrong. 
It's not gravity, it's just the world that sucks.