Jump to content
Sign in to follow this  
J Montes

Importación custom de escenas

Recommended Posts

¡Hola foreros!

Estoy trabajando en un generador de escenas y me enfrento a decidir cómo voy a llevar el resultado a Unity. Me surgen varias dudas que quería exponeros a ver si me podéis ayudar a decidir una forma buena de hacerlo.

Actualmente mi generador genera GLTF, esto lo importo en Blender y lo exporto a FBX, que importo en Unity. Mis modelos tienen materiales con colores y el visor de GLTF los muestra correctamente, no así Blender y Unity, así que estoy perdiendo los materiales en el camino. También estoy perdiendo la jerarquía de objetos: cada geometría aparece en un nodo y todos ellos al mismo nivel, cuando yo querría mantener una jerarquía de objetos más compleja.

Lo que necesito es una forma de llevarme una jerarquía entera de nodos de la escena a Unity, y estoy barajando hacer algunos scripts para este proceso. Tengo la sensación de que una buena pipeline de importación me permitiría gestionar toda la escena desde mi generador procedural. Quiero evitar tener que editar nada de la escena en Unity.

Querría hacer todo esto automáticamente: crear y asignar materiales, reusar geometría, añadir colliders y otros scripts custom... Me gustaría poder hacer esto en tiempo de diseño pero también en tiempo de ejecución para poder descargar niveles desde Internet directamente desde Unity.

Me surgen un montón de dudas:

  • ¿Cuál sería la forma de implementar esto? He leído sobre los scripted importers pero creo que sólo funcionan en tiempo de diseño y no cumplen mis objetivos. Generar archivos en el formato de Unity me parece engorroso. Estoy pensando en usar un script en Unity que bien genere la escena entera o modifique una importada para añadir todo lo necesario.
  • En principio, mi intención es generar uno o varios archivos con un formato propio (definiendo colliders, scripts a añadir...), pero quizá pudiera usar algún formato soportado por Unity y procesar los metadatos de los objetos ¿sabéis si se pueden importar metadatos/properties con los modelos?
  • No me están funcionando los materiales (los modelos que importo ahora mismo aparecen con el default material). ¿Tiene sentido que procese los nodos importados y les asigne materiales de alguna otra forma? ¿cómo gestionáis esto en vuestras pipelines?
  • Para reusar geometría y GameObjects, ¿bastaría con importarla una vez y después usar GameObject.Instance() sobre ese nodo repetidas veces? (al hacer esto no usaría prefabs, pero creo que tendría el mismo resultado). ¿Es esto posible?
  • Si quiero hacer esto en tiempo de ejecución, donde entiendo que Unity no deja importar assets (leer .OBJ o .FBX), tendría que usar mi propio formato y construir los Mesh en tiempo de ejecución ¿es esto viable? ¿le veis sentido?
  • Por último, creo que si renuncio a cargar niveles en tiempo de ejecución, podría intentar generar archivos en el propio formato de Unity y usar formatos de modelo más estandar (OBJ, FBX). O usar ScriptedImporters. Y esto me permitiría reimportar prefabs sin tener que reimportar la escena entera,. Pero no me acaba de convencer y los ScriptedImporters me parecen más engorrosos que simplemente importar unos modelos y usando unos metadatos, procesar la escena para adecuarla a mis necesidades.
  • ¿Entiendo que hacer todo esto dinámicamente afectaría a las posibilidades de precocinar la iluminación y otros aspectos (ocluders?)?

Estoy un poco perdido :-$. A ver si me dais vuestra opinión en estos temas para decidirme en una dirección.

Y otra pregunta ¿qué pipelines desde "fuentes -> scene graph" usáis? Unity fomenta que importemos modelos y hagamos la edición en su editor, pero ¿qué pasa con los mundos procedurales y gente que prefiere usar tools externas? 

¡Gracias!

 

Edited by J Montes

Share this post


Link to post
Share on other sites

hola

de momento pinta bien tu proyecto de mapas.

parece que hay para Unity algun "importador" de GLTF en la red. Igual te sirve.

https://github.com/KhronosGroup/UnityGLTF

los materiales no se que puede estar pasando... habria que verlo.

a mi me parece si me parece viable que almacenes la geometria en un script, despues de importarla puedes hacer un array o list de "mesh" y ir guardandolos ahi para usarlos cuando necesites... o usar "instance" como dice.

construir mesh en tiempo de ejecucion tambien es viable, tengo cierta experiencia en mundos procedurales y se pueden calcular/crear muchas cosas en tiempo de ejecucion... y si necesitas puedes hacerlo usando corrutinas.

siento no poder ayudarte mas. 

animo.

  • Like 1

Share this post


Link to post
Share on other sites

Gracias por los comentarios.

Ahora mismo, esta es la ruta que voy a seguir:

  • Mi formato para meshes es GLTF. Estoy teniendo problemas por ahora para exportar/importar la jerarquía y algunos metadatos, pero de una forma u otra esto tiene solución.
  • Usaré el importador de Khronos para Unity. Además si es necesario puede modificarse un poco.
  • Crearé en Unity una herramienta para post-procesar los archivos importados usando sus metadatos:_
    • Asignar o modificar materiales (GLTF puede importarlos pero en muchos casos queremos usar materiales que ya tenemos definidos).
    • Crear y y asignar colliders.
    • Marcar la geometría como estática, cambiarla de capa, etc...
    • Crear y asignar otros scripts  (spawn points)
    • Instanciar gameobjects en algunos puntos
  • Esta herramienta podrá correr en tiempo de ejecución (para niveles cargados dinámicamente),  pero también en tiempo de diseño, haciendo los cambios persistentes en el editor.

Me quedan algunas dudas sobre cómo GLTF exporta los shared meshes , pero creo que siempre podría exportar las posiciones y solucionar estos temas en la herramienta de postprocesado.  También dudo sobre si debería usar varios archivos GLTF (uno para la escna y otros para los prefabs) o meter todo en un único GLTF y postprocesar los objetos repetidos, pero lo iré viendo sobre la marcha.

Creo que esto soluciona mi pipeline desde el generador procedural (que es en Python) hacia Unity, usando en principio todo formatos estándar. ¿Qué os parece?.

Share this post


Link to post
Share on other sites

yo tengo curiosidad...

todo esto es para el proyecto de "yourCity racing"?

funciona como google maps? osea: selecionas un lugar del mapa (de la Tierra) desde unity y te genera el mapa? o son partes de mapa previamente creados fuera y luego importados a unity? esque no entiendo bien como lo haces...

desde que vi tu proyecto he setido curiosidad por esto de los "mapas del mundo" tipo googleEarth... he visto en youtube proyectos de unity que si que parece que generan el mapa directamente en unity... porejemplo:

 

de hecho este proyecto esta en "github", me lo descargue pero no consegui que funcionase, creo que quizas me faltan "librerias" pero no lo tengo muy claro...

https://github.com/melowntech/vts-browser-unity-plugin

esta ahi... si consigues que funcione me gustaria saber como... si tienes alguna libreria de openStreetMaps o algo...

Edited by Igor

Share this post


Link to post
Share on other sites

Este importador en realidad lo quería para Anastutia . Empecé esto escribiendo una herramienta para poder hacer mapas de minigolf proceduralmente, pero en Anastutia necesito enviar los mapas al jugador en tiempo de ejecución (ya que en Anastutia los minijuegos los genera y envía el servidor para que sean nuevos e iguales para ambos jugadores).

Pero como conozco el mundillo GIS pues le di un intento a usar OSM y por ahora sigo con ello. Lo cierto es que por tiempo o interés siempre tengo todos los proyectos a medias.

El generador que estoy escribiendo funciona:

  • dándole las coordenadas de la zona del planeta que quieres generar
  • dándole los datos de OpenStreetMaps de esa zona y una cantidad razonable de alrededores (podrían recogerse automáticamente pero para poner esto accesible, deberías usar tu propio servidor mirror de OpenStreetMaps)
  • dándole un modelo de elevación de esa zona, idealmente con una resolución razonablemente buena (~35m/pixel)
  • dándole un mapa global de densidad de población (~500m/pixel) - usado para algunas heurísticas (densidad de casas y cosas así)
  • wishlist: en el futuro, dándole también las ortofotos de satélite (para detectar texturas, tejados, alturas de edificios, tipos de monumentos, árboles...)

Yo trabajo con esto y suelo tener todos estos datos para países enteros en mi disco duro. En cualquier caso, todos esos datos son públicos para la mayor parte del planeta. Pero como ves, esto siempre estaría ligado a un servicio para que un usuario normal pueda recoger esos datos (hablamos de TB de datos para todo el planeta). Usar servicios públicos para un juego normalmente contraviene sus términos de uso, siempre podríamos usar nuestros propios servidores pero ves el problema... 

Mi generador es bastante simplón y tarda varios segundos/minutos en correr  para generar 1 km2. Lo que hago es ejecutarlo offline e importar luego el modelo en Unity. Después lo postproceso para añadir colliders y cambiar materiales (y en el futuro, lo que haga falta). Podría hacerse esto online (el usuario tendría que esperar un poco pero sólo la primera vez), pero dependeríamos de un servidor propio haciendo ese proceso y de tener acceso a todos los datos mencionados antes para todo el planeta (algunas fuentes son muy diversas y algunas no están disponibles). Por ello, ahora mismo me planteo más bien generar mi ciudad, importarla a mano, cocinar la luz, hacer un juego sencillo, y luego ya veremos.

Hay un pequeño problema adicional: mi generador proyecta el terreno sobre un plano. Como (casi) todos sabemos hoy la tierra ha resultado ser más bien una esfera y esto hace que no pueda generar muchos kilómetros a de mis coordenadas de origen sin horribles distorsiones. Mi generador no puede generar todo el globo a la vez (como sí hacen Google Maps, CesiumJS o VTS).

¿Por qué no en C#? A mí me interesaba escribirlo en Python, poder ejecutarlo en Linux, y poder generar modelos fuera de Unity. De esta forma, puedo correrlo en un servidor o como API sin necesitar Windows o Unity. Puedo usarlo para renderizar con Blender o hacer análisis de inundaciones, yo qué sé. No me gusta usar Unity para nada más que la simulación.

La herramienta que mencionas, VTS Geospatial, es un conjunto de herramientas para gestionar, mezclar, servir y consumir datos GIS (mapas raster y modelos 3D). En particular, que yo sepa no proporcionan un algoritmo mágico para generar el terreno en base a fotos. Estoy seguro de que tienen acceso a una: esto es lo que hacen Google Maps  o el equipo de Microsoft Flight Simulator, aunque también tienen nubes de puntos de LIDAR. En el ejemplo que enseñas esa herramienta está obteniendo la geometría 3D de los servidores de Melown Technologies, que es la compañía detrás de VTS Geospatial, y no sé si tienen disponible todo el planeta, pero desde luego no sería gratis. No he podido probarla, lo siento, pero si comentas el error que ves en otro hilo igual podemos sugerir algo.

Pero en cualquier caso: hay una diferencia fundamental entre el estilo de esas herramientas y la síntesis desde OpenStreetMap. La generación desde imágenes y nubes de puntos no accede bien a zonas ocultas y a menudo genera artefactos muy extraños tanto en el modelo como en las texturas. Los túneles a menudo aparecen tapados o mal conectados. La inteligencia artificial falla en objetos inusuales o desconocidos (aunque esto ya es cada vez menos cierto, y Google está generando unos modelos impecables de cosas como grúas). Es difícil eliminar sombras, vehículos y otros objetos de las texturas y modelos. No capturan objetos pequeños (farolas, semáforos, papeleras). Pero lo más importante, estos mecanismos no separan los diferentes objetos, no saben qué es una grúa, qué es un monumento y qué es parte del edificio del al lado... no tienen información semántica. Aunque no faltará mucho para que hagan todo esto.

OSM es un mapa simbólico, y tenemos datos exactos, los nombres de las calles y monumentos, velocidad y direcciones del tráfico, y metadatos que "representan" una ciudad. Así, al generarlo de forma procedural, sabemos que una calle es una calle y podemos poner semáforos, papeleras y decoración en sitios adecuados, y permitir que el usuario/jugador interactúe con ellos. 

No es remotamente fiel a la realidad, pero nos permite generar un mundo más inmersivo. De esta forma, se pueden generar algo que se parezca al mundo real, pero también podemos generar mundos de fantasía simplemente mapeándolos. Podríamos incluso construir así interiores y edificios procedurales usando herramientas de mapeado. Podemos cambiar el estilo global o de las zonas parametrizando el generador o customizándolo.

 

 

Edited by J Montes
  • Like 1

Share this post


Link to post
Share on other sites

gracias!

muy buena explicacion.

ahora me queda mas claro todo.

seguire mirando sobre el tema ya que le veo muchas posibilidades.

Share this post


Link to post
Share on other sites
Sign in to follow this  

×
×
  • Create New...