Unity Spain
Post Antiguos => General (Antiguo) => Mensaje iniciado por: Jeko37 en Mayo 22, 2018, 04:37:56 PM
Buenas! les comento, mi idea es poder crear un universo generado aleatoriamente a partir de un "seed" o semilla, para desarrollar digamos un framework base que nos permita generar un universo entero, explorable como base para cualquier juego que se base en exploración espacial, pero bueno llegar a eso ya es algo más ambicioso y como recien estoy empezando me gustaria abordar las cosas una por una.
Mi idea es empezar creando un script capaz de generar un planeta entero, con sus fallas geograficas, oceanos, montañas, etc e ir afinando el codigo de dicho generador para hacerlo lo más realista posible, que genere paisajes lo más parecidos a los que podemos encontrar en nuestro planeta.
Como referencia les dejo estos dos videos descriptivos de planetas generados aleatoriamente utilizando OpenGL y Java, mi idea es poder hacer esto como punto de partida:
" width="640">" width="640">
Bueno, acá necesitaria de su ayuda, ¿alguien alguna vez realizo algo como esto? ¿tiene conocimiento de generacion de terrenos aleatorios o algo con lo que pueda empezar a documentarme? obviamente, paralelo a este hilo yo estoy buscando información por mi mismo en google y a medida que vaya avanzando iré publicando los avances para quien esté interesado.
Podrias empezar con un sistema de voxel para entender los conceptos básicos matemáticos y la implementación de técnicas para la optimización como los CHUNK.
Si logras algo decente con esta técnica entonces podrias pasarte a produceral mesh e intentar aplicar las mismas técnicas pero esta vez con matemáticas más complejas, recuerda que tambien un entorno tiene componentes físicos, por lo requiere un sistema que pueda manejarse de manera estable y simular sus propiedades.
Por ejemplo, una idea que se me ocurre es realizar un VOXEL con una cuadrícula de 100x100x100 y que cada bloque ocupe 1 unidad, luego dividir la unidad que cada bloque ocupa, con cada división obtendrás más "calidad", en este punto puedes implementar "shaders" para convertir el voxel en una malla.
Te dejo un tutorial que recomiendo lo sigas para entender algunos puntos complejos de estas implementaciones.
https://forum.unity.com/threads/tutorial-procedural-meshes-and-voxel-terrain-c.198651/ (https://forum.unity.com/threads/tutorial-procedural-meshes-and-voxel-terrain-c.198651/)
Y otro para entender un poco más sobre shaders (No se aplica en su totalidad a Unity pero sirve para los conceptos)
eature=oembed" width="480">
Desde ya te digo, si tu conocimiento matemático es bajo, trata de aprender cada fórmula, para que en un futuro entiendas que estás haciendo.
Hola muchas gracias, cuando llegue a casa (ahora estoy en el trabajo) voy a revisar lo que me pasaste y tratar de aplicar los conceptos, mi conocimiento matematico es bajo pero si tengo que sentarme a leer las formulas, lo hago, ya vengo mentalizado de que la resolución para este problema viene muy ligado a la parte matematica asi que no me queda otra que aprender. Gracias por la información!
ya alguien habia preguntado x ese tema
Cita de: Jeko37 date=1526999876poder crear un universo generado aleatoriamente a partir de un "seed" o semilla, para desarrollar digamos un framework base que nos permita generar un universo entero, explorable como base para cualquier juego que se base en exploración espacial, pero bueno llegar a eso ya es algo más ambicioso y como recien estoy empezando me gustaria abordar las cosas una por una.
El proyecto está genial, solo acordate de que, una vez que tengas todo cocinado hacé la parte del gameplay, diseño e historia del juego xD, no como:
(https://i.ytimg.com/vi/UcCAcNM8tlE/maxresdefault.jpg)
fuera de joda, sumando a lo que dijo francoe tenés charlas de este Tipo (el de la foto, no francoe) diciendo como funciona la matemática de No man sky, supongo está interesante. sobretodo cuando estés con el foco en el planeta y el ruido para generar esas fallas geográficas.
tart=1075&feature=oembed" width="480">
toma en cuenta q unity basa casi todos sus calculos en floats, q pierden precision alrededor del 100,000 en adelante... si piensas en 100mil años luz no es ni un grano en los 47billones de años luz del universo... tendras q ingeniartela para dividir el espacio
Cita de: lightbug date=1527031605...como funciona la matemática de No man sky, supongo está interesante. sobretodo cuando estés con el foco en el planeta y el ruido para generar esas fallas geográficas.
q buena!
Cita de: Braltor date=1527035811toma en cuenta q unity basa casi todos sus calculos en floats, q pierden precision alrededor del 100,000 en adelante... si piensas en 100mil años luz no es ni un grano en los 47billones de años luz del universo... tendras q ingeniartela para dividir el espacio
Sí, buen punto. me acuerdo de este Topic que trata de eso (hay un vid que demuestra el efecto, si es que todavía está el link intacto):
para mi este tema es como el santo grial de la programacion... otros lo han logrado.... asi que seguire intentandolo...
Ayer estuve revisando información, me vi los vídeos que me pasaron y encontré alguna que otra porción de código que no llevó a buen puerto, con respecto al problema de los floats se puede resolver dividiendo el espacio en cuadriculas y reiniciando las coordenadas de las cosas cuando se pase de una cuadricula espacial a la otra, pero desconozco si Unity me permite hacer algo así, en su momento supongo que se podrá abordar el problema pero por ejemplo imaginen que están dentro de un área espacial y van a pasar a la siguiente, simplemente trasladas el personaje de su coordenada actual y lo mandas más atrás mucho mas atrás (como una teletransportacion digamos jaja) y en ese interín borras todo el contenido 3D del area espacial y cargas los nuevos elementos (previamente procesados) y das la sensación de "infinitud" espacial sin llegar a tener problemas con el calculo de los floats, para poder volver para atras y cargar contenidos virtuales viejos como estaban antes es que ayudaria el seed. No se si me hago entender.
Por lo que estuve viendo en la documentación de Unity no hay porque creer que esto sea una tarea imposible, lo primero es lograr un pequeño algoritmo que deforme una esfera, después la idea es aumentar el detalle a medida que uno se acerca (si hacemos todo de una no hay manera que el procesador lo aguante) y después vendría la parte mas divertida, diseñar un algoritmo matemático que genere un ruido que de como resultado paisajes que den la sensación de reales, yo vi en No Man Sky los planetas y me aprecio muy descuidado el algoritmo que genera los mundos, da la sensación de que todos los planetas son iguales cuando para mi la gracia es entender que los planetas son muy diferentes entre si, por ejemplo vas a tener planetas como la tierra, con variedad de biomas muy distintos según las áreas donde aterrices, planetas como marte donde el paisaje va a ser mas bien monótono, planetas golpeados por asteroides con gran cantidad de crateres, planetas gaseosos que serian los mas fáciles de hacer ya que no hay calculo de terreno.
Con el tema de la historia del juego, no tengo en mente hacer un juego a partir de esto, sino crear un framework de base para que quien quiera crear un juego con un universo explorable lo pueda hacer facilmente.
En fin, cuando tenga algún avance voy a ir publicando las imágenes y el código así me ayudan a ir afinándolo.
Aca va un poco de matemáticas para empezar a sudar frio: http://mathproofs.blogspot.com.ar/2005/07/mapping-cube-to-sphere.html (http://mathproofs.blogspot.com.ar/2005/07/mapping-cube-to-sphere.html)
Cita de: Jeko37 date=1527085170Ayer estuve revisando información, me vi los vídeos que me pasaron y encontré alguna que otra porción de código que no llevó a buen puerto, con respecto al problema de los floats se puede resolver dividiendo el espacio en cuadriculas y reiniciando las coordenadas de las cosas cuando se pase de una cuadricula espacial a la otra, pero desconozco si Unity me permite hacer algo así, en su momento supongo que se podrá abordar el problema pero por ejemplo imaginen que están dentro de un área espacial y van a pasar a la siguiente, simplemente trasladas el personaje de su coordenada actual y lo mandas más atrás mucho mas atrás (como una teletransportacion digamos jaja) y en ese interín borras todo el contenido 3D del area espacial y cargas los nuevos elementos (previamente procesados) y das la sensación de "infinitud" espacial sin llegar a tener problemas con el calculo de los floats, para poder volver para atras y cargar contenidos virtuales viejos como estaban antes es que ayudaria el seed. No se si me hago entender.
Por lo que estuve viendo en la documentación de Unity no hay porque creer que esto sea una tarea imposible, lo primero es lograr un pequeño algoritmo que deforme una esfera, después la idea es aumentar el detalle a medida que uno se acerca (si hacemos todo de una no hay manera que el procesador lo aguante) y después vendría la parte mas divertida, diseñar un algoritmo matemático que genere un ruido que de como resultado paisajes que den la sensación de reales, yo vi en No Man Sky los planetas y me aprecio muy descuidado el algoritmo que genera los mundos, da la sensación de que todos los planetas son iguales cuando para mi la gracia es entender que los planetas son muy diferentes entre si, por ejemplo vas a tener planetas como la tierra, con variedad de biomas muy distintos según las áreas donde aterrices, planetas como marte donde el paisaje va a ser mas bien monótono, planetas golpeados por asteroides con gran cantidad de crateres, planetas gaseosos que serian los mas fáciles de hacer ya que no hay calculo de terreno.
Con el tema de la historia del juego, no tengo en mente hacer un juego a partir de esto, sino crear un framework de base para que quien quiera crear un juego con un universo explorable lo pueda hacer facilmente.
En fin, cuando tenga algún avance voy a ir publicando las imágenes y el código así me ayudan a ir afinándolo.
¿Por qué no empezar con algo más simple?, me comentaste que tus conocimientos en matemáticas son bajos y esto es matemática avanzada, empieza con simulación de olas deformación de mallas planas.
Cita de: Jeko37 date=1527085170Ayer estuve revisando información, me vi los vídeos que me pasaron y encontré alguna que otra porción de código que no llevó a buen puerto, con respecto al problema de los floats se puede resolver dividiendo el espacio en cuadriculas y reiniciando las coordenadas de las cosas cuando se pase de una cuadricula espacial a la otra, pero desconozco si Unity me permite hacer algo así, en su momento supongo que se podrá abordar el problema pero por ejemplo imaginen que están dentro de un área espacial y van a pasar a la siguiente, simplemente trasladas el personaje de su coordenada actual y lo mandas más atrás mucho mas atrás (como una teletransportacion digamos jaja) y en ese interín borras todo el contenido 3D del area espacial y cargas los nuevos elementos (previamente procesados) y das la sensación de "infinitud" espacial sin llegar a tener problemas con el calculo de los floats, para poder volver para atras y cargar contenidos virtuales viejos como estaban antes es que ayudaria el seed. No se si me hago entender.
Por lo que estuve viendo en la documentación de Unity no hay porque creer que esto sea una tarea imposible, lo primero es lograr un pequeño algoritmo que deforme una esfera, después la idea es aumentar el detalle a medida que uno se acerca (si hacemos todo de una no hay manera que el procesador lo aguante) y después vendría la parte mas divertida, diseñar un algoritmo matemático que genere un ruido que de como resultado paisajes que den la sensación de reales, yo vi en No Man Sky los planetas y me aprecio muy descuidado el algoritmo que genera los mundos, da la sensación de que todos los planetas son iguales cuando para mi la gracia es entender que los planetas son muy diferentes entre si, por ejemplo vas a tener planetas como la tierra, con variedad de biomas muy distintos según las áreas donde aterrices, planetas como marte donde el paisaje va a ser mas bien monótono, planetas golpeados por asteroides con gran cantidad de crateres, planetas gaseosos que serian los mas fáciles de hacer ya que no hay calculo de terreno.
entonces tienes q enfrentarte a estas cosas entre otras:
* como procesas las fisicas en los limites de esas cuadriculas?
* como procesas los objetos en cada cuadricula en todo el universo en tiempo real para q hagan sus tareas segundo a segundo?
* como procesas los movimientos y los sistemas de ecuaciones de gravedad entre todos los objetos de diferentes masas en todas las cuadriculas?
* hacer el perlin de un planeta es sencillo, pero como le aplicaras erosion para q el entorno se vea real?
* como vas a simular las dinamicas de fluidos para aguas y atmosferas?
* como vas a procesar los datos de suelos plantables y los q no son aptos para la vida?
* como vas a generar formas de vida diferentes adaptadas a sus planetas y entornos?
Cita de: Braltor date=1527088088entonces tienes q enfrentarte a estas cosas entre otras:
* como procesas las fisicas en los limites de esas cuadriculas?
* como procesas los objetos en cada cuadricula en todo el universo en tiempo real para q hagan sus tareas segundo a segundo?
* como procesas los movimientos y los sistemas de ecuaciones de gravedad entre todos los objetos de diferentes masas en todas las cuadriculas?
* hacer el perlin de un planeta es sencillo, pero como le aplicaras erosion para q el entorno se vea real?
* como vas a simular las dinamicas de fluidos para aguas y atmosferas?
* como vas a procesar los datos de suelos plantables y los q no son aptos para la vida?
* como vas a generar formas de vida diferentes adaptadas a sus planetas y entornos?
Como.. Para una persona y agregado a esto sin conocimientos es IMPOSIBLE. Uno tiene que ser sincero .
Cita de: francoe1 date=1527088452Como.. Para una persona y agregado a esto sin conocimientos es IMPOSIBLE. Uno tiene que ser sincero .
jajaj si... si alguien me dijera "te pago mes a mes por hacer eso hasta q lo termines" eso me daria una gran alegria xq tendria trabajo pagado para el resto de mi vida!
Cita de: Braltor date=1527089000jajaj si... si alguien me dijera "te pago mes a mes por hacer eso hasta q lo termines" eso me daria una gran alegria xq tendria trabajo pagado para el resto de mi vida!
Jajajjaja Exactamente...
jeje, tampoco es tanto... toda la vida no... yo creo que lo acabarias antes... jeje
yo poco a poco voy avanzando en el tema... tengo varios proyectos diferentes sobre esto...
redondear un cubo es facil (no es un cubo, son seis planos individuales)
aplicar ruido tambien es muy facil... a la vez que aplicas ese ruido, cojes el valor que te ha dado ruido para generar una textura tipo splash (pudiendo mexlar cuatro texturas, una por cada canal de la textura splash (rgba)... cada una con su bumpMap)
ya esta texturizado todo...
meto otra esfera para el oceano y otra para la atmosfera
el problema de la suvdivision es lo que mas me esta costando... se te acercas cada plano de divide en cuatro, que son echos sus hijos, y desactivo el render del pader.... y asi sucesibamente... hasta que cada "poligono" mide 1 unidad de lado... si te alejas desactivo los hijos y activo los padres... pero luego me di cuenta de que los bordes de los planos no encajan bien con los que tienen diferente "LOD" ("nivel de detalle"... por llamarlo de alguna forma)... y opte por esta solucion chapuzera pero rapida... (encontrada en la web)
la imagenes son solo para hacerte una idea... ya que los planos son 16*16..
izquierda: mi problema
derecha: la solucion que he usado
...haciendola despues de recalcular las "normals" para que no haya cambio de iluminacion al "inclinar" ese ultimo poligono del borde/union...
claro, ahora los planos son de 18*18... en vez de 16*16... pero asi ademas ya coinciden tambien las normales de los bordes con los de los bordes vecinos ya que hay poligonos solapados que luego inclino (al final del todo del calculo)
pero ahora lo que si que no se como voy a haces es para llenar el planeta de vegetacion... o de algo...
y luego tendria que solucionar el problema ese de la precision...
Con el tema de la matemática tengo a un matemático amigo que va a ayudar si fuera necesario. Obviamente son muchos problemas a sortear pero hay que ir resolviendolos uno por uno. Por ahora mi objetivo es simple, generar un planeta, con ruido generar un terreno que se asemeje a algo natural y nada mas, a partir de ahi iré avanzando.
Acá hay un código interesante aunque no tuve tiempo de probarlo pero creo que seria un buen punto de partida
https://github.com/Tiggilyboo/UnityQuadTreePlanet (https://github.com/Tiggilyboo/UnityQuadTreePlanet)
Bueno, por las cosas que estuve leyendo los primeros pasos para empezar a crear un planeta procedural seria:
1 - Crear un cubo
2 - Subdividir sus caras en una malla de teselas (cuadrados)
3 - deformar los vértices de las seis caras del cubo para "esferizar" las mallas
4 - Según la cámara este más lejos o más cerca de la superficie de la malla dividir los cuadros para aumentar la definición del área visible
5 - Escribir una funcion de noise que genera un mapa de alturas sobre la malla para formar los paisajes
6 - Texturizar
La creación del cubo y la esferización de sus caras lo pude hacer hoy a la tarde.
(http://drive.google.com/uc?export=view&id=1zHR0ldca5i60QVmZaAT5DXRZdtsEUH8e)
mirate este documento:
https://catlikecoding.com/unity/tutorials/cube-sphere/ (https://catlikecoding.com/unity/tutorials/cube-sphere/)
explica como "arreglar".... como hacer que todos los lados sean igual de grandes... porque si te fijas salen mas juntos los poligonos de los bordes....
con este pequeño script quedan ya "igualados"....
private void SetVertex (int i, int x, int y, int z) {
Vector3 v = new Vector3(x, y, z) * 2f / gridSize - Vector3.one;
float x2 = v.x * v.x;
float y2 = v.y * v.y;
float z2 = v.z * v.z;
Vector3 s;
s.x = v.x * Mathf.Sqrt(1f - y2 / 2f - z2 / 2f + y2 * z2 / 3f);
s.y = v.y * Mathf.Sqrt(1f - x2 / 2f - z2 / 2f + x2 * z2 / 3f);
s.z = v.z * Mathf.Sqrt(1f - x2 / 2f - y2 / 2f + x2 * y2 / 3f);
normals = s;
vertices = normals * radius;
cubeUV = new Color32((byte)x, (byte)y, (byte)z, 0);
}
Interesante! ayer conseguí que según la distancia de la cámara a la superficie de la malla, esta se subdivida en cuadriculas más pequeñas por sectores, lo cual es un buen avance, aunque los resultados todavía no me convencen, voy a frenar con eso para aplicar lo que dice ese documento para suavizar esos bordes entre las mallas con el script que me pasaste.
Gracias!
Cita de: Jeko37 date=1527170888Interesante! ayer conseguí que según la distancia de la cámara a la superficie de la malla, esta se subdivida en cuadriculas más pequeñas por sectores, lo cual es un buen avance, aunque los resultados todavía no me convencen, voy a frenar con eso para aplicar lo que dice ese documento para suavizar esos bordes entre las mallas con el script que me pasaste.
Gracias!
tené en cuenta que todo procesado de voxels, geometrias y cosas así generalmente se hacen en GPU ya que las entradas (vertices) son independientes unos de otros, si por ej realizás calculos de que involucren muchos planetas, distancias, LODs, etc (proyectando un poco a futuro tu proyecto), pero los hacés en un script(C#) estas usando directamente el CPu para todo, que no digo que para cosas simples como la esfera funcione, pero cuando todo se complique vas a tener que dar un Reset y pasar al GPU. Lo recomendable para esto es usar o shaders para tal tarea (como un tesselation por niveles, muy común esto) o simplemente un geometryShader como pusieron antes para cualquier cosa que quieras y se te ocurra (mas de propósito general).
Cita de: lightbug date=1527171313... pero cuando todo se complique vas a tener que dar un Reset y pasar al GPU. Lo recomendable para esto es usar o shaders para tal tarea (como un tesselation por niveles, muy común esto)
tessellation not working in my computer
Cita de: Igor date=1527193900tessellation not working in my computer
olvidate, en la mia tampoco el gpu batalla, pero a veces no le da pa tanto.
bueno... he hecho avances en uno de esos proyectos
union entre "chunks" solucionada inclinando los ultimos poligonos (poligonos extra "superpuestos"), los del borde de cada "pieza" despues del calculo de "normals"...
texturizado hecho con un shader "splat" de 4 canales, + 4 canales bump, + specular, + rim.
el ruido lo he hecho al final mezclando perlin con voronoi.
me falta hacer alguna cosilla... que el "tiling" de las texturas se adapte a la "escala" de la pieza... ...meter la atmosfera y el mar... pero eso es facil...
y faltaria el tema de la precision y eso...
...y luego ya vere para que lo uso...
se va viendo bastante bien!
Cita de: Igor date=1527262463...y luego ya vere para que lo uso...
x q no lo pones en github para q otros te contribuyan?
130k triangulos... necesitas implementar algun LOD para q sea utilizable en juegos
Cita de: Braltor date=1527266236se va viendo bastante bien!
x q no lo pones en github para q otros te contribuyan?
130k triangulos... necesitas implementar algun LOD para q sea utilizable en juegos
si, tengo que ajustar la distancia y el maximo de subdivisiones del lod.... y un monton de cosas mas.... igual estoy pensando en cambiar las "piezas", planos 18*18 (16*16 + una fila extra de borde) ...por otros que sean 14*14 (12*12 + fila extra) ...igual incluso 10*10 (8*8 + 1fila extra)....
el planeta minimo ahora mismo serian 6 planos de 18*18 (16*16)...
y le he puesto que haga hasta 8 veces la subdibision... o baje a 7 creo... con lo cual al final si que hay un montonazo de poligonos...
pero igual simplemente poniendo otro plano con menos poligonos bajaria el "poliCount"... pero hay que hacerlo el plano un poco especialito.... tiene que ser un modelo (plano) que mida 2*2 (desde 1,0,1 hasta -1,0,-1) ....menos la ultima fila, la de los bordes (la extra), que tiene que esta "fuera de los limites" para que se superpongan (se solapen, "z-fight" creo que se llamaba) ...luego esos son los bordes que "doblamos"...
lo del "Lod" ...se supone que es lo que hace... cada plano 18*18 se divide en cuatro planos 18*18, ...la subdibision ese hace en funcion a la distancia... osea, mas cerca hay mas poligonos, y mas lejos hay menos...
pero creo que lo he hecho demasiado progresivo y lejos sigue habiendo mas de los que deveria...
ajustare unas cuantas cosas... y limpiare cosas que sobran...
cuando este mas avanzado y limpio quizas lo comparta
Muy bueno tu resultado, te voy a pedir ayuda cuando llegue la hora de texturizar mi planeta xD, yo me quede con mi esfera y ahora estoy empezando a programar el LOD, una vez que eso este ajustado pienso hacer una clase que implemente el noise para generar los terrenos y recien por ultimo el texturizado, la atmosfera, la generacion de vegetacion, etc.
Ya tengo un poco avanzado el LOD pero todavía estoy ajustándolo para que funcione como yo quiero, aca dejo una imagen:
(http://drive.google.com/uc?export=view&id=1dfRXK2vkZjK7H7AHQq3BmPk5sU0Zd_6w)
Espero que una vez hecho esto la implementacion de la función de noise no genere problemas entre las diferentes mallas.
Cita de: Jeko37 date=1527315889Espero que una vez hecho esto la implementacion de la función de noise no genere problemas entre las diferentes mallas
Muy bueno te esta quedando, supongo que el LOD se lo vas a tener que aplicar a la version ruidosa y no aplicar el ruido a la version LODeada... no?
Cita de: Jeko37 date=1527315889Espero que una vez hecho esto la implementacion de la función de noise no genere problemas entre las diferentes mallas.
tal como lo tienes te va a pasar el mismo problema que a mi... las uniones entre planos de diferente "LOD"... yo lo solucione haciendo un plano "especial" (ya lo he explicado antes) ... y el la parte del codigo donde generas las "mallas", al final del todo, despues de aplicar el ruido, las normals, y la textura... entonces "bajo" un poco los ultimos vertices (tienes que saber que vertices son los de los bordes, y simplemente restarles su "normal" eso hara que esten mas "abajo")
mi "malla":
se puede apreciar en los bordes de cada pieza los poligonos extra solapados (y doblados, "bajados")
detalle de la union con fila extra:
Estuve documentandome sobre el problema y efectivamente si, el noise lo tengo que aplicar primero sobre la esfera sin ningun noise aplicado y sobre esa esfera con noise ir haciendo el LOD, la solución tuya de restar la malla de menor resolucion para poner encima la de mayor resolucion no me parece una solución muy elegante, estarias procesando vértices de la malla oculta de forma innecesaria, lo ideal seria ir eliminando las que ya no uses, por otro lado la forma en la que aplicas el LOD esta buenisimo, te quedó mucho mejor que a mi, voya dejar el lod de lado y concentrarme en el noise, lo voy a retomar una vez tenga el planeta formado.
Consulta: a alguien más le pasa que cuando quiere iniciar sesión le rebota la contraseña? cada vez que entro a publicar tengo que resetear la contraseña porque me aparece como invalida.
Cita de: Jeko37 date=1527374033Consulta: a alguien más le pasa que cuando quiere iniciar sesión le rebota la contraseña? cada vez que entro a publicar tengo que resetear la contraseña porque me aparece como invalida.
si intentas entrar en el foro con el correo suele dar problemas...
es mejor entrar con el nombre de usuario
y si, se que no es una solucion elegante... pero llevaba tiempo atascado ahi... y queria avanzar un poco... asi que de momento voy a usar esa solucion...
ya le he añadido agua, atmosfera, y nubes... todo un poco provisional y mejorable... ahora estoy mirando a ver como pongo arboles...
Genial! estas mucho mas avanzado que yo, yo acabo de hacer una función de "noise" tipo prototipo para ir programando el LOD sobre eso y después me voy a ocupar de afinarla bien para que genere cosas interesantes.
Acá está mi esfera ruidosa! :)
(http://drive.google.com/uc?export=view&id=1feJPfW7FpL-Sghij-K_BNPmIo0RBZqxR)
Tengo un problema con la iluminacion y los Mesh, cuando hago el LOD, obviamente tengo que generar Mesh con más resolución de cuadriculas y eso me esta dando dos problemas, aunque por ahora solo quiero abordar el que creo es más sencillo de solucionar, el tema de la iluminación me queda bastante extraño mostrando iluminaciones raras en las zonas donde los Mesh se unen
(http://drive.google.com/uc?export=view&id=1aAhYxSxhy4PPKffhhnLTxV_S9DgeNdgQ)
¿Como puedo solucionar este problema?
Estuve leyendo y dicen que después de mani***r los vertices (cuando aplico el noise y armo la malla con más resolucion) tengo que ejecutar RecalculateNormals(); que es exactamente lo que yo estoy haciendo pero aún asi el fenomeno sigue apareciendo.
¿Alguna idea?
pues te he estado diciendo en los post de antes... que yo lo he solucionado poniendo una fila extra.... superpuestas, solapadas, y dobladas.... con esto arreglas las "normals" y rellenas algun hueco que se crea entre las piezas de diferente "tamaño/resolucion"...
Cita de: Jeko37 date=1527558099¿Alguna idea?
Quizás los vértices entre mesh y mesh deberían estar "weldeados", me perdí un poco y no se porque son diferentes mesh (quizás por el LOD) pero si son distintos vértices y están en la misma posición eso no te asegura que te vaya a quedar lindo como querés y quizás sea la razón de lo que te pasa...quizás. Es decir vas a tener que tener un solo vértice que las una, osea no existirían varias mesh juntas sino una sola, el LOD debería afectar a toda una gran mesh, igual que pasa con un terrain.
Cita de: Igor date=1527587061pues te he estado diciendo en los post de antes... que yo lo he solucionado poniendo una fila extra.... superpuestas, solapadas, y dobladas.... con esto arreglas las "normals" y rellenas algun hueco que se crea entre las piezas de diferente "tamaño/resolucion"...
Habia entendido otra cosa con lo del post anterior, ahora entiendo perfectamente xD de todas maneras creo que debe haber una solución para este problema que no implique superponer los mesh, si tengo que hacerlo lo voy a hacer pero quiero explorar antes otras alternativas.
Cita de: lightbug date=1527593500Quizás los vértices entre mesh y mesh deberían estar "weldeados", me perdí un poco y no se porque son diferentes mesh (quizás por el LOD) pero si son distintos vértices y están en la misma posición eso no te asegura que te vaya a quedar lindo como querés y quizás sea la razón de lo que te pasa...quizás. Es decir vas a tener que tener un solo vértice que las una, osea no existirían varias mesh juntas sino una sola, el LOD debería afectar a toda una gran mesh, igual que pasa con un terrain.
Es posible que si, que tenga que weldear los mesh, yo actualmente lo que hago es ocultar el mesh de mayor resolución con
enabled = false y luego crear 9 submeshes de mayor resolucion que ocupan el mismo espacio del mesh que oculte. O sea que yo tendria que unir los submeshes de diferentes resoluciones en un unico mesh.
la solucion buena es muy compleja... cada pieza tiene que saber que piezas tiene a los lados... y dependiendo de si son "mayor" o "menor" tendrias que adaptar los bordes...
fijate en esta imagen de ejemplo.
en la izquierda, los vertices conflictivos (marcados con estrellitas)
en la derecha, borde de la pieza adaptado
esta solucion es mas compleja de implementar...
...y para que el sombreado (las "normals") sea "continuo" tendrias que acceder a las piezas vecinas para ver las normales de los siguentes vertices... para poder calcular las normals de los bordes corretamente... que tambien tiene su historia...
con la solucion (chapuzera) de superponer o solapar una fila extra solucionas las dos cosas, la iluminacion(normals) y los huecos que se generan por las diferentes alturas que tienen los vertices con estrellitas de la imagen... porque esos vertices con estrellita no existen en las piezas vecinas...
Si, la verdad parece algo muy complejo y que llevaria demasiado tiempo, igual si lo hiciera todavia me quedaria el problema de medir las distancias de los meshen con menos LOD para ir ajustando la resolucion, es decir si solo tengo un mesh weldeado, como hago para saber cuando subir la resolucion del mesh? hoy lo estoy haciendo midiendo la distancia de la camara con respecto a la ubicacion de los meshes. En fin, un bajon que se empiece a complicar asi.
Cita de: lightbug date=1527593500Quizás los vértices entre mesh y mesh deberían estar "weldeados", me perdí un poco y no se porque son diferentes mesh (quizás por el LOD) pero si son distintos vértices y están en la misma posición eso no te asegura que te vaya a quedar lindo como querés y quizás sea la razón de lo que te pasa...quizás. Es decir vas a tener que tener un solo vértice que las una, osea no existirían varias mesh juntas sino una sola, el LOD debería afectar a toda una gran mesh, igual que pasa con un terrain.
es eso que dices... al ser diferentes "mesh" la union no va a quedar "linda"... tienes que acceder a los "mesh" vecinos y ver como tienen los vertices siguientes a la union para poder calcular las "normals" para que quede lindo... y es un poco lio... sobretodo si no sabes la numeracion de tus vertices... ni que "mesh" tienen a cada lado...
asi que les puse la fila extra para solucionarlo...
Cita de: lightbug date=1527593500...osea no existirían varias mesh juntas sino una sola, el LOD debería afectar a toda una gran mesh, igual que pasa con un terrain.
los terrain si que puedes tener varios unos junto a otros (en cuadricula) y si te fijas tienen variables public para que le asignes cada uno de los vecinos (neighbour) (norte, sur, este y oeste) ... y el mismo sistema de terrenos de unity se encarga de calcular las correctas normals de las uniones para que el sombreado quede continuo...
es una pena no poder ver el codigo de los terrenos de unity, eso nos ayudaria, porque los terrenos de unity hacen el LOD como en la imagen que he mandado... que es la solucion correcta...
lo de medir las distancias parece complejo, pero es mas facil de lo que parece... primero las subdibisiones tienen que ser hijas de la pieza anterior... y asi todo el rato... osea tengo uno de los 6 lados de la esphera, lo subdibido, y a esas subdibisiones les digo que su padre es el que las ha subdibidido... y ese padre lo "apago" si estas mas cerca de una distancia, esas subdibisiones las subdibido y las hago hijas otra vez... y apago las padre, ....y si te alejas apago las hijas y enciendo el padre... mas o menos... porque hay que comprobar si tiene hijos antes de subdibidirlo, si no tiene hijos pues subdibides y apagas el padre, si SI tiene hijos (porque ya los has creado antes al acercarte a esa zona..) ...pues simplemente los enciendes y apagas el padre...
Cita de: Igor date=1527604816lo de medir las distancias parece complejo, pero es mas facil de lo que parece... primero las subdibisiones tienen que ser hijas de la pieza anterior... y asi todo el rato... osea tengo uno de los 6 lados de la esphera, lo subdibido, y a esas subdibisiones les digo que su padre es el que las ha subdibidido... y ese padre lo "apago" si estas mas cerca de una distancia, esas subdibisiones las subdibido y las hago hijas otra vez... y apago las padre, ....y si te alejas apago las hijas y enciendo el padre... mas o menos... porque hay que comprobar si tiene hijos antes de subdibidirlo, si no tiene hijos pues subdibides y apagas el padre, si SI tiene hijos (porque ya los has creado antes al acercarte a esa zona..) ...pues simplemente los enciendes y apagas el padre...
Eso es justamente lo que estoy haciendo ahora, decia que es dificil medir cuando no hay diferentes mesh sino uno solo todo calculado con sus nuevas cuadriculas weldeadas, porque ahi ya no habrian mesh hijos de otros meshes.
Supongamos que teoricamente tengo localizados dos vertices vecinos que comparten la misma ubicación pero aún asi pasa lo que les mostré en la imagen, como tendria que calcular las normales para que quede bien? que calculo deberia realizar exactamente?
https://docs.unity3d.com/Manual/ComputingNormalPerpendicularVector.html (https://docs.unity3d.com/Manual/ComputingNormalPerpendicularVector.html)
ahi explican lo sencillo que es calcular una normal de un vertice en un triangulo...
en tu caso tendrias que buscar todos los triangulos que "usan" ese vertice en tu mesh, y en el mesh vecino, sumas todos y le haces "Normalize()"... lo dificil es buscar los triagulos del vecino...
Cita de: Igor date=1527604816los terrain si que puedes tener varios unos junto a otros (en cuadricula) y si te fijas tienen variables public para que le asignes cada uno de los vecinos (neighbour) (norte, sur, este y oeste) ... y el mismo sistema de terrenos de unity se encarga de calcular las correctas normals de las uniones para que el sombreado quede continuo...
es una pena no poder ver el codigo de los terrenos de unity, eso nos ayudaria, porque los terrenos de unity hacen el LOD como en la imagen que he mandado... que es la solucion correcta..
Cita de: Jeko37 date=1527600358Es posible que si, que tenga que weldear los mesh, yo actualmente lo que hago es ocultar el mesh de mayor resolución con enabled = false y luego crear 9 submeshes de mayor resolucion que ocupan el mismo espacio del mesh que oculte. O sea que yo tendria que unir los submeshes de diferentes resoluciones en un unico mesh.
Si, a lo que iba es que no es necesario encarar el problema con distintas meshes y adaptar el borde (lo crítico del asunto) , sino tener una gran mesh y dar detalle a la zona de interés, esto te da mucha más versatilidad ya que podés tener un detalle "que se mueve" con la cámara por ej (o no, como en este caso) y no tener dar detalle a la mesh X que está cerca, con los problemas que eso trae (lo que está pasando ahora).
El algoritmo funcionaría exactamente como un "adaptative tesselation". Es una técnica que hace tiempo que se ve mucho sobretodo en terrains, esas demo de outerra, voxel terrains y demás, un ej:
eature=oembed" width="480">
otro ej :
eature=oembed" width="480">
Con lo de las filas extras tenés que tener info de los vertices compartidos y de los vertices que le siguen a ambos lados ya que querés que la transición sea suave para formar al vector normal, identico a las tangentes de las curvas de animación, para que se entienda, es como decís @Igor pude ser alto quilombo esto ya que necesitas info de la de al lado (con suerte si toca un solo vecino y no tres en una punta). Acá además no podés hacer magia con un shader (Ej decirle que interpole normales) ya que son objetos diferentes (diferentes meshes, diferentes materiales)... Además que teniendo más y más meshes estás introduciendo un "overhead" ya que metés info de más innecesaria (nuevo gameObject, nuevas instancias de materiales, nuevos meshrenderers, nuevos meshFilters, etc) quizás con 10,100 o 1000 no se note pero es medible sin dudas a la larga.
muy lindo el tema este, cuando tengan algo más o menos suban una demo pa la gilada que lo testeamos
Cita de: lightbug date=1527621263Si, a lo que iba es que no es necesario encarar el problema con distintas meshes y adaptar el borde (lo crítico del asunto) , sino tener una gran mesh y dar detalle a la zona de interés, esto te da mucha más versatilidad ya que podés tener un detalle "que se mueve" con la cámara por ej (o no, como en este caso) y no tener dar detalle a la mesh X que está cerca, con los problemas que eso trae (lo que está pasando ahora).
El algoritmo funcionaría exactamente como un "adaptative tesselation". Es una técnica que hace tiempo que se ve mucho sobretodo en terrains, esas demo de outerra, voxel terrains y demás
probe varios shaders de tessellation y no funcionan en mi PC... o igual es que estoy haciendo algo mal...
este sistema que estamos usando tiene ese problema que dices... al final puedes acabar teniendo demasiados objetos... pense en borrar las piezas que no se usan... pero entonces tendria que estar creando todo el rato... asi que decidi que se quedasen desactivadas para no tener que crearlas de nuevo... pero al final igual es mejor borrarlas.... nose...
bueno:
planet.zip ahi teneis una "demo" por si quereis probar...
esta muy "en pañales" todabia... tengo que mejorar mil cosas... ajustar las distancias a las que se cambian las piezas... arreglar un "errorcillo" que tengo en el metodo de la fila extra... porque empujo los vertices finales hacia abajo pero siempre la misma distancia... indepemdientemente del tamaño de la pieza... y en piezas grandes se sigue apreciando un poco de "z-fighting" de ese... me acabo de fijar... jeje... ya lo arreglare... y tengo que mejorar el mar, la atmosfera, las nubes... meter unas texturas mejores, que las actuales son solo de 512... y mil cosas mas...
No te preocupes que cuando tenga el planeta listo voy a subir el codigo a github para todos, pero me gustaria tener algo bien hecho para eso. La verdad si soluciono los dos problemas que actualmente tengo, el tema de las uniones en los mesh, y arreglar los vertices en las uniones con mesh de menor resolucion, podria empezar a limpiar codigo y crear rutinas que eliminen mesh viejas (podria guardar en memoria los parametros para su creacion cuando sean necesarias, eso tendria el problema del reprocesamiento del mesh, pero no ocupariamos tanta memoria).
Si la verdad es un lindo desafio, en este momento estoy trabado pero seguramente lo terminare solucionando.
te quedo muy bueno @Igor , esto se produce por las filas inventadas esas?
Cita de: lightbug date=1527715317te quedo muy bueno @Igor , esto se produce por las filas inventadas esas?
si, asi es, los planos tiene una fila extra de poligonos por cada lado... estas filas son dobladas hacia abajo despues de calcular las "normals"...
tengo que poner que se bajen esos vertices en proporcion al tamaño... ahora se bajan una cantidad fija... y para las piezas pequeñas queda muy bajado... y para las piezas grandes queda muy poco bajado... en las muy grandes a veces se ponen tan "planos" que se superponen unos con otros y queda feo... y en las muy pequeñas pasa eso que se ve en las imagene... cuando lo ponga en proporcion al tamaño quedara un poco mejor la union en las piezas muy grandes... (cuando estas muy lejos)
...aunque en realidad estoy dibujando un monton mas de triangulos para arreglar el problema de las uniones...
No soy experto ni nada pero, si intentas hacer un "sistema de GENERACIÓN de planetas ALEATORIO" tienes que darte cuenta que al iniciar la escena se va a cargar muchos objetos y puede que si el planeta es lo suficientemente grande la escena tardaria unos 10 minutos o más para cargar todo y más aún si eso se repite cada vez que se inicia la escena con nuevos planetas y diferentes posiciones, según yo creo que sería mejor "instanciar" prefabs de planetas ya creados manualmente (o como quieras) y poner un sistema de chunks que hará que la carga de la escena sea más rápida.
Yo digo de esa manera, talvez ya lo tienes resuelto, pero es mi opinión y puede ser que te sirva.
Si algún dia lo terminas me gustaria probarlo xD Saludos!
Cita de: Alex date=1527741248
Si algún dia lo terminas me gustaria probarlo xD Saludos!
colge una demop hace un par de dias...
Cita de: Igor date=1527639205
planet.zip
ahi teneis una "demo" por si quereis probar...
hola, he estado unos dias desconectado, pero ayer estube trasteando un poco el proyecto del planeta...
os dejo una nueva demo, he rebajado el numero de triangulos, pero he mejorado el "acabado"... estoy probando diferentes maneras de meter vegetacion.... ahora la he dejado desactivada
(wasd = mover, espacio = turbo)
planetLod.rar
nueva demo del planeta :)
(enlace del "Drive")
https://drive.google.com/file/d/1DSyBf8JxLM24nV2ABGNWvciBxeO0pv6H/view?usp=drive_web (https://drive.google.com/file/d/1DSyBf8JxLM24nV2ABGNWvciBxeO0pv6H/view?usp=drive_web)
Cita de: Alex date=1527741248No soy experto ni nada pero, si intentas hacer un "sistema de GENERACIÓN de planetas ALEATORIO" tienes que darte cuenta que al iniciar la escena se va a cargar muchos objetos y puede que si el planeta es lo suficientemente grande la escena tardaria unos 10 minutos o más para cargar todo y más aún si eso se repite cada vez que se inicia la escena con nuevos planetas y diferentes posiciones, según yo creo que sería mejor "instanciar" prefabs de planetas ya creados manualmente (o como quieras) y poner un sistema de chunks que hará que la carga de la escena sea más rápida.
Yo digo de esa manera, talvez ya lo tienes resuelto, pero es mi opinión y puede ser que te sirva.
Si algún dia lo terminas me gustaria probarlo xD Saludos!
la escena no tarda nada en cargar... tarda como un segundo o asi... en cuanto le das al play se genera el planeta... se lo va "inventando" todo en tiempo real... no crea todo el planeta a la vez... de primeras lo que crea son seis planos de 18*18... y luego ya va dando mas "resolucion" a las partes cercanas, subdibidiendolas en cuatro planos de 18*18... una y otra vez (hasta un limite) ...
conforme te acercas a una zona, esa zona es la que se subdibide...
he metido tambien un poco dd "tessellation" (GPU) al terreno (con displazament) para darle un poco mas de detalle...
la texturas tambien son generadas en tiempo real... cuando se crea cada "cacho"...
y encima cuando estas cerca, tiene que calcular las posiciones de los arboles (muchos), tambien en tiempo real, que se almacenan... los arboles los dibuja la GPU, pero todo los demas son muchos calculos para hacer en la CPU... y eso hace un poco de "cuello de botella" al programa... y la verdad que cuando tiene que "crear" muchos cachos a la vez bajan los FPS.... :(
he bajado un poco la "velocidad de vuelo" para que no tenga que crear tantos cachos a la vez... y he limitado la cantidad de cachos que se pueden crear a la vez a 3.... pero valla... a la CPU le cuesta... si bajo a menos de 3 a la vez, poco a poco al final no le da tiempo a "seguirte" al escenario, y se empieza a "generar" tarde...
...y la "velocidad de vuelo" no quiero bajarla mas...
en unos dias colgare otra demo con los nuevos avances...
hola, les dejo una nueva demo:
https://drive.google.com/file/d/1V2nDwSznrwgUEG1fU***t-DSGHNEmdhL/view?usp=drivesdk (https://drive.google.com/file/d/1V2nDwSznrwgUEG1fU***t-DSGHNEmdhL/view?usp=drivesdk)
he aumentado el tamaño del planeta, mejorado (un poco) la texturizacion del terreno, añadido "s***line" (espuma en las costas) al agua...
la demo incluye un par de pruebas que estoy haciendo para recrear galaxias y sistemas solares...
WASD = mover (como siempre)
Q / E = rotar
espacio = turbo
en la demo del sistema solar la tecla "TAB" activa/desactiva las lineas de las orbitas
con la nave, pulsando raton1, disparas...
pulsando raton2, apuntas/te detienes (vas un poco para atras)
