Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Menu

Mostrar Mensajes

Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menu

Mensajes - senior wapo

#616
 Una errata:

para la tangente se usa la mitad del angulo, asi que no es tan (90) sino tan(45):

// FOV 90 = 1.0 =  tan( 45.0 * M_PI / 360.0);

Aparte de que la tangente de 90 es infinito, si usaras 90 tendrias un FOV de 180 grados (90 a cada lado). No afecta al código, solo al comentario por si quieres usar otro ángulo.
#617
 
Cita de: "LudwigVan"¿Porque decimales? Es decir, tengo un cuadrado de 0.6 unidades y me ocupa alomejor un 20% de la pantalla asi que supongo que la pantalla o al menos para esto de las primitivas es de 1x1 ¿?

Como me oriento para poner cosas por la pantalla?, en 2d por ejemplo tenia la referencia clara de los pixeles.
Intentaré no usar palabrejas raras y que sea sencillito, lo prometo  (twist)

En 3D la referencia es la coordenada Z (o lo que uses de profundidad) y la amplitud de tu campo de visión. Mira a tu alrededor, si te colocas un libro 1 metro a tu derecha no lo ves. pero si retrocedes un par de metros, lo ves aparecer en tu campo de vision, ¿verdad?

Para convertir de pixeles a coordenadas 3D:

Cuando Z=1, el primer pixel por la izquierda es la coordenada x=-1, y el pixel más a la derecha x=1 (ancho de pantalla=2). Si dibujas el objeto más lejos, por ejemplo a profundidad z=5, entonces el pixel más a la izquierda es x=-5 y el más a la derecha x=5.  Básicamente, si ignoramos el factor de corrección,  el ancho de las coordenadas se multiplica por Z.

¿ Y el factor de correción de que depende ?
Pues de la amplitud de tu campo de visión. Se le llama FOV (Field of View) y en los humanos oscila entre 45 y 60 grados a cada lado. Yo uso 90 grados de FOV (45+45),  Blizt3D usa 90 grados, ID software usa 90 grados (desde el viejo wolf3D hasta DOOM3), Irrlicht engine usaba 45 (o 60, lo cambiaron hace poco). 90 grados tiene unas propiedades matemáticas muy ventajosas, aunque ese es otro tema de post.

Hablo de 90 grados horizontalmente (derecha a izquierda). La pantalla es mas ancha que alta, asi que poner el mismo FOV verticalmente comprimirá las imagenes verticalmente y aparecerá todo achatado, para que quepa el mismo angulo en menos pixeles. Lo solucionas con un FOV menor verticalmente.

En OpenGL el FOV lo ajustas con la función glFrustum. Estrictamente, lo que ajustas son los planos de corte ("clipping planes"), pero viene a ser lo mismo.

Olvidate de gluPerspective, si usas FOV  90 grados, simplemente inserta estas líneas de código justo antes del primer glTranslate (justo debajo de donde ajustas las matrices de modelo y proyección):


  float zNear = 3.0f;
  float fov_value_x = zNear  * 1.0f;   // FOV 90 = 1.0 =  tan( 90.0 * M_PI / 360.0);
  float aspect_ratio_y = (GLfloat)alto_pantalla/(GLfloat)ancho_pantalla;
  aspect_ratio_y *= fov_value_x;

  glFrustum( -fov_value_x, fov_value_x, -aspect_ratio_y, aspect_ratio_y, zNear, 8192.0f );

Si usas un campo de visión distinto pues usas la formula del comentario de fov_value_x

3.0 y 8192 son la coordenada mínima y máxima de profundidad que planeas poder visualizar. Cuanto más restringidas (menos amplio), más precisión tendrás en el bufferZ y menos errores aparecerán al dibujar dos superficies casi superpuestas (casi misma Z). Si no lo entiendes, déjalo como está.

Si te he liado demasiado (seguro que si) dime donde te tengo que aclarar algo  :D
#618
General / Motor 3d Para Mover Una Ciudad Virtual
23 de Diciembre de 2004, 12:12:15 PM
 Este es un proyecto gigantesco (en todos los sentidos), olvídate de motores gráficos como torque, necesitas un paquete de visualización específico.

#619
General / Hacer Algo Útil
18 de Diciembre de 2004, 10:48:07 PM
 Algo util es algo que cubre una necesidad no cubierta aún. Eso de entrada descalifica los motores 3D. En el mundillo free, faltan cosas como:

- Un editor de niveles 3D. Todo lo que ves por ahi son minimodeladores, como si un nivel fuese solo la geometria. Soporte de entidades, caminos y nodos, areas, triggers, spawn points, conexion a DBMS para extraer la informacion no geométrica y trabajar en grupo. Soporte de plugins/scripts para generación de contenidos procedural (o te colocas los 324 arbustos a mano, uno a uno).
- Una herramienta de reducción poligonal (y si no jode mucho los canales UV y recalcula los materiales, mejor que mejor).
- Una herramienta de gestión contenidos (CVS para el apartado artístico). Es un follón tremendo organizar modelos, texturas, niveles, scripts, musica, efectos de sonido, shaders, scripts de FX particulas, etc... con varias personas trabajando juntas y teniendo que mantener distintas versiones del mismo recurso por si hay que echarse para atrás en un momento dado.
- Una herramienta de localización a otros idiomas robusta, con buen GUI, conexión a DBMS y soporte de metainformación (no veas que risa cuando traduces el texto pero el engine no cambia automáticamente el archivo de voz al mismo idioma, etc...)
- Exportadores de formatos o conversores.
- Una herramienta de generación de contenidos. Hay programas que generan arboles, plantas y terrenos. Y alguno que modela humanos (no, Poser no, MakeHuman de blender  :P ). También hay generadores de Dungeons cuadriculados (pero no crean mallas 3D por ejemplo)..

- En general, cualquier cosa que consolide 2 o màs pasos de workflow en uno solo. O permita hacer 1 paso de una manera mas rápida o menos propensa a errores o simplemente menos estresante.



Si no te referias a herramientas, sino a como organizarse al hacer juegos y no tirar el tiempo reinventando la rueda o haciendo cosas inútiles, pues ese, ya es otro post  :D  
#620
Proyectos / Elegir Motor Par Aun Videojuego
17 de Diciembre de 2004, 08:18:37 PM
 
Cita de: "Jedive"Estas seguro? Mark Sibly, el autor, dijo que Blitz3D compila a código nativo. Por lo visto hay un stub precompilado con toda la librería y tal, y el código que mete en el recurso del EXE es código máquina real, pero así se ahorra el tener que hacer un linker.
Si, tienes razón. No es interpretado sino compilado. Edito el post de más arriba para no propagar falsa información. O mejor no lo edito, que se me ha pasado el tiempo  :P  
#621
Proyectos / Elegir Motor Par Aun Videojuego
17 de Diciembre de 2004, 05:19:53 PM
 Rectifico: Blitz3D si es interpretado, es una maquina virtual como pueda ser java. El ejecutable generado es el VM y los bytecodes van insertados en un recurso del ejecutable.

En lo demas de Blitz3D, me reafirmo    :D  
#622
Proyectos / Elegir Motor Par Aun Videojuego
17 de Diciembre de 2004, 01:29:32 PM
 Pues depende, y mucho, del ámbito del proyecto y de vuestra experiencia y forma de trabajar. Tampoco pones si ha de ser 100% gratuito o aceptais engines de 100$ o menos.

Yo he estado mirando motores ultimamente y al final me he decidido por Blitz3D (100 euros).  Pero porque mis necesidades eran muy peculiares  :D

Sobre los motores más importantes, aqui van mis impresiones personales (lo subrayo que luego me muerden los fans de unos y otros):

Ogre3D:  Potente motor de rendering, pero solo hace eso. API3D: OpenGL, DirectX7 y DirectX9.
Problemas:
- 1,000,123 millones de dependencias DLL y ficheritos de configuración.
- Casca malamente en mi portatil (los otros motores no).
- 1 hola mundo ocupa varios megas.
- Necesitas meterle Ode/Tomahawk/ColDet para collisiones, OpenAL para sonido, etc. etc...
- LGPL asi que olvidarte de linkar estatico, solo como DLLs (como 6+ DLLs por proyecto)
Ventajas:
- Calidad de rendering y buen diseño.
- Si solo necesitas motor de visualización puede ser muy adecuado. No tener sonido, colisiones etc... lo pongo también aqui como ventaja, segun el caso.
Otros:
Juegos comerciales: 1 juego lo usa (VTrike)
Tamaño Hola Mundo: 3MB+ de DLLS del motor, mas otro MB y pico de dependencias DLLs

Irrlicht: Motor de rendering y colisiones. API3D: OpenGL, DirectX8 y DirectX9
Problemas:
- Medianamente lento (muy lento si usas sombras dinamicas)
- Poca calidad de rendering
- Diseño poco elegante y  poco ampliable
- Shaders cutres y no multiplataforma (EDITO: motor multiplataforma, los shaders no, has de usar shaders nativos)
- Aun muy joven y con demasiados bugs, pero es funcional.
Ventajas:
- Muy facil de aprender
- Excelente para prototipar juegos, puedes tener algo decente funcionando en 1 dia.
- Amplio soporte de formatos 3D
- Incluye colisiones y "extras" bastante utiles.
- Compacto, ocupa poco.
- Puedes linkar estatico y no tiene dependencias externas.
Otros:
Juegos usandolo: Ninguno.
Hola Mundo: 800KB link estatico

NeoEngine: No lo he mirado mucho, pero tiene buena pinta. Poca documentación y algo engorroso de manejar. API3D: OpenGL y DirectX8
- Su autor abandonó el desarrollo y su desarrollo actual es más lento que el nuevo Duke Nukem, y con su mismo futuro  :P
- Puedes linkar estatico.
- Siento no poder decirte mas, no le dediqué mucho tiempo.

Nebula Device 2: Un ganador, hecho por profesionales del videojuego y se le nota. Gran motor de Juegos. API: DirectX9 (DX8 y OpenGL en la vieja version Nebula1). Es el engine que yo elegiria si hiciera un proyecto grande y de ultima tecnologia.
Problemas:
- Dificil de aprender bien, has de urgar en el codigo fuente para entenderlo porque la documentación es básicamente inexistente.
- No funciona con la tarjetas radeon 7x00 de ATI, pero supongo que lo arreglarán. El parche consiste en perder la funcionalidad de sombras.
- Arquitectura un tanto peculiar = te costará acostumbrate un poco.
- Poca comunidad de usuarios, encontrar información para Nebula2 es complicado (para Nebula1 no).
- Solo para Win32 (Nebula1 soporta Windows y Linux).
- Curva de aprendizaje lenta.
Ventajas:
- Buena calidad de rendering.
- Rapido
- Versatil
- Buen diseño
- Motor de Juegos, no de rendering solo. Integra ODE para colisiones, y motor propio para lo demás (sonido, input, visibilidad, etc...)
- Link estatico
- Excelente soporte de scripting integrado (LUA, TCL(mini) de serie ).
Otros:
Juegos usandolo: La versión Nebula1 utilizada por 25+ juegos comerciales (Project Nomads el más conocido). Nebula2 por ninguno aún, creo.
Hola Mundo: 1.8MB link estatico

Crystal Space: No hay nada que ver, circulen, circulen.

Torque Games Engine (100$-450$): Motor de juegos. API3D: OpenGL y DirectX7
Ventajas:
- Tecnología probada y que funciona. Diseñado por profesionales. Fue el motor del juego Tribes, de Dinamyx.
- Gran comunidad de usuarios.
- Funciona en Mac, Windows y Linux
- Incluye los fuentes
Inconvenientes:
- Excasa documentación.
- Con la licencia de 100$, si superas cierto numero de ventas, has de pagar por la licencia de 450$
- No incluye editor de niveles (recurrir a editores externos en un engine de pago es una desventaja).
- Sin shaders de serie, has de comprar (y pagar) por la actualización a TSE que además aún no está del todo pulida.
Otros:
Juegos usandolo:Tribes (comercial) y bastantes juegos shareware (ThinkTanks, etc...).

DarkBasic: Ni me molesté, estando Blitz3D que tiene mejor motor, mejor lenguaje y es mas rapido.

Blitz3D (100$): Compilador (no interprete) Basic con soporte DirectX7. Junto con Torque, es el motor "Indie" por excelencia.
Ventajas:
- Muy facil de usar
- Gran comunidad de usuarios, excelente archivo de funciones contribuidas por los usuarios.
- Desarrollo muy rapido.
- Excelente herramienta de prototipado rapido, es a la programación 3D lo que Clipper era a las bases de datos y VisualBasic -a... ...bueno, se me entiende  :D
- Compilador, no es un intérprete. No requiere runtime ni ninguna DLL externa.
- Sorprendentemente, buen rendimiento del código (si se usa bien).
- Acepta DLLs externas para ampliar tus programas con código en C/ASM/Pascal... lo que sea.
- Motor DirectX7 (si, versiones anteriores a DX8 son una ventaja para ciertos propósitos).
- Editor de niveles muy facil de usar (Maplet). Por cierto, ahora es gratuito e independiente de Blitz3D.
Inconvenientes:
- Editor de niveles rudimentario (Maplet)
- Lenguaje Basic: Nada de orientación a objetos
- No soporta unidades de compilación, 1 cambio implica recompilar todos los fuentes del programa, ya que son meros "INCLUDES" en el principal y no ficheros compilables por separado.
- Motor DirectX7 (es decir, no shaders)
Otros:
- Tamaño Hola Mundo: 1MB
- Juegos usandolo: Muchos Shareware (Best Friends, PacLands, etc...) (@Jedive: Century esta hecho en Blizt3D? tienes una captura en su foro...)

Cypher engine (100$)Motor de juegos. Lo conozco poco, lo que pongo no lo se de primera mano (sino de webs, foros....)
Ventajas:
- Incluye codigo fuente
- Desarrolladopor un profesional del videjuego.
- Muy completo (Networking, sonido, etc...)
- La mejor opción para desarrollar FPS (clones de Quake).
Inconvenientes:
- No incluye editor de niveles (creo)
- Orientado a FPS, desconozco que tal se adapta a otro estilo de juegos.


En resumen, si quieres hacer un triple AAA/techdemo te recomiendo Nebula Device 2, si quieres hacer un juego share, te recomiendo Blitz3D (si me apuras, Torque/cypher para un FPS, pero un FPS share....) . Si quieres aprender, Irrlicht.
Es muy dificil (por no decir imposible) encontrar un motor DirectX7 gratuito (y decente), todos son OpenGL o DX8-DX9. Para juegos share (publico casual, no hardcore), leas lo que leas, solo te conviene DX6 o DX7 (olvidate de DX8+ o de OpenGL, se ponga aquí la gente como se ponga) .

Un saludo.
#623
General / Desarrollo Indie
14 de Diciembre de 2004, 12:38:33 AM
 Gracias a todos por las respuestas. Tendré en cuenta las distintas opciones.

Lo que sigo sin saber es de que manera se facturan los graficos en caso de comprarlos: algo asi como X $ por modelo con 2 animaciones, o XXX$ por pack o como diablos sea, vaya, que no se como valorar si me estan timando (en caso de optar por encargar modelos a un grafista).

No se si afecta en algo, pero por si acaso, aclaro que en juegos Indie hablamos de modelos 3D para PCs de la época DirectX6 - DX7, graficos al estilo de lo que serian los de Nintendo64, para PCs de no mas de 600Mhz. Nada de cosas muy detalladas.

Un saludo.
#624
General / Desarrollo Indie
12 de Diciembre de 2004, 06:00:35 PM
 Hola a todos, a ver si podeis aclararme una duda.

Tras haberme recorrido internet en busca de información Indie, mas o menos tengo claro que el primer paso viene a ser terminar y publicar un juego simplón, por ejemplo, un remake de arkanoid (eso, que hay pocos) o pacman o mahjong y similares. Hasta ahi, muy bien: hacemos eso, ganamos experiencia de marketing, de negocios, de atención al cliente, de desarrollo, la paciencia, miramos con mejores ojos la idea de dedicarnos a freir hamburguesas, ponemos los pies en el suelo, y no esperamos ver un duro en los primeros juegos. Ok.

La cuestion es, pasada la fase puzle-remake (si la llegas a pasar ), ¿ cuanto cuesta pagar por la musica y los graficos ? Hablo de modelos 3D animados y con materiales aplicados. Se cobra por modelo o ¿ como va eso?

¿ Y la música y efectos de sonido ?

Ando muy perdido en estos temas, y yo no doy para mas que hacer un monigote simple en Wings3D

Gracias de antemano  :)  





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.