3D render op een FPGA

Eerst je algoritme maken in een hogere taal en dat omzetten naar een fpga ontwerp. Overigens had Wolfenstein een zeer slimme en toch eenvoudige techniek om snel 3D plaatjes op het scherm te zetten. Met Google moet daar wel wat over te vinden zijn.

Heb je al enige ervaring met een 3D interface op je PC, openGL en dergelijke? Dat is een belangrijke opstap voordat je echt zelf 3D computer graphics gaat produceren.

Hier wat wiskunde:

Om een een coordinaat (X,Y,Z) te roteren om het punt (0,0,0)
kan je als volgt doen:

roteer coordinaat eerst om de X-as,

Ytemp = Y * COSINUS(Xhoek) - Z * SINUS(Xhoek)
Ztemp = Y * SINUS(Xhoek) + Z * COSINUS(Xhoek)
Y = Ytemp
Z = Ztemp

roteer coordinaat dan om de Y-as,

Xtemp = X * COSINUS(Yhoek) - Z * SINUS(Yhoek)
Ztemp = X * SINUS(Yhoek) + Z * COSINUS(Yhoek)
X = Xtemp
Z = Ztemp

roteer coordinaat dan om de Z-as,

Xtemp = X * COSINUS(Zhoek) - Y * SINUS(Zhoek)
Ytemp = X * SINUS(Zhoek) + Y * COSINUS(Zhoek)
X = Xtemp
Y = Ytemp

Het coordinaat is nu klaar om van 3D naar 2D te projecteren:

Als schermdiepte kan je nemen b.v. 256

X = Schermdiepte * X / Z + ( Schermbreedte / 2 )
Y = Schermdiepte * Y / Z + ( Schermhoogte / 2 )

Dit is de eenvoudigste manier, je zou ook gebruik kunnen maken van matrices

Eventueel heb ik nog wel een zeer oude Assembler source ( voor DOS ) waar ik een kubus laat roteren.

Aan alle bedankt om te antwoorden.

@Siekmanski: Zo iets had ik ook in gedachten.
http://en.wikipedia.org/wiki/Bresenham's_line_algorithm
Hier staat een leuke en simple algorithme om lijtje te tekenen. Morgen heb ik hopelijk tijd om wat te testen.

Robin

Misschien is deze pagina ook interessant, al is het geschreven voor een PIC, in C. De achterliggende wiskunde kan je misschien wel gebruiken. http://www.pyrofersprojects.com/blog/?page_id=3

Op 27 januari 2008 22:13:21 schreef Squant:
Heb je al enige ervaring met een 3D interface op je PC, openGL en dergelijke? Dat is een belangrijke opstap voordat je echt zelf 3D computer graphics gaat produceren.

Dat gaat wel meteen erg ver. Je kunt zoals andere reacties ook al uitwijzen ook makkelijker beginnen met 3D. De TS hoeft natuurlijk niet meteen complete games gaan ontwerpen maar wil gewoon wat spelen met FPGA en daarvan leren en wil gewoon wat simpels genereren. Voordat OpenGL en DirectX bestond was er ook al 3D graphics.

@robint91: Post je ook je resultaten? Ik denk dat wel meer mensen geinteresseerd hierin zijn. Het kan uiteraard hier maar er is ook een groot FPGA topic waar mensen het wel willen zien. Echter kun je ook altijd daar een postje maken verwijzend naar deze post.

Edit: Ah ik zie dat je daar je Spartan al hebt gepost > CPLD-FPGA eenvoudige voorbeelden

@Eagle666: Morgen ga ik beginnen met lijn algorithmes aka 1ste graad functies.Ik wil eerst een wireframe hebben runnen. Ik heb bestaande code die me wat vooruit helpt: hsync en vsync generatoren en een RGB generator. Ik denk dat ik ook best ga uitzoeken hoe ddrram werk en zit laat aansturen.

Robin

ik doe ongeveer hetzelfde op een de1 boardje in vhdl
heb ook gisteren vga aan de gang gekregen,

als robint91 kaas van mirc/irc gegeten heeft
kan je op irc.freenode.com eens langs komen in #openhardware ( om niet een msn topic te maken )

heb ook al een blockje voor een keyboard in telezen aan de praat en zit nu zelf ook idd met een frame buffer rgb aansturing etc

en dan uiteindelijk wat op beeld te hebben en te manipuleren etc

Hey

@sould3mon: ik zal sevens eers zien.

@allen: Wie kent er een hele kleine 16bit proc?

Robin

Even een tip: Vrijwel alle computer graphics kan met 4x4 matrixen (xyzw). De W leg ik zo uit.... Die rotatie om X as van hierboven is dus een matrix:

1      0            0        0
0  cos(xhoek)  sin (xhoek)   0
0 -sin(xhoek)  cos(xhoek)    0
0      0            0        1

Als je dan een tweetal rotaties achter mekaar wilt doen, hoef je niks anders te doen dan die matrices met mekaar te vermenigvuldigen. Of je nu 1 of 10 rotaties of zo wilt doen, dat maakt allemaal niet uit: Het kost maar 1 4x4 matrix vermenigvuldiging!

W is altijd 1. de matrix voor translaties is dus dan makkelijk te maken....

Om projecties op een vlak te doen (hetgeen je doet als je op een plat beeldscherm terecht wilt komen) zit er een deling in het geheel. Die maak je door TOCH dingen bij W op te tellen.

Als we willen projecteren op het Z=1 vlak, met de oorsprong als punt waarheen we projecteren, wordt (x',y',z') = (x/z, y/z, z/z). De 4x4 matrix is dus:

1 0 0 0
0 1 0 0
0 0 1 0
0 0 1 0

Je uitgangs vector is dan (x, y, z, z), waar ineens W niet meer 1 is. Je moet het hele ding dan normalizeren: delen door de huidige W waarde om de W-waarde weer gelijk aan 1 te krijgen.

Als je dus naar een object kijkt vanuit een camera oogpunt met een "kijk-vector", dan is de matrix daarvoor ontzettend lastig te bepalen. Maar als je eerst de hele ruimte eens transleert zodat de camera in de oorsprong komt, vervolgens om de X-as roteert zodat de kijkvector in het XY vlak komt te liggen, en vervolgens om de Y as, zodat ie ook in XY vlak ligt, zit je ineens te projecteren op een Z=constant vlak! En daar weten we de projectie matrix ineens WEL van!

Voor ieder van die stappen maak je een 4x4 matrix. Al die stappen achter mekaar, gewoon de 4x4 matrices vermenigvuldigen!

Professor Blinn, van Caltech heeft me dit geleerd in 1985..... Het werkt nog steeds.

Op deze manier vertaal je de 3D punten van je object naar schermcoordinaten. Heb je die, dan moet je daar nog lijnen tussen trekken. Dat gaat met bresnham:

Xn+1 = Xn + eps * (Xend - Xstart);
Yn+1 = Yn + eps * (Yend - Ystart);

Hierbij is het voor computers handig om eps = 2 ^-iets te kiezen. Dan hoef je niet dik te rekenen voor het 1 en ander. Je kunt bijvoorbeeld Xend-Xstart en Yend-Ystart beide door 2 blijven delen (schuiven) totdat ze beide onder de 1 zijn. Dan krijg je mooie lijntjes zonder gaten...

Tip: Oefening om de lijnen aan de gang te krijgen: Maak een "STIX" (of heet ie STYX) screensaver. (je hebt twee eindpunten die over het scherm stuiteren, er wordt steeds een lijn tussen de twee eindpunten getekend, die pas 10 frames later weer wordt weggehaald). (Was een leuke screensaver in het apple2 en C64 tijdperk).

[Bericht gewijzigd door rew op donderdag 31 januari 2008 16:52:27 (18%)]

Voor (snelle) algorithmen:

Wellicht kun je de artikelen van Micheal Abrash uit Dr Dobbs' Journal (begin jaren 90) nog ergens bemachtigen. Google eens op Mode X.

(Ik word er bijna melancholisch van als ik daaraan terug denk)

@rew: zeer hartelijk bedankt voor uw uitleg. Ik wil eerste bresenham aan het bollen krijgen. Weet iemand een kleine 16bitter en een ddr sdram controller?

Robin

In xilinx zit ergens bij de ip cores de MIG generator. Heeft weinig met dat vliegtuig te maken , maar staat voor memory interface generator. In deze generator zit een knopje met "starter-kit files" of iets van die strekking. Hier zou het mee kunnen werken.

Ik heb het aan de gang gekregen met de core van opencores, is vast nog wel ergens te vinden.

Nu heb 340 rare fouten van xilinx xst. Hij optimalseert gans mijn processor weg. :(
Xst:1710 - FF/Latch <REGD_3> (without init value) has a constant value of 0 in block <XLXI_1>.
zo krijg ik veel warnings.

de code:
http://robin.tussen.be/GPU16BIT.old.v

Robin

edit:

de hele lijst van warnings
http://robin.tussen.be/warnings.txt
pasop (40Kb)

actief lage reset die aan massa hangt?

WARNING:Xst:852 - "TOPLVL.vf" line 39: Unconnected input port 'RESET_i' of instance 'XLXI_1' is tied to GND.

[Bericht gewijzigd door stecj366 op zaterdag 2 februari 2008 00:17:37 (60%)]

@stecj366: dat is het probleem niet. Zie code?

Robin

Sevens verder doen: eerst eten

Assigneer eens iets aan je input data, hang dat bv aan wat input pins. Zou wel eens kunnen dat ie de FF's daarachter wegoptimaliseerd. Dat is bij de altera toch zo.

@stecj366: Dat doet niks extra de proc word nog steeds weg geoptimaliseerd .

Robin
Edit een kleine aanpassing
http://robin.tussen.be/GPU16BIT.v

[Bericht gewijzigd door robint91 op zaterdag 2 februari 2008 10:12:43 (27%)]

Op zich geeft de hele lijst je precies aan wat er aan de hand is. Ik heb niet alles gechecked (da's me even teveel werk), maar ik zou zeggen, begin bovenaan en kijk of het terecht is dat ie het weghaald. Constante assignment naar 0 is een goede reden om de FF niet neer te leggen maar het signaal rechtstreeks aan 0 te leggen.
Wat er vaak gebeurt is dat je van de ene optimalisatie een andere krijgt, in het extreemste geval hou je niks over. Dat gebeurt bv als je geen van de outputs gebruikt. Dan kan ie net zo goed een lege FPGA synthetiseren.
Succes met debuggen.

PROBLEEM gevonden ik had een rotte memory gemaakt in verilog.
nu een memory gepakt van xilinx zelf en het bold half, er zit ergens een fout in hij stuurt geen data naar de output

Robin

EDIT

Hij draait :p:p
een simple tellertje, maar het volstaat:p

Hmm, die tweede zin is abacadabra voor mij. Maar het werkt dus. Op zich zou het niet uit moeten maken of je zelf een memory codeert, of dat je een xilinx module pakt. Dat's is geen reden om wel/niet weg te optimaliseren. Maar ROTTE momories werken inderdaad niet

Heeft iemand al eens met xilinx MIG gewerkt? Het is heel onduidelijk!

Robin