[Løst]Problem med ray-tracing og skriving til buffer

[GeirGrusom]

Hei

 

Jeg har kanskje verdens snodigste feil nå, og det er såpass lite og enkel kode at jeg ikke kan fatte hvordan det kan skje

 

pr er en ray for en spesifikk pixel, it er iterator for primitivene og ints er punktet der pr kolliderer med primitiven.

volume_pixels er et dynamisk allokert array med float3(posisjon) og float4(farge)

float3 ints;
if(ray_intersect_primitive(pr, *it, ints))
{
  /*
  volume_pixels[i + offset].pos = ints;
  volume_pixels[i + offset].color.x = 1;
  volume_pixels[i + offset].color.y = 0;
  volume_pixels[i + offset].color.z = 0;
  volume_pixels[i + offset].color.w = 1;
  */
  break;
}
else
{
 volume_pixels[i + offset].pos = pr.normal;
 volume_pixels[i + offset].color.x = 1;
 volume_pixels[i + offset].color.y = 1;
 volume_pixels[i + offset].color.z = 1;
 volume_pixels[i + offset].color.w = 1;
}

 

Ok, denne koden går i en løkke for hver primitiv. Problemet er at det jeg har remmet vekk skaper en utrolig merkelig feil

 

Koden sånn den er nå gir dette resultatet:

 

 

Som er som forventet

 

Derimot når jeg tar vekk remmen (som skal føre til at alle objekter som blir tracet skal dukke opp som røde) blir slik:

 

 

Når jeg debugger så blir y mer eller mindre lik 1 og jeg FATTER ikke hvorfor det blir sånn. En skulle tro det var noe galt med ray-tracing funksjonen, men problemet er bare at det også da plutselig gjelder perspektiv-"seilet" (de to vite arkene) så da må det være noe annet...

Noen som har noen peiling på hva det kan komme av?

De røde strekene er vieporten som treffer et horisontalt plan langs (0,0,0) men jeg tror jeg har skrevet den funksjonen feil.

Endret 30. september 2009 av GeirGrusom

[GeirGrusom]

 Bah! Fant ut av det med en gang jeg hadde postet denne... typisk etter å ha sittet i 15 minuuter uten å skjønne en dritt, så dukker det opp.Feilen lå i ray-plane funksjonen, som gir helt riv ruskende gale verdier, og clamper punktene til planet.

 

 

Så dette ble resultatet når jeg byttet fra debug OpenGL visning til ferdig raytracet bilde, ikke noe stort, men ihvertfall en start:

Endret 30. september 2009 av GeirGrusom

[GeirGrusom]

Ble ferdig nok med dette i går, så jeg legger ut binærfilene, og kildekoden her

Det er dog noe galt med ray-plane intersect funksjonen jeg skrev, som jeg har prøvd å fikse en stund uten å forstå hva jeg har gjort feil

 

Programmet krever dog SDL 1.3 og OpenMP, og OpenGL for debug visning (definér #USE_GL i main.h)

Programmet skal teknisk sett kompilere under Linux, men jeg har ikke prøvd.

 

Programmet er ikke så veldig objektorientert, på grunn av at tanker en å implementere det i OpenCL for å se ytelsesforskjellen.

 

kildekode:ray_trace_src.zip

 

binærfiler for x86 og x64 Windows:ray_trace.zip

[Largie]

Krever kanskje mer enn SDL library, exception ved oppstart her...

[GeirGrusom]

Jeg kan tenke meg at du kjører 32-bit versjon og mangler Visual C++ Runtme Library? Jeg glemte å velge den som static linking i 32-bt versjonen.

http://www.microsoft.com/downloads/details...0D-3802B2AF5FC2

 

64-bit versjonen går dog betraktelig raskere enn 32-bit av en eller annen grunn. Jeg har heller ikke testet på mer enn en dual core, men teoretisk sett skal den bruke opp til 4 kjerner (tror jeg)

[Largie]

Kanskje, kanskje ikke... Har jo installert Visual Studio 6.0, 2005 og 2008 så jeg burde være dekka

 

Uansett, var ikke så farlig for meg... Ville bare se litt gode gamle raytraces igjen

[GeirGrusom]

^^

Vel, både 32-bit og 64-bit fungerer på alle mine maskiner, men det er litt vanskelig å vite hva problemet er når jeg ikke kan reprodusere det :/

 

Egentlig ville jeg skrive det for OpenCL, men jeg måtte nesten skrive den i vanlig software først.

[Giddion]

Begge filene starte veldig fint meg, men de stopper ikke like lett

[GeirGrusom]

Hehe nei sant, det er noe merkelig med avvsluttingen i SDL 1.3, men det funker fint å trykke på Escape, men det skulle også funket å krysse det vekk... vel teori er visst noe annet enn praksis.

[AMajor]

jeg har en uferdig raytracer koda i software som jeg jobber litt med innimellom. For et par dager siden implementerte jeg adaptiv subsampling, men driver og forsker litt på hvordan jeg kan optimisere den enda mer. En ganske tidlig rendera-versjon av den ligger på youtube:

 

Det er litt gøy og se at andre driver med raytracing også.

[GeirGrusom]

Nice!

 

Du har litt flere effekter enn meg inne ser jeg :S

 

Har dog fikset skygger og plane nå, men akkurat nå jobber jeg med å skrive den over i OpenCL for å se om jeg får noen solid ytelsesbedring, helst burde det gå glatt i full oppløsning på såpass enkle scener, kanskje såpass mye bedre at jeg kan legge til anti-aliasing?

[Skagen]

Fikk "bare" 11 FPS. Skulle tro det skulle gå litt kjappere uten så mange effekter og enkel geometri når det var skjermkortet (8800GT) som renderte.

Endret 5. oktober 2009 av Skagen

[GeirGrusom]

Japp, håper på det.

Men jeg kjenner OpenCL godt kunne vært laget bedre, hvorfor i helsike er float8 og float16 definert, men ikke float3? hva i svarte svingende tenkte de på? Det er en temmelig vanlig datatype, og er støttet av alle shading språk, hvorfor er det ikke i OpenCL?

Jeg kan ikke skjønne at float8 og float16 er mer nyttig enn float3...

 

Og det er litt i overkant C99.

 

edit: Hvorfor støtter ikke OpenCL rekursive funksjoner? virker som en temmelig vilkårlig regel egentlig...

Endret 6. oktober 2009 av GeirGrusom

[GeirGrusom]

Jeg har sittet med en liten idé i hodet mitt. Jeg får ikke OpenCL til å kompilere (den sier at JIT bytecoden er feil på linje 503 av 392 linjer med kode)

Så jeg tenkte en tanke for å optimalisere ytelsen endel... hva med å bruke heltall fremfor flyttall? Hvis jeg velger et vilkårlig tall som "1" la oss si 65536, og at long long erstatter float.

Ville en ikke kunnet få en drastisk høyere ytelse? Ser dere noen problemer med det? (annet enn manglende sqrt for heltall)

[AMajor]

GeirGrusom: det kommer litt ann på. hva med å profilere koden din og sjekke hvor bottlenecken ligger? jeg gjorde det med min (den er software rendra) og jeg fant ut at det som tok flest cpu cycles lå i Trace funksjonen. så kanskje et lite tips.

angående float to integer så vet jeg ikke helt, floats tror jeg er så rask på gpu og i sånne tilfeller beregnet for floats, men du kan jo prøve uten at jeg vet om det er der ting går tregt hos deg. så som jeg sa, anbefales det å profilere koden din først.

[TheMaister]

GPUer sin styrke og grafikkytelse ligger vel i flyttallsytelse så vidt jeg vet.

[GeirGrusom]

GPU-er sin styrke ligger i at den kan utføre veldig mange operasjoner samtidig, og er laget kun med flyttall i tankene.

 

Men glem GPU-en et lite sekund, jeg får ikke nVidia OpenCL til å kompilere allikevel.

 

CPU-en er betydelig flinkere med heltall enn med flyttall. Tanken var at dette kunne blitt brukt fremfor flyttall, og da prosessoren ofte er 64-bit har den for meg en tenkt mulighet:

Dersom en skalerer 1 til å bety meter, mens en måler i nanometer, altså 1 m = 1000000 nanometer, så vil en kunne flytte en vertex innenfor et tredimensjonalt rom som dekker 9 tusen milliarder meter (hvis en bruker signert 64-bit heltall) så overflow er ikke et problem med mindre en skal rendre en galakse i realistisk målestokk.

 

rydi: kan du anbefale noen profilere? Jeg har aldri hatt bruk for det tidligere.

[AMajor]

rydi: kan du anbefale noen profilere? Jeg har aldri hatt bruk for det tidligere.

 

Jeg testa Intel sin VTune for ikke så lenge siden. Har ikke brukt den så mye, men det jeg fant var hvilke funksjoner som brukte mest cycles og så kunne man sjekke cycles per linje inni valgt funksjon. jeg har ikke testa andre profilere, men VTune ga en god indikasjon på hvor cpu'en jobbet mest.