Virtual Reality: Akustiken. Ett prototypsystem för ljudsimulering

Klicka för att visa original titelblad, sammanfattning, förord m.m.

Amiga är ett registrerat varumärke av Commodore-Amiga Inc.

"dbx" är ett registrerat varumärke av dbx, Newton, Mass. USA, en division i BSR NA Ltd.

Dolby A, B, C, S, Sr är registrerade varumärken av Dolby Laboratories Inc., San Francisco, California

Dolby Sorround är ett registrerat varumärke av Dolby Laboratories Inc., San Francisco, California

Lund University LUP Student Papers, Virtual Reality: Akustiken. Ett prototypsystem för ljudsimulering

Till mina nära och kära

Sammanfattning

För närvarande är det mycket vanligt med video-ray-tracers till persondatorer, men audio-ray-tracers finns inte i samma mångfald. Kommersiellt finns inga sådana tillgängliga till rimliga priser. Detta faktum plus dagens ökade in- tresse för VR-miljöer indikerar ett starkt behov av en audio-ray-tracer som både är snabb och lätt att använda. Visualiseringen som finns i alla video-ray-tracers bör ha en akustisk motsvarighet i en audio-ray-tracer, och denna kallas audialisering (auralisering).

Vidare kan ett audio-ray-trace program vara ett mycket bra hjälpmedel för förbättring av akustiken i redan existerande rum. För ett sådant hjälpmedel ställs inte de krav pårealtidsfeedback som uppstår när vi önskar en god VR-miljö.

Denna rapport är en grundlig genomgång av det akustiska kriteriet- 3D-Audio - i den starka VR-miljö definitionen. En kort introduktion av ljud, ljuduppfattning och audiobehandling tjänar som inledning. Avslutningsvis för denna, definierar och summerar jag VR-miljöer. A finis diskuterar jag arbetet med 3D-Audio gentemot dessa aspekter, och mot effektiviteten av människa-dator-interaktion, samt de algoritmer som är knutna till ljudfältsgenerering. Även auralisering diskuteras, och en möjlig lösning för denna presenteras.

Abstract

This report is a thorough look at the acoustic criteria - 3D-Audio - the strong definition of VR-environment. A brief introduction to sound, the human ear and audiohandling is given, and to conclude this introduction, a definition and summary of VR-environments. Finally I discuss the implementation of 3D-Audio with regard to these aspects, and to the effectiveness of human-computer- interaction and the algorithms in the sound-field-generation module. As a conclusion, the auralization stage is discussed and a possible solution is presented.

Förord

Denna rapport behandlar ett examensarbete utfört under första halvåret av 1994 vid en $\mu$ -dator av typen Amiga. Examensarbetet är en grundlig prolog till akustiska VR-miljöer. Tonvikten har lagts påmänniska-dator-interaktion och algoritmeffektivitet för syntetisering av ljudfält.

Jag tackar mina föräldrar för deras tålamod med mig och för deras värdefulla hjälp i svårare stunder genom åren.

Jag vill tacka Michael Dovits och Lars Malmborg för att ha sporrat mig med intressanta idéer och försöksprojekt genom åren. För den första högkvalitativa utskriften upplät Lars sin HP-550C.

Jag vill tacka Lars Holmgren för hans presentation av video-ray-tracern Lightwave.

Jag vill tacka Roberth Frank som delgivit mig mycket konstruktiv kritik, och hjälpt mig med korrekturläsningen av huvudskriften. Vitsen påsidan 17 har han ocksåbidragit med.

Jag vill tacka min handledare i akustik, forskningsingenjör Erling Nilsson, för hans klargöranden i ämnet och för att ha dämpat mina ambitioner i tid.

Slutligen vill jag tacka min handledare vid institutionen för Datalogi och Numerisk Analys, Sten Henriksson, för hans värdefulla kunskap och synpunkter.

Malmö November 1994 Denis Tumpic

Ljudets & Örats Principer

It has long been an axiom of mine that the little things are infinitely the most important.

Sir Arthur Conan Doyle

Här följer en kort introduktion till ljudets och hörselns natur. Grunden till att jag skrivit detta kapitel är främst att de som inte har någon hum om hur ljud fungerar ska kunna bilda sig en uppfattning om detta. För min fortsatta flytande plädering i de andra kapitlen bör även "gamla rävar" i akustik läsa detta kapitel.

Jag har försökt att ta upp de mindre uppenbara problemen i akustiken för att visa vilka problem som verkligen existerar. För en mycket god genomgång av akustik (främst då i rum), hänvisar jag den hugade läsaren till "Room Acoustics" av Heinrich Kuttruff. För örats principer rekommenderar jag "Encyclopedia Britannica", eftersom den har ett rikligt informationsstoff inom ämnet. Vidare är "Audio-Engineering Handbook', sammanställd av K. Blair Benson, mycket bra och nyttig läsning för de som även är intresserade av den tekniska aspekten.

Ljudets Natur

Ljudet är inte helt olikt ljuset till sin natur. Skillnaden är att det handlar om förtätningar och förtunningar av ett medium istället för en ständig ström av fotoner. Ljud fortplantar sig longitudinellt i motsats till ljusets tranversella utbredning, vilket visas i figuren nedan.

Transversell våg överst och longitudinell våg nederst, l är våglängden.

Ständigt i vardagslivet utsätts vi för olika former av ljud. Det kan vara djupa toner som får lösa föremål att vibrera. Dessa toner brukar kallas infrasoniska toner och våra öron uppfattar dem inte så bra, utan det är kroppens periferi som vibrerar lätt. Detta fenomen har alla, som blivit omkörda av en större lastbil när de är ute och cyklar, märkt. Speciellt när lastbilen ska accelerera uppkommer detta fenomen. Till de infrasoniska tonerna tillhör alla rena toner under 20 Hz. Med rena toner menar jag toner bestående av en enkel sinusvågform.

Fladdermusens (Chiroptera) sätt att spåra byten är mycket imponerande, och kan lättast jämföras med en radar (RAdio Detecting And Ranging). Till skillnad mot radarns radiovågor, utsänder fladdermusen en hög ton i dess färdriktning, för att utröna bla om där finns ett hinder eller byte i dess väg[1,2]. Denna höga ton kallas ultrasonisk ton, och alla rena toner över 20 kHz kallas så. Mellan det infrasoniska och det ultrasoniska frekvensområdena ligger människans normala hörsel.

Det är därför ingen slump, att High-Fidelity definieras bla av att inspelat material ska kunna återges med en rak frekvensgång i intervallet 20 Hz- 20 kHz [3, 4]. Med rak frekvensgång menas att små fluktuationer i närliggande frekvensområden är tillåtna, och att den maximala avvikelsen från medelvärdet högst får uppgå till 3 dB. Decibel är en relativ enhet och definieras i detta fallet av $10\log(\frac{P_{ut}}{P_{in}})$ , där P står för akustisk effekt.

I naturen förekommer flera ljudkällor. Egentligen är nästan allt en liten ljudkälla på något vis. En människa som talar är givetvis en ljudkälla, men även om hon är helt tyst, genereras ljud av hennes kropp. Dessa ljud har dock mycket mindre energiinnehåll än talet. När en symfoniorkester spelar i forte fortissimo, förkortas fff i notskrift och betyder att orkestern ska spela oerhört ljudligt, genereras endast ca 2.5 W akustisk effekt. Vårt eget tal, som i detta sammanhang är väl överröstat av symfoniorkesterns basunerande, brukar uppnå till ca 25 µW. Det är helt klart att vi omges av en aldrig sinande ström ljud. Allt från grannens lekande barn till blodets sus i öronen.

Några typiska ljudtryck för vanliga ljudproducerande objekt. Avstånden inom parantes anger mätavståndet.

Ljud brukar i allmänhet bestå av många sammansatta toner som ger dess karaktär. Dessa toner har olika amplitud (intensitet) och olika faslägen för att bygga upp ljudet. För att vi lättare ska kunna handskas med frekvensbegreppet, delar vi upp frekvensbandet i oktaver.

Ordet oktav kommer från den västerländska musikens värld och innebär en fördubbling av frekvensen. Vår musik lever i grund och botten i en modulo-8 värld - C1 D E F G A H C2 (okta = 8). Rent matematiskt skulle det nog varit modulo-7, men musiker använder inte noll som startreferens. Det bör tilläggas att vi här bortser från de "svarta tangenterna", eftersom de tillkom senare. Akustiska mätningar brukar delas in i oktavintervall, eftersom det då blir en naturlig och enkel framställning när vi betraktar musikmaterial.

Vid en frekvensanalys (fourieranalys) av ljudet kan vi visualisera dess karaktär. För att spjälka ett ljud på dess inneboende information, kan vi låta ett filter av bandpasstyp operera på ljuddata som kommer från en mikrofon. Dessa bandpassfilter ska ha disjunkta (ej överlappande) gränsfrekvensområden, och unionen av deras frekvensområden ska fylla ut hela frekven sområdet vi betraktar, om vi vill ha en god visualisering (figur 1.3). För förtydligandets skull är bandpassfilter ett filter som kraftigt dämpar alla frekvenser som är över den övre gränsfrekvensen och under den undre gränsfrekvensen (se även resonans). Filter är för övrigt ett stort område som jag inte går in på i detalj. De som vill veta mera om filter kan läsa om detta i telekommunikationsböcker.

Låter vi integrera energin i de spjälkade frekvensbanden över en bestämd tidsperiod, som ej behöver vara lika för något filter, kan vi visualisera informationen på ett relativt enkelt sätt. Denna visualisering kallas ljudspektra och kan vara ett lämpligt sätt att visa hur ett ljud är uppbyggt, speciellt då vid ljudproduktion.

En möjlig frekvensanalys av ett ljud i en given tidsrymd.

Ljudets Utbredning

Ljudets utbredning är inte helt trivial. Även om det tycks vara av en enkel natur, bör det påpekas att det handlar om mekaniska svängningar. Läsaren ombedes att ha detta i åtanke vid fortsatt läsning. Vidare bör det påpekas att ljud inte kan fortplanta sig i vakuum, eftersom vakuum innehåller ingen materia som kan utöva tryckförändringar för ljudets utbredning. Eftersom vi omges av enorma mängder material som har olika aggregationstillstånd (vid olika tryck och temperatur), gör detta det svårt att göra generella korrekta beräkningar och antaganden. Emellertid så finns det ett par grundläggande principer som även finns hos ljus.

Vi antar att vi har en rundstrålande källa, vilket innebär att källan strålar ut sin energi likformigt i alla riktningar. Vi låter den sända en kort impuls, och med hjälp av mikrofoner registrerar vi energin som mottages vid olika distanser från ljudkällan. Om vi gör detta försök ute i det fria utan större objekt som stör våra mätningar, kommer vi att finna att energin avtar kvadratiskt med avståndet.

Vidare kan vi utan större förbehåll säga, att så länge amplituden inte är extravagant, kommer förtätningarna och förtunningarna att propagera i konstant hastighet. Ljudets fortplantningshastighet i luft vid normal luftfuktighet och $20^o$ C, är ca 343 m/s. Denna hastighet är något blygsam i jämförelse med ljusets ca 300000000 m/s i vakuum. Ljudets hastighet är dock ändå mycket snabbare än min bil trots utförsbacke, medvind och hemlängtan.

Reflektion & Absorption

Alla har vi någon gång blivit förbryllade av att se ljudkällan, och höra dess ljud komma från ett helt annat håll. Vid extrema förhållanden kan detta hända. Direktljudet absorberas så mycket att reflektionerna dominerar ljudbilden. Detta medför att ljudkällan tycks delokaliserad, och det känns som om ljudet inte har någon kropp. Den naive tänker säkert att ljudet är som ljuset vid reflektion och absorption, men det är en mycket grov uppskattning som endast fungerar i mycket enkla fall. När det gäller ljudreflektion så beror den reflekterade ljudvågen på infallsvinkel, ytans beskaffenhet, reflektionsobjektets massa och ljudets karaktär.

Geometrisk tolkning av Vågfrontens utbredning i reflektion. ljudstrålarnas riktning.

Att reflektionen beror på ljudets karaktär innebär att den är frekvens- och fasberoende.Vidare har vi det stora problemet att plana ljudvågor oftast inte existerar i naturen. En plan ljudvåg beror bara på tid och en riktning. Detta innebär att vi aldrig kan ha parallella ljudvågor. Därmed är hypotesen att använda ljusets natur i beräkningar av ljudets utbredning något missvisande.

Interferens

Låt oss betrakta två identiska ljudkällor som utsänder koherent information. Vidare är dessa ljudkällor godtyckligt utplacerade i rummet. Enligt principen för superposition, som även fungerar för elektriska signaler, adderas de bidragande delarna från ljudkällorna linjärt för varje punkt i rummet. Med punkt menar jag här ett litet begränsat område som kan innehålla den högsta frekvensen i ljudets karaktär. Märk att detta område bla beror på mediat ljudet existerar i.

Två superpositionerade signaler med samma amplitud och frekvens men olika inbördes faslägen. Notera speglingen av den totala fasen efter 180º.

Interferens brukar delas in i två grupper, den konstruktiva och den destruktiva. När det handlar om konstruktiv interferens samarbetar de två ljudkällorna i den givna punkten vi betraktar. De svänger i fas och ger upphov till en förstärkning av signalen. Den destruktiva interferensen som uppkom mer när ljudkällorna inte svänger i fas ger en dämpad signal i den givna punkten, vilket förtydligas i figuren ovan. I naturen uppkommer detta fenomen naturligt av att direktljud och reflekterat ljud interfererar. Interferens kan användas i praktiskt syfte och tjäna som bullerdämpare. Den enkla idén är att låta placera mikrofoner i närheten av bullerkällan, och på ett lämpligt avstånd placera en högtalare, som med fasförskjuten signal släcker ut bullerkällan. Denna idé kallas aktiv ljuddämpning. Trots att det verkar tämligen enkelt att bygga en prototyp så har vi några problem att brottas med. Det första problemet är att vi tillför ljudenergi till systemet. Eftersom den tillförda energin inte kan användas selektivt (se plana ljudvågor), kommer vår prototyp att ge upphov till förstärkningar i vissa punkter. Buller är oftast av en komplex ljudkaraktär som beror av tiden, och detta ger oss ytterligare ett svårt problem. Det är inte helt omöjligt att göra aktiva ljuddämpare, men med dagens teknologi är det emellertid för dyrt i jämförelse med passiva ljudabsorbenter.

Diffraktion

Detta fenomen är enkelt att förstå men dess natur är mycket komplicerad. Fenomenet uppkommer när ett ljud avböjs runt ett objekt. Vid diffraktion blir vågfronten distorderad och resultatet blir att vi t.ex. kan höra runt hörn. Hur mycket ljud som diffrakteras beror på det skuggande objektets utformning och ljudets karaktär. Lågfrekventa komponenter i ljudkarakteristiken blir inte störda av småobjekt. Däremot blir de högfrekventa komponenterna, som har mycket mindre våglängd, lätt störda av diverse skymmande objekt i vägen. Alla har vi någon gång sett hur vattenvågor med långa svall inte berörs av bojar som råkar vara i vägen.

Diffraktionsfenomenet använder vi inte när vi gör en geometrisk tolkning av ljudutbredningen, eftersom den geometriska tolkningens huvudpostulat är de räta linjernas natur. När det gäller komplexa ljudkarakteristika med brett frekvensomfång, och om ljudkällorna inte är koherenta, kan även interferens bortses ifrån[5].

Refraktion

Ljud som färdas långa sträckor kommer med all sannolikhet att genomgå olika temperatur- och/eller strömningsförändringar. När ljud färdas mot förändringens gradient, blir ljudvågorna böjda och vi kan närmast likna resultatet vid en optisk lins. Rent naturligt uppkommer refraktion när det är temperaturinversion/medvind och temperaturlapse/motvind. När vi behandlar rum på under 10000 m³ kan vi bortse från dessa effekter, eftersom temperaturskillnaderna inte uppgår till några hela grader, och vind vanligtvis inte brukar förekomma i slutna rum. Det bör tilläggas att människans kroppsvärme, som bildar ett hölje runt hennes kropp [6], har de tillräckliga temperaturskillnader som krävs, men att dess utsträckning i normalfall är så begränsat att det inte ger någon större effekt på ljudupplevelsen.

Resonans

Om vi låter en pådrivande kraft verka på ett svängande system, kommer systemet att svänga i takt med den pådrivande kraften. När vi kopplar bort pådrivningen kommer systemet att anpassa sig till den frekvens som är naturlig för systemet. Denna frekvens kallas resonansfrekvens, och är en mycket viktig del i beräkningar av alla svängande system. Rent teoretiskt kan nästan allt i den fysikaliska världen skrivas om till en taylorutveckling. Trunkerar vi allt över andra ordningens termer i denna taylorutveckling, kvarstår en andra ordningens differentialekvation som vi vet är ett svängande system. Denna grova uppskattning indikerar att allt i naturen är ett svängande system. Ett svängande system kan beskrivas på många olika sätt, men det vanligast förekommande sättet är med kvalitetsfaktorn Q.

Beräkning av Q-faktorn (3 dB är halva max effekten).

Vikten av kvalitetsfaktorns betydelse i tex radiomottagare, högtalare och musikinstrument är mycket stor. För att radiomottagaren ska ha bra selektivitet (urvalsförmåga), krävs ett högt Q-värde i selektormodulen (hf-steget), som extraherar lyssningsstationen ur radiovågorna. Högtalarkonstruktören ska i allmänhet bygga konstruktioner med ett lågt Q-värde, för att förhindra färgningar av ljudbilden från dem. När det gäller musikinstrument är det instrumentets karaktär som ska förstärkas, och det är musikinstrumentets skapare som in i det oändliga mejslar och slipar instrumentet, tills det uppfyller de rätta resonansegenskaperna.

Direktivitet

Sändare som är rundstrålande har ingen egentlig riktning på sina sändarvågor, eftersom de sprids likformigt. Allt detta gäller även för mottagare, men med den skillnaden att ljudvågorna är motriktade istället för frånriktade. De flesta sändare är dock inte rundstrålande, utan har en i viss mån distinkt riktning på informationen de sänder ut. Riktningen är dessutom frekvensberoende, vilket kan ses i illustrationerna nedanför. Detta gör det klart att låga frekvenser tenderar att vara mycket mer rundstrålande än höga. Något som ytterligare försvårar beräkningsarbeten är att direktiviteten beror på hur sändaren är utformad.

Efterklang

Det första lyssnaren får höra är direktljudet från ljudkällan, som färdas med rak kurs mot hennes öron. Detta är lagen om första vågfronten, och L. Cremer var den första som insåg och formulerade detta faktum. Efter direktljudet kommer de tidiga reflexerna från tak, väggar, golv och diverse stora objekt. De tidiga reflexerna har en längre sträcka att färdas och når våra öron i ett senare skede, typiskt inom de första tiondelssekunderna. Kommer det en mycket stark reflektion efter de första tiondelssekunderna, betraktar vi det som ett eko. Eko är, i motsatts till efterklangens odistinkta luddiga signal, en distinkt uppfattbar ljudsignal.

Ljud som anländer senare och inte är reflexer i egentlig mening (högre ordningens reflexer), betraktas som efterklangsljud. Tiden för efterklangsljudets längd, som är en viktig del i akustiska beräkningar, kan beräknas med hjälp av Sabine's formel. Det finns flera olika typer av formler för beräkning av efterklangstiden, men den nämnda är den som bäst tjänar sitt syfte i generella modeller. När vi beräknat efterklangstiden ( $T_{60}$ ), kan vi använda olika akustiska kvalitetskriterier på betraktningsrummet. Dessa kvalitetskriterier använder sig av rummets impulssvar, som i visualiserad form kallas reflektogram och är en funktion av ljudtrycket med hänseende på tiden (se figur 1.10).

För att få rummets impulssvar låter vi generera en mycket kort energipuls, diracpuls. En diracpuls är en puls vars hela energi finns i startögonblicket - se appendix B för hela definitionen. Denna puls kan med god approximation åstadkommas mha en pistol eller ett handklapp. De mest användbara kvalitetskriterier är Clarity, Deutlichkeit, Rise Time och Lateral Efficiency. Dessa är subjektivt framtagna på experimentell väg, men är mycket användbara vid akustiska byggen.

Möjligt impulssvar från ett rum. Td är direktljudet och Tr är efterklangens inträdande vilket är en suddig gräns, och $T_{60}$ är efterklangstiden (reverberationstiden). Se bilaga B för formler.

Dispersion

När ljud propagerar i media som inte förmedlar frekvenserna i samma hastighet uppstår dispersion. Detta fenomen framträder oftast när ljud färdas i viskösa vätskor och tjocka gaser. I dessa media kommer ljudhastigheten att öka med ökad frekvens, och märk att detta är i direkt motsats till optisk dispersion i vanliga glasmedia.

Doppler-effekt

Hittills har vi endast betraktat stillastående ljudkällor och ljudmottagare. Låter vi ljudkällor och mottagare vara rörliga objekt i rummet, kommer ljudvågorna att förtätas i färdriktningen. Denna förtätning medför att ljudkarakteristiken transponeras upp i frekvens. I avlägsningsriktningen kommer ljudvågorna att bredas ut och en frekvenstransponering nedåt blir då följden. Även för ljus uppkommer detta fenomen, och det är bla därför som vi kan utröna om en himlakropp färdas mot eller ifrån oss.

Doppler-effekten är uppkallad efter den österikiske fysikern Christian Doppler. Han märkte att visslan från tåget som lämnade honom från stationen ändrade sin ljudkaraktär. Emellertid var det inte enbart doppler-effekten han hörde utan refraktion samexisterade eftersom det finns turbulenta strömningar runt tåget vid färd. Dessa turbulenta strömningar ska jag inte gå i närmare detalj på, eftersom det är allmänt accepterat att de är kaotiska system, och beräknings- kraften som behövs för att lösa sådana numeriskt är enorm.

Upplevelse av Ljud

I det vanliga vardagslivet är vi inte intresserade av ljudkvaliteten som når våra öron. Det är vid lyssning av musik och tal när vi besöker föreläsningssalen, operan, teatern eller bion som vi kräver en viss ljudkvalitet. Här följer några kriterier, valda delar av [7], som lyssnaren kan använda sig av vid karakterisering av ljudkvaliteten.

Klarhet (Clarity)

Höga betyg i denna klass kräver ett akustiskt system som återger ett brett spektrum av frekvenser, har rak frekvensgång och låg ickelinjär distortion. Det ickelinjära distortionskriteriet ska beaktas när vi betraktar reproducerande system som högtalare och dyl.

Ljushet, Skarphet & Fyllighet

När det akustiska systemet återger höga frekvenser med lite överdriven klang, upplevs detta som ljushet (brightness). Vid ännu mer överdriven klang utmynnar upplevelsen i skarphet (sharpness), i viss mån skrikighet. Det motsatta, när de låga frekvenserna blir dominerande, kallas fyllighet (fullness).

Rymdkänsla & Närhet

Dessa kriterier är nästan självförklarande - rymdkänslan (spaciousness) ökar om det högfrekventa materialet (typiskt område är 500 - 4000 Hz) som når våra öron, har betydande skillnader (låg korrelation). Ju mindre skillnaderna är desto närmare tycks ljudkroppen komma lyssnaren.

Högljuddhet (Loudness)

Detta kriterium är självförklarande men det ska inte förväxlas med skarphet eller betraktas som en mycket plågsam upplevelse.

Hörselorganet

Här kommer en kortfattad introduktion till örat och dess anatomi. Vidare har jag en liten utläggning om den senare tidens ljudkomprimeringsteknik.

Örats Anatomi

Människans hörselapparat. Ljudet koncentreras i hörselgången för att sedan förstärkas i mellanörat och slutligen omvandlas till elektriska impulser i innerörat. Innerörat innehåller även balansapparaten.

Öronen är våra antenner för mottagning av ljud, och kan uppdelas i tre huvuddelar (se figur ovan). Ytterörat, vars form liknar en trumpet, agerar som en riktad mottagarförstärkare. Läsaren bör erinra sig trumpetens direktivitet från föregående sektion. Förstärkningen beror på att en stor ljudtryckyta vid ytterörat pressas ner till en liten ljudtryckyta vid innerörat, och eftersom energin är samma, men mera koncentrerad, blir det en förstärkning av ljudet (trycket ökar med minskad area). Enligt Shaw [8], blir frekvenser över ca 2 kHz både reflekterande och resonanta i ytterörats komplexa struktur, vilket medför en färgning av det mottagna ljudet.

När ljudvågorna når trumhinnan, efter det att de har blivit diffrakterade av huvudet och färgade av ytterörat, omvandlas lufttrycksförändringarna till vätsketrycksförändringar i mellanörat, för att sedan omvandlas till elektriska nervimpulser i innerörat som skickar signalerna vidare till hjärnan för analys. Våra öron är mest känsliga runt 4 kHz området och minst känsliga i basområdet, vilket visas i figur 1.12. För ytterligare läsning rekommenderar jag "Encyclopedia Britannica" [9].

Hörselsnäckorna får inte sin information enbart från ytteröronen, utan vårt kranium tillhandahåller en stor portion av ljudet, eftersom ben är en god ledare av ljud. Ett enkelt försök är att bita i ett mekaniskt armbandur, och man kan "höra" tickandet.

När vi lyssnar med hörlurar finns inte extrainformationen från denna benkonduktivitet och ljudbilden känns en aning "tam", men för den skull inte helt utan klös. Det egna talet färdas i huvudsak denna väg genom kraniet. Därav motviljan att höra sin egen röst efter inspelning på band. Ljudet färgas mycket starkt och på olika sätt.

Något som ytterligare fördjupar känslan av ljudupplevelsen, och som inte kommer med vid hörlurslyssning, är när vi känner ljudet i magen, speciellt mycket låga toner med högt ljudtryck. En faktor som de flesta inte känner till eller inte tänker på, är när vi efter en stunds utomhusvistelse i kyla går in och värmer oss. För att njuta fullt ut, börjar vi lyssna på lite musik. Det som då upplevs är att allt låter skräp, eftersom våra trumhinnor är styva efter utomhusvistelsen. Det finns ytterligare orsaker till att det låter som det gör, men den största orsaken är den nämnda. Vid alla större klimatförändringar uppkommer detta fenomen men styrkan av upplevelsen är mycket individuell.

Det ljudtryck som krävs för att örat ska uppfatta olika frekvenser med samma intensitet som en referenston på 1 kHz. Dessa kurvor kallas phon-kurvor. Frihand från International Organization for Standardization, Recommendation R226.

Maskning

Ljudnivån från en ljudkälla som interagerar med andra ljudkällor, kommer att färgas av dessa. Denna färgning kallas maskning, och grundtonen för de interagerande ljudkällorna bestämmer var i frekvensbandet maskningen har störst effekt. Grundtonens övertoner bidrar med maskning i högre frekvenser, och undertonerna, som är färre och mera dämpade, bidrar i de lägre frekvenspartierna.

Detta är en förenklad bild av det hela, eftersom komplext ljud, som inte kommer från musikens värld, inte har en distinkt grundton med harmonisk natur. Det kan kännas lite förvirrande att ett ljud har en odistinkt grundton, och här kommer en förklaring. En grundton kan definieras som den första frekvens som uppkommer i en total frekvensanalys av ljudet. Låter vi grundtonen bero på tiden (små tidsintervall som är mindre än ca 30 ms), vilket det oftast blir i komplexa sammanhang, kommer grundtonen att vara odistinkt.

När det gäller rent musikaliska ljud, är den senare framställningen något överflödig, eftersom de flesta ljud med odistinkta grundtoner är dissonantiska och ej möjliga att använda i "riktiga" musikaliska stycken. De harmoniska övertonerna till grundtonen kan vara starkare än grundtonen själv, och för alla musikinstrument är dessa övertoner mycket viktiga. Något som ytterligare färgar instrumentets ljudkarakteristik, är om den starkaste övertonen har konstant energi, oberoende av grundtonen (formanter). För uttömmande informationsläsning av musikinstrument hänvisar jag den intresserade till [10,11].

Hörbarhetströskel för olika frekvenser med (a) isolerat, (b) smalbandsljud (400 ± 50 Hz) på 80 dB, och (c) ren 400 Hz ton på 80 dB som masknings ljud. Frihand från Donald B. Hall, Musical acoustics: An Introduction, Wadsworth, Belmont, CA1980.

Maskningseffekten är inte alltid oönskad, eftersom den kan dölja värre distorsion som är mycket mer dissonantisk i musiksammanhang. När ljudkällorna interagerar i samma tidsdomän och frekvensdomän kallas det simultanmaskning. Det är klart av tidigare resonemang, att ljud med höga lågfrekvenskomponenter lättare stör ljud med höga högfrekvenskomponenter än tvärt om. Oftast är det så att ljudkällorna inte agerar i samma tidsdomän, och då kallas det tidsmaskning. Vi har två typer av tidsmaskning, den första är framåtmaskning och den andra är bakåtmaskning. Framåtmaskningen resulteras av effekter som är kvar efter fysisk påverkan på våra öron. Alla har vi någon gång blivit utsatta för ett mycket starkt ljud, vilket givit oss en kort tidsperiod med lätt dövhet.

Exemplet är kanske i överkant men själva principen och verkningarna finns där hela tiden. De är emellertid inte lika uttalade som i extremfallet. Eftersom vår hjärna processar information parallellt och i olika hastigheter inträffar det bakvända också. Detta kan kännas lite konstigt för några läsare, och här kommer en förklaring. Speciellt om det senare ljudet är mycket starkare än det föregående, kommer neuronerna [12] att vilja "panik behandla" det starkare ljudet, vilket medför att de "glömmer" det svaga ljudet.

Maskning har i dagsläget faktisk praktisk användbarhet i ljudprodukter. Exempel på detta är Philips DCC (Digital Compact Casette) och Sonys MD (Mini Disc). För att lyckas komprimera data på ett effektivt sätt utan förluster i digital form, kan vi bla använda Huffmankodning, som komprimerar data med upp till 90% beroende på dataflödet.

När det handlar om ljud och bild kan vi tillåta en viss förlust av orginaldata, för att få ännu högre kompressionsgrad. Vi kan då använda oss av fraktal kompression, men denna teknik är väldigt långsam om vi ska kunna göra realtids inspelningar på mediat. Det som återstår är en idé som är både effektiv och säker.

Det fabrikanterna kokat ihop, är att låta uppdela frekvensbandet och analysera delarna i jämförelse med varandra och beräkna vilka frekvensband som är informationsbärande. Tricket är emellertid att ta bort onödig information i informationsbärarna, som kanske inte hörs eller syns. Märk att jag skriver KANSKE, eftersom de kriterier denna utgallringsprocedur beräknar efter är mycket individuella. De som inte är så kräsna på hur det låter och egentligen aldrig hört på musiken de spelat upp på sin stereoanläggning, tycker säkert att det låter likadant. Emellertid finns det en betydande mängd människor som älskar musik och ljudlandskap över mycket annat, och dessa är mycket kräsna på ljudkvaliteten och kan lätt höra skillnader.

Akustisk Reflex

Den mindre kända reflexen i vår kropp är den akustiska reflexen. Denna inträder ofrivilligt hos de flesta människor när ljudtryckvågor över 80 dBA når deras öron. Reflexen är antingen ett skydd för våra öron mot starka ljud, eller mot vårt tuggande och talande. Vilket av dessa två skydd reflexen är till för är medicinarna inte ense om, men min egen uppfattning är att båda var för sig är tillräckliga för att naturen ska evolutionera denna lösning. Hastigheten reflexen reagerar på är vid tröskelvärdet ca 150 ms, och för mycket starka ljud ca 10 ms [13].

Problemet med denna reflex är att trumhinnan spänns, vilket medför att förstärkningen sänks (vilket i och för sig är bra), men frekvenskarakteristiken ändras olinjärt (vilket inte är bra). När det starka ljudet avlägsnat sig kommer reflexen att långsamt ge med sig. Svaga ljud (egentligen fullt hörbara när reflexen är helt avslappnad) som kommer inom avslappningstidsrymden (tiden är beroende på bla människa, humör och klimat) kommer inte att höras väl, eftersom reflexen dämpar ljudtrycket med mellan 10 och 30 dB beroende på ljudkarakteristiken.

En rolig funktion har den dock för de som frivilligt kan påverka denna reflex, nämligen att dämpa bakgrundsbrus vid tentaskrivningar eller föreläsningar. Denna "feature" kan till och med dämpa talet från någon påstridig politiker. Även i hemmet kan reflexen göra nytta, vilket illustreras i följande korta vits:

Den bekymrade fru Svensson ringer sin husläkare: Snälla doktorn, det är något fel på min man. Jag kan tala till honom i timmar och efteråt verkar han inte ha hört ett ord!

Doktorn: Det är ingen sjukdom, det är skicklighet!

Tyvärr fungerar inte reflexen för mycket högfrekvensrikt skrik från småbarn, vilkas ljudresurser är enorma när det verkligen behövs. Vid transienta impulsljud (typ diracpuls) hinner inte reflexen aktiveras och det faktum att själv kunna påverka reflexen vid sådana tillfällen är av yttersta vikt.

Audiobehandling

It is the nature of all greatness not to be exact.

Edmund Burke

I detta kapitel har jag skrivit en mycket kort sammanfattning om signalproduktionens utveckling. Detta har jag gjort för att med största möjliga kraft kunna fastslå det digitala mediats starka sida. Avslutningsvis behandlar jag de problem som uppkommer när vi ska processa signaler mha av datorer. Här visar jag de nackdelar som en diskretisering av kontinuerliga signaler har.

Vid diskretisering behövs en "exakt" aritmetik vid beräkningar till skillnad mot den analoga motsvarigheten där vi kan addera och multiplicera mha operationsförstärkare. Observera att "exaktheten" förloras i båda fall. Om det är digitalt sker detta vid omvandlingen från analog signal, och om det är kontinuerliga signaler sker det vid beräkningarna.

Eftersom jag bara skrivit om de saker som understryker mitt syfteav examensarbetet, kan framställningen kännas lite korthuggen. Föratt ta upp allt som influerat mig inom detta området torde det krävas enbok. Därför hänvisar jag de som är mycket intresserade av ljudproduktion, till de stora mängder fakta och referenser som finns i "Audio Engineering Handbook", sammanställd av K. Blair Benson.

Analog Audio

I slutet av förra seklet uppfann Thomas Alva Edison en analogljudupptagare, som användaren kunde spela in upp till 30 sekunderljudinformation på. Edisons ljudupptagare graverade ett spår på enfolieklädd cylinder och ljudkvaliteten var förvånansvärt bra.Senare uppfann den danske uppfinnaren Valdemar Poulsen den förstamagnetiska ljudupptagaren. Ljudinformationen spelades in på en ståltråd och lät bättre än Edisons maskin, eftersom den elektriska styrkanvar högre från magnetfluktuationerna än från Edisons graverfluktuationer. Alltsedan dess har denna teknik förädlats till att återge ljudmed mycket god kvalitet, för att det ska kännas riktigt naturtroget.

De första apparaterna var i mono, en kanal ljudinformationtillgänglig, vilket visade sig vara otillräckligt för att få en braljudupplevelse. Detta insåg de flesta som arbetade med utveckling avanalog ljudreproduktion, och det tog inte lång tid förrän stereoinspelningar gjordes. För att få en rymdupplevelse av det inspelade ljudet,ska man kunna återge höga frekvenser vid uppspelning, allt i enlighetmed örats uppfattning av distans och riktning som beskrevs i förrakapitlet. För att öka det blygsamma (i dagens mått mätt) frekvensomfånget på de tidigare maskinerna behövdes nytänkande, eftersom ståltråden var en aning opraktisk. Detta var inte BASF (Badische Anilinund Soda Fabrik) sena att ta vara på. Redan 1928 hade de en prototypklar av dagens rullband, som då bestod av järnkarbonyl på pappersbas. Dessa band med magnetiskt skikt har sedan används för både ljudinspelningar och lagring av data från datamaskiner. Problemet är attmediat är sekventiellt, och söktiden för att hitta ett stycke ljud ellerdata är ibland mycket frustrerande.

För att underlätta ljudbehandling gjorde tillverkarna maskinermed flera kanaler. I dagsläget finns bandspelare från 1 till 96 kanalerför inspelning av ljudinformation eller styrsignaler. Säkerligen finnsdet produktionsstudior med ännu häftigare bandspelare, men de flestamusikproducenter behöver endast 32 kanaler eller färre.

För att fullständiggöra High-Fidelity definitionen, ska dynamikenav ljudtrycket kunna återges utan brus och distortion. Vidare skaefterklangen approximeras till den bästa möjliga grad, och vidflerkanalsinspelningar ska de inbördes olikheterna bevaras tillfullo [3,4].

Dynamiken för de bästa inspelningsstudior är omkring 140 dB (Pukstudio i Danmark), vilket kan tyckas överflödigt eftersom de flestapopulära musikformer har ett mycket litet dynamikomfång (typiskt mindre än 20 dB). Emellertid är en del seriös musik mycket dynamisk, ochkräver den höga dynamiken för att både få med de mycket starka partierna (fff = forte fortissimo), och de mycket svaga (ppp = piano pianissimo). Om vi verkligen vill höra den totala ljudupplevelsen, bör vi ienlighet med tabell 1.1 använda oss av ett reproduktionssystem med ca 130 dB dynamiskt omfång. För normala människor är detta inte ettnödvändigt måste, och knappast behövligt i varje situation. Men förtillfälliga ljudupplevelser, som tex i ett planetarium med $180^0$ filmduk, kan det vara mycket givande.

Magnetband har en inneboende gräns för maximalt möjliga dynamikomfång, som för närvarande ligger omkring 80 dB med de bästabandspelarna. För att öka dynamikomfånget kan vi låta ljudetpassera en kompressor innan det blir inspelat på band. Det finns olikasystem för kompression och några exempel är Dolby A, B, C, S, SR samtdbx. Dolby brusreduceringsystem komprimerar olinjärt i frekvensbandet vilket visas i figur 2.1. Däremot har Dolby SR dynamisk olinjärfrekvensbandsuppstyckning, och påminner lite om borttagning avmaskat ljud (se förra kapitlet om maskning), fast systemet tar intebort informationen, utan förstärker den över bandets brusnivå, ellerdämpar den under distorsionsnivån.

Det sista exemplet, dbx, har en linjär kompression över helafrekvensbandet och för alla signalnivåer. Problemet med att ta allt iett frekvensband är att basen tenderar att fluktuera (pumpa), mensenare digitala konstruktioner kringgår detta problem. För att sedanlyssna på det komprimerade materialet behövs en omvänd procedur,vilket kallas expansion. Märk att denna kompression/expansion intekomprimerar/expanderar data i frekvens- eller tidsväg utan i dynamikväg (jfr. med förra kapitlet om maskning).

Kompression/expansion av signaler, den övre grafen visardbx type I 1:2:1 companding och den nedre visar Dolby B. För dbx ärcompandingen linjär i hela frekvensbandet men för Dolby B är denfrekvensberoende. Dolby B grafen är frihandsavritad från "AudioEngineering Handbook", sammanställd av K. Blair Benson.

Digital Audio

Även om digitala media verkar nya, har de funnits sedan 1961, och teorin har funnits sedan 1937. Det tog nästan 25 år för forskarna attforma praktik av teorin och i dag kan vi "njuta" av det digitala ljudet. Fördelen de digitala lagringsmetoderna ger oss, är att det blir lättare att hantera inspelad information. Märk att det inte blir lättareom vi vidhåller det sekventiella bandmediat och därför behövs ettsmartare sätt att lagra data. För att öka användbarheten kan vilagra data på en cirkulär skiva. En ytterligare fördel vi får när vigör detta är att vi minskar slitaget på mediat. Rent mekaniskt är dennalösning lika enkel som en skivspelare, men toleranserna är betydligtsträngare. Vikten av att ha mycket få mekaniska detaljer i konstruktioner är stor, eftersom mekaniska tillståndsövergångar tar lång tidoch ger ofta hemska egenljud (metall mot metall).

Den vanliga skivspelarnålen, som försöker följa en kors modulerad graverad signal på skivan (till vänster), och en mycketförenklad bild av den mindre mekaniska och digitala motsvarigheten(lasernålen) till höger, som försöker följa etsade binära spår.

Det mesta i naturen är kontinuerligt, och ljudvågor är inte någotundantag. Observera emellertid att det uppträder en diskontinuitet närvi "spränger" ljudvallen, och det är denna diskontinuitet som hörssom ett bombnedslag, men för det mesta är ljudvågor betydligt snällare.Eftersom analoga lagringsmedia i princip har mycket stor bandbreddfår vi med ett brett frekvensband. Moderna videobandspelare registrerar lätt information i bandet 0-3 MHz, och detta är bara det frekvensraka området. Vi kan misstänka en något för hög upplösning av materialet, eftersom våra öron och ögon har ett ändligt antal känselcellersom kan operera på inkommande data. Därför är steget inte långt till endiskretisering av det analoga materialet. Fördelen med detta är att vikomprimerar datamängden extremt mycket (oändligt mycket teoretisktsett), och vi behöver inte längre klumpiga och trassliga lagringsmedia.

Dagens teknik kanske inte till fullo visar det digitala mediatskraft, men följande räkneexempel torde skingra de flesta dimmor. Låtoss anta att vi med hjälp av laser (Light Amplification by StimulatedEmission of Radiation) och finnurlig optik kan spjälka information pånågra nanometer när. Jag betraktar detta som en rimlig gräns, eftersomdet vid kortare våglängder krävs radioaktiva strålar för att lösaspjälkningen. Vidare låter vi en sfär med en diameter på 1 cm innehålladigital information, där varje bit är en sfär med några nanometers diameter.

Detta ger oss ungefär $1 \cdot 10^{18}$ bytes till vårt förfogande, och om vijämför hur många av dagens kompakt skivor (Eng. Compact Disc = CD)som skulle behövas för att lagra denna datamängd, blir det ungefär 3miljarder stycken. Vi kan med andra ord lagra allas liv, i textformoch även med viktiga bilder och ljud , i några sådana sfärer. Om vi komprimerar informationen med exempelvis Huffmankodning, får vi platsmed ytterligare data och troligen kommer vi då ner till en sfär, och somett plus får vi med alla data om hela världshistorien med alla bildersom någonsin tagits, filmer, skivor och teater pjäser.

Don't you think it's blinding??? You name it, you've got it!!!

Den absolut största fördelen med digitallagrad information somfinns tillgänglig på icke sekventiell skivform, är att vi kan "klippa &klistra" utan att förstöra ursprungdatat. Tidigare fick användarenklippa direkt i bandet för att få den ordning hon ville ha. För att kunnagöra detta utan att förstöra originalbandet, måste vi framställa enkopia, och klippa i denna. Kopiering av masterbandet, om vi ska ha godkvalitet, tar onödigt lång tid, och kvaliteten blir alltid sämre än originalet. När vi använder digitala klipp, låter vi en dator memoreravilka sekvenser som ska spelas upp, och i vilken ordning. Detta låtersig göras mycket enkelt, klippen blir mycket exaktare och tiden för atthitta de rätta vinklingarna i klippen betydligt kortare. Detta är samplingstekniken i sitt esse, och förfarandet kallas för ickelinjär editering.

Ickelinjär editering används även för videoproduktion, men mängdenminne och beräkningskraft som krävs för att göra detta smidigt är stort(några gigabyte sekundärminne och några tiotal megabyte primärminnesamt mycket goda videoprocessorer och god programvara) och är interiktat till vanliga människor. Oavsett om det blir en försämring avljudkvaliteten / bildkvaliteten när vi övergår till digitalt media ellerinte, kommer de stora tidsbesparingarna att mer än väl kompensera densämre kvaliteten, och dessutom kan kvaliteten bibehållas vid digital kopiering.

Vi kan emellertid förbättra kvaliteten på musikaliskt material,eftersom vi vet hur instrumentens karaktärer är uppbyggda. Låter viharmonisera övertonerna på syntetisk väg, och med hjälp av dessasudda bort eventuell diskretiseringshackighet hos signalen, kommer viatt återföra signalen mot en mera kontinuerlig återgivning.

Diskretiseringshackighet vid sampling av signal med 16 ggrstörre samplingsfrekvens än signalens grundfrekvens.

När det gäller naturliga ljud går det inte att använda denna metodrakt av, utan vi behöver en grundlig ombyggnad av algoritmen, och användning av en lämplig informationsindelning torde vara problemlösaren. Låter vi redan vid lagring dela upp ljuddata i en harmoniskoch en disharmonisk del har vi kommit en bit på väg. Den harmoniskadelen behandlas som musik enligt ovan, och den disharmoniska delenlåter vi approximeras med kubiska splines (se appendix B. Obs! Detta ärbara ett exempel). För att enkelt kunna använda denna teknik behövervi en något modifierad AD / DA omvandlare (AD= Analogt till Digitalt,DA = Digitalt till Analogt).

Det finurliga är att vi kan lagra data i flyttalsform med m antalsignifikanta bitar i mantissan och e antal i exponenten, istället för enheldiskret form med m bitar i mantissan och ingen exponent. Dagens bättre signalprocessorer klarar av dessa saker med lätthet, men de ärväldigt dyra och givetvis inte en var människas egendom. Det som karakteriserar en digital signalprocessor (DSP = Digital Signal Processor) är dess extrema beräkningskraft på flyttalsdata. Inom den ickekomersiella världen har den flitigt används till radar och missiler av olika slag.

De första områden som dessa DSP'er exploaterade, riktat mot allmänheten, var givetvis inom musikvärlden. Svårigheterna som musikskaparna tampats med under decennier, var nästan lösta men i sin"teknikiver" använder en del musikskapare tekniken fel. Resultatet äratt vissa skapare frossar i effekter som delay, chorus, phasing,flanging, pitch shifting, harmonizing, reverb och många många fler. Attde använder tekniken fel behöver inte innebära att det låter dåligt eller ointressant.

Dessa skapares verk har ingen verklighetsanknytning till existerande musikinstrument eller lyssningsrum, men har i stället en stormental verkan på lyssnaren. För att inte begränsa på denna friakreationsförmåga och färga materialet på något vis, krävs utrustningmed minst samma kvalitet som skaparens egna instrument (om vi ska tadet till sin spets). De senare användnings exemplen för DSP'er ärskrift- och röstigenkännare, realtids bildförvrängare ochfingeravtrycksigenkännare. Nu är det helt klart att diskretisering aven kontinuerlig signal, vare sig det är ljud eller bild, ger flera godamöjligheter som vi måste använda oss av till det yttersta.

Beräkningsaspekt på Digital Audio

(Förklaringar till formler i detta avsnitt behandlas i appendix B, för att inte störa flödet.)

En viktig detalj vid diskretisering av kontinuerliga signaler, ärmed vilken hastighet vi hackar upp inkommande data. Denna upphackninghastighet kallas samplingsfrekvens och vidare betecknar jagdenna med $f_S$ . Vare sig det är ljud, bild- eller sensorinformation som ska behandlas, har informationen en viss bandbredd som jag kallar B. Denna bandbredd betraktar vi från 0 Hz till den övre gränsfrekvensen B Hz. Nyquists teorem säger oss att vi behöver ett $f_S$ som är minst $2 \cdot B$ för att kunna spjälka all information från signalen. När vi betraktarflera källor, antalet kallar jag S, ska B inkludera den maximalafrekvensen som finns i en superpositionerad signal av alla källor. Vidare ska alla källor ha samma diskreta informationsdatabredd,vilket jag menar med AD/DA omvandlarens upplösning i bitar, som jag kallar I. Vid superposition (addition) av flera datakanaler behöver viett större $I_{OUT}$ i jämförelse med $I_{IN}$ , för att inte mista information i eventuella overflows.

$Dynamik \approx 6 \cdot I$ (dB) (0)

$I_{OUT}=I_{IN}+Ceil(\log_2(S))$ (bitar) (1)

I samband med flera sändarkällor har vi oftast flera mottagare(R) och även om mottagarens bandbredd är större ska vi inte överbelasta systemet med onödiga data. Vi ändrar alltså inte på $f_S$ . Låt ossbetrakta en möjlig simulering av ett ljudvågsutbredning från dessakällor mot mottagarna. De tidiga reflexerna som jag kallar $X_E$ (EarlyrefleXions, med enheten stycken) och antaletefterklangsapproximander som jag kallar $X_R$ (Reverberation refleXions, med enheten stycken), är även dessa rent beräkningstekniskt vanliga källor. Detta leder oss till en utveckling av (1):

$I_{OUT}=I_{IN}+Ceil(\log_2(S+X_E+X_R))$ (bitar) (2)

Hur mycket datorkraft krävs för att kunna addera alla dessa kanaler till en superpositionerad signal till mottagarna? Jag kommeratt använda mig av enheten op vilket innebär en addition plus en multiplikation. Följande formel ska användas för beräkning av den nödvändiga datorkapaciteten med denna NODIRAC algoritm:

$D=f_S \cdot (S+X_E+X_R) \cdot R$ (op/s) (3)

Om vi ska kunna göra detta i realtid, blir det enligt formel 3 fruktansvärt mycket datorkraft som krävs för ett så pass enkelt fall somföljande:

Problem 1:

Vi har två sändare och två mottagare. Den högstafrekvensen är 20 kHz och vi har 23 ytor som ger tidigareflektioner. Vidare approximerar vi efterklangen med 100, stokastiskt exponentialfördelade tidpunkter efter $T_r$ (få i början, många mot slutet), linjärt avtagande efterklangsapproximander. Hur mycket datorkraft behövsom vi ska lösa problemet med en NODIRAC algoritm?

Lösning:

Vi har $f_S$ =40 KHz, S=2, $X_E$ =23, $X_R$ =100 och R=2. Insättning i (3) ger 10 miljoner op/sekund.

Om vi ska göra en "riktig" studie av ett rum, kan vi sampla rummet med hjälp av en diracpuls från varje källa till varje mottagare. Låt oss kalla dessa diracpulsers samplingsfrekvenser $f_{DIRAC}$ , och tidslängden för dessa samplingar är, från första vågfronten tills signalens styrka sjunkit med 60 dB, $T_{60}$ . Låter vi dessa samplade rumssignaler ligga till grund för vår simulering (istället för de få reflektionerna och efterklangsapproximanderna), som vi kallar NOMIX algoritm,kommer formeln att se ut som följer.

$D=f_S \cdot S \cdot f_{DIRAC} \cdot T_{60} \cdot R$ (op/s) (4)

Enligt formel 4 kommer vi då att behöva en dator som klarar betydligtmera, även för extremt enkla fall som följande:

Problem 2:

Vi har två sändare och två mottagare och den högstafrekvensen är 20 kHz. Med hjälp av impulssvar, från en diracpuls med tidslängd på 2 s och med en samplingsfrekvens på 3125 Hz från alla källor till alla mottagare, vill vi beräkna den nödvändiga datorkraften. Viska lösa problemet med en NOMIX algoritm.

Lösning:

Vi har $f_S$ =40 KHz, S=2, $f_{DIRAC}$ =3125 Hz, $T_{60}$ =2 s och R=2. Insättning i (4) ger 1 miljard op/sekund.

Det kan vara en god idé att beräkna det minneskrav vi behöver vid dessa "exakta" simuleringar. För varje källa behöver vi memorera $M_S$ antal bytes som ges av följande formel:

$M_S=f_S \cdot T_{60} \cdot I_{IN}/8$ (bytes) (5)

Det totala minneskravet blir, med diracpulsernassamplingsminnesutrymme, följande:

$M_{TOT}=S \cdot (M_S+R \cdot f_{DIRAC} \cdot T_{60} \cdot I_{IN}/8)$ (bytes) (6)

Problem 3:

Hur mycket fritt minne krävs, om vi har eninformationsdatabredd på 16 bitar och resterande data ärsom i problem 2?

Lösning:

Vi har S=2, $f_S$ =40 kHz, R=2, $f_{DIRAC}$ =3125 Hz, $T_{60}$ =2 s och $I_{IN}$ =16. Insättning i (6) ger ca 360 kB

Vi inser det absurda i detta sammanhang, eftersom vi behöver en dator med mycket höga beräkningsprestanda och relativt lite minne.Eftersom minne brukar vara billigare än beräkningsprestanda, är detdärför en god idé att omfördela arbetsbördan. Om vi låter superpositionera källorna redan vid diskretiseringen, och låter dessa finnas tillgängliga i R minnesareor med $I_{OUT}$ bitars informationsbredd, får viföljande formler:

$D=R \cdot (S+f_{DIRAC} \cdot T_{60}) \cdot f_S$ (op/s) (7) $I_{OUT}=I_{IN}+Ceil(\log_2(S))$ (bitar) (8) $M_{TOT}=R \cdot f_S \cdot T_{60} \cdot I_{OUT}/8$ (bytes) (9)

Denna algoritm kallar jag MIXTHEM, och observera att den använder sig av samma impulssvar för varje ljudkälla, och ger därför inte samma filtreringssvar som NOMIX algoritmen.

Problem 4:

Vi har två sändare och två mottagare och den högstafrekvensen är 20 kHz. Med hjälp av impulssvar, från endiracpuls med tidslängd på 2 s och med en samplingsfrekvens på 3125 Hz från alla källor till alla mottagare, vill vi beräkna den nödvändiga datorkraften ochminnes kravet. Vi löser problemet med en MIXTHEM algoritm.

Lösning:

Vi har $f_S$ =40 KHz, S=2, $f_{DIRAC}$ =3125 Hz, $T_{60}$ =2 s, $I_{IN}$ =16 och R=2. Insättning i (7) ger 500 miljoner op/sekund. Insättning i (8) ger $I_{OUT}$ =17 vilket medför att vi minst behöver $I_{OUT}=32$ för att minneshanteringen ska bli så enkel sommöjlig. Vidare ger insättning i (9) att vi behöver 625 kB för lösning av detta problem.

NOMIX och MIXTHEM algoritmerna ger inte samma svar, eftersom de inte använder sig av samma diracfaltningar. Det kan då tyckas dumt att jämföra dessa. Kruxet är att låta ljudkällorna bli stereosamplade i reflexfria rum och lagrade i en databas. Ur denna databas låtervi sedan datorn hämta de rätta ljuden vid de rätta tidpunkterna, för attsedan låta dessa bli filtrerade genom MIXTHEM algoritmen (detta blir"nästan" rätt). Även med hjälp av redan färdigberäknade impulssvarfrån alla källor till alla mottagare, krävs det en enorm beräkningskraft för att simulera dessa typer av vågutbredningar.

Varken NOMIX eller MIXTHEM algoritmerna är helt korrekta, jämfört med naturen, men även om de vore det borde det stå mycket klart att det krävs finurlig hårdvara som sköter detta på "automatisk" väg. Jag menar inte de enkla DSP'er som finns i dagsläget, utan något mer sofistikerade apparater, som i egentlig mening inte använder sig av digital addition och multiplikation för beräkningarna.

Om vi bortser från kriteriet att falta de samplade diracpulserna i realtid, kan vi använda oss av en overlap-add algoritm [14]. Med denna algoritm krävs det ungefär en tusendel av NOMIX algoritmens beräkningshastighet, men inkommande data kommer att bli fördröjda med $2 \cdot T_{60}$ [15]. Hårdvaruimplementationen av overlap-add algoritmen finns kommersiellt tillgänglig i form av en FDP-1 krets producerad av Lake[16]. För små rum kan denna vara användbar, men för större hallar kan vi bortse från denna lösning, eftersom realtidsfeedback inte är möjlig med en släpeffekt på några sekunder. En analogi med verkligheten är JAS-planets styrsystem, som vid flera tillfällen visat denna brist (speciellt om piloten inte är medveten om släpeffekten).

Vidare har nya DSP-kretsar från Texas Instruments (kommersiellt släpps de hösten 1994) blivit ledande i beräkningshastighet ( $>1$ miljard flyttalsoperationer per sekund). Med hjälp av ett par av dessa dunder-DSP:er kan vi lösa faltningsproblemet i realtid, men kostnaden blir antagligen hög för vanliga människor och vi nödgas vänta på realtidsfaltning för folket. Märk att jag inte syftar till DSP-kretsen direkt, utan det mycket snabba minne som måste vara tillkopplat. Med ett approximativt överslag, krävs det ca 0.5 ns snabbt minne (om dataär i seriell form) för att optimalt mjölka kraften ur dessa DSP:er. Det bör tillägas att dagens $\mu$ -datorer har omkring 70 ns snabbt minne,vilket indikerar att vi bör dela upp data i ungefär 128 likformiga delar,och falta dessa parallellt. Den parallella lösningsformen är renthypotetisk, eftersom jag inte tagit del av hårdvaruspecifikationerna till fullo.

Virtual Reality

Between ingenuity and the analytic ability there exists a difference far greater, indeed, than that between the fancy and the imagination, but of a character very strictly analogous. It will be found, in fact, that the ingenious are always fanciful, and the truly imaginative never otherwise than analytic.

Edgar Allan Poe

Detta kapitel behandlar virtuell verklighet, och är riktat till de personer som inte vältrar sig i historia. Eftersom denna del av datorvetenskapen är relativt ny (NASA "började" med detta i mitten av 80 talet och VPL research gjorde VR till allmän åskådan 1989), försöker jag i första delen definiera vad "virtuell verklighet" är och i de följande dess användningsområden. Det förutsätts att läsaren är väl medveten om de stora beräkningskrav som tredimensionell visualisering (i sitt extremfall realtids video-ray-tracing, ett för varje öga) och auralisering (i sitt extremfall realtids faltningar av impulssvar som beräknas mha audio-ray-tracing, ett för varje öra) har.

I definitionen använder jag ordet detaljrikedom i den mening att ingående natur fullständigt ska efterliknas avseende reflektion, absorption, interferens, diffraktion, refraktion, diffusion, resonans och dispersion. Jag har inte skrivit om de vanvettiga idéer som finns i cyberkulturen, utan om de mera realistiska och fullt realiserbara idéerna.

Definition av VR

För att kunna definiera virtuell verklighet (Eng. Virtual Reality=VR), ska jag beskriva de viktigaste kännetecknen den riktiga verkligheten har. Vi uppfattar verkligheten genom att se, höra, känna, lukta och smaka. När vi är ute i naturen och beundrar trädens svajande, vattnets virvlar eller molnens rörelser, kan vi tycka att det är intressant att beskåda dessa. Grunden till vårt intresse är att det vi ser har en mycket hög detaljrikedom och/eller är i ständig rörelse. Förutom att vi ser bredd, höjd och djup kan vi betrakta världen från en godtycklig punkt.

(1) En god VR-miljö ska ha skalenliga och mjukt rörliga tredimensionella objekt med hög detaljrikedom. I denna modell ska vi ha möjligheten att betrakta omvärlden från en godtycklig punkt i en godtycklig riktning.

I enlighet med de två föregående kapitlen bidrar kravet på ljuduppfattning denna utvidgning:

(2) En god VR-miljö ska återge ljudvågsutbredning från ljudgenererande objekt till binaural återgivning (auralisering) med hög detaljrikedom.

Vårt liv hade varit tämligen ointressant om vi inte kunde känna ett objekts form och tyngd. Även om det kan tyckas att synen förmedlar objektets form, ska det påpekas att jag menar ytans släthet och temperatur. Detta ger oss följande utvidgning.

(3) En god VR-miljö ska förmedla objektens textur, temperatur och tyngd med god noggranhet.

Människans luktsinne är inte lika utvecklat som exempelvis hundens, men lika väl kapabelt om det tränas. Det viktigaste vårt luktsinne bidrar med är att förhöja smaken när vi äter. Något som de flesta inte känner till är även att vi människor kan lukta oss till fara, trygghet och kärlek. Det är pheromoner [17, 18, 19] som gör detta möjligt, och även om de flesta av oss "glömt" hur vi uppmärksammar dessa "dofter", kan vi öva upp luktsinnet. Detta resonemang ger oss denna utvidgning:

(4) En god VR-miljö ska kunna förmedla pheromoner och naturliga lukter.

De flesta småbarn kryper omkring och försöker smaka på allt möjligt. Detta gör de av ren nyfikenhet och för att bilda sig en uppfattning om omvärlden. I den vuxna världen kan vi tyvärr inte gå runt och smaka på allt vi ser. Emellertid behöver inte de objekt som finns i VR-miljön ha någon anknytning till jordens flora eller fauna.

(5) En god VR-miljö ska främst kunna förmedla söta, sura, salta och beska smakintryck vid oralt intag. All annan form av intag ska medföra en kemisk sammansättnings spjälkning.

Slutligen detta mycket viktiga krav för användarens säkerhet.

(6) Alla VR-miljöer ska ha mycket rigorösa säkerhetskrav för att inte ändra användarens hälsa till det sämre.

Användningsområden

Har mänskligheten någon användning av VR-miljöer, eller är det bara en "fluga" från Amerika som mycket annat? Här diskuterar jag några av de områden som kan få eller har stor hjälp av VR-miljöer.

Medicin

När medicinstuderande lär sig hur människokroppen fungerar, har de i bästa fall en skalenlig plastmodell av en människa. I de mera avancerade modellerna kan eleven plocka loss olika organ för närmare beskådning. För att lära sig anatomi verkar detta vara ett mycket bra och lätt förfaringsätt. Problemet är att alla ska ha en sådan modell för att lära sig lika snabbt, men den är alltför dyr. Något som ytterligare försvårar saken är att den tar onödigt utrymme i anspråk.

Fördelarna med att implementera människo- eller djurkroppen i en VR-miljö är att vi enkelt kan göra automatiserade prov. Det blir enklare att visa kirurgiska handhavanden (alla elever ser vad kirurgen ser) och sjukdomsspridningar. Dessa fördelar får vi även när vi använder oss av strategiskt utplacerade videokameror vid operationer. Problemet är att vi behöver en patient (levande eller död) med samma åkomma som just undervisas för att få god "mappning".

Tomografi är en vidareutveckling av vanlig röntgen. Patienten "scannas" i flera skivor som har hög upplösning i alla led. Vanlig röntgen är relativt suddig, eftersom den fotografiska plåten tar emot röntgenstrålar genom mycket tjockare skikt (dålig djupledsupplösning). Fördelen med att använda tomografi är att en tredimensionell bild, enkelt kan åstadkommas.

När dagens datortomograf användare betraktar patientens innandöme, gör hon detta på en enkel monitor. I bästa fall kan datorns programvara vara konstruerad för att visa en homogen tredimensionell bild av patientens sjukdomsregion. Låter vi visualiseringen förbättras med en mycket god VR-miljö kommer läkaren att ännu lättare hitta möjliga kirurgiska problem och därmed göra säkrare och snabbare ingrepp.

Medicinsk VR-miljö, behöver inte vara lika omfattande som den starka grund definitionen men syn och känsel ska finnas med. För patologer kan även lukt vara ett hjälpmedel, men generellt behövs det ej. Huruvida öronspecialisten behöver höra som sin patient, har jag ingen kännedom om. Utbildning av medicinstuderande i VR-miljö borde ge bättre läkarkunskap hos dessa och förhoppningsvis friskare patienter.

Video-scannad och retoucherad bild från Encyclopedia Britannica (Propaedia), visandes delar av en kvinnas inre anatomi.

Rymdfart

Video-scannad och retoucherad bild från Encyclopedia Britannica, visandes en rymdfärja av Rockwell-typ.

Förr eller senare kommer mänskligheten att behöva vidga sina vyer pga att vår jord inte kommer att kunna tillfredsställa våra behov. Detta kan göras om vi utforskar ett flertal himlakroppar ute i universum. Ett "litet" problem är att de mest intressanta himlakropparna finns på ett sådant långt avstånd från oss att det tar centennium att komma dit med dagens rymdfärjor. För att lösa detta problem kan vi öka rymdfärjans hastighet och acceleration. Men eftersom människokroppen inte tål höga accelerationer/retardationer (Dödligt över $10g \approx 100 m/s^2$ ) kan rymdfärjan inte uppnå maxhastighet eller bromsa inom rimliga tider.

En lösning på detta fysiologiska problem är att inte skicka med några människor alls. Nu är hastighetsproblemet betydligt mindre, eftersom all teknisk apparatur klarar mycket högre accelerationer än 10g. Obemannade rymdfärder har redan skett i form av Mariner- (1962-1973), Pioneer- (1972-1973), Viking- (1975) och Voyagerrymdsonderna (1977) från USA och Venera- (1967-1975) och Marsrymdsonderna (1971) från dåtida Sovjet [20]. Dessa tog endast bilder på långt avstånd och vi kan bara skönja mycket stora objekt på markytan. Det bör tilläggas att Viking-rymdsonderna tog "jord"-prov och mycket detaljerade bilder av marsytan. Allt detta är bra men inte tillräckligt bra (även om människan vandrat på månen).

Människan har alltid velat utforska okända ställen och farleder. Ett typiskt exempel är Columbus som på ett "föredömligt" sätt utforskat det okända. Det som drev upptäcktsresande var att de ville se det okända med egna ögon. Låter vi istället våra framtida rymdsonder fotografera mycket strategiska bilder för att kunna forma en VR-miljö, kommer vi att enklare kunna utforska en möjlig terraformering (Terra=Jord -> Sv.=Jordformning). Hela VR-definitionen behövs inte i en begynnande uforskning av himlakroppen (endast synen och smaken är nödvändiga), men när kartläggningen är klar ska den fullständiga definitionen användas. Märk att vi inte kan ha kommunikation mellan rymdsonden och VR-miljön eftersom tidseffekterna är för stora, och därmed inte kan möjliggöra realtidsfeedback av våra rörelser.

Underhållning

Video-scannad bild från Förhistoriska Djur (utgivet av Bonniers) visandes den grymmaste och mest imponerande skräcködlan - Tyrannosaurus rex.

För att komma ifrån vardagens tunga ok och lätta på tungsinnet, kräver de flesta människor underhållning av något slag. De flesta vill förlora sig in i en drömvärld som antingen finns i bok- eller filmform. Redan i början av 80-talet försökte filmskapare använda sig av datorgenererade miljöer i sina filmer, då främst i filmer som "TRON" & "The Last Starfighter". Problemet med dessa filmer var att datormiljön var mycket verklighetsfrämmande och inte lurade biobesökarnas ögon så väl. Nyligen gjorda filmer som "Terminator 2" och "Jurassic Park" har lyckats betydligt bättre på denna punkt. Även om filmskaparna inte kommit till den slutgiltiga gränsen för antalet "verkliga" fantasier som kan kreeras med tvådimensionell film, kan jag utan tvekan skriva att det krävs förnyelse inom branschen.

För att förhöja illusionerna krävs en tredimensionell återgivning och fömedlande av mycket högkvalitativt ljud. I ett senare skede bör även lukten implementeras. Denna VR-miljö har de tuffaste kraven, eftersom folk i gemen är mycket skeptiska mot datorer och dess påverkan på människorna. Därför är kravet på god kvalitet av yttersta vikt för att vanliga människor ska kunna ta till sig illusionerna.

En nackdel med att ha alltför bra illusioner är att dessa kan förleda människor att tro på saker som inte är korrekta. Tyvärr kommer mängder av människor att använda VR-miljöer tillsammans med någon form av drog för att förhöja illusionseffekten. Detta, plus att användaren får mycket mindre motion, kan leda till mycket stora sociala problem. Vetenskapsmän som sysslar med VR-miljöer bör informera om de möjliga sociala problem för de som ska använda sig av den i exempelvis film och reklam, innan den kommer ut till allmänheten.

Militärt

Alla goda saker kan användas till onda ting, och VR-miljöer är inte undantagna detta faktum. Eftersom tidseffekterna på jorden är relativt små (max ca 70 ms) kan vi utan större problem ha god realtidsfeedback av våra rörelser. Detta innebär att vi enkelt kan styra en mekanisk robot i fiendeläger utan att själv närvara. I nyare former av krig kan vi realisera krigsplatsen i en total VR-miljö, och låta dem som är intresserade av mänsklighetens förfall idka denna istället. Dessa personer kan då avreagera sig med diverse slaktmissioner, för att sedan återgå till "normalt' liv. Hur väl denna militära VR-miljö ska göras för att ha störst förebyggande effekt kan diskuteras men den torde kräva mycket goda syn- och hörselintryck.

Simulatorer

Det har funnits bil-, flyg- och båtsimulatorer på marknaden ett tag, och dessa är förhistoriska VR-miljöer. Flygsimulatorer har exempelvis funnits sedan 1929 [21]. Grunden till att jag kallar dem förhistoriska är att användaren sitter i en funktionell replika av den riktiga kommandobryggan. Detta är i och för sig bra eftersom det ger en perfekt mappning. Emellertid använder vi mekaniska omkopplare som tar mycket plats och är dyra om de ska vara tillförlitliga.

Övergår vi till en heldigital styrning av systemen (vilket är mycket svårt), kan vi utforma gränssnittet människa-maskin mycket enklare (både i VR-miljön och på riktigt), så att betydligt fler kan handha maskinen ifråga. Förhoppningsvis kommer inlärningen av perikulösa scenarian kunna göras snabbare och enklare. Vi kan utvidga användningen av VR-miljön, och implementera denna i samexistens med nuvarande kommandobryggor, för att eliminera synsvårigheter som exempelvis "döda vinklar".

Dagens gymnastikhallar har diverse redskap för att förbättra hälsan. Dessa är tråkiga att använda i längden, och en "pö om pö"-användare (som jag själv) drar sig i det längsta för att använda dessa. Lösningen är att åka ut i naturen och börja sin hälsokur där. I morgondagens sammhälle kommer befolkningstätheten att vara så stor att vi inte kommer att ha tillräckligt med utrymme för rekreation i naturlig mening. Ska människan då behöva bli instängd i ett rum och utöva hälsokuren stirrande in i en trist vägg?

Låt den sportidkande delen av befolkningen sporta i en VR-miljö som anpassas till användarens personliga fysiska styrka. I denna kommer alla att kunna springa lika snabbt, visuellt sett i VR-miljön alltså. Om användaren tycker det är skönt med en vinst för att förhöja intressegraden, kan VR-miljön programmeras för detta. Det är min övertygelse att de flesta som inte tycker om att utöva sport är för vinstfixerade, och när de inser sin dåliga kondition när de "tävlar" mot andra bryts deras vilja, och de avslutar sportandet. Personligen ser jag VR-miljöer som en frälsare i denna problematik. Dessa VR-miljöer kräver syn och hörsel för att få tillräckligt reella simuleringar.

Computer Aided Design

Arkitekter och maskinkonstruktörer har förnärvarande mycket stor hjälp av datorgrafiska visualiseringar. De ser sin konstruktion innan den är byggd och kan, om programmet tillåter, undersöka om konstruktionen håller och fungerar (typ IGRIP på Silicon Graphic maskinerna). Vid konserthusbyggen kan även den akustiska aspekten beaktas, och en auralisering kan åstadkommas med rätt mjuk- och hårdvara. Dessa hjälpmedel underlättar en hel del och dyra ombyggnader och konstruktionsmissar kan minimeras. För att få bästa möjliga konceptualisering, bör vi sträva efter en mera perfektionistisk verklighet mha VR-miljöer som ger användaren en fantasifullare och mera självförverkligande kreation.

Framtidens Programmeringsmiljö

I jakten på den ultimata användarvänligheten torde VR-miljöer vara ett steg i rätt riktning. Dagens programmeringsmiljöer lider av stora nackdelar, som vi kanske inte tänker på när vi använder dem korta tider. Kravet att allt visuellt ska vara lika kommer förr eller senare att ge användaren en smak av monotoni. De som programmerat över 16 timmar i sträck kan emellanåt känna viss faddhet vid datorn, som inte behöver bero på dålig kosthållning eller få toalettbesök. Egentligen är datorns gränssnitt mot människor fruktansvärt tråkiga, eftersom innehållet på skärmen är statiskt. En förebyggande metod kan vara att vistas i en VR-miljö vid utvecklingsarbeten, där visuella effekter ger uppmuntrande signaler till hjärnan. Arbetsgivaren behöver inte spendera pengar på möblemang, blommor och stora arbetsytor, utan VR-miljön (stora högupplösande Liquid Crystal Displayer på väggarna som är kopplade till en VR-Dator) anpassas till användarens smak.

En vidareutveckling av användargränssnittet, är att låta hjärnaktiviteten styra gränssnittets utseende för att bibehålla användarens uppmärksamhet och humör. Dagens problem som löses med datorer kräver stora arbetslag för programmering. Medlemmarna i dessa arbetslag bör ha liknande smak vad gäller inventarier och ambiensmusik, om de ska kunna arbeta effektivt tillsammans. Detta har jag själv uppmärksammat på diverse arbetsplatser genom åren.

Fördelarna med att vistas i VR-miljö är att medlemmarna inte behöver vara belägna på samma plats och de kan välja inventarier och musik efter eget tycke. Detta kommer att medföra en effektivitetsvinst, eftersom alla får som de vill och därmed mår mycket bättre. Varför ska vi behöva VR-miljöer för att lösa detta? Det går lika bra att göra detta med dagens teknik i en tvådimensionell datavärld men bristen på "tredimensionell" människokontakt lär bli ett stort problem förr eller senare. Vi behöver inte den fullständiga VR-definitionen i denna miljö, men syn, hörsel och känsel ska vara implementerat.

Musikstudio

Vi kan med stor fördel implementera morgondagens musikstudio i en VR-miljö. Det första ljudmixaren gör är att placera ut diverse musikinstrument (egentligen ljudgenererande objekt) i det självmodellerade virtuella rummet. Efter utplaceringen bestämmer hon vilken stämma objektet ska spela och med vilken styrka och karaktär. För att öka intressegraden och minska förutsägbarheten i musikstycket kan hon sedan låta instrumenten vandra i rummet eller ändra karaktär med tiden. Musiker över hela världen kommer att kunna spela i en virtuell konserthall, men fortfarande vara hemma i sin stol (Musikern Thomas Dolby försöker realisera denna idé).

Denna VR-miljö kommer även att vara till stor hjälp inom filmindustrin, eftersom det kommer bli lättare att editera in ljudeffekter i filmer. Även om dagens bättre biograffilmer finns med Dolby Surround (ej samme Dolby som ovan), som påminner om denna VR-miljö, lider de flesta av betydande audiomediala brister. För att få högsta möjliga ljudkvalitet bör denna VR-miljö lägga stor vikt vid hörselkriteriet i definitionen, men även synen ska implementeras för att underlätta handhavandet.

Huvudproblem

TNE logo ©Denis Tumpic

Das also war des Pudels Kern!

Johann Wolfgang Von Goethe

I detta kapitel beskriver jag mitt examensarbete genom att först definiera problemet. Sedan följer en analys av problemet i de viktigaste problemdelarna. Avslutningsvis kortbehandlar jag olika programmeringsmetodiker. Huvudsakligen handlar detta examensarbete om audio-ray-tracing i VR-miljö och implementeringen av en sådan. Denna idé är inte helt ny, eftersom vissa viktiga delar formulerades på en stabil grund 1992 [22, 23, 24 ,25].

Själva audio-ray-tracing metodiken har varit känd sedan 1967 [26], och har nyligen börjat intressera ett flertal forskare pga större tillgång till kraftfullare datorer. Min uppfattning av materialutbudet (mycket skralt i jämförelse med video-ray-tracing) i detta område har givit mig en känsla av att det är mycket få personer som egentligen utvecklar algoritmer för audiomediala VR-miljöer.

I början kan man ha den naiva inställningen att lösningsmetoderna är samma för video- som för audio-ray-tracers. Emellertid visar de första kapitlen de problem som ljudpropageringsberäkning innebär och de möjliga approximeringar vi kan göra. Själva implementeringen hjälptes av Amigasystemets huvudböcker och diverse C böcker plus en GUI framställare (se Böcker, Mjuk- & Hårdvara).

Problemställning

För närvarande är det mycket vanligt med video-ray-tracers till persondatorer (speciellt för datorfamiljen Amiga), men audio-ray-tracers finns inte i samma mångfald. Kommersiellt finns inga sådana tillgängliga till rimliga priser. Programmen Odeon och Computer Aided Theater Technique (CATT) som finns tillgängliga för IBM-kompatibla PC-maskiner är båda hutlöst dyra och långt från användarvänliga. Detta faktum plus dagens ökade intresse för VR-miljöer (Läs föregående kapitel om Virtual Reality) indikerar ett starkt behov av en audio-ray-tracer som både är snabb och lätt att använda.

Vad som bör finnas med i ett ray-trace program är en enkel grafisk 3D-editor, möjlighet att bestämma objektens material och typ, samt möjlighet att låta objekten följa förutbestämda rörelsescheman. Den grafiska 3D-editorn kan implementeras med mycket komplexa inslag som exempelvis "beta-splines" med "hidden surface removal". Att göra den perfekta 3D-editorn har inte varit mitt huvudmål, men dess användbarhet har i mycket stor utsträckning format programmets utseende. För en audio-ray-tracer kan objektens material vara knutna till ytornas absorptionsegenskaper och riktverkan (direktivitet). De olika typer av objekt som finns kan vara möbler, sändare och mottagare. Rörelsescheman ska innefatta både morfning (omformning) och translation i de tre dimensionerna (Läsaren ombedes att erinra sig den starka VR definitionen). Programmet ska kunna hantera ovan nämnda saker med enkelhet, så att användaren inte hindras i sin kreativa förmåga eller fråntas värdefull fritid.

Visualiseringen som finns i alla video-ray-tracers ska även ha en god likatydan i en audio-ray-tracer, och denna kallar vi auralisering. Denna term har Chalmers Tekniska Högskola gjort till de facto standard. Med tanke på den extrema beräkningskraft som krävs för auralisering (bevisas i Beräkningsaspekt på digital audio) i samband med den enkla hårdvara som vanliga persondatorer innehar, är detta mål inte det främsta, men det finns i åtanke för senare hårdvaruimplementationer.

En obligatorisk del vid auralisering är att kunna sampla existerande rum medelst diracpulser för användning och jämförelser i de beräknade impulssvaren. Denna del är för enkel att implementera, och jag nämner den bara i detta sammanhang som en möjlig utvidgning av mitt program. Egentligen är den redan implementerad pga att jag kan använda mig av de stora mängder samplingsprogram som finns att tillgå, och köra samplingsprogrammet parallellt med audio-ray-trace programmet.

En mycket givande och fullt realiserbar idé är att låta två persondatorer kommunicera med varandra, medan användarna vistas i en gemensam audio/video miljö som ett slags försteg till framtidens goda VR-miljöer. Denna del har jag siktat på, men eftersom en datalogs egentliga kunskapsgebit inte tillhör hårdvarubyggen, har jag utelämnat idén från denna framställning. Lösningen kräver snabbare kommunikation än vanlig seriell överföring. Det går att göra det med parallell överföring, men det blir ca 8-32 ggr dyrare (beroende på bredd), och därför är denna lösning inte en bra möjlighet.

Även följande idé har utelämnats eftersom den amerikanska hårdvaruleverantören har försatts i konkurs. Medelst speciella glasögon (egentligen två stycken enpixels Liquid Crystal Displayer) som alternerande släpper igenom varannan bild från datormonitorn till vardera öga, kan vi bilda kraftigt realistiska tredimensionella bilder för att öka användarvänligheten i 3D-editorn [27, 28]. Egentligen är hårdvaran mycket enkel att bygga själv, men återigen är en datalogs främsta gebit algoritmutveckling.

Vidare kan ett audio-ray-trace program vara ett mycket bra hjälpmedel till förbättring av akustiken i redan existerande rum. Detta låter sig göras om de rätta approximationerna implementeras i programmet för simulering av ljudpropagering, och om vi bortser från den audiomediala VR-miljöns hårda krav vars huvudpostulat är realtidsfeedback.

Valet av dator är mycket grundläggande, och som datalog ska man kräva ett bra operativsystem som understödjes av god hårdvara. Dessa kriterier ska inte få den ekonomiska aspekten att komma i skymundan, utan den ska sättas till sin spets. Datorkapaciteten ska användas till en sådan grad att algoritmernas effektivitet visas på enklaste sätt med minsta möjliga medel. Vid utvecklingsarbeten krävs minst "preemptive multitasking" om programmeraren ska arbeta effektivt. En form av "Infinite Stream Of Consciousness" infinner sig vid användning av dessa system.

Användningen av stora arbetsstationer till detta examensarbete hade varit lättare, men deras beräkningsprestanda döljer dåliga algoritmer. Eftersom jag är en ivrig motståndare till långsamma grafiska gränssnitt och ineffektivt programmerade pseudooperativsystem, har jag valt Intuition med Amiga-OS i grunden, min favorit miljö, för realisering av detta examensarbete. Examensarbetet är även en naturlig forsättning på Amiga-maskinernas ledande VR-tradition. Det enda jag möjligtvis tycker är dåligt med Amiga-OS är dess minneshantering, eftersom det ej är skrivet för MMU (Memory Management Unit) hårdvara. Grunden till detta är Amigans grafikhjälpprocessor (Agnes) som kan flytta data i programminnet. Detta, plus några ytterligare hjälpprocessorer (Denise, Paula, Buster, Amber, Ramsey, Gary med flera), är i sin tur huvudorsaken till Amiga-arkitekturens minneseffektivitet och snabbhet.

Denna Amiga-arkitektur (en riktig hybridmaskin) har funnits kommersiellt tillgänglig sedan 1985 och är i dagsläget, trots ålder, en mycket användbar dator. I längden forlorar den dock i prestanda mot större RISC (Reduced Instruction Set Computer) maskiner. Därför har jag inte optimerat vissa algoritmer i ren assembler. Algoritmer gjorda före 1989 är i assembler, men används inte i implementeringen eftersom snabbare algoritmer kommit i dagen (OBS! mina egna).

Vid sidan av datorvalet är programmeringsspråket en mycket viktig hörnsten. Komplicerade språk tenderar oftast att generera sämre översättningar till datorns grundsinstruktioner (speciellt i CISC (Complex Instruction Set Computer) arkitektur), och det stod mycket klart för mig att Pascal (egentligen inte komplicerat men ineffektivare än kompilerad BASIC på Amiga datorer !!!), Modula-2, Simula, Cluster och Modula-3 inte var tillräckligt effektiva. Dagens OOP (Object Oriented Programming) språk C++ (Definition 2.1) och Oberon är inte fullt utvecklade till Amigan, och vanliga C++ (Definition 1.0) var för ineffektivt.

De möjliga alternativ som finns kvar är assembler, DSPC (Denis tumpic Structured assembler Programming Code utvecklat 1986-1988, som ej har använts till denna implementation, eftersom RISC var i antågande) och programmeringsspråket C. Av dessa valde jag C, eftersom det är ett relativt enkelt och mycket fritt språk att arbeta med. Alla kan programmera i C eftersom det är uppbyggt med små medel, och allt är tillåtet (om vi jämför med de ovan nämnda "riktiga" datorspråken - BASIC borträknat! ). Detta sätter programmerarens disciplin på prov, och jag kan utan tvekan skriva att läsliga C-program är en konst att skriva. Rent programmeringstekniskt var mitt största mål att skriva ett mycket läsbart C-program, med mycket förklarande text vid svåra konstruktioner. Detta är av stor vikt vid större programmeringsprojekt, speciellt om det är ett enmansprojekt som detta.

Problemets Analys & Implementering

Examensarbetets implementeringsdel har jag delat upp i de grundläggande problemstrukturerna. Dessa är det grafiska gränssnittets utformning, beräkningsintensiva 3D grafiska algoritmer, ljudpropagerings algoritmer, efterklangs- approximering, auralisering och slutligen datorstrukturen. Dessa strukturer påverkar programmets effektivitet och utformning mest.

Människa Dator Interaktion

The most we can hope for is that the oftener things are found together, the more probable it becomes that they will be found together another time, and that, if they have been found together often enough, the probability will amount almost to certainity.

Bertrand Russell

I denna sektion skriver jag om de kriterier som krävs för goda användargränssnitt. Även de problem som uppkommer vid grafisk gränssnittsframställning berörs. Vidare beskriver jag de inspirationskällor jag haft för denna. Dessa har jag inte förklarat i detalj, utan bara extraherat originella bitar eller utvecklingsfaser. Avslutningsvis beskriver jag min implementering av gränssnittet och försöker analysera möjliga problem m.h.a. de kriterier som definieras i grundprincipdelen.

Grundprinciper

Dagens datorprogram är väldigt beroende av det grafiska gränssnittet (Eng. GUI - Graphical Unit Interface) om det ska överleva i den tuffa mjukvarukonkurrensen. Användare som inte accepterar ett program snabbt kommer fort att tröttna, och med stor säkerhet överge programmet till förmån för ett annat med ett bättre GUI. Enkelt uttryckt är GUI det viktigaste i ett program, och den som lyckas skapa det mest intuitiva gränssnittet vinner i längden.

Rent programmeringsmässigt är GUI programmeringen det som tar längst tid att implementera, och ett stort antal "mock up's" föds och dör innan det blir färdigt. Egentligen blir GUI aldrig färdigt eftersom vi kan förbättra in absurdum.

Hur gör vi en god GUI-framställning? Detta är en enkel fråga som har ett mycket komplicerat svar. I den fortsatta framställningen beaktar jag inte skillnader som finns mellan olika kulturer. Även de subjektiva preferenser som varje människa besitter har jag bortsett i från, eftersom vi tyvärr inte kan blidka alla användare.

Vad som kännetecknar ett bra utformat GUI är god mappning, snabb feedback och enkel adaptation. Dessa kriterier är inte de allena rådande, men de är utan tvekan de som har störst genomslagskraft. Vidare kan interaktiv omformbarhet (exempelvis förflyttning av omformare under programkörning) i GUI underlätta enkla subjektiva preferenser, vilket ger en gladare användare i längden. Detta finns delvis implementerat i MUI (Magical User Interface som är implementerat av Stefan Stunz och förnärvarande fritt tillgänligt på Amiga-public-domain), vilket är ett bibliotekstilläg till Intuition.

God mappning åstadkommes när vi låter aktion och reaktion vara kopplade på ett enkelt sätt. Det bästa exemplet är styrdosans (musens) mappning till pekaren på skärmen. Vi för styrdosan mot en godtycklig riktning (för närvarande tvådimensionellt), och pekaren följer med i samma riktning på skärmen. När vi aktiverar knappar eller andra programparameteromställare i GUI ska reaktionen visualiseras i en lokal närhet. Om det ej går att framställa visualiseringen lokalt ska uppmärksamhetsbildande effekter göras. Den senare problemlösningen är inte att föredra, men olyckligtvis krävs den i vissa situationer.

Snabb feedback är nog det svåraste kriteriet, eftersom det för det mesta kräver god hårdvara. I dessa tider är hårdvaruproblemet av ringa natur, men felaktiga GUI-implementationer kan få de mest spektakulära system att bli oanvändbara. När användaren gör en aktion på GUI, ska reaktionen, om möjligt, aktiveras och visualiseras omedelbart. Om det inte är möjligt med omedelbar aktivering, ska det med enkel och tydlig visualisering medelas till användaren att beräkning pågår. Något som ökar användarvänligheten, är att grafiskt låta visualisera den tid som är kvar för beräkningsarbetet. Jag har skrivit om realtidsfeedback i de föregående kapitlet, och med denna term menar jag en omedelbar feedback med en lokal mappning, oavsett (polynomiell) beräkningskomplexitet. Detta är mycket svårt att realisera men ett mål som ska eftersträvas.

Enkel adaptation beror mycket på användarens tidigare kontakt med datorgränssnitt. Är de tidigare gränssnitten utformade på ett likformigt och konsekvent sätt, kommer inlärningstiden för den nya applikationen att minimeras om vi utformar gränssnittet i samma anda. Likformigheten kan lätt åstadkommas genom att betrakta andra applikationer inom samma ämnesområde och "kopiera" utseendet. Denna lösning kan te sig lite skral eftersom det inte innebär något nytänkande. Nytänkandet, bla att vi lär oss av våra tidigare misstag, är av stor vikt vid alla former av konstruktionsarbeten. Därför ska GUI-utvecklaren endast "kopiera" de mest grundläggande enheterna för att bibehålla likformigheten.

De mer specialiserade enheterna ska implementeras på ett logiskt och visuellt sätt liknande de grundläggande enheterna. Användaren ska inte tyngas av många programfunktionsomformare. Dessa ska finnas i minsta möjliga mängd men med största möjliga funktionallitet. Deras funktion ska på ett enkelt visuellt sett visas, antingen med ikon (grafisk symbol) eller text. Problemet med att använda ikoner är att användaren belastar minnet med att försöka komma ihåg deras funktion (om de är dåligt ritade).

Storleken på ikonerna är direkt proportionelt mot användarens förmåga för perception. Detta är ett problem eftersom datorskärmen inte är obegränsat stor. Antingen kan vi öka skärmupplösningen för att få med mera grafik och noggrannare ikoner eller ersätta ikonerna med enkla ord. Även meningar kan användas, men dessa blir oftast för långa, och vid extensivt användande av denna lösningsmetod, kommer användarens handhavandehastighet att minska p.g.a att det tar betydligt längre tid att läsa meningar än att erinra sig funktionen knuten till en bild. "En bild säger mer än tusen ord.", heter det som bekant. En modernare tappning på samma tema kan i detta avseende sägas: "En bra visualisering säger mer än miljoner böcker.".

Det är oftast nödvändigt att dela upp GUI i flera större sammanhängande block. Om dessa olika block har liknande funktioner, ska deras programfunktionsomformare vara placerade på ett sådant sätt att de logiskt lika funktionerna finns på samma plats i de olika blocken. Detta är konsekvens i ett nötskal och är väldigt viktigt att eftersträva vid GUI modellering. När en applikation inte är konsekvent inom sina egna ramar, kommer användaren slutligen att nödgas kasta denna.

Konsekvens är en stor faktor i handhavandehastighet, och detta är för varjedagsanvändaren mycket viktigt om hon vill arbeta effektivt. Likformighet kan även kallas global konsekvens (något som jag tycker blir ett för stark kriterium) och konsekvens kan även kallas för lokal likformighet (något som jag tycker blir ett för svagt kriterium). Huruvida vi ska eftersträva global konsekvens kan det tvistas, men för att förhindra monotoni borde det vara relativt fritt för egna tolkningar av kanske mera välskapta metaforer än de som finns tillgängliga i maskinen i fråga.

Interaktiv omformbarhet kan implementeras till olika grad, men vid alltför god omformbarhet blir applikationen personberoende. Detta är ett akut problem om grundmetaforen kan ändras, och borde indikera att vi inte ska implementera in absurdum. Vi kan låta användaren själv bestämma var programfunktionsomformarna ska vara belägna och vilken funktion de ska ha.

Låter vi denna idé sippra vidare, kan vi även låta programmet bli styrbart från ett yttre program eller hårdvara. Egentligen använder det yttre programmet/hårdvaran slavprogrammet som ett bibliotek av helt "vanliga" funktioner. Denna idé kan göras med exempelvis AREXX (Inom Unix världen heter det REXX), och slavprogrammet kan bli hur avancerat som helst. Om vi ska kräva fullständig interaktiv omformbarhet i applikationen, borde vi kräva en mycket bra datorarkitektur, och i dagens läge är det frustrerande att använda dessa system eftersom handhavandet blir långsamt efter ett tag (datorkraften sinar snabbt). Även om detta är ett faktum, ska vi sträva efter att realisera denna idé i en snar framtid med hjälp av goda algoritmer och god hårdvara.

Det som kanske borde vara det absolut viktigaste och som faktiskt användaren först uppmärksammar, är om hon kan återkalla ett felaktigt beslut. En nybörjare är dömd till att misslyckas i de första stapplande användarstegen i applikationen om GUI är inkonsekvent. Tankefel kan för en expertanvändare lätt återkallas, och hon tappar inte självförtroendet vid maskinen. Att ha förtroende för handhavandet är speciellt viktigt för kritiska applikationer, som exempelvis kan finnas i kärnkraftverk och flygplan.

Den största frågan är hur djup "ånger" som ska finnas. I de enklaste systemen kan användaren återkalla den senaste omformningen, men i bättre och mera komplexa system torde det krävas ett "oändligt" ångerdjup. Givetvis kommer minnesaspekten in i dessa implementationer. Vi kan lösa detta problem genom att låta användaren bestämma ångerdjupet under körtid. Låter vi ångerdjupet vara virtuellt oändligt, ska användaren kunna spola ångerstacken vid alla besläktade GUI instanser under programkörningen.

Något som ytterligare försvårar handhavandet av datorprogramvara, är om dess GUI är utformat på ett sådant sätt att programmet delas in i moder. Detta kan vara mycket farligt och användaren kan känna sig instängd. Detta inskränker kreativiteten, och handhavandet blir otympligt och ineffektivt. Problemet med att implementera ett GUI utan moder, är att programkomplexiteten blir extremt mycket större, och avlusningsarbetet blir i sin tur väldigt mycket mera svårartat. Det är inte själva programkoden som växer, utan de besläktade funktionernas oberoendegrad, som ska vara total. För att testa alla möjligheter som vi kan ändra programflödet med krävs exponentiellt mycket arbete (n st omformare ger n! olika omformnings kombinationer). Detta, och att vi enkelt kan bevisa att vi inte kan konstruera ett program som undersöker ett annat programs validitet, bevisar delvis mitt påstående om att ett komplext GUI aldrig blir färdigt.

Alla nybörjare, möjligtvis några expertanvändare, kommer att undra vad alla programfunktionsomformare är till för. De flesta kommer att lusläsa någon form av instruktionsmanual, men efter ett tags användande kommer denna att bli utsliten. Lösningen på detta problem är att låta skriva en elektronisk manual, som användaren kan åberopa när problem vid programkörningen uppstår. Detta finns i Amiga-OS i form av Amiga-Guide, som existerat sedan 1988 och är en hypertextbaserad hjälpguide. Denna är inte en fysisk utan en logisk del av programmet. Vi kan även implementera "instant help" medelanden som är belägna på ett sådant sätt att användaren lätt kan hitta dessa direkt i applikationen. Vanligtvis lägger vi dessa "instant help" meddelanden i applikationens huvudfönster, och uppdaterar denna när det krävs (omedelbar feedback är ett krav i denna lösning).

Gränssnittets språk mot användaren kan ibland vara en barriär. Eftersom det var ett engelsktalande land som först definierade ett datorspråk och gjorde den första hårdvaran, blev grundspråket för datorer (både hård- och mjukvara) engelska. Dåtidens användare var för det mesta vetenskapsmän, och de kunde engelska. Numera är användarna inte alltid vetenskapsmän, och för det mesta kan de inte engelska.Detta bereder ett stort problem, eftersom en användare som inte förstår skärmens text i sämsta fall överger applikationen. Ett ytterligare argument mot användandet av ett språk till alla gränssnitt, är de dåliga översättningar (användarens egna) som brukar inträda. Några typiska exempel är save (sejv, som egentligen ska vara spara) och load (leåd, som egentligen ska vara ladda). Dessa uttryck sprider sig som en löpeld, och användargruppen för applikationen kommer att utveckla ett "bispråk" till originalspråket. Dessa bispråk kan få denna grupp att stundom bli betraktad som om den härstammar från yttre rymden. En lösning på detta problem är att forma GUI på ett sådant sätt att det blir lätt att byta grundspråk. Detta har lösts i Amiga-OS mha Locale (implementerat som ett library (funktionsbibliotek)) där vi specifierar vilket språk och land vi använder respektive bor i. Sedan är det upp till applikationen (om programmeraren implementerat locale instansen) att använda sig av denna inställning.

Inspirationskällor

Eftersom det finns en sådan uppsjö av video-ray-tracers till Amigan, har jag främst betraktat deras gränssnitt för att få inspiration. I början av 1987 fanns Sculpt-3D som var tämligen avancerat, men med en långsam editor, trots att den visade modellvärlden i "wireframe". Wireframe betyder att modellen endast visar objektens kanter vilket medför att vi kan se igenom objekten. Användaren kunde bestämma vilken synvinkel hon skulle ha på modellvärlden i vardera vy (tre parvis ortogonala vyer). Förstoring, perspektiv och diverse andra behändiga funktioner fanns även att tillgå. Kravet att göra animerade sekvenser av de beräknade bilderna krävde grundläggande ombyggnad av programmet, som exempelvis implementationen av motion-blur (rörelseoskärpa). Programmet bytte i denna veva namn till Sculpt-4D. Dock var editorn fortfarande lika långsam, vilket gjorde det hopplöst att använda detta program vid större ritningar.

Dessa program var bland de första som såg dagens ljus på Amigan, och de hade relativt bra användargränssnitt. Ett program som inte är en raytracer men väl värt att notera är Videoscape. I detta program var modellvärlden visualiserad med riktiga ytor, och användaren kunde även här göra enkla animationer. Även i detta program var handhavandet lite jobbigt vid större ritningar. Det bör nämnas att jag menar jobbigt i Amigatermer. Ett förtydligande av detta är att en 3D-editor är väldigt beroende av hur snabbt grafiken kan ritas ut på skärmen (egentligen all GUI överhuvudtaget) och hur snabbt vi kan transformera vektorer. Själva transformeringen ska göras med huvudprocessorn om inte grafikprocessorn har rutiner för detta. Amigans grafikprocessor (Agnes) har inte vektortransformering inbyggd, men Bresenham´s linjealgoritm är hårdvaruimplementerad. Detta gav ett stort försprång, även om de första Amigorna hade en enkel MC68000 (bolaget Motorola's grundsten i MC68K familjen) som huvudprocessor.

Detta koncept har även de mera avancerade grafikdatorer som figurerat i diverse sammanhang. Dessa har emellertid realtids texturmapping och z-buffering implementerat i hårdvaran, plus mycket snabba RISC huvudprocessorer från bla MIPS. Silicon Graphics maskiner (företaget SGI grundades 1982) är bl.a. kända genom filmindustrins Industrial Light & Magic (se kaptiel om Virtual Reality) och för deras hårdvarubestyckning.

Det första professionella programmet (började med mycket små resurser) var Caligari och det var mycket intuitivt. I detta program hade användaren en vy att betrakta modellen igenom, och hon kunde välja mellan solid (hastighetsmässigt mycket långsamt) eller wireframe visualisering (hastighetsmässigt godtagbart). Här i Europa slog inte denna applikation igenom eftersom marknaden var för begränsad och fattig. Caligaris användargränssnitt var bättre än de samtida applikationerna, eftersom handhavandet var enklare och realtidsfeedbacken var utmärkt. Vi kunde flytta 3D-objekt i realtid som vanliga ikoner. Tidigt blev Amigans video-ray-tracers "industristandard", speciellt i USA och Kanada, men marknaden krävde ett bättre program. Programmet som efter ett större skönhetslyft från tidig implementation i Intuition v1.0 till Intuition v2.0 heter Imagine.

Denna programserie tycker jag är en dålig fortsättning på de tidiga Sculpt- programmen, även om de är mera användbara. Grunden till att jag tycker detta, är att deras GUI blivit alldeles för plottriga och grötiga när det handlar om definition av material och rörelsescheman. En person som inte har stort tålamod överger denna programserie väldigt snabbt. Trots dessa problem används applikationen flitigt bland tv-reklammänniskor i Amerika.

Mitt favorit program i dessa sammanhang är Real-3D (RealSoft från Finland). Ursprungsversionen var implementerad i gamla Intuition v1.0 och byggde på samma metafor som Sculpt-programmen. Den största skillnaden var att vyerna var implementerade i icke förändringsbara fönster, och vyerna hade specifika synvinklar som inte kunde ändras. Det vi såg var modellens tre vyer (uppifrån, från sidan och ortogonalt mot dessa) och en lista med modellens objekt i ett hierarkiskt träd. Bredvid listan fanns ett antal ikoner för snabb definition av objekt i modellen. Dessa ikoner var mycket ambivalenta, och användaren valde fel grundobjekt för det mesta. Ur denna synvinkel kan man tro att programmet var svårt att använda men där bedrar sig läsaren. Detta program var mycket enkelt att arbeta med och en förstaanvändare kunde göra något produktivt inom de första fem minuterna.

Det som denna första implementation föll på var animeringsdelen. Denna var långt ifrån väl mappad, och medelresultatet (data som innehåller själva animeringsekvensen och inte den färdigberäknade grafiken) hade fruktansvärd redundans. Dessa problem försvann och ett mycket eftertraktat skönhetslyft kom vid introduktionen av Real-3D V2.0 som grundar sig på Intuition v2.0. Något som tyvärr bortsågs i från var enkelheten, vilket har medfört att endast en mycket specialiserad grupp människor har attraherats av detta program. Dessa blir i sinom tid experter, och rent definitionsmässigt klingar inte detta väl med hur ett bra GUI ska vara utformat.

Programmet är kopplat till Amiga-Guide och därför har en sällan-användare relativt stor hjälp trots allt. "Detta skyler inte problemen, men lite hjälp är bättre än ingen hjälp alls, och programmet kan trots allt användas, dock ej effektivt!" Detta citat var från en sällan-användares tysta klagan. Något som inte finns i de andra programmen är ett enkelt funktionellt språk (av Lisptyp), som bla underlättar tillverkningen av rörelseschema. Med detta minispråk kan vi enkelt applicera våra egna fysikaliska lagar på objekten. Detta ger användarvänligheten både en positiv och en negativ riktning. Positiv eftersom det blir lättare att realisera verkliga förlopp. Negativ eftersom metaforen är högnivåprogrammering och mekanikkunskaper, vilket torde ge en vetenskapshatande användare allergiutslag. Förhoppningsvis kommer detta att ändras kraftigt i senare implementationer.

Det största och dyraste, emellanåt det bästa, video-ray-trace programmet heter Lightwave. Detta program är en stor vidareutveckling av Caligari och har ett helt eget GUI. Det använder inte Amiga standard GUI, vilket jag personligen tycker är en stor nackdel. Själva 3D-editorn är snabb och mycket behändig att arbeta med. Problemet som finns i denna applikation är de moder som uppträder. Användaren uppmärksammas inte av ett mode skifte, och detta kan te sig fruktansvärt frustrerande. Även definitionsdelarna för objekt-, material- och rörelsescheman är oerhört plottriga, och får en att reagera trots åratal av datorvana. Möjligtvis är de användare som är experter mycket toleranta, men det minskar inte problemen. Lightwave har använts exempelvis i tv-serierna Babylon-5 och seaQuest-DSV.

De andra video-ray-trace programmen (även på andra persondatorer) som finns att tillgå (i samma prisklass, mellan 5000 och 50000 kr) är inte ens värda att nämnas här, eftersom de lider av långt större brister. För de som i dagens läge vill bli imponerade, borde Silicon Graphics maskinerna ge den upplevelsen i form av IGRIP och Elastic Reality programmen. Dessa applikationer är emellertid väldigt dyra och inte riktade till allmänheten.

Min Lösningsform för Fönster

Jag har valt engelska till programmets grundspråk. Översättning till svenska och implementering av Locale användning är enkel men tidsödande. Den centrala delen i programmet är själva 3D-editorn, och därför är fönstret "3D View & Edit" huvudfönstret. Användaren torde tillbringa mest tid i 3D-editorn, och därför känns denna lösning sund. Större delen av detta fönster visualiserar ritningen tredimensionellt (för närvarande endast wireframe), och resten av grafikytan är sparsamt fylld med några viktiga omformare. I detta fönster har jag "instant"-hjälp, som är placerad nederst och visar den senast gjorda funktionen.

Själva modellen ska kunna roteras i rymden och jag har implementerat denna rotation som "Guds hand". Denna term använder jag eftersom modellen är realiserad som ett objekt uppbyggt av objekt, och inte som en värld uppbyggd av objekt. Egentligen är dessa implementationer likvärdiga, men sätten att rotera modellen är högst olika. Tänk att vrida föreläsningssalen istället för att gå omkring i denna.

Jag tycker personligen att denna lösningsform blir en bättre mappning, eftersom användaren sitter kvar vid datorn vid rotering av modellen. Vid en fortsatt vidareutveckling till en god VR-miljö är denna form inte att föredra, men själva huvudkoden är densamma i de båda implementationerna, och därmed är arbetet inte gjort förgäves. De omformare som roterar modellen har jag placerat i närheten av modellvisualiseringsgluggen, vilket ger en starkare mappning än om de är placerade i ett eget fönster. Denna lösning kan te sig lite dålig, eftersom vi inte har muspekaren där modellen finns (läs dålig mappning). Emellertid är skärmen bara tvådimensionell, och implementering av osynliga funktionsomformare för att underlätta rotering i den saknade dimensionen ger långt större felmappningar. Rotationsomformarna är av typen "sliders", och är orienterade i den riktning som världshuvudaxlarna har (X-axeln åt höger, Y-axeln uppåt).

3D-Audio’s huvudediteringsfönster där användaren kan flytta, rotera och skala både modell och specifika objekt.

Problemet med Z-axeln är att Amigans standardomformare (Intuition v2.0) inte har cirkulära sliders, och jag nödgades använda en rak slider till denna axel. Vi har två möjliga placeringsformer för Z-axel-slidern, en under Y-axeln eller en bredvid X-axeln. Jag valde att placera den under Y-axeln vilket visas ovan.

Problemet med att använda sliders till rotering är deras ändlägen. Vid ändlägena kan vi inte rotera vidare i ändlägesriktningen, och detta är frustrerande. Jag löste problemet med att placera små återställningsknappar, visualiserade med ett o som i origo, vid alla ändlägen. När användaren trycker in en återställningsknapp, kommer slideromformarens "knob" (Sv. skjutknapp) att placeras mitt mellan ändlägena. Det kan tyckas vara en god idé att låta muspekaren följa med vid dessa återställningar, men att låta muspekaren hoppa kan kännas förvirrande och därför har jag inte realiserat denna idé. Ytterligare en detalj är att modellen ska rotera i samma riktning som slider-knobens rörelse.

Eftersom jag endast har en vy synlig, krävs ett par snabbknappar som ger de vyer av modellen som är speciellt intressanta och mycket användbara vid modellerande. Dessa knappar kallar jag "Fast View", och de omformar visualiseringen till uppifrån, från sidan, ortogonalt mot dessa och fågelperspektiv. Utan dessa knappar hade det varit omöjligt att modellera. Omformningshastigheten för fastview är kritisk i modelleringen, eftersom den är väldigt beroende av dessa knappar (se 3D grafiska algoritmer). Grunden till att jag endast har en vy är att grafikutritning ska minimeras. Vid multipla vyer ska vi uppdatera i vardera vy när vi flyttar objekt. Detta resonemang visar att tiden för beräkningarna, om vi ska ha god feedback, blir lika många gånger längre som det finns vyer. Denna extravagans har jag inte råd med, och dessutom kan flera vyer ibland vara mycket förvirrande.

Normalt brukar vi kunna begrunda modellen i olika storlekar, och detta går även i denna programvara. Även här har jag medelst sliders löst problemet. Återigen finns två likvärdiga, men med helt olika känsla, sätt att mappa förstoringen/förminskningen. Antingen kan vi låta en uppåtgående rörelse beteckna en förminskning (vi skjuter objektet från oss) eller en förstoring (vi placerar vårt huvud närmare objektet). I enlighet med tidigare resonemang borde jag ha implementerat den tidigare formen eftersom användaren sitter kvar vid datorn. Detta har jag emellertid inte gjort, eftersom det kändes fel med en sådan mappning (läs inkonsekvent). Även om detta är inkonsekvent är denna djupt logisk och användare borde inte uppmärksamma den omedelbart.

Realiseringen av förstorings-slidern gav mig ett ytterligare problem som uppträdde vid trakterna för full förstoring. Den första lösningen var att jag implementerade slidern med en exponentialfunktion. Detta medförde rejält dålig mappning, och jag tvingades kasta konceptet. En inte lika dåligt mappad implementation var ett tillägg till det övre ändläget (visualiserat med +), som alternerade slidern från grov- till fininställning och vice versa. Även denna lösning är egentligen dålig, men användandet av två funktionellt lika sliders bredvid varandra ger större förvirring, och därmed implementerade jag den extra knappen.

För att öka realismen kan vi visualisera modellen i perspektivform. Två parallella linjer, som riktas ifrån oss, möts i oändlighetspunkten (i detta fallet mitt på modellvisualiseringsarean). Likt de föregående omformarna har jag använt mig av en slider som ökar perspektivet vi hög position. Grunden för denna mappning är bla att mixerbordets skjutpotentiometrar (den analoga motsvarigheten till sliders) ger mindre dämpning vid högre position (högre signalstyrka).

I själva modellvisualiseringsarean visar jag även modellens markplan med hjälp av ett 3D-nät. Detta nät kan medelst cirkulärmenyer inställas i den enhet och indelning som känns bäst för tillfället. Själva måttet ("measure") kan vara i meter, fot och avstängt. Vid avstängt är 3D-nätet inte visualiserat. Nätet kan ha olika storlekar ("grid size"), som gör det möjligt att modellera världen i delportioner. Denna funktion används oftast vid definition av objekt som ska ingå i många ritningar. Det är oftast en god idé att minimera inknappning av tal och i denna situation verkar detta vara sunt. För att förtydliga modellens orientering har jag överdrivit storlekarna för huvudaxlarna, och adderat X', Y', Z' vid deras positiva ändläge. Tillägget prim eftersom världens huvudaxlar är stilla, och detta undviker dålig mappning med namnen för roteringsomformarna.

Objekten i modellen visualiseras medelst en knappnål i objektets roteringscentrum. Användaren bestämmer själv var detta centrum ska vara beläget vid definitionen av objektet. När användaren ska flytta ett specifikt objekt, väljer hon objektet genom att placera muspekaren i knappnålshuvudet och trycka på musknappen. Muspekaren försvinner och hela objektet blir en muspekare och problemen med perspektiv (saker som är närmare färdas snabbare än de som är långt borta) kringgås. Ytterligare ett visualiseringsförtydligande är att modellarean trycks in i monitorn, vilket indikerar att objektet är taget och modellen i övrigt är stilla (läs "objektet har lyfts från modellen"). När användaren släpper musknappen placeras objektet på den position som visualiserats.

Objekten flyttas i det plan som skärmen visualiserar. Detta är grunden till de tre första fast-view knapparna. Planförflyttningar är att föredra, eftersom rymdförflyttningar blir konstiga och mycket dåligt mappade. Åtminstone i de implementationer jag gjorde, med bla hjälp-skugga, blev det så. Något som minskar grötighet, som brukar framträda i wireframe modeller, är att jag låter knappnålarna ritas sist i visualiseringen. Detta medför att alla är främst och inga objekt skymmer andra objekts knappnålar. I komplicerade ritningar kan dessa knappnålar vara mycket grötiga (överlappa varandra), och användaren ser inte vilken knappnål som hör till vilket objekt. Även enkla tvåobjekts modeller kan bli ambivalenta, eftersom objektens knappnålar kan projiceras på samma yta. Problemets lösning återkommer jag till senare, eftersom det ingår i förklaringen av ett subfönster som heter "Drawing-Pool".

Våra objekt ska vi kunna forma och rotera på ett enkelt sätt. En möjlighet är att låta flyttning, rotering och förstoring vara olika moder i programmet eller att ha en knappnål för varje enhet. Moder är helt uteslutet, och tre knappnålar per objekt blir för grötigt. Kan vi lösa problemet med en knappnål, skulle det kunna vara en möjlighet. Emellertid är mappningsfelen som uppstår (vi saknar en dimension) så stora att jag nödgades kasta denna lösning (till min förtvivlan).

Caligari och Lightwave har detta implementerat med moder plus osynlig knappnål, men jag lyckades inte använda dessa på ett välartat sett. Därför har jag implementerat storleks- och roteringsomformare av slidertyp för detta. Dessa är endast tillgängliga när användaren valt ett objekt. När en omformare inte är tillgänglig visas detta med att denna skuggas. Användaren kan ändra storleken i objektets huvudaxlars riktning, och vridningen av ett specifikt objekt mappas likvärdigt som hela modellen. Den största skillnaden är att alla roteringomformare är orienterade åt samma håll.

Detta indikerar en dålig mappning, men utformningen stördes av osymmetrin och jag fastnade för denna lösning. Storleksomformarna är även de orienterade åt samma håll, eftersom objektens orientering i modellen inte behöver vara riktade som i den icke primade världens, i detta fallet monitorns, fysiska läge. För att förtydliga objektets orientering i modellen, låter jag visualisera en "orienter" som visar objektets huvudaxlars (X", Y", Z") riktning. Vid storleksförändringar ska användaren kunna förvissa sig om att hon förstorar i rätt led. Trots att dessa omformare inte är i lokal närhet till själva omformningen, går det att använda dessa relativt effektivt. När användaren väljer och flyttar ett objekt, visas objektets placering i modellen (i förinställd måttenhet) nere i "instant"-hjälpen. Vid storleksförändringar visas objektets dimensioner (Width, Height och Depth i förinställd måttenhet) på samma plats. Om användaren stängt av 3D-nätet ritas inte objektens knappnålar ut och modellen får en klarare visualisering. Eftersom objektens knappnålar inte är visualiserade, kan användaren inte välja något objekt av misstag. Detta är en ren säkerhetsåtgärd.

Användaren behöver inte välja ett specifikt objekt (placera muspekaren i knappnåls-arean), utan kan ta tag i hela modellen (alla andra ställen i modellvisualiseringsarean) och flytta omkring denna i projektionsplanet. Det uppkommer lätt svårigheter med denna funktion vid återrupprepade vridningar åtföljda av förflyttningar. Vårt huvud är kvar och allt annat rör sig omkring oss, vilket medför att vi enkelt kan vrida modellen utanför tittgluggen och aldrig mer få se den. Därför återställer jag modellens vridcentrum till origo vid modellrotering, för att förhindra vilsefarelse. Förflyttning av modellen åtföljt av ett objektval, kommer inte medföra en återställning av vridcentrum. Detta medför att perifiera objekt blir lättare att placera, rotera och storleksförändra (speciellt om vi har ett mycket starkt perspektiv).

De flesta namn på omformarna är förkortade på något vis, men mått- och stolekomformarnas namn till 3D-nätet är fullständiga ("Measure" för mått och "Grid Size" för nät storlek). Problemet att ha förkortningar är inte nytt, och om de är speciellt dåliga blir förståelsegraden obefintlig. Modellförstoringsomformaren kallar jag Mg (Magnification, som brukar förkortas Mag.) och perspektivomformaren kallar jag Pr (Perspective, som brukar förkortas Pers.). Det kan kännas kryptiskt till en början, men de längre förkortningarna gjorde stora estetiska fel i utformningen, eftersom jag inte har en obegränsad yta att bygga på. Rotationsomformarna kallar jag X-, Y- och Z-Axis och dessa borde inte ge några större förståelse problem.

Objektstorleksomformarna (object sizers) är egentligen mycket kryptiska (SX = Size in X-led, SY = Size in Y-led, SZ = Size in Z-led) liksom objektroteringsomformarna (object turners, AX = rotation Angle around X axis, AY = rotation Angle around Y axis, AZ = rotation Angle around Z axis). Dessa förkortningar kan kännas något korthuggna, men onödigt mycket text är i vägen för ett effektivt användande. Användaren tenderar nämligen att läsa texten varje gång hon använder omformaren, trots att hon vet vilken funktion den har. Denna form av förkortning antyder en viss inkonsekvens, eftersom jag i de första fallen använde mig av de två första konsonanterna, och i de senare fallen begynnelsebokstäverna "godtyckligt" plockade från meningen. Emellertid känns det vid snarare eftertanke rätt med dessa förkortningar, eftersom de har tillräcklig information inbyggt i sig.

Snabbvy ("Fast View") omformarna är relativt perceptiva i denna anda, eftersom deras namn antyder vilken vy som kommer att visas (X-Y View, Z-X View, Z-Y View och Bird View). Dessa omformare skulle egentligen varit understödda av ikoner för att förtydliga vy-utseendet, men att rita oambivalenta ikoner är svårt i detta fall.

En viktig del i editering av modeller är hur vi delar upp objektens olika egenskaper och sammanför dem på ett enkelt sätt. Vi kan göra en datorbas modell mha E-R diagram och utifrån denna bygga gränssnittet. I detta fallet var det inte nödvändigt med diagram eller någon normaliseringsmetod, eftersom objekten innehar mycket primitiva delar. Min lösning grundar sig i dessa delar som är form, material och rörelseschema.

3D-Audio’s modellkoordineringsfönster som användaren manipulerar vid definition av objekt, material och rörelseschema.

Dessa primitiver sammanstrålar i ett modellkoordinerings fönster som jag kallar "Drawing-Pool" (DP). Alla koordineringsfönster har "pool" som efternamn i mitt program. Grunden till namnet pool (pöl) är den "oreda" som brukar uppstå vid koordineringsförsök (egentligen djurens beteende vid vattenhål på savanner).

Huvuddelen i DP-fönstret är listan där de olika objekten finns uppradade. I denna lista kan användaren välja ett specifikt objekt, och uppdatering sker både i DP (förtydliganden av namn, typ, material och rörelseschema) och "3D View & Edit" ("highlightning" av objektet i wireframemodellen).

Tidigare skrev jag om grötighet vid wireframe-modellering, och jag löste selekteringsproblemet på följande sätt. Först väljer användaren ett objekt i DP-fönstrets objektlista. Sedan trycker hon ner någon av shift-tangenterna (egentligen dålig mappning, eftersom jag inte visualiserar hur användaren ska göra i dessa fall), vilket indikerar att hon håller i objektet med båda händerna (exempelvis vänster hand på shift och höger på styrdonet eller v.v.), och kan därmed placera, flytta, rotera eller storleksförändra det specifikt valda objektet. Denna funktion överges i samma stund som användaren släpper shift-knappen, men om användaren vidhåller styrdonets knapp, håller hon kvar objektet för flyttning.

Vid sidan av objektlistan finns knappar som underlättar organisation av modellobjekten. I enlighet med tidigare fönster är den största visuella arean uppe till vänster, och omformare för editering till höger. De omformare som har tre punkter efter namnet indikerar att en frågande fortsättning blir följden av aktionen.

Den översta editeringsknappens funktion ("New...") är att skapa ett nytt objekt i modellen, genom att medelst en frågeställare fråga vilken typ av objekt som ska adderas. Metaforen är att vi åker till ett möbelvaruhus och köper möbler. När användaren valt den specifika "möbeln", placeras alltid denna i modellens origo, och visualiseringsuppdatering av huvudfönstret följer. De nya objekten är inte knutna till specifika material eller rörelsescheman. Detta visualiseras med "NO TYPE AT ALL" (möbel typ), "NO MATERIAL ASSIGNED" (möbel material) och "NO FLIGHT ASSIGNED" (möbelns rörelseschema) i respektive upplysningsareor.

Användaren kan sedan välja vilket material objektet är gjort av mha "Select..."-knappen i linje med materialvisningsarean. Denna knapp ger upphov till en frågeställare där användaren anmodas att välja ett material. Specificeringen av rörelseschema är identisk fast där anmodas användaren att välja en "flygrutt" i stället. När användaren valt dessa enheter kan hon namnge det nyligen skapta objektet i modellen. Detta gör hon i "Name" omformaren. Namnändring ger upphov till en uppdatering av objektnamnlistan.

Om modellen ska innehålla flera objekt med samma morfologi och material, kan användaren kopiera redan existerande objekt med "Copy"-knappen. Objekt som är överflödiga eller på annat sätt visats onödiga i modellen, kan med "Delete"-knappen raderas. Vid radering läggs objektet överst på DP-fönstrets "göra ogjort"-stack, och kan återkallas med den större "Undo"-knappen. Om användaren vill radera hela modellen, kan hon aktivera "Clear"-knappen, och alla objekt läggs på "göra ogjort"-stacken. Denna funktion är endast implementerad som konsekvensfrämjande åtgärd eftersom den finns i de andra poolerna (med mycket större användningsgrad).

När användaren, efter en stunds rearrangering av modellen, vill återgå till huvudfönstret för objektplacering, gör hon detta genom att trycka på "Edit..."-knappen. Detta medför att huvudfönstret appliceras framför alla fönster och aktiveras med det valda objektet i "highlight"-form. Egentligen är färgmappning av ondo och bör undvikas i största möjliga mån. Grunden till detta är att även färgblinda personer ska kunna använda programmen. Emellertid är DP-fönstrets namnlista den huvudsakliga mappning där användaren ska undersöka vilket objekt som är valt. Grötigheten vid wireframevisualisering kräver denna lösning.

Användaren kan själv definiera egna objekt genom att aktivera "Drawing->Object..."-knappen. Denna funktion gör om hela modellen till ett enda objekt som bara består av den morfologiska strukturen. Metaforen i denna tanke är att kreatören skickar sin nya möbel till möbelfabriken för kloning.

Aktiveringsknapparna är alla av texttyp, eftersom deras funktioner är vanliga och mycket inrotade. Därför har jag inte använt mig av ikoner för dessa, trots att areabesparingarna blivit betydande och möjligen kunnat placera ikonerna i huvudfönstret. Även viss plottrighet undvikes när vi utformar GUI på detta sättet med stora "barnvänliga" knappar med viss luftighet omkring sig. Svårigheterna vid placering och formning av knappar för minsta möjliga användarfel, kan minimeras om vi placerar närbesläktade funktioner närmare varandra, och de icke fullt lika besläktade på betydande avstånd. En knapp som inte följer dessa kriterier är "göra ogjort"-knappen ("Undo"), som bör placeras närmast den mest fatala funktionen och minst vara av dubbel storlek mot de andra knapparna.

Möjligen är objektdefinitionsknappen svårtydd, eftersom den antar användarens kunskap om "->"-operatorn i språksammanhang. Denna språkoperator betyder omformning av enhet X till enhet Y (X->Y) i detta fallet. Rent logiskt känns denna definition rätt, men huruvida allmänanvändarens perception godtar detta intuitivt kan i vissa fall diskuteras. Emellertid är meningar av längre art onödigt invecklade och i mitt tycke störande i det annars rena utseendet (speciellt i detta fallet).

3D-Audio’s specifika hämtfönster för primitiva objekt, material och rörelseschema. Vid affirmering kommer användaren automatiskt tillbaka till modellkoordineringsfönstret.

De tre hämtplatser för objekt ("Object Pool"), material ("Material Pool" , MP) och rörelseschema ("Flight Pool") är baserade på en frågeställsarketyp. Denna arketyp är egenhändigt formad och är inte en del i "Amiga-GUI requester library". I samma anda som tidigare har jag en lista med namn till vänster, editeringknapparna till höger och namnomformare nederst. Deras funktioner är identiska med de som finns i DP-fönstret. Användaren ska välja det för objektet passande kriterier från dessa hämtplatser, och avsluta med att trycka på "Ok!" knappen eller, om någon felanvändning uppstått, på "Cancel" knappen. Dessa affirmeringsknappar är placerade i enlighet med riktig "Amiga requester layout". Definition av nya och omformning av äldre enheter, är för närvarande endast möjligt i MP fönstret.

Vid definition och omformning av material öppnas ett frågeställarfönster ("Characteristics"), där användaren definierar diverse materialegenheter. Egenheterna, som är placerade överst, är namn, typ (möbel, sändare, mottagare) och färg (ska användas i en fortsatt implementering med solidframe modellering). Nedanför dessa omformare finns en graf som visar materialets frekvenskarakteristik. Grafen visar absorptionkurvan om det är en möbel, och frekvensgång för de andra typerna (sändare och mottagare).

Här använder jag mig av tanken att alla objekt egentligen kan betraktas som filter. I denna graf kan användaren på frihand rita frekvenskarakteristiken, och vid första omformningen trycks grafen in i monitorn för att förtydliga att en förändring är gjord. Eftersom absorptionskoefficienter inte mäts i alla frekvensband, skuggas de områden som inte används i beräkningarna.

3D-Audio’s material definieringsfönster som användaren kommer till om hon tryckt på ”New...” eller ”Edit...” på materialhämtplatsen (”Material Pool”).

Under denna graf är riktningsomformarna placerade. Dessa är placerade under respektive frekvensoktav för god mappning. Här kan användaren bestämma vilka riktningar reflektionen, sändningen eller mottagningen har vid olika frekvenser (Läs ljudets natur och audiobehandling för att förstå terminologin). Även denna frågeställare har affirmeringsknapparna nederst. I motsats till mitt tidigare resonemang för placering av "göra ogjort"-knappen har jag placerat denna mellan affirmeringsknapparna.

Det var estetiskt fel att placera denna bredvid frekvensgrafen (höger sida för att följa konsekvensen). Emellertid är det fortfarande i linje med att finnas vid större fatala omformare (även om den inte är precis närgränsande). Utformningen av materialdefinieringsfönstret har vissa likheter med frågeformulär av den mera avancerade typen. Denna metafor kan vid rätt utformning bli en mycket god kontaktyta, eftersom formulär är mycket väletablerade i den västliga civilisationen.

3D-Audio’s beräknade strålgång visualiseras i detta fönstret och användaren har möjlighet att välja vilken relativ luftfuktighet som råder och vilken av modellens öron (receivers) som ska ligga till grund för impulssvaret nederst.

När strålföljningen beräknas öppnas ett datavisualiseringsfönster ("Computed Data", CD). Detta fönster är fortfarande på betastadie, eftersom den riktiga implementationen ska finnas i auraliseringsmodulen. Överst till vänster visar jag de parametrar strålföljaren är inställd på. Dessa beskrivs i kortast möjliga koncisa engelska, eftersom grafikarean krävs till viktigare saker. En mycket viktig graf är efterklangsdistributionen, som visar efterklangstiderna i olika frekvensband. Dessa tider är beräknade mha Sabine's formel.

Vidare kan användaren välja specifik luftfuktighet från en cykel meny ("R. Humidity"). Medan datorn beräknar strålgången, kommer den vid lyckade beräkningar att visualisera (amplitud beroende på strålväg) dessa i echogrammet nederst i fönstret. En stapel som visar hur mycket av beräkningarna som är kvar visualiseras i detta echogramblock. Även om denna visualisering är bra, understryker jag alla längre beräkningsinstanser med att ändra muspekarens utseende. Pilen omvandlas till en klocka om användaren har standardinställning i "Pointer Preferences" (inställningsprogram för Amigan). Vid färdig strålföljning kan användaren välja vilken mottagare som ska visualiseras i echogrammet med hjälp av cykelmenyn "Receiver".

3D-Audio’s förinställnings fönster ("Preferences") där användaren kan specificera var de olika dataenheterna ska placeras i just hennes datorsystem.

För att göra livet enklare och roligare för användare, har jag implementerat ett fönster för grundinställningar. Här kan användaren bestämma var hennes lagrings areor ska finnas för modeller, möbler, material, rörelseschema och beräknade strålgångar.

Antingen kan användaren skriva i namnomformarna eller trycka på "Set...", som medför att en lagringsfrågeställare aktiveras. Även applikationens grundfärger kan ställas in om så önskas. Färgomformarna är av standard Amiga-GUI-typ vilket innebär att färger delas upp i tre komponenter (R= Red, G= Green, B = Blue). Dessa komponenter är mycket väl rotade i Intuition och används bla i "Palette Preferences" (inställningsprogram för Amigan). Användaren väljer först färg och sedan skjuter hon slideromformarnas knobar till de rätta positionerna. Färgerna ändras simultant vilket ger relativt god mappning.

I Intuition V3.0 finns ett färghjul för bättre mappning, men problemet att införskaffa nödvändiga fakta för användningen av denna har inneburit att jag tvingades implementera den sämre varianten. Nederst finns återigen affirmeringsknapparna som i detta fall är något mer komplicerade än tidigare. Om användaren gör fel trycker hon som vanligt på "Undo Edits"-knappen och om hon inser att hon inte behöver göra några omformningar trycker hon på "Cancel". När programmet startar laddas detta fönsters inställningar in och används. Därför kan användaren spara ("Save Edits"), för framtida bruk tills ny omformning åtföljd av "Save Edits" görs, eller använda utan att spara inställningarna ("Use").

Vid längre modelleringssessioner kommer användaren att glömma vilken "möbelaffär", "råvaruaffär" och "flygbolag" hon besöker. Därför har jag implementerat ett upplysningsfönster ("About Window"), som visar dessa och modellens namn. Även de två minnesformernas (fast- och chipram) tillgänglighet och programtillverkarens namn visas. De tre olika typer av objekt som kan finnas i en modell, skrivs ut för att upplysa användaren om hur komplex modellen är. Dessa siffror är direkt proportionella mot strålgångberäkningstiden (högre siffror ger längre beräkningstider).

3D-Audio’s förstahjälpen fönster där användaren kan se vilka primitiver som är inladdade och hur komplex modellen är. De två olika minnessorternas tillgänlighetsgrad visas i antalet bytes.

Förutom alla dessa fönster finns en mängd upplysnings-, affirmerings- och frågeställsfönster. Dessa har jag implementerat för att användaren inte ska kunna göra större fel, som att exempelvis förlora modellen vid utträde från programmet. I figur 4.8 visar jag ett axplock av de extra fönstren som finns i programmet, och som användaren kan konfronteras mot vid "hutlös" användning.

Frågeställarfönster uppkommer vid alla former av sekundärminnesaktivitet. Dessa är Intuition's egna "file requesters" för att programmet ska vara likformigt med alla andra Amiga program. En form av frågeställarfönster är de som endast kräver affirmering (affirmeringsfönster). Dessa sorters fönster har vi bla när användaren ska göra en större omformning (utträde från program, radera projektet mm.).Vid byte av modell, objektpöl, materialpöl och rörelseschemapöl, kommer applikationen att fråga om användaren vill kasta ändringarna om sådana blivit gjorda. Om användaren vill göra totalt utträde eller en fullständig återställning av programmet, kommer även detta att ifrågasättas om ändringar blivit gjorda. I fallet med flera ändringar kan vi bunta de olika enheterna till ett fönster, vilket ger en bättre överblick. Enheterna ska skrivas ut i samma ordning som de uppträder i programmet för att bibehålla konsekvensen.

Upplysningsfönster används när ett användarfel uppstått, och kan innehålla ett mer eller mindre intelligent felmeddelande. I de flesta grafiska användargränssnitt är användarfel av en mycket lätt natur, och därmed enkla att forma ett felmeddelande av. Emellertid är de användarfel som uppstår vid hämtning av programdata på något sekundärminne av en mycket svårare natur.

Eftersom jag sparar alla data som produceras från applikationen i en editerbar form (användaren kan läsa datat i en vanlig texteditor och ändra i denna), kan användaren editera fel. Dessa fel ska hittas och ge ett okryptiskt felmeddelande vid försök av laddning. Jag har endast implementerat beräkning av felets radnummer, vilket kommer att kommenteras senare i "Min lösningsform för arbetsbänken".

Affirmerings knappar ska vara av texttyp för att minimera ambivalens. Standarden som ska följas i Intuition är att den "fatala" omformningen görs vid aktivering av den vänstra knappen i affirmeringsfönstret ("Ok!", "Quit Program!", "Erase Data!"). För att komma ifrån möjliga handhavandemisstag aktiveras högra affirmeringsknappen ("Cancel"). Denna knapp ska aldrig ändra text för att minimera förvirring. Däremot är de fatala omformarna (vänsterknappen) mycket klarare om vi använder specialskrivna meningar vid blockaffirmeringar.

När endast en affirmeringsknapp finns, ska denna spegla problemets natur. Om användaren gör fel, ska knappens text stå i JAG-form för att öka påminnelsen om att användaren gjort fel ("My Fault!"). Detta borde få användaren att hata felanvändning efter ett tag. Problemet kan senare bli att användaren irriteras av datorn och dess "besserwisser" fasoner.

Problem av lägre natur (exempelvis felinstallering av programvara) som inte påverkar applikationen i större utsräckning, ska givetvis inte ge upphov till dessa starka upplysningsformer ("Never Mind!"). Grunden till min användning av dessa ordval, är att de program som uteslutande använder sig av knappen "OK", förr eller senare kommer i ett tvetydigt stadium, och att ändra misstagsknappen är att bryta mot reglerna. Det ska vara lättare att rätta misstag än att göra dem.

Ett axplock ur 3D-Audio’s frågeställar-, affirmerings- och upplysningsfönster.

Min Lösningsform för Menyer

Ytterligare detaljer som underlättar handhavandet är menyer. Dessa finns bla för att undvika multipla tangentnedtryckningar för olika funktioner. Utformning av menyer ska även följa gränssnittets övriga natur och vara mycket lika andra program. Enligt Intuition standard ska projektomformningar finnas först, och därefter ska editeringverktyg finnas. Efter dessa kommer mera programspecifika omformare. Även om multipla tangentnedtryckningar ska undvikas, finns de i form av nedtryckning av höger Amiga-tangent plus en vanlig tangent. Denna form visualiseras automatiskt i menyn av Intuition. Dessa funktioner ökar användareffektiviteten utan att förstöra nybörjarvänligheten.

I varje applikationsinstans, kan användaren aktivera de nödvändiga menyfunktioner som är kopplade till det aktiva fönstret. Vi kan implementera lokala menyer, och de är specialutformade för varje användarfönster. Detta ger användaren mycket förvirrande känslor, eftersom stora visuella menyändringar inom applikationsramen ger dålig lokal likformighet. Jag löste denna svårighet genom att låta menyn vara en globalmeny. Problemet med denna lösning är att användaren kan aktivera fel funktioner vid fel instanser. För att undvika dessa problem och leda användaren till rätt funktioner, låter jag de ickebesläktade menyfunktionerna vara inaktiva (skuggade) i alla specifika fall.

De i "Project" menyn implementerade funktionerna är "New" (Fullständig återställning av hela applikationen), "Open..." (Laddning av modell, objektpöl, materialpöl, rörelseschemapöl, framåtstrålföljningsdata och bakåtstrålföljningsdata), "Merge..." (Sammanslagning av modeller, objektpölar, materialpölar och rörelseschemapölar), "Save" (Sparande av modell, objektpöl, materialpöl och rörelseschemapöl utan namnbyte från tidigare namn), "Save As..." (Som "Save" men med ett eventuellt namnbyte från tidigare namn), "About..." (Öppnar upplysningsfönstret "About Window") och "Quit..." (Avslutar programmet med frågeställningar).

3D-Audio’s projekt meny som används vid alla externa förhavanden. Vidare kan användaren erhålla förstahjälpen fönstret genom denna meny , och om hon vill avsluta modelleringssessionen kan ett totalt utträde göras.

Eftersom detta program är riktat till större arbetslag, vilka ska arbeta parallellt, är uppdelning av programdata mycket viktigt. Några i arbetslaget modellerar medan andra gör material och möbler. Vidare kan några applicera rörelseformer på de objekt i modellen som är klara. Sammanslagningsfunktionerna ("Merge") är till för detta.

De funktioner som finns i "Editing Windows" är endast för att placera respektive fönster främst och undvika grötighet på skärmen. Uppdelningen i två block är gjord pga att de tre nedersta är av frågeställartyp, eftersom de översta är huvudediteringsfönster.

När användaren inte har tillgång till en stor högupplösande monitor, kommer skärmen vara nerlusad av överlappande fönster, och för att underlätta letandet finns denna meny. Aktivering av en specifik menyrad medför att det fönstret kommer överst.

Strålföljarens parametrar och aktivering är visualiserade i "Tracer" menyn. Noggrannhetsparametrarna är alla av samma uppräkningstyp ("High", "Medium", "Low", "Auto"), och deras funktionsnamn är koncist formade. Även om de är av den längre texttypen, är dessa funktioner av lågfrekvent användartyp. Användaren spenderar längre tid för modellerandet än vid parameterinställningar, och därmed är effektivitetskravet av ringa vikt i detta fall. Egentligen är denna form av parameterinställning av ondo, eftersom användaren inte har någon överblick över inställda funktioner. Återigen ska det påminnas att strålföljningsdelen fortfarande är på betastadiet. Andra blocket i denna meny är för aktivering av strålföljningsberäkningsdelen i applikationen. Tredje blocket är för visualisering av redan beräknade data.

De olika parametrarna för själva strålföljningsalgoritmen har försatts till denna meny. (Obs! Beta stadie)

De funktioner som inte platsar i andra menyer, samlar vi i slutet av menyraden ("Miscellaneous"). Denna meny ska inte betecknas som någon "slaskmeny" för överflödiga funktioner, utan den ska innehålla viktiga funktioner. Funktioner som är av vikt i mitt program är radering av specifika "göra ogjort" stackar ("Clear >>" , >> betyder att submenyer finns) och öppnandet av användargränssnittets grundinställningsfönster ("Preferences...").

När datorminnet tryter kan det vara en god idé att tömma diverse "göra ogjort högar". Användaren kan genom denna meny aktivera förinställningsfönstret.

Min Lösningsform för Arbetsbänken

Applikationens tillhörande dataenheter ska visualiseras på arbetsbänken ("Workbench") med enkla ikoner. Dessa ikoner ska visualisera vad dataenheterna innehåller (Se figur 4.13), och användaren kan omdefiniera dem i "Icon Editor" (standard Amiga environment program) för att passa hennes behov bättre. Dataenheternas ikoner samt förinställningar och primitiva objekt, material och rörelseschema är belägna i en speciell map ("3DA-Prefs"). Alla dessa ikoner och datafiler kan användaren själv omforma efter sitt tycke genom en lämplig systemeditor. Inskrivning av siffror har jag undvikit i huvudprogrammet, eftersom strålföljningsnoggrannheten är låg.

Egentligen är alla former av sifferrepresentation stötande för de användare som inte är tekniskt inriktade. Vid ett flertal tillfällen har jag uppmärksammat användare som övergivit en applikation för dess överflödiga representation av siffror. Kan vi utesluta större sifferblock ökar vi användarvänligheten (personligen älskar jag siffror). De användare som är intresserade av stor noggranhet kan "dubbel-klicka" på en dataenhet. Detta medför att favoritordbehandlaren startas, och i sin tur laddar in dataenheten. I mindre kryptiska ordalag är ikonen knuten till ordbehandlaren, och inte till mitt huvudprogram. Emellertid kan detta enkelt ändras genom att ändra "Default Tool" i ursprungsikonerna, som är belägna i submapen Icons.

Den enda användarvänligheten i dessa editerbara dataenheter, är att textrader föregås med $ och sifferrader med #, plus att ett huvud upplyser användaren vad det är för sorts fil. För de som tycker att det är konstiga tecken, vill jag förtydliga att dessa är en kvarleva från BASIC-tiden, och jag tyckte att de passade i detta fall. Egentligen ska det finnas en tvåvägs kompilator (mellanspråk<->språk) till denna enhet. Detta har jag emellertid satt lägsta prioritet på, eftersom huvudprogrammet inte är fullständigt. Implementeringen av en tvåvägs PHIGS (Programmer's Hierarchical Interactive Graphics Standard) konsistent kompilator eller interpretator (parallell körning under ARREX) är bara det ett specialprojekt.

Ett möjligt scenario på arbetsbänken. De olika dataenheterna är logiskt och fysiskt åtskilda även på lagringsmediat. Själva förinställningsenheterna finns i 3DA-Prefs och här kan användaren själv sätta egna primitiv-filer som ska laddas vid uppstart av 3D-Audio. Vidare är standard ikonerna förlagda i ett underbibliotek "Icons", där användaren själv kan omforma dataenheternas ikoner, och vilken typ av program som ska köras vid dubbel klick på ikonen.

Utformningen av dessa ikoner är gjorda på en "naiv" nivå. Exempelvis är rörelseschemaikonen visualiserad som ett flygplan. Vidare är materialikonen tagen från signalfilterstandarden (tre vågor ovanpå varandra). Objektikonen är ritad som en fritt svävande kub medan modellikonen är en liten modell med mark. Förinställningsikonen är utformad som ett frågeformulär i miniatyrform. De två möjliga beräkningsmetoderna framåt- och bakåtstrålgång visualiseras med en högtalare och mikrofon med pil riktad åt rätt håll. Ikonen för huvudprogrammet är en stiliserad variant av A3D (Audio 3D), som ska likna en mikrofon i ett ljudfält. De som inte lyckas tyda ikonen på detta vis ska inte oroa sig nämnvärt. Vid start kan applikationer kräva olika startparametrar ("WBArgs" som betyder WorkBench Arguments eller "CArgs" Command line interface Arguments).

Huvudprogrammets ikon där användaren kan ställa in vilken skärmupplösning hon vill arbeta med för just denna applikation (WBArgs).

Dessa parametrar kan beskriva minneskrav och skärmupplösning mm. Jag implementerade skärmupplösningsparametern i detta försteg, eftersom applikationen troligtvis endast installeras en gång per maskin. Engelsk Amigastandard kräver att "HIRES" eller "SUPERLACE" ska adderas till "Tool Types" som upp- lösningsord för likformighetens skull.

Ikoninteraktionsflöde

Ikonflödesschemat visar kommunikationen mellan de olika programdelarna. Heldragen pil betyder att data genereras och används. Streckad pil betyder att editering inte är tillrådlig. Tjock heldragen linje betyder huvudprogrammets grepp.

3D Transformeringsalgoritmer

...real computer scientists rarely use numbers larger than 255...

Andrew S. Tanenbaum

I förra avsnittet skrev jag om människa-dator-interaktion (MDI) och dess krav. Den viktigaste delen i mitt program, om vi beaktar MDI, är den tredimensionella grafiska editorn. För att denna ska vara användbar bör de basala algoritmerna inom 3D-modelleringen optimeras till bästa möjliga grad. Vi kan dela upp 3D-modellering i följande bitar: skalning (storleksförändring), translatering (förflyttning), rotering och projicering. Anledningen till att vi här betraktar projicering är att vi visualiserar på en 2D-skärm. Skalning och förflyttning kräver inte någon större beräkningskraft, och projicering är inte överdrivet behäftat med svårigheter. Däremot är rotering den i särklass mest tidskrävande operationen. Jag bortser från linje- och areautritningar, eftersom Amiga har detta implementerat i hårdvaran. I denna sektion visas den algoritmoptimering som följt från 1987 (Bas Algoritmen) till 1994 (Diskret Optimering Typ III = DOT³) av roteringsalgoritmen.

Varje program har flera svaga länkar med tonvikt på beräkningshastighet, och det är dessa vi ska optimera. Optimering ska göras när vi har en välformulerad algoritm, som har lägst komplexitet bland andra algoritmer som löser samma problem. Gränsen mellan optimering och algoritmutveckling är mycket suddig. Skillnaderna mellan DOT¹ och DOT³ algoritmerna skulle kanske benämnas algoritmutveckling och inte optimering. Dessa algoritmer är i princip väldigt enkla (när vi ser lösningarna i skriven form) och borde inte ge större huvudbry. För att fullständigt förstå algoritmerna kräver jag att läsaren kan algebra plus Motorola mnemonic. Emellertid är optimering väldigt svårt, och programproducenter brukar inte lägga ner tid och pengar på detta. Den som inte är intresserade av optimering och datorns primärspråk kan hoppa över denna avdelning, dock betraktar jag dessa sidor som nyttig läsning, eftersom dessa algoritmer och deras för- och nackdelar är mycket viktiga att förstå.

Jag har implementerat DOT³ algoritmen i flyttalsform för att få större vetenskaplig konsistens i applikationen. Trots att flyttalsoperationer är mycket långsammare än vanlig diskret aritmetik, är DOT³ algoritmens kraftfullhet så stor att flaskhalsen ligger i grafikprocessorn. Obs! Med vanliga ECS-Agnes är detta sant, men inte med AGA-Agnes (två olika generationer grafikprocessorer till Amiga datorerna). Detta medför att användbarheten är lika bra på en A-500 (MC68030 huvudprocessor på 50 MHz och MC68882 matematikprocessor på 60 MHz - dessa IC's är från Motorola) som på en A-1200 (MC68020 huvudprocessor på28 MHz men utan matteprocessor!). Ytterligare förtydligande är att MC68020 inte har data cache och inte lika stor instruktionscache som MC68030. I vidare implementationer med AAA-Agnes (ej släppt grafikprocessor) torde det krävas den diskreta implementeringen av DOT³ algoritmen för att mjölka datorn på all kraft.

Bas Algoritmen

De enheter som är lämpliga att betrakta omvärlden med, är bredd (X-led), höjd (Y-led) och djup (Z-led), som jag kallar huvudaxlar. Märk att dessa är ortogonala (rätvinkliga) mot varandra. När vi har denna världsuppfattning kan vi fortskrida med olika operationer. De basala operationer som ska kunna göras är att vrida modellen runt huvudaxlarna. För vridning runt en huvudaxel kan vi använda oss av 2D-roteringar, eftersom punkternas placering i roteringsled inte ändras.

Rotering av ett block i Z-led med 270º visar invariansen i Z-led.

När vi vrider runt Z-axeln kommer alla punkter $(x, y, z)$ att omformas till $(x', y', z')$ på följande sätt:

Formel 1: $Turn_z(x,y,z,a_z)$

\begin{array}{l|l} \hline x'=x \cdot \cos(a_z)-y \cdot \sin(a_z) & (1.x) \\ y'=x \cdot \sin(a_z)+y \cdot \cos(a_z) & (1.y) \\ z'=z & (1.z) \\ \hline \end{array}

När vi vrider runt X-axeln kommer alla punkter $(x, y, z)$ att omformas till $(x', y', z')$ på följande sätt:

Formel 2: $Turn_x(x,y,z,a_x)$

\begin{array}{l|l} \hline x'=x & (2.x) \\ y'=y \cdot \cos(a_x)-z \cdot \sin(a_x) & (2.y) \\ z'=y \cdot \sin(a_x)+z \cdot \cos(a_z) & (2.z) \\ \hline \end{array}

När vi vrider runt Y-axeln kommer alla punkter $(x, y, z)$ att omformas till $(x', y', z')$ på följande sätt:

Formel 3: $Turn_y(x,y,z,a_y)$

\begin{array}{l|l} \hline x'=z \cdot \sin(a_y)+x \cdot \cos(a_y) & (3.x) \\ y'=y & (3.y) \\ z'=z \cdot \cos(a_y)-x \cdot \sin(a_y) & (3.z) \\ \hline \end{array}

Efter diverse förenklingar och omstuvningar kan vi samla ovanstående 3 formler i en allmängiltig formel med 12 multiplikationer och 6 additioner:

Formel 4: $Turn_{zyx}(x,y,z,a_z,a_y,a_x)$

\begin{array}{l|l} \hline y_1=y \cdot \cos(a_x)-z \cdot \sin(a_x) & (4.y_1) \\ z_1=y \cdot \sin(a_x)+z \cdot \cos(a_x) & (4.z_1) \\ x_1=x \cdot \cos(a_y)-z_1 \cdot \sin(a_y) & (4.x_1) \\ z'=x \cdot \sin(a_y)+z_1 \cdot \cos(a_y) & (4.z_2) \\ x'=x_1 \cdot \cos(a_z)-y_1 \cdot \sin(a_z) & (4.x_2) \\ y'=x_1 \cdot \sin(a_z)+y_1 \cdot \cos(a_z) & (4.y_2) \\ \hline \end{array}

Nu ser vi enkelt problemet med roteringar, eftersom vi behöver snabba trigonometriska funktionsberäkningar. Enklast löser vi detta genom att placera de trigonometriska faktorerna i pseudokonstanter (se programmeringsmetodik för termförklaring), vilka beräknas i Initiatus för funktionen. Detta medför att matteprocessorn inte blir överbelastad och hastighetsmässigt är det klart fördelaktigt att göra på detta sättet. Här följer en möjlig implementering av basalgoritmen, och läsaren ombedes att uppmärksamma frånvaron av matrisimplementation i datastrukturen. Grunden till detta är att vi behöver all kraft till algoritmen och inte till att upprätthålla datastrukturen.

    /******************************************************************
    * Denis Tumpic 1987                                               *
    * Dimenzione 3.                                                   *
    * Extract from Slave Function: Turn_Coordinates                   *
    ******************************************************************/
    .
    .
    .
    /**************************************************************
    * Initiatus : Precalculation of turn angles which are placed  *
    *           in pseudoconstants                                *
    **************************************************************/
    sax=Sin(ax): cax=Cos(ax)
    say=Sin(ay): cay=Cos(ay)
    saz=Sin(az): caz=Cos(az)

    /**************************************************************
    * Itera Computa : Operate turnmatrix over all coordinates     *
    **************************************************************/
    Iterate next chunk thru i from 0 to Number_Of_Coordinates with
    positiv discrete monotonic:
            tempY=sourceY[i];
            tempX=sourceX[i];
            tempZ=sourceZ[i];
            Y1=tempY*cax-tempZ*sax;
            Z1=tempY*sax+tempZ*cax;
            X1=tempX*cay-Z1*say;
            destinationZ[i]=tempX*say+Z1*cay;
            destinationX[i]=X1*caz-Y1*saz;
            destinationY[i]=X1*saz+Y1*caz;

Diskret Optimering Typ I

Det första som slår oss av basalgoritmens utseende är dess beroendegrad av trigonometriska beräkningar. Smådatorer har sällan extra matematikprocessorer och det är en fullkomlig omöjlighet att implementera basalgoritmen i flyttalsform på dessa maskiner om realtidsfeedback är ett krav. Vi kan lösa problemet genom att ge upp noggrannhetskravet. Monitorns upplösning är låg (1280x570), och därför krävs egentligen inte flyttalsberäkningar. För att kunna kasta dessa måste vi göra de rätta approximationerna, eftersom för låg upplösning (beräkningsmässigt) är ren vetenskaplig vedervärdighet.

Först delar vi upp cirkeln i 256 delar, för enkelhetens och effektivitetens skull. Därefter kan vi generera en sinus- och cosinus tabell (sammanflätade) på 640 byte, som basfunktionen kan hämta färdigberäknade data ifrån. Varje funktionsvärde har 16 bitar, multiplicering med 32768 är då möjlig, vilket ger minst två värdesiffror. Det kan kännas meningslöst att göra denna diskretisering. Lite tankearbete klargör för oss att vi mestadels kommer att rotera objekt. Detta eftersom vi roterar objekt inuti andra objekt, och alla objekt flyger omkring i modellen i varje instans. För förtydligande hänvisar jag till den starka definitionen av VR-miljöer i förra kapitlet.

Hastighetsförändringen är så pass stor att vi enkelt kan konstruera ett fraktalt landskap med 100 punkter och 300 linjer, som vi kan rotera i realtid (25 ggr/s) på en vanlig A-1000 (MC68000 på 7.14 MHz). Följande programlistning är en tidig assemblerimplementation till IGG (Inter Gigantica Galactica - Den fullständiga VR-miljön):

    /******************************************************************
    * Denis Tumpic                                                    *
    * Pre Inter Gigantica Galactica                                   *
    * 1987-1988                                                       *
    * Slave Function: Turn_Coordinates                                *
    *   a0 : Pointer to Source_Coordinates                            *
    *   a1 : Pointer to Destination_Coordinates                       *
    *   a6 : Number_Of_Coordinates                                    *
    *   ax, ay, ax : Turn angle around x-axis, y-axis, z-axis         *
    *cc instruction              remark                               *
    ******************************************************************/
    TurnCoords                  ;Initiatus
lea      SinTable,a2    ; ->SinTable data fetch start address
lea      CosTable,a3    ; ->CosTable data fetch start address
move.b   ax,d0          ;Get angle AX
and.w    #$FF,d0        ;Clear highbyte
asl.w    #1,d0          ; *2 givs relative table pointer
move.w   0(a3,d0.w),d1  ;d1=Cos(ax)
move.w   0(a2,d0.w),d2  ;d2=Sin(ax)
move.b   ay,d0          ;Get Angle AY
and.w    #$FF,d0        ;Clear highbyte
asl.w    #1,d0          ; *2 givs relative table pointer
move.w   0(a3,d0.w),d3  ;d3=Cos(ay)
move.w   0(a2,d0.w),d4  ;d4=Sin(ay)
move.b   az,d0          ;Get angle AZ
and.w    #$FF,d0        ;Clear highbyte
asl.w    #1,d0          ; *2 givs relative table pointer
move.w   0(a3,d0.w),d5  ;d5=Cos(az)
move.w   0(a2,d0.w),d6  ;d6=Sin(az)

    TurnLoop                    ;Itera Computa
move.w   2(a0),d0       ;d0 = y
muls     d1,d0          ;d0 = y*Cos(ax)
move.w   4(a0),d7       ;d7 = z
muls     d2,d7          ;d7 = z*Sin(ax)
sub.l    d7,d0          ;d0 = y*Cos(ax)-z*Sin(ax)
asl.l    #1,d0          ;d0 = d0*2
swap     d0             ;d0 = d0/65536 -> Normalized Y1
move.w   d0,a3          ;Y1 = a3 = d0
move.w   2(a0),d0       ;d0 = y
muls     d2,d0          ;d0 = y*Sin(ax)
move.w   4(a0),d7       ;d7 = z
muls     d1,d7          ;d7 = z*Cos(ax)
add.l    d7,d0          ;d0 = y*Sin(ax)+z*Cos(ax)
asl.l    #1,d0          ;d0 = d0*2
swap     d0             ;d0 = d0/65536 -> Normalized Z1
move.w   d0,a4          ;Z1 = a4 = d0
move.w   (a0),d0        ;d0 = x
muls     d3,d0          ;d0 = x*Cos(ay)
move.w   a4,d7          ;d7 = Z1
muls     d4,d7          ;d7 = Z1*Sin(ay)
sub.l    d7,d0          ;d0 = x*Cos(ay)-Z1*Sin(ay)
asl.l    #1,d0          ;d0 = d0*2
swap     d0             ;d0 = d0/65536 -> Normalized X1
move.w   d0,a5          ;X1 = a5 = d0
move.w   (a0),d0        ;d0 = x
muls     d4,d0          ;d0 = x*Sin(ay)
move.w   a4,d7          ;d7 = Z1
muls     d3,d7          ;d7 = Z1*Cos(ay)
add.l    d7,d0          ;d0 = x*Sin(ay)+Z1*Cos(ay)
asl.l    #1,d0          ;d0 = d0*2
swap     d0             ;d0 = d0/65536 -> Normalized Z'
move.w   d0,4(a1)       ;Z' = d0
move.w   a5,d0          ;d0 = X1
muls     d5,d0          ;d0 = X1*Cos(az)
move.w   a3,d7          ;d7 = Y1
muls     d6,d7          ;d7 = Y1*Sin(az)
sub.l    d7,d0          ;d0 = X1*Cos(az)-Y1*Sin(az)
asl.l    #1,d0          ;d0 = d0*2
swap     d0             ;d0 = d0/65536 -> Normalized X'
move.w   d0,0(a1)       ;X' = d0
move.w   a5,d0          ;d0 = X1
muls     d6,d0          ;d0 = X1*Sin(az)
move.w   a3,d7          ;d7 = Y1
muls     d5,d7          ;d7 = Y1*Cos(az)
add.l    d7,d0          ;d0 = X1*Sin(az)+Y1*Cos(az)
asl.l    #1,d0          ;d0 = d0*2
swap     d0             ;d0 = d0/65536 -> Normalized Y'
move.w   d0,2(a1)       ;Y' = d0
addq     #6,a0          ;Increase source pointer
addq     #6,a1          ;Increase destination pointer
subq     #1,a6          ;Decrease coordinate counter
bne      TurnLoop       ;Transform until no more coordinates
        rts

De siffror som står i början av raderna är inte radnummer, utan antalet klock cykler (cc) som krävs för att fullborda operationen. Summering av dessa värden ger att Initiatus behöver 254 cc och Itera Computa 1162 cc per koordinat. Märk att både data- och adressregister har använts som mellanlagring för att öka hastigheten. Dataregistren d1 till d6 är pseudokonstanter och ska inte förstöras i Itera Computa. Därför nödgas vi använda adressregister för mellanlagring. Extern minnesaccess medför nämligen minst 4 cc/acces extra tid. Även om waitstate problem inte finns på Amigan ska vi alltid minimera externaccesser. Speciellt ska vi göra detta om vi har waitstate-arkitektur där vi har flera processorer som samsas om bussen på ett ickesynkront sätt.

Diskret Optimering Typ II

Från basalgoritmens beräkningstunga (över 100000 cc per koordinat (cck)) sfär till DOT¹ algoritmens beräkningslätta (1162 cck) slankhet, tycker de flesta att vidare optimeringar inte är nödvändiga. Emellertid är det ett lockande mål att implementera algoritmen under 1000 cck. Beräkningskraften ligger på multiplikationerna (max 70 cc/mult) och innehar 840 cc av hela beräkningen. Om vi kunde eliminera de tolv multiplikationerna skulle vi få upp hastigheten ytterligare. Lösningen blir, som vi tidigare insett, att generera en färdigberäknad tabell med alla möjliga multiplikationer. Problemet med denna implementering är att tabellen tar mycket minne.Om vi inte tar i rejält och använder oss av 8 bitars (256 värden) aritmetik, kan vi generera en tabell på 160 kB (640*256 byte). Det största problemet med denna algoritm är att vi inte kan ha en högupplösande modell, och att höja aritmetiken till 16 bitar kräver 40 MB minne. Vidare blir precisionen i kanterna ännu sämre i denna implementering än i DOT¹. För att lösa upplösningsproblemet kan vi modellera i små " 256-världar " som konkateneras på ett lämpligt sätt. Denna lösning kommer även att öka precisionen i kanterna. Rent implementeringsmässigt tänkte jag tidigt använda mig av denna lösning, eftersom jag enkelt hamnar under 1000 cck. Egentligen skulle den komma ner till 600 cck, men eftersom det krävs lite mer dataskyffling än tidigare, hamnar den omkring 900 cck. Däremot är konkateneringen inte helt trivial, och nästa algoritm gav mig andra idéer.

Själva principen för hur de små 256x256x256 enheters världarna konkateneras med överlappning (konkateneringsrymd). Denna bestämmer direkt hur stort det största objektet (del av objekt vid fullständig hierarkisk struktur) i modellen kan vara. Beräkningar behöver bara göras på de enheter som vi ser för stunden, och algoritmen kan lätt delas upp på flera processorer om vi antar att de olika objekten är oberoende.

Diskret Optimering Typ III

De tidiga algoritmerna är gjorda i slutet av -80 talet, och de flesta känner nu att där inte finns så mycket mer att göra. Emellertid är det ett mycket lockande mål att komma under 500 cck. Det borde finnas smartare sätt att implementera roteringsalgoritmen på, och om vi använder oss av lite algebra och verkligen försöker förstå vad kommutativitet (jämför med att vrida en bok först 45º runt x-led och sedan 45º runt y-led och v.v.) innebär, kommer algoritmen att vidareutvecklas till följande fröjd:

    /************************************************
    * Denis Tumpic                                  *
    * IGG30++ 1994                                  *
    * Extract from Slave Function: Turn_Coordinates *
    *************************************************
    x'=x; y'=y; z'=z

    if (daz)
           x1=Cos[daz][x']-Sin[daz][y'];
           y1=Sin[daz][x']+Cos[daz][y'];
           x'=x1; y'=y1;
        if (dax)
           y1=Cos[dax][y']-Sin[dax][z'];
           z1=Sin[dax][y']+Cos[dax][z'];
           y'=y1; z'=z1;

        if (day)
           x1=Cos[day][x']-Sin[day][z'];
           y1=-Sin[day][x']+Cos[day][z'];
           x'=x1; y'=y1;

Märk att jag använder mig av vinkelskillnader istället för absoluta vinklar. Observera dock att dessa vinkelskillnader kan vara godtyckligt stora (modulo 256). Notera även omformningen till en algoritm som rent komplexitetsmässigt ändrat karaktär från att vara en algoritm som alltid tar lika lång tid (isokron algoritm), till en tre falls algoritm (icke isokron algoritm). Vidare är Initiatus inbyggd i Itera Computa. Denna insikt medför att vi helt och hållet kan bortse ifrån matematikprocessorn, och användningen av tabellen i DOT² medför att vi nu är nere under 500 cck. Som mest (Worst Case) behövs lite mindre än 300 cck och i bästa fall ungefär 140 cck. Jag vågar inte säga att denna implementation är den nedre gränsen för rotationer, eftersom jag två gånger tidigare misstagit mig på denna punkt. Emellertid gör denna algoritmimplementering det möjligt att rotera mer än 20000 koordinater per sekund på en vanlig A-1000, med en huvudprocessor MC68000 på 7.14 MHz (Basalgoritmen klarade ungefär 70 st). Eftersom jag vill vidhålla den vetenskapliga tonen i applikationen, implementerade jag denna helt i flyttalsform (AOT³). Hastighetsmässigt är AOT³ snabbare än den flyttalsanaloga varianten av DOT¹, och det medförde möjligheten att flytta större objekt i 3D-modelleringen med mindre hackiga rörelser.

Eftersom dagens stora turbulens kring huvudprocessorer medför ett skede av tveksamhet, har jag inte programmerat algoritmen i assembler. Algoritmens enkla struktur kanske indikerar att en RISC baserad dator får en bättre implementering. Däremot är de många externaccesserna det stora problemet. Dessa algoritmer kräver ett snabbt minne utan waitstates.

Om vi kan åstadkomma en multiplikation snabbare än en dataflyttning, faller dessa algoritmer som ett korthus. Vidare ska vi kanske tycka att en hårdvaruimplementering av AOT³ algoritmen borde vara standard i en VR-maskin. Hur Hewlett-Packard implementerat roteringsalgoritmen i sina CAD-program, som använder HCRX-grafikkort (detta klarar att rita 2.3 miljoner 3D-vektorer/sekund om huvudprocessorn kör på 100MHz), vet jag inte. Det bör inte vara helt olikt min lösning om hastigheten satts till ett primärmål.

Ljudpropagerings-Algoritmer

Eine Hauptursache philosophischer Krankheiten - einseitige Diät: man nährt sein Denken mit nur einer Art von Beispielen.

Ludwig Wittgenstein

Detta avsnitt handlar om ljudpropagerings algoritmens utveckling. I motsats till 3D transformerings-algoritmer, vilka är mycket välformulerade, är ljudpropagerings algoritmerna inte lika fullt välformulerade, och därmed inte förlagda i ett optimeringsstadie. Algoritmutveckling börjar alltid med att vi ställer upp ett hypotetiskt sätt att lösa problemet på. När vi har en välformulerad hypotes som fungerar vid möjlig implementering, ska hypotesen förbättras på ett sådant sätt att beräkningskomplexiteten blir mindre för algoritmen. på ren svenska innebär det att vi ska utföra mindre arbete, och resultatmässigt ska de båda algoritmerna ge identiska svar.

Vi har två världar att förpassa våra algoritmer till. Beroende på vilken av dessa vi väljer, påverkar det beräkningstiderna direkt. I den första och mest vetenskapliga världen har vi en helanalytisk lösning på problemet. I den andra styckar vi upp problemet i diskreta bitar och löser detta med minskat krav på noggranhet, vilket medför betydligt kortare exekveringstider. Vidare ska vi alltid förhindra algoritmer som ger exponentiell ökning av minneskrav eller exekveringstid, beroende på ökning av mängden indata.

Först beskriver jag den helanalytiska problemlösningen, för att sedan övergå till den heldiskreta. Efter dessa kommer den mycket välkända spegelkällemetoden, som används vid exempelvis beräkning av vågledare (telekommunikation), och vidare det relativt nya strålföljnings (ray-tracing) synsättet. En väl avvägd blandning av spegelkällemetoden och ray-tracing berörs, och en liten avstickare som jag kallar ellipsoidapproximering beskrivs. Ovanstående algoritmer medförde snabbt tanken, att implementera ljudpropagerings-algoritmen med en välformulerad heuristik, för att möjliggöra realtidsfeedback. Avslutningsvis beskriver jag den minst vetenskapliga metoden "Cut & Paste Ray-tracing" och dess brister.

De böcker som influerat mig i denna avdelning är Room Acoustics avHeinrich Kuttruff, Audio Engineering Handbook sammanställd av K. Blair Benson, An Introduction To Ray Tracing sammanställd av Andrew S. Glassner, Advanced Animation and Rendering Techniques av Alan och Mark Watt.

Helanalytiska Lösningen

Det första vi alltid ska försöka oss på är den helanalytiska lösningen. Om vi lyckas med att implementera en helanalytisk lösning kommer vi inte att ha approximationsfel. Märk att jag avser en datoralgebraisk lösning på problemet. Även om algebraiska lösningar är mera matematiskt korrekta, är dessa mycket tidsödande att lösa. I de få enkla fall det går att lösa på algebraiskt sätt ska vi göra det, men i huvudsak är problemen av mycket svårare natur.

Heldiskreta Lösningen

Efter det platta fallet med den helanalytiska lösningen, kan vi fösöka oss på en heldiskret lösning. Följande exempel får tjäna som grund: Vår värld innehåller en vägg och ett ljudgenererande objekt. I detta fall kommer vi att få ett direktljud och ett reflekterat ljud, om vi placerar lyssningsobjektet på samma sida som det ljudgenererande objektet. Detta enkla fall kan vi beskriva enkelt med en vågekvation, och lösa relativt snabbt med någon finita-elementmetod (FEM) eller rand-elementmetod (BEM).

Om vi betraktar den starka VR-definitionen, inser vi att vår modellvärld innehåller många objekt, och dessa har inte linjära ytor. Vare sig de är ljudgenererande eller inte, kommer dessa att ge upphov till olinjära vågekvationer. Vi kan nu fråga oss hur många vågekvationer vi behöver för att lösa ljudpropageringsproblemet heldiskret. Eftersom alla objekt (n st) interagerar, krävs minst n*(n-1)/2 olinjära vågekvationer. Varje objekt kan ge upphov till en diskontinuitet om de inte diffrakterar ljudvågorna, och denna är dessutom frekvensberoende. Vidare ska vi beakta luftmassornas (diverse refraktionseffekter), objektens rörelser (doppler effekt) samt temperaturfluktuationer, vilket ger ytterligare olinjäriteter i vågekvationerna.

Om vi begränsar oss till inneslutna rum och delar upp vågekvationerna i frekvensväg, kommer det att krävas ca 1.8*109 differentialekvationer för varje punkt vi betraktar i rummet och om vi betraktar frekevensintervallet 0-10 kHz [29] (löses med en lämplig FEM).

Ur detta gigantiska ekvationssystem ska vi konstruera modellvärldens impulssvar i de punkter som vi har mottagare i. När vi väl lyckas ställa upp dessa, ska de beräknas i realtid med en hastighet på fS ggr/sekund. Grunden till den höga beräkningshastigheten är att exempelvis dopplereffekten och dispersionen ska bli fullständigt realiserade. Efter denna enkla match ska vi bara auralisera modellen, och den totala audiomediala VR-miljön är ett faktum.

Även om vi har tillgång till universums snabbaste datorer, verkar det fruktansvärt ineffektivt att lösa problemet på detta viset. Det tar nämligen kortare tid att bygga flera fysiska fullskaletestriggar, och dessutom blir det billigare, trots att vi troligtvis kommer att riva ett stort antal av dessa innan vi blir nöjda.

I en variant av FEM, delar vi upp modellen i små kubiska enheter som är disjunkta, men närliggande i rymden och innehar diverse egenheter. Egenheterna kan variera från att vara hur de interagerar med varandra till rörelsen i rymden. I enlighet med den starka VR-definitionen ska vi stycka upp modellen i den minsta urskiljbara bitarna. Detta medför att vi rent audiomedialt kräver en enhetsupplösning på ca 17 mm för att få med 20 kHz. Problemet med denna lösning är det stora minneskravet (typiskt för ett vanligt rum 8*106 *antalet egenheter) och beräkningarna, som även de blir fruktansvärt tunga. Det finns implementationer [30] (ej fullständig FEM), [31] (specialfall) av denna lösningsform, men även här nödgas vi kasta konceptet eftersom realtidsfeedback knappast är möjlig.

Möjligen blir metoden realiserbar om vi låter varje objekt vara en nod i en fullkopplad graf. I denna lösning är dimensionen n*(n-1)/2 istället för tre, och därmed kommer egenheterna att öka i samma grad. Varje objekt ska ge upphov till uppdateringar av strålflöden i varje annat objekts egenheter. Vidare medför rörelseschemakravet att alla egenheter är variabla i varje beräkningsinstans. Observera likheterna med neurala nätverk. Om vi betraktar vad diffraktion medför ska grafen stundom urarta från fullkopplingen, och detta ska ske automatiskt. Problemet med denna metod är att snabba förlopp kommer att förlängas i tidsdomänen. Denna förlängning (utsmetning, dispersion) av ljudet medför att klarheten och rymdkänslan försvinner. Emellertid är lösningen god om modellen är statisk.

Spegelkällemetoden

Efter två hopplösa varianter krävs lite andra angreppssätt. I spegelkällemetoden låter vi ljudvågor propagera som ljusvågor (räta linjer), och detta är en väsentlig skillnad mot de tidigare formerna. Detta medför att vi betraktar ljudfältet som diffust. Löst uttryckt är ett diffust ljudfält en homogen ljudtrycksfördelning utan fasskillnader. Vidare är diffraktion, dispersion och alla de andra olinjära faktorerna ej representerade i denna lösningsform (men kan läggas till i efterhand). Figuren på nästa sida visar hur metoden fungerar i 2D-fallet.

Som vi märker är denna metod mycket minneskrävande, eftersom vi kräver att modellen är uppkopierad i minnet till den grad att alla reflektioner till $T_{60}$ (efterklangstiden) kan beräknas. En normal modell kan typiskt uppta 100 kB av minnet. Låter vi $T_{60}$ vara en halv sekund medför detta att strålar med högst 170 m längd ska beräknas. Rummet, som är ungefär 5*2*4 meter, ska då uppkopieras 34*85*43 gånger för att få med alla strålar. Minneskravet blir hela11 GByte !!! Detta är inte det enda problemet med denna metod. Eftersom vi har rörliga objekt i hela modellen, ska vi uppdatera (vrida och translatera varje kopia) modellvärlden i varje förändringsögonblick. Tyvärr medför dessa saker att realtidsfeedback blir smått omöjligt, trots att vi kan använda oss av en ortogonalspecialiserad DOT³ algoritm. Fördelen med denna metod är att vi har hundraprocentig hitrate.

Definition Hitrate: Hitrate är kvoten mellan antalet säkert nödvändiga strålträffar och det möjliga antalet nödvändiga strålar.

Strålföljningsmetoden (Ray-tracing)

Om vi släpper kravet på en hundraprocentig hitrate, kan vi sprida strålar likformigt rundstrålande från alla ljudkällor. Dessa strålar låter vi sedan reflekteras mot objektens ytor. Vi låter dessa fortsätta att reflekteras i andra objekt tills ljudenergin är minimal eller en ljudmottagare träffats. Ljudenergin blir minimal (örats hörtröskel) vid $T_{60}$ och vi behöver inte följa strålen längre, vilken därmed kastas. När vi betraktar modellen från ljudkällorna kallas det forward ray-tracing (från ljudmottagare kallas det backward ray-tracing). Resultatet från framåt- och bakåtstrålföljning är inte samma eftersom strålarna inte har samma ursprungspunkt (små vinkelavvikelser i början ger stora avvikelser mot slutet).

Även ray-tracing kräver att vi har ett diffust ljudfält, eftersom strålarna, egentligen små strålande koner, sprids ut allt mer ju längre de propagerat. Oberoende vilken form av ray-tracing vi implementerar, ska vi lagra strållängden och dess filtreringssvar. Filtreringssvaret beräknar vi enklast genom att multiplicera ihop de objekts absorptionskurvor som ingått i strålens väg (se appendix B för förtydligande). Vidare kan vi lagra träffarnas infallsvinklar på mottagaren, och därmed enkelt skala bort de onödiga träffar som inte är med i direktiviteten.

Ray-tracing metoden är inte ny, och i sin ursprungsform medför den vissa problem. Det största problemet är att den har en fruktansvärt dålig hitrate (<2%). Detta betyder att 98% av beräkningarna är bortkastade (en beräkning på 10 h skulle tagit mindre än 12 minuter!). Detta är priset vi får betala när vi inte vill använda så mycket minne som i spegelkällemetoden.

    Primal Ray-tracer Code:

    Definition Max length:
            Computed reverberation time with Sabins's formula
            multiplied with the soundvelocity through air.

    Definition Hit object:
            An object that mostly reflects rather than diffracts
            soundrays.

    Definition Transceiver:
            Objects that transmits (loudspeaker) or receives (ear)
            sound.

    Definition Hit point:
            Ray impact area on hitobject.

    Definition Omnidirectional:
            Uniformly select angles from (0..2¶, 0..2¶, 0..2¶)

    Definition Clean hit:
            When the ray-tracing cone hits a specific hitobject or
            transceiver.

    Master (Depth First Algorithm) function Trace:
        Iterate over omnidirectional tracing rays.
        Ray-trace until:
            Transceiver hit or if raylength exceeds Max length.
        When detected a Clean hit memorize:
            Raylength, absorptionresponse and impact angle.

    Slave (Recursive or/and Iterative) function Ray_Trace:
        Compute nearest possible Hit object and reflect ray specularly through the new Hit point.
        Multiply this Hit object absorptionresponse with:
            Previous absorptionresponse in this recursion.
        Depending on depth and grade of diffusion:
            Smash ray into several directions and recurse.

Den första implementeringen av denna algoritm gav flera viktiga slutsatser: mycket lång exekveringstid och mycket låg hitrate. Efter diverse primär- och sekundäroptimeringar kunde dock exekveringstiden mer än halveras (diverse kvadratrotsborttagning och färdigberäkning av objektytornas normaler och utsträckning). Även om vi är på god väg är det emellertid fortfarande omöjligt att få realtidsfeedback.

Ellipsoidapproximeringsmetoden

Betraktar vi omvärlden rent morfologiskt, visar den oss att allt är mer eller mindre kantigt. Om vi bortser från objektens kantighet, som speciellt färgar ljudet vid höga frekvenser, kan vi betrakta alla objekt som superellipsoider. Ellipsoider av hög grad är mera lika rätblock än ellipsoider. Vidare är beräkningshastigheten omvänt proportinell mot ellipsoidgraden (hög grad medför långsammare beräkningar). Med denna metod har vi mindre förutberäknade data att handskas med, och därmed är den mera minneseffektiv. Ytterligare fördelar är att denna metod får enklare uttryck för beräkningen av strålträffar och reflektionsvinklar (oavsett grad). Trots dessa möjligheter medför hitraten (bedrövliga <0.1%) att denna metod inte ska implementeras.

Hybrid-metoden

Ett smart drag kan vara att sammanföra spegelkällemetoden med ray-tracing-metoden. Här låter vi modellen uppkopieras i en mindre omfattande mängd än tidigare (typiskt 3*3*3 stycken modeller). När vi beräknat de "exakta" reflektionerna i spegelblocket, kan vi fortsätta med ray-tracing i respektive modellrum som strålarna befinner sig i.

Märk vikten av transformeringsalgoritmernas effektivitet i denna lösnings- metod. Även om det mestadels är ortogonala speglingar vi handskas med blir realtidsfeedbacken lidande. Emellertid kommer hitraten öka till mycket bättre nivåer, och om vi bortser från strikta VR-miljöer är denna metod mycket användbar.

En stor fördel med denna metod är att vi enkelt kan implementera denna lösningsform i parallell exekveringsform. Detta kan vi göra om vi bortser från interferens och maskning (vilket vi kan göra). Problemet läggs nu på processortillgången och den ortogonalspecialiserade DOT³ algoritmen. Här börjar en viss lättnad krypa fram, eftersom vi nu ser en möjlighet att lösa problemet. Emellertid är denna lösning fortfarande mycket dyr, och fortsatt hjärnverksamhet skadar inte.

En Heuristisk Metod

De tidigare metoderna har inte givit oss några större "wow"-upplevelser precis, och nu tar vi fram universallösningen nummer ett. Medelst en lämplig heuristisk funktion (matematiskt kallas de objektiva funktioner) kan vi öka hitraten till en sådan grad att vi möjliggör realtidsfeedback. Problemet är att hitta denna funktion, och detta lär vara det som tillsammans med GUI utformning tar längst tid att skapa.

    Denis Tumpic's Heuristic Ray-tracer Code:

    Definition Max length:
            Computed reverberation time with Sabins's formula
            multiplied with the soundvelocity through air.

    Definition Hit object:
            An object that mostly reflects rather than diffracts
            soundrays.

    Definition Transceiver:
            Objects that transmits (loudspeaker) or receives (ear)
            sound.

    Definition Hit point:
            Ray impact area on hitobject.

    Definition Clean hit:
            When the ray-tracing cone hits a specific hitobject or
            transceiver.

    Definition Looking range:
            Circular cone that spreads(¶/2) from the hitpoint with
            the direction of specular reflection.

    Definition Diffuse hit:
            When the path from ray-trace hitpoint to transceiver
    surface is in the lookingrange and free from hitob
    jects.

    Master (Pseudoprobabilistic Heuristic) function Trace:
        Iterate over ray directions that point onto objects.
        Ray-trace until:
            Transceiver hit or if raylength exceeds Max length.
        When detected a Clen hit memorize:
            Raylength, absorptionresponse and impact angle.

    Slave (Recursive and Iterative Heuristic) function Ray_Trace:
        Compute nearest possible Hit object and reflect ray specu
        larly through the new Hit point.

        Compute nearest possible Hit object.
        Multiply this Hit object absorptionresponse with:
            Previous absorptionresponse in this recursion.
        When Diffuse hit detected:
            Damp ray then memorize:
                raylength, filterresponse and hit direction.
            End recursion.
        Depending on depth and grade of diffusion:
            smash ray into several directions and recurse.

I denna modell betraktar jag alla objekt som möjliga mottagare av direktljud. Beroende på hur sändarens direktljud faller mot betraktningsobjektet (läs infallsvinkel), dämpar vi signalen i lagom mängd. Enklast är det att använda sig av cosinus funktionen för denna del. Infallsvinkel på 90º ger ingen dämpning, och parallella ljudvågor (om de finns) blir totalt utdämpade. Denna approximation kan te sig mycket grov i början. En jämförelse med de tidigare approximationerna, diffust ljudfält och oändligt stora och släta objektytor, vilket är kravet för att ray-tracing ska fungera, visar dock att den är av mindre magnitud.Ytterligare fördelar med denna metod, är att vi enkelt kan implementera diffraktion som ett normalt steg i heuristiken. Dispersion, refraktion och direktivitet kan på ett tidigt stadium invävas i heuristiken, vilket dock medför att exekveringshastigheten blir kraftigt reducerad.

Jämförelser

Nedan följer några jämförelsedata på de olika algoritmerna jag implementerat och provat på mitt eget vardagsrum. Observera att detta (47 m³) egentligen är för litet för att Sabine's formel ska fungera riktigt bra. Reflektionsdjupet är satt till femtio reflektioner (vilket är väldigt mycket i ray-tracing-sammanhang).

\begin{array}{l|c|c} \hline Algoritmnamn & max Hitrate \% & Exekveringstid \\ \hline Ellipsoidapproximering & 0.1 & 6 h \\ Primal Ray-tracing & 2.8 & 8 h \\ Nosqareroots Ray-tracing & 2.8 & 7 h \\ Precalc. Normal Planes (PNP) Ray-tracing & 2.8 & 4 h \\ Diffuse PNP Ray-tracing & 9.2 & 4 h \\ Heuristic Diffuse PNP Ray-tracing & 54.5 & 12 min !!! \\ \hline \end{array}

Dessa algoritmer har alla givit likartade svar. Vidare har sampling av mitt vardagsrum med ett enkelt handklapp visat sig överensstämma (åtminstone i början) med de beräknade impulssvaren. Med tanke på de grova approximationer vi tvingas göra, blir det relativt godtagbara resultat.

Cut & Paste Ray-tracing

Avslutningsvis denna djärva ovetenskapliga metod (om vi betraktar den rent matematiskt). Märk att vi inte behöver beräkna längre än Tr (tiden för efterklangens inträdande), eftersom efterklangen inte betraktas som en distinkt ljudkälla. Det vi kan göra är att låta strålfölja de tidiga reflektionerna (Cut), och sedan mha dessa syntetisera fram de sena reflektionerna (Paste). Enklast gör vi detta genom att translatera "Cut" till tiden efter den sista beräknade reflektionen i "Cut". De translaterade reflektionerna åtföljs av att vi tidsmodulerar dessa med en lämplig funktion, dessa är "Paste" bidraget. Tidsmoduleringen kan även vara färdigberäknad efter existerande modeller eller efter välformulerade sannolikhetsmått. Observera att efterklangen inte skall beräknas i detta steg, eftersom noggrannheten avtar med strålföljningslängden och onödigt många beräkningar görs. Efterklangen behöver inte hög noggrannhet eftersom denna är odistinkt.

Eftersom vi vill åstadkomma realtidsfeedback i audiomediala VR-miljöer, torde Cut & Paste Ray-trace metoden vara den enda som kommer i närheten av en möjlighet. Tillsammans med heuristisk ray-tracing, kan vi med små medel åstadkomma något som påminner om ett försteg till den starka VR-definitionen. Detta låter sig göras om vi sänker realtidskravets beräkningshastighet från fS ggr/s till fDIRAC ggr/s. I enlighet med "spaciousness", behöver fDIRAC vara omkring 8000 Hz, för att fullständigt efterlikna inkommande ljuds riktning.

Förekommande Implementationer

De olika implementationer som cirkulerar är spegelkällemetoden [32, 33], ray-tracing [34], hybrid [35, 36], heuristisk [37] (observera att denna är endast en utomhusmodell) och finita elementmetoden [31]. Dessa är mer eller mindre avancerade varianter av de korta introduktioner jag skrivit om. Emellertid är alla dessa mycket begränsade, och har ytterligare hårdvara som kringutrustning.

Efterklangs-approximering

This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.

Sir Winston Leonard Spencer Churchill

I denna avdelning beskriver jag olika sätt att uppskatta och beräkna efterklangen, utan att behöva strålfölja på djupet med dålig hitrate som resultat. Det finns två approximeringsmetoder - den första är den deterministiska och den andra är den stokastiska (gränsen mellan dessa är suddig). Dessa har jag inte implementerat till fullo eftersom idéerna är för många trots att de är relativt enkla.

Eftersom jag fastslagit den heuristiska ray-trace-algoritmen som grund, ska vi approximera impulssvaret efter tiden Tr till tiden $T_{60}$ (samma sak gäller för spegelkällemetoden). Grunden till detta är att vi kräver diffusare ljudfält ju djupare reflektioner vi betraktar. Problemet är att fastställa Tr på ett sådant sätt att alla reflektioner innan Tr ska vara distinkta, och de som är efter ska vara överlagrade inom vissa tidsdiskreta områden. Om vi oberopar lagen om första vågfronten, ska vi inte ha ett diffust ljudfält (rent naturligt finns inte totalt diffusa ljudfält), och detta medför att vi inte ska strålfölja djupt ner. Typiskt tredje ordningens reflektioner är det som brukar användas, och detta är en kvalitativ uppskattning som inte bevisas. Observera dock att tiden Tr är mycket modellberoende, och rent heuristiskt kan vi inte generalisera föregående uppskattning.

Deterministiska Metoder

Själva efterklangen är egentligen ett tidsberoende filter som färgar signalen på ett visst distinkt sätt. Om vi betraktar de redan existerande lyssningshallarna och jämför deras efterklangsutseende, visar det sig att de följer samma struktur. Sammanslår vi detta faktum med att efterklangen är odistinkt, kan vi använda oss av en redan samplad efterklang. Denna idé är endast realiserbar om vi vet att modellen är en hall. Rent VR-mässigt har denna metod för stora generaliseringar, och vi nödgas omforma efterklangen med lämpliga funktioner. Dessa lämpliga funktioner kan vara en sammanslagning av ett flertal kända efterklanger i mer eller mindre linjär form. Problemet mynnar ut i att hitta ytterligheterna inom efterklangsstrukturerna och ett väl avvägt antal mellanvarianter, som kan blandas på ett sådant sätt att modellen kommer inom den rätta ramen.

Stokastiska Metoder

En vidareutveckling av föregående metoder är att mha de samplade efterklangerna och de beräknade tidiga reflektionerna bilda modellens efterklang. Denna beräkning behöver bara göras en gång, eftersom efterklangen i stort sett är objektpositionsoberoende. Detta är en approximering, eftersom tiden för efterklangens inträdande (Tr) inte är objektpositionsoberoende.

Vidare kan vi applicera en helstokastisk variant som bygger efterklangsfunktionen med följande parametrar: De första reflektionerna, antalet objekt i modellen, efterklangstiden $T_{60}$ och rörelseaktivitetsintensiteten. Tiden $T_{60}$ kommer att bestämma storleken på efterklangen. Antalet objekt och rörelseaktivitetsintensiteten bestämmer hur odistinkt efterklangen hörs. Vidare kan rörelseaktivitetsintensiteten följas av en stokastisk funktion (effektivare och enklare, baserad på en lämplig stokastisk process) eller en deterministisk funktion (långsammare och svårare, baserad på objektens rörelsescheman) för att förändra efterklangens möjliga beroende av objektposition.

två schematiska bilder på efterklangs-approximering där D visar den deterministiska varianten och S visar den stokastiska. Krysset betyder att de två funktionerna (möjligen flera) opererar skalärt på varandra för beräkning av impulssvaret. Dubbelkrysset betyder att de två funktionerna (möjligen flera) opererar stokastiskt på varandra för syntetisering av efterklangen.

Auralisering

So gelangt man beim Philosophieren am Ende dahin, wo man nur noch einen unartikulierten Laut ausstossen möchte.

Ludwig Wittgenstein

Vid grafisk ray-tracing är det mycket enkelt att visualisera enstaka bilder som visar hur modellen ser ut. När vi handskas med ljud-ray-tracing är grafisk visualisering inte lika givande. Det kan vara trevligt att se rummets impulssvar eller enstaka energiknippen som propagerar runt i rummet. Men att visa ljudutbredning med grafik är lite som att försöka beskriva ett ljud för en person med medfödd grav hörselskada (mycket svårt). Egentligen är detta dålig mappning, eftersom vi ser det vi vill höra. I enlighet med den starka VR definitionen plus människa-dator-interaktionens hårda krav på god mappning, medför detta att vi måste auralisera (Eng. Auralization). Om vi ska ha språklig konsekvens borde auralisering heta audialisering, men de som vandrat dessa vägar tidigare har fastnat för begreppet auralisering.

För fortsatt läsning kräver jag att läsaren har läst "Beräkningsaspekt på digital audio" i "Audiobehandling", och jag kommer referera till denna del med [BDA].

Det stora beräkningskravet som bevisades i [BDA] (trots ickeutvecklade algoritmer), medför att vi inte, utan viss finurlighet, kan auralisera på en vanlig µ-dator. Problemet finns redan i ray-trace-algoritmen. Denna kan vi emellertid implementera med en snabb heuristik som tar hänsyn till örats riktverkan, maskning och olinjäritet (phon kurvorna). Detta, i samband med att vi endast strålföljer ner till tredje ordningens reflexer, medför att vi kan bygga första delen av modellens impulssvar i realtid (25 ggr/s).

So what! How about the auralization?

Eftersom vi handskas med en dator med ytterst begränsad beräkningskraft, kommer vi inte långt med auraliseringen. Amigan har åtta bitars ljud med fyra kanaler i stereo (två för vardera öra), och volymen för varje kanal (stämma) kan ställas in med 64 olika nivåer (logaritmiskt spridda). Den lägsta nivån är en dämpning av signalen med 36 dB, vilket medför att vi kan bygga ett delsvar av impulssvaret i ett givet tidsintervall med 64 ljudreflektioner. Detta är beräknat i enlighet med formel 1 i [BDA]. Det innebär att vi inte behöver beräkna mer än 64 reflektioner för varje öra. Den heuristiska strålföljningsalgoritmen lär knappast bli långsammare av denna gräns.

Losing my patience! How about the auralization?

I enlighet med pläderingen i "Efterklangs-approximering" och de två första kapitlen, medför detta att vi inte behöver fullt den höga kvalité som diracsamplingsfaltningarna ger. Därför kan vi approximera efterklangen med ett lämpligt reverb, som finns i en mängd olika varianter i musiksammanhang. Det enda kravet är att det ska ha MIDI (Musical Instrument Digital Interface) för att vi externt ska kunna ändra de viktigaste parametrarna, $T_{60}$ och efterklangsdiffushet. Lösningen medger att användaren själv bestämmer vilken kvalitet efterklangs-approximeringen ska ha. Denna lösning är även en naturlig forsättning på Amiga-konceptet (låt specialprocessorer göra grovjobbet). Nedan visas algoritmen och en hårdvaruflödesplan.

    Denis Tumpic's Heuristic Auralizer-Ray-tracer Code:

    Definition Max length:
            Computed reverberation time with Sabine's formula
            multiplied with the soundvelocity through air.

    Definition Max rays:
            Total number of additions without cancellations.

    Definition Hit object:
            An object that mostly reflects rather than diffracts
            soundrays.

    Definition Transceiver:
            Objects that transmits (loudspeaker) or receives (ear)
            sound.

    Definition Hit point:
            Ray impact area on hit object.

    Definition Clean hit:
            When the ray-tracing cone hits a specific hit object or
            transceiver.

    Definition Looking range:
            Circular cone that spreads(¶/2) from the hit point with
            the direction of specular reflection.

    Definition Diffuse hit:
            When the path from ray-trace hitpoint to transceiver
    surface is in the lookin grange and free from hit ob
    jects.

    Definition Trace hits:
            The calculated impuls response from the Ray Trace algo
    rithm.

    Master (Realtime V:input sampligfrequency) function Auralizer:
        First time:
            Compute reverberation time with Sabins's formula.
            Initialize extern reverb through MIDI system messages.
        Allways (Isochrone \& Parallel):
            Convolv incomming data with Trace hits.
            Output convolution to audiochannels.

    Master (Parallel Pseudoprobabilistic Heuristic) function Trace:
        Iterate over ray directions that point onto objects.
        Ray-trace until:
            Transceiver hit or
            Raylength exceeds Max length or
            Total Rays exceeds Max rays.
        When detected a clen hit memorize:
            Decay time and attenuation.

    Slave (Recursive and Iterative Heuristic) function Ray_Trace:
        Compute nearest possible Hit object and reflect ray specu
    larly through the new Hit point.
        Compute nearest possible Hit object.
        Multiply this Hit objects absorptionresponse with:
            Previous absorptionresponse in this recursion.
        When Diffuse hit detected:
            Damp ray then memorize:
                Decay Time and attenuation.
            Increase Total Rays.
            End recursion.
        Depending on depth and grade of diffusion:
            smash ray into several directions and recurse.

Denna bild visar hårdvaruschemat till auraliseringsalgoritmen. Mikrofonen kan kan bytas ut mot en DAT (Digital Audio Tape) som vi låter återge en tidigare inspelning gjord i ett reflexfritt rum.

Datastrukturen

Totally dynamic sets are the key to everything.

I denna del beskriver och kommenterar jag valda delar av programmets öppna datastrukturer. Först börjar vi med några uppräkningstyper.

Följande typ använder jag för att identifiera objekten vid diverse beräknin gar:

    /*****************************
    * What type of object is it? *
    *****************************/
    enum ObjectType {Furniture,Sender,Receiver};

De primitiva modellobjekten är uppdelade i följande enheter:

    /**************************************
    * What type of primitiv object is it? *
    **************************************/
    enum PrimitivObject (Tetraeder, Cube, Octaeder, Prism, Room, Pyramid, Plate};

Direktiviteten har denna uppräkningstyp:

    /**************************************************
    * Propagation Directivity for objects in general. *
    **************************************************/
    enum DirectionType {Omni,Bi,Cardioid};

Eftersom det är pölar vi handskas med använder jag mig av dubbellänkade listor (egentligen onödigt i en första betraktning, trots att söktiderna enkelt kan halveras). Nedanstående struktur är för specifika materials egenheter. I en vidareutveckling av programmet, med full hierarkisk uppbyggnad, ska allt under pekarna (*prev och *next) samlas till en struktur (gäller för huvuddelen av dessa strukturer). Detta är grunden till dubbellänkningen i denna struktur. Vidare kan vi även implementera en sorteringsknapp i koordineringsfönstren, och döpa om dessa till lager (Eng. Stock). Om vi är förnuftiga ska strukturen omformas till en lämplig trädmodell (strukturnamnet byter i detta fall namn till Material<typ>Tree).

    /******************************************************
    * Master struct for Material Characteristics          *
    * Materiallist holding all loaded \& created materials *
    ******************************************************/
    struct MaterialList
    {
        struct MaterialList *prev;  /*Pointer to previous in list    */
        struct MaterialList *next;  /*Pointer to next in list        */
        char Name[80];              /*Material name                  */
        int usage;                  /*How many objects uses this MTR */
        enum GraphType GraphMode;   /* Spline or linear              */
        enum ObjectType OType;      /*Furniture, sender or receiver  */
        int Color;                  /* Draw Color (furnitures only)  */
        int Volume;                 /* Sound Volume (senders only)   */
        double meanabsorption;      /*Material mean absorption coeff */

        /*********************************************************
        * Softtypeequalizer with normal equalizing frequencies   *
        * and extra directioncharacteristics for each frequency. *
        * Frequency Absorption/Response variables                *
        * 32,63,125,250,500,1k,2k,4k,8k,16k,32k Hz               *
        *********************************************************/
        int EHZ[11];

        /*****************************************************
        * Frequency Direction variables Omni, Bi or Cardioid *
        * 32,63,125,250,500,1k,2k,4k,8k,16k,32k Hz           *
        *****************************************************/
        enum DirectionType DHZ[11];
    };

Varje objekt är uppbyggt av ett antal kubliknande delobjekt, som är av typen primitivobjekt. Dessa läggs i en dubbellänkad lista (endast för att det ska vara likformigt). Eftersom full hierarki inte är implementerad har jag förlagt objektets material i modelleringstrukturen istället. Emellertid kommer detta i en senare form att vara förlagt i denna struktur. Planekvationsvärden (beräkning av spegelreflektion mha normalen) och ytornas utsträckning (undersökning om strålen träffar) finns i denna pga att de gav strålföljningsalgoritmen en rejäl hastighetsökning. Jag tycker att denna hastighetsökning är viktigare än de extra 480 byte som krävs. Vidare är areauträkningen förlagd i insertstadiet (läs beräkningsamortering vid modelleringen), vilket får beräkningarna med Sabine's formel att komma ner i acceptabla nivåer. De många lagringsareorna för vektorerna grundar sig i AOT³-algoritmens effektivitet och kommenteras inte vidare här (se 3D-Transformerings-Algoritmer).

    /*******************************************
    * Struct holding all surfaces of an Object *
    *******************************************/
    struct SurfaceList
    {
        struct SurfaceList *prev;  /* Pointer to previous in list   */
        struct SurfaceList *next;  /* Pointer to next in list       */
        enum   PrimitivObject PO;  /* What type of prim object is it*/
        double x[8],y[8],z[8];     /* x,y,z Rigid Coords            */
        double mx[8],my[8],mz[8];  /* x,y,z 1 transformed Coords    */
        double tx[8],ty[8],tz[8];  /* x,y,z 2 transformed Coords    */
        double AV[6],BV[6],CV[6],DV[6];/* Plane equation            */
        double maxx[6],maxy[6],maxz[6];/* Plane boundaries          */
        double minx[6],miny[6],minz[6];/* Plane boundaries          */
        double Area[6];            /* Area of the plane             */
    };

Följande struktur är noderna i objektlistorna (även dessa är dubbellänkade för likformighetens skull):

    /**************************************************
    * Masterstruct for a specific Object              *
    * ObjectList holding all loaded \& created objects*
    **************************************************/
    struct ObjectList
    {
        struct ObjectList *prev;      /* pointer to prev in list  */
        struct ObjectList *next;      /* pointer to next in list  */
        char Name[80];                /* Root name of an Object   */
        int cubes;                    /* Number of sub cubes      */
        struct SurfaceList *surfaces; /* Pointer to a surfacelist */
    };

Själva modelleringstrukturen är även denna en dubbellänkad lista. Märk att vi inte ska göra en helimplementation av ett sökträd för denna, med tanke på snabb söktid när användaren väljer ett objekt på skärmen, eftersom vridningar medför att knappnålarna ändrar läge och en ny sortering krävs (läs ajöss med realtidsfeedback). Emellertid är trädstrukturen nödvändig för hierarkisk lagring. Vidare finns objektets position i världen och deras riktning (tre ortogonala enhetsvektorer) för bla storleksförändring. Enhetsvektorerna grundar sig i att AOT³-algoritmens beräkningsform kräver det (bla inverterad rotering vid storleksförändring). Strålföljningsalgoritmen mellanlagrar träffytans normal i denna nod, om strålen träffar någon yta i dess objektlista. Detta är ett tillägg från den heuristiska lösningsformen.

    /*************************************************************
    * Masterstruct for a specific object in current Drawing Pool *
    * DrawingList holding all objects in current drawing         *
    *************************************************************/
    struct DrawingList
    {
        struct DrawingList *prev;       /* Pointer to previous in list   */
        struct DrawingList *next;       /* Pointer to next in list       */
        double x,y,z;                   /* Center of object in space     */
        double dxx,dyx,dzx;             /* Sizing Orientation  ex        */
        double dxy,dyy,dzy;             /* Sizing Orientation  ey        */
        double dxz,dyz,dzz;             /* Sizing Orientation  ez        */
        long int recnumber;             /* Tracer receiver number        */
        int    ax,ay,az;                /* Anglegadgets real angle       */
        int    dax,day,daz;             /* Anglegadgets deviation        */
        double sx,sy,sz;                /* Sizergadgets real size        */
        double dsx,dsy,dsz;             /* Sizergadgets deviation        */
        double W,H,D;                   /* Width, Hight, Depth of object */
        double AV,BV,CV,DV;             /* Hitplane normal               */
        double pinx,piny,pinz;          /* Pin location                  */
        char   Name[80];                /* Userspecified extra name      */
        struct ObjectList *object;      /* Pointer to Objectdatalist     */
        struct MaterialList *material;  /* Pointer to a material         */
        struct FlightList *flight;      /* Pointer to a flightpath       */
    };

Strålföljningsdata läggs i dubbellänkad lista, för att konkatenering av beräkningsresultat från en parallell form av strålföljningsalgoritmen enkelt ska kunna göras. Dessa sammanslagningar används i senare beräkningar för diverse akustiska kriterier. Vid själva auraliseringen kan varje processor falta sina beräkningar och sedan skicka svaret till huvudprocessorn. Märk att vi inte behöver resultaten i en specifik ordnad följd, eftersom faltning görs på hela datamängden. på en enprocessorsmaskin är dynamiska arrayer en snabbare datastruktur för själva faltningen. Observera också att med NOMIX- och MIXTHEM-algoritmerna är datat i en ordnad följd pga att vi använder oss av samplingar.

    /**************************
    * List/node of tracedata. *
    **************************/
    struct TraceList
    {
        struct TraceList *prev;     /* Pointer to previous in list   */
        struct TraceList *next;     /* Pointer to next in list       */
        double length,acoeff;       /* Length and absorption of path */
        double ex,ey,ez;            /* Origin direction              */
        double time,amplitude;      /* Realtime renderdata           */
        char   Sname[80],Rname[80]; /* Name of sender \& receiver    */
        int    recnumber;           /* Asociated number to tracer    */
    };

Programmeringsmetodik

Quick and Dirty, Slow and Clean, Blade Running that's my dream.

DDT

I detta avsnitt behandlar jag min programmeringsmetodik i en lättsam beskrivning, och de som inte är intresserade av ett stundom högtravande språk ska inte läsa vidare.

Själva programmeringsmetodiken tycker jag är väldigt viktig, och jag lägger oftast stor vikt vid utformningen av programkoden, om det finns tid. De flesta av oss har mycket individuella programmeringssätt, och i stora enmansprojekt är det av stor vikt att vara strikt och stringent.

Vi kan förlägga den strikta programmeringsmetoden i Slow & Clean-Programming (SCP). För rena algoritmutvecklingar är SCP inte att föredra, eftersom programmeraren då hänger upp sig på detaljer, istället för att få algoritmen att beräkna problemet. För att testa idéer kan programmeraren använda sig av Quick & Dirty-Programming (QDP).

När algoritmerna genomgått de första optimeringarna, kan den rensas från allmänna onödigheter (konstiga variabelnamn och dylikt). Det finns ett flertal nivåer på optimeringar, och den första kallar jag primär optimering. Denna är av ren matematisk natur och ska minska eventuella onödiga beräkningar. Vidare har vi sekundär optimering, vilket innebär att vi i förväg beräknar (amorterar) sökvägar/beräkningsresultat som ständigt återkommer. Det finns flera optimeringar men dessa är de som alltid kommer före en större algoritmutveckling. När vi har en välformulerad algoritm med lägst beräkningskomplexitet, kan vi optimera denna i ren assembler. Detta förfaringssätt brukar oftast vara av mycket dyr natur, om vi jämför med vinsten mellan implementeringar i olika riktiga programmeringsspråk.

Programmen tenderar oftast att expandera till ohanterlighet om vi inte har en viss likformighet i sättet att beskriva funktionerna. Det vanligaste sättet att hantera större problem, är att beskriva problemet i ett par underproblem. Dessa underproblem delar vi sedan upp i ytterligare underproblem. på detta förfaringssätt gör vi tills vi kan lösa de små delproblemen. Märk att detta är en "Söndra-och-Härska"-algoritm. Oftast är delproblemen mer eller mindre besläktade, och de som är starkt besläktade ska skrivas i närgränsande textmassa (helt naturligt i Simula, mindre naturligt i andra språk). Dessa textmassor är moduler i verklig mening och jag brukar kalla dessa <name>handler (exempelvis ViewHandler, TraceHandler, SabineHandler). Huvudprogrammet ska ha ett mindre kryptiskt namn, som koncist beskriver vad det utför eller är ett rent kommersiellt estetiskt namn. Figuren 4.21 visar den övergripande bilden på hur mitt programs uppstyckning indelats [^1].

3D-Audio interkommunikationsflöden. Dubbelpil betyder datatrafik och enkelpil betyder programflödesändringar. Stjärnan indikerar att anrop i globalfunktionsmodulen (AboutPrefsMischandler) görs. Färdigberäkning i respektive modul resulterar i återvändo till händelsemodulen 3DAudio_events, för en passiv väntan pånya användaromformningar.

Vid färdigställning av en modul ska denna vara helt rensad och normaliserad. Normaliseringen utgör fasen då programmeraren gör en fullständig likformighetsomformning av programkoden. Detta innebär att hon fullständigt ska beskriva funktionerna i funktionshuvuden, och svårare konstruktioner ska kortfattat beskrivas i närgränsande områden. För programmeraren är programmet som ett stort bevis med definitioner och satser. Varför ska vi inte kräva att programmen ska vara lika vackra som matematiska bevis, eller välskrivna som de bästa litterära verken? Nästa sida visar min normaliseringsuppbyggnad, och layouten är tagen från Amiga-Autodocs standard.

    /****** <Handler name> **************************************
    *                                                           *
    *   NAME                                                    *
    *   <Function name> -- <Small description>                  *
    *                                                           *
    *   SYNOPSIS                                                *
    *   <Function name> ( <parameters> )                        *
    *                                                           *
    *   FUNCTION                                                *
    *   <Big description>                                       *
    *                                                           *
    *   INPUTS                                                  *
    *   <Parameter description>                                 *
    *                                                           *
    *   RESULT                                                  *
    *   <Computed data description>                             *
    *                                                           *
    *   EXAMPLE                                                 *
    *   Just necessary if it is a Global or Child function.     *
    *                                                           *
    *   NOTES                                                   *
    *   Type of function:                                       *
    *       <Global, Master, Slave or Child>                    *
    *   (   <Realtime V:<velocity> > <Isochrone>                *
    *       <Parallel or Sequential>                            *
    *       <Iterative, Recursive <Bottom upp or Top down>,     *
    *        Input/Output or Event>                             *
    *       <Monte Carlo, Las Vegas, Pseudoprobabilistic or     *
    *        Deterministic>                                     *
    *       <Depth first, Width first, Greedy or Heuristic>)    *
    *   function                                                *
    *       <Function name>_<Nearest Parent name>               *
    *                                                           *
    *   BUGS                                                    *
    *   <Known bugs or logical missconditions>                  *
    *                                                           *
    *   SEE ALSO                                                *
    *   <This functions Global, Slave and Child calls>          *
    *                                                           *
    *                                                           *
    *************************************************************
    *
    */
    <Function name> ( <parameters> )
    {
        <Definitions>
            Konstants have big first letter.
            Descrete variables are i,j,k ...
            Continous variables are x,y,z ...
            Array variables are A[],B2[][],C3[][][]...
            Pointers have big first letter and the type of data
            structure with the leading characters as a suffix.

            Suffixes are: <Oneway, Double, Circular or Vien> List,
                      <Binary, B- or <specialls>> Tree,
                      <Plain, Binomial or Fibonacci> HEap,
                      <Open, Chaining or Universal> HAshing ...

            Initiatus <pseudoconstants, script or graphics>
            <Itera or Recursiva> Computa
        or
            Redirection of programflow.

        <Function return>
    }

Dessa saker är triviala när koden har mindre än ett hundratal funktioner. Stora problem brukar oftast ha betydligt flera funktioner, och tro mig att det inte blir trivialt när vi ska normalisera dessa program. Ibland kan det vara svårt att hitta optimum för den snabbaste implementeringsvägen - speciellt när programmeraren varit i QDP-fasen för länge uppträder dessa problem. Oftast genom tidigare erfarenhet kan denna "punkt" kännas. Alla människor kan programmera, men bara de bästa programmerarna balanserar på detta equilibrium. Huruvida detta projekt är en verkligt optimal implementering eller inte, lämnar jag som en öppen fråga till de som inte är dataloger. Själv anser jag att implementeringen gick för långsamt, och det grundar sig i de något komplicerade funktionsvarianterna jag tvingade mig själv att göra i vetenskapens tjänst (vilket jag inte ångrar).

Slutsatser

När jag började med detta projekt hoppades jag på att det skulle finnas lite material om dessa problem, för att i så stor utsräckning som möjligt vidga mina vyer. Jag fick min önskan uppfylld med råge. Trots att univeritetsbiblioteket (UB2) har mycket material och att jag fick ett par värdefulla namn från min handledare, skulle det visa sig att närmare fyra veckors djupdykningar efter relavant material åstundade. Vanligtvis brukar informationsmängden explodera när vi hittar ett par spår, men så icke i detta fallet. Det verkar som om ett stort antal av de vetenskapsmän som sysslar med audio-ray-tracing inser det hopplösa i situationen, och lämnar över problemet till de nästkommande med bättre datorer. Detta är att jämföras med video-ray-tracing, där det finns ett mycket stort antal "anhängare".

Även om Amigan inte har lika stor beräkningskraft som diverse arbetsstationer, vill jag framföra att CPU-kraft inte är allt. De till synes konstlade funktionsimplementeringar jag emellanåt tvingade mig själv att skriva, skulle aldrig sett dagens ljus på andra system, eftersom frustrationsgraden över algoritmernas ineffektivitet stundtals var olidlig. Med detta i åtanke skulle ett långsamt grafiskt gränssnitt varit en stor barriär, och hindrat mig från att koncentrera mig på programmeringen och de specifika algoritmerna. Valet av dator och programmeringsspråk har således visat sig vara ett bra val. Emellertid krävs en "Iris Crimson" (en SGI maskin) om jag skall kunna realisera beräkningarna i realtid.

Mitt examensarbete i det stora sammanhanget. " Inter Gigantica Galactica " (IGG) är den fulländade VR-miljön, där användaren kommer att kunna göra och uppleva allt, i enlighet med den starka definitionen av VR.

Det brukar sägas att ett problem tar minst dubbelt så lång tid att lösa som den tid man först åsätter till det. Detta beror mycket på hur stor ambi tion och vision vi medtager. När visionerna överträffar ambitionen kommer det att ta mycket längre tid. I detta fallet är min vision långt större än min ambition. Även om detta är ett faktum, ska det på intet sätt uppfattas som att min ambition varit medioker. De som själva vill börja med att lösa au dio-ray-trace-problemet, kan ansöka om att få ta del av "The Making Of 3D-Audio so far" och se vad som möjligtvis kommer att vänta dem.

3D-Audio instruction manual

What is 3D-Audio

This program is a simple but fast audio-ray-tracer, with a semiprofessional three dimensional editor as a base for human-computer interaction. It has been developed on the Amiga line of computers and thus works, at the moment, only on these machines. Recent virtual-reality hysteria and the vast amount of video-ray-tracers on these machines, gave Me the idea of making this piece of software, as a prologue to the strong definition of VR (my own). Most parts of the program are profound, but a warning to those with small sized memories when ray-tracing. I am not checking if there is enough memory when starting the ray-trace session, and thus could make the computer hang, when the vast amount of ray-tracing hits are found and stored.

What it isn't

As for the most audio-ray-tracers there are some limitations, and thus it can't be used in predicting the room model impulse response without having the following facts in mind.

(1) The emitted sound is strongly quantized in direction, due to the heuristic function.

(2) All model surfaces are plane and smooth.

(3) Specular reflections and angle-independent absorption are assumed.

(4) Energy addition is assumed.

(5) Discontinuities at the edges are discarded.

(6) Diffraction, Dispersion, Resonance and Refraction isn't implemented yet.

(7) Partially diffuse sound field is assumed.

Installing the Software on Hard-drive

(0.1) If you don't have an Amiga computer, then you have to go and purchase one, or else go to 1.1

(0.2) Follow the hardware set-up and install the system disks. Go to 1.2

(1.1) Turn the computer on.

(1.2) Find a suitable place where you want the software, and make a New Drawer there.

(1.3) Insert 3D-Audio disk in any drive and double click at the disc icon.

(1.4) Multiselect the six drawers and the main program, and drag them to the New Drawer.

(1.5) Click once at the program icon and request information about the program.

(1.6) Change screen resolution to your preference in the Tool Types list.

(1.7) Double click at the program icon and way you go.

Happy modelling!!!

Main Editing Windows

The two editing windows are the "3D View & Edit" window (VE) and the "Drawing Pool" window (DP). Moving, resizing and turning objects are done by operating gadgets in VE. Additional gadgets in VE are for model purposes that relate to the object size/position, viewpoint, perspective and the grid. Inserting new objects and changing old ones are done by operating gadgets in DP. The following two pictures shows what each gadget does, and I urge the user to open the test model and play around with it.

This is 3D-Audio’s main editing window. With the X-Axis, Y-Axis and Z-Axis slider gadgets you can turn the model around to any view. The small restore buttons, placed at the endpoints of these rotary sliders, and visualized as little O, places the turn knob in the middle. With the ”Measure”-cycle-gadget, you can change the scale system from meters, feet and to off. With the ”Grid Size”-cycle-gadget you can change the dimension of the surface ground.

This is the model coordinating window, where all the visible objects in the model are listed. You activate the ”New...”-button, when you want to insert a new object in to the model. Deleting a false or an unnecessary object is done with the ”Delete”-button. Assigning materials and flights are done with the appropriate ”Select...”-button at the equilevel. Defining an object from the existing model, is done with the big ”Drawing->Object...”-button. Selecting a specific object in this pool and pressing either shift key, holds that object in editing mode. This function is very useful when the pins of the objects are clustered, and you can’t select the appropriate object in ”3D-View & Edit”.

Objects, Materials, Flights & Characteristics

When pressing "New..." or "Select..." gadgets in DP one of the following requester windows will appear on the screen. The "Object Pool" window handles the object fetch table, the "Material Pool" window (MP) handles the material fetch table and the "Flight Pool" window handles the objects morphing and flight path fetch table, and this end of the program is not yet fully implemented, and thus have no effect on the traced data.

This figure shows what type of requesters appear, when you invoke different functions in the model coordinating window. You have to select the appropriate object, material and flight in these requesters list-view gadgets and press the ”Ok!”-button, that is, if everything is all right. Otherwise you should press the ”Cancel”-button, then the program-flow is changed, back to the time before the wrong doing.

When pressing "New..." or "Edit..." gadgets in MP the "Characteristics" requester window appears on the screen. This window handles the entities of a specific material, and it's properties are visualized in the following picture.

The definition of the material is done in the ”Characteristics” window, which is a sub-requester to the material coordinating window - after invoking the ”New...”- or ”Edit...”-button. Naming is easily done with the string-gadget ”Name”, and the type of object is selected with the cycle-gadget ”Type”. You edit the frequency response or absorbing curve by freehand - in the graph box -, with the left mouse button pressed. Directivity characteristics are toggled with the radio buttons, placed under every frequency octave.

Computed Data

When you reach the stage of tracing the model, the "Computed Data" window gets active. If it's active the mouse pointer shows a clock. This indicates that the computer is calculating the reverberation times with Sabine's formula, and afterwards, that the ray-tracing has begun. While the computation commences, the echogram, at the bottom of the window, shows the computed ray hits. The reverberation distribution is visualized at the upper right corner, and you can - when computation is finished - change the air relative humidity, with the cycle gadget under the reverberation distribution.

Preferences

I have implemented a preference window to make modelling life easier. Here you can change the location path - mass storage location - for each model type (e.g. models, objects, materials and flights) and the traced data. Furthermore you can change the screen colors as in the workbench palette-preferences. The following picture shows this window.

Menus

As usual the "Project" menu is at the left most position and it has the following properties visualized in the following picture.

When you have to open, merge or save those drawings, objects, materials, flights and traced data that you create, you have to select the appropriate function in the ”Project” menu.

The "Editing windows" menu has the effect of placing the respective window front most.

If you do not have a big monitor (e.g. HIRES instead of SUPERLACE is written in the main program icon - invoked with right-Amiga I, when single clicked icon - tool types list) this menu becomes very handy.

The "Tracer" menu have all the parameters associated to the accuracy of the ray-tracer algorithm, and the initiation of tracing is also done here.

The ”Tracer” menu have all the parameters that is associated with the ray-tracing algorithm. This is only the beta-stage look, and the appearance IS subject to change without notice. If you want the latest and the most user-friendly version to this aspect (parameter toggling), then you have to wait for release 2.

The "Miscellaneous" menu have, amongst other things, the Undo stack clearance functions. If you run out of memory, after a while modelling, you have probably many things in these undo stacks. This is because the computer remembers all deletion within the respective model type.

This menu handles the undo-stacks and the invoking of the ”Preferences” window.

Data Files

Each of the model types can be edited in a normal text editor. All though it isn't recommended that a novice user should mess in these files, an expert user could have some fun with them. She can, amongst other things, create new primitive objects in this way. The following lists shows the file formats associated with 3D-Audio software.

WARNING!!!

Users that input false data format, could make the program calculate very strange things, and it is very important that she knows what she is doing. I have no responsibility if the computer goes berserk, or some "new" acoustical phenomena are encountered.

Drawing File Form

File form:

        $3D-Audio_DrawingHeader
        # <number of objects> <Magnification 1-10000> <Perspective 1-250> <Measure: 0=Meter, 1=Feet, 2=Off> <Grid Size 0-11 (0=Big 11 Small)>
            $<Object #n model name>
            #<Object #n><origo XO, YO, ZO>
              <eigen vectors XE, YE, ZE><size XS,YS, ZS>
            $miniOBJHYES
                Remark: $miniOBJHNO and discard the following if no object data is present.
                $ <Object #m primitive name>
                # <number of primitive objects>
                # <Special primitive #> <Eight x,y,z coordinates>
                    0: Tetrahedra
                    1: Cube
                    2: Octahedra
                    3: Prism
                    4: Room
                    5: Pyramid
                    6: Two dimensional plate

            $miniMATRHYES
                Remark: $miniMATRHNO and discard the following if no material is assigned.
                $ <Material name>
                # 0 <type of source> 0 0
                    0: Furniture
                    1: Sender
                    2: Receiver
        Remark:Frequencies (Hz): 32 63 125 250 500 1k 2k 4k 8k 16k 32k
                # <Eleven absorption coefficients ranging from 0 to 100>
                # <Eleven directivity numbers at above stated freq.>
                    0: Omnidirectional
                    1: Bicardioid
                    2: Cardioid
            $miniFLGHNO
                Remark: Not implemented.

Example:

            $3D-Audio_DrawingHeader
            #1 9711 231 0 5
            $Big Sofa
            #0.040670 0.171643 0.656502 1 -0.001465 0.000168 0.001466 0.999994 -0.003108 -0.000164 0.003108 0.999995 67 92 99 $miniOBJHYES
            $Big Sofa
            #4
            #1      -1.378665 -0.251693 0.281572 1.341315 -0.250144 0.273905   1.341489 0.251856 0.273736 -1.378491 0.250308 0.281404 -1.378989 -0.251859 -0.218429 1.340991 -0.250311 -0.226097 1.341165 0.251690 -0.226266 -1.378815 0.250141 -0.218600
            #1  1.345374 0.259635 0.275123 1.478653 0.259711 0.274748 1.478686 0.357711 0.274715 1.345407 0.357636 0.275090 1.345049 0.259469 -0.224880 1.478328 0.259545 -0.225255 1.478362 0.357545 -0.225288 1.345084 0.357469 -0.224912
            #1  -1.525151 0.240771 0.279624 -1.391872 0.240847 0.279249 -1.391839 0.338847 0.279215 -1.525117 0.338770 0.279591 -1.525478 0.240603 -0.224378 -1.392198 0.240679 -0.224754 -1.392165 0.338679 -0.224787 -1.525444 0.338602 -0.224412
            #1  -1.394825 0.222433 0.385671 1.325155 0.223981 0.378003 1.325443 0.809575 0.508692 -1.394537 0.808027 0.516360 -1.394881 0.244214 0.288071 1.325099 0.245763 0.280403 1.325387 0.831357 0.411093 -1.394593 0.829808 0.418760
            $miniMATRHYES
            $Skin
            #0 0 0 0
            #8 10 7 12 25 30 29 31 40 45 44
            #1 1 1 1 1 1 1 1 1 1 1
            $miniFLGHHNO

Objects File Form

File form:

        $3D-Audio_ObjectsHeader
        # <number of objects>
            $ <Object #n primitive name>
            # <number of primitive objects>
                # <Special primitive #> <Eight x,y,z metric coords.>
                    0: Tetrahedra
                    1: Cube
                    2: Octahedra
                    3: Prism
                    4: Room
                    5: Pyramid
                    6: Two dimensional plate

Example:

            $3D-Audio_ObjectsHeader
            #1
            $Cube
            #1
            #1 -1 -1 1 1 -1 1 1 1 1 -1 1 1 -1 -1 -1 1 -1 -1 1 1 -1 -1 1 -1

Materials File Form

File form:

        $3D-Audio_MaterialsHeader
            $ <Material name>
            # 0 <type of source> 0 0
                0: Furniture
                1: Sender
                2: Receiver
        Remark:Frequencies (Hz): 32 63 125 250 500 1k 2k 4k 8k 16k 32k
            # <Eleven absorption coefficients ranging from 0 to 100>
            # <Eleven directivity numbers at above stated frequencies>
                0: Omnidirectional
                1: Bicardioid
                2: Cardioid

Example:

            $3D-Audio_MaterialsHeader
            #1
            $Black Hole 100%
            #0 0 0 0
            #100 100 100 100 100 100 100 100 100 100 100
            #0 0 0 0 0 0 0 0 0 0 0

Trace Data File Form

File form:

     $3D-Audio_ForwardTraceHeader or $3D-Audio_BackwardTraceHeader
     #Number of trace hits
          #<Ray density><Reverberation accuracy><Specular depth><Diffusion accuracy><Diffraction accuracy><Frequency accuracy><Mean reverberation time in seconds><Max Number Of Receivers>
     Remark:   Accuracy: 0.00 to 1.00 are Manual values -1.00 initiate Auto state.
        Density, Depth & Max number: Integer values
        Seconds: Float value.
     Remark: Entries at frequencies (Hz): 32 63 125 250 500 1k 2k 4k 8k 16k 32k
        # Frequency dependant reverberation times, 11 entries at 40% R.  hum.
        # Frequency dependant reverberation times, 11 entries at 50% R.  hum.
        # Frequency dependant reverberation times, 11 entries at 60% R.  hum.
        # Frequency dependant reverberation times, 11 entries at 70% R.  hum.
        #<Ray length in meters><Accumulated absorption coefficient><Receiver number>
        # Directivity eigen vectors XE, YE, ZE
        $Sender Name
        $Receiver Name

Example: These data should not be manually edited, even if you know what you are doing!!!

Preferences File Form

File form:

        3D-Audio_Preferences_file.
        Drawings Path
        Objects Path
        Materials Path
        Flights Path
        Trace Path
        Remark: Color numbers 0-7, RGB values 0-15, Seven entries!
        <color number> <Red value> <Green value> <Blue value>
        Remark: For further expansions only, don't change manually.
        0 0 0 0

Example:

            3DAudio_Preferences_file.
            Work Harddisk:C Prg/Sound Tracer/Drawings
            Work Harddisk:C Prg/Sound Tracer/Objects
            Work Harddisk:C Prg/Sound Tracer/Materials
            Work Harddisk:C Prg/Sound Tracer/Flights
            Work Harddisk:C Prg/Sound Tracer/Traced_Data
            0 13 8 6
            1 0 0 0
            2 15 13 9
            3 14 11 8
            4 15 0 0
            5 0 15 0
            6 0 0 15
            7 15 15 15
            0 0 0 0

Ordförklaringar, definitioner etc.

Additiv Absorption

Låt energistrålen reflekteras i ytorna $\{x_i; i=1, 2, ..., n\}$ med respektive frekvensberoende absorptionskoefficienter $\{\alpha_i(f); i=1, 2, ..., n; f=[20..20000] Hz\}$ då kommer den totala absorptionen vara följande:

$\alpha(f)=1-\Pi(1-\alpha_{i}(f))$ $\{i=1, 2, ..., n\}$

Clarity

$g(t)$ är rummets impulssvar.

$C=10\log_{10}\frac{\intop_{0ms}^{80ms}[g(t)]^{2}dt}{\intop_{80ms}^{\infty}[g(t)]^{2}dt}$ dB

Deutlichkeit (Definition)

$g(t)$ är rummets impulssvar.

$D=\frac{\intop_{0}^{50ms}[g(t)]^{2}dt}{\intop_{0ms}^{\infty}[g(t)]^{2}dt}$ 100%

Diracpuls

Definition:

(1) $\delta(t)=0,$ t $\neq0,\delta(0)=+\infty$

(2) $\intop_{-\infty}^{\infty}\delta(t)dt=1$

(3) $\delta(-t)=\delta(t)$ ( $\delta$ är jämn)

(4) $\delta(\frac{t}{a})=a\delta(t),a>0$

(5) $\Theta'(t) = \delta(t), \quad \frac{d}{dt} \operatorname{sgn}(t) = 2\delta(t)$

Disjunkt

Vi har två mängder A och B som inte har några gemensamma enheter.

$A\bigcap B=\emptyset$

Dynamik

I är informationsdatabredden i antalet bitar.

$Dynamik=20\log_{10}(2) \cdot I$ dB

Förklaring Dynamik

Vänstershiftning av ett binärt talvärde med ett steg medför en fördubbling av värdet. Enligt definition av Decibel är varje bit då värd $10\log_{10}(2^{2})$ dB. Detta ger formeln.

Energifördelning i Rum

Q : är runstrålande källans akustiska effekt.

$I(r)$ : är energi-intensiteten, r meter från ljudkällan.

$S_i$ : är en specifik ytas totala absorptionsyta.

$a_i$ : är en specifik ytas absorptionskoefficient.

N : är antalet ytor i rummet.

$R = \sum{\alpha_i}{S_i(1-\alpha_i})^{-1}$ $\{i=1, 2, ..., N\}$

$I(r) = Q \cdot ((4{\pi}r^2)^{-1}+4/R)$

Energipropagering

Q är runstrålande källans akustiska effekt.

$I(r)$ är energi-intensiteten, r meter från ljudkällan.

$I(r) = \frac{Q}{4{\pi}{r^2}}$

Faltning (Convolution)

Definition: Diracsamplingen är en diskret sekvens med följande form: $F=\{f_i:i=[0..n-1]\}$

Inkommande data är en diskret sekvens med följande form: $S=\{s_j:j=[0..n-1]\}$

Mängden F är statisk, men S är dynamisk och ändrar i varje samplingsögonblick sina element sj+1=sj med början i sn-1. Det senaste samplingsdatat är s0 och uppmärksamma att:

$n=f_{DIRAC} \cdot T_{60}$

eftersom vi inte behöver falta resultatet längre än diracsamplingens längd. Faltningen av F och S blir då följande:

$C=f_0 \cdot s_0+f_1 \cdot s_1+ ... + f_{n-1} \cdot s_{n-1}$

Detta ger n st multiplikationer och (n-1) st additioner. För enkelhetens och klarhetens skull, säger jag att den kräver n st op/samplingsögonblick (op betyder att en addition plus en multiplikation görs).

$I_{OUT}$

I är informationsdatabredden. S är antalet termer (ljudproducerande objekt).

$I_{OUT}=I_{IN}+Ceil(\log_{2}(S))$

Förklaring $I_{OUT}$ : Det största talet vi kan representera med I bitar är $2I-1$ . Vid addering av S stycken termer, blir det maximalt $(2I-1) \cdot S$ . För att få tag i hur många bitar det blir gör vi följande:

$I_{OUT}=Ceil(\log_{2}((2^I-1) \cdot S))=Ceil(\log_{2}(2^I-1))+Ceil(\log_{2}(S))=I_{IN}+Ceil(\log_{2}(S))$

Impulssvar

Diracpulsen i figure B.1 har gjorts med en kraftig och snabb handklapp. Denna har samplats med 35 kHz samplingsfrekvens genom en enkel mikrofon och egenhändigt byggd sampler. Samplern var kopplad till Amigan och hela förloppet varar ca 460 ms.

Lateral Efficiency

$g(t)$ är rummets impulssvar.

$g_{lat}(t)$ är energin som kommer från sidorna.

$L_{eff.} = \frac{ \intop_{25ms}^{80ms}[g_{lat}(t)]^{2}dt}{\intop_{0}^{80ms}[g(t)]^{2}dt} \cdot 100\%$

$M_S$

$f_S$ är samplingsfrekvensen. $T_{60}$ är reverberationstiden beräknad mha Sabine's formel. $I_IN$ är inkommande informationsdatabredd i antalet bitar.

$M_S = f_S \cdot T_{60} \cdot I_{IN}/8\ \text{byte}$

$M_{S} = f_{S} \cdot T_{60} \cdot I_{IN}/8~\text{byte}$

Förklaring $M_S$ : För att kunna falta inkommande data i varje tisdinstans behöver vi memorera alla samplade data. Denna memorering har $f_S \cdot T_{60}$ enheters längd, eftersom vi kräver memorering upp till diracpulsens tidslängd. Ovanstående faktum och definitionen av informatinsdatabredden, ger formeln.

MIXTHEM Kapacitet

op är en addition plus en multiplikation. D är datorkapaciteten i antalet op/s. $f_S$ är samplingsfrekvensen. S är antalet ljudproducerande objekt. $f_{DIRAC}$ är samplingsfrekvensen vid sampling av diracpulsen. $T_{60}$ är reverberationstiden beräknad mha Sabine's formel. R är antalet mottagare.

$D=f_S \cdot (S+f_{DIRAC} \cdot T_{60}) \cdot R$

Förklaring MIXTHEM Kapacitet: För-addition av alla ljudkällor till varje mottagare skall göras med samma hastighet som inkommande data, och detta ger följande bidrag till formeln:

$f_S \cdot S \cdot R$

Impulssvarets längd är $f_{DIRAC} \cdot T_{60}$ enheter och har direkt- ,reflex- och reverbljudet i sig. Vidare behöver vi falta varje mottagare genom de $f_{DIRAC} \cdot T_{60}$ st del-ljud som vi för-adderat. Även detta skall göras med samma hastighet som inkommande data. Detta ger följande bidrag:

$f_S \cdot f_{DIRAC} \cdot T_{60} \cdot R$

MIXTHEM $M_{TOT}$

R är antalet mottagare. $f_S$ är samplingsfrekvensen för inkommande data. $T_{60}$ är reverberationstiden beräknad mha Sabine's formel. $I_{OUT}$ är utgående informationsdatabredd i antalet bitar.

$M_{TOT} = R \cdot f_S \cdot T_{60} \cdot I_{OUT}/8$

Förklaring MIXTHEM $M_{TOT}$ : Till varje mottagare behövs det $f_{DIRAC} \cdot T_{60} \cdot I_{OUT}/8$ bytes för att memorera för-adderingarna som med impulssvaret används vid faltningarna (IOUT eftersom vi inte vill förlora data genom beräkningarna). Märk att det är av stor vikt, att ha samma samplingsfrekvens för inkommande data och diracsamplingen, för att underlätta för-adderingarna. Detta ger formel.

NODIRAC Kapacitet

op är en addition plus en multiplikation. D är datorkapaciteten i antalet op/s. $f_S$ är samplingsfrekvensen. S är antalet ljudproducerande objekt. $X_E$ är antalet tidiga reflexer. $X_R$ är antalet reverberationsapproximander. R är antalet mottagare.

$D=f_S \cdot (S+X_E+X_R) \cdot R$

Förklaring NODIRAC Kapacitet: Varje källa ger upphov till S st direktljud till varje mottagare. Detta medför att vi kräver $S \cdot R$ op för faltning av direktljudet.

De tidiga reflexerna ger upphov till XE st reflexljud till varje mottagare. Detta medför att vi kräver $X_E \cdot R$ op för faltning av reflexljudet. Reverberationsapproximanderna ger upphov till XR st reverbljud till varje mottagare. Detta medför att vi kräver $X_R \cdot R$ op för faltning av reverbljudet.

Allt åvanstående skall göras i varje samplingögonblick och detta ger formeln.

NOMIX Kapacitet

$D=f_S \cdot S \cdot f_{DIRAC} \cdot T_{60} \cdot R$

Förklaring NOMIX Kapacitet: Impulssvarets längd är $f_{DIRAC} \cdot T_{60}$ enheter och har direkt- ,reflex- och reverbljudet i sig. Vidare kommer varje källa att ge upphov till $f_{DIRAC} \cdot T_{60}$ st del-ljud till varje mottagare. Detta medför att vi kräver $S \cdot f_{DIRAC} \cdot T_{60} \cdot R$ op för faltning av alla del-ljud. Åvanstående skall göras i varje samplingsögonblick och detta ger formeln.

NOMIX $M_{TOT}$

$M_S$ är mellanlagringsstorleken för impulssvarsfaltningen. R är antalet mottagare. $f_{DIRAC}$ är impulssvarens samplingsfrekvenser. $T_{60}$ är reverberationstiden beräknad mha Sabine's formel. $I_{IN}$ är inkommande informationsdatabredd i antalet bitar.

$M_{TOT} = S \cdot (M_S+R \cdot f_{DIRAC} \cdot T_{60} \cdot I_{IN}/8)$ byte

Förklaring NOMIX $M_{TOT}$ : För att mellanlagra varje sändares faltningsdata krävs det $S \cdot M_S$ byte. Från varje sändare till varje mottagare behövs det $f_{DIRAC} \cdot T_{60} \cdot I_{IN}/8$ bytes för att memorera impulssvaret som används vid faltningarna. Detta ger följande:

$M_{TOT} = S \cdot M_S+S \cdot R \cdot f+{DIRAC} \cdot T_{60} \cdot I_{IN}/8$

Nyquists teorem

Sampling av en lågpass filtrerad signal med bandbredden B Hz, kräver en samplingsfrekvens på 2B Hz för att få med alla frekvenser upp till B Hz.

Bevis: En våg består av en positiv och en negativ del runt en referens. Oscillerar denna våg B ggr/s runt referensen, kommer vi att ha B st positiva delar och lika många negativa delar. För att få med båda delarna, så att vi kan regenerera vågen, behöver vi sampla 2B ggr/s.

Rise Time

Tiden tills hälften av energin, i den transmitterade diracpulsen, anlänt testpunkten.

Sabine's formel

V är rummets fria volym. $S_i$ är en specifik ytas totala absorptionsyta. $a_i$ är en specifik ytas absorptionskoefficient. m är luftens dämpkonstant och denna kan bortses ifrån om rummet är litet. N är antalet ytor i rummet.

$T_{60}=\frac{0.163 \cdot V}{\sum{S_i\alpha_i+4mV}}$ ${i=1, 2, ..., N}$

Splinefunktion (kubisk)

Definition: Låt $x1<x2<...<xn$ vara samplingspunkterna och en funktion s(x) vara definierad på intervallet $[x1, xn]$ . Vidare skall $s(x), s´(x), s´´(x)$ vara kontinuerliga över detta intervall. För varje delintervall ${ [x_i, x_{i+1}], i=1, ..., n-1 }$ låter vi ett kubiskt polynom interpolera värden mellan de diskreta samplingspunkterna. Då är $s(x)$ en kubisk splinefunktion.

Superellipsoid

$f(x, y, z) = ((x/a_1)^{2/e_2}+(y/a_2)^{2/e_2})^{e_2/e_1}+(z/a_3)^{2/e_1}-1$

$0<e_1<1, 0<e_2<1, f(x,y,z)=0$

Böcker, Mjuk- & Hårdvara

Timeo hominem unius libri

St. Thomas Aquinas

För de som själva tänkt göra något liknande arbete, kan denna up pradning av källmaterial vara till god nytta. Alla följande enheter är nämnda med den mest förekommande enheten överst.

Bokinfluenser

Heinrich Kuttruff, Room Acoustics Andrew S. Glassner, An Introduction to Ray Tracing K. Blair Benson, Audio Engineering Handbook Alan Watt & Mark Watt, Advanced Animation & Rendering Techniques Stewen Brawer, Introduction to Parallel Programming John Watkinson, The Art of Digital Audio

Artikelinfluenser

Yoichi Ando, Calculation of subjective preference at each seat in a concert hall, Acoustical Society of America 74 (1983) 873

A. Krogstad, S. Strøm & S. Sørsdal, Fifteen Years' Experience with Computerized Ray Tracing, Applied Acoustics 16 (1983) 291

Katsuaki Sekiguchi & Sho Kimura, Calculation of Sound Field in a Room by Finite Sound Ray Integration Method, Applied Acoustics 32 (1991) 121

Bokanvändning

Amiga ROM Kernel Reference Manual: Include and Autodocs Amiga User Interface Style Guide Amiga ROM Kernel Reference Manual: Libraries Amiga Hardware Reference Manual Steven Williams, Programming the 68000 Craig Bolon, Mastering C J.D. Foley & A. van Dam, Fundamentals of Interactive Computer Graphics Karl Gustav Andersson, Lineär Algebra Grant R. Fowles, Analythical Mechanics Tobias Weltner, Jens Trapp & Bruno Jennrich, Amiga Graphics Inside & Out

Snabbreferensböcker

Encyclopedia Britannica version 1991 Webster's International Dictionary Jorge de Sousa Pires, Electronics Handbook Carl Nordling & Jonny Österman, Physics Handbook Lennart Råde & Bertil Westergren, Beta Mathematics Handbook Steven Williams, 68030 Assembly Language Reference Alan V. Oppenheim & Ronald W. Schafer, Digital Signal Processing

Programvaruinfluens

Real 3D v2.0, RealSoft Caligari, Octree Lightwave, NewTech Real 3D v1.4, RealSoft Imagine 2.0, Impulse Sculpt 3D, Eric Graham Videoscape, Aegis

Programvaruanvändning

Finalwriter, SoftWood, för dokumentskrivning Deluxe Paint, Electronic Arts, för bildframställning och retouchering TxEd, för programskrivning Tool Maker, Commodore, för GUI frammställning SAS C v6.0 och v6.5 compiler, för programgenerering CPR, för avlusning Enforcer, som avlusningshjälpmedel Devpac 3.0, HiSoft, för optimering Metacomco Macro Assembler, för optimering Maple IV, för hypotesundersökning

Hårdvaruanvändning

Amiga 500+ system 2.1 med 50 Mhz MC68030, 60 Mhz 68882 och 4 MB, för utveckling Vidi Amiga, Rombo, för videoscanning av diverse bilder med Sony Handycam Star LC24-200, för preprint-korrekturutskrift Hewlett Packard Desk Jet 550C, för masterprintout v1.0 Hewlett Packard Desk Jet 520, för masterprintout v2.0 och uppåt Amiga 1200 system 3.0 med 28MHz MC68020 och 6 MB, för testning och utveckling Amiga 1000 system 1.3 med 7.14 MHz MC68000 och 2.5 MB, för optimeringar Amiga 3000 system 3.1 med 25 MHz MC68030 och 25 MHz 68882, för konsistenscheck Amiga 4000 system 3.1 med 30 MHz MC68040, för konsistenscheck Quadraverb, Alesis, för auraliseringsförsök Egenhändigt byggd sampler, MIDI interface samt Mixer för auraliseringsförsök DSS8+ (Digital-Sound-Studio) Hårdvara och Mjukvara, GVP, för auraliseringsförsök Dynamisk Mikrofon, Sherman, för diracsampling (korrelationbestämning modell $\Leftrightarrow$ verklighet)

Referenser

1

Hofstätter, M., Illustrerad Vetenskap 11 (1989) 50.

2

Nya Rön, Illustrerad Veteskap 12 (1993) 19.

3

IEC 581.

4

McGraw-Hill Encyclopedia of Science & Technology 8 (1992) 444.

5

Kuttruff, H., Room Acoustics (1991) 82.

6

Swiatecki, S., Illustrerad Vetenskap 5 (1994) 50.

7

Gabrielsson, A. & Lindström, B., "Perceived Sound Quality of High-Fidelity Loudspeakers," J.Audio Eng. Soc., 65, (1979) 1019-1033.

8

Shaw E. A. G., "The Acoustics of the External Ear" Handbook of Sensory Physiology, vol. V/1: Auditory System, Springer-Verlag, Berlin, 1974.

9

Human Hearing, Encyclopedia Britannica, 27 (1991) 204.

10

Meyer, J. Acoustics and the Performance of Music, Verlag das Musikinstrument (1978)

11

Olsen, H.F., Music, Physics and Engineering, 2nd edn (1967)

12

Cell-To-Cell Communication Via Chemical Signaling (Encyclopedia Britannica) 15 (1991) 599.

13

Toole, Floyd E., Principles of Sound and Hearing (Audio Engineering Handbook) 1.42 (1988).

14

Oppenheim, A. V. & Shafer, R. W., Digital Signal Processing. Prentice Hall, Engelwood Cliffs, NJ, (1975) 242

15

Hilmar Lehnert & Jens Blauert, Principles of Binaural Room Simulation, Applied Acoustics 36 (1992) 285.

16

Adams, G.J. & Watson, A. P., Digital audio processing for simulation of room acoustics. ASSPA, 1989, 103-107

17

Endocrine Systems, Encyclopedia Britannica, 18 (1991) 291.

18

Animal Behaviour, Encyclopedia Britannica, 14 (1991) 662.

19

Pheromone, Encyclopedia Britannica, 9 (1991) 262.

20

Exploration, Encyclopedia Britannica, 19 (1991) 48.

21

Flight simulator, Encyclopedia Britannica, 4 (1991) 834.

22

Möller H., Fundamentals of Binaural Technology, Applied Acoustics 36 (1992) 171

23

Gierlich H.W., The Application of Binaural Technology, Applied Acoustics 36 (1992) 219

24

Lehnert H. & Blauert J., Principles of Binaural Room Simulation, Applied Acoustics 36 (1992) 259

25

Vian J. & Martin J., Binaural Room Acoustics Simulation: Practical uses and Applications, International Symposium on Auditory Virtual Environment and Telepresence (Bochum 8 april 1991) & Applied Acoustics 36 (1992) 293

26

Krokstad A., Strøm S. och Sørsdal S., Fifteen Years' Experience with Computerized Ray Tracing, Applied Acoustics 16 (1983) 291

27

Roese J. A. och Khalafalla A. S., Stereoscopic Viewing with PLZT Ceramics, Ferroelectrics 10 (1976) 47

28

Roese J. A. och McCleary L., Stereoscopic Computer Graphics for Simulation and Modeling, SIGGRAPH '79 Proceedings, Computer Graphics 13(2) (1979) 41

29

Kuttruff H., Room Acoustics, Elsevier Applied Science (1991) 62

30

Forsberg P., Applied Acoustics 18 (1985) 393

31

Choi S. och Tachibana H., Estimation of impulse response in a sound field by the finite element method, Thirteenth ICA No. E11-7 (1986)

32

Borish J., Extension of the image model to arbitrary polyhedra, Acoustic Society America 75(6) (1986) 1827

33

Kirszenstein J., An image source computer model for room acoustics analysis and electroacoustic simulation, Applied Acoustics 17 (1984) 275

34

Krokstad A., Strøm S. och Sørsdal S., Calculating the acoustical room response by the use of a ray tracing algoritm, Sound & Vibration 8(1) (1968) 118

35

Vorländer M. Simulation of the transient and steady-state sound propagation in rooms using a new combined ray-tracing/image-source algorithm, ASA 86(1) (1989) 172

36

Van Maercke D., Simulation of sound fields in time and frequency domain using a geometrical model, Twelfth ICA No. E11-7 (1986)

37

L'Espérance A., Herzog P., Diagle G.A. & Nicolas J.R., Heuristic Model for Outdoor sound Propagation Based on an Extension of the Geometrical Ray Theory in the Case of a linear sound speed Profile, Applied Acoustics 36 (1992) 111

Sammanfattning​

Abstract​

Förord​

Ljudets & Örats Principer​

Ljudets Natur​

Ljudets Utbredning​

Reflektion & Absorption​

Interferens​

Diffraktion​

Refraktion​

Resonans​

Direktivitet​

Efterklang​

Dispersion​

Doppler-effekt​

Upplevelse av Ljud​

Klarhet (Clarity)​

Ljushet, Skarphet & Fyllighet​

Rymdkänsla & Närhet​

Högljuddhet (Loudness)​

Hörselorganet​

Örats Anatomi​

Maskning​

Akustisk Reflex​

Audiobehandling​

Analog Audio​

Digital Audio​

Beräkningsaspekt på Digital Audio​

Virtual Reality​

Definition av VR​

Användningsområden​

Medicin​

Rymdfart​

Underhållning​

Militärt​

Simulatorer​

Computer Aided Design​

Framtidens Programmeringsmiljö​

Musikstudio​

Huvudproblem​

Problemställning​

Problemets Analys & Implementering​

Människa Dator Interaktion​

Grundprinciper​

Inspirationskällor​

Min Lösningsform för Fönster​

Min Lösningsform för Menyer​

Min Lösningsform för Arbetsbänken​

Ikoninteraktionsflöde​

3D Transformeringsalgoritmer​

Bas Algoritmen​

Diskret Optimering Typ I​

Diskret Optimering Typ II​

Diskret Optimering Typ III​

Ljudpropagerings-Algoritmer​

Helanalytiska Lösningen​

Heldiskreta Lösningen​

Spegelkällemetoden​

Strålföljningsmetoden (Ray-tracing)​

Ellipsoidapproximeringsmetoden​

Hybrid-metoden​

En Heuristisk Metod​

Jämförelser​

Cut & Paste Ray-tracing​

Förekommande Implementationer​

Efterklangs-approximering​

Deterministiska Metoder​

Stokastiska Metoder​

Auralisering​

Datastrukturen​

Programmeringsmetodik​

Slutsatser​

3D-Audio instruction manual​

What is 3D-Audio​

What it isn't​

Installing the Software on Hard-drive​

Main Editing Windows​

Objects, Materials, Flights & Characteristics​

Computed Data​

Preferences​

Sammanfattning

Abstract

Förord

Ljudets & Örats Principer

Ljudets Natur

Ljudets Utbredning

Reflektion & Absorption

Interferens

Diffraktion

Refraktion

Resonans

Direktivitet

Efterklang

Dispersion

Doppler-effekt

Upplevelse av Ljud

Klarhet (Clarity)

Ljushet, Skarphet & Fyllighet

Rymdkänsla & Närhet

Högljuddhet (Loudness)

Hörselorganet

Örats Anatomi

Maskning

Akustisk Reflex

Audiobehandling

Analog Audio

Digital Audio

Beräkningsaspekt på Digital Audio

Virtual Reality

Definition av VR

Användningsområden

Medicin

Rymdfart

Underhållning

Militärt

Simulatorer

Computer Aided Design

Framtidens Programmeringsmiljö

Musikstudio

Huvudproblem

Problemställning

Problemets Analys & Implementering

Människa Dator Interaktion

Grundprinciper

Inspirationskällor

Min Lösningsform för Fönster

Min Lösningsform för Menyer

Min Lösningsform för Arbetsbänken

Ikoninteraktionsflöde

3D Transformeringsalgoritmer

Bas Algoritmen

Diskret Optimering Typ I

Diskret Optimering Typ II

Diskret Optimering Typ III

Ljudpropagerings-Algoritmer

Helanalytiska Lösningen

Heldiskreta Lösningen

Spegelkällemetoden

Strålföljningsmetoden (Ray-tracing)

Ellipsoidapproximeringsmetoden

Hybrid-metoden

En Heuristisk Metod

Jämförelser

Cut & Paste Ray-tracing

Förekommande Implementationer

Efterklangs-approximering

Deterministiska Metoder

Stokastiska Metoder

Auralisering

Datastrukturen

Programmeringsmetodik

Slutsatser

3D-Audio instruction manual

What is 3D-Audio

What it isn't

Installing the Software on Hard-drive

Main Editing Windows

Objects, Materials, Flights & Characteristics

Computed Data

Preferences