Pues he probado la demo y me ha gustado, me recuerda al Elite dangerous, pero mas enfocado a la accion y no tanto a llevar mercancias XD.
 
Felicidades por el currazo que os estais pegando.

No tendras alguna variable llamada "Time" del tipo float???

Pues hechandole un ojo no llego a entenderlo, es decir.Veo que basicamente tiene dos formas de importar,AssetDownloader y AssetLoader.Y las dos tienen pinta de hacerse de manera asincrona,no pone nada pero al tener los tipicos onAssetLoader y demas pues es de suponer que si.Tambien supongo que la manera que no funciona en Holo es AssetDownloader,no veo porque no deberia,tampoco entiendo que en el editor una manera te vaya fina y la otra te provoque 4 segundos de paron.Por que a parte de la descarga de datos,el importar el modelo deberia ser igual asi que si en una se atasca en la otra tambien deberia.
 
Creo que lo mejor sera que envies un email al desarrollador haber que te dice,si hay manera de hacer que la manera fina funcione en Holo,que te asegure que la otra manera se hace de manera asincrona,podria entender que bajara el rendimiento del Holo, tienen poca potencia y importar Fbx puede ser caro,pero en el editor no se deberia atascar durante 4 segundos y si lo hace tendria que hacerlo de las dos maneras.Has probado con otro formato ,.obj es mucho mas barato p.ej,y con un objeto sencillo,un plano o un cubo,a ver si se atasca tambien.
 
En el peor de los casos si el proyecto te lo permite podrias considerar AssetBundles,te da mas posibilidades,aunque te restringe al tener que crearlos en el editor.
 
No se, no se puede decir mucho al ser un plugin.Haber si hay suerte y el desarrollador puede ayudarte.
 
 

Mmmhh con un plugin thirdParty por medio la cosa se oscurece ya que no sabes bien bien que esta haciendo y hay cosas que no sepueden hacer fuera del main thread.
 
Pero me extrañaria que la api del plugin no trajera un metodo para hacer una carga Async,como lo que ha puesto Igor de unity para assets pero propia de la api para los modelos.
 
Lo normal seria que la api tenga algun metodo LoadAsync/ImportAsync y algun callback onLoaded,onFinish,onFailed que te lance un metodo subscrito cuando acabe.
 
Mira en la doc de la api si hay algo parecido, o dejanos el link de la doc haber si lo vemos.
 

Buenas.
 
Antes que nada,no soy programador como tal, mas bien un pica-codigo,asi que no puedo darte una definicion tecnica de las coroutinas,pero un par de apuntes.
 
Las coroutinas no se ejecutan en un hilo a parte, se ejecutan en el mismo main thread,a menos que tu las lances desde otro thread,por lo tanto si una coroutina tiene que calcular mucho bloqueara el main thread como cualquier otro metodo/funcion.
 
Las coroutinas dijamos que son metodos/funciones que permiten hacer saltos de frame, si tu pones un
 
yield return null;
 
lo que hace es que a partir de ese punto,saltara/esperara hasta el siguiente frame y continuara con su ejecucion.
 
Luego tienes otras variantes como waitforsecons,waituntil... que hacen lo mismo,esperar al siguiente frame, en estos casos por tiempo o a que se cumpla una condicion,para que se siga ejecutando como un metodo/funcion cualquiera.
 
Quiero decir no son asinchronas por que si,es como si pudieras poner puntos de espera dentro del metodo/funcion.
 
Bueno como ves no es una explicacion muyy tecnica XD seguramente incorrecta incluso XD
 
Lo que tendrias que hacer es hacer la carga del modelo en un thread diferente,o en un job si estas con las ultimas versiones de unity.
 

StartCorutine(LoadObject);
LoadObject{
  EnableLoadWindow()
  LoadObjectThread()
  yield return waitUntil objectLoaded
  DisableLoadWindow()  
}

 
Espero se entienda este pseudo-pseudo-pseudo-codigo XD,seguro alguien nos da una explicacion mas tecnica y mejor), pero la idea es asi,tendras que buscar como se crea un thread/job en unity porque asi "a pelo" no recuerdo bien las palabras exactas para hacerlo. pero no era complicado
 
Un Saludo!

Pues he estado mirando videos y por como rodean algunos obstaculos ,unidades del mismo commander unas por la izquierda y las otras por la derecha para esquivar un coche,no parece que se libren de tener que calcular los path de las unidades.
 
Solo se me ocurre que al commander se le pasa la posicion deseada, el commander supongo hara un sphereCast de cierto radio para detectar los objetos cercanos,coberturas y tal,entonces segun los elementos que tenga en un radio de la posicion deseada el commander le pasa a las unidades las posiciones a las que tienen que ir cada una y estas se calculan su path.Si calculas los path en un job aparte para que no te saturen el hilo principal no creo que hubiera problemas de rendimiento por esta parte,tambien podrias ir metiendo solicitudes de calculo de path en alguna pool para asegurarte que no se calculan 100 en un mismo frame aunque seria mucha casualidad que todas las unidades calcularan el path a la vez.
 
Luego a las unidades les meteria un sphere trigger para que mientras recorren el path detecten ciertos elementos, compañeros por ejemplo para frenar un poco y que lo deje pasar,estos harian una llamada al commander y este decidiria cual frena teniendo en cuenta quien esta mas cerca del final del path para dejarlo pasar,o por si se cruzan una cobertura media o obstaculo pequeño que lo saltaran.
 
Si no solo quedaria coger algun tipo de offset desde la posicion del commander para cada unidad y que lo intentara mantener mientras recorren el unico path, con un sphere para detectar obstaculos y en tal caso hacer que vaya recortando el offset del el path calculado hasta que no encuentre el obstaculo.
 
Esto es como el all-i-oli XD,decirlo parece facil, a la que te pones te das cuenta de que no y que se ha cortado XD

Me uno al bando @lightbug
 
Lo primero que pense al ver que se editaban a parte los prefabs fue , POR FIN!!!!!. Siempre que tenia que tocar algo de algun prefab,y tenia que instanciarlo en medio de alguna escena,como no puedes acceder a sus nietos desde proyect window no quedaba otra, me tocaba la moral de mala manera,sieeeempre una vocecilla en mi cabeza que decia ***!
 
Ahora habra que mirar que funcione bien y no produzca mas desgracias que soluciones

Oh!! podrias utilizar el nuevo tandem jobs + ECS parece ideal para estos casos,i dont tested yet.Luego se me ocurre,depende del tipo de juego claro como siempre, podrias generar en el nivel algun octree(o simplemente un grid) de triggers, cuando un enemigo entre en algun trigger lo seteas como su commander.Entonces pues no se podrias hacer que los enemigos que esten en algun nodo vecino a el nodo que contenga al player calculen su propio path y sus cosas individualmente,mientras que los que esten en nodos mas lejanos calcular 1 path desde el nodo y pasarselo a los enemigos que contengan,o si estan muy lejos que no hagan nada.No se, si es un octree aun puedes ir despiezando mas los calculos segun la profundidad de este.Empiezas en la primera subdivision y segun vas bajando en el octree vas haciendo calculos,y vas viendo en que nodos hace falta bajar mas y hacer mas calculos.Seria como un arbol de commanders ,cada commander manda sobre sus commanders hijos,y el ultimo commander que calcule algo que mande sobre las unidades,como una jerarquia de mando,donde cada commander va delegando a sus descendientes como si fuera por quadrantes
 
El problema de commanders sueltos ,me parece, es que tendrias que estar controlando de ir metiendo a las unidades en su commander correspondiente,si se aleja una unidad por ejemplo,sacarla de uno y metarla en otro con otro grupo o dejarla sola,no se me parece lioso.
 
Otra cosa que suelo hacer,muy tipica seguro, es pares/impares, algunos enemigos hacen sus calculos de estado en los frames pares,y el resto en los impares.
 
Dolor de cabeza seguro que es , pero ahorraras bastante seguro, depende del tipo de juego claro.Lo he escrito asi pensando,no se si te encajara en lo que necesitas ,pero alomejor te sirve para amasar algo interesante,ya nos cuentas que estos temas siempre interesan.
 
Beers!!!

Buenas.Eso, 6 grados de libertad, osea poder rotar en todos los ejes,como dice Igor, normalmente los juegos rotan en 1 angulo,una camara en 3persona o un avion son 2, 3 es muy raro de ver, kerbal space ,el antiguo Descent,elite dangerous me vienen a la cabeza.No se como lo haran,aunque nunca se rota los 3 a la vez,asy que pueden adaptarse y cambiar el orden de rotacion de los ejes.Si fuera posible los animadores no tendrian dolores de cabeza con el gimbal,seguirian con sus xyz tan felices.
 
Si estas implementando tu propio ik, lo que buscas se llama ful lbody ik, no tiene mucho que ver con lo de rotar,eso tendria que calcularlo el solver del sistema segun lo configures en el momento.
 
Te lo habia puesto pensando que solo querias controlar un poco la rotacion para ajustarla,como el  personaje tampoco va a tener rotaciones tan exageradas en esos hueos,por ejemplo, en X hacia adelante a un puede llegar a 90 para atras mucho menos,en y la parte de los hombros si que puede llegar a los 80º la parte inferior muchisimo menos,en z lo que se puede rotar es minimo, no llegara a 45º la parte de arriba.Y estos limites siendo la suma de todos los huesos hasta el ultimo, no solo de uno.Por eso pense que alomejor te servia. Pero lo que quieres no tiene nada que ver.
 
He encontrado un par de links con codigo fuente de sistemas fbik,ue4 y unity
 
https://github.com/hacoo/rtik
 
https://github.com/Stereoarts/SAFullBodyIK
 
 
 
Aunque no tiene nada que ver con lo que buscas,alomejor a alguien le sirve.
 

constrained.rotation =  Quaternion.Euler( bendZ * constrained.forward ) * Quaternion.LookRotation(boss.position - boss.parent.position);

 
el boss,el cubo, tiene que estar en la misma posicion que su padre y adelantado en z 1 unidad. osea 0,0,1
 
Si movemos verticalmente el cubo rotara en x, si lo movemos horizontalmente rotara en y, z se rota con una variable independiente(podemos ponerle la z euler local del cubo).No hay que mover en z el cubo.
 
Da un poco de juego a la hora de controlar la animacion del personaje pero no tiene nada que ver con un sistema fullbodyik

Buenas,pues esa es la parte dificil,no se como lo hara unity internamente la verdad, lo veo dificil, en el momento que intentas controlar las rotacion con 3 variables encontraras gimbal,aunque lo hagas en quaternions,el orden en que se aplican las rotaciones siempre importa,,prueba a rotar desde el rotator handler en la scena 90z,90x ,luego partiendo otra vez del reposo hazlo al reves,90x,90z, el resultado es completamente diferente.Aparte el gimbal del editor engaña mucho crees que estas rotando en x,pero si miras inspector lo estas haciendo en z en verdad,Asi que creo que tampoco puedes guiarte mucho por el gimbal del editor.Un follon vamos, me dan caspa los quaternions vs eulers, cuando son 3 angulos a rotar. XD
 
Quizas algun modo de control picth(x),yaw(y),roll(z) te pueda servir o algun 6dof
 
Prueba asi haber si te sirve(ni 6dof ni nada), plantealo como si con x controlas la inclinacion hacia delante,con y el twist, con el z el bend,lo dijo porque si miras los vectores te puede chocar al ver que no coincide a cuando lo mueves con el handler,peor creo que alomejor te puede servir al ser un personaje.Basicamente hay un parent para el cubo donde controlaremos zx, en el cubo controlaremos y.
 

boss.parent.localRotation = Quaternion.identity;
boss.localRotation = Quaternion.identity;
constrained.localRotation = Quaternion.identity; 
boss.parent.localRotation = Quaternion.Euler(uler.x, 0f, uler.z);
boss.Rotate(Vector3.up,uler.y,Space.Self) ; 
Quaternion newOffset = Quaternion.Inverse(boss.rotation) * constrained.rotation;    
constrained.rotation = boss.rotation * offset;

 
a ver si hay suerte!!!
 

 
 

Cita de: lightbug date=1528504179ese no es Shift + F ?
   

Pues alomejor tambien XD yo siempre he usado ff,no se.
 
Otro
 
Shift + space ,poner la ventana en la que estemos a pantallo completa
 
ctrl+c,ctrl+v lo hago para pasar cosas de una escena a otra,rara vez pero a veces viene bien, si no siempre tiro tambien de ctrl + d
 
Hay uno que no recuerdo si lo soñe o que pero que no me sale nunca,y es el de ordenar listas desde el inspector.Si alguien sabe

FF, la camara de scene seguira al gameobject haya donde se mueva
 
ctrl+p play/stop
 
ctrl+alt+p pause
 

Buenas, pues podrias hacerlo con los animations events.A ver si consigo explicarlo.
 
Te creas una clase scriptableObject que contenga un dictionary<string,Sprite> (ya no recerdo si era sprite)
 
la key se utilizara de id ("attack01_front","attack02_front","attack03_front","attack01_back".........)
 
y tendra asignado cada sprite correspondiente como value
 
Te puedes crear tantos scriptables como personajes tengas,respetando siempre los id y solo cambiando los sprites.
 
Tonces
 
Te creas una classe con una variable para assignar el scriptableobject,el dictionary, del personaje que quieras.
 
Y una funcion con un string de entrada que sera el id.Esta funcion buscara el id en el dictionary del scriptable assignado,el cual nos devolvera el sprite correspondiente a esa id.A partir de ahi que la funcion haga el cambio de sprite donde toque.
 
Luego al  crear las animaciones las haces creando animation events que llamen a esa funcion pasandole el id del sprite que toca.
 
Cheers!
 
 

oh,los graficos me recuerdan mucho al interestate 76 XD Juegazo.
 
La primera, pega mas con la tipo de los botones y el estilo lo veo mas apropiado,a parte se me hace pequeño el titulo con la segunda
 
 

Eii buenas,esta vez si que me he mirado los videos .Mhhh esta dificil....,preguntas y consideraciones.
 
En el anterior video que rotas el cubo a traves del inspector y te sale el gimbal lock, fijate que si pones x 90,luego rotas desde la scene con el handler de rotacion en local el eje y,veras como unity automaticamente te corrige los ejes yz
 
Es decir x90y0z0 gimballlock yz ,pero x90y-90z-90 es exactamente la misma orientacion pero sin el problema del gimball.Cuando rotas desde la scena unity corrige el gimball,desde el inspector no se corrige.
 
Lo mismo te pasara si lo haces desde la variable eulerAngles que tienes en el scriptable.
 
La verdad que esta complicado de saber,pueden ser muchas cosas o varias a la vez,por ejemplo si algun padre del spine que no es padre del solver tiene rotacion durante la ejecucion,animacion o script,problema,ya que entonces el offset ya no seria el mismo que el inicial, y al estar asignando una rotacion(mejor dicho orientacion) global,el spine va a quedar bloqueado en esta orientacion global sin importarle que el padre rote, el siempre apuntara con esa orientacion mientras no cambie el offset

 

Se me ocurren algunas cosas, pero sin saber como funciona lo mas probable es que me equivoque y acabe liandote 
 
Mira lo de los padres del spine que no roten, y haz una prueba quitando lo del vector3 euler del scriptable y haz la rotacion directamente en el solver en la ventana scene.Haber si asi funciona.
 


Lo de los euler lo miramos despues,primero asegurarse que esta primera parte funciona y luego le buscamos otra manera a aplicar los euler.Quiza sacando los quaternions por separado y luego sumandolos a los otros,....... * offset * qx * qy * qz,pero eso luego,primero asegurarse que funciona la relacion solver/spine sin la variable euler del scriptable conduciendo al solver.
 
Un saludo.