[buen]

Pues eso, con la reciente adquisicion de mi nuevo reproductor mp3, he visto que solo se basa en el tag ID3 del archivo para organizar la libreria, con lo que o bien me hago playlists a saco (ya las tengo) o me pongo a renombrar/editar todos mis ficheros mp3.
Asi que lo que busco es un editor de ID3 para cambiar facilmente los tags, pero no puede ser uno cualquiera, deberia tener estas caracteristicas (a grandes rasgos):
- Editar varios ficheros a la vez para cambiar uno o varios campos del ID3, p.e. seleccionar los mp3 de un disco y decirle "esto es tal grupo y tal disco".
- Pasarle un fichero con los titulos y que lo rellene en base a un patron que le indique yo, p.e 'autor - numero pista - titulo'.
- Cambiar el nombre del fichero en base al tag o viceversa, rellenar el tag con lo que pone en el nombre del fichero (dandole un patron a seguir).

En definitiva, busco un buen editor ID3. Antes que programarlo yo mismo prefiero saber si ya existe, que no me extrañaria (por lo de no reinventar la rueda y eso). Creo que todos nosotros hemos deseado un programa asi alguna vez, asi que tiene que existir!

Primero una breve introduccion para poneros en el tema. Hasta hace pocos meses tenia un Creative MuVo 1Gb. La calidad del reproductor me dejo bastante satisfecho, tanto auriculares (que aun conservo) como el propio reproductor. Lo que pasa es que se apagaba de repente cuando le apetecia, asi que lo envie al servicio tecnico y ahi me lo perdieron los muy cabrones. Total, que me sale mas a cuenta comprar uno nuevo que pelearme con ellos para no conseguir nada.

Aqui os pongo una lista de mis preferencias a la hora de buscar, ordenadas de mayor a menor importancia:
- Buena calidad de sonido, al menos como el MuVo.
- Larga duracion de la bateria, a poder ser recargable.
- Minimo 1Gb de memoria (preferiblemente a partir de 2-3Gb).
- Bajo peso (que no me haga ladearme cuando camine con el...).
- Que salga informacion clara en el display (hay reproductores realmente malos en ese aspecto, y jode mucho).
- Precio: no mas de 180-200 euros.

Con esto en mente y viendo que Creative, a parte de en SAT, son decentes en calidad/precio, he visto que el ZEN Micro esta bastante bien, sobre todo en esta oferta de Fnac.
Mis preguntas son: ¿lo habeis probado alguien? ¿que opinion teneis de el? ¿alguna sugerencia mejor? (podeis variar un poco mis preferencias, estoy abierto a sugerencias).

 Bueno, ahora que esta tan de moda el tema casual gaming y el mercado shareware para los grupos independientes os propongo unas preguntas para ver que opinais, mirando de favorecer el exito del proyecto.

¿Que tematicas creeis que son mas apropiadas para juegos shareware? ¿Deberian estar enfocados a los casual gamers o es inependiente de que sean shareware?

Tras ver el exito que han tenido juegos como Tribal Trouble, he pensado que muchas veces el exito viene dado por el aspecto gracioso del juego. Pensando en hacer un juego de esta indole junto con varias personas, estabamos barajando varios tipos de argumentos para el juego. En mi opinion el humor es un factor clave a la hora de diseñar el concepto del juego y la historia, ya que al menos le da un aliciente para no resultar aburrido.

¿Que generos de juegos pensais que se benefician mas de esta caracteristica?

[del juego]

 Me gustaria saber como meteis la parte de IA en vuestro engine. Aunque creo que la pregunta deberia ser mas general. ¿Que entendeis por IA orientada a juegos? Me refiero a nivel de que tareas desarrolla la IA.
Yo habia imaginado que el marco de trabajo son controladores para objetos de la escena, que puedan modificar la transformacion (posicion,rotacion,escala) o efectuar alguna otra operacion sobre el objeto, como añadir,modificar o quitar mas objetos de su jerarquia (sacar un arma) o cambiar de animacion (correr->saltar).

¿Que opinais? ¿Hay algo que me deje por el camino? Pensad que esto es solo el marco de trabajo, ya que cuando programe la IA del juego estara scriptada usando este framework. La accion de disparar seria ir metiendo diferentes tipos de controladores al objeto que maneja la IA.

 Bueno, ya que el otro thread sobre scenegraphs no ha tenido exito, voy a ver si en este me llegan mas opiniones para decidir.
Al final he optado por tener una lista de objetos (prototipos) cargados en memoria, como un manager de recursos. Esto me permite tener instancias de los mismos para crear las vistas de la escena.
Una de esas vistas es la espacial, en la que tengo la organizacion jerarquica de las instancias en la escena.

Ahora tengo que decidir que estructuras usar para particionar el espacio y organizar la geometria.
Voy a separar la geometria en dos tipos: estatica, para geometria que no se mueve (no tiene nada que ver con animacion) y dinamica, para geometria que se mueve por la escena. Creo que tienen que estar separadas en diferentes estructuras, ya que tenerlo todo junto tiene bastantes inconvenientes.
Mi pregunta es, ¿que tipo de estructuras usais/usariais para cada tipo? La geometria estatica no necesita una ED optima en cuanto añadir/quitar nodos, simplemente ofrecer buen rendimiento al visitarla para culling o colisiones. La geometria dinamica necesita un poco mas de trabajo, puesto que cuando se mueve un objeto hay que recalcular la jerarquia de volumenes o incluso volver a añadir el objeto en el arbol para resituarlo en un espacio en el que quepa mejor. ¿Sugerencias?

 Bueno, siguiendo con mis threads sobre diseño, aqui va uno sobre grafos de escena (SG).

Primero un poco de introduccion siguiendo el patron MVC. Por un lado tenemos una lista con los objetos de la escena, nuestro modelo. Luego tenemos los SG que son nuestras diferentes vistas.
Nuestra vista base es un SG que guarda relaciones de dependencia entre objetos (referenciados de la lista), nada de transformaciones ni bounding volumes.
Ahora hay que definir las vistas que vamos a usar. En mi opinion antes hay que definir que operaciones vamos a realizar sobre las vistas.
Esto ya depende de cada motor. En mi ultimo proyecto tenia una unica vista que me guardaba la transformacion y el bounding volume en cada nodo. Este SG lo usaba para actualizar la transformacion y la jerarquia de bounding volumes (BVH) cada vez que movia un objeto. Tambien lo usaba para el culling, obteniendo una cola de objetos a dibujar que se pasa al renderer. No habia ni colisiones, ni fisica, ni animacion, asi que no lo tuve en cuenta.

Despues de leer un poco sobre el tema, he visto que se puede hacer mucho mas eficiente.
Actualizacion de la escena. Utilizaria un arbol n-ario normal y corriente, una vista basica que guarde en cada nodo la transformacion. Simplemente cuando se modifica un nodo, su transformacion se pasa hacia las hojas y se va actualizando la transformacion global de cada nodo.
Rendering. Podemos tener un arbol con prioridades en cada nivel para ordenar los objetos que se van a dibujar en funcion del material (algo como lo que se habla en delphi3d sobre ordenacion por estados).
Culling. Habria que ver que estructuras espaciales van mejor en funcion del tipo de escena. He leido que algunas van muy bien para geometria estatica (octree/quadtree/abt), y otras para mantener geometria dinamica.
Colisiones. Seguramente con usar las mismas vistas que para culling seria suficiente, aunque teniendo en cuenta que solo colisionan objetos dinamicos contra dinamicos o estaticos.

Habria que usar el patron Observer para notificar a las vistas de los cambios en la lista de objetos (adicion/eliminacion de objetos) y viceversa, si cambia algo en una de las vistas, hay que hacerselo saber a la lista para que actue convenientemente (notificando a otras vistas implicadas p.e.).


Y bien, ¿que opinais? A parte de que el sistema pueda ser demasiado complejo y todas eso, el caso es que se usa y es muy flexible. Siempre puedes tener una simple vista como hice en mi anterior proyecto, pero si defines un sistema abstracto te da pie a reusar del codigo (lo mas importante) y futuras ampliaciones.

¿Como organizais vosotros las escenas?

[Shadow mapping.]

 Bueno, estaba pensando en que metodo usar para hacer sombras en el motor que estoy diseñando. Supongo que utilizare shadow mapping, ya que puedo reutilizar mucho codigo de mi ultimo proyecto (aunque habria que refactorizarlo un poco).

Despues de pensar un rato, me he dado cuenta de que las cosas han cambiado mucho. La mayoria de documentacion sobre algoritmos de sombras o iluminacion es bastante vieja, y no suele tener muy en cuenta los grandes (enormes) avances a los que se ha llegado con las GPUs actuales.
Vamos a discutir un poco sobre los metodos para hacer sombras, con sus ventajas e inconvenientes.

Shadow mapping.
- Es un algoritmo rapido, ya que solo requiere una pasada extra por cada luz y puede hacer sombras de modelos muy teselados sin demasiada sobrecarga.
- Self-shadowing automatico.
- Sufre de aliasing, que puede ser subsanado con una transformacion de perspectiva. Hay varias implementaciones: PSM, LiSPSM, TSM. Suelen ser un poco complicadas de implementar, aunque dan buenos resultados.
- Con el uso de un pixel shader se puede acelerar la construccion del depth map.
- Las nuevas tarjetas con sus extensiones (como FBO en OpenGL) permiten evitar la copia a memoria del render para tener un depth map en una textura. Se puede compartir directamente, disminuyendo el coste de los renders extra para los depth maps.

Shadow volumes.
- Depende mas de la geometria que proyecta la sombra, ya que hay que calcular el contorno y luego extruirlo.
- El self-shadowing creo que no funciona tan bien como con los shadow maps.
- No sufre de aliasing
- Puede acelerarse la extrusion (y busqueda) del contorno para proyectar la sombra.
(No se mucho mas sobre shadow volumes, asi que alguien mas podria ir completando la lista con lo que falte).

Pues bien, en mi opinion creo que los shadow maps son un algoritmo genial, ya que de cada dia los modelos estan mas teselados, aunque no se hasta que punto beneficia la GPU en la extrusion del contorno. Eso si, hay que implementar algun tipo de correccion de la perspectiva (LiSPSM y TrapezoidSM parecen dar muy buen resultado, aunque la ultima diria que quieren patentarla).
Ademas, ahora casi todas las tarjetas graficas (al menos dentro de 6 meses a 1 año) tienen las extensiones/caracteristicas necesarias.

 Ultimamente hay un tema que me ronda mucho la cabeza: ¿saben realmente los que estudian ingenieria informatica lo que estan haciendo?
Hablando desde lo que veo en mi universidad, creo que es una carrera que esta demasiado masificada. Mucha gente la hace porque dicen que tiene mucha salida y chorradas de esas. Otros simplemente piensan que la informatica es reinstalar windows o picar codigo para programas de gestion, cosas que puedes hacer con el titulo de analista o tecnico.

Mi principal frustracion es cuando llego a asignaturas de 4º curso y veo que mucha gente sigue sin tener ni idea de programar, que hace 3 años que no programan en c++ y no saben hacer una clase ni que es polimorfismo. Pero no es que sean los tipicos vagos, no, estudian como el que mas. Todo esto me lleva a pensar que sigue siendo como en el cole: estudiar a piñon para sacarse la asignatura en cuestion y luego olvidarlo todo.
Si les interesa tan poco la carrera, ¿por que la estudian? Nadie les obliga como en el cole, y pasarse de 5 a 8 años pagando de 2 a 7k euros por año (segun donde vivan) para estudiar algo que simplemente escogieron por sus supuestas salidas no me entra en la cabeza.

La pregunta es, ¿es normal que un ingeniero informatico no sepa programar a falta de un año para titularse? ¿Que salidas ofrece esta carrera que no requieran de esta habilidad? Claro que puedes investigar, administrar una base de datos, montar un proyecto, dar clases, etc.; aunque diria que es mas que recomendable saber programar a algun nivel incluso para eso.

[QUOTE]

 He estado leyendo unos apuntes de Ingenieria del Software y he pensado que podria utilizar UML y la metodologia que se expone para diseñar un juego.
Segun lo que he visto y leido por ahi, muchas de estas metodologias se aplican principalmente a software orientado a negocios, con un flujo de acciones bastante marcado y que para videojuegos quizas aun no le ha llegado el momento.
Por otro lado no deja de ser una herramienta, la usas cuando es necesaria, no es un dogma que seguir al pie de la letra para obtener resultados.

Bueno, al grano. Estas son mis preguntas:
¿Cuales serian los actores? En principio seria el usuario y el reloj del juego, pero si separamos cada subsistema y sacamos sus casos de uso, pueden aparecer los otros subsistemas como actores.
¿Que casos de uso podriamos tener en un juego? Algo asi como esto

QUOTE (Post en GameDev.net)

Title: Using environment items as weapons. Description: A character can pick items and use it as weapons to hit enemies. Actors: Main Character (MC), Enemy Character (EC), item (weapon). Principal flow: - MC approaches an item he wants to pick. - Item gets added to MC's inventory. - MC activates item as principal weapon. - MC hits EC with his principal weapon. [/quote] ¿Deberian ser todos los casos de uso sobre el juego o habria que clasificarlos entre juego y motor? ¿Y si separamos por subsistemas? Me gustaria saber vuestras opiniones al respecto, tanto para las preguntas que he hecho como del tema en general: utilidad de UML y de Use Cases para diseñar un motor/juego. ¿Alguno de aqui lo usais? PD: para el que le interese, he hecho un thread mas o menos igual para conocer mas opinones (a ver si tiene exito :huh: ). #10 General / Chapter Igda En Barcelona 04 de Diciembre de 2005, 07:17:44 PM  Desde el pasado dia 18 de Noviembre, ya esta funcionando el Chapter IGDA de Barcelona. Estaria bien contactar con ellos para que participen en las quedadas que se hagan en BCN. Aunque la web esta vacia, ya esta montado, lo cual es un comienzo. ¿Que opinais de que exista el chapter? ¿Sirve de ayuda? #11 Proyectos / Dudas Sobre El Diseño De Un Juego 29 de Noviembre de 2005, 12:08:08 PM  Buenas, pues queria exponeros unas dudas para contrastar opiniones o pedir consejo sobre la implementacion del guion del juego. Hasta ahora lo unico que he hecho ha sido programar demos de tecnicas o motores (excepto un proyecto entero de simulacion, aunque no era un juego). Lo que tengo en mente ahora es hacer un arcade/aventura no muy complicado, mas que nada para aprender y sobre todo para terminarlo. Tengo el argumento del juego y una sinopsis del guion, pero a partir de ahi me surgen diversas dudas. Voy a comenzar a diseñar el engine para ese tipo de juegos (para hacer algunas piezas reutilizables), ¿deberia tener en cuenta el guion de la historia para diseñarlo o con pensar varios escenarios y analizar diversos casos de uso me basta? ¿Como meteis el guion dentro del juego? Habia pensado en una especie de grafo de sucesos (cada suceso necesita de 1...n sucesos padre completados para ocurrir) y cada uno con un trigger asociado. ¿Cuan largo y completo suele ser el guion? Ya que si el juego debe durar un rato, deberia tener muchas cosas para hacer. ¿Como diseñais eso? Bueno creo que nada mas por ahora. Gracias. #12 General / Trabajar En Barcelona 04 de Julio de 2005, 10:19:28 PM  Quiero trabajar en el sector, pero no se si ir por libre o como becario, ya que tengo la mitad de la carrera. ¿Alguno trabajais o habeis trabajado de becario? ¿Que tal es? He visto que en la bolsa de empleo de stratos hay algunas ofertas por aqui cerca, pero no me atrevo aun a mandar el CV; prefiero preguntaros aqui un par de dudas que tengo al respecto. Os pongo un poco en situacion: De los 16 a los 18 estuve haciendo un programa de gestion en la empresa de mi padre (el ultimo año a tiempo completo), lo cual me dio mucha experiencia, pero claro sin contrato. ¿Hay alguna manera de hacer que eso cuente en el curriculum? Tengo el codigo fuente y puedo demostrar que es mio, de hecho este verano tengo que terminar el susodicho programa (aunque probablemente en la misma situacion :P ). Otra cosa es el proyecto de graficos que hacemos en la universidad. Cuando lo presentemos (1a semana de septiembre) sera la caña, muy bonito tecnicamente y todo eso. ¿Tambien entra en el CV? ¿Piden muchos trabajos hechos para pillarte? Me da cosa que me digan 'bueno, has hecho un buen proyecto, ¿algo mas?' y me quede con las ganas, por mucho que le diga que he empezado varias cosas que no han llegado a buen puerto. Claro que siempre me puedo buscar un curro de admin de bbdd, pero prefiero experiencia en el sector del videojuego. ¿Que opinais? PD: Por muy bueno que me considere como diseñador de software (lo q mas me gusta d la informatica), ¿hasta que punto te 'dejan' demostrarlo? No se si me explico  :huh:   #13 Programación gráfica / Compatibilidad Con Shaders 27 de Mayo de 2005, 10:53:12 AM  Hace unos dias ya que estoy mirando como se hacen los shaders, pero ahora me ha asaltado una duda. Estuve mirando con la aplicacion glView que tarjetas soportan ps y vs y he visto que es de la FX para arriba (no me acuerdo de que ATi). Si escribo un shader con GLSL, puede correr en una FX? y si solo es vertex shader, va en una GF4Ti? (lo mismo para las homonimas en ATi). Lo pregunto porque si no es asi, supongo que si quieres usar shaders en un programa, tendras que hacer versiones en GLSL y en ensamblador ese tan feo, y eso es lo ultimo que quiero. PD: ya podemos ir migrando todos a shaders, son lo mejor!!  B)   #14 Programación gráfica / Filtros Para Texturas 09 de Mayo de 2005, 06:06:04 PM  Estoy mirando unos papers para implementar Subsurface Scattering (simular piel, cera, plastico, marmol, ...). En concreto los Translucent Shadow Maps. La tecnica requiere integrar la luz que llega a cada punto de la superficie del objeto (mapa de irradiancia) en funcion de la normal en ese punto, la normal en el punto que dibujamos y una funcion de la distancia entre los 2 puntos. El paper dice que se puede hacer mucho mas facil usando un filtro jerarquico, con los mipmaps de las texturas que hacemos desde el pov de la luz (mapa de irradiancia, normales y profundidad). ¿Como puedo seleccionar el texel en el mipmap que yo quiera? Primero tengo que hacer un pase desde la luz, usando Multiple Render Targets para sacar las texturas que he nombrado antes; luego tengo que hacer los mipmaps (¿me vale la funcion de gluBuild2DMipmaps?) y finalmente desde la camara dibujar la escena y para cada pixel aplicar el filtro en las texturas con los mipmaps correspondientes. Se que es chungo de explicar, pero basicamente necesito saber como funciona ese tipo de filtros (los pesos me los da la funcion de distancia de los dos puntos). Ademas me gustaria saber si habeis usado los MRTs para dibujar simultaneamente en varias texturas y no tener que hacer tantos pases. #15 Programación gráfica / Efecto De Hielo, Metal Y Cristal 07 de Marzo de 2005, 02:10:27 PM  Tenemos que hacer un proyecto para la universidad que consiste en reproducir de la forma mas realista posible una partida de ajedrez. Uno de los requisitos que hemos puesto es tener materiales bonitos para las piezas, p.ej. hielo, metal, cristal, madera, marmol, ... con su iluminacion y todo eso. He pensado que para las reflexiones lo mas conveniente es usar cubemaps, pero no se si tienen mucha utilidad en materiales que no sean metalicos. ¿Le tengo que dar algun tipo de alfa o blur a la reflexion si no es metal? Ademas el cristal y el hielo tendran que refractar, ¿como lo consigo? A ver si me podeis orientar un poco que ando algo perdido. He leido el tutorial de nVidia sobre cubemaps, pero aun asi me quedan dudas sobre como hacerlo realista. Saludos #16 Jad Engine / Arquitectura Y Diseño Del Motor 04 de Marzo de 2005, 07:18:27 PM  Acabo de ver el segundo video y esta muy bien, muy buenas las caracteristicas que mostrais, felicidades :D ¿Podriais explicar como habeis diseñado el motor? Prerrequisitos, arquitectura, modulos, ... ¿Que metodologia habeis usado para diseñarlo? En una asignatura tenemos que hacer un proyecto, visualizar de la manera mas realista posible una partida de ajedrez. Tras pensar los prerrequisitos, hemos comenzado a plantear cuales seran los modulos y que estrategia de diseño vamos a usar. Ahora me gustaria saber como lo hace la gente para sus proyectos, ya que aun no tengo experiencia en ingenieria del software. #17 General Programadores / Diseño De Vuestro Framework 23 de Diciembre de 2004, 11:34:24 PM  Bueno, hacia mucho que no posteaba en stratos :cry: Llevaba tiempo sin tocar el engine y ahora he vuelto a pensar en el y me he decidido a terminar de plantear el diseño sobre papel. Supongo que la primera pregunta cuando queremos diseñar un programa es: ¿Que es lo que quiero? Pues lo que quiero es un framework para construir un engine(s) sobre el. A parte de comunicar con el SO, necesito toda una serie de entidades para manejar recursos; tales como texturas, sonidos, mallas, bufferes, nodos, terrenos, etc... Mi pregunta es: a la hora de hacer el diseño, que pensais? como definis que es lo que hace cada entidad, cual depende de cual, quien controla a quien, etc... Si por ejemplo una textura debe saber dibujarse o es el renderer el que lo sabe? o una mezcla de ambas? y si es asi, hasta que punto? La respuesta facil es decir que se sabe con la experiencia, pero me gustaria ir mas alla y comparar diseños de la gente del foro, seguro que se puede reunir informacion y elaborar una especie de FAQ. #18 Programación gráfica / Collision Detection 29 de Septiembre de 2003, 07:49:52 PM  Pues eso, voy a comenzar con el tema de las colisiones en el engine y por ahora lo veia facil ya que pensaba solo en el siguiente caso: colision entre una esfera/caja y otra esfera/caja. Por ejemplo un personaje con el suelo, con un arbol, una roca, etc... Pero claro, y si tengo q pasar a traves del objeto? (un granero, cobertizo, puente cubierto, ...). Mi pregunta es: que sera mas eficiente? usar un OBB-Tree o sacar un convex hull (con un editor de modelos, precalculando los puntos del hull y sacando una especie de malla de <100 triangulos contra la q colisionar)?? #19 Programación gráfica / Como Chupan Las Matrices Y Vectores! 11 de Agosto de 2003, 07:08:31 PM  Pues eso, q me chupan un huevo... de fps las jodias. He visto q me baja de 999fps (el maximo del fraps) a 450fps con solo llamar a una funcion. La funcion es la q calcula la transformacion en world coordinates, q lo unico q hace es esto: Código [Seleccionar] Expand void WorldObject::UpdateWorldData(float fDeltaTime) {    if ( m_pkParent )    {        m_fWorldScale = m_pkParent->m_fWorldScale*m_fScale;        m_kWorldRotate = m_pkParent->m_kWorldRotate*m_kRotate;        m_kWorldTranslate = m_pkParent->m_kWorldTranslate +            m_pkParent->m_fWorldScale*(m_pkParent->m_kWorldRotate *            m_kTranslate);    }    else    {        m_fWorldScale = m_fScale;        m_kWorldRotate = m_kRotate;        m_kWorldTranslate = m_kTranslate;    } } el scale es un float, rotate una matrix3 y translate un vector. Es muy raro pq las funciones d multiplicar matrices y vectores y todo eso las he cogido de un engine q vi. Lo unico q hice fue meter las clases d matriz, vector, etc... en un .lib y ademas las hice inline y todo pa q sea mas rapido. La funcion esta se llama cada frame. Es demasiado tiempo el q consume, se me hace raro... Alguna sugerencia? puede ser q al estar en un .lib no las haga inline y eso chupe tanto? no se, en estas cosas no controlo #20 Programación gráfica / Occlusion Culling 11 de Agosto de 2003, 11:29:48 AM  Bueno, he implementado una jerarquia de nodos en mi engine y le he añadido el frustum culling. Los bounding volumes los guardo en una clase cuyos miembros son: radio, vector centro, y 6 floats con las esquinas de la bounding box (axis-alligned) top, bottom, left, right, front y back. Para probar contra el frustum d la camara uso la esfera ya q es mas rapido, aunq puedo ponerle un flag a las meshes con las q vaya mejor un test de boundingbox pero weno, eso es una optimizacion q no viene al caso. Ahora ha llegado el momento de implementar el occlusion culling, el cual es una maravilla. Para los q no lo sepan simplemente es un frustum (o conjunto de planos) que ocluyen el espacio que encierran, al contrario que el frustum d la camara (o viewing frustum) que muestra el espacio q encierra. Pues bien, este conjunto de planos tengo pensado sacarlo con la bounding box del objeto, ya que como mucho son 6 planos (se ven 3 caras de la caja como mucho, las cuales forman un contorno de 6 lados) lo cual es mucho mas optimizado q usar un convex hull y sacar su contorno q puede ser d muchos planos. Estos planos los añado a la camara para usarlos en su funcion de culling (prueba una esfera con los planos del frustum completo, usea viewing+occlusion) Por supuesto el computo del occlusion frustum solo lo haran los objetos q yo marque como posibles occluders, que en mi caso actual me interesa que sean los nodos del quadtree, ya q pueden tener varios miles d vertices tal como tengo ahora el quadtree y el terreno (sin LOD). Aqui pongo un screenshot del terreno con los boundingboxes de cada hoja del quadtree (todos los nodos tienen bbox, no solo las hojas) El triangulo rosa es la camara, las lineas verdes vienen a ser el viewing frustum. Sin el occlusion culling se verian 12 nodos (ya los he contado yo). Ahora vienen mis teorias para que las corrijais/comenteis. El rectangulo rojo seria la parte de la bounding box del nodo mas cercano a la camara con cuyas aristas hariamos los planos de oclusion (seguid leyendo para entender esta parte si no la veis). Si implemento el OC supongo q deberia ordenar a los posibles occluders por distancia con la camara y usar este algoritmo: Código [Seleccionar] Expand for each x WorldObject in OccluderList  if(!isCulled(x))    Plane *planes = CalcularPlanosDeBoundingBox(x.Bound, Camara.Location)    Camara.PushPlanes(planes)    Renderer.Draw(x) Tenemos que comprobar si el objeto esta fuera del frustum, ya que el q venia antes ha podido añadir una serie de planos al frustum que ocluyen a otros ocluders; por ejemplo un camion ha tapado a la caseta d la once q tapaba a esa tia tan wena q mirabamos, la caseta d la once y el camion son occluders los dos, pero la caseta ha sido tapada por el camion, asi q ya no la computamos. El algoritmo para sacar los planos no lo tengo muy claro. Tengo que mirar que caras apuntan a la camara (cada cara son 4 lados ya q es un cubo, no hace falta bajar hasta triangulos) y con las aristas q forman el contorno (las cuales no se como sacar) hacer un plano mediante 2 puntos de la arista y location d la camara. Si alguien tiene algun comentario q lo diga Páginas1 2 Ayuda | Ir Arriba ▲ SMF 2.1.4 | SMF © 2013, Simple Machines Síguenos en Aviso legal Tratamiento de datos Seguridad Cookies © 2024 Stratos Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad. Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante. Muchísimas gracias.

 Desde el pasado dia 18 de Noviembre, ya esta funcionando el Chapter IGDA de Barcelona.
Estaria bien contactar con ellos para que participen en las quedadas que se hagan en BCN. Aunque la web esta vacia, ya esta montado, lo cual es un comienzo.
¿Que opinais de que exista el chapter? ¿Sirve de ayuda?

 Buenas, pues queria exponeros unas dudas para contrastar opiniones o pedir consejo sobre la implementacion del guion del juego.

Hasta ahora lo unico que he hecho ha sido programar demos de tecnicas o motores (excepto un proyecto entero de simulacion, aunque no era un juego). Lo que tengo en mente ahora es hacer un arcade/aventura no muy complicado, mas que nada para aprender y sobre todo para terminarlo.

Tengo el argumento del juego y una sinopsis del guion, pero a partir de ahi me surgen diversas dudas.
Voy a comenzar a diseñar el engine para ese tipo de juegos (para hacer algunas piezas reutilizables), ¿deberia tener en cuenta el guion de la historia para diseñarlo o con pensar varios escenarios y analizar diversos casos de uso me basta?
¿Como meteis el guion dentro del juego? Habia pensado en una especie de grafo de sucesos (cada suceso necesita de 1...n sucesos padre completados para ocurrir) y cada uno con un trigger asociado.
¿Cuan largo y completo suele ser el guion? Ya que si el juego debe durar un rato, deberia tener muchas cosas para hacer. ¿Como diseñais eso?

Bueno creo que nada mas por ahora. Gracias.

 Quiero trabajar en el sector, pero no se si ir por libre o como becario, ya que tengo la mitad de la carrera. ¿Alguno trabajais o habeis trabajado de becario? ¿Que tal es?
He visto que en la bolsa de empleo de stratos hay algunas ofertas por aqui cerca, pero no me atrevo aun a mandar el CV; prefiero preguntaros aqui un par de dudas que tengo al respecto.
Os pongo un poco en situacion:
De los 16 a los 18 estuve haciendo un programa de gestion en la empresa de mi padre (el ultimo año a tiempo completo), lo cual me dio mucha experiencia, pero claro sin contrato. ¿Hay alguna manera de hacer que eso cuente en el curriculum? Tengo el codigo fuente y puedo demostrar que es mio, de hecho este verano tengo que terminar el susodicho programa (aunque probablemente en la misma situacion :P ).
Otra cosa es el proyecto de graficos que hacemos en la universidad. Cuando lo presentemos (1a semana de septiembre) sera la caña, muy bonito tecnicamente y todo eso. ¿Tambien entra en el CV? ¿Piden muchos trabajos hechos para pillarte? Me da cosa que me digan 'bueno, has hecho un buen proyecto, ¿algo mas?' y me quede con las ganas, por mucho que le diga que he empezado varias cosas que no han llegado a buen puerto.

Claro que siempre me puedo buscar un curro de admin de bbdd, pero prefiero experiencia en el sector del videojuego. ¿Que opinais?

PD: Por muy bueno que me considere como diseñador de software (lo q mas me gusta d la informatica), ¿hasta que punto te 'dejan' demostrarlo? No se si me explico  :huh:  

 Hace unos dias ya que estoy mirando como se hacen los shaders, pero ahora me ha asaltado una duda.
Estuve mirando con la aplicacion glView que tarjetas soportan ps y vs y he visto que es de la FX para arriba (no me acuerdo de que ATi). Si escribo un shader con GLSL, puede correr en una FX? y si solo es vertex shader, va en una GF4Ti? (lo mismo para las homonimas en ATi).

Lo pregunto porque si no es asi, supongo que si quieres usar shaders en un programa, tendras que hacer versiones en GLSL y en ensamblador ese tan feo, y eso es lo ultimo que quiero.


PD: ya podemos ir migrando todos a shaders, son lo mejor!!  B)  

 Estoy mirando unos papers para implementar Subsurface Scattering (simular piel, cera, plastico, marmol, ...). En concreto los Translucent Shadow Maps.
La tecnica requiere integrar la luz que llega a cada punto de la superficie del objeto (mapa de irradiancia) en funcion de la normal en ese punto, la normal en el punto que dibujamos y una funcion de la distancia entre los 2 puntos.
El paper dice que se puede hacer mucho mas facil usando un filtro jerarquico, con los mipmaps de las texturas que hacemos desde el pov de la luz (mapa de irradiancia, normales y profundidad).
¿Como puedo seleccionar el texel en el mipmap que yo quiera? Primero tengo que hacer un pase desde la luz, usando Multiple Render Targets para sacar las texturas que he nombrado antes; luego tengo que hacer los mipmaps (¿me vale la funcion de gluBuild2DMipmaps?) y finalmente desde la camara dibujar la escena y para cada pixel aplicar el filtro en las texturas con los mipmaps correspondientes.

Se que es chungo de explicar, pero basicamente necesito saber como funciona ese tipo de filtros (los pesos me los da la funcion de distancia de los dos puntos). Ademas me gustaria saber si habeis usado los MRTs para dibujar simultaneamente en varias texturas y no tener que hacer tantos pases.

 Tenemos que hacer un proyecto para la universidad que consiste en reproducir de la forma mas realista posible una partida de ajedrez.
Uno de los requisitos que hemos puesto es tener materiales bonitos para las piezas, p.ej. hielo, metal, cristal, madera, marmol, ... con su iluminacion y todo eso.

He pensado que para las reflexiones lo mas conveniente es usar cubemaps, pero no se si tienen mucha utilidad en materiales que no sean metalicos. ¿Le tengo que dar algun tipo de alfa o blur a la reflexion si no es metal?
Ademas el cristal y el hielo tendran que refractar, ¿como lo consigo?

A ver si me podeis orientar un poco que ando algo perdido. He leido el tutorial de nVidia sobre cubemaps, pero aun asi me quedan dudas sobre como hacerlo realista.


Saludos

 Acabo de ver el segundo video y esta muy bien, muy buenas las caracteristicas que mostrais, felicidades :D

¿Podriais explicar como habeis diseñado el motor? Prerrequisitos, arquitectura, modulos, ... ¿Que metodologia habeis usado para diseñarlo?
En una asignatura tenemos que hacer un proyecto, visualizar de la manera mas realista posible una partida de ajedrez. Tras pensar los prerrequisitos, hemos comenzado a plantear cuales seran los modulos y que estrategia de diseño vamos a usar. Ahora me gustaria saber como lo hace la gente para sus proyectos, ya que aun no tengo experiencia en ingenieria del software.

 Bueno, hacia mucho que no posteaba en stratos :cry:

Llevaba tiempo sin tocar el engine y ahora he vuelto a pensar en el y me he decidido a terminar de plantear el diseño sobre papel.
Supongo que la primera pregunta cuando queremos diseñar un programa es: ¿Que es lo que quiero? Pues lo que quiero es un framework para construir un engine(s) sobre el. A parte de comunicar con el SO, necesito toda una serie de entidades para manejar recursos; tales como texturas, sonidos, mallas, bufferes, nodos, terrenos, etc...

Mi pregunta es: a la hora de hacer el diseño, que pensais? como definis que es lo que hace cada entidad, cual depende de cual, quien controla a quien, etc... Si por ejemplo una textura debe saber dibujarse o es el renderer el que lo sabe? o una mezcla de ambas? y si es asi, hasta que punto?
La respuesta facil es decir que se sabe con la experiencia, pero me gustaria ir mas alla y comparar diseños de la gente del foro, seguro que se puede reunir informacion y elaborar una especie de FAQ.

 Pues eso, voy a comenzar con el tema de las colisiones en el engine y por ahora lo veia facil ya que pensaba solo en el siguiente caso: colision entre una esfera/caja y otra esfera/caja. Por ejemplo un personaje con el suelo, con un arbol, una roca, etc...

Pero claro, y si tengo q pasar a traves del objeto? (un granero, cobertizo, puente cubierto, ...). Mi pregunta es: que sera mas eficiente? usar un OBB-Tree o sacar un convex hull (con un editor de modelos, precalculando los puntos del hull y sacando una especie de malla de <100 triangulos contra la q colisionar)??

 Pues eso, q me chupan un huevo... de fps las jodias. He visto q me baja de 999fps (el maximo del fraps) a 450fps con solo llamar a una funcion. La funcion es la q calcula la transformacion en world coordinates, q lo unico q hace es esto:

Código [Seleccionar] Expand


void WorldObject::UpdateWorldData(float fDeltaTime)
{
   if ( m_pkParent )
   {
       m_fWorldScale = m_pkParent->m_fWorldScale*m_fScale;
       m_kWorldRotate = m_pkParent->m_kWorldRotate*m_kRotate;
       m_kWorldTranslate = m_pkParent->m_kWorldTranslate +
           m_pkParent->m_fWorldScale*(m_pkParent->m_kWorldRotate *
           m_kTranslate);
   }
   else
   {
       m_fWorldScale = m_fScale;
       m_kWorldRotate = m_kRotate;
       m_kWorldTranslate = m_kTranslate;
   }
}

el scale es un float, rotate una matrix3 y translate un vector. Es muy raro pq las funciones d multiplicar matrices y vectores y todo eso las he cogido de un engine q vi. Lo unico q hice fue meter las clases d matriz, vector, etc... en un .lib y ademas las hice inline y todo pa q sea mas rapido. La funcion esta se llama cada frame. Es demasiado tiempo el q consume, se me hace raro... Alguna sugerencia? puede ser q al estar en un .lib no las haga inline y eso chupe tanto? no se, en estas cosas no controlo

 Bueno, he implementado una jerarquia de nodos en mi engine y le he añadido el frustum culling. Los bounding volumes los guardo en una clase cuyos miembros son: radio, vector centro, y 6 floats con las esquinas de la bounding box (axis-alligned) top, bottom, left, right, front y back. Para probar contra el frustum d la camara uso la esfera ya q es mas rapido, aunq puedo ponerle un flag a las meshes con las q vaya mejor un test de boundingbox pero weno, eso es una optimizacion q no viene al caso.

Ahora ha llegado el momento de implementar el occlusion culling, el cual es una maravilla. Para los q no lo sepan simplemente es un frustum (o conjunto de planos) que ocluyen el espacio que encierran, al contrario que el frustum d la camara (o viewing frustum) que muestra el espacio q encierra.

Pues bien, este conjunto de planos tengo pensado sacarlo con la bounding box del objeto, ya que como mucho son 6 planos (se ven 3 caras de la caja como mucho, las cuales forman un contorno de 6 lados) lo cual es mucho mas optimizado q usar un convex hull y sacar su contorno q puede ser d muchos planos. Estos planos los añado a la camara para usarlos en su funcion de culling (prueba una esfera con los planos del frustum completo, usea viewing+occlusion)

Por supuesto el computo del occlusion frustum solo lo haran los objetos q yo marque como posibles occluders, que en mi caso actual me interesa que sean los nodos del quadtree, ya q pueden tener varios miles d vertices tal como tengo ahora el quadtree y el terreno (sin LOD). Aqui pongo un screenshot del terreno con los boundingboxes de cada hoja del quadtree (todos los nodos tienen bbox, no solo las hojas)


El triangulo rosa es la camara, las lineas verdes vienen a ser el viewing frustum. Sin el occlusion culling se verian 12 nodos (ya los he contado yo). Ahora vienen mis teorias para que las corrijais/comenteis.
El rectangulo rojo seria la parte de la bounding box del nodo mas cercano a la camara con cuyas aristas hariamos los planos de oclusion (seguid leyendo para entender esta parte si no la veis).

Si implemento el OC supongo q deberia ordenar a los posibles occluders por distancia con la camara y usar este algoritmo:

Código [Seleccionar] Expand


for each x WorldObject in OccluderList
 if(!isCulled(x))
   Plane *planes = CalcularPlanosDeBoundingBox(x.Bound, Camara.Location)
   Camara.PushPlanes(planes)
   Renderer.Draw(x)


Tenemos que comprobar si el objeto esta fuera del frustum, ya que el q venia antes ha podido añadir una serie de planos al frustum que ocluyen a otros ocluders; por ejemplo un camion ha tapado a la caseta d la once q tapaba a esa tia tan wena q mirabamos, la caseta d la once y el camion son occluders los dos, pero la caseta ha sido tapada por el camion, asi q ya no la computamos.

El algoritmo para sacar los planos no lo tengo muy claro. Tengo que mirar que caras apuntan a la camara (cada cara son 4 lados ya q es un cubo, no hace falta bajar hasta triangulos) y con las aristas q forman el contorno (las cuales no se como sacar) hacer un plano mediante 2 puntos de la arista y location d la camara.

Si alguien tiene algun comentario q lo diga