Page 1 of 2 1 2 LastLast
Results 1 to 15 of 20

Thread: Reacties op artikel '3D Graphics Met Delphi en OpenGL'

  1. #1

    Reacties op artikel '3D Graphics Met Delphi en OpenGL'

    Onlangs werd op NLDelphi een vraag over 3d programmeren gesteld. Daarop ontstond een leuke thread waarin mij gevraagd werd om een artikel te schrijven over de basis van 3d programmeren. Zie hier het resultaat. :-)

    Lees het artikel

    ...of reageer op dit artikel als reply op deze thread.
    Marcel

  2. #2

    Thumbs down

    Fout artikel! Het klinkt allemaal zo makkelijk dat ik meteen denk dat ik het ook kan

    Zonder gekheid; een goede inleiding in de 3D wereld. Ik heb de code nog niet uitgeprobeerd, maar ik ga er even vanuit dat dat werkt. Ik heb er eigenlijk ook niets op aan te merken, behalve dat ik denk dat dit nog niet of nauwelijks genoeg is om mee aan de slag te gaan.

    Dit is overigens zeker geen verwijt. Het is gewoon zoveel informatie dat dat onmogelijk in één artikel kon worden gevat. Heel veel voorbeelden beginnen met een hoop code zonder de achterliggende theorie uit te leggen, maar jij doet het net andersom. Puik! Ik hoop dat er meer volgt.
    1+1=b

  3. #3
    Nog eens het artikel doorgekeken en zitten peinzen. Ik ben een complete leek als het om 3D spul gaat, dus misschien praat ik wel onzin, maar ik vroeg me toch af:

    Was het niet zo dat een polygon het beste driehoekig kan zijn? Wanneer je namelijk 4 (of meer) hoeken hebt, dan loopt je de kans dat een hoek zich niet in het vlak zit. (Zeker als je een domme gebruiker (moi) in een niet al te beste (Unreal1) Editor bent. In dat geval krijg je dus eigenlijk een gebogen vlak en wordt het tekenwerk een puinhoop.

    Nu zou het wel weer zonde van het rekenwerk zijn om een vierkant in twee driehoeken te verdelen, of een vijfhoek in 3, maar als je je vertices toch in een aparte lijst hebt opgeslagen en dus maar één keer berekent, dan maakt het niet zoveel uit. Behalve natuurlijk als twee driehoeken tekenen meer tijd kost dan één vierkant, maar dat weet ik niet..
    1+1=b

  4. #4
    @GolezTrol:

    Het voordeel om driehoeken te gebruiken is het feit dat je zeker weet dat een driehoek 'convex' is.

    Convex wil zeggen dat wanneer je de punten van je polygon/driehoek op volgorde langsloopt dat de x en y verplaatsing afzonderlijk van elkaar maar twee keer van richting verandert.

    Een polygon kan namelijk ook 'complex' zijn. Als je een figuur binnen een vlak hebt en dit figuur is 'gedeukt'

    stel je voor dat je een vierkant (Convex) hebt en je verplaatst de linker boven hoek naar het midden van het vierkant en iets verder richting rechter onder hoek heb je een Complex polygon.

    De meeste hardware renderen met driehoeken of misschien beter de engelse term triangles. Polygons met meer dan 3 punten worden verdeeld in triangles voor dat de hardware mag gaan renderen. Dit process wordt dan Triangulation genoemd.

    Groet,
    Daniel

  5. #5
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Hoe je 't ook wendt of keert, met de huidige hardware kom je altijd uit bij triangles. Een aantal 3D API's (waarvan ik het van OpenGL zeker weet) heeft wel ondersteuning voor vierkanten e.d., maar of de software maakt hier 2 triangles van of de hardware doet 't. Wat wel leuk is is dat de nieuwere hardware ondersteuning heeft voor patches, waarbij je een figuur definieert aan de hand van een formule. Dit kon softwarematig natuurlijk al, maar je blijft overhead houden. De hardware kan dit nu zelf beter en het is bovendien nog makkelijker om het Level of Detail te bepalen zonder meerdere modellen te maken... maar voordat we te ver afwijken, waar 't om gaat is dat ook dit model uiteindelijk in triangles wordt gedefinieerd, om de simpele reden dat het renderen daarvan nu eenmaal de snelste methode is...
    Qui custodiet ipsos custodes

  6. #6
    Ik kan me voorstellen dat sommige berekingen voordeliger zijn voor een polygon (binnen een vlak dan wel) dan die berekening te doen voor elke triangle binnen die polygon zelf.

    Het controleren of een vlak visible is bijvoorbeeld. Dat hoef je dan alleen maar voor dat vlak te doen en niet meer voor elke triangle.

    Maar ik neem aan de OpenGL en DirectX dit wel effectief in de object -> rendering pipeline hebben zitten.

    Is overigens toch al een tijd geleden dat ik bezig ben geweest met 3D programming.

    Groet,
    Daniel

  7. #7
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Wat betreft de visible-check, de meeste triangles zijn onderdeel van een groter object, en elk object heeft een of meerdere bounding boxes (die je vantevoren makkelijk kan berekenen, of bij meerdere zelfs in het bestand kan definieren)... dat betekent dat je die hele groep triangles in een keer kan uitsluiten. Voor half-in-beeld objecten kan je dan weer een stapje verder gaan... een object bestaat meestal toch niet uit 1 grote polygon met heel veel triangles, dus je blijft veel controles houden...


    Het is voor mij overigens ook weer een tijdje geleden. Heb pas nog wat gedaan met OpenGL, maar niet echt ver mee gekomen. Wel vond ik gisteren een heel interessant document bij toeval, hij is te vinden op deze locatie...
    Qui custodiet ipsos custodes

  8. #8
    @ Goleztrol: Bedankt voor de complimenten. Inderdaad kan je over 3d zo ongelooflijk veel vertellen dat het onmogelijk is dat allemaal in 1 artikel te plaatsen. Zelfs als je slechts een inleiding wilt schrijven, moet je nog heel duidelijk je terrein gaan afbakenen. Ik heb ervoor gekozen om te laten zien hoe je een 3d object kunt definieren. Zelf ben ik overigens nog niet helemaal tevreden over het artikel. Ik zal het binnenkort refinen en plaatjes toevoegen om 1 en ander te verduidelijken. Een plaatje zegt soms meer dan een heel artikel.

    Nog even wat betreft convex: een driehoek is inderdaad altijd convex, kan niet anders. Ook heb je zogenaamde "concave" polygonen (soms ook wel complex genoemd, zoals Dunebuggy al zei). Stel dat je een rechte lijn wilt trekken binnen de grenzen van je polygoon, maar die lijn doorkruist dan twee of meer "edges" van die polygoon, dan is die polygoon concave. Bij een convex polygoon kan je een lijn trekken vanaf elk punt BINNEN die polygoon naar elk willekeurig ander punt binnen die polygoon zonder dat je edges doorkruist. Ik zou willen dat ik nu een plaatje toe kon voegen, dan was het gelijk duidelijk... :/

    Inderdaad is het ook zo dat triangles het snelst worden gerenderd. Dat heeft met name te maken met de texturing algorithms. Voor een driehoek hoef je simpelweg minder te berekenen. En dan praten we over berekeningen per pixel (!) dus dan weet je wel hoeveel snelheidwinst je kunt halen.

    Wat betreft bounding boxes: die zijn erg handig bij culling. Voor culling bestaan uiteraard ook weer verscheidene mogelijkheden. Afhankelijk van het soort 3d "engine" dat je wilt schrijven (indoor/outdoor/hybride) kies je een culling methode. Meestal kan je "frustrum culling" in zowel indoor als outdoor toepassen. Hierbij bepaal je een frustrum (gebied wat de camera "ziet") en alles wat daarbuiten valt, render je dus niet. Hierbij kan je zo'n bounding box erg goed gebruiken, zoals PsychoMark als zei. Je controleert dan alleen of die box (een simpele cube) zichtbaar is of niet (binnen het frustrum valt of niet). Kijken of een cube zichtbaar is of controleren of kijken of een heel ingewikkeld 3d object zichtbaar is... das nogal een verschil.

    Overigens is er trouwens een groot verschil tussen 3d engines en 3d editors te constateren. Bij een 3d engine render je een van tevoren gedefinieerde 3d wereld bestaande uit 3d objecten. Dat betekent dat je die 3d wereld van te voren al mooi kunt onderbrengen in een handig formaat (polygonen handig voorgesorteerd enzo) zodat je 3d engine razendsnel kan renderen. Bij een 3d editor kan dit niet, omdat je hier realtime allerlei bewerkingen doet op die 3d wereld die je aan het editen bent. Toch moet ook een 3d editor de 3d wereld snel kunnen renderen, omdat het anders toch al snel te traag wordt om nog lekker te kunnen editen. Das een probleem waar ik nu met DeleD tegenaan loop. Interessant probleem, dat zeker!

    Hoe dan ook, de topics die we hier in deze thread behandelen zijn stuk voor stuk ook al weer leuke onderwerpen voor afzonderlijke artikelen...
    Last edited by Jeroen; 13-Jul-03 at 14:28.
    If you can't solve the problem, it isn't a problem... - DeleD - 3D editor project - www.delgine.com

  9. #9
    Ik heb een nieuwe versie van het artikel gekregen van Jeroen. Deze staat inmiddels op de site.
    Marcel

  10. #10
    TCustomVader JosAikema's Avatar
    Join Date
    May 2002
    Location
    Harderwijk
    Posts
    1,491
    Wanneer ik dan nog een klein opmerkinkje mag maken. Je tekent je coordinaten stelsel x,y,x rechts naar achteren en je tekent je kubus recht naar achteren (als je begrijpt wat ik bedoel). Je kubus is niet volgens het zelfde co?Ârdinaten stelsel getekent als bovenin het artikel.
    Vanaf 1 oktober 2004 geen Delphi programmeur meer

  11. #11
    Ik begrijp niet helemaal wat je bedoelt. "x,y,x rechts naar achteren"? Waarschijnlijk een typo. Dat zou dan "x,y,z rechts naar achteren" zijn. Bedoel je dat ik in het plaatje het assenstelsel min of meer geroteerd heb? Dat klopt, omdat het lastig is om een 3d assenstelsel in 2d te tekenen. De Z-as loopt in ieder geval recht naar achteren, om het zo te zeggen. Volgens mij klopt de kubus definitie daarom wel.
    If you can't solve the problem, it isn't a problem... - DeleD - 3D editor project - www.delgine.com

  12. #12
    TCustomVader JosAikema's Avatar
    Join Date
    May 2002
    Location
    Harderwijk
    Posts
    1,491
    Wat ik bedoel is dat je in het stelsel de Z-as schuin (rechts) naar achteren terwijl bij de kubus de z-as recht naar achteren staat. Als je de kubus op de x,y,z assen aan het begin het het artikel projecteert krijg je geen kubus maar een raar figuur. De kubus zou volgens dat stelsel ook naar rechts moeten zijn georienteerd.
    Vanaf 1 oktober 2004 geen Delphi programmeur meer

  13. #13
    Ah zo! Ja, dat klopt helemaal. Eigelijk wilde ik de z-as in het stelsel ook recht naar achteren tekenen, maarja, doe dat maar es. Mischien dat ik de kubus ook nog es rechts orienteer, mits dat het plaatje duidelijk(er) maakt.
    If you can't solve the problem, it isn't a problem... - DeleD - 3D editor project - www.delgine.com

  14. #14
    Sommigen sites beweren dat je glEnd() moet gebruiken, en niet glEnd. Is dit waar?
    OpenGL moet de standaard worden! Niet DirectX aub!

  15. #15
    Senior Member PsychoMark's Avatar
    Join Date
    Nov 2001
    Location
    Raamsdonksveer
    Posts
    10,269
    Maakt helemaal niks uit, beiden zijn een aanroep naar een parameterloze functie...
    Qui custodiet ipsos custodes

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Replies: 28
    Last Post: 23-Feb-08, 12:19
  2. Replies: 67
    Last Post: 15-Jun-04, 12:32

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •