Intel visar raytracing i Wolfenstein

Dom har gjort upp med sitt förflutna betydligt bättre än de flesta andra, han kallade nazarna för monster inte alten kamraden.
Till saken hör också att en 70 årig tysk var 5 år vid krigsslutet, inte många ansvariga vid liv i dag.
Intressant demo, som faktiskt visar att det fortfarande är långt kvar enligt min mening.

Haha aa, håll Crysis maxinställningar utom räckvidd för spelbar fps 10 år till xD

Tyckte det såg direkt förjävligt ut.. Rök och eld har sett snyggare ut än så i spelen i många år.

Om de verkligen har raytracing i realtid inom räckhåll tycker jag att de hade kunnat demonstrera med något som faktiskt ser snyggt ut. Vissa detaljer såsom ljusbrytningen i glaslampan såg dock läckert ut.

Hmm, blev också lite konfunderad där. Vilka monster tänkte jag, jag ser inget, bara soldater som springer runt runt. Vad menar han ?

På vilket sätt är det förnekelse att kalla dom för monster? Du kanske skulle vakna upp till verkligheten vad som hänt i Tyskland de senaste 100 åren.

Bilen, ljuskronan och framförallt det demonstrationen gick ut på raytracingen var high tech. Så nej elden var inte det minsta high tech, däremot om du lyssnade på vad han sa hur ray tracingen fungerade genom elden var rätt high tech.

Största fördelen, som jag ser det, är att antalet polygoner blir totalt ointressant. Dvs, man kan göra extremt bra modelleringar utan att det har någon inverkan på prestanda.

Tycker ljussättning för det mesta är imponerande bra gjort i de flesta högkvalitativa spel idag. (Även om det inte kommer kunna mäta sig med en fullständig raytracing-miljö.

Tyvärr så är det ju en metod som kräver brute force, vilket förklarar hårdvaran. Intressant är dock att jag tycker Intel framförallt har visat ganska många raytracing-demos med ungefär liknande fps och upplösning i flera år. Dvs tidigare har hårdvaran varit betydligt sämre, men fortfarande har vi liknande prestanda. (Skulle väl kunna förklaras av att dom eventuellt har ökat antalet "ljusstudsar" för mer realism antar jag.)

Prestandan blir ju rätt kass om man måste göra en aa effekt tex, dvs många samples för en pixel på skärmen, också som fog sa så är ju ljusstudsarna viktiga i ray tracing för reflektioner och rätt belysning, detta kommer antagligen att justeras av parametrar om ett spel skulle använda ray tracing.. För övrigt finns det många optimeringar inom ray tracing som också finns i vanliga spel, bounding volumes, spatial data structures etc så blir väll inte riktigt brute force...

Men när vi börjar kunna köra raytracing på vanliga datorer så kan det ju bara bli snabbare i framtiden, har man väl passerat gränsen så blir det nog inga större problem att driva det, självklart kommer studsarna att begränsas rätt mycket i början men hur stor skillnad det blir återstår & se...

Hmm, Raytracing i sig är ju inget nytt. Men det coola här är ju att dom lyckats göra det i realtid, i någorlunda spelbara fps.
Om man följer Moore's lag så kommer man krympa ner antalet servrar med hälften om 18månader, så om 3år bör vi kunna se En maskin som klarar av att köra detta demo. Sedan hur lång tid det tar innan en vanlig PC klarar av det vettefan, har inte tryckt i mig tillräckligt mycke kaffe ännu.

I demot så verkar det ju enligt hans förklaring att kristallkronan slöar ner systemet med 50% just pga antalet polygoner.

The basics är inte så svårt som man tror, dock kanske man får tänka till lite om man vill ha fler effekter osv...
Man skickar i princip en stråle från skärmens yta & in mot skärmen, sedan kollar man kollisioner med geometriska objekt , bounding volumes (boxar, sfärer) först tex för att kunna välja bort djupare skärningstester på tex polygonnivå om miss... strålen fortsätter från ett objekt med en färgad stråle med typ ingångsvinkel=utgångsvinkel till nästa objekt (lite mer färgad stråle) och sedan kanske till en ljuskälla som lägger till sin egna färg och styrka. Sedan kan man knacka in att strålen skall brytas genom material, som glaskulor, strålen fortsätter genom objektet med nån fördefinierad brytning som kan ge fisköge-effekter.

Detta görs för varje pixel på upplösningen man kör, flera samples kan behövas för ljämna kanter, som anti-aliasing tex.

Hur menar du nu?

Tänkte skriva ungefär vad du skriver om optimeringar, men var för trött för att fortsätta. Ptja, om man verkligen menar äkta ray-tracing (utan försämringar gällande kvalitet) så vet jag inget annat sätt än att göra tokmycket beräkningar.

Skulle tro det handlar om att det ljus som når kristallkronan studsar väldigt många gånger och påverkar en stor area. Hade kristallkronan inte haft "glas-egenskap" så hade det nog sett annorlunda ut.

Så jag vet inte hur man ska uttrycka det, en sanning med modifikation? Hade det bara varit en enda polygon som modell för kristallkronan (spegel) hade det ju inte varit många vinklar att beräkna jämfört med nu.

Men ja, indirekt så har du inte i närheten av samma begränsning gällande polygoner som med rasterisering.

Läs om skillnaderna mellan raytracing och rasterisering.

Fler polygoner innebär ju flera skärningstest, som också beror på hur bra man delat upp dessa i okomplexa former (bounding volumes) tex...

Äkta raytracing? "Klassisk" (whitted) raytracing skjuter rays från pixlarna ut i scenen, och beräknar sedan färgen där den träffar med en lokal ljusmodell t ex Phong. Med denna modell är det inte ljuset som studsar direkt, utan man följer strålen från kameran till en diffus yta (eller tills energin är för låg alternativt man når det maximala antalet traces man har).

Att det skadar prestandan mycket är nog delvis för att den består av många polygoner, samt att raytracingalgorithmen är rekursiv och vid glas (reflekterande och brytande) skapas två nya rays vid varje intersection.

Jag ser ingen uppenbar anledning till varför raytracing skulle vara mer oberoende av hur stor scenen är jämfört med rasterisering. Tänk t ex om du har en scen med tre sfärer som du ska rendera med raytracing (alla är diffusa, för enkelhetens skull). Då får du köra en ray-sphere-intersection tre gånger. Har du sex sfärer, sex gånger osv. Det finns självkart smarta datastrukturer osv att lagra scenen i för att göra detta snabbare, men det utgår jag från finns till metoder som använder rasterisering också.

EDIT: Är det optimeringar med kd-träd och liknande som är lättare att använda iochmed raytracing möjligtvis?

Är det något väldigt uppenbart jag missar?

Jag har bara kollat videon utan ljud, men det verkar ju som att dom inte har förklarat hur deras ray tracing fungerar, datastrukturer, algoritmer osv så är ju omöjligt att veta... sen hur effektivt det är att splitta det på så många trådar, skalar det bra? dåligt?

Som du säger markusW så blir det ju enormt mycket beräkningar just vid kronan då strålarna bryts, men lite ballt att se att ljus studsar bort mot väggen... dock verkar dom alldeles för få och det som skiljer mot riktiga ljusprickarna om det är kristall är väll regnbågsfärgerna...

Ah jag tänkte faktiskt inte på att det var causticseffekter också. Nu blev man ju lite mer nyfiken på vad det faktiskt är för metoder de använt.

Rent allmänt så skulle man ju i princip kunna köra varje Ray i sin egen thread, alltså skulle man kunna köra varje pixel på skärmen med en egen thread. eller något sånt... i Framtiden när vi har GigaCore processorer, så skulle man kunna låtar varje core ansvara för en pixel på skärmen.
Eftersom raytracing är baserad på mjukvaruberäkningar, och inte är beroende av hårdvarans begränsningar, så kan man i princip räkna lite hur man vill. (här menar jag exempelvis dela upp arbetet i många threads.) Iallafall tills hårdvaran börjar stödja raytracing, sen är man låst till vad hårdvaran/standarden tillåter.

För dom som fortfarande inte förstår vad raytracing är, så kan jag säga att raytracing är baserat på äkta fysiska beräkningar på ljus. medans vanlig 3D som vi har nu är mest ett fulhack får att få det att 'Se ut som" äkta. (dvs behöver inte nödvändigtvis vara baserad på fysik alls.) fördelen är dock att fulhacket är mycket snabbt jämnfört med raytracing. medans raytracing räknar hur äkta ljus beter sig.

Ja åtminstone i större mån än tidigare men det är fortfarande bra mycket "fulhack" i raytracing mot hur äkta ljus beter sig.

Det är sant, men det finns inget som hindrar att köra (högst) en tråd per pixel. Att köra mer än så låter lite onödigt, då de flesta skärmar ändå har ungefär (minst) en miljon pixlar och då kanske man vill multisampla också. ^^

bara schemaläggaren klarar av det med så många trådar, behöva gå igenom vilka trådar som för närvarande inte gör något skulle ju ta sin lilla tid för att fördela dit en ny stråle... sen bör ju alla bli någesånär lika behandlade...

men men, synd vi inte fick reda på mer...

Allt för många trådar sänker CPU:n, att hoppa mellan trådar kostar ganska mycket CPU-tid.