Mijn methode werkte door de wereld op te delen in meerdere kubussen, voor elke 'kamer' eentje. Net zoals je lijn op kunt delen in 2 lijnstukken, een velletje papier op kunt delen in 4 kwadranten kun je een kubus opdelen in 8 'octanten'. Vervolgens deel je die octanten ook weer op, en die ook weer, totdat de hoeveelheid detail in 1 octant te behappen valt.
Zit je nog met het probleem dat als je in 'de wereld' een bepaalde kant op kijkt, dat een groot deel van die wereld niet zichtbaar is omdat er een muur of boom in de weg staat. Dat lostte ik met 2 methodes op: een stukje software dat driehoekjes zwartwit in een stukje geheugen tekende, met in elke octreenode een versimpelde weergave van het detail werkelijkheid. Dat levert een plaatje op, en overal waar het beeld 'zwart' is zijn de achterliggende octanten niet zichtbaar, en hoef je die dus ook niet te verwerken. Met een duur woord: een 'occlusion map'. Voor lampen precies hetzelfde: doe dat truukje gezien vanuit de lamp, en je hebt een mooi plaatje dat je als een dia over de wereld kunt projecteren, voila, schaduw. Dat proces liep parallel met wat de grafische kaart aan het doen was.
Laatste probleem is geheugen en processorsnelheid. Zoeken in een octree is een binair proces en kan vreselijk snel, maar je moet er honderden tot duizenden keren per beeld doorheen en dat vele beelden per seconde. Verder is een hele wereld nogal groot en je wilt de benodigde delen pas van disk af laden als ze nodig zijn. Dat deed ik met 'portals': gewoon een duur woord voor venster. Aansluitend aan kamer A zit kamer B, en daartussen zit een venster of deur. Als het venster zichtbaar is ga je eens kijken wat er allemaal in kamer B zit, is het venster niet zichtbaar of het deurtje dicht, dan hoef je heel kamer B niet te verwerken. En zo kun je ook spiegels maken; door de portal zie je dan weer gewoon kamer A, maar dan vanaf de andere kant.
Allemaal nog relatief te behappen; het word pas echt leuk als er veel bewegende dingen zijn. Een ophaalbrug die omhoog gaat komt al gauw in andere octanten terecht, maar wanneer wint dat administreren het nou van maar gewoon domweg tekenen?
[edit]
't is bij jullie altijd 'pics or it did not happen'. De executable van het engine zelf draait niet meer op modern windows 7 64-bit, de radiosity preprocessor/scenebuilder nog wel grotendeels.
plaatje 1
plaatje 2
Octree is goed te zien, portaal naar verre werelden ook alleen is die wereld zwart
[/edit]
Geweldig leuk spul allemaal. Veel denkwerk, weinig regels code, maar wel tot op het bot uitgeknepen code. 't is niet voor niets dat ik na de HTS ben gaan werken voor een bedrijf dat grafische processoren maakte (en daar eigenlijk nog werk, al heet het bedrijf anders en is de ASIC-tak allang failliet). Dit soort dingen, realtime raytracers, volumerenderers, zaken als CFD/FEM, etc. zijn gewoon Ernstig Affentittengeil Spul. Userinterfaces, SQL databases en visual basic prut enzo maak je me dan weer absoluut niet blij mee.
Dan snap je nu ook waarom ik ooit riep dat ik een 2D HSM CAM kern onder een setje subroutines voor zo'n shopfloorprogrammeergeval wel zag zitten. Intersectie van zo'n frees met een 2,5D/3D model van je werkstuk is een probleem waar ik wel eerder wat mee te maken gehad heb. Of de STL-mesh ter correctie van mijn freesmachine; dat is recyclen van kennis die ik ooit had ('t is wel wat stoffig geworden).
Voor de topicstarter: het proces waar je nu doorheen gaat heb ik ook al eens ooit gehad, en ik kan het punt waarop je vast gaat lopen al bijna voelen. Ik raad je toch aan om over te stappen op een 3D 'wereld' zonder truukjes, want vroeg of laat loop je tegen 'kan robotarm X doosje Y oppakken?' aan of 'we hebben een nieuw model doosjes, en die zijn niet rechthoekig'. En ook omdat het hele gedoe dan opeens heel 'clean' en rechttoe-rechtaan word in plaats van een brei met truukje hier - plakband daar.
Dat klinkt allemaal ingewikkeld, maar dat is het niet, zeker niet in gebruik. als je zover gekomen bent als nu kun je je niet meer achter 'ik ben maar LTS' verschuilen
Alles wat je met je 3D punt wil doen kun je in een 4x4 matrix kwijt. Roteren, schalen, verplaatsen, projecteren, bla. (niet helemaal waar, maar voor nu dicht genoeg bij de waarheid)
Het leuke is dat bewerkingen na elkaar zo simpel zijn als die 4x4 matrices met elkaar vermenigvuldigen. In nep-code:
Model doosje = Maak1x1x1doosje();
Matrix schaal_doosje = SchaalMatrix(10,10,20); // dit doosje is 10x10x20
Matrix roteer_doosje = RotatieMatrix(45,45,45); // doosje staat op z'n punt. Ja, heel raar.
Matrix verplaats_doosje = VerplaatsMatrix (100,100,0); // doosje staat op locatie 100x100, eerste laag.
Matrix camera = CameraMatrix (0,0,-100); // we kijken vanaf XY=(0,0) en 100 stappen terug naar de pallet
Matrix uiteindelijk = schaal_doosje * roteer_doosje * verplaats_doosje * camera;
Model uiteindelijk_doosje = doosje * uiteindelijk;
for i in uiteindelijk_doosje.coordinaten
teken_vlakje (uiteindelijk_doosje.coordinaten)
end_for
Zie je hoe schoon en rechtlijnig de code word? En hoe makkelijk het is om de pallet van een andere kant te bekijken (andere camera-matrix aanmaken)? Er missen nog wat details; de vlakjes moet je bijvoorbeeld nog sorteren van ver weg naar dichtbij (painters algorithme; een schilder schildert ook eerst de achtergrond en de voorgrond daar overheen). Mijn gerebbel hierboven word pas interessant als je alle doosjes van een heel logistiek centrum wil gaan tekenen; jij komt weg met simpelweg sorteren van achter naar voor.
(wat diepchess overigens ook zei..)
Hier vind je nog wat informatie: http://www.opengl-tutorial.org/beginner ... n_matrices
Zoals je ziet is het invullen van die matrices een kwestie van de nummertjes op de goede plek zetten, en twee matrices of een coordinaat en matrix met elkaar vermenigvuldigen is ook geen ingewikkeld iets. Hoef je ook niet zelf te verzinnen; die code is makkelijk te googelen.
