Simulación o modelismo...

[Divi4p]

Que caña!!!, yo estoy estudiando informatica y eso del render me suena de lejos jeje, estube en una conferencia sobre simuladores y hablaban de openGL y lo dejaban como el dios jejeje

Hombre, tiene cosas muy chulas... filtros y antes simulaba muy bien los reflejos del agua...



Claro que hay cosas... que sólo salen con DX9....



CryEngine, incialmente algo diseñado como demo para las gráficas de nvidia, finalmente se le puso interfaz, armas, argumento y listo para ser un juego, Far Cry, bastante bueno, por cierto...

[javierav]

Buenas.

Gracias divi4p por tu ayuda. Ahora voy entendiendo más o menos como va esto.

Resumiendo, un motor gráfico lo que hace es facilitar un poco las cosas al programador, para no tener que verselas con DirectX u OpenGL directamente, creando funciones que realizan determinadas tareas, ¿no?

He estado ojeando algunos motores gráficos, y sin duda hay mucha variedad aunque sí los veo demasiado enfocados a juegos de primera persona (de hecho, es lo que suele ocupar las capturas de demostración). También incluyen muchas funciones y demás añadidos, pero claro, tienen muchísimas cosas que por ejemplo en el caso de un simulador ferroviario pues no son de utilidad. Entiendo entonces que en el caso que nos ocupa (simulación ferroviaria), crear un motor grafico (por así llamarlo) propio, que utilizando OpenGL, realice sólo aquello que nos va a hacer falta, es la opción ideal, no necesitando el mismo número de horas o de personal que los otros motores gráficos estándar que incluyen muchas más utilidades que nos son indiferentes.

Saludos.

[Divi4p]

Resumiendo, un motor gráfico lo que hace es facilitar un poco las cosas al programador, para no tener que verselas con DirectX u OpenGL directamente, creando funciones que realizan determinadas tareas, ¿no?

No, el motor gráfico se programa y se comunica con librerías DirectX y OpenGl que son las que evitan que se las vea directamente con las gráficas, placas y procesadores. Estas librerías conocen y traducen y te evitan tener que programar para cada procesador, para cada gráfica y para cada placa de sonido o base.

He estado ojeando algunos motores gráficos, y sin duda hay mucha variedad aunque sí los veo demasiado enfocados a juegos de primera persona (de hecho, es lo que suele ocupar las capturas de demostración). También incluyen muchas funciones y demás añadidos, pero claro, tienen muchísimas cosas que por ejemplo en el caso de un simulador ferroviario pues no son de utilidad. Entiendo entonces que en el caso que nos ocupa (simulación ferroviaria), crear un motor grafico (por así llamarlo) propio, que utilizando OpenGL, realice sólo aquello que nos va a hacer falta, es la opción ideal, no necesitando el mismo número de horas o de personal que los otros motores gráficos estándar que incluyen muchas más utilidades que nos son indiferentes.

Evidentemente, ley de la oferta y la demanda... hacer simuladores no suele ser rentable y por eso no suelen estar tan a la última. Los FPS venden mucho y entran por los ojos directamente porque es su filosofía de juego.

Si estás pensando en crear tu propio motor gráfico para un simulador ferroviario... lo mejor es que intentes desterrar la idea... realmente utilizando OpenGl o DX y aún programando lo estrictamente necesario para el simulador... el motor gráfico ha de tener parámetros matemáticos de iluminación, algoritmos de "colisiones", física, sonido, efectos, partículas, herramientas de edición... es mucho más que lo que simplemente se ve estando parado... y eso en pasta es mucha pasta y en tiempo es mucho tiempo y más para tí sólo

Aparte de que lo ideal es siempre hacerlo lo máximo flexible, cosa de la que Microsoft, la verdad no tiene ni idea, siempre de cara a futuras ventas de licencias de uso... hay que hacer el tema rentable.

Luego hay cosas curiosas, como Havok, que "rellenan" huecos en la programación de motores, Havok es un motor de física que pagando te evitas crearte uno propio y tal y como está el panorama se ahorra mucho tiempo...

Un saludo.

[Victor]

Las OpenGL son librerías compiladas, una .dll en windows la cual incluida en el código de programación, es decir, en C quedaría algo así como:

include <stdio.h>

por ejemplo (esta librería no es OpenGL), siempre antes de declarar y asignar un puntero a las variables.

Sirve como bien dice Javier para ayudar al programador, simplemente realizando llamadas a funciones ya escritas, como por ejemplo podría ser el antialiasing.

Igualmente, al ser librerías de funciones, e incluidas en el código, una vez compilado, se necesitan tener instaladas para poder llamarlas. Me imagino que están hechas para gestionar de maravilla la memoria.

Saludos.

[Divi4p]

Aquí tienes Havok en acción:

http://curiosoperoinutil.blogspot.com/2 ... domin.html

Sería interesante que los próximos simuladores incorporaran al menos una versión "lite" de éste. Se podrían ver cosas muy chulas...

[Victor]

La simulación dinámica no tiene nada que ver con los gráficos.

Saludos.

[Divi4p]

La simulación dinámica no tiene nada que ver con los gráficos.

Saludos.

No, pero si te molestaras en leer el resto del hilo, especialmente la conversación entre Javier y yo te darías cuenta de lo que hablamos.

Especialmente:

Luego hay cosas curiosas, como Havok, que "rellenan" huecos en la programación de motores, Havok es un motor de física que pagando te evitas crearte uno propio y tal y como está el panorama se ahorra mucho tiempo...

Yo no menciono los gráficos.

Y el hilo habla de simulación y gráficos, una conjunción, entiendo que se admiten ambos, havok es un motor físico, entra en el apartado simulación.

Saludos.

[Victor]

Tranquilo chico, baja las espadas, que cualquiera diría que pretendo hacerte sombra con respecto a tus conocimientos.

Lo que te trato de decir es que librerías gráficas y motores de cálculo dinámicos no tienen nada que ver, aunque puedan estar integrados en un mismo juego.

Es como cuando programo un shader para MentalRay con el fin de simular la deformación de lente producida por una 'gran angular' o cuando programo el comportamiento de disipación del vapor que sale de un cilindro en función del tiempo. Efectivamente estoy programando en ambas, creando funciones, pero son dos cosas diferentes.

Si te molesta que aporte mi punto de vista, tranquilo, me lo puedes decir, que no por ello dejaré de hacerlo.

Saludos.

[Josep]

Holas,

Interesante tema, al que me sumo.

Ejemplo de programación "fascinante": un nivel de un juego que ocupa solamente 96 Kb. El famoso "kkrieger", un "shoter" de primera persona.

Aviso: solamente para equipos con configuraciones:

- A 1.5GHz Pentium3/Athlon or faster.
- 512MB of RAM (or more)
- A Geforce4Ti (or higher) or ATI Radeon8500 (or higher) graphics card
supporting pixel shaders 1.3, preferably with 128MB or more of VRAM.
- Some kind of sound hardware
- DirectX 9.0b

Descargable en http://www.theprodukkt.com/kkrieger.html (observad las capturas...)

Ya me contaréis...

Solamente para comentar que los motores gràficos de los actuales simuladores ferroviarios están muy desfasados y fuera de lugar.

Saludos.

Josep

[Divi4p]

Tranquilo chico, baja las espadas, que cualquiera diría que pretendo hacerte sombra con respecto a tus conocimientos.

Al contrario, mis conocimientos en estas áreas no pasan de lo poco leído y experimentado, cualquiera que se dedique a ello profesionalmente me da mil vueltas.

Lo que te trato de decir es que librerías gráficas y motores de cálculo dinámicos no tienen nada que ver, aunque puedan estar integrados en un mismo juego.

Coñ*, hablando en plata, pues haber empezado por ahí, no, no tienen nada que ver, tienes razón por supuesto, pero explícate bien porque das lugar a malentendidos. Porque no es lo mismo decir lo que has dicho ahora aclarado que lo de antes que daba pie a ambigüedades.

Un motor físico como Havok es un "complemento", luego, el motor gráfico y la renderización en pantalla es el resultado de los cálculos del motor físico. Lo que yo le estaba explicando a Javier es cómo funciona más o menos por lo que sé un motor gráfico y la función de las librerías y Havok era sólo un pequeño inciso como posibilidades añadidas a un simulador, una física ultrarrealista.

¿Mentalray no era alguna historia de renders para 3ds y Maya?, creo que lo mencionan en algún libro de los que tengo, de todas formas, me parece que vamos por ramas distintas, yo estoy más interesado en la renderización en tiempo real y el mundo del 3d va siempre muy por delante, en general que el de las aplicaciones 3d en tiempo real.

Un saludo.

[Victor]

La verdad, no creo que una u otra 'rama' vaya por delante de la contraria. Simplemente son campos de investigación totalmente diferentes. Cierto es que lo bueno sería conseguir cualquier tipo de render en tiempo real, pero como eso de momento no es posible, pues cada tipo de render tiene sus puntos fuertes y débiles.

Personalmente prefiero trabajar con renders donde me tarda cada frame entre cuatro y quince minutos de renderizado en un DualCore 64 bits y 4 Gigas de RAM.

Saludos.

[Josep]

Holas,

Me parece que el ejemplo que os he puesto es de render en tiempo real....no?

Hoy en día muchos procesos de render se realizan en tiempo real en los juegos, gracias a los chips aceleradores gràficos... que procesan muchos efectos en tiempo real, cada vez más.

OpenGl proviene del mundo de Silicon Graphics, una librería gráfica (para programar) abierta válida para entornos Windows. Los mejores juegos suelen estar programados con esta librería... Directx es otra librería desarrollada por Microsoft para aceleración gráfica. Su nivel actual es muy aceptable para juegos y procesos gráficos, aunque des de siempre prefiero OpenGl.


Por otro lado, los "renders", amigos, dependen de muchos factores, por lo que la frase que comentas, apreciado Victor, sobre que prefieres renders de entre cuatro y quince minutos... me parece poco serio. Poco serio, ya que los renders dependen del trabajo y nivel de detalle final, y el sistema y procesos que intervienen...por lo que preferir un tiempo de render me parece simplemente fuera de lugar...

Si el resultado que pretendo necesita un render de horas, lo haré. Si el mismo resultado puedo conseguirlo con menos tiempo, lo intentaré.

Mi experiencia tan solo se limita a que mi record de "render" es de 65 días en una máquina... lo que realmente supuso un fin de semana en un "render farm" utilizando más de 30 ordenadores en red. En otros casos, mi "render" para una imagen panorámica de 360 grados fué de 9 horas. Y así te puedo ir contando, hasta cansarnos.

Los renders en tiempo real: los he visto con hardware especializado...(calculando reflexiones, refracciones, etc...) en equipos muy potentes. El render en tiempo real es el que se realiza en los juegos...

Insisto: bajad y provad el juego de 96 kb...y ya me diréis cómo lo han hecho...

Saludos y buen debate.

Josep

PD: lo de Mental Ray es efectivamente un renderizador utilizado para cálculos de cáusticas y GI (Iluminación global), que sustituye el motor de render de 3ds Max, por ejemplo. Precisamente estoy ahora impartiendo clases a mis alumns sobre el tema. Muy interesante... Víctor: ¿qué programas para mental Ray...?

[Victor]

Hola Josep,

Tal vez no fuí acertado en el modo de expresarme, cuando me refiero a ese tipo de render, me refiero a un render no de tiempo real, con sus características implícitas.

En cuanto a Mentalray, no me he metido mucho, puesto que pretendo definirme más en la animación procedural y concretamente en fluidos y partículas.

Con lo que ahora estoy de lleno en cálculo vectorial y funciones de una o de varias variables.

Por cierto, como motor de cálculo de partículas, no he trabajado las dinámicas, me resultó muy interesante y potente RealFlow, de Nextlimit, software desarrollado por españoles y de gran proyección internacional.

Saludos.

[LBA]

Yo lo he bajado, probado y casi colgado... relamente solo lo conocía de oidas. Gracias.

Pero lo que realmente me pica... ¿Cómo se programa algo para que ocupe tan poco? ¿En que lenguaje? ¿Donde esta el truco? Si un mínimo archivo txt ya ocupa casi más. En el editor de procesos bien he visto como durante la ejecución llegaba a los 500000 kb sin muchos problemas. Me ha sorprendido enormemente.

Lo dicho, gracias por aportar algo palpable al post.

[Antuan]

Hola.

Me he descargado el juego pero a mí no me funciona (sólo tengo 256 Mb de RAM, y mi sistema es un portátil de memoria de vídeo compartida).

Eso sí, las capturas son excelentes, yo también creo que estamos desfasados en nuestros simuladores ferroviarios. Pero lo importante es que pronto aparecerá una nueva generación, y seguro que será sorprendente.

Hay mucho camino por recorrer todavía para alcanzar la perfección en todos los aspectos de la simulación: IA, metereología real, gráficos, sistemas, etc, y es porque todos éstos componentes que harán posible algo muy, muy cercano a la realidad, significan ordenadores mucho más potentes. Pero es sólo cuestión de tiempo...

Saludos.