BYDK: jak jsem ti psal do PM. Pokud to ma byt assetbundle per level, nemuselo by to byt az tak komplikovane, kdyz si vyresis pipelinu. Sranda zacina pozdeji u dependencies, shared resources a podobnych radosti. Ale per-level AB by mohl byt relativne simple...

Zjistil jsem vice. Od verze 5.X to vse funguje trochu jinak. Stary system jiz neni ani dostpny na asset storu. Take fixnuli neco s prenositelnosti ligtmap, ktera ve stare verzi pry nefungovali uplne dobre. Netusim co byl za problem. Funguje to tak, ze zabalim asset bundle pomoci jednoducheho API. A pak pres www clasu stahnu balicek a ten nasledne rozbalim, kdyz je vse stazene a dekodovane, mohu naloadovat scenu ci nove objekty. Vlastne je to dost simple. :) Otazka, jak to bude nakonec fungovat, ale nemel by tam byt problem.

asset bundly nebo SceneManager.LoadSceneAsync nebo jak se to.... melo by to nejak rozumne fungovat i ve webgl, teda v web pluginu to fungovalo (tam to teda jeste nebylo pres scene magar, ale application.LoadSceneAsync

BYDK: imho potrebujes rozbehat AssetBundly... GL&HF!

Ahoj, ma nekdo zkusenost s Level streamingem pro WebGL? Jednoduse receno stahne se mi prvni scena. A kdyz prechazim do dalsiho levelu, tak se mi stahnou dalsi data a naloaduje se level. ;)
Defakto nevim jak zacit... nejak bych tomu potreboval porozumnet.

urci si ty uhly sam podle pozice kloubu. imo by ti pro vetsinu pripadu mel bohate stacit Vector3.Angle. Pripadne 2d variantu jen v jedne rovine, ale tam by sis musel ty hodnoty ztransformovat, aby to odpovidalo (mela by stacit rotace kolem y, aby bylo spravne Z presne dopredu

GREATDRAKE: OK, zkusím to promyslet.. Ještě jednou díky!

GREATDRAKE: Ono to asi jinak moc nepůjde...
Ještě mě napadlo to počítat z pozic těch kloubů.
Nevíš, pod čím hledat tu funkci transformaci eulera? To by mohlo být nejrychlejší.
Jsem fakt v presu :-( A s prckem za zádama se čas hledá těžko.
Jak jsem psal, trošku jsem to neodhadnul :-(
Každopádně díky za pomoc...

NASA: ano eulerovské úhly jsou nepříjemné mmj v tom, že máš množství ekvivalencí (-90,0,90 bude další taková). A ano v takovém případě nechceš poměřovat to, co ti vypadne -- pokud si na těch číslech nezavedeš nějakou vhodnou fci, která to vždy převede na ekvivalentní složení rotací v tobě známém tvaru.

nápad (nedělní, odpolední, moc jsem tomu nedal :)) by byl ten, že s kostrou, kterou máš, spojíš jednoduché geometrické objekty - představ si, že máš na ruce "navlečený" rotační kužel uchycený na rameni. Ten virtuální kužel je právě tak tvarován, aby ti určil safe ergonomickou zónu. pohybuje se s daným kloubem protože je napojen na skeleton. A pak budeš sledovat kdy se kloub o jedna níže v hierarchii dostane vně ten kužel. (Samozřejmě, že to v praktickém provedení nebude asi kužel ale pro vizualizaci mi to přišlo nejlépe)

GREATDRAKE: No, to jsem také myslel, ale když z toho udělám euler axis, tak dochází k problém s rotacemi - například předpažení může být rotace (0, 90, 0) - dlaň směrem dolů, nebo taky (90, 180, 90) - dlaň otočená do strany.
V prvním případě mi úhel od svislého směru určuje y část, v druhém je to x.
Z tohoto se nemůžu vymotat.
Proto přemýšlím, jeslti nebude lepší udělat to přes ty pozice bodů. Ale také to tranformovat v řetězci.
Zkusím přidat obrázky...

NASA: No však - to co je v tom letáku je ideální užití lokálních rotací. Je ti jedno, jestli je pán předkloněn, či ne, když chceš jen jak má ruku ohnutou v lokti. Tam by ti prosté užití těch quaternionů mělo dát skorem okamžitě vždy to, co potřebuješ.

SHIGORBIRDMAN: Je to ergonomická analýza - normálně se to dělá ručně, ale mého vedoucího napadlo, že by to mělo jít dělat přes Kinect.
Prostě snímám nějakou činnost a když je třeba předpaženo víc, než nějaký úhel, tak je to ergonomicky špatně.
V podstatě elektronická verze tohoto:
http://ergo-plus.com/wp-content/uploads/RULA.pdf
+ ještě jedna analýza, ale princip je stejný - potřebuju úhel předpažení, předkonění, etc.
Figuru rozhýbanou Kinectem mám.

Taky si myslím, že to musí jít nějak jednoduše, ale asi jsem se v tom zamotal.
Já se přiznám, že v tom moc nedělám, c# se učím za běhu stejně tak Unity.
Moc nechápu ty quaterniony - převáděl jsem je na euler, ale to dělá problémy s těma rotacema.

NASA: ted uz jsem naprosto zmaten :) takze ty ty uhly uz mas jako quaterniony - tak v cem je problem? pokud jen potrebujes obecnou velikost uhlu, tak bud zjistit jak je definovany ten ktery uhel pro kterou kost (coz muze mit kazdy model nastaveno jak chce), pak preklopit quaternion na eulerovy uhly, nebo proste spocitat ten skalar mezi dvema vektory

v cem konkretne mas problem? pokud mas urcit uhel v kloubu, pokud mas souradnice kloubu a druhych koncu co je na nich, tak je to prachobycejny uhel mezi dvema primkami cili skalarni soucin, to je stredoskolska matematika.

Pokud s tim chces pak nejak manipulovat, tak kinematicky retezec proste nadefinujes maticove (uznavam ze to uz dneska asi sstredoskolska matematika neni, ale na diplomku bych cekal, ze jsi maticovy pocet uz nekde potkal), pripadne s ohledem na presnost radeji jako rotacni quaterniony a posun... Dopredna kinematika je primitivni. Zpetna kinematika je mnohem vetsi zabava.

Z toho co pises mi opravdu neni moc jasne co presne s tim chces delat... ze "snímám kinectem člověka podle úhlu kostí to počítá nějaké hodnoty." bych cekal ze jen potrebujes mit informace o tech uhlech

GREATDRAKE: Já mám model s kostrou, to je navázané na Kinect.
To funguje - úhly i pozice jednotlivých kloubů počítá ten skript pro Kinect.
Mám tedy kloub (joint) třeba Shoulder a pro něj mám quaternion s úhlem (lokální i globální) a pozici kloubu.
Teď mě napadá, že vlstně by mi síš mohl pomoci ten globální úhel. Lokální vychízí z předchozího kloubu.
Tím pádem při rotaci v ose o 180 st. je to všechno obráceně. Ale globálně by to mělo sedět.
Vlastně v tom zase hraje roli to, že když se ten člověk předkloní, tak se to musí přepočítat...
Grrr

Tohle umí (mimo jiné) ten skript ke Kinectu:
public Vector3 GetJointPosition(uint UserId, int joint)
public Vector3 GetJointLocalPosition(uint UserId, int joint)
public Quaternion GetJointOrientation(uint UserId, int joint, bool flip)
public Quaternion GetJointLocalOrientation(uint UserId, int joint, bool flip)

NASA: tohle se standardně řeší násobením matic. Brát to takhle, tak se z toho brzo zblázníš :)

Máš jednu matici pro paňácu, která určuje jeho pozici a rotaci v globálních koordinátech. A pak pro každý kloub, se kterým chceš pracovat používáš matici určující relativní pozici a rotaci daného kloubu v lokálních koordinátech. Tedy skelet, se kterým hýbeš máš podobně udělaný "skelet" z matic a toho jak jsou na sebe závislé.
Tzn. když máš matici pro rameno a matici pro loket a zápěstí - stačí ti pak pronásobit tu matici kosti ramení a pohneš si celou rukou (neb v těch zbylých dvou už je jen relativní posun a relativní rotace loket vs rameno a zápěstí vs loket.

Ta matematika za tím (jak udělat transformační matici z eulerovo úhlů a vektoru, případně jak to celé převádět na quaterniony) není triviální, ale zas je na to už celkem dost knihoven tam venku.

Sakra, ono to bude ještě horší - stejně moc nevím, jak z toho dostat ty polohy...
Potřebuju třeba levou ruku, že je předpažená v úhlu 40 stupňů (0 je ruka volně dolů).
Nebo že je pravá ruka upažená vodorovně (90 stupňů).
Pak úhel v lokti asi tímhle výpočtem. Zápěstí - další prekérka :-(
Netušíte pls někdo?
Napadlo mě udělat fiktivní roviny, do kterých budu promítat ty vektory a z toho to spočítám,
ale teď se mi to v hlavě motá, jdu si udělat 3D model ze sirek :-)
Kdyby někdo tušil - googlil jsem až moc, ale asi blbě...