Permitidme datos para pensar en unos supuestos mecanismos gráficos.

[EntidadX]

¿En que cantidad de potencia gráfica (aunque estemos hablando de cifras ridículas) estimaríais que tendría suficiente apoyo un supuesto programa que encendiese 1 pixel y lo hiciese hacer ir recorriendo una gama de, digamos, 64.000 colores, color a color en cuestión de a 40 colores por segundo?.

Ya se que no es tan sencillo como se pinta, pero aquí cada cual es libre de dar una respuesta resumida o extenderse cuanto quiera.

Pregunto esto porque a ver si soy capaz de estimar una cosa respecto a un motor gráfico que creo posible y que permitiría crear y ejecutar videojuegos fotorrealistas y de jugabilidad y estilos tan avanzados y variados como los que tenemos en esta era, en ordenadores...relativamente antiguos.

Si hay alguien que sepa responder a la pregunta (ojo, a la pregunta que he hecho, no que me de una solución completa al proyecto), debatamos.

[engel lex]

potencia para eso es practicamente 0, eso que dices lo puede hacer sin esfuerzo incluso un integrado de 32Mhz, más peso tiene establecer el "ambito" de trabajo (la supérficie sobre la que se dibujará junto con la "tubería" para mandar eso al gpu)

creo que la visión sobre la creación de videojuegos no la tienes realmente clara... lo que requiere potencia no es cambiar un pixel, es estimar en un mundo 3d, cual es la conversión necesaria para plasmarlo en 2d y cual sería el color resultante, tomando en cuenta la tectura del objeto y sus normales en base a las luces y sombras del ambiente

así se puede hacer en javascript  (colocas un elemento canvas con id "myCanvas")... usé random para no tener que hacer la lista de colores a mano

Código (javascript) [Seleccionar] Expandir


var canvas = document.getElementById("myCanvas");
var ctx = canvas.getContext("2d");

t = setInterval(function(){
var r = parseInt(Math.random()*256)
        var g = parseInt(Math.random()*256)
        var b = parseInt(Math.random()*256)
ctx.fillStyle = "rgb("+r+","+g+","+b+")";
ctx.fillRect( 1, 1, 1, 1 );
}, 1000/40)





[Serapis]

Te ha respondido engel satisfactoriamente...

Así que solo falta aclararte que 'encender' un pixel... lleva de tiempo exactamente el refresco de tu monitor, es decir si es a 60 herzios, la pantalla completa (no un solo píxel) se redibuja 60 veces por segundo... si es a 200 herzios, 200 veces por segundo.

Luego lo que versa necesidad de tiempo es computar lo que ha de contener la memoria gráfica (búffer) que será volcado en el siguiente refresco.

Calcular una escena 3D, parte de los diferentes objetos que contiene, se empieza con una posición local para cada objeto, luego se aplican transformaciones de rotación (sobre el propio objeto) y escala y desplazamiento (rotación sobre el mundo 3d) en la escena. Una vez posicionados todos los objetos requieren ser ordenados en el plano Z, para hacer un recorte y 'dibujar' solo aquello que se ve, ignorando las partes ocultas tapadas por otros objetos (a veces es más fácil redibujar un objeto encima del previo que calcular ese área que no se debería dibujar del objeto que está detrás), luego se aplican texturas, e iluminación con o sin reflejos de luz (que complican porque requiere recalcular varias veces píxeles que ya fueron calculados con anterioridad)... y al final cuando la escena esté montada pegarla al búffer... generalmente se puede disponer de varios búferes de modo que se va calculando uno (mientras se vuelca a pantalla otro) y a su término se pone en cola... realmente es más complejo, porque no se precisa redibujar todo cada vez, si no solo aquellos objetos que han cambiado en la escena y actualizar a  otros que involucren, por lo que acaba habiendo otros búferes intermedios con 'el fondo' básico de la escena, etc...

La proyección (calcular las posiciones 2D de una escena 3D), es trivial... es muy rápido ya que la GPU dispone de bastante hardware dedicado a ello, por lo que al diseñar un motor 3D, una dificultad adicional estriba en saber con qué funciones nativas cuantan todos (o x) procesadores gráficos, para saber qué funciones deben ser programadas y cuales invocadas de forma nativa (llamadas al driver).

Y en general el diseño del motor 3D, muchas veces se remite a tomar decisiones sobre la cascada de funcionalidad que debe tener, su orden de ejecución y el nivel de precisión... ya que a estas alturas los procesadores gráficos incluyen toda clase de funciones, de modo que cuando programas una función que posee la GPU, será más por gusto o porque quieres darle algo especial que no incluyen otros y todo siempre contando con la fluidez... en un juego, nadie puede esperar 1 sg. a que se genere una escena cada 3 segundos... se tolera al cambiar de escenario, de nivel, etc... pero no mientras estás jugando. Las pausas no deben ser por insuficiencia de la alimentación del búfer... o la gente se desesperará y pensará que o su equipo es poco potente (pero ya el mismo dirá que se lo acaba de comprar, que es lo último...), o el juego es demasiado exigente (si fuera verdad que la calidad es muy superior a todo), o sencillamente que el juego usa un motor de **??**

Ahora si crees haber 'descubierto' algo nuevo y potente... adelante, que no te pare las críticas de nadie, pero también, asegúrate antes de no estar haciendo el tonto y creer que acabas de inventar la rueda.

[EntidadX]

De acuerdo, pero aunque los hz del monitor sean los responsables de la tasa de refresco, lo que yo quería decir es que será algún tipo de programación la que consiga que el pixel cambie de color 60 veces por segundo. No quiero decir que esté en lo correcto, porque probablemente ya haya fucniones que se encarguen de la iluminación de los píxeles respecto al funcionamiento de entornos poligonales, pero es que me planteo que quizás se pudieran reducir las carga de procesos hacia cpu y gpu con algoritmos de dibujado, luces, etc, etc...alternativos a librerías que, sin duda han tenido éxito, y de hecho han estado evolucionando hasta ahora, pero más afinados y que tuvieran que ver con algun motor que diese órdenes de color a los pixeles, agrupado, cambiante respecto al movimiento del objeto en un mundo 3d pero planteado en ''2d'', digamos que (para explicarlo) en una realidad en que lo lejano planteado en un escenario 2d, es sólo porque es más pequeño.

 Un día, le expliqué a un programador experto del que hace mucho que no se nada, pues dejó de entrar en Facebook un día y no volvió, que podía conseguir un efecto 3d simplemente creado una ventana en cuyo fondo se dibujase un cuadrado y haciendo que el cuadrado creciese por cada lado por igual a cierto ritmo cuando se pulsase la flecha arriba y decreciese cuando se pulsase la flecha abajo. La cosa no parecía costarle al ordenador mucho más que sumar 1+1 con la calculadora, XD. Pero vamos, que seguiré expresando los trazos de lo que tengo en mente si es que la conversación evoluciona favorablemente, y, para eso, la pregunta que teneis que responderme es la primera que he puesto en este último mensaje.

 Por cierto engel lex, tu respuesta me ha aportado algo más de lo que realmente iba buscando (es que no se nada de programación, nada o casi nada, así que lo sencillo y comprensible es lo que me aporta algo), pero sigamos si os place.

[engel lex]

el problema es como te dije, la respuesta a la pregunta original es la misma, para efectos prácticos la carga causada por dibujar 1 pixel en pantalla es 0... incluso para dibujar los 2.073.600 que tiene una pantalla 1080p sigue siendo 0, ese proceso se asume "natural" como base de funcionamiento del gpu

lo que causa carga del gpu no es el dibujo... es el calculo del color que tendrá cada pixel... creo que deberías estudiar bien sobre openGL y shaders para entender de que va todo lo que se encarga la gpu

por lo menos el ejemplo del cubo rotando, el dedubar un 2d que se deforme, practicamente no causará carga, pero el proceso normal es
(programador)
1- crear en 3d un cubo dentro del gpu (y un punto de luz para que se vea)
2- darle textura
3- calcular la matriz de rotación
(gpu procesado 3d, esto se hace sobre los objetos virtuales)
1- revisar que parte del cubo es visible
2- calcular que parte de la textura corresponde a cada punto
3- simular la emisión de fotones desde la fuente de luz
4- calcular la intensidad de brillo y color que obtienen los fotones al golpear el objeto
(gpu dibujado esto se hace sobre los pixeles de la pantalla)
1- calcular que parte del objeto es visible desde ese pixel
2- calcular como los colores son afectados por el ambiente (neblina u otros efectos)
3- ubicar el color del pixel

[EntidadX]

Bueno, perdón por la tardanza, pero la verdad es que daba el tema por muerto, porque mi nivel de ánimos..., pero bueno, gracias al apoyo (curiosidad más bien) de lo usuarios de otro foro y la capacidad del mismo de notificarte cuando te citan o te mencionan, he podido pensar un poco más en el tema. Copio y pego el último mensaje que les he dejado:

 

A ver, la latencia que pueda haber a niveles de que para el ojo humano pase totalmente inadvertida, en la instrucción de iluminar x pixeles a lo ancho y a lo alto, simulando el tronco de un árbol, o un árbol y su copa, surgidos de manera sencilla de marrón y verde, ¿cual podría ser?, es decir ¿cuanto tardaría el pc en iluminar con esos colores el area designada que contendría los colores que nosotros interpretaríamos como árbol?.

Ánimo, que creamos una herramienta de generación procedural de cuadros. Ya es bastante, aunque ya vendrá alguien que haga libre su tecnología de generación procedural de paisajes con toas sus 3 dimensiones, oh si, ou yea.

 Se que a vosotros os gusta más lo procedural, por eso tengo que mencionar a generación procedural de modelos de diferentes objetos, plantas, casas, rocas, accidentes geográficos y tal y cual, para añadirlos a una base de datos seleccionable después por el editor del cuadro a base de esas ''pegatinas'', y con la ayuda de algún botón u opción que haga que la imagen global formada entre todos los objetos, tenga cosas de fondo y cosas que se superpongan a lo que tienen detrás, activando también la opción de disminuir el tamaño de una imagen para ponerla más pequeña y que representase lejanía en el caso de que quisiéramos hacer algo con aspecto de profundidad. Para hacer el cuadro bastaría con esa base de datos de cientos (como mínimo pienso debiera tener pienso) de modelos generados proceduralmente respecto a "roble", "pino", "tierra", "montaña", "sierra", "barranco", etc, etc, de de entre los que poder escoger.

 Luego también se podrían hacer cuadros "vivos", o entornos 3d más complejos pude que incluso nuestro universo, la cuestión sería ¿hasta que límite?, ¿hasta la locura?,  .

[EntidadX]

Estoy pensando que casas quizás sería difícil diseñarlas proceduralmente, pero si se podrían diseñar ventanas, puertas, tejas (vistas de frente en primera persona), muros. Lo de los balcones ya sería más complicado, pero las posibilidades con la que creo sencilla esencia de lo listado, ya serían muy amplias. Y sigo pensando y creo que las casas no tienen tantos avalorios (veletas, aspas, chimeneas...) como para que la lista fuese demasiado grande.

 Aunque si ya hablamos de secuenciación de las piezas en diferentes ángulos..., la cosa se vuelve compleja, aunque no se si mucho o poco, mucho probablemente...

 Se forró el de Minecraft, pues quien hiciese esto..., pero si, tiene mucha complejidad, perdonad todos, porque tal base de datos no la tiene ni el Unreal engine, y puede ser que sea la única solución, o la más sencilla por lo menos (que otras cosas no están inventadas).

  Edito: Ya está hecho, XD, y se antoja demasiado complicado.

  https://www.youtube.com/watch?v=FRxnKYy62KE

  Perdón por las molestias y mis deseos de que disfruteis de la información.

[Serapis]

Pués si, me parece que al final quieres reinventar la rueda... pero además sin saber siquiera lo que es un eje (pecata minuta común en los principantes).

Ya hay programas que hacen todo eso que tienes pensado, pero mucho mejor, inmensamente mejor.
Por ejemplo, yo he usado Terragen desde hace unos 20 años o así y su única pega por entonces es que resultaba muy lento el cálculo de una escena, así que típicamente para hacer cambios y 'ver' solía uno restringir bastantes opciones de cara a seguir avanzando y solo cuando al final lo tenías listo, cuando quería renderizar la imagen completa es cuando activabas todas las opciones y aumentabas las dimensiones de salida d ela imagen (mientras probabas a bajas resoluciones).
A día de hoy que la potencia de cálculo ha mejorado sensiblemente y que el mismo programa ha ido evolucionando (recuerdo que de una versión a otra, mejoró sensiblemente el rendimiento, precisamente por precalcular que planos quedaban ocultos y evitar calcularlos), lo que se podrá hacer con el mismo, será indistinguible d ela realidad...
Hace tiempo (años), que no descargo ninguna versión reciente, pero fijo que  sigue vivo (lo miro ahora mismo). Además había otros programas 'competidores', que seguro que siguen activos también (por ejemplo Renderosity, VistaPro que venía desde los antiguos Amiga de Apple (finales de los 80), etc... )...

Página de Terragen:
https://planetside.co.uk/
Puedes descargar una copia gratuita de evaluación, a la que se imponen algunas restricciones, como el tamaño máximo de imagen de salida.
La última versión es la 4 y data del 2016.
Algunas imágenes en la galería, aunque también puedes buscar en youtube o en el propio google:
https://planetside.co.uk/terragen-image-gallery/

Te aclaro que ya por 2003-2004, las imágenes generadas eran fotorrealistas, y  supongo que el programa estaba 'capado' en capacidades, únicamente por el excesivo tiempo de renderizado, es decir que podría ofrecer más calidad, sin la imposición de restricciones por culpa del rendimiento de entonces, así que si no vas a hacer nada mejor, es preferible que no pierdas el tiempo.

Dispone de diferentes ventanas para definir cosas como el terreno, la atmósfera, hasta las nubes resultan muy realistas... y pueden guardarse los detalles en pequeños ficheros de definición... por ejemplo recuerdo haber generado diferentes tipos de hierba, más adelñante puedes importar en otras escenas aquellas cualidades que hayas guardado, es muy completo pero no complejo de usar quizás sí, para exprimir todo su potencial, pero no para trastear con él... resulta muy intuitivo.


p.d.: La definición de objetos sencillos, se conoce como primitivas, y por ejemplo Autocad... lleva ya varias décadas con ello.
Aún conservo por ejemplo las librerías que definía otro programa llamado Drafix-Cad, que además del programa ofrecía paquetes especializados para profesionales: de mecánica, de arquitectura, etc...
En realidad todo ese campo, se empezó a tratar en profundidad a comienzos de los 90, con la llegada de los 16bits a los ordenadores...

[EntidadX]

¿Y que me dices de el Unreal engine que he comprado tras la edición de mi último mensaje?, ¿sabes algo?.

[EntidadX]

Aquí está la descarga por si a alguien le interesa:

  https://www.unrealengine.com/en-US/download

  Me despido del hilo.