Jump to content

hammer

Registrados
  • Content Count

    220
  • Joined

  • Last visited

  • Days Won

    14

Everything posted by hammer

  1. 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.
  2. No tendras alguna variable llamada "Time" del tipo float???
  3. 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.
  4. 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. :)
  5. 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. :P pero no era complicado Un Saludo!
  6. 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
  7. 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 WTF! Ahora habra que mirar que funcione bien y no produzca mas desgracias que soluciones :D
  8. 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 ;D,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 :D 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 :D, pero ahorraras bastante seguro, depende del tipo de juego claro.Lo he escrito asi pensando,no se si te encajara en lo que necesitas :D,pero alomejor te sirve para amasar algo interesante,ya nos cuentas que estos temas siempre interesan. Beers!!!
  9. 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
  10. 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!!! :)
  11. Pues alomejor tambien XD yo siempre he usado ff,no se. Otro Shift + space ,poner la ventana en la que estemos a pantallo completa :D 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 :)
  12. FF, la camara de scene seguira al gameobject haya donde se mueva ctrl+p play/stop ctrl+alt+p pause :D
  13. 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!
  14. 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
  15. 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.
  16. Gimbal Lock, hasta el apolo 13 tuvo problemas con el. Basicamente las rotaciones por eule se aplican una a una en ciierto orden y por separado, en este caso es xyz(unity no deja cambiarlo),entonces.......como no se me ocurre como explicarlo te dejo un video(no he encontrado en español,aunque me extraña que no haya) y un ejemplo para que puedas reproducirlo en Unity para poder verlo bien y se entiende a la primera. Puedes hacer la prueba, crea 3 planos uno para cada eje(ponle su color correspondiente son solo para que se vea la idea), pon cada plano con su normal apuntando en su eje, un plano para x donde su normal apunte en la misma direcion que el eje X,otra para y ,otro para z.Luego crea 3 gameobjects vacios y emparentalos uno detras de otro y dentro de cada uno emparentas el plano que le corresponda(no se pueden utilizar los planos ya que al posicionarlos ya no partiriamos de r:0,0,0 que queden asi:(los planos son solo para ayuda visual -x(vacio rotacion 0 , 0 ,0) --planoX --y(vacio rotacion 0 , 0 ,0) --planoX ---z(vacio rotacion 0 , 0 ,0) --planoX Ahora prueba a rotar el objecto, y ,en el eje y(el gameobject vacio) en el inspector y veras como se reproduce el problema. Esto no tiene solucion,es asi,no hay mas.Cada año miles de riggers y animadores se suicidan por culpa del gimbal lock.Y es la razon por la que se utilizan Quaternions para representar rotaciones en el espacio. Como lo has implementado?? porque se supone que haciendolo con quaternions no deberias encontrarte este problema.Tambien es posible que segun que jerarquia padres/hijos tengas y como la estes rotando estes reproduciendo el error como hemos hecho con el ejemplo. :) edit el ejemplo estaba mal, no recordaba que unity no deja resetear rotations,estaba pensando en maya :)
  17. Buenas!!Otra forma con quaternions. Calculas el offset que hay entre las dos rotaciones Luego a la rotacion del que manda le aplicas el offset. https://docs.unity3d.com/ScriptReference/Quaternion-operator_multiply.html Mind Blow!!! public Transform boss; public Transform constrained; private Quaternion offset; public void OnEnable() { offset = Quaternion.Inverse(boss.rotation) * constrained.rotation; } public void Update() { constrained.rotation = boss.rotation * offset; } :)
  18. Pues con huesos solo se me ocurre hacer como un Grid de huesos independientes,hacerles un constraint a su posicion correspondiente de la maya,hacer una simulacion de cloth y bakear la posicion de los huesos.Luego esos huesos les haces un el skinning con un mesh sin animacion. Asi tendrias la animacion del pliegue/despliege hecha con los huesos, y los huesos libres por si quieren hacer algo par darle una deformacion extra. Ahora si no se van a utilizar los huesos "inGame" yo lo plantearia de otra manera,que dara mejores resultados y consumira practicamente lo mismo,o incluso menos. Tochete is coming!!! La animacion del pliegue/despliegue pues la haria directamente en blender con cloth,la bakearia y la importaria en unity como meshAnimation/vertexAnimation(o como se diga).Puede parecer que esto consuma mucho, pero todo lo contrario, piensa que por ejemplo en la era de la play2 solo los juegos punteros como doom3/halfLife2 utilizaban huesos porque consumian muchos recursos,en la mayoria usaban vertexAnimations en los personajes que podian tener cientos de animaciones y mas de 5000 polygonos.Tu solo necesitarias dos,la del pliegue y la del despliegue,y una bandera de 5000 polygonos tendria una animacion muy buena que no conseguiras con huesos a menos que usaras un grid de huesos muy grande. Esto para el pliegue/despliegue, para controlar la potencia del viento cuando sopla a favor de la vela pues con un blendShape para la potencia que lo controlas con alguna variable de direccion del viento. Y por ultimo para simular las pequeñas turbulencias,pues atraves de un shader con alguna textura noise animada deformas un pelin los vertexs,puedes pasarle al shader tambien la variable que marque la direccion del viento y asi mover la textura noise que simula las tarbulencias hacia la derecha o la izquierda dependiendo de por donde venga el aire. Para evitar que las turbulencias afecten en los anclajes de la vela pintas algun canal de los vertexColors para controlar cuanto le afectan,0 en los anclajes superiores 0.5 en los inferiores que van mas sueltos y en el resto de la maya a 1. Asi te podria quedar una vela que consuma muuuyy poco,muy realista y con bastante control. Pliegue/despliegue---VertexAnimations de una animacion bakeada en blender potencia aire--blendshape + direccion del viento turbulencias-- shader moviendo un noise con la direccion del viento A menos que los huesos se quieran utilizar ingame para algo,me parece que esta opcion es muchissimo mejor. Cheers.
  19. Holas!!! no puedes rotar las uvs?? es mas barato seguro en texturas grandes y no te tienes que pelear con arrays, lo puede haces por script o mejor aun si puedes por shader que seria lo mas rapido. public void RotateUVs(float radians) { MeshFilter mf = this.GetComponent<MeshFilter>(); Vector2[] uv = mf.mesh.uv; float c = Mathf.Cos(radians); float s = Mathf.Sin(radians); Vector2[] rotMatrix = new Vector2[2]; rotMatrix[0] = new Vector2(c, -s); rotMatrix[1] = new Vector2(s, c); Vector2 uvPivot = new Vector2(0.5f, 0.5f); for (int j = 0; j < uv.Length; j++) { uv[j] = uv[j] - uvPivot; float u = rotMatrix[0].x * uv[j].x + rotMatrix[0].y * uv[j].y + uvPivot.x; float v = rotMatrix[1].x * uv[j].x + rotMatrix[1].y * uv[j].y + uvPivot.y; uv[j].x = u; uv[j].y = v; } mf.mesh.uv = uv; } Por shader no lo he probado,puede que haya algo mal escrito,pero diria que tiene que ser asi void vert(inout appdata_full v) { float s = sin(_radians); float c = cos(_radians); float2x2 rotationMatrix = float2x2(c, -s, s, c); float2 uvPivot = float2(0.5, 0.5); v.texcoord.xy = mul(v.texcoord.xy - uvPivot, rotationMatrix) + uvPivot; }
  20. Oh, pues hace un tiempo me vi en un problema parecido,en verdad no pero una parte de la solucion creo que te puede servir.Lo que hice fue hacerme un shader para poder controlar los uv mediante los vertexcolors del mesh. Acabo de hacer uno a ver si te sirve,hay dos versiones, la version que pone test es una modificacion con 4 sliders en el material simulando los vertex colors del mesh para que se vea mejor como funciona,que me suelo explicar muy mal :D un pequeño resumen. tilesinwidth/tilesinheight => especificamos n filas/columnas textura => el "spritesheet" generado (tiling y offset por defecto) canal r => sirve para escojer que sprite se muestra (tendras que calcular el rango de cada sprite teniendo en cuenta el numero de sprites) canal g => para tintar el sprite mediante un HUE canal b => intensidad del tintado canal a => para controlar el clipping del sprite En cuanto lo veas lo pillas en un momento,ahora mismo el shader es del tipo Unlit,se puede cambiar si quieres. un saludo! TileSheetShaderTest.shader TileSheetShader.shader
  21. mhh quiza te sirva asi Quaternion.FromToRotation (Vector3.forward, dir);
  22. Buenas,diria que dentro del transform tienes lo que buscas, "TransformDirection()"; , tambien tienes variantes como point/Inverse, por si el vector es un punto o una direcion, y por si quieres cambiar a local o a global. Tambien lo tienes con matrices con , worldToLocalMatrix o localToWorldMatrix,dentro del transform tambien ofcourse. Saludos!
  23. Wow. Menudo curro te has pegado. Muchisimas gracias,mañana le pegare un repaso.
  24. Eiii, le has puesto una isla enorme ahora xD,tiene buena pinta.Podrias jugar un poco con el ambien intensity en lighting,si no se ve muy oscuro al personaje aun cuando no es de noche del todo. Yo creo que el motor de terrains de unity esta un poco anticuado ya,hay muy buenos assets en el store que tienen mejores herramientas.Para hacer un terreno muy grande lo mejor es partirlo en trozos y ir cargandolos y quitandolos. Pero bueno , el que has puesto parece bastante grande ya,como para tardar un rato de punta a punta XD. Saludos!
  25. Vale ya esta,capullada mia XD , resulta que cuando abro la ventana en el editor cojo los .json los leo y tal, pues se me havia olvidado hacerle el .Close() al StreamReader despues de leerlos, facepalm XD,la de rato que he perdido por un descuido Merci por las respuestas. Saludos!!
UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...