Az egész téma jelenleg valószínűleg borravaló.
Hogy eljussunk a lényeghez, vegyük a pincéreket. Nekik általában tényleg szoktak adni borravalót. Ők kedvesek a vendéggel, tisztelettudóak, türelmesek. Ez a kedves viselkedés, pontosság egy olyan dolog, munka közben, amire én is azt mondom, hogy rendben, ez megér pár extra Forintot a zsebébe, hisz ez neki nyilván energiába kerül, de megteszi, hogy nekünk ne legyen kellemetlen.
Ezzel a résszel nincs bajom.
Amivel bajom van; van egy bizonyos étterem, ahonnan néha rendelgetek levest. Maga a leves igen jó, sőt, mást is szoktam ritkábban onnan, és kifejezetten mondhatom, hogy amit tőlük rendeltem, az nagyon jó volt. Viszont az a mód, ahogy kihozzák nekem az ételt a futáraik... Azért többesszámban mondom, mert már kettőnél járok, többet meg nem láttam még onnan hordani, bár mintha derengene egy harmadik is, hasonló típusú, ez nem biztos viszont.
Az a lényeg, a múltkori eset az volt, hogy a srác, aki kihozta a kaját, valami olyan volt, akivel még nem találkoztam. A negyedik emeleten lakok, 4 emeletes panel, és nincs lift.
Tudom, hogy fárasztó felsétálni, nekem is állandóan kell ugye fel és le. Hozzá lehet szokni. Meg egészséges is, gondolom.
A gyakori futár a kettő közül általánosan feljön, majd jóformán hozzámvágja a kaját fél méterről, és sarkon is fordul, indul lefelé. Nem köszön (még annyit sem, hogy "helló"), meg sem szólal, és csúnyán néz közben, mint aki elfáradt az élettől és túl van már két világháborún. Egyébként egy ötvenes évei körül járó fickó.
A másik, mostani, új futár egy pocakosabb, fiatalabb srác volt, talán harmincas. Felhozta az ételt nagyon laza tempóban, becsöngetés után vagy 3 perccel ért fel 4 emeletet (én mozgékony típus vagyok, nekem ez 45-50 másodperc szokott lenni kábé - csak példaként mondom). Szóval az azért nem egy sietős tempó, még ha van is nála Mindössze két apró zacskó; mivel kocsival jött idáig, elég volt azt magával hoznia az épületbe. Ezek után felsétált szóval, valamivel szebben ideadta, mint a kollégája, majd egy elég megvető arccal, miközben megköszöntem neki szépen a fáradozásait, annyit nyögött vissza fordulás közben, hogy "Én is köszönöm, hogy felsétálhattam!"..
._.
Na akkor, haladjunk sorban a dolgokon.
Először is: én tehetek róla, hogy nincs lift? Azt hiszem, hogy nem sok közöm van a dologhoz.
Másodszor: ez nem a munkája része? Nem tudom pontosan, hogy mi a munkaköri leírása, de gondolom, ha már az ételrendelős oldalakon (kettőt használok, általános kajára a Falatozz.hu-t, gyorskajára a NetPincért) egészen meg van adva a házszámon túl az emelet, ajtó is, akkor nyilván nem opcionális számára, hogy egészen az ajtóig hozza az ételt, hanem feladata. Ha feladata, akkor ilyen lépcsőzős esetben is, miért ő van még felháborodva?
Ha nekem egy megerőltetőbb feladatot adnak a munkahelyen, én sem nyavalyogva állok neki, hogy de hát ez fárasztó.
Valamint, ha probléma a felsétálás, mert fárasztó, ami érthető, akkor jó. Ne szóljon egy szót sem, de akkor ne vágjon mellé savanyú pofát. Csinálja teljesen robotként, ne köszönjön, nekem sem lesz vele problémám akkor. Ezzel a megoldással is ellennék, ha nem grimaszol mellé. Meg nem hozzámvágja a kaját, hanem a kezembe adja rendesen.
Nem fizetnek eleget ezért? Arról sem én tehetek, úgy gondolom. Ha pedig nem szereti ezt csinálni, az sem az én hibám. Vagy ha mindkettő - nem is szereti, és nem is fizetnek eleget, váltson munkahelyet. Ha erre nincs lehetőség, akkor meg örüljön, hogy van munkája, és hogy minimális fáradalmat kell elviselnie...
Jártam már úgy is, hogy azt kamuzta a futár (belegondolva ez még az előző lakhelyemen volt, ami a belvárosban volt; ott a 3. emeleten laktam és lift is volt, és ugyanerről a helyről ugyanaz az első, gyakori futár volt), hogy nem nyílik az ajtó, menjek már le én az épület elé.
Egyébként egy szót nem szóltam, és lementem én, átvettem emberi módon tőle.
Sőt, speciel én még ebben az opcióban is benne lennék. Hívjon fel, mikor ideér, és lesétálok én érte, inkább ez, minthogy köcsög módra "hozzámvágja" a kajámat, meg a nyugtát.
Vissza az elejére. A borravaló. Nyilván ez lehet a probléma fő oka. Ha már ennyit sétál felfelé, elvárna párszáz Ft-ot a kezébe. Ezzel a logikával nehezen tudok egyetérteni. Az étel, amit rendelek, az maga 1500 Ft körüli. Ha adok neki 500 Ft-ot, akkor technikailag az étel árának negyedét adom oda neki. Szóval 4 ilyen rendelés után buktam is egy egész kajálás árát.
Van kb. 200 Ft kiszállítási díj beépítve a rendelési felületbe. Ha ez akkora gond a futároknak, miért nem kérik, hogy ezt emeljék párszázzal? Ha a borravaló be lenne építve az árba, nem lehetne "kihagyni", ha már ennyire fontos nekik az a plusz párszáz Ft minden alkalommal. Én ebben is benne lennék, mert ugye mit tehetnék ellene.
Személy szerint futároknál sokallom ezt az elvárást, hogy borravaló. Miközben a feladatuk épp a kiszállítás, ami nem csak kocsikázásból vagy motorozásból (, ritkábban biciklizésből) áll, hanem ez a séta is benne van.
És mit ne mondjak, külön zavar, hogy tényleg elvárják némi nehézségért a plusz pénzt. Vajon mit szólna a főnök, ha én azt mondanám neki, hogy "ez a feladat necces, kérnék érte egy kis plusznak egy pizza árát most a kezembe, és aztán nekifogok". Ha morális alapon nézzük, akkor sem érdemli meg a futár. Másfél-két órát kell várni mindig a kajára, és volt már, hogy szinte kihűlve érkezett meg a leves, olyankor nyilván nem csak későn készült el, hanem későn jutott vele idáig. Ráadásul nem is kedves a fickó, ha már ez a másik ok, amiért borravalót adnánk. Ha se nem precíz, se nem kedves, sőt, konkrétan ellenszenvet vált ki, mert miatta még én érzem magam rosszul, hogy nem dobok neki extra pénzt, nem is hiszem, hogy érdemel.
A lényeg pedig:
A Falatozz.hu-n csak az ételt lehet értékelni a rendelés után, míg a NetPincéren a kiszállítást is. Ebből a bizonyos étteremből legközelebb a NetPincérről rendelek, elvileg fent van ott is..
Ételfutárok 2020. június 28., vasárnap - 11:04
Hely:
Miskolc, Magyarország
Texture splatting 2020. április 21., kedd - 0:51
A Wikipédia is ír róla egy cikket, képtalálatok közt is sok jó ötletet látni a kifejezésre keresve.
Példa:
Ebbe a problémába én legelőször a Three.js-sel futottam. Más környezetekben már eleve kész megoldás van rá, lásd Unity3D-nél. Rajzolhatsz paint-szerűen 3d-ben, és azonnal tökéletes az egész.
Régen az első ötletem a Metin2 miatt az volt, hogy biztos az egész pálya textúrázása Photoshop-szerűen meg van rajzolva már előre, majd ezt feldarabolták (ez az egész művelet akár automatizált is lehet, a lényeg azon van, hogy előre elkészítve történik a dolog) kis részekre, akárcsak magát a pályát, és egyszerűen betölti a megadott chunk textúráját a megadott területre.
Ez tuti működő, és nagyon CPU-kímélő, cserébe rohadtul helyigényes, de memóriaigényes is. A metinből ki is nézném, de igencsak ott sem ez van a háttérben.
A fenti kép példán jól látszik a lényeg. Adott N textúra, amiket L hosszúságú átmenettel akarunk ellátni egymás felé, bármelyikből bármelyikbe.
A Three.js megoldása shaderes alapú, amit egy tanárEmbör valósított meg példa módon, és tett is közzé, amit köszön neki minden élő, mert remek alap.
Én magam is kísérleteztem vele, az ő megoldásával két nagy gond van (nem is a megoldásával, hisz csak példaképp hozta létre, nyilván olyan céllal, hogy aki többet akar, az tovább is fejlesztheti).
De ez a módszere alapja shaderrel.
Lényegében:
A domborzatra, vagy síkra (mindegy) minden textúra ki van rajzolva egyszerre. Ugyanakkor a shader ad egy virtuális magasságot a textúráknak, amik le tudnak menni 0-ra vagy alá is (ekkor meg sem jelennek, hanem egy default fekete kirajzolási szín veszi át a helyüket, amit a textúrák egyébként ki tudnak takarni). És tulajdonképp a trükk annyi, hogy bizonyos magasságtól indulva hullámszerűen az egyik textúra elkezd kiemelkedni 1 irányába, míg az épp látszódó elsüllyed 0 felé, és idővel helyetcserélnek, így képezve adott pontokon az átmenetet. És ugyanez megy végbe más-más Y magasságoknál a textúrákon.
És hogy lehetne ezt javítani?
Mármint olyan értelemben, hogy bármelyik textúra bármelyikbe át tudjon menni, és akár változtatható hosszúságú átmenettel is?
A netes leírások alapján sokan színhez kötik a textúrát egy térképen, mint fenti képen látható. Így alapvetően 3 vagy 4 szín jelöl 3/4 textúrát, és ezek egymásba kábé bármilyen átmenettel át tudnak menni. A hiba ezzel kettő: a textúrák mennyisége, és hogy egy majdnem real méretarányú textúrára valósítják meg. És pont a spórolás a lényege a dolognak. Szóval faja, hogy egy ekkora képen több tíz pixel átmenetével szép átmenetet képeznek a textúrák közt is, de egy játékbéli térképen majd 4-5 pixel is soknak fog hatni, több métert fed át a játékon belül (már amennyiben a Metinhez hasonlóan kb 300-500 pixeles térképek vannak, amik több száz métert fednek le a játékon belül).
Megoldás röviden: az RGB minden betűje. Tulajdonképp ugyanezt megcsinálva, de mondjuk jól kihasználva a színeket egy PNG képpel már 256 textúrát tárolhatunk akár (trükközéssel még többet is). Hogyan? (És itt jön a lényeg, ami előtt rizsázok mióta.) Mondjuk a red sáv jelöli a kép pixelében az original textúrát (hogy miből induljon az átmenet), a zöld szín a "melyikké" textúra indexét, és a kék szín utolsó helyen pedig az átmenet állapotát százalékban. Ennyi. Már csak meg kéne valósítani, hogy a shaderes megoldással ez király legyen, és ez némi gondolkodást igényel majd, meg számítást.
Magát a kis térképet, amin ez a miből, mibe és hány% típusúan, a pixelben lévő színek összetételét meg vizualizálhatjuk is egyből 3d-ben, akár egy Unity-szerű painttal (ilyet is akarok), és végül a memóriában tárolt bittérkép alapján menthet egy PNG képet a megtervezett térképről, így már szinte tényleg semmi munka nem lesz vele, és teljesen Unity hatást kapunk készítés közben és használati performancia közben is.
Idővel majd megvalósítom, már egyszer elkezdtem, félig kész is volt, de félbehagytam, és törölték a tárhelyem is, talán viszont volt mentés /de akkor is 0-ról csinálom újra, tökmindegy/.
Ezt a bejegyzést majd folytatom, ha lesz kedvem a leírtakat is megvalósítani.
Példa:
Ebbe a problémába én legelőször a Three.js-sel futottam. Más környezetekben már eleve kész megoldás van rá, lásd Unity3D-nél. Rajzolhatsz paint-szerűen 3d-ben, és azonnal tökéletes az egész.
Régen az első ötletem a Metin2 miatt az volt, hogy biztos az egész pálya textúrázása Photoshop-szerűen meg van rajzolva már előre, majd ezt feldarabolták (ez az egész művelet akár automatizált is lehet, a lényeg azon van, hogy előre elkészítve történik a dolog) kis részekre, akárcsak magát a pályát, és egyszerűen betölti a megadott chunk textúráját a megadott területre.
Ez tuti működő, és nagyon CPU-kímélő, cserébe rohadtul helyigényes, de memóriaigényes is. A metinből ki is nézném, de igencsak ott sem ez van a háttérben.
A fenti kép példán jól látszik a lényeg. Adott N textúra, amiket L hosszúságú átmenettel akarunk ellátni egymás felé, bármelyikből bármelyikbe.
A Three.js megoldása shaderes alapú, amit egy tanárEmbör valósított meg példa módon, és tett is közzé, amit köszön neki minden élő, mert remek alap.
Én magam is kísérleteztem vele, az ő megoldásával két nagy gond van (nem is a megoldásával, hisz csak példaképp hozta létre, nyilván olyan céllal, hogy aki többet akar, az tovább is fejlesztheti).
- csak előre meghatározott hosszúságban tud átmenet keletkezni a megoldásával 2 textúra közt
- csak egymás után következő textúrák tudnak átmenetelni a másikká.
- A-ból lehet B, B-ből C, C-ből D, viszont A-ból D nem, stb.
De ez a módszere alapja shaderrel.
Lényegében:
A domborzatra, vagy síkra (mindegy) minden textúra ki van rajzolva egyszerre. Ugyanakkor a shader ad egy virtuális magasságot a textúráknak, amik le tudnak menni 0-ra vagy alá is (ekkor meg sem jelennek, hanem egy default fekete kirajzolási szín veszi át a helyüket, amit a textúrák egyébként ki tudnak takarni). És tulajdonképp a trükk annyi, hogy bizonyos magasságtól indulva hullámszerűen az egyik textúra elkezd kiemelkedni 1 irányába, míg az épp látszódó elsüllyed 0 felé, és idővel helyetcserélnek, így képezve adott pontokon az átmenetet. És ugyanez megy végbe más-más Y magasságoknál a textúrákon.
És hogy lehetne ezt javítani?
Mármint olyan értelemben, hogy bármelyik textúra bármelyikbe át tudjon menni, és akár változtatható hosszúságú átmenettel is?
A netes leírások alapján sokan színhez kötik a textúrát egy térképen, mint fenti képen látható. Így alapvetően 3 vagy 4 szín jelöl 3/4 textúrát, és ezek egymásba kábé bármilyen átmenettel át tudnak menni. A hiba ezzel kettő: a textúrák mennyisége, és hogy egy majdnem real méretarányú textúrára valósítják meg. És pont a spórolás a lényege a dolognak. Szóval faja, hogy egy ekkora képen több tíz pixel átmenetével szép átmenetet képeznek a textúrák közt is, de egy játékbéli térképen majd 4-5 pixel is soknak fog hatni, több métert fed át a játékon belül (már amennyiben a Metinhez hasonlóan kb 300-500 pixeles térképek vannak, amik több száz métert fednek le a játékon belül).
Megoldás röviden: az RGB minden betűje. Tulajdonképp ugyanezt megcsinálva, de mondjuk jól kihasználva a színeket egy PNG képpel már 256 textúrát tárolhatunk akár (trükközéssel még többet is). Hogyan? (És itt jön a lényeg, ami előtt rizsázok mióta.) Mondjuk a red sáv jelöli a kép pixelében az original textúrát (hogy miből induljon az átmenet), a zöld szín a "melyikké" textúra indexét, és a kék szín utolsó helyen pedig az átmenet állapotát százalékban. Ennyi. Már csak meg kéne valósítani, hogy a shaderes megoldással ez király legyen, és ez némi gondolkodást igényel majd, meg számítást.
Magát a kis térképet, amin ez a miből, mibe és hány% típusúan, a pixelben lévő színek összetételét meg vizualizálhatjuk is egyből 3d-ben, akár egy Unity-szerű painttal (ilyet is akarok), és végül a memóriában tárolt bittérkép alapján menthet egy PNG képet a megtervezett térképről, így már szinte tényleg semmi munka nem lesz vele, és teljesen Unity hatást kapunk készítés közben és használati performancia közben is.
Idővel majd megvalósítom, már egyszer elkezdtem, félig kész is volt, de félbehagytam, és törölték a tárhelyem is, talán viszont volt mentés /de akkor is 0-ról csinálom újra, tökmindegy/.
Ezt a bejegyzést majd folytatom, ha lesz kedvem a leírtakat is megvalósítani.
Címkék:
érdekesség,
internet,
javascript,
ötlet,
programozás,
tanítás
Időkép-kamera 2020. január 31., péntek - 2:12
Hát röviden, bátyám ötlete volt, de király ötlet. Mármint az, hogy kell kamera, IP kamera, amit kirakhatunk az időképre. Neki már volt egy közvetítése, androidos, régi, már nem használt telefonról az utcánkra, ez így egy szintlépés volt tulajdonképp.
Most a történetet hosszasan nem írnám le. Itt érhető el az új kamerája egyébként.
Egyébként innen rendeltük, és erről a kameráról van szó, amihez még ezt a csomagot kell hozzácsapni a kosárba.
Megjegyzendő, hogy pár Ft-tal drágábban egészen jobb minőségű kamerák is kaphatóak ugyanitt, szóval ha ilyesmit fontolgatsz, nézd át az oldalt!
Ha pont ezt a kamerát vennéd meg, akkor a következő lépéseket kell megtenni:
Ott pedig be tudsz lépni az alapértelmezett adatokkal, valami papíron tuti le van írva, vagy elsőre jelszót kell megadnod, ilyesmi.
Tök jó, hogy sok dolgot be lehet rajta állítani, először nem árt az IP címet átállítani arra, amit otthon amúgy is használsz, és ezután visszaállíthatod a saját IP-det is DHCP-re. Meg igazából ezután átdughatod a kábelt a gépedből a routerbe, úgyis eléred otthonról már a kamerát, IE-ből.
Valójában ez így már kész is, egy DDNS-t érdemes beállítani. A kamera beállításai közt tuti van ilyesmi, javasol is egyet, automatikusan frissíti ő magát a kábeles neten. Érdemes még kiszedni a videó-megtekintéshez való autentikációt, hogy a felvételt /ha nyilvánosnak van úgyis szánva/ azonnal megnyissa bármi, jelszó és egyéb nélkül.
Egy azonnali pillanatképet elérhetsz a kamerás cuccod elérhetőségén http-vel kezdve, majd útvonal szerint "/snap.jpg".
// ez persze eltérhet kameránként, de én ugye ezt a leírást ahhoz írom, amit mi rendeltünk.
No hát no, az Időképnek van saját leírása több is az oldalon, hogy oldd meg a képet.
Ehhez persze elengedhetetlen, hogy meg kell osztanod a kamera-eszközöd belső IP-jéhez a 80-as és az 554-es portot (az utóbbit csak akkor, ha live videót is akarsz engedélyezni). A port forwardnak könnyű utánajárni, én most Digi-s vagyok; nincs lehetőség port range megadására első ránézésre, DE a trükk az, hogy állíts be appnak bármit, akkor megjelenik a portszámok inputja, ahova írhatod őket, és utána akár vissza is állíthatod egyedire amúgy a radiobuttont.. (Mindegy, ez csak Digi-s extra help.)
De röviden a kamera beállításoknál az oldalukon megadod képletöltési linknek ezt a snap.jpg-t, live-nak meg megadhatod az rtsp://IPCIMED:554 címet nyugodt szívvel.
az IPCIMED helyére természetesen a külsőleg elérhető IPv4 címed kell, de persze érdemes DDNS-sel folyton frissítve tartani, és akkor az állandó átirányítási cím kell oda.
Ezzel valójában kész is, ezután automatikusan működik az időkép kamerád.
Az enyém itt érhető el egyébként:
https://www.idokep.hu/webkamera/eprog
Raknék ide egy pillanatképet róla, de ugye a HTTPS oldal nem szereti a HTTP contentet, és így hajnal 2-kor lusta vagyok valamivel leparseolni a képet, szóval majd máskor. Vagy kattints ide..
Végezetül egy csodás kép, hogy is sikerült elhelyezni a kamerát az erkélyen:
Edit:
Az első nap körülbelül 500 megtekintés volt a kamerán, és egyből kikerült ebbe a cikkbe.
Most a történetet hosszasan nem írnám le. Itt érhető el az új kamerája egyébként.
Egyébként innen rendeltük, és erről a kameráról van szó, amihez még ezt a csomagot kell hozzácsapni a kosárba.
Megjegyzendő, hogy pár Ft-tal drágábban egészen jobb minőségű kamerák is kaphatóak ugyanitt, szóval ha ilyesmit fontolgatsz, nézd át az oldalt!
A Google szemszögéből bemutatva; kábé erre és néz, és innen, az én kamerám. |
Ha pont ezt a kamerát vennéd meg, akkor a következő lépéseket kell megtenni:
- bedugod a kamerát a laptopodba/PC-dbe egy UTP kábellel
- bedugod az adapterét az áramforrásba
- nyitsz egy Internet Explorer 8+-t, mivel a kezelőfelülete ActiveX-et használ, így ez megkerülhetetlen :(
- valószínűnek tartom, hogy WIN10 van a gépeden, így:
- a tálcán jobb-lent, ahol a kábeles/wifi jelecske van, azon jobb kattintás
- hálózati beállítások, vagy ilyesmi
- bal menüben kiválasztod az Ethernet pontot
- rányomsz a csatlakoztatott lehetőségre
- legörgetsz, az alján az IP-beállításoknál a szerkesztésre nyomsz
- átállítod a DHCP-t kézire, lenyomod az IPv4-et, és valami olyat produkálsz, mint a lista alatti képen van
- itt annyi a lényeg, hogy legyél közös alhálón a kamerával, ami default 0.168 végződésű, vagy 1.168, az utolsó előtti számjegyed legyen ugyanaz
- megnyitod az IE-ben a 192.168.0.168 címet (ha jó rémlik, ez volt a default, ha mégsem, akkor 1.168 a vége)
Ott pedig be tudsz lépni az alapértelmezett adatokkal, valami papíron tuti le van írva, vagy elsőre jelszót kell megadnod, ilyesmi.
Tök jó, hogy sok dolgot be lehet rajta állítani, először nem árt az IP címet átállítani arra, amit otthon amúgy is használsz, és ezután visszaállíthatod a saját IP-det is DHCP-re. Meg igazából ezután átdughatod a kábelt a gépedből a routerbe, úgyis eléred otthonról már a kamerát, IE-ből.
Valójában ez így már kész is, egy DDNS-t érdemes beállítani. A kamera beállításai közt tuti van ilyesmi, javasol is egyet, automatikusan frissíti ő magát a kábeles neten. Érdemes még kiszedni a videó-megtekintéshez való autentikációt, hogy a felvételt /ha nyilvánosnak van úgyis szánva/ azonnal megnyissa bármi, jelszó és egyéb nélkül.
Egy azonnali pillanatképet elérhetsz a kamerás cuccod elérhetőségén http-vel kezdve, majd útvonal szerint "/snap.jpg".
// ez persze eltérhet kameránként, de én ugye ezt a leírást ahhoz írom, amit mi rendeltünk.
No hát no, az Időképnek van saját leírása több is az oldalon, hogy oldd meg a képet.
Ehhez persze elengedhetetlen, hogy meg kell osztanod a kamera-eszközöd belső IP-jéhez a 80-as és az 554-es portot (az utóbbit csak akkor, ha live videót is akarsz engedélyezni). A port forwardnak könnyű utánajárni, én most Digi-s vagyok; nincs lehetőség port range megadására első ránézésre, DE a trükk az, hogy állíts be appnak bármit, akkor megjelenik a portszámok inputja, ahova írhatod őket, és utána akár vissza is állíthatod egyedire amúgy a radiobuttont.. (Mindegy, ez csak Digi-s extra help.)
De röviden a kamera beállításoknál az oldalukon megadod képletöltési linknek ezt a snap.jpg-t, live-nak meg megadhatod az rtsp://IPCIMED:554 címet nyugodt szívvel.
az IPCIMED helyére természetesen a külsőleg elérhető IPv4 címed kell, de persze érdemes DDNS-sel folyton frissítve tartani, és akkor az állandó átirányítási cím kell oda.
Ezzel valójában kész is, ezután automatikusan működik az időkép kamerád.
Az enyém itt érhető el egyébként:
https://www.idokep.hu/webkamera/eprog
Raknék ide egy pillanatképet róla, de ugye a HTTPS oldal nem szereti a HTTP contentet, és így hajnal 2-kor lusta vagyok valamivel leparseolni a képet, szóval majd máskor. Vagy kattints ide..
Végezetül egy csodás kép, hogy is sikerült elhelyezni a kamerát az erkélyen:
Edit:
Az első nap körülbelül 500 megtekintés volt a kamerán, és egyből kikerült ebbe a cikkbe.
Edit (2021-04-24):
Április elsején valószínűleg új szabályt hozott az Időkép, minimum méretre korlátozta a kameraképet, azalattiakat nem jelenít meg. Muszáj volt alkalmazkodni most már, hiába csinál kis snapshotot a 2 megapixeles kamera az 1-hez képest. Így most megoldódott az is, ugyanis most már a stream méretével megegyező képeket mentek. Röviden:
Hely:
Miskolc, Magyarország
OSM && Dévaványa 2020. január 2., csütörtök - 10:52
Úgy adódott, hogy már régi tervem, hogy random helyeket átültessek 3D-be, egy játékba, és most részben nekifogtam.
Mert amúgy tökre szeretnék egy GTA-t csinálni, ráadásul valós helyszínen játszódót. Legalábbis annyira, hogy az utak megegyezzenek a valóssal, és a főbb pontokon keresztülnézve egy arrafelé jártas ember, pl. aki az adott hely környékén lakik, az igenis tudja, hogy ha előre menne egy utcányit, akkor mit találna ott, és merre mehetne tovább, a játékon belül is, mint a valós helyen.
Az első ilyen célpont életemben Dévaványa volt, mert hát kicsi hely, és a lakhelyem volt 20 évig.
A nagy terveim félbeszakadtak, mikor Miskolcra felköltöztem, akkor inkább Miskolcot akartam már célnak kitűzni, és állandóan egész BP lebegett a szemem előtt, de az halál nagy feladat volna, bármilyen sok segítséggel is.
Szóval összességében egy játékmotort mégis Dévaványára érdemes építeni, esetleg egyszer, ha végtelen időm lesz, akkor nagyobb városokba is bele lehetne fogni.
Szóval itt újévi, hajnali merengésből nekifutva, sok random téma köszöntött bátyámmal. Volt régen egy GTA Vice City szervere, azon és a fennmaradt videóin röhögtünk, majd elkezdtem keresgélni.
Valamiért python 3D játékmotort, de nem találtam olyat, ami szimpi, csak a PyOgre-t, mert az Ogre-t régről ismerem a Game Maker-es portja miatt. Aztán dobtam az ötletet, végül az lett, hogy hát lehetne Unity3D. Mármint ha egy random, nem-találom-fel-újra-a-kereket típusú Vice City klón játékot akarok csinálni, miben fognék hozzá. A unity jó. Bénáztam vele kicsit, majd miután kész volt a TPS kameranézet, és irányítás: térkép kellene.
Netes leírásokból kiindulva a GTA VC térképét lehet exportálni modellként, csak haláli sok munka. Nekem erre nincs időm, és energiám. Annyiba kerülne, hogy nem éri meg.
És akkor jött: hát .. akkor újra Dévaványa? És nekifogtam.
Felcsaptam az OSM oldalát, és exportáltam Dévaványa területét valami XML formátumban.
Megnéztem az adatokat, és bedobtam a MySQL adatbázisomba egy egyszerű szerkezetet nekik, alakítgattam az adatokat látva. Majd közben írtam egy béna, de gyors és működő PHP parsert az XML-hez, ami a számomra lényeges node-okat beküldi a DB-be. Ez elég pöpecül sikerült is, néhányezer adat volt mindössze. Én csak a pontokat importáltam, meg a "way-eket", amik nem csak pontokat összekötő vonalak, hanem akár area-k is lehetnek (elvileg);
Erre közben összedobtam egy HTML5 megjelenítőt is, ami nagyjából jól működik, most elég királyul vonalakkal összeköt minden pontot a megfelelővel. Zsírul néz ki.
Ha minden egybetartozó vonalat random színezünk, akkor meg szépen elszeparálódnak a dolgok..
No mindegy. Ez csak ilyen érdekesség. Az OSM király! Ezekből a vektoros adatokból, szemben azzal, ha pl. Google térkép screenshotból generálnám, elég pontos 3D-s utakat tudok majd generálni modell formátumba; vagy ha azt épp nem, de a pálya minimális helyre tömörítve el fog férni, az utak adatait tárolva, amit így már bármilyen nekem tetsző módon kezelhetek, és realtime generálhatom a pályát az elmentett koordináták alapján. Majd egyszer.
Mert amúgy tökre szeretnék egy GTA-t csinálni, ráadásul valós helyszínen játszódót. Legalábbis annyira, hogy az utak megegyezzenek a valóssal, és a főbb pontokon keresztülnézve egy arrafelé jártas ember, pl. aki az adott hely környékén lakik, az igenis tudja, hogy ha előre menne egy utcányit, akkor mit találna ott, és merre mehetne tovább, a játékon belül is, mint a valós helyen.
Az első ilyen célpont életemben Dévaványa volt, mert hát kicsi hely, és a lakhelyem volt 20 évig.
A nagy terveim félbeszakadtak, mikor Miskolcra felköltöztem, akkor inkább Miskolcot akartam már célnak kitűzni, és állandóan egész BP lebegett a szemem előtt, de az halál nagy feladat volna, bármilyen sok segítséggel is.
Szóval összességében egy játékmotort mégis Dévaványára érdemes építeni, esetleg egyszer, ha végtelen időm lesz, akkor nagyobb városokba is bele lehetne fogni.
Szóval itt újévi, hajnali merengésből nekifutva, sok random téma köszöntött bátyámmal. Volt régen egy GTA Vice City szervere, azon és a fennmaradt videóin röhögtünk, majd elkezdtem keresgélni.
Valamiért python 3D játékmotort, de nem találtam olyat, ami szimpi, csak a PyOgre-t, mert az Ogre-t régről ismerem a Game Maker-es portja miatt. Aztán dobtam az ötletet, végül az lett, hogy hát lehetne Unity3D. Mármint ha egy random, nem-találom-fel-újra-a-kereket típusú Vice City klón játékot akarok csinálni, miben fognék hozzá. A unity jó. Bénáztam vele kicsit, majd miután kész volt a TPS kameranézet, és irányítás: térkép kellene.
Netes leírásokból kiindulva a GTA VC térképét lehet exportálni modellként, csak haláli sok munka. Nekem erre nincs időm, és energiám. Annyiba kerülne, hogy nem éri meg.
És akkor jött: hát .. akkor újra Dévaványa? És nekifogtam.
Felcsaptam az OSM oldalát, és exportáltam Dévaványa területét valami XML formátumban.
Megnéztem az adatokat, és bedobtam a MySQL adatbázisomba egy egyszerű szerkezetet nekik, alakítgattam az adatokat látva. Majd közben írtam egy béna, de gyors és működő PHP parsert az XML-hez, ami a számomra lényeges node-okat beküldi a DB-be. Ez elég pöpecül sikerült is, néhányezer adat volt mindössze. Én csak a pontokat importáltam, meg a "way-eket", amik nem csak pontokat összekötő vonalak, hanem akár area-k is lehetnek (elvileg);
Erre közben összedobtam egy HTML5 megjelenítőt is, ami nagyjából jól működik, most elég királyul vonalakkal összeköt minden pontot a megfelelővel. Zsírul néz ki.
Ha minden egybetartozó vonalat random színezünk, akkor meg szépen elszeparálódnak a dolgok..
No mindegy. Ez csak ilyen érdekesség. Az OSM király! Ezekből a vektoros adatokból, szemben azzal, ha pl. Google térkép screenshotból generálnám, elég pontos 3D-s utakat tudok majd generálni modell formátumba; vagy ha azt épp nem, de a pálya minimális helyre tömörítve el fog férni, az utak adatait tárolva, amit így már bármilyen nekem tetsző módon kezelhetek, és realtime generálhatom a pályát az elmentett koordináták alapján. Majd egyszer.
Címkék:
érdekesség,
internet,
javascript,
ötlet,
php,
programozás,
statisztika,
személyes,
városom
Excel Wolf3D 2020. január 1., szerda - 6:04
Valójában Google Sheet, a halál se használ Excelt ma már, nyilván.
Volt egy prog.hu-s cikk, amiben valaki csinált egy full 3d-s raycast cuccost, ami király.
Nem mostani a cikk, már jópár napos, de én most vettem észre, keresgélve. Aztán ez tényleg tök sok kedvet adott, hogy hát egy nagyon easy raytrace cuccot nem is lenne bonyolult még az én tudásommal sem összerakni egy ilyen táblázatkezelőben, hiszen csak pár vonal, koordináta, meg szögfüggvény kell hozzá.
Először csak hülyeségből kialakítottam neki egy felületet, de az ilyen dolgok mindig úgy berántanak, hogy nem tudom abbahagyni, míg valami látványos nem sikerül belőle a lehetőségekhez mérten.
Volt egy prog.hu-s cikk, amiben valaki csinált egy full 3d-s raycast cuccost, ami király.
Nem mostani a cikk, már jópár napos, de én most vettem észre, keresgélve. Aztán ez tényleg tök sok kedvet adott, hogy hát egy nagyon easy raytrace cuccot nem is lenne bonyolult még az én tudásommal sem összerakni egy ilyen táblázatkezelőben, hiszen csak pár vonal, koordináta, meg szögfüggvény kell hozzá.
Először csak hülyeségből kialakítottam neki egy felületet, de az ilyen dolgok mindig úgy berántanak, hogy nem tudom abbahagyni, míg valami látványos nem sikerül belőle a lehetőségekhez mérten.
Kellett hozzá végül valami szkript is, netes segítséggel meg is írtam. Mert akartam irányító nyilakat, de sajnos csak szkripttel oldható meg normálisan. Az is elég gáz, mert így folyton egy külső fájlt hívogat driveon keresztül, és gyáá.. Mi ez már.. Mindegy, a cél szentesíti az eszközt.
Szóval most egész tűrhetően kész is lett, egy kis videót is csináltam róla, egyszer majd talán folytatom, vagy befejezem, és publikálom is..
Címkék:
érdekesség,
Google,
internet,
ötlet,
programozás,
videó