Video: Unlimited Detail i intervju

Håller verkligen med (Y)

Jag är lite osäker på varför du citerade mig eftersom du trots allt verkar hålla med mig.

Jag kände att jag hade rätt att uttala mig eftersom jag har läst två kurser inom 3D-programmering och har varit relativ påläst om voxlar redan innan denna hysteri startade.

Till skillnad från dig ser jag dock ingen anledning att tvivla på att han skulle använda Point Cloud Data. Han nämnder det i sin första video då han jämför PCD med voxlar, även om han inte är riktigt sanningsenlig i sin bedömning.
http://www.youtube.com/watch?v=Q-ATtrImCx4

När intervjuarern berättar om Sparce Voxel Octree så medger han att det skulle kunna ses som det. Vilket är helt korrekt, för om du verkligen förstår vad ett Octree innebär så förstår du att det i det här fallet inte gör någon skillnad om trädet består av voxlar eller PCD. I en vanlig SVO går man rekursivt igenom alla celler i ett "Octree" tills cellen är lika stora som en pixel på skärmen. Om det inte finns tillräckligt med detaljrikedom sparad för att cellerna ska komma ner i samma storlek som en pixel kommer man se en kub istället. Om det samma händer med PCD i ett Octree kommer man om jag förstått det rätt se en rundad kant, ungefär som vektor grafik.

Ja jag vet att man kan göra voxlar på GPUn, i det här exemplet så beräknar de dock voxlarna på CPUn och ger grafikkortet en "chunk" med voxlar för att extrahera en polygonmesh från den m.h.a. marching cube algoritm.
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

Angående skuggor så förstår jag inte hur det skulle vara något problem med att använda samma depth-buffer till både polygoner och voxlar speciellt eftersom de båda ska kunna kasta skugga på varandra, men annars har du rätt i ditt påstående.

Detta gör dock ingen skillnad, även om de använder sig av PCD så är tekniker som SVO likvärdiga och ingen av dem som har sysslat med det påstår att de kommer revolutionera grafiken för all framtid för det.
http://procworld.blogspot.com/2011/08/unlimited-detail.html

Kan det vara en fördel att spara point-clouds i ett octree för att sedan gör om det till voxlar för att köra marching cubes? Jämfört med att köra ett SVO dvs? Är det bekräftat att de använder MC på GPUn vid rendering?

Edit: Det slog mig just att de inte alls kör MC på GPUn, han säger att de skulle kunna kört på ett grafikkort från 90-talet. (Läste fel och förstod inte att du menade youtube-länken.)

Jag önskar alla hade läst "Psykopatens värld" av Robert Hare, bara för att ha i åtanke när de ser den här intervjun och läser om all tvivelaktig information. Vore väldigt intressant att få reda på om de inte är mer än villiga att folk går in med mer kapital (trots viss antydan på motsatsen i videon). De har redan fått två miljoner dollar av regeringen, och det är nog många andra som trycker på att få gå in med kapital. Tyvärr kommer endast ett fåtal lära sig en läxa, eftersom de flesta fortsatt vill tro gott om alla människor. Och nej, det är ingen dygd att tro gott om alla, det finns många som kan vittna om hur dyrt de fick lära sig den läxan.

Det var ingen kritik utan jag fyllde mest igen det som jag tyckte var luckor.

Det är stor skillnad på point clouds och SVO även om resultatet kan vara liknande. SVO är en extremt simpel representation som också är extremt simpel att traversera. Point clouds är absolut inte det, däremot om man vrider på alla orden som han så kan man ju självklart hävda att voxlar är point clouds.

Point clouds är en bunt punkter i en rymd, en punkt har ingen naturlig tillhörighet till andra punkter utan kopplas ihop via avstånd och liknande parametrar. Mao, det skulle inte ens fungera bra för ändamålet.

Jag känner mig säker på att dom använder SVO, men kanske hittat på några optimeringar för det. Dom säger ju tom själva att dom konverterar point clouds till trianglar, som sedan konverteras till deras format. Varför skulle man ens göra det om motorn bygger på point clouds? (Även påståendet om att det finns "64 atomer per kubikmillimeter" (dvs, 4x4x4) är ett korkat påstående om det är point clouds)

Det är stor skillnad på den länken och den jag posta till, din länk har ingenting gemensamt med UD eller SVO. Tekniken du länka till gör om densitetfunktionen till voxlar för marching cubes som du säger, vilket sedan görs om till trianglar... vad har det med UD eller SVO att göra?

Poängen med UD och SVO är att man kan beräkna en pixel utan att geometrins komplixitet påverkar prestandan i någon större grad. Och triangelrendering bygger istället på att geometrins komplexitet är vad som påverkar och väldigt lite beror på antalet pixlar.

Självklart kan man använda samma depth-buffer till både polygoner och voxlar, men då åker du också på de precisionsproblemen (och övriga problem) som skuggor lider av idag... vilket är ett väldigt stort problem när man har detaljer på den nivån. Det skulle troligtvis uppstå väldigt många konstigheter på ytan och i små utrymmen (vilket även är ett problem idag). Så jag vet inte hur bra det skulle funka i praktiken om man är ute efter detaljer på den nivån som UD visar.

Tanken är bra i teorin om vi haft oändligt med prestanda, men hela poängen med SVO är att datan ska vara extremt snabb att traversera. Om datan inte faktiskt finns utan beror på en dyr matematisk formel så faller det hela. Visst går det säkert utnyttja procedurell generering för SVO i framtiden om det skulle bli populärt, men det skulle inte vara som en direkt lösning på minnesproblemet.

Var det inte per kvadratmillimeter? Jag trodde att de bara behövde lägga "atomer" på ytan av föremålet, inte fylla det med atomer?

Det är säkerligen så ja, men påståendet syftar antagligen på att modellerna dom visar kan ha upp till 64 atomer per kubikmillimeter (dvs, att det är "upplösningen").

PS. Kvadratmilliter kan inte vara rimligt då det skulle implicera ett 2D-plan. Men det spelar mindre roll, slutsatsen skulle ändå vara den samma.

http://en.wikipedia.org/wiki/Perpetual_motion#Invention_histo...

Vad vill du ha sagt egentligen? Att vår kunskap inom aerodynamik för 100 årsedan var obefintlig? Så för att en framstående person gav ett felaktigt uttalande på felaktiga grunder så får vi inte kritisera något, inte ens uppenbart skitsnack? Datorgrafik är ett väldigt seriöst och aktivt forskningsområde, och tekniken UD bygger på finns det också seriös forskning inom. Det är inte magi eller revolutionerande.

Det KAN vara del av grunden till nästa steg inom datorgrafik, precis som vi gått från Forward Shading till Deferred Shading (vilket förövrigt "uppfanns" 1988!). Det betyder inte att vi kunde använda Deferred Shading när folk började forska och visa demon på det. Det är först nu det verkligen blivit användbart. UD och liknande tekniker är inte praktiska som alternativ inom de närmsta åren (det är ingen konspiration av EA).

Han antydde att de inte behöver mer kapital, vad säger att de inte kommer ta in mer bara för det? Han avslutar intervjun väldigt bekvämt genom att mer eller mindre säga "vi kommer gå undan nu, det är så vi jobbar, sen kommer tvivlarna undra vart vi tog vägen, men de kommer få se". Väldigt effektivt sätt att kunna dra ut på tiden utan att behöva leverera. Under tiden kommer de kunna plocka in mer kapital från naiva och giriga investerare. Jag kör med samma metod och säger - vi får väl se.

Själv ska jag somna till fina minnen av Refaat El-Sayed. Och även Valdi Ivancic som skulle sälja laptops för 1000kr och samtidigt annonserade att han ska bli vår näste statsminister.

Hur fanken gör man animationer med point-clouds? Jag är medveten om att det går, men är det svårare med pointclouds i förhållande till en polygon baserad model? Jag pysslade lite med 3Dsmax förr i tiden men är absolut ingen höjdare på´t. Måste man göra en separat model för varje liten rörelse?

Retards gonna post.

Skulle vilja se honom bli intervjuad av Carmac, då skulle vi ganska snabbt få veta vad det här egentligen är.

Finns ju massor av anledningar till att neka kapital! Man slipper bla insyn i företaget och eftersom de är ekonomisk oberoende kan de lika gärna vänta tills ett riktigt stort företag köper upp deras teknik.

and idiots reply

För det första så bygger filmkomprimering på extremt "lossy compression" och det faktum att du har keyframes du kan utgå ifrån när du konsturera alla andra frames. Det är inte på något sätt applicerbart här. Sen får du inte glömma att du kan inte traversera en komprimerad datastruktur utan att packa upp den. Mao, du kan bara ha väldigt lätt komprimerad data. Och lägg då till att komprimeringen man kör för texturer på grafikkort är 1:2 eller 1:4 och har många fula artefakter. Och att JPEG som är väldigt lossy har mellan 1:3 till 1:20 för duglig kvalitet.

Så absolut kan man ha välkomprimerad data på HDDn, men även där går det inte komprimera hur bra som helst, http://en.wikipedia.org/wiki/Entropy_(information_theory), men i minnet är det absolut inte lätt... speciellt inte om det ska gå fort.

1 GB = 1024*1024*1024

Så om varje voxel tar 16 byte så blir det:
1024*1024*1024 / 16 = 67108864 voxlar

Men då har vi inte räknat med att det är octrees, vilket betyder att storleken nästan dubblas eftersom du måste spara alla högre nivåer med (16+8+4+2+1 = 31), åtminnstonne i minnet. Sen tar även representationen för alla tomma slutnoder en viss mängd utrymme.

Men om vi igornerar det, och sprider ut voxlarna på ett PLATT 2D-plan, så blir det:
sqrt(67108864) = 8192 (^2)

Så, för 1GB okomprimerad data får du en helt platt yta på 8192*8192, lägg då till att det är mycket upp och ner, och ska marken tom vara ihålig för att reprenstera grus och gräs och liknande så är det lätt 5-10 pixlar per punkt i 2D-planet.
sqrt(67108864 / 5) = 3663 (^2)

Och då ska vi inte glömma hus, träd, buskar, etc, som kan vara extremt mycket dyrare än så.

Och låt oss säga att vi ha en otrolig komprimering på 1:100:
sqrt(67108864 / 5 * 100) = 36635 (^2)

Och så säger vi att varje punkt i 2D-planet är 1 millimeter stor.
36635 / 1000 = 36.6 meter^2 (EDIT: oops, det är ska vara 36.6m)

Det är inte alls imponerande, trots att vi har en otrolig komprimeringsalgoritm, som vi på något sätt även använder i minnet, och ändå använder vi 1GB... och inte representerar någon typ av material och dess parametrar.

Och som du kanske märker av uträkningar så skulle inte ens en algoritm på 1:1000 (eller motsvariga optimeringar) hjälpa situationen på något avsevärt sätt. Och då har jag ändå räknat till fördel för algoritmen i alla mina uträkningar.

sqrt(67108864 / 5 * 1000) = 115852 (^2)
115852 / 1000 = 115.9 meter^2

Jag hoppas att jag inte gjort något räknefel, isf får ni skrika.

Skickades från m.sweclockers.com

För det första, ta och tagga ner lite. Du räknade fel, jag rättade till det utan att klaga på dig och lade fram fakta. Och jag känner inte för att gå till personangrepp men du har uppenbarligen ingen djup kunskap inom algoritmer om det är ditt svar... vad du personligen tycker bryr sig inte en algoritm om.

En komprimeringsfaktor på 1:100 lär sällan vara något man träffar på i verkligheten, inte ens med lätt komprimerbar data och som går att packa upp snabbt, och om den är rimligt lossy. Oavsett om du nu hittar en algoritm som är 1:100 för voxlar så kommer du aldrig någonsin kunna köra det i realtid (om den inte är väldigt lossy). Och som sagt va, inte ens 1:1000 hjälper situationen avsevärt.

För att du ska förstå sammanhanget så för att få 1:100 i JPEG för naturbilder så är det motsvarigheten till ca 4% kvalitet i JPEG, mao, bilden kommer ut som skräp... och då är det mer eller mindre den bästa komprimeringsteknik vi känner till för naturbilder! .. plus att det är inte ens i närheten av realtid!

S3TC komprimering som man använder för komprimering av texturer som används i realtid idag för grafikkort är 1:4 och 1:6, och med påtagligt försämrad kvalitet.

30m^2 är inte imponerande, det är lika imponerande som vilken annan siffra som helst. Det är inte PRAKTISKT att använda i ett spel, inte överhuvudtaget, och beroende på vad du vill ha för kvalitet kan det vara 3m^2 eller 200m^2, oavsett inte PRAKTISKT.

Och oavsett, det spelar ingen roll att skärmen bara har ~1.000.000 punkter att rita, du behöver MYCKET mer av världen inladdad hela tiden, och låt oss inte ens prata om mardrömmen att streama octrees.

I ett modernt spel kan du ofta representera kilometervis med hus, terräng och effekter med 1GB okomprimerad data. Och om du inte tar fram förstoringsglaset så lär du ha svårt att få känslan att världen är repeterad.

Det är SVOs dom använder, dom har mer eller mindre erkänt det själva och allt dom pratar om tyder på det. Och resultatet dom visar är mer eller mindre identiskt med det alla andra presenterar för SVO.

Det spelar ingen roll om John Carmack själv har utforskat det SVO och alla de typer, om han inte använder det så betyder det att det inte höll måttet av flera olika anledningar. Och även om han nu bestämmer sig för att använda det, så känner jag mig säker på att det inte är på mm-voxel-nivå (fast där möjligtvis materialparameterar genererar fler nivåer). Utan handlar nog snarare om en naturlig vidareutveckling av megatextures över voxelbaserad terräng eller något liknande.

Sen angående UD så vill jag lämna dig med ett sista räkneexempel.

8 GB = 8 * 1024 * 1024 * 1024 = 8589934592
sqrt(8589934592) = 92681 (^2)
92681 / 4 / 1000 = 23 m^2 (4an från 4x4x4 = 64 voxlar per kubikmillimeter)

Det blir 529st 1m^2 block (23 * 23). Så, om vi antar att det går åt ~12 gånger (6 sidor, plus lite extra för kurviga ytor) så många voxlar när vi gör våra 2D-block till 3D, så blir det ca ~44 st block (529 / 12), sen får vi inte glömma overhead i octrees så vi delar på 2 igen som en gissning, så det blir ~22 st block (44 / 2). Viktigt att notera är att jag nu har räknat med att varje voxel kan representeras som en enda byte (vilket inte ens är orimligt då dom faktiskt skulle kunna använda en färgpalett, posiiton behöver inte beskrivas).

Notera att jag då använder de rimligaste värdena jag kan komma på, 8GB har han i sin laptop, det kan vara upp till 64 voxlar per kubikmillimeter, dvs 4x4x4. Och jag uppskattar ett block till att ha en bas på 1m^2. Och vi antar att dom lyckats komprimera varje voxel till 1 byte. Och vips, så har vi 22 st block, och i videon säger dom att dom har 24.

Nej då det är säkert bara en slump att min uträkning ens hamnade i närheten av deras faktiska antal.

Jag diskuterar gärna, men presentera fakta eller något som du kan backa up isf.

Skickades från m.sweclockers.com

http://nwn.blogs.com/nwn/2011/08/is-the-future-of-immersive-3...

Såg att Carmack hade gett ett litet svar på Perssons påståenden. Synd Carmack inte var mer tydlig från början.

Jag citerar:

"Med 1GB kan man beskriva 1048.6kvadratmeter yta med en punktupplösning på 16punkter/kvadratmillimeter!"

Så förklara gärna, för om jag inte är helt snurrig så tar dina 1048 m^2 (och 16 punkter per mm^2) ... 1048.6 * (1000^2 * 16) = 15.6 GB (det är sent och jag är trött så rätta mig gärna om jag klantat mig)

Och då har vi inte ens räknat med att det finns flera nivåer i ett octree, att världen inte enbart är platt och att en voxel kanske bör representeras som mer än 1 byte.

Och sen är det väldigt viktigt att inse att 1048m^2 i praktiken är en yta på 33*33m... det är inte ens i närheten av en fotbollsplan!

Jag accepterar lossyness, jag säger ju tom att dagens grafikkort har 1:4 och 1:6, väldigt lossy. Men som jag visade innan med ett räkneexempel, det spelar ingen roll om du ens hittar en realtidsalgoritm som är 1:100, mängden data du får ut är ändå OFANTLIGT STOR relativt vad som används idag och vad som praktiskt kan distribueras.

Praktiskt som i att, att en kvadratkilometer yta skulle kräva en stor del av bluray-skiva... det är inte praktiskt. Precis som att streama RAW 1080p film över nätet till konsumenter inte heller är praktiskt.

Självklart, du har bra tankar, men med all sannolikhet faller det i praktiken. För vad jag vet så funkar SVO just nu inge vidare med roterade objekt. Så alla objekt skulle behöva vara vridna i 90-graders vinklar (detta kanske däremot går att lösa ganska effektivt, men vad jag vet har ingen visat att det går att göra effektivt än). Ganska fyrkantig värld det skulle bli, isf. Och då utgår du också ifrån att det ens går att komponera ihop flera lager av SVO-objekt effektivt... något som bör vara ett väldigt stort problem i praktiken eftersom du med all sannolikhet behöver traversera samtliga SVO-objekt inom ett område (nu blev kostnaden beroende av geometrins komplexitet igen = dåligt), vilket också med all sannolikhet är varför UD inte gör det utan håller sig till en fast grid... dom slipper överlapp.

Och då kommer man även ifrån den stora fördelen med UD, att du kan göra din oändligt komplicerade modell, och den kommer prestera precis lika bra... visst, den kommer prestera precis lika bra men den kommer istället sluka enorma mängder utrymme. Och för att minska mängden utrymme så skulle det krävas ett gräsligt arbete med att handplacera objekt (vilket då troligtvis kanske förstör prestandan istället). Sen underskattar du alla småeffekter som används idag, en tegelvägg är inte bara en repeterad tegeltextur, utan det ligger säkerligen minst en textur ovan på den som skapar variation över hela väggen. Och samma gäller för allt annat också.

Och sen kommer vi tillbaka till minnesproblemet, allting du nämnde ovan, kan man även göra med trianglar och texturer (och det gör dom!)... vilket betyder att trianglar och texturer alltid kommer vara mycket mer utrymmeseffektivt. Och spelutvecklare har redan utrymmesproblem idag med mer eller mindre alla spel. All låta varje objekt ta upp avsevärt mer utrymme kommer inte lösa det. Och när man får mer utrymme kan man även öka kvaliteten på trianglarna och texturerna.

Vi kan redan idag använda högupplösta displacementmaps (för väggar, mark, etc) och liknande tekniker och det skulle emulera mycket av det som UD stoltserar med... men man gör inte det för prestandan och utrymmet (och tiden!) spenderas bättre på annat håll, som atmosfäriska effekter, ljussättning, skuggor, dimma, etc.

John Carmack har också sagt att Idtech 6 inte kommer att komma på många år. Och jag sa inte att han övergivit det, utan att han uppenbarligen inte använder det just nu, och att om han kommer använda det, så har jag väldigt svårt att se att han isf skulle gå rätt i UDs fotspår.

[/quote]

Och nej, jag säger inte 500m^2 på 8GB, jag sa 22 block på 8GB om du läser hela kommentaren. Dvs, 22 block likt dom som UD använder, och UD använder 24 unika block (och har 8GB minne i sin dator!). Min poäng var att UD har med all sannolikhet inte alls kommit på någon revolutionerande teknik och att minnesutrymmet absolut är ett problem. För dom visar mer eller mindre EXAKT så många block som jag räknade fram att dom bör kunna visa. Och hur intressant är deras värld som isf tar 8GB utrymme?

Allting som är O(N^2) är i praktiken väldigt sällan praktiskt, det gäller även kvadratmeter med voxlar. Dvs, om inte ALLT i hela världen kan representeras som enormt återanvända instanser av voxelobjekt, så kommer utrymmet öka O(N^2) med storleken. Det är inte praktiskt. Och voxlar kommer alltid att kräva mer minne än trianglar och texturer, tills trianglarna bli små som voxlar. Trianglar har inte denna stenhårda begränsning.

Om jag inte gjort fel i min beräkning ovan, så har du visst gjort en felberäkning, om jag pga trötthet själv räknat fel istället så ber jag om ursäkt.

Och min poäng var att du pratar om t.ex hur olika komprimeringsalgoritmer visst kan användas för att komprimera voxlar utan att visa på att det ens finns några som helst belägg för dom går att anpassa till voxlar på det sättet du beskriver.

Jag referrar till ovan, din tanke är väldigt bra i teorin, den löser minnesproblemet (däremot blir inte grafikerna så glada)... men istället förstör den hela poängen med UD om ingen hittar en fantastisk algoritm som kan söka igenom överlappande och arbiträrt placerade och roterade SVO-objekt på O(1) eller väldigt väldigt billigt.

Och tills någon tagit fram en sådan algoritm så kan vi inte heller anta att någon kommer att kunna göra det. Om någon inte kan presentera en vetenskaplig teori för hur det isf skulle funka. Återigen, rätta mig gärna om jag har fel.

Ok, jag missade att det handlade om komprimering. Men du har fortfarande inte visat att det finns några typer av realtidskomprimeringalgortimer som är MINST 1:16 (för annars kommer det fortfarande ta MINST 16GB utrymme i minnet), och där man dessutom kan beskriva en voxel med ENABRT 1 byte. Och där man dessutom inte har någon overhad från octreet. Plus att du antar att hela världen är spikrak och platt. Du har gjort ett otroligt komplicerat problem (en värld) till ett trivialt exempel (ett platt plan).

Hur kan det inte vara ett problem med att 33x33m tar MINST 1GB utrymme (med din icke existerande realtidskomprimering, och utan allt det jag nämner ovan)? 33x33m är ju inte ens lika stort som en counter-strike karta! Och enligt mina beräkningar, så om man inte kan komprimerar datan men istället använder en palett (från 12 bytes till 1 byte), så tar 22m^2 av rimlig data 8GB.

Och det spelar ingen roll vad du påstår om komprimering, det finns förnärvarande inga algoritmer som jag känner till som kan åstadkomma hög komprimeringsgrad och dekomprimering av SVO i realtid.

Ja, och läs ovan, jag tänker anse att 1 liter vatten visst får plats på 1mm^3, det är löjligt, det finns ingenting som stödjer att det skulle vara möjligt, och tills någon bevisar eller lägger fram en teori om hur det skulle gå till, så kan jag inte heller rimligtvis anta att det någonsin kommer vara rimligt (för även om det fysiskt möjligt så är lösningen antagligen att hälla det i ett svart hål).

Nu skrev jag tom fel, jag menade faktiskt 1000m^2 vilket inte ens är i närheten av 1km^2. Vilket är löjligt lite, som sagt va, det är inte ens i närheten av en fotbollsplan (ett hyreshus eller vad du nu vill jämföra med, och det krävs mer variation än bara en vägg och ett fönster).

Och återigen, om du utgår från att vi kan hitta sätt att låta UD använda 100GB utrymme, fundera då även på vad man kan göra med trianglar om vi ger dom 100GB utrymme. Väldigt mycker mer skulle jag gissa.

Det är meningslöst att argumentera med "vadå långsamt? långsamt idag var snabbt för 100 årsedan! så därav är ingenting snabbt eller långsamt, och min bil är därför lika snabb som din.".

Och här håller jag inte med dig det minsta, att argumentera över teoritisk framtida utveckling är löjligt. Då antar jag också att vi hittar en algoritm som mappar trianglar till ett octree på O(1) och därmed blir trianglar bättre än SVO på alla sätt... och så räknar jag med att vi kan komprimera varje triangel till 1 byte. Alla problem lösta, SVO är meningslöst... men det kanske inte funkar i praktiken!

Jag anser att situationen i UD skulle vara värre i praktiken, men eftersom det inte finns några verktyg idagsläget så är det självklart svårt att ge några konkreta exempel. Min poäng var iaf att UD marknadsförs som "skanna en palm", så har du en palm i spelet, om du istället måste klippa upp den i löv och stomme, och sedan kopiera och placera dessa förhand så har mycket av poängen och unikheten försvunnit.

Vadå man kan "ha små voxelbitar som du lägger på teglet"? Hur sjutton skulle det gå till, ytterligare en massa SVO-objekt med "kludd" som man överlappar? Och visst man kan ha flera variationer av tegel. Men det jag menar är:

http://borralm.files.wordpress.com/2010/10/brick_wall.jpg
Det skulle kunna vara en tegelvägg i ett spel, först har man en tegeltextur som upprepas, sen ovanpå det har man lagt en till textur som ger till synes oändlig färgvariation. Dvs, om du skulle gjort det i ett spel så skulle ingen tegelsten på väggen se ut exakt som någon annan, även om grundtexturen upprepas många gånger. Det går dra det här mycket längre, man kan även använda displacement mapping och tessellering, och så har man något som är väldigt likt UD! Du skulle tom kunna sampla tegelstenar i realtid på GPUer för att göra hela väggen unik... och det skulle återigen krävs mindre utrymme.

Och jag ser verkligen inte dragningskraften med detaljrikedomen som visas i UD, trianglar kan emulera det mesta av detaljrikedomen, redan idag om man slipper tänka på shading och allt annat som måste in i ett spel (t.ex. som att folk inte har obegränsat med RAM!). Men som sagt va, det finns ens praktisk sida i det hela också, och den är inte än på några år, och om några år så har nog trianglar tagit ännu några steg längre frammåt.

Ja, det är väl självklart det finns en brytpunkt där trianglar och texturer bli mer ineffektiva, dvs, troligtvis då en triangel i medel motsvarar ~4-8 voxlar kanske. Och det finns absolut ingen anledning att någonsin göra på det sättet. För på den nivån funkar tessellering, procedurell genering och displacement mapping bättre. Dvs, det finns ingen anledning att någonsin lagra så små trianglar.

Du kan kolla Unigen Heaven som du säkerligen känner till, det kör i full FPS på modern hårdvara, och visst, det har inte riktigt samma nivå av detaljer som UD, men UD går inte ens att använda i realtid i spel idag! Och verkligen, hur mycket mer detaljer än vad som visas i Unigen behövs i praktiken?

Nej det sa jag faktiskt inte, 500m^2 på 8GB var innan jag gjorde klart alla beräkningarna i kommentaren (där jag in octree overhead, etc). Och därefter har jag ingen aning om vad du snackar om.

Eh va?
Självklart är dina teorier inte omöjliga, men fram tills att någon ens lägger fram några belägg för att dom funkar så är det totalt meningslöst att anta att dom är sanna. Som sagt va, jag antar att vi hittar en log(N) komprimeringsalgoritm i framtiden, för det verkar lösa mina problem väldigt väl.

Voxlar är mer eller mindre den yttersta generaliseringen av en värld (atomer), mao, så för att SVO ska vara effektivt så måste voxlar vara den absolut bästa approximeringen av ett problem. Och en voxel är inte det, fördelen med voxlar är att dom är "atomer", så man kan approximera de flesta objekt väldigt väl, men inte utrymmeseffektivt. Trianglar är en mindre generell approximering som bygger på observation att många ytor är platta eller har en platt utgångspunkt som sedan kan tesselleras för att skapa variation.

Dvs, varför vill vi representera en tegelväg som individuella voxlar, när man kan representera den som en enda stor quad som tesselleras och displacement-mappas och på så sätt kan varje tegelsten i väggen bli tillsynes helt unik och samtidigt vara ungefär lika detaljerad som SVO-alternativet, samtidigt som man kan göra den oändligt stor. Och allt som krävs är, 1 quad, 1-4 lagom upplösta texturer och några shaders.

Jag vet inte riktigt vart diskussionen tagit vägen, men UD är inte praktiskt idag (prestanda, utrymme, etc), och det är säkerligen flera år tills det ens finns hopp om att det blir praktiskt. Och om det blir praktiskt då bygger på att vi väldigt effektivt löst komprimering, animering, etc OCH dessutom utvecklat bra verktyg för att jobba med det. Vilket är väldigt stora problem. Notera att jag säger ingenting om SVO generellt, för det finns säkerligen praktiska användningsområden för SVO redan idag, men UD har en väldigt specifik fokus.

Och det går inte argumentera förbi att utrymme är ett problem för trianglar och texturer även idag, voxlar kan omöjligt vara mer utrymmeseffektiva för samma kvalitet för praktiska ändåmål i dagsläget.

Sen tycker jag återigen att det blivit väldig hysteri kring detaljerna i UD, som sagt va, moderna grafikkort klarar av pressa ut liknande grafik i 60 FPS om dom också skiter i shading och alla andra effekter. Men som sagt va, spelutvecklare har som tur va insett att detaljstudera stenar och grässtrån är långt ifrån det viktigaste man gör i spel... utan att helhetsintrycket är det viktiga, animering, atmosfär, ljussättning, skuggor, variation, dimma, effekter, etc. Och det enda SVOer visat för sig hitills i någorlunda realtid är en ytterst repeterad, platt och statisk och solid värld... men väldigt detaljerad.

Skickades från m.sweclockers.com

Grejen är ju att de gör det på EN kärna i en laptopprocessor. Då har de HELA gpuns beräkningskraft kvar till dina effekter.