Jump to content
UnitySpain

Aceptamos donaciones vía Paypal.

UnitySpain.com es un servicio gratuito, pero mantener la Comunidad conlleva una serie de gastos.

Fondo Anual Unityspain: Donados 15,00€ de 150,00€

  • Servidor: Dominio.com y Hosting Web
  • Mantenimiento de los Foros
  • Contenido y Servicios Extras
  • Mantenimiento para Redes Sociales

J Montes

Registrados
  • Content Count

    64
  • Joined

  • Last visited

  • Days Won

    6

J Montes last won the day on February 18

J Montes had the most liked content!

Community Reputation

36 Excellent

About J Montes

  • Rank
    Usuario

Profile Information

  • Especialidad
    Otros

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @lightbug, el Ray Marching es otro rollo así que quizá quitaría el insert del video para mayor claridad en el post ;-). El video del Sebastian es genial. ¡Gracias!.
  2. Nunca he animado personajes 3D así que no sé cómo se hace si el personaje está animado. Pero si la mano del personaje es un GameObject, podrías simplemente poner el objeto como hijo de ese GameObject cuando el personaje lo agarra.
  3. También sería bueno recordar que los motores gráficos ya suelen mantener la transformación local y la global por nosotros. En Unity, tenemos Transform.localPosition y Transform.localRotation, así como Transform.position y Transform.rotation. Las primeras son las coordenadas locales, las que vemos en el panel de coordenadas del editor, y normalmente son las que queremos manipular. Las segundas son las coordenadas globales (las que se "dibujan"), que Unity calcula para nosotros aplicando las transformaciones acumuladas de todos los padres. El objeto Transform de cada GameObject también nos proporciona métodos para convertir entre ambas (Transform.localToWorldMatrix y Transform.worldToLocalMatrix), que son bastante utilizados cuando toca convertir de uno a otro espacio. También nos proporciona las propiedades .forward, .up, y .right que son vectores en world space que apuntan en esas direcciones respecto al GameObject (calcular esos vectores es muy común, y Unity nos lo ahorra). También tenemos más directamente que usando las matrices, métodos para transformar puntos desde el espacio de un Transform al World Space (TransformDirection, TransformPoint y TransformVector). Recomiendo revisar la documentación de Transform .
  4. @Pathus22 y @Alex : no, eso servirá para la posición pero no para toda la transformación (rotación, escalado y posición), y no de forma anidada. @Pathus22 y @Alex: hay una forma de incluir código en los posts y que se vea bonito, os animo a usarla ;-). @nomoregames, como bien te dice @francoe1 tienes poco que ganar haciendo tú mismo algo para lo que Unity está optimizado, y sería bueno que comentases para qué quieres hacer eso: suelen recomendar que uno pregunte por su problema, no por la que cree que es su solución! Dicho esto... Tu problema es un problema clásico de robótica (calcular la posición del extremo de una serie de brazos articulados), también aplicable a astronomía (satélites que rotan alrededor de planetas que rotan) y a programación gráfica (que es el caso que nos ocupa). La manera que tenemos de atacar este problema es tirando de álgebra lineal. ¡No dejes de leer aún! Al principio es un lío, pero estos objetos matemáticos (vectores, matrices y quaterniones) podría decirse que están hechos a medida para este tipo de problemas, y explorarlo nos acerca un poco al funcionamiento de los motores y las tarjetas gráficas. Iba a dejarte una explicación general pero no me veo capaz. Si expones tu problema, intentamos ayudarte. Te pongo una respuesta random pero realmente sería bueno saber qué quieres hacer: La posición, orientación y escalado de un objeto se pueden representar mediante un Vector3, Quaternion y Vector3 respectivamente. Estas operaciones (traslación, rotación, dejando el escalado aparte) son operaciones lineales, lo que significa que las cosas que están en línea recta seguirán en línea recta después de cualquiera de estas transformaciones. Sabemos por el álgebra lineal que las transformaciones lineales representan una forma de "transformar el espacio" (o los puntos en el espacio). Y también que cualquier número de esas transformaciones lineales se pueden combinar en una única transformación "unificada". Las transformaciones vectoriales se pueden representar con una matriz. Cuando la matriz representa traslación, rotación y escalado, la llamamos "matriz de transformación homogénea" (y es de 4x4). En Unity se usa la clase Matrix4x4 para albergar esas matrices. El álgebra nos dice que para transformar un punto (un Vector3) de un espacio a otro, podemos multiplicar un vector por esa matriz. Las matrices y vectores y sus operaciones se han definido para esto: son "objetos matemáticos" hechos para facilitar la representación y las operaciones con espacios vectoriales. Vector3 traslacion = new Vector3(0, 0, 0); Vector3 rotacion = Quaternion.Euler(0, -30, 0); Vector3 escalado = Vector3.one; Matrix4x4 transformacion = Matrix4x4.TRS(traslacion, rotacion, escalado); Vector3 puntoOriginal = new Vector3(4,5,6); Vector3 puntoTransformado = transformacion.MultiplyPoint3x4(puntoOriginal); Esto es bastante mágico: las matrices también se pueden multiplicar. Y esto representa geométricamente lo que uno hubiera pensado: ¡la combinación de dos transformaciones sucesivas! ¡qué bien pensadas están! (mucha gente muy lista ha tenido que morir para llegar a donde estamos :D). También sabemos que todas estas operaciones NO son conmutativas (en algún caso podrían serlo, pero no en general). Así que no es lo mismo "rotar, multiplicar y escalar" que hacerlo en otro orden. Tampoco es equivalente aplicar las rotaciones en orden XYZ o en orden ZYX (los Quaterniones no tienen este problema, pero los ángulos eulerianos sí). Y tampoco por tanto podemos cambiar de orden la multiplicación de matrices al concatenarlas (esto sería equivalente a anidar padre e hijo al revés). Por tanto, las matrices de transformación de cada nodo se multiplican sucesivamente, y el resultado se usa para transformar los vértices del modelo. Esto pone el modelo en "World Space" (ya que los vértices del modelo en sí mismo suelen estar centrados en 0, 0, 0). Además, parecidas matrices de transformación se usan después para proyectar todos los puntos primero en el espacio de la cámara (que pulula por la escena), y luego todo en el espacio de la pantalla (2D). Esto es lo que hace la gráfica todo el rato. A la gráfica Unity le pasa realmente la última matriz de transformación, que hace toda la conversión en una única multiplicación de "vector * matriz" para cada vértice en pantalla (simplificando un poco bastante). Los vértices normalmente están ya en la memoria de la gráfica, en coordenadas locales (y no se tocan). Si quieres repetir este proceso, busca las matrices que te interesen, multiplícalas en el orden correcto, y finalmente multiplica tus puntos por esa matriz. Notas: La documentación de MultiplyPoint3x4 tiene ejemplos de la transformación de un Mesh. Y también explica por qué usar ese método y no otras alternativas. Tal y como has hecho la pregunta, no puedes usar transform.worldToLocalMatrix porque tendrá acumuladas las transformaciones de sus objetos padre. De hecho Unity (cualquier motor) optimizan mucho el cálculo de estas matrices. Pero en función de tu caso, igual sí puedes aprovechar la matriz ya acumulada de un Transform.
  5. ¿Por qué los mensajes de @pioj no tienen corazón? Yo quería darle al like...
  6. Diferencias Usas raycasting cuando quieres saber a qué distancia o qué objeto impacta con un un segmento de línea. Así sabemos qué tenemos delante en la dirección de interés. Ese segmento lo defines en el momento de calcular el raycast, así que puede ser lo que tu quieras (pero por cada rayo que calculas, incurres en un coste computacional). Se pueden usar para: Calcular la distancia al suelo desde un punto (rayo hacia abajo) para posicionar objetos o cámaras. Calcular el lugar donde impacta un disparo "instantáneo" (rayo desde el cañón de un arma). Calcular en qué objeto está apuntando el ratón. Calcular qué objetos "ve" uno de nuestros personajes o vehículos (se suelen calcular unos cuantos rayos alrededor para saber si vamos a colisionar con algo). Fíjate que puedes proyectar rayos para calcular la distancia a objetos con los que aún no se está colisionando. Y recuerda también que además del Raycast, tienes el Spherecast y otras variantes, porque una línea es muy fina, y a veces necesitamos proyectar una "esfera" para saber si hay algún objeto en la dirección de interés. Las colisiones en Unity en cambio son resueltas por el motor durante la simulación física, y necesitan que haya un Rigidbody involucrado (ya que los Rigidbody son los objetos con los que trabaja el motor físico). Sólo obtendrás colisiones entre Ridigbody y objetos que tengan un Collider de algún tipo. Las colisiones se pueden gestionar como eventos, así que Unity llamará a OnCollide cuando se produzca una colisión. Además, los Collider pueden marcarse como "Trigger", lo que causará que no se comporten como sólidos, sino que puedan ser atravesados (en este caso, Unity llamará a OnTriggerEnter). Esto se puede usar para saber cuando uno de nuestros objetos físicos impacta con algo o atraviesa un "trigger".: Saber cuando un personaje u objeto entra en determinado área. Reproducir sonidos en las colisiones entre objetos. Saber cuándo un personaje u objeto toca a otro o una parte del escenario. Cuál usar para un character controller Parece que no es muy recomendable usar el motor físico para controlar un personaje a no ser que la simulación del movimiento en sí misma deba ser físicamente realista. Yo en general opino parecido, pero cada caso varía. El motivo principal de no usar el motor físico, en mi opinión, para esto, es que tendrías que modelar el movimiento del personaje usando fuerzas, rozamientos, materiales... y gestionar los tropiezos y caídas (superficies inclinadas, etc). Esto puede tener sentido en algunos proyectos pero en general complica lograr un movimiento consistente. Por otra parte usar uno o unos pocos Raycast es más rápido que dejar que el motor físico mueva tu personaje, aunque esto no tiene un gran impacto si el collider de tu personaje es una simple cápsula.
  7. No es un error crítico, y como dice el propio mensaje puede causar que los errores indiquen el número de línea incorrecto pero salvo eso no he visto otros problemas, auqnue tendría cuidado con las directivas del preprocesador (#IF). Esto se produce cuando editas el mismo código en Windows y Mac/Linux, ya que cada editor introduce los finales de línea de manera diferente (al estilo del sistema operativo en que te encuentres). En general, deberías configurar todos tus editores para utilizar el mismo estilo de final de línea.
  8. Update. Esta versión no tiene muchas novedades. Trabajé en la iluminación y añadí efectos de postprocesado (bloom), y muestra una ruta de 12km por la costa. Me gusta el aspecto del asfalto y la iluminación, pero después de grabar este video probé con HDR y Deferred Rendering, y después nunca volví a recuperar este aspecto. La iluminación y definición de materiales es un arte oscuro y difícil que me supera por completo. Creo que lo dejaré para más adelante, cuando los coches y algunos otros modelos sean más finales, porque mi talento gráfico es nulo.
  9. Había escrito (más bien copiado y retocado) un shader para aplicar vertex colors que además añadía una detail texture, pero generando las coordenadas UV en el shader: sólo funcionaba en el plano horizontal. Lo mismo hice para wrapear las texturas que hay ahora: las coordenadas UV corresponden a las coordenadas X,Z en world space (así que todo lo que no sea horizontal está deformado). ¿Cómo se haría para, teniendo en cuenta si el triángulo es vertical u horizontal, asignar UV correctas en un vertex shader? ¿Es mejor usar un shader que incluir las coordenadas UV en el modelo? Si tienes un ejemplo lo pruebo O:) De todas formas: mi intención era generar las coordenadas UV en el generador, como hago ahora, pero de forma correcta: aplicando cube, cylinder o sphere wrapping, o directamente en base al perfil y altura del edificio (que al fin y al cabo, lo estoy generando proceduralmente, y tengo más "información"). Sin embargo no sé ni cómo se suele hacer, ni qué pinta tienen las texturas que se usan para esto, si se usan muchos o pocos materiales... También pensaba añadir algo más de detalle a la geometría: balcones, tejados chimeneas, quizá portales... pero no tengo claro qué tipo de modelos debería generar o qué será lo más razonable... para mí lo más fácil es generar puertas, portales, balcones, etc como geometría, pero son demasiados triángulos. Supongo que tendré que usar una mezcla de todo esto, en función del LOD. Por ahora sólo estoy generando el nivel "más detallado", pero imaginaba que tendré que generar varias versiones de cada "pedazo de mapa", simplificando geometrías y usando menos materiales.
  10. Actualizo. En esta versión el importador aplica algunos materiales y el generador genera coordenadas UV, aunque el wrapping es muy basico y las paredes verticales se ven mal texturizadas.
  11. J Montes

    Imágenes ARCore

    En la documentación de ARCoreImage ponen que: Images must: Fill at least 25% of the camera frame to be initially detected. Be flat (for example, not wrinkled or wrapped around a bottle). Be in clear view of the camera. They should not be be partially obscured, viewed at an oblique angle, or viewed when the camera is moving too fast. Entiendo que ese 25% viene a ser un 40%, si además la imagen tiene que estar centrada como dicen en el tercer punto. Una vez que la encuentra, sí debería ser capaz de seguirla. También ponen: Tips for selecting reference images Augmented Images supports PNG and JPEG file formats. For JPEG files, avoid heavy compression for best performance. Detection is solely based on points of high contrast, so both color and black & white images are detected, regardless of whether a color or black & white reference image is used. The image's resolution should be at least 300 x 300 pixels. Using images with high resolution does not improve performance. Avoid images with sparse features. Avoid images with repetitive features. Use the arcoreimg tool to get a score between 0 and 100 for each image. We recommend a score of at least 75. Here are two examples: When an image is initially detected by ARCore, and no expected physical size was specified, its tracking state will be paused. This means that ARCore has recognized the image, but has not gathered enough data to estimate its location in 3D space. Do not use the image's pose and size estimates until the image's tracking state is tracking. Asegúrate de que las letras tienen un marco claro (no sólo el folio en blanco) e intenta eliminar la cantidad de brillo que tienen, buen contraste (sin brillos, si es necesario plastificadlas para que sean planas y mate). Tienen que tener la mayor cantidad de "features" distintivas posible, la herramienta "arcoreimg" te dará un score. Posiblemente podáis añadir huecos a las letras (círculos, otras letras o rasgos) de un tamaño visible, eso aumentará el número de características distintivas. No uséis patrones regulares, cuanto más aleatoria sea la distribución de esas "features"; mayor será la correlación entre base de datos e imagen. El último punto sugiere que es mejor que le digas a la API el tamaño real del objeto, para que no tenga que deducirlo. Las letras tienen una distribución de features muy similares (bordes verticales, horizontales, y curvas normalmente de radio similar en posiciones similares). Si sólo ves un frame borroso y de calidad reducida de unas letras en diferentes posiciones, será difícil que reconozcas de primeras cuáles son y sus posiciones, tamaño y orientaciones exactas. Si son fotos de personas te seŕa más fácil porque sus características son más reconocibles (pelo arriba, barbilla abajo, etc...). Convierte tus letras en algo con identidad visual propia. La biblioteca trabaja en blanco y negro, usando el contraste. Usar color NO ayuda a distinguir las imágenes, usa bordes bien marcados y de un grosor bueno visible fácilmente en la cámara. Espero que te ayude... de todas formas, nunca he usado esta API así que te comento basado en lo que he leído.
  12. Mis ideas: - Busca alguien con más experiencia con quien colaborar, y que esté dispuesto a ser tu mentor en ese proyecto. - Coge una o dos parte pequeñas, acotadas del proyecto, y ocúpate de ella. Si acabas, coge otra. Alternativamente: - Elige un proyecto MUY pequeño, intenta ejecutarlo de principio a fin. - Intenta buscar un mentor con quien poder discutir el desarrollo del proyecto y que lo revise. Estudia lo que sea necesario para llevar a cabo tu parte o ese pequeño proyecto. Alguien tendrá que guiarte. Si estudias formalmente te darán varios años de formación, cuando eres autodidacta tienes que ir eligiendo el camino y al principio es más difícil.
  13. Aquí se ve la carga (previa generación) de pedazos de mapa, recorriendo varios kilómetros y decenas de pedazos. En esta versión, todos los pedazos están cargados (pero desactivados) en la escena, pero también pueden cargarse dinámicamente. De esa forma he podido generar más de 110km2 (al parecer esto es más que GTA San Andreas o que AC Origins ), aunque en los extremos la iluminación y las físicas no se comportan del todo bien. Además, en algunos casos tarda demasiado en cargar, y se ve feo -faltaría generar diferentes LODs para cada trozo de escenario. En el video, también se pueden ver varios defectos en la generación del escenario. Intentaré avanzar con el generador de escenarios.
  14. Es una primera versión... seguramente faltan usuarios para ir puliendo y que te vayan comentando necesidades. El potencial es muy grande. Yo le pondría 12,30 o 14, 70 pavos e intentaría ir haciendo base de usuarios para avanzarlo rápido un par de versiones y unos cuantos bugfixes, y me lo replantearía. Un plugin como este a pleno potencial y con algunos assets... vale algo más yo creo, pero... tampoco sé las calidades de los assets ni he usado el plugin. ¿Tienes un hilo en Unity Forums? allí es donde se anuncian todos los plugins (además de aquí claro :D)
×
×
  • Create New...