ty math utilities jsou na pohled celkem pekny :) kdyz vidim ten vizualizer minkowskeho sumy a gjk a vzpominam si, jak jsem to pred mnoha lety sam rval do vlastniho enginu a dost si trhal vlasy, aby to nejak fungovalo.... to bych tenkrat hodne ocenil jako referenci :)

BYDK: Jasny, nasypal jsem to taky jen tak z patra s tim, ze se muze nekomu hodit. Budu rad i za dalsi zdroje...

Našel by se zde ochotný programátor, který by měl chuť v unity udělal výzkumný obchod.
Jedná se asi celkem o 260 řádků obsahujících až 7 údajů pro 10 objektů.
Více v poště.
Díky.

BYDK:
JAACOB:
SHIGORBIRDMAN:

to dava smysl, diky moc

rucni vypocet bude v podstate delat uplne presne to same - zjisteni relativni pozice a rotace vuci prvnimu hristi (cili transformace z world do hriste local space) a pak zpetne transformovat z local noveho hriste do world space.

pokud z nejakeho duvodu nemuze byt hrac v hierarchii a nechce se ti pocitat, muzes pouzit prasarnu s nejakym dummy objektem, ktery budes parentovat misto nej a pro hrace zkopirujes jeho world pos / rot

FREELA: v tomhle pripade mi prijde nejjednodussi, jak uz bylo receno (a pokud to teda muzes udelat), opravdu parentnout hrace na to hriste a pak mu proste jen nastavoval localpos a localrot podle libosti relativne vuci hristi. cili pred spawnem dalsiho hriste si vzit localpos / localrot a po spawnu dalsiho je proste pouzit

FREELA: jestli ti jde jen o rotace v ose Y, teoreticky by ti pro to mely stacit euler angles. Zjisti si eulerY prvniho hriste, eulerY prvniho hrace, udelej mezi nima rozdil (relativni natoceni hrace ke hristi) a pak u druheho hriste otoc noveho hrace stejne relativne k eulerY druheho hriste... To je takove polopaticke.

Pak me napada, za predpokladu, ze by hrac byl v hierarchii primo pod hristem, pouzit transform.localRotation, coz by mela byt relativni rotace vzhledem k parentovi - tedy po spawnu noveho hriste by melo stacit predat novemu hraci stejnou hodnotu local rotation.

Da se to ale resit i primo pres quaterniony, akorat v tom mam dodneska trochu bordel, tak ted mozna budu placat: Mam pocit, ze odectenim dvou quaternionu dostavas relativni rotaci, kterou pak muzes vynasobit jinej quaternion (mozna jeho Quaternion.Inverse hodnotu?) a melo by si to sednout. Ale tohle ted taham trochu z paty. Vim, ze jsem s tema operacema vzdycky chvilku valcil a ve finale zjistil, ze je na to, co potrebuju, nejakej daleko jednodussi postup...

BYDK: Vector3.Distance pouzivam, ale ted mi to nestaci. Zkusim to jeste rozepsat...

Na mape mam fotbalove hriste a to presne vodorovne (leva branka zapad/ prava vychod). Postavim hrace od stredu 3 metry na jih a 4 metry na zapad.

Nasledne spawnuju dalsi hriste, ktere je ale jinde na mape a o 45° clockwise otocene. A ted bych mel podle udaju z toho prvniho hriste zas postavit hrace na stejnou pozici.

FREELA: Jestli to chapu dobre, muzes si ty transformace parentnout. Pak se ti bude zobrazovat to co chces i s rotaci, vzdalenosti. Pohoda. :) Pripadne distance vypocitas: https://docs.unity3d.com/ScriptReference/Vector3.Distance.html

Jeden zacatecnicky dotaz:

Na mape mam bod A (Vector3, Quaternion) a bod B (Vector3, Quaternion)
Potreboval bych vypocitat distance tak, aby se po wipe mapy, na ktere se zobrazi nekde jinde opet a v jine rotaci bod A, zobrazil automaticky bod B a to i natoceny stejnym smerem vuci bodu A.

SHIGORBIRDMAN: Chápu, tak snad to nějak dopadne v rámci možností dobře.
I když někdy by nějaká ta rozumná čistka asi nebyla úplně na škodu. Biť by to bylo bolestné, ale pokud by to mělo pak ušetřit v nějakém rozumném horizontu nervy a lépe a jednoduššeji fungovat nezlobil bych se.

ROLAND: problemy s enginy vzdycky jsou a budou, proste je to velky kus softwaru... ktery si za sebou vetsinou tahne spoustu legacy potizi. Software psany a prepisovany a predelavany pres dvacet let (coz v podsatte plati jak pro unreal, tak uz myslim i pro unity), ktery nebude mit sve potize, to proste imo nejde.

Jak unrealu, tak unity by pomohlo udelat nejaky velky skrt a cistku, ale to si samozrejme netroufnou, uz tak je vsichni proklinaji za pomale upravy a deprekovani opravdu starych a spatnych veci. Unity musim uznat, ze po chaosu a potizich s prechodem na 5 vypada, ze prece jen pomalu nekam kraci a nejen cestou oblibenou drivejsi, koupime nejaky middleware, narveme ho tam, a stare potize ignorujeme. Ale mozna to rikam proto, ze jsem nikdy nezkousel delat neco vetsiho nez mikropokusy s 2017+, protoze pracovne jsem byl nenavratne zaseknuty na suicidal combo 4 & 5

ROLAND: unreal je jeste porad tvrde fixovany "engine na dalsi unreal tournament / gears of war" - spousta legacy veci tam porad zustava (ne ze by unity a legacy veci nebyly problemy, byt pomalicku nasledky toho, ze to kdysi byla puvodne javascriptova sracka mizi). Unity ma problemy s vykonem a pameti, o streamovani nemluve, byt uz je to mnohem lepsi nez byvalo, takze velke open world veci se na nem delaji mimoradne blbe.

Jednorazove demo udelas na unity stejne hezke jako na unrealu s trochou snahy, a mozna se ti i bude hybat :) Velke obrovske aaaargh svety... mozna ze jednou konecne ten garbage collector vyhodi :) (fun fact, unity pro hololens problem nema, protoze bezi na standardnim mrkvim...)

Ale teď jsem si znovu pročetl to tvé story ohledně Unrealu a říkám si jestli některé ty problémy v těch enginech nesouvisí spíše s Windows nebo s OS.
Pokud tedy nepracuješ v Linuxu.
A nebo se nám brzo samozrodí nějaké to AI. ;)

SHIGORBIRDMAN: Ano díky, naštestí mám vesmír, takže jako tam by se to mohlo nějak ztratit. A pořád doufám že půjde rozumě škálovat měnit nějak rozměry a z 30 km pak lehce udělat 3x3km apod.

To s těmi kolizemi se musím zeptat programátora, ale opět naštěstí hra je primitivní, takže nebude vadit moc překrytí. Ale to poskakování by mohlo možná nastat při větším počtu lodí. Ale tak zase snažím se aby ty modely lodí měli málo polygonů a aby to pak pokud možno šlo transportovat na mobilní zařízení. Teď jsem to zatím vypustil.

NaN se už přihodilo u věžiček.

Já tak mám ještě stále loknuté že android a zjednodušeně řečeno na malé či menší věci a Unreal na FPS a open world. I když popravdě ted netuším jak to je. Co jsem viděl to jedno demo v tom lese v Unity tak moc hezké, otázka zní jak by v tom fungovala hra a na jakém HW by to bylo schopno tak běžet.

ROLAND: 30 kilaku x 30 kilaku, realisticke vzdalenosti a rychlosti budou problem. vzdalenost 30 kilometru od nuly uz ti muze vyvolavat viditelne potize kvuli floatum (trepani veci - u dead effectu jsme kvuli tomu museli presouvat vsechny levely rozumne do nuly, protoze pokud byl level par kilaku od nuly, vznikaly viditelne artefakty). vyzkousej, uvidis, ale pocitej s tim, ze problemy se muzou vyskytovat. hlavne nezapomenout na vsechny rychle veci nastavit continuous dynamic detekce kolizi - jinak ti lod klidne proleti jinou lodi a i terenem (pokud to neni standardni heightmap teren z unity, ktery je ale dost nepouzitelny) - nebo dostane pri reseni kolize nesmyslne velke hodnoty, roztoci se ti a rozpadne, nebo dokonce rovnou zmizi, protoze nekde proleze infinity nebo NaN.

Ad Unreal - viz ten elaborat, co jsem tu psal driv. Jsou veci, ve kterych je unreal viditelne a nekdy i citelne lepsi nebo aspon jsou, kdezto v unity je to napis si sam / kup si middleware a doufej ze bude pouzitelny (vykon, garbage collector, polyformni serializace, takze neni potreba resit slozitejsi data externe pres json/xml, multiplayer, ktery je ted v unity hodne spatny, streamovani...). Ale spousta veci je fakt mnohem horsi. Rvani si vlasu kvuli problemu zpusobeny nejakym black magic deep inside byly v unity caste, ale u unrealu mas jedno jedine plus - mas zdrojaky a hypoteticky si to muzes najit a opravit sam (good luck). Zazdene potize, obsolete veci, veci co najednou nefungujou, stare postupy nalezene na answers, ktere uz ale dva tri roky neplati, i oficialni rady a samply, ktere nefunguji... je i v unrealu.



Pricetny engine... uz chut psat si (zase) vlastni znamena, ze se projevuje moje nepricetnost :D Udelat rozumnou fyziku, na tom jsem zabil hezkych par mesicu, prestoze jsem to delal maximalne primitivnim zpusobem, aby to fungovalo rozumne rychle a ne uplne blbe - a pak jsem zacal delat s unity a zjistil, ze physx je taky impulse based a dela uplne stejne picoviny jako to moje :D

(defakto jediny duvod, proc s tim uz zase koketuju je to, ze neexistuje engine, co by umel veci, ktere bych na jeden svuj experimentik potreboval... jinak bych si celkem s jistotou hral s unity, protoze afaik porad neexistuje lepsi system na rychle iterovani a programatorske experimenty)

SHIGORBIRDMAN: Sakryš, to si mě nepotěšil. Ale díky ti.
Já totiž objekty nechal grafika dělat v metrech aby pak bylo i nějak řekněme snašší možné měřítkové škálování objektů. A tak jsem chtěl i nějakou řekněme realistickou rychlost objektů. Takže k mému nespokojení to budu muset zkrátka nějak nafejkovat a budu muset odhadnout.

A tak si nejsem jist jestli jsem neudělal trochu blbost s tím že hrací prostor bude mít velikost asi 30km x 30km. No uvidíme snad mě programátor nezabije.

SHIGORBIRDMAN: Počkat Unreal je také nějak moc špatný? Jako moc bugů než by se dalo řekněme s nějakou tou lehkostí překonat. A ne si při tom rvát vlasy? Jako v Unity jsme před pár lety narazili na problém co byl znám podle dotazu 3 roky tehdy a nikdo jej neopravil. Takže ta věc se pak řešila jinak.

Tak jestli se ti povede příčetný engine, tak prosím ať je možné operovat s fyzikou a aby objekty mohly se pohybovat rychlostí i třeba rychlostí světla. ;)
No a také nějaké fine uživatelské rozhraní a logické ovládání. ;)