Városi úthálózat procedurális generálása
2014-05-27T10:55:49+02:00
2014-07-05T18:49:50+02:00
2022-06-29T14:51:29+02:00
  • Ez 8 éve volt :D http://x.pgy.hu/~worm/het/progress/terr17.jpg
    De nyilvan 1 google utan siman levagod, hogy mi az a forgovaz.
    En azt irigylem bennetek meg **G**-ban, hogy ertitek azt a sok krixkraxor a linkjén -> Runge-Kutta methods - Wikipedia, the free encyclopedia
    Nekem hu de sokat kene tanuljnom, hogy felfogjam a levezetest lol. Pedig regen a foiskolai matekot en ugy csinaltam meg, hogy 1-es, hianyzik, 1-es, hianyzik, tanul, 5-os :D

    Ha meg egysikuak a ház modellek, akkor meg szedjel valami regi jatekbol. En pl. az MSTS pályaelemeit lopkodtam meg a magyar MSTS modellezoknek a fantasztikusan elethu modelljeit. Nagyon inspiralo ha valamit programozol es az grafikailag is jol nez ki :D
    Mutasd a teljes hozzászólást!
  • Köszönöm a biztatást!
    Nem tudtam mi az a forgóváz, ki kellett gugliznom, :) de így már értem, hogy mit csináltál. Kár, hogy abbamaradt. A lengéscsillapító amúgy nálam is egyszerű függőleges csillapított rugó lesz első körben, de aztán valszeg beteszek oldalirányú rugót is, csak ahhoz jobban utána kell nézzek a lengéscsillapítóknak.
    Mutasd a teljes hozzászólást!
  • Szep hobby projekt, en drukkolok, hogy csinaljad :D

    Regen az en vasut-sim-emben odaig sikerult eljutnom, hogy 2 forgovazra rugalmas felfuggesztessel felraktam a mozdony kasztniját. A forgivazak egyszerusiteskent csak egyszeruen tapadtak a sinre.

    A forgovazak folott egy felfele iranyulo kepzeletbeli vektort szimulaltam. A vektor vegpontjahoz es orientaciojuk atlagahoz illesztettem rugalmasan (sima csillapitott rugó szimulacio) a kasztnit. Teljesen fake volt, de jol nezett ki es 'belul ulve' is allat volt :D

    Az integralas reszhez meg a fejemben az az otlet kering, hogy lehet, hogy ezek a modszerek barmilyen valtozo dt -re jol mukodnek, de en inkabb konstans minimalis dt-vel csinalnam: Mondjuk 200hz-vel szimulalnam a jelenetet, a kirajzolaskor pedig egy picit elore-szimulalnek es linearis interpolacioval nyerném ki a halal-pontos megjelenitesi poziciot.
    Ez amolyan atmenet lenne a vegtelen kis dt -vel szamolt tokeletes mozgas es az osszevisza dt mellett is 'elmeletileg tokeletesen' mukodo modszerek kozott.

    Na de hajrá! Es varom a screenshotokat :D
    Mutasd a teljes hozzászólást!
  • Lehet. A kuplungot amúgy nem azért akarom szimulálni, hogy feltétlenül a user irányítsa, csak hogy még akár ha a számítógép csinálja is a váltásokat, akkor is a megfelelőek legyenek a gyorsulások, motor fordulatszámok és a motrohang magassága.

    Van egy matematikai kézikönyvem, amiben a minap nézegettem az Euler-nél jobb integrálási módszereket, de nem mélyedtem el bennük nagyon. A linken lévő tutorial a runge kutta-ról nagyon jónak tűnik, köszi!
    Mutasd a teljes hozzászólást!
  • Köszi. Ha jól látom nincs részletezve, hogy pontosan hogyan számol a kuplunggal. Estimate módban valami iterációkat csinál, ami hasonló lehet az én 2 iterációmhoz. De ez alapjan lehet, hogy tovább tudok guglizni.

    Elméleti szempontból az én megoldásomban az a problémás, hogy direkt csak 3 testre van kihegyezve, amelyek 2 súrlódási erővel vannak összekötve. Egyből adódik a kérdés, hogy mi a megoldás N darab (N-1 súrlódási erővel csatolt) testre? Valósznűleg N iterációt kell kiátlagolni valahogy... De szerencsére erre az autószimulátorban nincs szükség (remélhetőleg a differenciálmű nem kavar majd be, előzetesen úgy sejtem, hogy egy szabadon futó differenciálműnél nincsenek ilyen problémák, esetleg egy limited slip diffeerenciálműnél igen, mert ott megint súrlódás van a két tengely között...)
    Mutasd a teljes hozzászólást!
  • Gondolom többek között azért nincs sok anyag a kuplungról, mert gondoltak a pedállal nem rendelkező játékosokra. Billentyűzeten nehéz csúsztatni a kuplungot :)
    Így az esetek nagyon nagy részében egy sima on-off kuplung elég, ha egyáltalán van kuplung implementálva :)

    Ahogy nézem sima Euler-t használsz integráláshoz. Én lehet RK4-et használnék. Pontosabb :)
    Gyorsan rákeresve ez egy normális cikk-nek tűnik első pillanatásra
    Integration Basics - gafferongames.com
    Mutasd a teljes hozzászólást!
  • Kivancsi lennek a profik hogyan csinaljak a kuplung valosaghu modellezeset.

    Ezt találtam most:

    PhysX Vehicle SDK
    Vehicles - NVIDIA PhysX SDK Documentation
    Mutasd a teljes hozzászólást!
  • Kihekkeltem a kuplung problemat. Kivancsi lennek a profik hogyan csinaljak a kuplung valosaghu modellezeset. Azokban a leirasokban amit en olvastam nem jutottak el a kuplungig, forumokon meg csak kuzdest, meg valosagtol nagyon elrugaszkodott leegyszerusitesre valo javaslatot olvastam. Itt a step fuggvenyem az elozoleg irt 3. iteracio vegen. Szep sima minden, nincs alternalas:

    void CarPhysics::step(float dt) { // Engine schaft torques and acceleration float engineDriveTorque = engineModel.calcTorque(engineAngVel, throttle); float engShaftClutchTorque = calcClutchTorque(dt, engineAngVel, tireAngVel); float engineSumTorque = engineDriveTorque - engShaftClutchTorque; float engineAngAcc = engineSumTorque / engineMomentOfInertia; // Tire schaft torques and acceleration float forceSlip, torqueSlip; calcSlipForceAndTorque(dt, forceSlip, torqueSlip); float tireSumTorque = engShaftClutchTorque*gearRatio + torqueSlip; float tireAngAcc = tireSumTorque / tireMomentOfInertia; // Clutch hack: // With the traditional approach, because of the clutch friction-coupling // engine drive is counter-forced with the tire slip force only in the next step. // This leads to big alternations in clutch torque (e.g.: 500, -500, 500, -500). // We hack it this way: calculating what the engine and tire angular velocities would be at the end of this step, // we calculate what the clutch torque would be next step, and recalculate the current torque as the average of the currently calculated torque // and this next would-be torque. After that we recalculate everything depending on it. engShaftClutchTorque = (engShaftClutchTorque + calcClutchTorque(dt, engineAngVel + engineAngAcc * dt, tireAngVel + tireAngAcc * dt)) / 2.0f; engineSumTorque = engineDriveTorque - engShaftClutchTorque; engineAngAcc = engineSumTorque / engineMomentOfInertia; tireSumTorque = engShaftClutchTorque*gearRatio + torqueSlip; tireAngAcc = tireSumTorque / tireMomentOfInertia; // Car forces and acceleration float sumForce = forceSlip; float acceleration = sumForce / weight; std::cout << "ct: " << engShaftClutchTorque << " et: " << engineSumTorque << " eav:" << engineAngVel << " tav:" << tireAngVel << std::endl; // ********* Calculate velocities *************** carVel += acceleration * dt; engineAngVel += engineAngAcc * dt; tireAngVel += tireAngAcc * dt; // ********** Calculate positions ************ carPosition += carVel * dt; }
    Mutasd a teljes hozzászólást!
  • Eleg jol halad a varos generalas, de minden epulet unalmas betontomb meg, es az utakon sincs meg szinte semmi, screenshotokat majd kesobb rakok be, amikor mar erdekesebbet tudok mutatni.

    1 hete az auto mechanikai szimulaciojaval foglalkozom.
    Ha barki ilyesmit akar csinalni, akkor miutan utanaolvasgatott, erosen javaslom, hogy leegyszerusitett modellbol fokozatosan fejlesztve csinalja, mert egyebkent elsore annyi lesz benne a hiba, hogy az ember azt se tudja, hova kapjon. Nekem ugy tunik bevalik a kovetkezo lepesekre bontani (minden pont utan erosen kitesztelem):

    (Egyelore az oszes pontnal sik terepen vagyunk es nem foglalkozunk utkozesekkel.)

    1. Eloszor az autonak csak 1 kereke van, nincs kormany, nincs fek, nincs kupung, nincs sebessegvalto (a motor kozvetlen hajtja az egy kereket) az auto gyakorlatilag pontszeru test. Ami van: gazpedal, motor rpm/torque gorbe, kerek Pacejka surlodasi modell. Mar itt jonni fognak a problemak a surlodas numerikus integralasanak stabilizalasaval.
    2. Van sbssegvalto
    3. Van kuplung. Ez nagyon nagy szivas, ha kicsit is realisztikusak vagyunk. Itt a kuplung miatt a motor, a kerek es a fold 3 szegmens, amik csak surlodasi eron keresztul kapcsolodnak, ami mar komolyabb stablitasi problema a numerikus integralasnak. Nem is stabilizaltam meg rendesen, alternal egy kicsit a kerek szogsebessege, de van egy jo otletem, amivel este stabilizalom.
    4. Van fek
    5. Van gordulesi surlodas es legellenallas
    6. Vegre ket kerek van, elso es hatso, az auto mar 2 dimenzios (oldalnezets auto), mar van felfuggesztes es sulypont elore hatra tolodas fekezeskor, gyorsitaskor.
    7. Negy kerek van, az auto 3D-s, van kormanyzas, differencialmu, a kerek Pacejka surlodasi modellje a slip angle-t is kezeli.

    Erdekes tema, kar,hogy kicsit amator vagyok hozza, de majd csak kialakulnak a dolgok.
    Mutasd a teljes hozzászólást!
  • Ahogy ígértem csatolok egy .svg-t, amit a koncentrikus körös topológia torzításával értem el.

    Amiket változtattam:
    - A kör szektoronként ki van lapítva
    - A kerületek trapézainak csúcsai véletlenszerűen el vannak mozgatva
    - 7%-a (állítható) az utaknak ki van törölve
    - A szektorok egy részében (egy sugáron kívül) a nem főútvonalas csomópontok pozíciójára zaj van modulálva (a közelderékszög constraint betartatásával...)

    Messze nem olyan, mint amit egy szofisztikált úthálózat generátor fog majd generálni, de v0.1-es verziónak most egyelőre elmegy, amivel már elkezdhetem fejleszteni a ráépülő városgenerálást.
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Mármint a kályhához, nem?

    Ööö, igazából nem a szólás tartalmi részét akartam megragadni

    A kaptafa itt egy "terep" adta sajátosság amire fuzzy logikai szabályokkal (+ némi véletlen) ráépítesz egy településhálózatot! De mint már látom, Te is kétlépcsősre csinálod.

    Például egy útnak van minimum szélessége, egy teleknek minimum mérete, egy útkereszteződésnek típusa, ilyesmikre gondolok.

    Tervezek én is játékot, várossal de még tervezési szinten sincs kész (van egy kész város alap, és annyi!)
    Mutasd a teljes hozzászólást!
  • Mondjuk van erre is van ellenpélda. pl. Brazíliaváros, ami tervezőasztalon született kifejezetten az autós közlekedést figyelembe véve.

    Ez akkor sem élvezhetett abszolút prioritást - hiszen az abszolút prioritást mindig a fizikai törvények és gazdasági korlátok képezik. Amik egy játék esetében azonban ebben a formában gyakorlatilag nem léteznek.

    Ráadásul egy úthálózatnak mindig tömegeket és ezzel együtt széles igényeket kell kiszolgálnia - amiből egyben következik az is, hogy valójában senki igényeit nem fogja tudni tökéletesen kielégíteni, hanem mindenkinek valamilyen közös, kompromisszumos megoldást kínál. Ezzel szemben egy játék által generált pálya tökéletesen illeszkedhet az adott játékos egyedi igényeihez és sajátosságaihoz is, lehet tökéletesen személyre szabott is.

    Stb.
    Mutasd a teljes hozzászólást!
  • "

    Nem lehet, hogy a bejárható városok generálása helyett google map adataiból letöltött térképekkel jobb eredményeket érhetnél el, mint generált városokkal?

    "

    Ki fog ez alakulni ha kitartok, és sokáig fejlesztem a programot, valszeg egyre jobban fogom tudni, hogy mit generáljak, hogy hasznos legyen a szoftver, és könnyen lehet hogy valós adatokat is használok majd.

    "

    de gyorsan rájöttem, hogy túlságosan komplex programra lenne szükség, hogy valós helyzetekhez közeli szituációkat tudjak létrehozni.

    "

    Én is régen dédelgetem ezt az ötletet, én amiatt nem kezdtem bele soha, mert úgy éreztem, hogy a monitor mögül való vezetés nem tanít eléggé a valódi vezetésre. Viszont most, hogy jön az Oculus Rift, a user úgy érzi, hogy tényleg ott ül az autóban. Hirtelen kinézhet a baloldali ablakon, vagy hátra nézhet, a holttér ugyanott van mint a valóságban, a tükröket ugyanúgy használhatja mint a valóságban (ugyanolyan szögben kell fordítania a fejét). NEm hiszem, hogy egy valós autóssiskolai oktatáson annyira extra forgalmi helyzetek kerülnének elő, sőt a szimuláció előnye, hogy tesztelni lehet a nagyon veszélyes, ritka helyzeteket (mások hibája, nagyon csúszós út, stb...)

    "

    Illetve tervezel-e bele bénán vagy szabálytalanul vezető bot-okat?

    "

    Szerintem mindenképpen érdemes ilyeneket beletenni oktatási céllal (esetleg kikapcsolhatóan).
    Mutasd a teljes hozzászólást!
  • Mondjuk van erre is van ellenpélda. pl. Brazíliaváros, ami tervezőasztalon született kifejezetten az autós közlekedést figyelembe véve.

    Origo - "Mintha egy másik bolygón járnál" - jubilál a vonalzóval húzott főváros

    A hivataloknak és minisztériumoknak szánt várost a mérnökök autós közlekedésre alakították ki, a számításokba nem kalkulálták bele a leendő lakók szociális igényeit. Például, hogy az emberek szeretnek sétálgatni az utcákon és szívesen jönnek össze a sarki kocsmákban. "Autó nélkül egyszerűen sehova sem jut el az ember, és a buszhálózat is főleg csak a főbb tengelyeket fedi le. Nincsenek sajátos hangulatú összefüggő negyedek, ezért lehetetlen például kocsmatúrázni. Ha bulizni megy az ember, akkor célirányosan indul egy bárba" - írta az [origo]-nak brazíliavárosi tapasztalatairól egy fiatal nő, aki 2009-ben fél évet élt a városban.
    Mutasd a teljes hozzászólást!
  • Nem lehet, hogy a bejárható városok generálása helyett google map adataiból letöltött térképekkel jobb eredményeket érhetnél el, mint generált városokkal? A különböző játékokban is a legjobbak a "kézzel készített" pályák.

    Ez mondjuk szerintem két különböző dolog. A valós városi utakat az eredeti földrajzi adottságok, a történelmi fejlődés, valamint a gazdasági igények és a pénzügyi racionalizmus alakította - ezek képezték a meghatározó prioritásokat a megépítésük során. Az, hogy vezetés milyen élményt képezett rajtuk, csak sokadlagos résztényező volt.

    Ezzel szemben egy játékban a pálya minőségét az adott játék fizikája, stílusa és pontrendszere határozzák meg - az lesz a legjobb pálya, amit a legmagasabb szintű játékélményt nyújta az adott paraméterek mellett. A klasszikus gazdasági korlátozó faktorok pedig (ti. hogy milyen minőségű anyagból készüljön, milyen széles legyen, mennyire legyen girbe-gurba vagy éppen egyenes) nem, illetve csak mint a játékélménynek alárendelt faktorok léteznek.

    A fentiekből eredően egy játékban valószínűleg nagyon nem produkálnának jó eredményeket (játékélményt) a való életből vett úthálózatok. Kivéve ha ennek célja a valóság minél jobb utánzása lenne, beleértve az ezzel járó minden bosszantó hátrányt is (pl. Dugószimulátor 2014). Persze egy ilyen játéknak meg nem lenne sok értelme, ill. nem lenne értelme játéknak hívni.
    Mutasd a teljes hozzászólást!
  • Én is eljátszottam már többször is egy KRESZ oktató program gondolatával, de gyorsan rájöttem, hogy túlságosan komplex programra lenne szükség, hogy valós helyzetekhez közeli szituációkat tudjak létrehozni. 

    Nem lehet, hogy a bejárható városok generálása helyett google map adataiból letöltött térképekkel jobb eredményeket érhetnél el, mint generált városokkal? A különböző játékokban is a legjobbak a "kézzel készített" pályák.

    Illetve tervezel-e bele bénán vagy szabálytalanul vezető bot-okat?
    Mutasd a teljes hozzászólást!
  • "

    Tervezel valamiféle közlekedési rendszert is, lámpákat, jelző táblákat?

    "

    Persze, ez tulajdonképpen egy vezetés oktató szoftver lesz, a lényeg, hogy lehet közlekedni egy szimulált városban, szimulált forgalomban (pl. lesznek feladatok, hogy juss el A-ból B-be, vagy lehet szabadon csavarogni), és a rendszer folyamatosan jelzi neked az általad elkövetett kisebb nagyobb KRESZ vétségeket. (A projekt kódneve: 'Traffic Experience')

    A road network generátor kimenete egy síkbarajzolható gráf (azt exportáltam .svg-be). A következő modul az, ami ebből valódi út geometriát csinál (utak pontos szélessége, kereszteződések pontos geometriája centiméter pontossággal, sávok, úton lévő felfestések generálása, egyirányúság, elsőbbségadás és az azokat jelző táblák generálása, jelzőlámpák rendszere, parkolók, megállni tilos táblák, stb...) Akkor akarom csak nagyon kifinomulttá tenni a road network generátoromat, amikor ezzel a modullal is előrébb leszek: fontos constraint, hogy ez a modul milyen road-network kereszteződéseket tud lekezelni (jelenlegi tudásom szerint ez előszőr csak a nem elfajult szögben lévő 4-ágú, a 3-ágú T kereszteződéseket, és a szinte tetszőleges kereszteződéseket támogatja körforgalommal, de ez utóbbiból nem lehet sok.)

    Egyébként a végső cél az lenne, hogy a user megmondhatná, hogy melyik ország KRESZ-e szerint szeretné a városát generálni. Nem teljesen elrugaszkodott dolog a világ országainak nagy részét támogatni, mert van néhány nagy flavour (amerikai, európai) még azok is hasonlóak, és azokon belül már nagyon picik az eltérések. Az első verzió mindenesetre egyetlen KRESZ-t fog támogatni. A nagy piac miatt USA-ra esett a választásom. Az USA-ban persze minden államnak saját KRESZ-e van (ezek eltérése nagyon pici). Egy olyan államot választottam, aminek könnyen megtaláltam a neten a KRESZ-ét: Massachusetts:

    Driver's Manual
    Ezt behatóan tanulmányoztam.

    Emiatt egyébként a generált épületek is elsősorban a Boston MA -ban lévő épületekre fognak hajazni (a felhőkarcolóktól a családi házakig). Iszonyúan nagy segítség, hogy a google street view-val részletesen tanulmányozhatom Boston utcáit és épületeit.

    Amúgy első körben egyetlen város lesz csak, de később több várost generálok majd, és köztük lesz autópálya is, és akkor majd lehet generálni ilyan kereszteződéseket:

    Interchange (road) - Wikipedia, the free encyclopedia

    Pl. a multi-level stack interchange-ek odaba...nak :)

    File:Viaduct in Puxi, Shanghai.jpg - Wikipedia, the free encyclopedia
    Mutasd a teljes hozzászólást!
  • Talán célszerű lenne egy létező topológiából ( hegyek, folyók, dombok, szigetek, partszakasz )  kiindulva kiválasztani egy városközpontot és a topológiának megfelelő úthálózatot generálni. Körforgalmakkal, hidakkal, felüljárókkal. 

    Tervezel valamiféle közlekedési rendszert is, lámpákat, jelző táblákat?
    Mutasd a teljes hozzászólást!
  • Hú egy ilyen "városban" közlekedni igazi rémálom lenne, főleg ha a házak között se lenne sok eltérés, kb. sohase tudnád hol is vagy.
    Mutasd a teljes hozzászólást!
  • Na, generáltam "informatikus úthálózatot"  (Tökéletesen szabályos 8 szektoros 64-1 gyűrűs sugár-körgyűrű topológiájú úthálózat. (Olyan 60 métert kell elképzelni a szomszédos gyűrűk között, a vastag utak értelemszerűen vastagabb vonallal vannak jelezve.) Remélem minden programozó szívét melengeti a 2 hatványok harmóniája  (a sugárutak 2 hatványoknál duplázódnak...))
    Csatoltam a generált .svg-t (.zipbe pakolva).

    Namost ahogy írtam, ebbből a betegesen szabályos térképből indulva, az alaptopológiát megtartva geometriai torzításokkal, és apró topológiai változtatásokkal megnézzük, hogy miket lehet kihozni pár óra munkával... Még a hétvégén csatolom a torzított térképeket.
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Az egész projekt C++.
    Néhány helyen kell a performancia (grafikához, sok autó útvonalszámításához, mozgatásához) illetve a real-time-ness (grafikához), vagyis a garbage collector miatti megtorpanások hiánya.
    Persze, pontosan még nem tudom, hogy melyik részek lesznek igazán performancia kritikusak (a grafikát kivéve, az mindenképpen az), meg sok mindent meg lehetne oldani más nyelveken is, és főleg keverhetném a nyelveket, de én az egyszerűség kedvéért mindent C++-ban írok.
    A C++-nak vannak hátrányai és előnyei, a hátrányok közül a legnagyobb, hogy nehéz rendesen megtanulni, de szerencsére ez már nálam nem játszik, már jól ismerem. (Lehet, hogy perverz dolog, de még szeretem is (pl. a const kulcsszót régen csak nyűgnek tartottam, ma már szeretem.))
    Igazából ennek a projectnek a sikere nem a nyelven fog múlni.
    Egyébként a projektnek egyelőre sok lib dependencyje sincs, csak grafikára az OpenGL 4, néhány OpenGL util lib (glew, glfw), assimp (Open Asset Import Library) (grafikai assetek importálása a saját formátumomba, amit a mini grafikai engine-em eszik), fizikára  a Bullet (csak terv, még nem integráltam, nem tartok ott), és az Oculus SDK (Oculus Rift nélkül is fog futni, de az igazi élmény Oculus Rift-el lesz.)
    Mutasd a teljes hozzászólást!
  • Milyen programnyelvben fejleszted az úthálózat generátort ?
    Mutasd a teljes hozzászólást!
  • OFF, schedulálódik OMG! Magyarítsuk, legyen inkább szkedzsölálódik.
    Mutasd a teljes hozzászólást!
  • "

    Menjünk vissza a kaptafához, azaz hogyan alakulnak ki a települések!

    "

    OFF
    Mármint a kályhához, nem? A kaptafához visszatérést arra mondják, ha valaki újra olyasmit csinál, amit már sokszor csinált, ahelyett, hogy új utakat fedezne fel.
    ON

    Ja, az igazi egy jó organikus modell lenne, bár eszementen sokáig tartana jól megcsinálni.
    Egyébként a város életének dinamikus modellezésénél is azt a filozófiát követem, hogy először legyen egy egyszerű modell, amit később lehet továbbfejleszteni.
    A város autósai úgy lesznek modellezve, hogy minden 24 óra elején generálódik nekik egy schedule, ami egy lista: mikor, hova induljanak el. Amikor valahova eljutottak, ott a közelben leparkolnak, majd parkolva várják, hogy a következő schedulált indulásuk eljöjjön. A schedule-ok generálása egyszerű: mindenkinek
    van egy otthoni címe, ide küldi őket a schedulejuk a legtöbb este. Hétköznapokon reggelente legtöbbször egy commercial-ipari negyedbe küldi őket a schedule, de kisebb eséllyel máshova is, meg kisebb eséllyel éjszaka is schedulálódik ilyesmi (lényeg, hogy kisebb egyenletes forgalom szinte mindig lesz, és hogy a nagy trendek tényleg érződjenek (reggeli, délutáni csúcsforgalom, stb...)).
    A gyalogosokat is hasonlóan modellezem majd. Mivel egyelőre tömegközlekedés nem lesz, első körben vagy csalok azzal, hogy épületen belülről hazateleportálódnak :), vagy kicsit szofisztikáltabban bemennek egy metrólejáróba (amibe a szimulátorból nem lehet belátni, és tulképp egy delayed teleportációval modellezem a metrón való utazást :))
    Szal' csak egyszerűen, de azért amellett kitartok, hogy minden szereplő pozíciója egyedileg nyilván legyen tartva. (A fun kedvéért lehet, hogy nevet is generálok nekik, az utcáknak pl. biztosan generálok nevet, az fontos a szimulációhoz is.)
    Mutasd a teljes hozzászólást!
  • Menjünk vissza a kaptafához, azaz hogyan alakulnak ki a települések!

    Képzelj el egy házat amely egy vízforrástól (patak, tó, csermely, forrás, kút) ahol pár haszonállat tartásából élnek az emberek, egy kis legelő a közelben. Egy ilyen település a tanya, amely egy zsákutcába végződik.
    A tanya (hapcienda) fejlődik, lesz még több épület, nagyobb állattartó rész. A fejlődés az bevezető út irányától függ, és a lakóépületek mellé vagy attól kissé távol.
    A bevezető út nem elég, az utat továbbviszik (folytatják). Ez általában elkerülő útként viselkedik, a településen nem megy át, hanem közvetlen mellette halad el.
    A betelepülők az út másik oldalán alapítanak maguknak férőhelyet.
    Megjelenik a fix épület, pl. fogadó, kocsma, templom. Ezek sokáig fenn fognak maradni (település jellemzőek lesznek), míg a lakóépületek nem!
    Több betelepülő jön, 1) az úttól nem messze alapít; 2) a település közelében alapít, azaz megjelennek az utak!
    A település fejlődésével a központi rész átalakul, megjelennek a szolgáltató részek (kisiparosok), a lakóövezet pedig a szélre húzódik!
    A sok ház, ipar és egyéb épületek annyira felszaporodnak, hogy egy "központi" irányítást követel meg, azaz megjelenik a település város szerkezeti arca (polgármester).
    A kezdeti településszerkezet elavult, a felsőbb döntéshozó szerv alakítja át a város szerkezetét. Ez házbontásokkal, telkek méretének meghatározásával, építési tilalommal jár.
    Az úthálózat (jellemzően) jelentős terhelés alá esik, a vezetés nagyobb átmenő kapacitásra épít át pár (főutat).
    Megjelenik az ingatlan értéke, a házakat már fix telekárban, ingatlanértékkel számítják. Ettől a telkek feldarabolódnak (a legkisebb fix értékre), konzerválódnak az utak.
    A fejlődés megállíthatatlan, az épületek elkezdenek felfelé nőni! Elkezdődik a városmag preferálása, és ez nem feltétlenül a kezdeti település lesz!
    Az egyéni közlekedés feltorlódása miatt megjelenik a tömegközlekedés (felszíni).
    A "külterületi" részeken speciális városfejlesztés jön létre (szennyvíz, ipar, külváros).
    Az utak fejlesztése akadályokba ütközik, házbontások, kisajátítások jönnek (ha előrelátó a városvezetés eleve kijelölte az átmenő forgalom számára az út helyét).

    Innentől úgy változik a város, hogy az utak (általában) nem változnak meg. Te pedig ezt a "végeredményt" akarod procedurálisan meghatározni!

    A domborzati tényezőket még nem is említettem!
    Mutasd a teljes hozzászólást!
  • Köszi, ezeket még nem láttam. Hú, az első forrása nem kicsi.


    "

    Miután a felhasználó elindította a programot, vagy előre legenerálnál 10 pályát és jónapot. Ha utóbbi, akkor érdemes ezzel futni egy kört, különben szerintem nem.

    "

    Hát ez még képlékeny, az első a minimum amit szeretnék, de jó lenne ha a felhasználó is generálhatna magának szerintem, szerintem sokan örülnének egy teljesen saját városnak. :)
    Mutasd a teljes hozzászólást!
  • Köszi a hozzászólást. Jó ötlet a 2-nél több szintű rekurzió, és a paraméterek a rekurzió aktuális állapotától függő változtatása. A berácsozáson alapuló megoldás valóban nagyon primitív, de baseline verziónak érdemes lefejleszteni, mert annyira egyszerű, és amíg egy szofisztikáltabb módszer nincsen kész, addig is lehet a többi modult fejleszteni. A berácsozás azért olyan egyszerű, mert az az egyetlen megoldás, ami nem szenved a 'mit csináljunk ezzel a nem túl szerencsés alakú maradék területtel', ami minden más módszernél előjön ha nem vigyázunk. Végleges verziónak a rácsozgatás persze tarthatatlan.
    Mutasd a teljes hozzászólást!
  • Na futottam még egy kört a kereséssel és találtam ezt a projectet:

    Interactive Procedural Street Modeling

    Ehhez van forráskód is. Visual Studio, C++ és MFC-vel készlt. 3 megányi forráskód van ott + leírás.

    Itt a forráskód:
    http://www.sci.utah.edu/~chengu/street/streetmodeling.zip


    Mondjuk a végeredmény kicsit művi, de annyira nem is rossz.

    Nézegetve a forráskódot, hááát... Kell hozzá bátorság, hogy kirakja az ember valami éles rendszerbe. Jobban belegondolva, hogy akarod ezt az út generálást, mármint mikor? Miután a felhasználó elindította a programot, vagy előre legenerálnál 10 pályát és jónapot. Ha utóbbi, akkor érdemes ezzel futni egy kört, különben szerintem nem.


    Közben találtam egy másikat, ahhoz is van source:

    Ben Wu - CG Artist

    forráskód:
    wenbu/CityGenerator

    Itt van videó róla:
    Demo Reel
    Mutasd a teljes hozzászólást!
  • Én rekurzív/iteratív finomító módszerrel állnék neki. Tehát először kialakítanám a legfőbb, legnagyobb forgalmú, legszélesebb útvonalakat, amik felosztanák a területet kisebb régiókra. Aztán ezeken belül alakítanék ki kisebb, de még mindig kvázi nagy forgalmú utakat, amik szintén kisebb régiókra osztanák a megmaradt szegmenseket. Ezeken belül pedig még kisebb forgalmú utakat alakítanék ki.

    Persze a rekurzió mélységétől függően eltérő paraméterekkel kellene a generálást megoldani. A nagyobb utaknak nyilván területarányosan ritkábbaknak és hosszabbaknak kellene lenniük, de lehetnének bennük eleve törések és nagyobb ívek is. A kisebb utak értelemszerűen sűrűbben lehetnének és rövidebbek is, viszont törést nem és íveket is csak ritkán tartalmazhatnának.

    Az utakat - a legelső szintet leszámítva - értelemszerűen mindig úgy kellene generálni, hogy már meglévő utak között jöjjenek létre és azokat egymással nem túl éles szögben kössék össze. Ahol ez nem lehetséges, ott nyilván nem ill. kis valószínűséggel alakítunk ki utakat. (Kivéve ha akarsz zsákutcákat is, amik egyik végpontja a semmi közepén, a már meglévő utak közötti régiókban is végződhetne.)

    Ezen kívül a generálás során arra is oda kell figyelni, hogy már meglévő kereszteződésekbe (értsd: olyan pontokba, ahol már fut be egy alsóbb rendű út egy magasabba) is nagyobb eséllyel végződtessük az újonnan generált, azonos vagy maximum egy szinttel lejjebb vagy feljebb lévő utakat, és kisebb eséllyel fusson be az új út két már meglévő kereszteződés (becsatlakozás) közé.

    A szóban forgó valószínűségek és peremfeltételek (pl. egymást keresztező utak által bezárt minimális és maximális szög, az egyes szinteken az utak minimális és maximális hosszúságával, sűrűségével) lehet az adott terület stílusát, jellegét szabályozni. (Pl. ipartelep, lakótelep, üzleti negyed, agglomeráció, stb.)

    Nagyon fontos a valószínűségek használata, hogy ti. a meghatározott kvázi ideális feltételektől (pl. az adott szegmenstípusra jellemző átlagos utcahossztól vagy a 90 fokos becsatlakozási szögtől) eltérő, ill. távol eső variánsok generálására is megengedett legyen (egy bizonyos határig), de egyre csökkenő valószínűséggel. Ez biztosítja majd a változatosságot és a "tökéletlenséget" anélkül, hogy a szegmens alapjellege megváltozhatna, a meghatározottól alapvetően eltérővé válhatna.

    Mindenesetre a lényeg, hogy szerintem nem "berácsozni" kell a területet valamilyen minta (négyzetrács, sugaras rács, stb.) alapján - ahogy én azt a korábbi javaslatokból kivettem, hogy ti. azok így működnének -, kvázi egyként kezelve a teljes területet (vagy legfeljebb pár kisebb szegmensre bontva azt, amik azonban megint csak teljes egészükben berácsozásra kerülnének), hiszen az utakat sem így építik, alakítják ki a valóságban. Illetve legfeljebb csak a tudatosan, egyben megépített lakó- vagy ipari parkokban.  Amik száma és területe azonban a világ legnagyobb részében elenyésző a szervesen fejlődő területekéhez képest.
    Mutasd a teljes hozzászólást!
  • Valóban nincs értelme ebbe a részfeladatba most túl sok energiát ölni, a nagyon valósághű úthálózatot egy ideig hanyagolom.
    Azért hogy legyen már most is valami fully procedurálisan generált a topicbeli ötletekből levonva is, a következőt valósítom meg most pár nap alatt:

    - Sugárutas- körutas topológia. Logikailag gyűrűkre, azokon belül szektorokra bontva. Egy gyűrű egy kb. trapéz alakú szektora, amit kerületnek is hívhatunk, már egyszerű grid topológia (a.k.a Manhattan style).
    - Ha megvan ez a biztos alap topológia, ezt a változatosság elérése miatt egy csomó paraméterrel megbolondíthatjuk: Szektorok száma, szektorok eltérő szögei, sugarak eltérő mérete miatt körtől jelentősen eltérő geometria, kerületek topológiájának megtartása, de a csúcsok elmozdítása, bizonyos kerületekben a belső grid pontok offsetelése (bizonyos constraintek betartásával), bizonyos gridpontok törlése, néhol a grid négyzetekbe átlók behúzása: minden olyan lépés, ami biztosan nem rontja el a már kész várost, de csökkenti a szabályosságot.

    Egy ilyet 'olcsón' pár nap alatt, mindenféle rizikó nélkül le fogok fejleszteni, majd felrakom az így generált térképet ide is (.svg-be generálom), aztán megyek tovább a következő részfeladatokra.
    Mutasd a teljes hozzászólást!
Címkék
abcd