Archief - [ART][Modula] 3D engine from scratch

Hallo allemaal, Ik ben sinds een dikke week geleden in de ban van het programmeren van een 3d engine volledig van 0 opgebouwd. Het was eerst bedoeld als anti vervelingsmiddel voor de laatste 14 dagen vakantie maar ik ben er steeds verder mee bezig geweest en nu zit ik toch al met een behoorlijk resultaat
Aangezien ik er nu echt mee moet stoppen had ik graag geweten of er misschien iemand van jullie al is hetzelfde geprobeerd heeft en hoever je geraakt bent...
ziehier mijn gepruts:
-http://users.pandora.be/wtcb/drieDengine.exe

-http://users.pandora.be/wtcb/hyper3Dengine.exe

de laatste was een poging tot het namaken van quake 3's engine
bedienen doe je met de muis en de pijltjes (niet letten op dat klein windows venstertje dat mee openspringt)
kheb de sourse code er ook opgezet (in modula) dus feel free voor commentaar!

asge vs gebruikt onder windows -> ergens in uw linker opties subsystem op windows zetten ipv console, dat doet het console venster weg.

Dat flikkeren bij beweging is niet echt goed , je werkt toch double buffered mag ik hopen ?

Flikkeren is idd storend; kire zn diagnose zal er wschl niet ver naast zitten. Verder zie ik in je quake demo vaak maar 1 of 2 lijnen van het huis wanneer ze allemaal zichtbaar zouden moeten zijn. Ook is je viewport clipping algoritme te scherp, je clipt ook polygons die de viewport snijden (kijk naar het grid als je aan t draaien bent, je ziet de randen weggeknipt worden); als een polygon de rand van de viewport snijdt moet je m ofwel subdividen op de rand en slechts 1 helft tonen, maar best is m eenvoudigweg volledig te renderen, pas als ie volledig buiten de viewport valt mag je m clippen. ( ik betwijfel dat t echt polygons zijn, wschl teken je gewoon lijntjes, maar hetzelfde geldt daarvoor )

k Geef gewoon wat constructieve kritiek hoor, k denk dat het een leuke & leerrijke ervaring voor u is

KeaTs zei:

Flikkeren is idd storend; kire zn diagnose zal er wschl niet ver naast zitten. Verder zie ik in je quake demo vaak maar 1 of 2 lijnen van het huis wanneer ze allemaal zichtbaar zouden moeten zijn. Ook is je viewport clipping algoritme te scherp, je clipt ook polygons die de viewport snijden (kijk naar het grid als je aan t draaien bent, je ziet de randen weggeknipt worden); als een polygon de rand van de viewport snijdt moet je m ofwel subdividen op de rand en slechts 1 helft tonen, maar best is m eenvoudigweg volledig te renderen, pas als ie volledig buiten de viewport valt mag je m clippen. ( ik betwijfel dat t echt polygons zijn, wschl teken je gewoon lijntjes, maar hetzelfde geldt daarvoor )

k Geef gewoon wat constructieve kritiek hoor, k denk dat het een leuke & leerrijke ervaring voor u is

Klik om te vergroten...

clippen had ik idd niet gemerkt, ma is wel juist.

Ik ga ook akkoord met keats van: renderen, niet subdividen, dat laatste kan immers nogal zwaar tegenvallen (in cpu-use) als je veel polygonen hebt.

ma voor de rest ziet het er nice uit (voor de tijd dat je ermee bezig bent)

Ge zegt dat ge 3Dengine van 0 maakt, dus ik veronderstel dat ge zelf ook uw teken-algoritmes en de volledige pipeline hebt geschreven (ni openGL ofzo).. dus.. mijn (niet belangrijke) mening:

Persoonlijk zou ik eerder voor het subdividen gaan (vooral omdat ik het een properdere oplossing vind).

Eenmaal je alle driehoeken (of andere primitieven) gesubdivided hebt, zit je met een hoop driehoeken die allen binnen uw frustrum vallen (en dus potentieel op uw scherm zichtbaar kunnen zijn). Bij alle volgende stappen in uw pipeline (z-buffering, blabla...) moet je er dan niet meer op letten het algoritme alleen toe te passen voor de driehoeken die in uw frustrum vallen (makkelijkere & properdere code + daar win je dan iets van snelheid).

Het is ook niet dat het softwarematig rasterizeren totaal geen cpu-kost heeft, dus de tijd die ge gebruikt om primitieven de subdivided spaart ge ergens anders in uw pipeline wel uit.

Uiteindelijk zult ge toch, voor elke driehoek die deels uit uw frustrum ligt, de kleur en evt texture-coordinaten moeten bepalen voor (oa) de randpunten, dus deze berekening gebeurt toch al (zij het later in uw pipeline), dus kan je deze evengoed voorberekenen bij het clippen.

Kortom, ik denk dat het een logischere, properdere (subjectief!) en gemakkelijkere (voor uzelf als prorgammeur) keuze is, die echt niet trager hoeft te zijn (integendeel zelfs).

Ik dacht trouwens (not 100% sure) dat openGL ook subdivisioning gebruikt van primitieven die deels buiten het frustrum liggen (als side-note )

Succes ermee nog, hoop dat ge binnekort nog wat work-in-progress kunt laten zien

ik denk wel degelijk dat het een engine mbv opengl of zo is ze, dat op 2 weken lijkt me nogal straf .

Ik kan het venster niet afsluiten met de escape-toets, alt-f4 of het kruisje rechts-bovenaan. Het lukt me enkel als ik het consolevenster afsluit.

wls zei:

Ge zegt dat ge 3Dengine van 0 maakt, dus ik veronderstel dat ge zelf ook uw teken-algoritmes en de volledige pipeline hebt geschreven (ni openGL ofzo).. dus.. mijn (niet belangrijke) mening:

Klik om te vergroten...

Ik denk dat je het begrip 3D engine met het begrip rasterizer verward:
Waar jij het over hebt is een software rasterizer ipv de gebruikelijke hardware rasterizer. De rasterizer is slechts een onderdeel van de grafische engine en als die engine goed geschreven is dan kan je ipc makkelijk nieuwe rasterizers toevoegen.

Een grafische(2D of 3D) engine omvat veel meer dan die rasterizer:
- asset management(textures, shaders, meshes, animations, ...)
- animation blending
- scene management(octree, bsp, frustum culling ...)
- render mode management
- etc.
(ze hoeven niet allemaal aanwezig te zijn natuurlijk)

Ik had het eigenlijk over een rasterizatie-engine (in tegenstelling tot raytracing-technieken bv) eerder als algemene techniek ipv het rasterizatie-algoritme zelf (welke allebij onderdeel zijn van nen 3D engine enzo maar blablabla da weten we allebij wel)

Ik dacht eigenlijk dat hij gewoon een rasterizatie + clipping algoritme had geimplementeerd (softwarematig) en dan wat had getest met het uittekenen van lijnen of dit goed werkte. Het leek me raar om clipping problemen met het uittekenen van lijnen te hebben in OpenGL omdat die zelf al aan clipping doet (standaard).

Trouwens (as a side note voor beginnende programmeurs), een engine volledig softwarematig maken (zonder openGL dus) lijkt me veel leerrijker dan dmv openGL, je snapt de basis + het is nog een goede oefening voor wat programmeer-skills te kweken. Zijn genoeg tutorials te vinden die het idiot-proof uitleggen (als ik het zelfs al kan )

Der is idd nog wat werk aan voor ik het nen echten engine kan noemen I know, ma tis mijn bedoeling om echt volledig van scratch te beginne om te zien hoe dat de very basics ineen zitten, dus wat OpenGl eigelijk doet. Maar kzal eerst nog wat terminologie moeten bekijken voor ik verder kan gaan want kweet nog niet eens wat rasterizer of subdiven betekenen .
Dat flikkeren kan ik niks aan doen das omdat ge bij modula telkens clearscreen moet doen om het scherm te wissen.
Voor dat clipping probleem, kweet nie goe hoe ge het best een lijn tussen 2 punten in 3D weergeeft op het scherm. Ik trek nu gewoon een lijn tussen de projecties van die punten..
Daarna zal ik me polygonen kunnen beginnen

wls zei:

Trouwens (as a side note voor beginnende programmeurs), een engine volledig softwarematig maken (zonder openGL dus) lijkt me veel leerrijker dan dmv openGL, je snapt de basis + het is nog een goede oefening voor wat programmeer-skills te kweken. Zijn genoeg tutorials te vinden die het idiot-proof uitleggen (als ik het zelfs al kan )

Klik om te vergroten...

Naar mijn mening is programmeren veel meer dan weten hoe een 3D API in elkaar zit. En dat is dan ook vaak het probleem van tech coders: die kunnen héél goed hun ding(rasterizers, tools, etc.) maar die zijn vaak slecht in object-geöriënteerd programmeren.
Maar begrijp me niet verkeerd! Een simpele software-matige 3D engine maken vind ik best interessant om meer van graphics programming te begrijpen Want je komt daardoor ook ineens in aanraking met zowat alle 3D-gerelateerde transformaties in de wiskunde(matrices, quaternions, etc.).

tja

je kan ook gewoon een boek over meetkunde gaan lezen eh .

Ik bedoelde het ook effectief als een oefening op graphics & programmeer-skills & (als ge het deftg doet) wat OO programmeren. Mensen die een stuk 3d engine (bv rasterizatie) schrijven zonder iets van de rest af te weten lijken me vrij zeldzaam tbh, want hun code kunde toch elk project hergebruiken.

Ik denk persoonlijk nog altijd (en uit ervaring) dat een (simpele) 3D (rasterizatie) engine nog steeds een heel nuttige programeer oefening is, zowel op vlak van OO (als ge een OO engine wilt maken) als op vlak van snelheid (wat belangrijk is) en op vlak van algemeenheid (beetje nadenken hoe ge alles wilt organizeren en uitbreiden op lange termijn). Ik heb in ieder geval toch veel geleerd van mijn eerste raytracer ivm 3D engines.

Greetz