[Algoritme] isometrische belichting *

[killercow]

Oke ik ben al een tijd bezig met een isometrische webgame, maar nu wordt ik ondertussen helemaal gefrustreerd van het maken van tiles (die kleine plaatjes) deze hebben vaak een net iets andere vorm aangezien je hellingen kan hebben, ik kan ze natuurlijk allemaal aan gaan maken maar dat is stom.

ik heb hiervoor een functie geschreven, deze kan aan de hand van de hoogtes van de 4 hoekpunten de vorm van de tile uitrekenen. dit is dus mooi, nu kan hij hier ook de texture in plakken zodat er een mooie tile ontstaat.
Dit is natuurlijk allemaal aardig maar een isometrisch landschap krijgt pas diepte als er lichtere en donkere tiles zijn, aan de coorkant van een berg dus licht en dr achter donker.

Nu heb ik het fenomeen slag schaduw even daar gelaten en is de belichting dus alleen afhankelijk van de positie ten opzichte van de zon.

stel dat je een map hebt van 3x3
[ 0] [ 0] [ 0]
[ 0] [ 1] [ 0]
[ 0] [ 0] [ 0]
de hoogtes van de punten die naar de 1 wijzen maken we nu ook 1 zodat het landschap glooiend wordt.
hierdoor krijgen we echter tiles met in de tile zelf vershillende hoogten. links-boven/rechtsboven/linksonder/rechtsonder

ik moet nu eigenlijk weten hoe ik uit kan rekenen hoeveel ik een bepaalde tile moet verkleuren met een gamma functie om de schaduw erop te krijgen. ook vraag ik me af of de verkleuring een verband heeft met het hellingsgetal van de tile, dus als hij niet bijvoorbeeld 1 verschil heeft maar een verschil van 3 dat hij dan nog donkerder wordt.

oja ik ben er ondertussen uit dat sommige tiles geknikt zijn, ik ben dus aan het uitvinden hoe ik uireken of een tile geknikt is door te kijken of het hellings getal van de 2 zijdes vershilt.

Heeft iemand een idee hoe zoiets oplosbaar is?
hier nog even een pic van m'n projectje deze map is gerenderd uit een png plaatje.

[Verwijderd]

Lijkt verdacht veel op een spel dat Transport Tycoon heette

[killercow]

tjah idd ik heb de graphics files van hun gekraakt voor de eerst tiles

[Bergen]

De verkleuring is volgens mij hetzelfde als bij bumpmapping. Aan de hand van 3 cijfers bereken je de hoek en aan de hand van de invalshoek van de zon, de hellingshoek van het vlakje en de richtingshoek van het vlakje bereken je de kleur van het vlakje. Ik ga hier ff over nadenken...

Docjes:
http://thorkildsen.no/faqsys/docs/bumpmap2.txt
http://thorkildsen.no/faqsys/docs/bumpmap.txt

[Soultaker]

Als je ervan uitgaat dat de zon loodrecht op je landschap staat, kun je stellen dat de belichting uitsluitend bepaald wordt door de verhouding tussen het oppervlak van je vakje (1 voor 'platte' vakjes en iets meer voor schuine vakjes) en het oppervlak van het vakje wanneer het ('horizontaal') geprojecteerd op het vlak van je landschap, wat voor alle vakjes 1 is.

Je kunt dus volstaan met het uitrekenen van de oppervlakte van de tiles (of eigenlijk van elk van de twee driehoekjes, want zo kun je het beter zien). Daar is met behulp van goniometrie wel een mooie formule voor te verzinnen.

Er is waarschijnlijk een correlatie tussen dit oppervlak (wat dus bepaald hoe donker 't vakje is) en de hoek ten op zichte van de verticale as, maar dat is meer gevoelsmatig. Misschien dat iemand dit aan kan vullen?

Die screenshot ziet er trouwens ontzettend gaaf uit; hou ons op de hoogte!

[Bergen]

Zekers, als de zon loodrecht op het landschap staat is het een eitje, die berekening. Maar daar wordt het niet echt mooi van. Het is mooier als je zelf de positie van de zon kunt instellen. Als je het goed wilt doen bereken je voor elk vlakje de invalshoek met een matrixberekening.

[edit]Ik krijg ineens een ontzettende zin om ff een delphiprogje te bakken die ook zoiets maakt. Die matrixrommel heb ik namelijk wel maar ik moet 't ff aanpassen omdat ik bij m'n 3d dingetjes tot nu toe altijd licht van de voorkant gebruik... Laat ik daar maar eens verandering in scheppen.

[.oisyn]

het is in principe heel simpel, je berekent gewoon het dotproduct tussen 2 vectoren, namelijk de richting van de zon en de normaal van de tile (de normaal staat altijd loodrecht op het vlak)

is de uitkomst -1, dan is de belichting maximaal, en is ie 0 dan is er geen belichting (het licht komt dan precies van de zijkant). Bij waarden groter dan 0 schijnt de zon zeg maar tegen de achterkant van de tile aan

(dotproduct tussen 2 vectoren, a en b, is a_x * b_x + a_y * b_y + a_z * b_z)

[Bergen]

edit:
hier stond iets doms, ik was in de war

Kben ondertussen al druk met m'n baksel bezig..

[killercow]

cool, laat me even weten hoe en wat, ik ben nu bezig met een systeem wat water in de game kan krijgen door transparante gifjes op een beplaade hoogte te leggen. een layer naar beneden doe ik dat nog een keer zodat er lagunes kunnen ontstaan.

deze screenshots zijn dus gewoon de eerste paar tests, ben ook bezig met een systeem dat het toelaat om meerdere van deze maps via pijlen aan elkaar te linken zodat er een wereld kan onstaan waarin we honderden spelers kwijt kunnen.

ik snap zelf niet zo heel erg meer wat jullie nu precies aan het berekenen zijn maar laat me het even weten als jullie iets gevonden hebben ,

alvast heel erg bedankt voor de reacties.

[Bergen]

Ben net wakker geworden Kheb ff geslapen van 8:00 tot 14:00, anders haal ik het vannacht bij 't stappen niet meer Want zoals een beroemd man zei: "Real Programmers never work 9 to 5. If any real programmers are around at 9 AM, it's because they were up all night." Affijn. Back to work.

Wat kan m'n proggel al? Een landscape verzinnen, smoothen, scherm-coordinaten uitrekenen, normalen berekenen en daar unitvectors van maken.
Wat moet er nog gebeuren? Hij moet nog ff backface culling doen (man-o-man het wordt een halve 3d engine hoor), normalen draaien aan de hand van hoek van inval van de zon, kleuren daarmee berekenen en dan de zooi van achter naar voor tekenen. Kwas eigeluk nog niet van plan om te texturemappen. Ik zie wel...

[Verwijderd]

hmmkay, maar hoe berekenen we nu aan de hand van de 4 punten noord oost zuid west (met de klok me vanaf het bovenste puntje) de gamma correctie? want dat is volgens mij z'n vraag, iemand een idee? dus gewoon een stukje hapklare code? want ik snap er ook weinig van.

[Bergen]

Het heet in ieder geval geen gamma correctie. Dit heet gewoon shading. Ik was eigenlijk een stuk code aan het schrijven waarmee de lichtbron overal kunt neerzetten, dus ook in hoogte kunt verstellen. Dat is niet een stukje hapklare code... En het is ook best veel rekenwerk voor de pjoeter want hij moet voor elk vlakje bij elke verschuiving van de zon of beweging van het vlakje opnieuw de normaal berekenen en draaien tov de lichtbron.

Wat natuurlijk ook kan is de zon niet in hoogte verstelbaar maken maar dat ie gewoon om de map heen kan draaien. Scheelt een beetje in rekenwerk... Als de lichtstralen ook nog eens parallel op het landschap moeten vallen (wat oorspronkelijk ook de bedoeling was natuurlijk ) is er vast wel een brok hapklare code te maken. Maarja ik doe nou eenmaal altijd moeilijk

[Bergen]

Oh en uhm het zijn allemaal driehoekjes. Geen vierkantjes, dus je berekent alles aan de hand van 3 punten, niet 'noord oost zuid en west'. De meeste vlakjes lijken wel vierkant maar hier en daar zie je stiekem wel een driehoekje zitten wat verraadt dat het allemaaaal driehoekjes zijn. Met alleen vierkantjes kun je zoiets niet maken namelijk.

Gebruiken jullie trouwes allemaal kleine plaatjes of wordt alles realtime getexturemapped?

[Bergen]

Moet de zon eigeluk kunnen bewegen??

[killercow]

de zon blijft staan op een bepaalde plek.

de plaatjes worden van te voren allemaal gemaakt zodat de clients ze kunnen downloaden. het zijn idd allemaal driehoekjes 4 per tile om precies te zijn en ik zal je verklappen dat we gewoon plaatjes in layers op de juiste plek in de html planten tjah t werkt snel genoeg. en het is redelijk goed aanpasbaar.

van iedere tile weten we iig de 4 hoekpunten, deze zijn afhankelijk van de normale hoogte van de tile, wat ik nu wil kunnen is gewoon dit:

ik voer in: 1-1-0-2

deze levert een tile op waarvan de noordpunt(boven) en de oost punt(rechts) eentje hoger zijn.
de zuid punt(onder) zit op de basis hoogte, en de west punt zit op 2 hoger dan de normaal.

als je hier kijkt zie je de tile gegenereerd,

http://www.pc-gamers.com/webgame/tilegen/tilegen.php?north=1&east=1&south=0&west=2&gamma=1&source=grass

alles werkt behalve de verkleuring, ik snap dat de tile mischien in 4 driehoekjes moet worden gehakt en dat die allemaal een eigen verkleuring kunnen hebben, alleen hoe reken ik dat dan in gods naam uit?

[Bergen]

Elk vierkantje hoeft toch niet in 4 driehoekjes te worden gesplitst? 2 driehoekjes is genoeg hoor! Gewoon door de helft dus

Enneh ok, de zon moet van de voorkant er tegenaan schijnen dus? Ik krabbel ff op papier..

[thomaske]

Plaatje werkt niet..

source:

please specify a source tile
Warning: imagecreatefrompng: Unable to open '/home3/www/pc-gamers/webgame/tilegen/sourcetiles/.png' for reading in /home3/www/pc-gamers/webgame/tilegen/tilegen.php on line 7

Warning: Supplied argument is not a valid Image resource in /home3/www/pc-gamers/webgame/tilegen/tilegen.php on line 49

Warning: Cannot add header information - headers already sent by (output started at /home3/www/pc-gamers/webgame/tilegen/tilegen.php:3) in /home3/www/pc-gamers/webgame/tilegen/tilegen.php on line 52
PNG IHDR@(tnªPLTE§z=ÚtRNS@æØf IDATxc`ôh²çkIEND®B`

_{[edit] De &'s worden veranderd..
http://www.pc-gamers.com/webgame/tilegen/tilegen.php?north=1&east=1&south=0&west=2&gamma=1&source=grass}

[killercow]

http://www.pc-gamers.com/webgame/tilegen/tilegen.php?north=1&east=1&south=0&west=2&gamma=1&source=grass

tjah hij verandert & im &

[killercow]

Op zaterdag 23 maart 2002 16:47 schreef GerbenW het volgende:
Elk vierkantje hoeft toch niet in 4 driehoekjes te worden gesplitst? 2 driehoekjes is genoeg hoor! Gewoon door de helft dus

Enneh ok, de zon moet van de voorkant er tegenaan schijnen dus? Ik krabbel ff op papier..

klopt alleen dan moet je wel uitvinden welke 2 driehoekjes want je hebt dan 2 vershillende versies van de gehakte tile, eentje met de driehokjes boven elkaar en eentje met de driehoekjes onderelkaar.

[Soultaker]

De 'driehoekjes' die GerbenW bedoelt, zijn er slechts twee (in jou voorbeeld de bovenste en onderste helft). Van elk driehoekje kun je de normaalvector berekenen (de vector die loodrect op de oppervlakte staat) en die vergelijken met de normaalvector van de zon (in jou geval waarschijnlijk er recht boven). Die kun je vervolgens vergelijken op de al eerder besproken manier (inprodukt nemen, etc.), alleen ben ik er nog niet van overtuigd dat de zo gevonden waarden direct corresponderen met de hoeveelheid licht (hoewel de kans groot is dat het zo is). In elk geval zal het niemand opvallen als 't NET niet klopt.

[killercow]

okey, ik ben dom, ik snap t nie

de hoeveelheid licht is iid niet echt heel belangrijk alleen er moet ook rekening gehouden worden met tiles die de knik van boven naar beneden hebben lopen, ik kom er gewoon niet uit, mischien is de uitleg boven te moeilijk voor mij omdat ik nog nooit een 3d engine met een matrix systeem heb gebouwd.

ik zal even kijken of ik een kleine demo kan maken van een groepje tiles, ik beperk met tot hoogte 1 maar het script kan natuurlijk ook andere hoogtes aan.

de zon staat in mijn geval in de rechter onderhoek van het scherm, hierdoor krijg je dus een groep tile (voorkant van de berg en rechterkant) die meer belicht worden, een groep die gewoon belicht wordt, de top van de berg, en een groep die minder belicht wordt. de achterkant.

[SJR]

Euhmm.. pardon me hoor, maar zou je zoiets niet beter in Java kunnen schrijven, dat is toch een veel krachtigere taal dan php. Zeker van belang als het echt een mp game wordt, en je de serverload wat wilt beperken. Maargoed, ik weet natuurlijk ook niet hoe je alles hebt geprogged.
Ziet er allemaal wel gaaf uit hoor, daar niet van.

[killercow]

tis de bedoeling dat de server op basis van mysql gewoon arrays met data uitpoept, deze worden dan op dit moment door javascript omgebouwd tot html maar hij moet ook een flash client kunnen gaan voeren.

we zijn ook al bezig met een java cient en een client die via mm director verschillende 3d technieken toepast deze is dus ontzettend snel en aangezien php alleen maar de mutaties naar de client hoeft te sturen is alles ontzettend snel. zelfs als alles met dhtml wordt opgebouwd.

hier is een demo te vinden, is ongeveer 110 k denk ik
gzip staat nu nog uit. www.pc-gamers.com/webgame/iso-js.php

[Bergen]

Ik heb ff een progje geupload waar ik laatst mee bezig was maar wat ik nooit heb afgemaakt. Als je hem downt en start kun je hem met de muis draaien en met de rechtermuisknop wisselen tussen vertex- en wireframemodus. Die rommel eronder werkt niet btw. Oh ennuhm... resize het venster maar niet Dat runtime bitmap-resizen heb ik ook nooit afgemaakt namelijk en dan krijg je vage effecten

Maar nou kun je iig ff zien wat ik met die driehoekjes bedoel:
http://www.gerbs.net/wapper.zip

[Verwijderd]

Leuk idee:

Ik neem aan dat het landschap een rechthoekige map is. Er ontstaat dan ook een raster van vertexes. Als je nou voor iedere vertex in het begin een normaal vector bepaalt. (Deze is afhankelijk van zijn omliggende triangles.

Je kunt dat voor iedere vertex een lichttint berekenen. Verder kun je dan de lichttinten van iedere pixel uit iedere triangle baricentrich interpoleren.

Resultaat: een mooi smooth landschap

barycentrische interpolatie:

(http://www.cut-the-knot.com/triangle/barycenter.html of zoek betere site met google)



t0,t1,t2 zijn punten van een driehoek(tinten)
t is de uiteindelijke tint voor een bepaald punt op een driehoek u, v zijn barycentrische coordinaten

t1 - t0 is de v as
t2 - t0 is de u as
t = t1 * v + t2 * u + (1 - u - v) * t0

[killercow]

tjah t werkt goed en snel (99fps) alleen wat kan ik precies mee?

zoals je hier kunt zien zijn er 2 vershillende soorten breuken. eentje met de breuk horizontaal en eentje verticaal. dat komt natuurlijk omdat de tiles verschillende kanten "opkijken" en omdat de tiles bijvoorbeeld verschillende hellingsgetallen hebben.

[Bergen]

Op zaterdag 23 maart 2002 17:36 schreef TimD het volgende:
Leuk idee:

Ik neem aan dat het landschap een rechthoekige map is. Er ontstaat dan ook een raster van vertexes. Als je nou voor iedere vertex in het begin een normaal vector bepaalt. (Deze is afhankelijk van zijn omliggende triangles.

omliggende vertices bedoel je.. de normaal is gewoon:
voor polygoon 1:

code:

fNx := fA.fHeight-fB.fHeight;
fNy := fA.fHeight-fC.fHeight;
fNz := 1;

en voor polygoon 2:

code:

fNx := fC.fHeight - fB.fHeight;
fNy := fA.fHeight - fB.fHeight;
fNz := 1;

fA, fB en fC zijn pointers naar de vertices, uiteraard met de klok mee, van bovenaf gezien.

Je kunt dat voor iedere vertex een lichttint berekenen. Verder kun je dan de lichttinten van iedere pixel uit iedere triangle baricentrich interpoleren.

Resultaat: een mooi smooth landschap

Ja, mooi gezegd Maar dat gaat hier niet op... Hij maakt een landschap zoals in SimCity enzo, dus maken we gebruik van flatshading want die plaatjes zijn standaardplaatjes en worden niet runtime getekend.

[Bergen]

Op zaterdag 23 maart 2002 17:41 schreef killercow het volgende:
tjah t werkt goed en snel (99fps) alleen wat kan ik precies mee?

zoals je hier kunt zien zijn er 2 vershillende soorten breuken. eentje met de breuk horizontaal en eentje verticaal. dat komt natuurlijk omdat de tiles verschillende kanten "opkijken" en omdat de tiles bijvoorbeeld verschillende hellingsgetallen hebben.
[afbeelding]

Dat wordt lastig. Kun je de driehoeken niet allemaal horizontaal maken? Of allemaal vertikaal, wat jij wilt...

[killercow]

nee niet echt, dan ben je namenlijk heel erg beperkt in het aanmaken van je maps, ik genereer me maps uit een grayscale png plaatje zodat ik ze lekker uit de clouds functie van photoshop kan trekken daarna normalize ik dus de hoekjes zodat ze aansluiten aan hun parent tile, dit is voor ieder hoekpunt dus een andere tile. maar een knik zou betekenen dat je bovenstaande situatie nooit kan maken maar je kan dan ook niet een kleine bult maken in je landschap aangezien je dan ook 4 hoekputen hebt waarvan er 2 vertcaal geknikt zijn en 2 horizontaal.
vandaar mijn idee om mischien het centrum uit te rekenen en dan dan per hoekpunt het hellingsgetal daarheen te berekenen. hiervoor heb je dus 4 driehoekjes nodig, deze krijgen dan soms de zelfde kleur maar t maakt het mischien makkelijker.

iig bedankt voor jullie reacties, maar uhm KEEP em comming

als jullie de bron willen zien van de tile generator moeten jullie t maar ff zeggen.

[Bergen]

Effe wat in paint shop pro gekloot... Als ik het goed begrijp is de situatie dus zo:

Bovenste: mijn idee, alle driehoekjes dezelfde kant op
Middelste: hoe het nu is, afhankelijk van uhm.. iets
Onderste: hoe je het misschien gaat doen?

[killercow]

tjah ik gebruik de middelste manier alleen dan zijn dat bij mij dus 4 tiles.

ik wilde het zo op gaan lossen:
ik deel de tile op in 4 driehoekjes, de tile vorm blijft dus nog steeds het zelfde, maar ik kan dan de 4 afzonderlijke delen los van elkaar belichten zodat ik alle mogenlijke knikken automatisch krijg.

andere manieren hebben volgens mij te veel verschillende vlakken om snel te berekenen, terwijl het niet eens zo'n enorm voordeel oplevert kwa "golvendheid" van het landschap.

ik had dus eerst het idee om het toch maar met ifjes te gaan doen, kijken welke 2 punten het hoogste zijn en dan kijken in welke categorie de tile valt alleen is dit natuurlijk niet te doen als je tiles wilt kunnen belichten die bijvoorbeeld deze samenstelling hebben 45-23-23-0
dit zou dan bijvoorbeeld een hele stijle wand voorstellen.

iemand een idee?

[brammetje]

Hmmz.. zoals Oisyn het voorstelt lijkt het mij niet heel moeilijk meer, moet je misschien wel je tile in 4 driehoekjes verdelen...

edit: wel een vet idee btw.

[killercow]

nu ik nog eens naar jouw voorbeelden kijk zie ik dat het wel zou kunnen als het onderste voorbeeld uit 4 tiles bestaat waarvan ik ieder 4 driehoekjes bereken, alleen heb jij de breuken wat krom getekend wat ik waarschijnlijk niet ga doen.

en btw dank je voor de hulp

[killercow]

iemand nog ideen? want ik zit vast

er is dus niet iemand die ooit al eens een algoritme heeft gebouwd? coz * killercow neeeeds it

[Soultaker]

Het makkelijkste lijkt me nog steeds om elke (in essentie) vierkante tile op te delen in twee driehoeken, door over een diagonaal te splitsen. Dat kan maar op twee manieren, waarvan de verdeling die in het isometrische perspectief de vlakjes in een linker- en een rechterhelft opdeelt waarschijnlijk het mooiste is. Het voordeel hiervan is dat je van de 'knikken' af bent, het texture-mappen niet zoveel moeilijker wordt en het berekenen van de shading kan gebeuren op de al eerder genoemde manier.

Het vervelende met het knikken van tiles, wat jij wil doen, is dat het in principe alleen kan als minstens twee van de vier vertices dezelfde hoogte hebben. Anders krijg je alsnog 'schuine' driehoekjes.

[killercow]

okay ... en hoe zou ik dat in mijn engine kunnen bouwen?
ik weet per tile namenlijk de hoogtes van de 4 hoekpunten ten opzichte van de hoogte het centrum van de tile, naja de normale tile hoogte zeg maar.

ik snap dr namenlijk geen aars meer van

[Soultaker]

Ik ga liever geen geheel uitgewerkt script maken, maar ik kan je wel op weg helpen. Elk vakje (set van vier punten) deel je op in twee setjes van 3 punten. Welke 3 punten je neemt, maakt niet uit, als de punten die je weglaat maar tegenover elkaar liggen. Als je bijvoorbeeld de punten als volgt nummert:

code:

   1
 /   \
4     2
 \   /
   3

Zou je {1,2,3} en {1,3,4} kunnen pakken. Op basis van de feitelijke positie (x,y,z dus) kun je de shading berekenen; dat is al eerder uitgelegd. Die weet je nu dus.

Ik neem aan dat je van elk punt, gegeven de coordinaten, de positie op het scherm kan berekenen (dat schijnt nu al goed te gaan namelijk en anders kom je er zelf vast wel uit, teken het bijvoorbeeld even uit op een kladblaadje). Tussen deze drie punten kun je een driehoekje tekenen met de berekende shading.

Het texture mappen is nu nog wat lastig, zeker als 't correct moet; ik zou zeggen, probeer het eerst eens met uitsluitend shading, dat zou ook al een goed effect moeten geven. Algoritmes voor texture mapping van de driehoekjes zijn wel te vinden via Google.

Je creeert hier wel ontzettend veel verschillende driehoekjes mee trouwens, waardoor het misschien handiger is om het speelveld in een image te tekenen met Boutell's GD-library in plaats van afzonderlijke driehoekjes door te sturen naar de client. De huidige methode werkt toch al ranzig traag.

Als dit niet genoeg uitleg voor je is, lijkt het me beter dat je het project helemaal opgeeft, want dan wordt het veel te ingewikkeld voor je. Succes ermee!

[Bergen]

* Bergen is ook weer in the house...
Terug van een zwaar weekend stappen Morgen kijk ik weer ff wat ik kan doen.

[Sponge]

Heb je hier wat aan?

http://www.lighthouse3d.com/opengl/terrain/index.php3?normals

[killercow]

woei er begint met iets te dagen,
als je een driehoekje hebt dan heb je natuurlijk een vector die er in het midden haaks op staat, weizig je de hoogte van een van de hoekpunten dan verandert de richting van de verctor, als ik dus voor alle 4 de driehoekjes de vectoe uit kan rekeken dan kan ik die middels een tabel vergelijken met de vector van de zon right? of ik bouw gewoon een tabel met mogenlijke waardes en haal desnoods gemiddeldes daaruit om de gamma correctie te berekeken (php kan alleen gamma correcties )

oke dus dat is mooi, ik geloof dat jullie me dat ook uit wilden leggen right? tjah

alleen nu moet ik natuurlijk driehoekjes maken in de tile, hiervoor heb ik het middelpunt nodig in de tile, als de tile 2-1-0-1 is is dat natuurlijk ook 1 (gemiddelde van 0 en 2, en van 1 en 1) maar uhm watnu als ik een tile heb zoals dit: 1-0-0-0 dan heb ik dus een knik, het middelpunt moet uiteraard 0 zijn aangezien ik anders de 2 onderste driehoekjes moet verbuigen en dat niet mooi is als je een helling hebt etc. hoe kom ik achter het centerpoint? ik heb alleen een miljoen schetjes gemaakt van tiles maar ik zie de logica niet helemaal, al ben ik wel weer wat stappen verder thanx too you guys.

[Grum]

het driehoekje is een vlak

en elke lijn die loodrecht op tenminste 2 lijnen in het vlak staat is evenwijdig aan de normaal van het vlak

dus je hebt het middelpunt niet nodig ...

alleen 2 vectoren ... nu zijn die niet zo lastig .. gewoon 2 vd 3 zijdes in et vlak

die vectoren kan je btw van te voren uitrekenen

der zijn maar een paar mogelijkheden voor dit soort tiles:

code:

Dit is natuurlijk alle kanten op te roteren :)

   a
 /   \
d     b
 \   /
   c

niet geknakt :
a b c d
0 0 0 0 - horizontaal
1 1 0 0 - 1 kant schuin
2 1 0 1 - 2 kanten schuin

geknakt:
a b c d
1 0 0 0 - 1 puntje omhoog
1 0 1 0 - 2 puntjes omhoog
1 1 1 0 - 1 puntje naar beneden

dit waren ze volgens mij wel

[Soultaker]

Rest het probleem wat je nou precies doet als alle vier de vertices een verschillende hoogte hebben. Dan valt er in principe weinig te knakken. Het lijkt me moeilijk te garanderen dat die situatie zich niet voordoet.

Spelletjes met zo'n engine als jij wilt maken maakten geloof ik verticale wandjes als ze in die situatie kwamen. Dan namen ze gewoon de laagste vertex en maakte de hoogte daarvan gelijk aan de op-een-na laagste vertex. Voordeel is dat alles er nog steeds goed uitziet, maar je moet dan wel ook de verticale wandjes tekenen. Een makkelijke manier om dit te doen is de achtergrond vantevoren (of de ongebruikte ruimte achteraf, dat komt op hetzelfde neer) te vullen met de achtergrond kleur/texture.

[Pooh]

Op maandag 25 maart 2002 20:30 schreef Soultaker het volgende:
Rest het probleem wat je nou precies doet als alle vier de vertices een verschillende hoogte hebben. Dan valt er in principe weinig te knakken. Het lijkt me moeilijk te garanderen dat die situatie zich niet voordoet.

Spelletjes met zo'n engine als jij wilt maken maakten geloof ik verticale wandjes als ze in die situatie kwamen. ...

Hmmm... Zijn tiles komen rechtstreeks uit transport-tycoon, die, net als simcity geloof ik, niet meer dan een hoogteverschil van 1 toeliet over 1 tile, (dus nooit hoeken van meer dan 45 graden). Dan kan die situatie zich dus nooit voordoen.

[killercow]

jah maarjah, ik had die tiles alleen even gebruikt om te kijken of alles werkte, nu is het dus wel de bedoeling dat mijn tiles tot een redelijk hoogte verschil kunnen scalen, bijvoorbeeld grote schuine wanden van bergen.
en tjah dan moet je denk ik toch knakken en breken per tile