SHIGORBIRDMAN: Jono, to stary ui sem chvili zazil a uz tam sme radsi pouzivali nGui(to delal tusim ten typ co jim pomahal s tim soucasnym?) takze jak odiky bohu aspon za to co tam je ted urcite.

Jinak on v tom videu tvrdi ze to UI bude jeden drawcall vzdy coz mi vhledem k tomu ze to cpes vlastnima assetama kteray se na jeden atlas casto nevejdou pokud mas vic UI trochu smrdi... no nevim zkusim si v tom nejaky slozitejsi UI posladat a podivam se co to ve skutecnosti dela treba na mobilu)

jeden draw call mozna dosahnou (pokud to je vubec mozne, cili atlasovane textury), ale bojim se, ze dynamicke zmeny budou vykonove jeste brutalnejsi peklo nez u soucasneho ui, kde muzes aspon optimalizovat rucne a pouzivat pooly atd...
(ja to puvodne chapal ze to ma byt, KONECNE, nahrada editoroveho ui, ktere ma sice vyhodu extra rychleho masteni nejakych zakladnich tlacitek, ale vykon je osklivy)

SHIGORBIRDMAN: jasne no, to je muj nejvetsi otaznik asi, kdyz rikaji ze bude cely UI jeden drawcall tak me zajima co bude stat ten jeden drawcall vygenerovat.

ale zas si rikam ze by predelali kompletne cely UI od zakladu a udelali z toho nejaku pazravou vec v momente kdy performance je jedna z veci co dostavaj nejvic sezrat a evidentne se snazej s tim neco pomalu ale jiste udelat?

U 3rd party xml based UI se nedivim ze to bylo v prdeli protoze takovouhle 3d party vec imho neudelas bez brutalniho overheadu?

(je samozrejme mozny, ze nejakym kouzlem ten perf nebude zly, minimalne pro slozitejsi editory to bude super, protoze imgui a tabulka s par stovkama polozek... ehm..., ale fakt bych se toho hodne bal, po dlouholetych zkusenostech s tim, jak unity nektere veci bastli hlava nehlava...)

JAACOB: Nn muzes to animovat normalne z kodu, bud pres jejich predpripravenou funkcionalitu, ale zaroven kazdej UI element ma svoji c# reprezentaci kterou muzes animovat z kodu jak te napadne, kdyz na to budes chtit napojit animator tak muzes taky, ale tomu je stejne dobry se vetsinou vyhnout uz ve stavajicim UI.Co se particlu a sandwichovani 3D/2D tyce tak tam o tom mluvi, ale to jeste asi uplne dotazeny nemaj, typek se tam psal presne na to samy co pises a dostal trochu mlzivou odpoved - evidentne to uz ted nejak jde ale asi to bude zatim podobnej voprc jako se soucasnym UI, Nicmene to scalovani/flex UI podle gameobjectu a zpet to vypada ze maj vyreseny celkem dobre, ale to sem zatim nezkousel.

PTSD z web developmentu mam taky takze trochu chapu, na druhou stranu jestli nekde uz zkousej dost dlouho jak rozumnym zpusobem popsat layout a vizualni props UIcka tak je to tam a soucasny unity UI je v porovnani s tim fakt tragicky. Ale je to teda vyhra asi hlavne pro lidi co to UIcko sazej no:)

me teda hlavne zajima jak se to UIcko vlastne rendruje a pocita kdyz je nakonec jeden panel jeden drawcall, aby sme soucasny bottle necky UIcka ktery uz zname nevymenili za jiny novy bottle necky jinde ktery budou mozna ve finale vetsi vopruz. No nejaky bolehlavy budou urcite, to se nebojim:)

je novy junity jenom prezentacka a nic neni implementovany jak ma?

Ja mam osobne nejvetsi strach z provazani s kodem, ruznyma animacema a souzitim se zbytkem gameobjektu. V prednasce zminujou nejaky support pro tweening (nevim, jestli jsem to pochopil tak, ze to bude definice animacek primo v tom jejich USS podobne jak to podporuje web anebo jestli budem kodem ridit upravy toho USS?). Pak by me zajimalo jak dobre to bude fungovat pri vrstveni a nasledne hierarchii. Treba ted jsem resil neco, kdy pouzivam particly uprostred UI a hakoval jsem to pres sorting layery (background vespod, particly pres, front UI buttony apod. nad tim vsim). No a nakonec - kdyz bude treba rekneme vyresit inventar, kde bude muset byt nejakej flex container kolem spousty itemu, pritom ty childy budou muset byt 3D gameobjekty, u nich stitky v nejakych sub UI a ted budes muset resit, aby se ti treba parent scaloval podle rozlozeni a velikosti childu, ale protoze kombis gamobjekty a UI, tak jak se vyresi ta navaznost mezi master parentem a tema childama, kdyz to v ramci gameobjekt hierarchie bude muset byt rozvrstvene...

Jako vypada to na demu hezky, ale jeste z toho taky asi vyplyne dost bolehlavu. :)

To mam stejne a nakonec pokud to bude litat, mi to prijde vic namiste v runtime nez v editoru.

Pro nejaky editor okna to je ok, ale doufam ze to nespadne do toho ze si kazdej autor (i internich) component udela custom inspektor UI po svym, protoze to najednou jde. Ne ze by to neslo v imGUI ale drzi to nejakou kulturu. Poprve me vydesilo i okno "services" kdyz jsem tam cuchal nejakej embedlej webview nebo co to vlastne je a proc to vypada jak vypada.

jj, mam pocit ze ze zacatku platilo, ze pokud se ten operator pouzil u unityobject, ze to mohlo v nekterych pripadech hodit uz neplatny. netusim, jestli to unity pak nejak doresilo...

jj, to retezeni je uzitecne - kod je pak kompaktnejsi. ja si to teda jeste furt nezvykl pouzivat. mimo jine proto, ze jsem donedavna obcas brousil v prehistorickem unity a pristi tyden do nej zas budu strkat nos

SHIGORBIRDMAN: ah. prave som sa pozrel na null propagation a nie je to celkom to iste!

ide o to ze pouzitim "?" operatora sa da dosiahnut to ze sa checkovanie zastavi hned pri prvom neexistujucom clene toho retazca. Cize hned to vyhodnoti ako null, bez toho aby vyhodilo chyby na dalsich castiach hierarchie objektov ktore tiez nebudu pritomne na neexistujucom objeckte.

cize :
var teacherName = classroom?.GetTeacher()?.Name;
// teacherName is null if GetTeacher() returns null OR classroom is null

co som si pri tomto teraz vsimol (a vyzera uzitocne) je ?? operator. Sprava sa velmi podobne ako trinarny, ale netreba tam davat explicitne tu podmienku (myVar == null) ? "hodnota ked je null" : "hodnota ked nie je";

var teacherName = classroom?.GetTeacher()?.Name ?? "No Name";
// teacherName will be "No Name" when GetTeacher()
// returns null OR classroom is null OR Name is null