Hello!
Tarkoitus yhä tässä kehittää tätä Java Graphics2D:n avulla rakentuvaa 3D pelimoottoriani ( Esim. Shakkilauta ) -> http://88.192.212.114
En ole täysin epämatemaattinen henkilö, mutta, minulla ei kuitenkaan aivot aivan riitä tähän ongelmaani kuin kovin hitaasti ja aikaa kuluu turhaan perus dataan,
kun esim. jos minulla on 3D maailma ja siellä lentokone ja tarkoitus olisi liikuttaa tätä lentsikkaa esim. kursoreilla kääntyily ja vaikka ctrl- shift- näppäimistä nopeuden säätö.
Niin, mitä kaikkea minun on otettava huomioon jotta lentsikan liikkuminen 3D maailmassa sitten on mahdollisimman "realistista".
Aika ongelma taas, kiitosta vaan kun jos osaatte 3D perusteita, niin neuvoistanne.
Tämä pyörän uudelleen keksimisen tilanne tässä taasen, eli lyhyemmin kysyttynä
mitä kuuluu olla perus taidoissa kun haluaa liikuttaa alusta 3D maailmassa hienosti.
( Edit. Muokkasin viestiäni hieman, kpzpt )
//----
Kiitos,,
Kiihtyvyys ja objektit(esim. pilvet) luovat realistista tuntua. Peruskoulu fysiikka ja matematiikka riittää joten matemaattisia ongelmia ei pitäisi ilmentyä.
Itse asiassa peruskoulun matematiikka ei riitä alkunkaan. Puhumattakaan toimivasta 3d-renderöijästä, lentokoneen liikkeen laskeminenkaan ei onnistu peruskoulun matematiikalla - sini, tangentti ja kosini siellä kyllä opetetaan, mutta ei niiden käytännön sovellusta tämän kanssa. Nämä toki saa jostain sopivasta esimerkistä luntattua (tällöin tosin voi olla että ei ole hajuakaan siitä mitä ne tarkallaan tekevät). Mitä tulee fysiikkaan, niin ei se aivan niin yksinkertaista ole kiihtymistä laskea jos sen tekee muutenkin kuin joillain mielivaltaisesti valituilla arvoilla.
Oletin että kyseiseen ohjelmaan ei tule kaarteita kääntyessä.
Matematiikan soveltaminen taas riippuu ihan henkilöstä, jotkut keksivät heti miten kuution tilavuus lasketaan avaruuslävistäjästä ja toiset muistavat sen tekemästään tehtävästä luettuuaan matematiikan kirjaa tuntitolkulla.
Mielivaltaiset arvot toimivat hyvin.
Jokotai kirjoitti:
Oletin että kyseiseen ohjelmaan ei tule kaarteita kääntyessä.
Onko tällainen lentokoneen liike sinusta jollakin tavalla realistista? :)
kpzpt: Avaintermi lentokoneen käytöksen mallintamisessa on jäykän kappaleen liike (engl. rigid body dynamics). Lisäksi tarvitset jonkin mallin sille, millaisia voimia ja momentteja lentokoneeseen kohdistuu eri tilanteissa. Yleinen jäykän kappaleen liike on yliopistofysiikan peruskurssien asiaa ja näinollen "helposti opeteltavissa lukiofysiikan ja -matematiikan pohjalta". Aiheesta löytyy myös kiva intialaisella aksentilla maustettu YouTube-luentosarja.
Minua kiinnostaisi tietää, miten olet ratkaissut tai aiot ratkaista useampien kappaleiden asianmukaisen (siten, että taaempana olevat jäävät etualalla näkyvien taakse) piirtämisen näytölle Java2D:llä (ilman z-puskuria?). Tai jos et vielä ole, niin sinua saattaisi kiinnostaa tietää, että se on luultavasti helpommin sanottu kuin tehty.
os kirjoitti:
kpzpt: Avaintermi lentokoneen käytöksen mallintamisessa on jäykän kappaleen liike (engl. rigid body dynamics). Lisäksi tarvitset jonkin mallin sille, millaisia voimia ja momentteja lentokoneeseen kohdistuu eri tilanteissa. Yleinen jäykän kappaleen liike on yliopistofysiikan peruskurssien asiaa ja näinollen "helposti opeteltavissa lukiofysiikan ja -matematiikan pohjalta".
Minua kiinnostaisi tietää, miten olet ratkaissut tai aiot ratkaista useampien kappaleiden asianmukaisen (siten, että taaempana olevat jäävät etualalla näkyvien taakse) piirtämisen näytölle Java2D:llä (ilman z-puskuria?). Tai jos et vielä ole, niin sinua saattaisi kiinnostaa tietää, että se on luultavasti helpommin sanottu kuin tehty.
3DMaailma!
Minä en valitettavasti ole suorittana edes lukiota loppuun jäi tasan puoleen 22 suoritettua kurssia, joskus -98.
Olisikos teillä jotain suosituksia, vaikkapa jonkin hyvä kirjan ostoon, esim. perus peli fysiikka taikka jotain tuollaista ??
-----
Olen jo ratkaissut tässä demossani, joka on jo ollutkin hyvin esillä -> http://88.192.212.114
niin, olen ratkaissut tämän z-bufferin, näin että, kun jokaisella 3D objektilla on keskusta,
näin järjestän piirtojärjestyksen näitten keskuksien mukaan ja sitten taasen
3D objekti tasolla kaikki käänteiset pinnat jätetään kokonaan piirtämättä ja tämä sitten riittänee.
z-bufferia tarvitaan oikeastaan aika harvoin, on aika voimakas lause, mutta,
kun vähän ruuvia vääntää, niin, kyllä se vaan näin on, kappaleet voi eteenkin
ilmailu peleissä piirtää tietyssä järjestyksessä, maan kamara ensin sitten
lentävät 3D objektit ja nämäkin kauimmaiset ensin.
//----
Kiitos,,
kpzpt kirjoitti:
z-bufferia tarvitaan oikeastaan aika harvoin, on aika voimakas lause, mutta,
kun vähän ruuvia vääntää, niin, kyllä se vaan näin on, kappaleet voi eteenkin
ilmailu peleissä piirtää tietyssä järjestyksessä, maan kamara ensin sitten
lentävät 3D objektit ja nämäkin kauimmaiset ensin.
Tuo tapa tosiaan toimii tietynmuotoisilla (konvekseilla) yksittäisillä kappaleilla. Jos kappaleet voivat olla liian ikävässä asennossa toisiinsa nähden, olet kuitenkin hankaluuksissa. Asianmukainen lajittelu voi osoittautua ongelmaksi jopa ihan "tavallisissa" tilanteissa. Monikulmioiden keskustojen etäisyydet kamerasta eivät nimittäin määrää sitä, mikä monikulmio pitää piirtää ensin (EDIT: kuten Metabolixin linkittämästä kuvasta näkyy).
kpzpt kirjoitti:
Olisikos teillä jotain suosituksia, vaikkapa jonkin hyvä kirjan ostoon, esim. perus peli fysiikka taikka jotain tuollaista ??
Älä väheksy aiheen vaikeutta äläkä koulujen merkitystä. Kolmiulotteiseen matematiikkaan ja fysiikkaan ei ole oikotietä. Et voi oppia sitä opettelematta myös lukion oppimäärää tarvittavista aiheista.
Suosittelen lukion fysiikankirjoja. (Kirjastosta löytyy, kysy tädeiltä.) Kannattaa lukea ensimmäinen kurssi (yläasteen kertausta) ja sen jälkeen kaikki liikkeeseen liittyvät kurssit. Vastaavasti (pitkän) matematiikan puolella geometria, analyyttinen geometria, vektorit ja trigonometria ovat tärkeitä. Niistäkin kerrotaan lukion oppikirjoissa. Kirjoissa ei kerrota kaikkea, mutta lukiokirjojen tiedoilla voi ihan todella johtaa esimerkiksi lookAt-ketjussa esittämäni kaavan. Kirjan tietojen lisäksi tarvitaan tietenkin omaa älyä.
Kannattaa tehdä koulukirjoista myös turhilta tuntuvia tehtäviä. Jos ratkaisumallin hahmottelu oppikirjan vaikeimpiin tehtäviin kestää yli viisi minuuttia, ajatuksen soveltaminen toimivasti 3D-moottoriin voi hyvinkin kestää vaikka yli viisi vuotta.
Kolmiulotteisen fysiikan voi helposti johtaa kaksiulotteisista opeista, kunhan muistaa peruslait ja osaa vektorilaskut. Lisäksi Wikipediasta löytyy monien kaavojen kolmiulotteiset versiot, mutta niiden opettelu vaatii, että kaksiulotteiset ovat ensin hyvin hallussa.
kpzpt kirjoitti:
z-bufferia tarvitaan oikeastaan aika harvoin, ... kappaleet voi eteenkin ilmailu peleissä piirtää tietyssä järjestyksessä
Miten ajattelit selvitä esimerkiksi lentokoneen siivestä? Jommankumman moottorin keskikohta voi olla kauempana katsojasta kuin siiven keskikohta, jolloin piirtojärjestyksesi menee pieleen.
Metabolix kirjoitti:
Suosittelen lukion fysiikankirjoja. (Kirjastosta löytyy, kysy tädeiltä.) Kannattaa lukea ensimmäinen kurssi (yläasteen kertausta) ja sen jälkeen kaikki liikkeeseen liittyvät kurssit. Vastaavasti (pitkän) matematiikan puolella geometria, analyyttinen geometria, vektorit ja trigonometria ovat tärkeitä. Niistäkin kerrotaan lukion oppikirjoissa. Kirjoissa ei kerrota kaikkea, mutta lukiokirjojen tiedoilla voi ihan todella johtaa esimerkiksi lookAt-ketjussa esittämäni kaavan. Kirjan tietojen lisäksi tarvitaan tietenkin omaa älyä.
Kannattaa tehdä koulukirjoista myös turhilta tuntuvia tehtäviä. Jos ratkaisumallin hahmottelu oppikirjan vaikeimpiin tehtäviin kestää yli viisi minuuttia, ajatuksen soveltaminen toimivasti 3D-moottoriin voi hyvinkin kestää vaikka yli viisi vuotta.
Kolmiulotteisen fysiikan voi helposti johtaa kaksiulotteisista opeista, kunhan muistaa peruslait ja osaa vektorilaskut. Lisäksi Wikipediasta löytyy monien kaavojen kolmiulotteiset versiot, mutta niiden opettelu vaatii, että kaksiulotteiset ovat ensin hyvin hallussa.
----
Miten ajattelit selvitä esimerkiksi lentokoneen siivestä? Jommankumman moottorin keskikohta voi olla kauempana katsojasta kuin siiven keskikohta, jolloin piirtojärjestyksesi menee pieleen.
3DPiirtelyä!
Täytyypäs tässä käydä keskustan kirjakaupoissa, hakemassa pari fysiikan ja matikan
kirjaa heti ensi viikolla, luultavasti toivottavasti niistä sitten on rutkasti apuja.
-----
Tuo lentokoneen siipi on ihan helppo, sitä on vasen siipi ja oikea siipi.
Näin molempien siipien keskustat ovat moottorin ja rungon vasemmalla ja oikealla puolella,
piirtojärjestys ei mene pieleen kun siipiä on kaksi eikä vain yksi rungon lävistäjä.
Tuo minun linkkini Shakki lauta on jo järjestyksessä -> http://88.192.212.114
En vielä ole linkittänyt sprite ja polygoni sorttausta yhteen, mutta molemmat
siinä linkissä kuitenkin jo sortataan, erikseensä siis vielä toisistaansa tosin.
( Edit. Metabolixille : katselin vasta nyt tuon sinun linkkisi kuvan, olet oikeassa että sitä
pystyy rakentamaan 3d hahmoja joita on vaikeata sortata, mutta, kun näin kerran
on niin sitä myöskin pystyy rakentamaan 3D hahmoja joita on helppo sortata, minä
olen jo päätynyt tähän että rakennan kaikki 3D hahmoni, niin, että, ne ovat helppoja sortata. )
http://temp4321.dy.fi/images/siipi.png
//----
Kiitos,,
kpzpt kirjoitti:
olen jo päätynyt tähän että rakennan kaikki 3D hahmoni, niin, että, ne ovat helppoja sortata
Olet päättänyt tehdä mahdottoman tehtävän. Intuitiivisesti ajatellen pallo on luultavasti ainoa esine, jonka kohdalla lajittelu toimii sijainnista ja asennosta (heh) riippumatta oikein (ja tässäkin ehtona on, että kappaleet eivät ole sisäkkäin). Otetaan mahdollisimman yksinkertainen tapaus: viivan eteen voi piirtää pisteen, joka on kuitenkin kauempana kuin viivan keskipiste. (Katso kuva. Silmä on vasemmassa reunassa.) Millä tahansa vähänkään kulmikkaalla mallilla onnistuu sama temppu.
Metabolix kirjoitti:
kpzpt kirjoitti:
olen jo päätynyt tähän että rakennan kaikki 3D hahmoni, niin, että, ne ovat helppoja sortata
Olet päättänyt tehdä mahdottoman tehtävän. Intuitiivisesti ajatellen pallo on luultavasti ainoa esine, jonka kohdalla lajittelu toimii sijainnista ja asennosta (heh) riippumatta oikein (ja tässäkin ehtona on, että kappaleet eivät ole sisäkkäin). Otetaan mahdollisimman yksinkertainen tapaus: viivan eteen voi piirtää pisteen, joka on kuitenkin kauempana kuin viivan keskipiste. (Katso kuva. Silmä on vasemmassa reunassa.) Millä tahansa vähänkään kulmikkaalla mallilla onnistuu sama temppu.
3DPiirtelyä!
Heh, en ala riitelemään täällä, kun kerran olen jo päätynyt käydä ruinaamassa tällä forumilla sitten myöhempinä kuukausina ja vuosina vinkki apuja pelisivustoni rakenteluissa,
mutta, mutta miksi tämä Shakkilauta ei riitä sinulle todistamaan että 3D sorttaus ei ole mahdoton tehtävä -> http://88.192.212.114
Toisena todisteena esitän yhä saman siipi.png kuvan mikä oli edellisessä viestissänikin -> http://temp4321.dy.fi/images/siipi.png
En ole rakentamassa cyrix, vai mikä se nyt olikaan, suur pelejä, pieniä keveitä 2D ja 3D Java pelejä vain.
Olen itse syntynä vuonna 1970 ja olen nuoruus aikuisuuteni pelaillut Amiga ja DOS pohjaisia 3D pelejä, ja kaikki nämä pelit ovat olleet ilman zbufferia.
Voin sortata 3Dobjectini polygonien keskipisteen taikka lähimmän/kauimman polygoni pisteen, taikka, sitten tietenkin koko objektin vastaavien avulla, ja kaikki mainitsemani tavat toimivat vielä tänä päivänä aivan yhtä hyvin mitä vuosina 91-96 Amiga ja Dos koneissa.
Katso tarkkaan tuota siipi.png kuvaa, se kone tavallaansa on "pallo" jossa on runko paloja ja useita siipiä, ajattele kaikki erillisinä "palloina" jos haluat.
//----
Kiitos,,
kpzpt: Olet valitettavasti väärässä. Voit nähdä tämän esimerkiksi oman lentokonemallisi avulla: jos katsot mallia (EDIT:) riittävän jyrkästi yläviistosta, niin saat aikaan tilanteen, jossa rungon keskipiste on lähempänä kameraa kuin kummankaan alasiiven keskipiste, vaikka piiirtojärjestys pitäisi olla: kauempi alasiipi, runko, lähempi alasiipi.
os kirjoitti:
kpzpt: Olet valitettavasti väärässä. Voit nähdä tämän esimerkiksi oman lentokonemallisi avulla: jos katsot mallia sivulta, loivasti alaviistosta (pyöritä vihreän akselin ympäri noin 45 astetta), niin olet tilanteessa, jossa lähemmän (ylä)siiven keskipiste on lähempänä kameraa kuin rungon keskipiste, vaikka siipi pitäisi piirtää ennen runkoa.
3DMallinnus!
Testaan viikonloppuun mennessä, kunhan saan ensin tämän minun blenderin tallentaman .directx fileen lukijani valmiiksi.
Huomauttaisin yhä että olen pelannut runsaasti 91-96 vuosien 3D pelejä, jotka kaikki ovat ilman zbufferia ja toimivat ainoastaan piirtojärjestyksen mukaan.
Kuinka kommentoitte vuosien 91-96 Amiga ja Dos 3D pelit ??
Vahvistan kuitenkin että koko 3D objektin keskipisteellä ei voi rakentuva engineni tietenkään toimia oikein ihan aina.
Minun koko engineni rakentuu kuitenkin Java Graphics2D luokan avulla tekniikoilla joita siis käytettiin jo Amiga ja Atari ST aikoina.
//----
Kiitos,,
kpzpt kirjoitti:
Huomauttaisin yhä että olen pelannut runsaasti 91-96 vuosien 3D pelejä, jotka kaikki ovat ilman zbufferia ja toimivat ainoastaan piirtojärjestyksen mukaan.
Kuinka kommentoitte vuosien 91-96 Amiga ja Dos 3D pelit ??
Vahvistan kuitenkin että koko 3D objektin keskipisteellä ei voi engine tietenkään toimia oikein ihan aina.
Minun koko engineni rakentuu kuitenkin tekniikoilla jota siis käytettiin jo Amiga ja Atari ST aikoina, Java Graphics2D luokan avulla.
Se, että jokin peli ei käytä z-puskurointia, ei tarkoita sitä, että se toimisi välttämättä idealla, jota sinun ohjelmasi käyttää. Esimerkiksi Wolfenstein 3-D (kuten aiemmissa ketjuissa on jo mainittu) käyttää ray casting -nimistä tekniikkaa, jonka lähestymistapa poikkeaa sekä z-puskuroinnista, että kappaleiden järjestämisestä ennen piirtoa.
EDIT: pahoittelut edellisen viestin "ohjeiden" kanssa säheltämisestä. Kantava ajatus on kuitenkin se, että esimerkiksi lentokonemallisi on jo sellainen kappale, jota et saa piirtymään oikein järjestämällä sen osia keskipisteiden etäisyyksien mukaan. Riippumatta siitä miten lasket keskipisteet, löydät aina katselukulman, josta malli piirtyisi väärin.
os kirjoitti:
EDIT: pahoittelut edellisen viestin "ohjeiden" kanssa säheltämisestä. Kantava ajatus on kuitenkin se, että esimerkiksi lentokonemallisi on jo sellainen kappale, jota et saa piirtymään oikein järjestämällä sen osia keskipisteiden etäisyyksien mukaan. Riippumatta siitä miten lasket keskipisteet, löydät aina katselukulman, josta malli piirtyisi väärin.
3DMallinnus!
Ööh, nyt kyllä täytyy sanoa että tämä on minun ensimmäinen oma 3D engine, minulla on rajoitettuja kokemuksia Direct3D ja OpenGL kirjastoista, mutta, niitten tuntemisesta ei Graphics2D:n kanssa ole juuri mitään apua, kenties ajatus mallit kirjaston rakentamiseen.
Kuitenkin olen luottavainen että onnistun rakentamaan lähiviikkoihin mennessä täysin valmiin ( ilman fysiikkaa vielä ) 3DObjekti, 3DScaleSprite ja 3DPolygoni enginen, olen rakentana tämän 3DObjektien piirron siis polygonien ja itse objektien keski etäisyyden mukaan.
Kantava ajatus on tietenkin tämä polygonien keskipiste ja touhua 3Dobjektien etäisyyksien ollessa suuria nopeuttaa tämä itse 3Dobjektien keskipiste.
Kantava ajatus on myös se että polygonit ovat suurin piirtein samankokoisia,
tämä on minun netti kokemattomuuttani että en huomannut sanoa tätä jo aiemmin
kun polygonit ovat suurinpiirtein samankokoisia, näin, tämä keski etäisyys ymmärtääkseni toimii ihan hyvin.
Mutta, vahvistan nämä sitten kunhan tämä minun .directx file lukijani on valmis ja tuo siipi.png kone pörrää vaikka tuon linkkini shakkilaudan päällä parin muun vastaavan koneen kanssa.
//----
Kiitos,,
Jos "ihan hyvin" sallii sen, että asiat näkyvät aina välillä vähän väärin, kun niitä kääntelee, niin silloin lähestymistapasi toimii ihan hyvin. Polygonien koko ei varsinaisesti vaikuta asiaan. Oikeanlaisilla rajoituksilla ja kikkailuilla ohjelmassa voit kyllä saada aikaan paljon toimivaa 3D-grafiikkaa, kuten nykyinen shakkilautasi, mutta geneerisen 3D-enginen kanssa taitaa olla aika hiljaista.
On tosiaan harmi, jos Java 3D:tä tai mitään matalan tason OpenGL-APIa ei voi käyttää appleteissa ilman lisäasennuksia. Ilman niitä kunnollinen 3D-piirto ei nimittäin kovin helpolla taida onnistua.
Minusta algoritmisi voi todeta aika huonoksi jo sillä perusteella, että käytännössä kaikki 3D-pelit viimeisen kahdenkymmenen vuoden aikana ovat käyttäneet jotain mutkikkaampaa tapaa. Eihän kukaan huvikseen halua vaikeasti ja hitaasti tehdä, vaan sille on oltava hyvä syy.
Polygonien koolla ei ole mitään tekemistä sen kanssa, toimiiko kyseinen algoritmi vai ei. Voisin esittää matemaattiset perustelut sille, että ideassasi on virhe, mutta turha niitä on esittää, kun et kuitenkaan ymmärtäisi niistä mitään. Niinpä turvaudun taas havainnolliseen esimerkkiin:
Seuraavassa ASCII-piirroksessa on kolme yhtä pitkää viivaa. Suoraan vasemmalta katsottuna ylin viiva on kauimpana mutta silti etummaisena. Toisin sanoen algoritmisi toimisi väärin. Voit korvata jokaisen viivan lentokoneella, niin saat pitävän todisteen, että algoritmisi ei toimi silläkään.
/ / // / // / /
On aika turhauttavaa toistaa samoja asioita moneen kertaan henkilölle, joka ilmeisesti uskoo ilman lukiomatematiikkaa tietävänsä kolmiulotteisesta geometriasta enemmän kuin pitemmälle opiskelleet ja alan harrastajat. Taidan siis lopettaa neuvomisyritykseni tältä erää tähän – tervetuloa takaisin sitten, kun olet opetellut tarpeeksi matematiikkaa ja fysiikkaa näitä laskuja varten. Sitä ennen pidä mielessäsi, että vaikka tietystä kuvakulmasta kone näyttääkin oikealta, et voi väittää olevasi oikeassa, ennen kuin olet kokeillut kaikki kuvakulmat.
Metabolix kirjoitti:
Minusta algoritmisi voi todeta aika huonoksi jo sillä perusteella, että käytännössä kaikki 3D-pelit viimeisen kahdenkymmenen vuoden aikana ovat käyttäneet jotain mutkikkaampaa tapaa. Eihän kukaan huvikseen halua vaikeasti ja hitaasti tehdä, vaan sille on oltava hyvä syy.
Tässä tapauksessa tilanne taitaa olla siinä mielessä erilainen, että käytössä on Java 2D, jolla voi piirtää kiihdytettyä 2D-grafiikkaa, mutta ei käyttää z-puskuria. (korjatkaa jos olen väärässä)
os kirjoitti:
Metabolix kirjoitti:
Minusta algoritmisi voi todeta aika huonoksi jo sillä perusteella, että käytännössä kaikki 3D-pelit viimeisen kahdenkymmenen vuoden aikana ovat käyttäneet jotain mutkikkaampaa tapaa. Eihän kukaan huvikseen halua vaikeasti ja hitaasti tehdä, vaan sille on oltava hyvä syy.
Tässä tapauksessa tilanne taitaa olla siinä mielessä erilainen, että käytössä on Java 2D, jolla voi piirtää kiihdytettyä 2D-grafiikkaa, mutta ei käyttää z-puskuria. (korjatkaa jos olen väärässä)
3DProjektini!
Te käytätte aivan liian voimakkaasti tyrmäävää kieltä aloittelevan pelisuunnittelijan tyrmäämiseen, miksi pitää puhua huonoa oloa toiselle ??
"mutta turha niitä on esittää, kun et kuitenkaan ymmärtäisi niistä mitään",
Minä huomauttaisin vielä kerran että tämä toimii, mitä olen rakentamassa, ja jos herra Metabolix vaivautuu käsittämään
nuo esimerkki kuvansa viivat yksittäisinä polygoneina niin etäisyys mittaus toimii ihan hyvin, eteenkin kun polygonit ovat suurinpiirtein samankokoisia.
http://temp4321.dy.fi/images/siipi.png
En ala riitelemään enempää, laitan demon ensi viikoon mennessä linjoille,
lisä pyytönä, jos nyt kerran sitten olette niin varma että valikoimani tapa ei voi toimia, niin,
lyhyt kysymys vielä, millä tavalla Amiga, Atari ST ja DOS 3D pelit piirrettiin ruutuun,
niissä ei missään ole ollut zbufferia myöskään.
//----
Kiitos,,
kpzpt kirjoitti:
lyhyt kysymys vielä, millä tavalla Amiga, Atari ST ja DOS 3D pelit piirrettiin ruutuun, niissä ei missään ole ollut zbufferia myöskään.
Misä tiedät, että niissä ei ole?
Sitten toinen kysymys, niin mihin peleihin viittaat? Itse muistan Amigalla, että joissakin ohjelmissa 3D-esineet näkyivät joissain tilanteissa väärin, mutta se ei ollut sen ajan standardien mukaan niin hirveän paha asia. Voin silti kuvitella että erilaisia implementaatioita löytyi ziljoona. Siinähän rauta tuki lähinnä viivan piirtoa ja fillaamista sekä pintojen yhdistämistä blittaamalla. Loppu jäi softalla toteutettavaksi ja siinä tietty voi toteuttaa vaikka z-bufferin jos haluaa (eikä välttämättä edes paha rasti suhteessa muun laskennan määrään).
Grez kirjoitti:
Misä tiedät, että niissä ei ole?
Loppu jäi softalla toteutettavaksi ja siinä tietty voi toteuttaa vaikka z-bufferin jos haluaa (eikä välttämättä edes paha rasti suhteessa muun laskennan määrään).
zBuffer!
Nyt täytyy sanoa että en ole tosinkaan ammattilainen, en edes kehittynyt harrastelija, 3D:n kanssa, mutta, minun käsittääkseni zbuffer on yleensä yhtä suuri alue mitä näyttö piirtoaluekkin, tämä zbuffer sisältää näyttöpixelin kohdalla syvyys arvon jota tarkistamalla voi sitten arvioida voiko kyseiseen pixeliin piirtää polygoni väriä.
Eli, zBuffer kylläkin tuplaa-triplaa tehon käytön, no ainaskin aika lähelle.
zBuffer pitää tarkistaa ennen piirtoa, ja myöskin updateta jos polygoni pixelin voi piirtää kyseiseen bufferin kohtaan.
Eteenkin vanhoissa laitteissa oli käytännössä melko mahdotonta rakentaa sulavaa 5fps-10fps näyttöpäivitystä jos kun käytti syvyys bufferia.
Mutta, en ole ihan varma olenko sitten ymmärtänä tämän koko bufferin toiminnan oikein !!
//----
Kiitos,,
Grez kirjoitti:
Itse muistan Amigalla, että joissakin ohjelmissa 3D-esineet näkyivät joissain tilanteissa väärin, mutta se ei ollut sen ajan standardien mukaan niin hirveän paha asia. Voin silti kuvitella että erilaisia implementaatioita löytyi ziljoona. Siinähän rauta tuki lähinnä viivan piirtoa ja fillaamista sekä pintojen yhdistämistä blittaamalla. Loppu jäi softalla toteutettavaksi ja siinä tietty voi toteuttaa vaikka z-bufferin jos haluaa (eikä välttämättä edes paha rasti suhteessa muun laskennan määrään).
Itse asiassa luulen, että taisi suurin osa kyllä vaan sortata objektit z-koordinaatin mukaan ja piirtää ne ruudulle takaa-eteen järjestyksessä. Monesti rajoitetuilla resursseilla ideanahan on vain huijata silmää, eli käytännössä hiukan järjestellä asioita ja pitää kaikki kovassa liikkeessä, jotta puutteet eivät tulisi niin pahasti esille.
Ja mitä tulee z-bufferiin, missä siis piirrettäessä jokaisen polygonin jokainen pikseli tarkistetaan, että onko se etummainen pikseli kyseisissä koordinaateissa. Rupeaa 8 MHz tietokoneella laskennan määrä olemaan kyllä jo kohtuullisen suuri, jos nimittäin haluaa, että pelistä ei tule hidastettua diaesitystä.
Hienoa, saatiin perustelut miksi niissä ei todennäköisesti ole käytetty z-bufferia.
kpzpt kirjoitti:
lyhyt kysymys vielä, millä tavalla Amiga, Atari ST ja DOS 3D pelit piirrettiin ruutuun,
niissä ei missään ole ollut zbufferia myöskään.
Lyhyt vastaus: nämä pelit (ainakaan ne, joita olen itse pelannut) eivät tukeneet mielivaltaisiin malleihin perustuvaa 3D-grafiikkaa. Niissä käytetään mitä kummallisimpia temppuja, jotta asiat saataisiin näyttämään mahdollisimman kolmiulotteisilta. Esimerkiksi Wolfenstein 3-D on pelimekaniikaltaan täysin kaksiulotteinen peli. Millekään tuon ajan moottorille ei olisi voinut vain antaa lentokonemalliasi ja olettaa, että se piirtää sen oikein, kuten nykyisille 3D-moottoreille voi.
Pahoittelen, jos omat kommenttini ovat vaikuttaneet liian tyrmääviltä. Tarkoituksena on ollut vain kertoa, että ohjelmassasi on piirtoon liittyvä ongelma, jota on vaikea ratkaista kunnolla (itse en ainakaan suoraan keksi mitään ratkaisua) ja tämä kannattaa tiedostaa, ennen kun alkaa rakennella liian monimutkaisia sovelluksia tuon moottorin varaan.
Ja mitä fysiikkaan tulee, niin varsin omaperäisillä "luonnonlaeilla" on ennenkin saatu hienoja sovelluksia aikaan, joten kannattaa miettiä, kuinka realistisia liikeyhtälöitä oikeastaan tarvitsee.
kpzpt kirjoitti:
Te käytätte aivan liian voimakkaasti tyrmäävää kieltä aloittelevan pelisuunnittelijan tyrmäämiseen, miksi pitää puhua huonoa oloa toiselle ??
"mutta turha niitä on esittää, kun et kuitenkaan ymmärtäisi niistä mitään",
En suinkaan ilkeyttäni tuota sanonut, vaan johan itsekin olet todennut moneen kertaan, ettet osaa pistetuloa ja ristituloa edes sen vertaa, että olisit kopioinut aiemmin esittämäni projektiokaavan ("lookAt-kaavan"). Siltä pohjalta on aika hankala ymmärtää vielä astetta mutkikkaampia kaavoja. Anteeksi kuitenkin, jos ilmaisuni loukkasi.
kpzpt kirjoitti:
Minä huomauttaisin vielä kerran että tämä toimii, mitä olen rakentamassa, ja jos herra Metabolix vaivautuu käsittämään nuo esimerkki kuvansa viivat yksittäisinä polygoneina niin etäisyys mittaus toimii ihan hyvin, eteenkin kun polygonit ovat suurinpiirtein samankokoisia.
http://temp4321.dy.fi/images/siipi.png
Edelleenkin katsot vain yhtä tilannetta ja yhtä mallia. Seuraavassa kuvassa on kolme samanlaista lentokonetta (suunnilleen oman mallisi mukaan tehtyjä), ja lienee selvää, että oma algoritmisi piirtäisi ne väärin juuri tästä kuvakulmasta.
http://metabolix.jouluserver.com/putka/kpzpt/
Ongelmallisten osien etäisyyksiä kamerasta (järjestyksessä):
- vasemman koneen alempi siipi kuvan keskellä: 19,5
- oikea kone: 19
- alimman koneen ylempi siipi kuvan keskellä: 18,5
- alin kone: 17
Kaksi ensin mainittua osaa piirtyvät siis väärin, ja itse en ainakaan nykyaikana hyväksyisi pelissä noin pahaa piirtovirhettä: melkoinen pala ylimmästä koneesta jäisi piiloon! Toki ongelmia voi aina vähentää jakamalla mallit entistä pienempiin paloihin, mutta kun osien määrä lisääntyy, myös järjestäminen kestää pidempään, ja aika pian siitä tulee hitaampi kuin edes z-puskurista.
Ja jos nyt vetoat yksittäisten polygonien tapaukseen, niin mitäpä jos herra kpzpt suvaitsisi itse hahmottaa ne kolme viivaa samankokoisina polygoneina (jatka vaikka viivasta neliö siihen suuntaan, joka ei kuvassa näy), jolloin hän ehkä huomaisi, että tilanne ei muutu miksikään, vaan polygonit ovat samalla tavalla väärässä järjestyksessä kuin viivatkin.
Aihe on jo aika vanha, joten et voi enää vastata siihen.
