elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Recopilación Tutoriales y Manuales Hacking, Seguridad, Privacidad, Hardware, etc


+  Foro de elhacker.net
|-+  Programación
| |-+  Programación General
| | |-+  El ingenio en la simulación (proceduralismo y frames/segundo)
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] Ir Abajo Respuesta Imprimir
Autor Tema: El ingenio en la simulación (proceduralismo y frames/segundo)  (Leído 8,130 veces)
EntidadX

Desconectado Desconectado

Mensajes: 72


Ver Perfil
El ingenio en la simulación (proceduralismo y frames/segundo)
« en: 13 Marzo 2022, 15:58 pm »

Los diseños procedurales ahorran el procesamiento continuado, ¿no?, sino que cargan en memoria rom lo que procesan en un principio, lo memorizan recurriendo a un espacio rom mínimo (lo que ocuparía un archivo de partida guardada) que interpreta una base de datos de estructuras y luego ya no hay carga ninguna...

Creo que esto se podría aprovechar por ejemplo para juegos de un solo jugador y para ahorrar recursos de procesamiento, por ejemplo, dando forma a todos los objetos estáticos (árboles, edificios y tal, que son la mayoría) y poniéndoles una textura procedural también que se memorizaría en un archivo de partida que dependería más de la velocidad de lectura del ''disco duro'' que de procesador y gráfica.

Mucho más complicado sería explicar creo como movían los 33 mhz de la Play1 el Diablo 1 hace 20 años (esta afirmación creo que demostraría que mi conspiranoia, incluso sólo está viendo la punta del iceberg). Y esperad, que ahora os pongo otra diabluría del puto ingenio (un momento, va a ir aquí a continación), ya está:

https://m.youtube.com/watch?v=AAgDDFd9-5Q

Es de Master system, o sea, ni siquiera 16 bits, sino 8, y https://es.m.wikipedia.org/wiki/Master_System . No se programar, pero si se hubiera seguido por esas lindes para Megadrive/Super Nintendo, la simulación podría haber sido espectacular. Es un tema más, el ingenio para la simulación...no tanto polígono, pero ya puestos y encantados/as con lo visto, sobre el tema del hilo, mi opinión es que será todo lo enrrevesado que quiera lo que planteo, pero de algún modo pienso que si un Petium 4 puede mover un vídeo a 1080 sin problemas..., es que no lo se, porque como actualizamos los equipos, pero tengo un netbook de 10" con oprocesador Atom a 1'6 ghz, del 2010, que con Xubuntu 21.10 mueve el 720p casi bien, y por supuesto sobra resolución ahí para esa pantalla por un tubo. Pues creo que a una resolución menor se podrían casi equiparar los frames que es capaz de mover de forma que una película sea fotorrealista, a que un videojuego lo hiciese porque la carga en directo del procesador se reduciría a sólo un poquillo más que con el vídeo puro y duro (serviría también el ejemplo de como se pasa de una imagen hechada con la cámara de fotos a otra en el visualizador de fotos...que se ralentiza notablemente para resoluciones idénticas - póngase las mismas fotos - con cada versión nueva del s.o. ...de Windows al menos lo tengo comprobado creo).

Y la Play1 también movía el Doom 1 (30 mb de rom como mucho) con una solltura...creo que mi obsesión por estos juegos viene de alguna regla que hace las cosas más bonitas, algo como que el arte engendra arte o algo así.

He pensado en una especie de mapa con definiciones de lo que hay ahí..., definiciones estructurales, o sea: 10 metros de altura, 50, todo respaldándose en una base de datos de supuestos objetos (limitados por juego a unos pocos cientos, y sería vistosísimo), y luego en la generación procedural y lo que ya he dicho.

Todo se basa en un ejemplo que le puse a un antiguo amigo que un día dejó de publicar en Facebook y no volví a saber de él. Le dije que hiciera (yo no se programar) un cuadrado que creciese por todos los lados al pulsar la flecha de arriba, y él lo hizo en no llegaría a un minuto de tiempo, y le dije: ahí tienes el 3d.

Bueno, decidme de momento si le veis utilidad/razón al menos a lo primero que he dicho, a ver si puedo pensar en esto del 3d..., no, no voy a poder. Creo que todo lo que podría haber dicho ya lo he dicho.

Definición..., si..., pero de...... Bueno, está todo dicho creo..., no, en realidad se me ocurrieron explicaciones más comprensibles..., al menos en lo de la simulación 3d que le daría lados a ese cuadrado unicolor con texturas procedurales añadidas, pero ya no puedo... Espero no incitaros al odio y que alguien me de una respuesta instructiva. Creo que no podría hacer otra pregunta más sobre el tema, sino que todo pasaría con que pudiese recuperar mis capacidades y me pusiera a hacer experimentos con lo que se me ocurriese...así por pura magia como quien dice, por lo que puede que todo esté explicado con que de algún modo en mi memoria personal asocie el gozo de la salud a esos juegos antiguos, mientras que con los nuevos me sea imposible asimilarla..., pero por otra parte creo que es indudable que tenían una belleza especial e inigualable (y con poco consumo de potencia  :laugh: ).

Buen futuro.

Al menos en juegos 3d lineales y por sectores, se podría ir eliminando lo ya visto del disco duro, tras haber representado una distancia de visión más que digna y envolvente.

Decidme una cosa, es una tontería, pero ¿cualquier juego de mundo abierto de los de ahora, está procesando todos los objetos del mundo en tiempo real?.

Lo pienso y es curioso: aprovechar la capacidad de almacenamiento y la velocidad de lectura del disco para mover un personaje 3d con animaciones por un pre-renderizado en 3d (proceduralismo) generado mediante el cálculo de todas las imágenes posibles fuese cual fuese la posición en pantalla según fuésemos a mover al personaje, memorizadas y movidas.

Al menos nos podríamos entretener calculando la amplitud de las áreas que permitirían 10 gb de un nnme. Una nueva reama de la ciencia del 3d simulado (seguro que sin necesidad de diseñar una base de datos ni nada parecido, se podría elaborar el método para calcularlo en, por ejemplo, un escenario de 4x4 metros, y creo que por metro que se añadiese, el crecimiento sería algo distinto a exponencial, sino que tendría su propia fórmula. No es difícil, ¿no?. Luego sólo sería multiplicar por el peso de una foto de 3 megapíxeles cualquiera).

Podíamos empezar averiguar cuantos frames son posibles en un giro de 360 grados..., todo sería una dimensión sólo que viendo los diferentes detalles de la textura procedural de la sala hasta que el patrón se empiece a repetir, pero ¿cuando se empieza a repetir para 4 metros cuadrados de sala?.

¿Se sabe cuantos círculos caben dentro de una esfera si los círculos tienen que rozar sus paredes si o si?, ¿alguien sabe si esto tiene nombre?, y si no lo tiene, ¿alguien se imagina como podría calcularse?.

No voy a poder expresarlo bien porque no voy a poder pensar, pero dependería de los metros cúbicos de esa sala cuadrada que se quisiera representar. Si alguien quiere correlaccionar, que correlaccione, XD, y de paso que incluya la cantidad de fotogramas que es capaz de captar el ojo humano, porque por poder, quizás en 360 grados simplemente cabrían infinidad de partes. Velocidad de giro...la que se quiera preestablecer, ya que el movimiento en los videojuegos van a la velocidad que se preestablece (así que es un patrón que se repite al x tiempo que decidamos), por lo que se sacan los fotogramas captables por el ojo, que ya los tenemos programados en la cara y esto no es más que una pantalla. A más velocidad, menos partes de la realidad (virtual en este caso), por eso establecer una velocidad en lo virtual ayuda a comprender donde estamos, y en lo real...vete tu a saber.

MOD: No hacer multiples posts seguidos.


« Última modificación: 14 Marzo 2022, 00:14 am por MCKSys Argentina » En línea

Muerte vs vida.

4.000-3.
Serapis
Colaborador
***
Desconectado Desconectado

Mensajes: 3.348


Ver Perfil
Re: El ingenio en la simulación (proceduralismo y frames/segundo)
« Respuesta #1 en: 14 Marzo 2022, 02:38 am »

Guau...

No resulta adecuado hacer afirmaciones sobre cosas que uno no tiene ni idea. Hubiera sido más adecuado si te limitaras a hacer las preguntas que te parezcan y ya.

Citar
proceduralismo
Esa palabra no existe, se dice procedimental.

Citar
Los diseños procedurales ahorran el procesamiento continuado, ¿no?, sino que cargan en memoria rom lo que procesan en un principio, lo memorizan recurriendo a un espacio rom mínimo (lo que ocuparía un archivo de partida guardada) que interpreta una base de datos de estructuras y luego ya no hay carga ninguna...
No. Ahorran memoria, no procesamiento.
Tener una única copia de x procedimiento, permite simplemente separar los datos de la funciónalidad. Los datos serán tantas copias como instancias cuasi-simultáneas precisen esa funcionalidad mientras esté cargada en memoria.
Tampoco es radicalmente así, a veces se opta por hacer funciones que se denomina 'inline', es decir funciones muy reducidas es más rápido procesarlas con su propia función y destruída al terminar... a fin de cuentas cualquier funcionalidad que deba tratar con distintos punteros de acceso a datos, precisa ser convenientemente canalizado, lo que consume algo de tiempo que para pequeños procedimientos, resulta más rentable el tiempo que la memoria usada.

Citar
Creo que esto se podría aprovechar por ejemplo para juegos de un solo jugador y para ahorrar recursos de procesamiento, por ejemplo, dando forma a todos los objetos estáticos (árboles, edificios y tal, que son la mayoría) y poniéndoles una textura procedural también que se memorizaría en un archivo de partida que dependería más de la velocidad de lectura del ''disco duro'' que de procesador y gráfica.
Esto es relativo (al momento crítico de la Historia en que se aplique).

Hoy día los procesadores gráficos son tan eficaces, que se puede calcular algo 20.000 veces antes que cargar eso que tu dices una sola vez de disco.
En el pasado aunque los procesadores eran más lentos, la memoria en disco tampoco iba sobrada e iba más lento, por lo que por lo general es el propio programador el que evalúa al momento del diseño (y pruebas de rendimiento), qué caso se aplica mejor, indistintamente de que a futuro la cosa cambie... se diseña para 'ahora'.
No hay una solución universal... como tu pretendes, depende del caso y el hardware con que se cuenta.

Citar
Mucho más complicado sería explicar creo como movían los 33 mhz de la Play1 el Diablo 1 hace 20 años
No temrino de entender...
Básicamente cuando el sistema es crítico, o se baja resolución o se optimiza el código... si no basta en última instancia pueden diseñarse en  ensamblador ciertas partes críticas. Tampoco ocnfundas el procesador (CPU), con el procesador gráfico (GPU).

Además da igual la velocidad de proceso, incluso aunque funcionara a 1Mhz, si luego hay 200 unidades de paralaje, pués se procesan 200 unidades al mismo tiempo.
En las GPU, hay largos conjuntos de instrucciones que s eprocesan en paralelo, porque son funciones muy frecuentes y harto conocidas, además están especializadas precisamente para las funciones gráficas.

Citar
...mi opinión es que será todo lo enrrevesado que quiera lo que planteo, pero de algún modo pienso que si un Petium 4 puede mover un vídeo a 1080 sin problemas..., es que no lo se, porque como actualizamos los equipos, pero tengo un netbook de 10" con oprocesador Atom a 1'6 ghz, del 2010, que con Xubuntu 21.10 mueve el 720p casi bien, y por supuesto sobra resolución ahí para esa pantalla por un tubo. Pues creo que a una resolución menor se podrían casi equiparar los frames que es capaz de mover de forma que una película sea fotorrealista, a que un videojuego lo hiciese porque la carga en directo del procesador se reduciría a sólo un poquillo más que con el vídeo puro y duro...
No se debe hablar tan a la igera con suposiciones... las suposiciones van bien cuando no hay forma de saber algo a ciencia cierta o cuando algo carece de importancia técnica la exactitud.

Cuando se habla de resolución hay que hacer los cálculos para saber lo que se está indicando: ancho en pixeles * alto en pixeles * bits por píxel * frames por sg. así puedes comparar cuan distintas son dos resoluciones entre sí...
El vídeo sin embargo, es algo grabado, tan solo comprimido... un juego debe calcular las escenas, desde posiciones, tamaños, texturas, luces, etc... no es una comparativa 'honesta', de hecho es como comparar peras con sombreros.

Citar
Todo se basa en un ejemplo que le puse a un antiguo amigo que un día dejó de publicar en Facebook y no volví a saber de él. Le dije que hiciera (yo no se programar) un cuadrado que creciese por todos los lados al pulsar la flecha de arriba, y él lo hizo en no llegaría a un minuto de tiempo, y le dije: ahí tienes el 3d.
La ignorancia no es mala por sí misma, peor cuando se saca a pasear con orgullo...

...a ver si he entendido tu haces aumentar un cuadrado por los 4 lados y los que tienes es un cuadrado más grande cada vez, además hay que comprensar su posición, y desde luego yo no veo ahí ningún 3d, como tu lo llamas.
La perspectiva (que es lo mas parecido que puedo concluir) de la cordenada z (distancia), también debe ser calculada... todos esos cálculos 3d, Rotación, posición, tamaño, perspectiva se hacen con multiplicación de matrices, luego es algo bastante simple por sí mismo. Es la cantidad de detalles, la enorme cantidad... lo que puede ralentizar el cálculo.

Citar
Bueno, decidme de momento si le veis utilidad/razón al menos a lo primero que he dicho, a ver si puedo pensar en esto del 3d..., no, no voy a poder. Creo que todo lo que podría haber dicho ya lo he dicho.
Lo siento, nada de lo que has dicho tiene utilidad.

Todas las matemáticas de la geometría del 3d, ya se conocía incluso en el siglo XIX... un libro muy reutilizado por aquellos tiempos fue el mítico: "Elementos de geometría analítica" de Sonnet y Frontera, publicado en 1854 (en francés), y traducido a quien sabe cuantos idiomas, yo tengo la versión de 1863 que no sé si es la primera o segunda edición en español.

Para tí te recomiendo un libro pequeñito pero no por ello menos interesante: "Teach Yourself Computer Graphics" de John Lansdown, de unas 230 páginas publicado en 1987. Perfecto para ser el primer libro de cualquiera que pretenda adentrarse en el 2d y 3d, sea para programar, o al menos hablar con propiedad.

Citar
puede que todo esté explicado con que de algún modo en mi memoria personal asocie el gozo de la salud a esos juegos antiguos, mientras que con los nuevos me sea imposible asimilarla...
No hay diferencia entre los antiguos y los de ahora más que la potencia de cálculo. También nuevos algoritmos en cuanto a la implementación de la luz, pero si ya en aquellos tiempos costaba mover algo simple, y no podían ponerse determinada cantidad de colores, mucho meos hacer cálculos de luz, Aún así se hacían pero solo para imágenes estáticas, no para juegos que debían funcionar en tiempo real.

En la medida que la potencia de cálculo ha aumentado, se pueden hacer más cosas sin sacrificar la 'jugabilidad'... incluso así, algunos creadores 'se pasan' exigiendo siemre más potencia que los equipos que sus potenciales clientes tienen.. obligándoles constantemente a adquirir nuevo equipo con cada nuevo estreno de un videojuego.

Por ello, en aquellos tiempos que los gráficos que añoras, tenían la enorme virtud de tener que mantener la 'esencia' del gráfico dada la limitación de recursos para que el jugador pudiera sentir que ese gráfico era lo que sus autores habían pretendido que fuera. ...y siempre había quien se quejaba de todo...

Citar
Decidme una cosa, es una tontería, pero ¿cualquier juego de mundo abierto de los de ahora, está procesando todos los objetos del mundo en tiempo real?.
No. Ni antes tampoco.
Los juegos solamente procesan los objetos que están a la vista, incluso de estos, solo aquellas partes que son visibles.
Hay algoritmos para calcular que objetos están fuera de escena (sea fuera de posición o tapados por otros), esos no se procesan. Una esfera por ejemplo, solo precisa ser calculado el plano 2d que tu ves, es decir un círculo... que viene a ser media esfera, aunque en el perímetro los detalles se acumulan y pueden obivarse muchos de ellos que por su posición no cubren el equivalente de 1 píxel.

Además cuando hay movimiento, los detalles no necesitan ser tan precisos, como cuando está inmóvil, e incluso cuando está en movmineto, se calcula si un área dado, necesita ser recalculado o sigue siendo vigente el área previa.

Citar
Lo pienso y es curioso: aprovechar la capacidad de almacenamiento y la velocidad de lectura del disco para mover un personaje 3d con animaciones por un pre-renderizado en 3d (proceduralismo) generado mediante el cálculo de todas las imágenes posibles fuese cual fuese la posición en pantalla según fuésemos a mover al personaje, memorizadas y movidas.
No se puede calcular todas las 'posibilidades', el espacio necesario para su alamcenamiento sería inexorable.
Hay una técnica llamada 'sprite' que consiste en establecer x imágenes de transición para un objeto, que son repetitivas, por ejemplo un personaje al andar... 30 años atrás hubiera tenido entre 4 y 8 imágenes de transición, además habría diferentes si se ve de frente, perfil o pordetrás... ahora esoso sprites parten de un esqueleto que ´facilmente se posiciona en 3d... siguen siendo sprites, pero bastante más complejos.
Toda la dinamica de diseño se apoya en lo que se llama un 'motor de juego (3d al caso)'.

Citar
se podría elaborar el método para calcularlo en, por ejemplo, un escenario de 4x4 metros, y creo que por metro que se añadiese, el crecimiento sería algo distinto a exponencial, sino que tendría su propia fórmula. No es difícil, ¿no?. Luego sólo sería multiplicar por el peso de una foto de 3 megapíxeles cualquiera
Hay algoritmos de renderizado de texturas incluso aleatorias... seguro que si tienes cierta edad habrás jugado o visto jugar al Flight Simulator, las nubes, el terreno, el mar, se renderiza de forma aleatoria partiendo de un plano sencillo 2d, o bien recurriendo a fractales. Esto último es lo más adecuado cuando se duiseña algo desconocido, un plano es preciso cuando debe ceñirse a la fidelidad de algo existente. Aunque a día de hoy ambas tecnologías conviven.

Citar
Podíamos empezar averiguar cuantos frames son posibles en un giro de 360 grados..., todo sería una dimensión sólo que viendo los diferentes detalles de la textura
Como te he indicado eso lo controlan los sprites, si alguien determina que quiere un sprite por cada 15 grados de angulo, pués calculando tienes 24 sprites.
Si alguien quiere que funciones por cada minuto de arco, pues requerirá 360*60, ahora ya no serán sprites, serán recalculados en tiempo real.

El sprite es adecuado para ahorrar cálculos, pero si la potencia de cálculo es enorme puede prescindirse y recalcularse en tiempo real. Al menos los obtetos principales, los objetos 'muertos' (casas, calles árboles) y todo lo que no esté en primer plano (personajes en la lejanía), por no requerir tanto detalle, pueden seguir tirando para ellos de sprites, así se consigue cierto realismos de primer plano, sin pecar de jugabilidad... un 'truco sucio' es situar las escena en cierta penumbra, así ciertos detalles no necesitan tanta precisión (todos los gatos son pardos de noche).

Citar
¿Se sabe cuantos círculos caben dentro de una esfera si los círculos tienen que rozar sus paredes si o si?, ¿alguien sabe si esto tiene nombre?, y si no lo tiene, ¿alguien se imagina como podría calcularse?.
Estos son matemáticas... Puede interesarte la "conjetura de Kepler" (es el nombre que buscas), Busca por Gauss y Thomas Hales.

Citar
por eso establecer una velocidad en lo virtual ayuda a comprender donde estamos, y en lo real...vete tu a saber.
Para tu información la técnica está a años luz de tu imaginación... lee, infórmate, en vez de teorizar por debajo del estado actual del arte, hay infinidad de libros sobre la temática de gráficos por ordenador...


En línea

EntidadX

Desconectado Desconectado

Mensajes: 72


Ver Perfil
Re: El ingenio en la simulación (proceduralismo y frames/segundo)
« Respuesta #2 en: 14 Marzo 2022, 07:05 am »

Me quedo con esto:

Citar
¿Se sabe cuantos círculos caben dentro de una esfera si los círculos tienen que rozar sus paredes si o si?, ¿alguien sabe si esto tiene nombre?, y si no lo tiene, ¿alguien se imagina como podría calcularse?.

Estos son matemáticas... Puede interesarte la "conjetura de Kepler" (es el nombre que buscas), Busca por Gauss y Thomas Hales.

y esto:

Citar
Podíamos empezar averiguar cuantos frames son posibles en un giro de 360 grados..., todo sería una dimensión sólo que viendo los diferentes detalles de la textura

Como te he indicado eso lo controlan los sprites, si alguien determina que quiere un sprite por cada 15 grados de angulo, pués calculando tienes 24 sprites.
Si alguien quiere que funciones por cada minuto de arco, pues requerirá 360*60, ahora ya no serán sprites, serán recalculados en tiempo real.

El sprite es adecuado para ahorrar cálculos, pero si la potencia de cálculo es enorme puede prescindirse y recalcularse en tiempo real. Al menos los obtetos principales, los objetos 'muertos' (casas, calles árboles) y todo lo que no esté en primer plano (personajes en la lejanía), por no requerir tanto detalle, pueden seguir tirando para ellos de sprites, así se consigue cierto realismos de primer plano, sin pecar de jugabilidad... un 'truco sucio' es situar las escena en cierta penumbra, así ciertos detalles no necesitan tanta precisión (todos los gatos son pardos de noche).

Ayer después de escribirlo lo estuve pensando mientras me quedaba dormido, aunque daba por hecho que era un tema ahogado porque no habría ninguna respuesta, así que gracias.

Para o de los círculos dentro de las esferas(en reallidad pueden ser infinitos, a no ser que le pongamos medida a la esfera y a la linea que forma el círculo, que, por otra parte, la tienen que tener si son lo que supuestmente son, eso obligatoriamente (el personaje sólo mira de izquierda a derecha y viceversa, y de arriba a abajo y viceversa, así son los videojuegos y muy pocas veces se ha simulado más que eso (incluso nosotros, cuando giramos la cabeza a un lado, seguimos viendo lo que tenemos delante de los ojos igual a como lo veíamos, puesto que los ojos no se quedan fijos). lo que facilita mucho las cosas, porque simplemente tenríamos que establecer la distncia que se recorrer con dos tipos de paso, uno caminando y otro corriendo. Yo como dije, lo quiero hacer con frames, entonces serían posiciones que darían acceso a una parte de la memoria rom donde se hubicase el frames que el pc calcularía no gráficamente pero muy velozmente, tras todo el rollo de la generación y memorización de todas las imágenes del entorno en la carga de la pantalla, para después mostrarlo).

Lo más curioso e en lo que derivó el tema por mero capricho del cerebro: En un aparato de juguete que tuviera la capacidad de movilidad de un helicóptero (o una cámara capaz de adoptar un gran espectro de ángulos; pero lo de el helicóptero no es una idea csual, pues los helicópteros son los aparatos que menos rodeos tienen que dar para llegar con facilidad al punto que desean), con una patalla, micrófono altavoz y cámara, para poder salir de casa sin salir, y poder hablar con la gente. Lo vi útil para personas que no se puedan mover lo mínimo necesario para socializar dada la cantidad de sicópatas que hay en internet, que al menos puedan pasear y saludar a gentes ya connocidas, ya que las ayudaría mucho a no volverse locas de soledad, habría que adoctrinarlas en seguridad (básicamente que no facilitasen su dirección y mucho menos abriesen la puerta a alguien que hayan conocido así, pero el resto de datos sobre esa seguridad los gestionaría una empresa. Vamos, que de seguro tendría una *****...pero...). Lógicmente, el aparato debería tener internet y gps (y batería, y ram, y rom...y placa base - electrónica ¿eh? XDD - ).

Edito:Respecto al tema de ahorro de recursos y por lo que ha sido dicho, me doy cuenta después de pensar un poco más, que la gente piensa de cojones, porque eso de que de lo que tienes delante no se cargue/procese-renderice (no tengo demasiado claro el término) todo el conjunto de objeto, sino sólo lo que va a estar delante de los ojos, la verdad es que pensé que si sería así, que se ''cargaba'' todo y no se tenía en cuenta el ahorro de recursos por el tema de la potencia sobrada de los procesadores. Pero...si hay una cosa que ahorraría recursos, y esto es indudable y técnicamente entendible (lo de generar todas las imágenes que decía antes sería un experimento sólo, pero lo que voy a decir sigue la corriente natural de los avences tal y como han estado dándose y se están dando). Todo pasa por un complejísimo entramado de observaciones a nuestro propio sistema ocular, que quizás sea menos potente que el de una Rtx 3070 por ejemplo..., y creo que menor aún que el de una tarjeta de menor calibre, o de mucho menor calibre..., La cuestión es sencilla: seguimiento ocular, debido a que si os fijais cuando vais por la calle, e incluso cuando estais mirando algo que os quedais ensimismados y dejais de recibir imagen en diferentes grados, llegando a ser nada incluso, o no para el consiente. Me he fijado andando ahora hace un rato que he ido a hacer unas cosas, que en un videojuego se carga a tope de reslución todo el contenido de la pantalla, pero es cosa que los ojos humaos no pueden aprovechar..., por ejemplo, si miraiis lo que estais leyendo ahora y os dais cuenta ¿como os aparece el resto de la pantalla?, se ve difusa mientras mantengais la vista en un punto.

Lo dicho, sería complicadísimo (al menos para algunas personas) dar con las claves para aplicar esa técnica a nivel de videojuegos, pero le ahorraría carga a la gráfica, ¿no?. Lo que es cierto es que cuando enfocamos algo, sólo vemos a resolución real eso. Pero luego lo del enfoque es un lío creo (no lo he comprobado), o a lo mejor sólo tiene 2 posiciones sólo que barremos el objeto de varias pasadas y no somos conscientes de que lo hemos ido viendo por partes..., lo digo por los paisajes, que a mi se me hace que cuando miro uno lo veo entero..., pero creo que se puede comprobar simplemente mirando la foto de un paisaje, y ahí pasa esto que digo igualmente.

Ahora si acierto, ¿no?, muy básicamente, pero acierto.

Pero la pregunta final para demostrar lo que serían los diferentes grados de lucided que se pueden llegar a tener o eso creo, sería: ¿debería ser representada la imagen desenfocada con una resolución igual a la del resto del juego, sólo que a su manera, o seaa, para representar la imagen desenfocada con nitided, o de forma que todos los píxeles de la pantalla se enciendan)?.  :laugh: Oo

MOD: No hacer multiples posts
« Última modificación: 15 Marzo 2022, 01:44 am por MCKSys Argentina » En línea

Muerte vs vida.

4.000-3.
RayR

Desconectado Desconectado

Mensajes: 239


Ver Perfil
Re: El ingenio en la simulación (proceduralismo y frames/segundo)
« Respuesta #3 en: 15 Marzo 2022, 18:09 pm »

Si te interesa realmente el tema, también yo te recomendaría que leas por lo menos algún libro básico, porque, como dijo Serapis, sigues asegurando cosas (incorrectas), a pesar de que, como tú mismo has dicho, ni siquiera sabe sabes programar.

Ahora, respondo algunos puntos.

Citar
(incluso nosotros, cuando giramos la cabeza a un lado, seguimos viendo lo que tenemos delante de los ojos igual a como lo veíamos, puesto que los ojos no se quedan fijos).

No, no es así. Al girar, la perspectiva cambia, aunque sea de forma sutil. Si no lo has notado (y hay varias razones para eso) es otra cosa, pero claro que cambia, y eso en una pantalla es aún más notorio que en el mundo real, así que los juegos tienen que calcular esa perspectiva sí o sí.

Citar
lo que facilita mucho las cosas, porque simplemente tenríamos que establecer la distncia que se recorrer con dos tipos de paso, uno caminando y otro corriendo. Yo como dije, lo quiero hacer con frames, entonces serían posiciones que darían acceso a una parte de la memoria rom donde se hubicase el frames que el pc calcularía no gráficamente pero muy velozmente, tras todo el rollo de la generación y memorización de todas las imágenes del entorno en la carga de la pantalla, para después mostrarlo).

Aquí está lo que te decía. Afirmas que es fácil o al menos relativamente fácil, y que "simplemente" tienes que establecer las distancias, cuando en realidad, de simple no tiene nada. Como ya te dijo Serapis, no es práctico hacerlo. Calcular todas las imágenes posibles, tendiendo en cuenta que en 3D tenemos 3 ejes , y que hay que calcular todas las combinaciones posibles, la cantidad de memoria requerida sería enorme, y el resultado sería bastante inútil para un juego, ya que con esto sólo habrías obtenido las imágenes desde un punto concreto. Si el jugador da un paso a la izquierda, o adelante, o a donde sea, eso cambia completamente la perspectiva de todos los objetos en pantalla, por lo que necesitarías un conjunto de imágenes distinto para cada punto posible. La cantidad de memoria requerida lo hace prácticamente inabordable. Y de todas formas, como también te dijo ya Serapis, la diferencia de velocidad entre la memoria y la potencia de CPUs y GPUs haría que, con toda probabilidad esta "solución" fuera mucho más lenta que realizar los cálculos en tiempo real, como se hace en la actualidad. Y ni hablemos de sombras, brillos o reflejos...

Lo de los desenfoques y demás tampoco es muy útil. No sólo son efectos relativamente costosos, en términos de procesamiento, sino que los ángulos de visión, puntos muertos, etc. dependen de la persona, del tamaño de la pantalla, y la distancia a la que esté sentada, además de que nada impide que en cualquier momento dirija la vista a cualquier punto de la pantalla, cosa que el juego no puede predecir. Y si cuando hablabas de seguimiento ocular te referías realmente a usar algún dispositivo físico, estaríamos creando más problemas de los que supuestamente resolvemos: hacer que el jugador tenga que invertir en un aparato potencialmente invasivo, inseguro, y a ver si tiene la velocidad necesaria para no introducir una latencia notable...

Citar
en un videojuego se carga a tope de reslución todo el contenido de la pantalla, pero es cosa que los ojos humaos no pueden aprovechar..., por ejemplo, si miraiis lo que estais leyendo ahora y os dais cuenta ¿como os aparece el resto de la pantalla?, se ve difusa mientras mantengais la vista en un punto.

De nuevo, no. Depende de cada caso, pero por lo general, especialmente en mundo abierto, y precisamente aprovechando el hecho de que en el mundo real nuestra visión es limitada, los juegos muestran modelos de distintas "resoluciones" (número de polígonos) según las posiciones de los objetos en pantalla, e incluso, como te dijo Serapis, a veces simplemente texturas planas. A medida que el jugador camina hacia ellos (y por ende, los "enfoca" mejor) se van mostrando modelos de mejor calidad.

Te reitero, si quieres entender el tema, lee algún libro. Sin saber siquiera programación, no es muy racional creer que se te va a ocurrir alguna solución que nadie más haya pensado antes (lo digo por aquello que pusiste de "Una nueva rama de la ciencia del 3d simulado"), cuando cientos, sino es que miles, de expertos, entre matemáticos e ingenieros, llevan estudiando estos asuntos desde hace décadas, cuando no siglos. Todo lo que has comentado, incluyendo lo del campo de visión de los ojos y los puntos muertos, es bien conocido desde hace décadas al menos. Si algunas de tus ideas no se han implementado, es porque se encontró que no eran realmente útiles, o que había alternativas mejores, no porque a nadie se le hayan ocurrido.
En línea

EntidadX

Desconectado Desconectado

Mensajes: 72


Ver Perfil
Re: El ingenio en la simulación (proceduralismo y frames/segundo)
« Respuesta #4 en: 17 Marzo 2022, 19:57 pm »

De acuerdo, gracias. Decir que entre este y otro hilo anterior de 3 ó 4 que he abierto desde que me registré, quedan expuestas todas las cosas que se me han ocurrido respecto a hacer que un Pentium 4 mueva fotorrealismoo (XD). Lo mismo se me ocurre alguna más con el tiempo como inpensable me era que se me hubieran ocurridos estas de ahora en el hilo más antiguo que este en el que me cuestionaba cosas del tema de exprmir al máximo las capacidades de computación de los ordenadores. Si es así lo diré...(esto es como el gestor de instalación de Xubuntu ''Si quieres contrrrribuir con la mejora de Xubuntu entra en www.xxxxxxx.com. No son necesarios conocimientos específicos para contribuir''. Eh, eh, que eso lo dicen quienes hacen el SISTEMA OPERATIVO, XD.

Bueno, de nuevo gracias, ya que yo si no es parlamentando personal o medio-personalmente, en estos últimos tiempos no estoy capacitado de aprender tecnicismos. 1 saludo.
En línea

Muerte vs vida.

4.000-3.
EntidadX

Desconectado Desconectado

Mensajes: 72


Ver Perfil
Re: El ingenio en la simulación (proceduralismo y frames/segundo)
« Respuesta #5 en: 18 Diciembre 2022, 13:53 pm »

Hace bien Elhacker.net en no archivar los hilos, porque vengo de otros foros donde los archivan y luego tienes que estar al tanto de seducir al/a la moderador/a caústico/a de turno para que te lo reabra, siendo muchas veces las probabilidades 0 (cero) directa y radicalmente.

He recordado un juego de Ps2 que me hizo pensar en este tema, el Okami de Ps2:



Y otro:



Y la verdad es que he pensado que Ps2 no tenía mucha potencia, pero sin embargo, a medio camino entre Ps2 y Ps3...



...para mover un juego que se puede considerar un dibujo artístico en movimiento (no diseño tridimensional para cada hoja de los árboles), lo cual podría dar pie a un género en el futuro que compitiese con el de hiperreaslimo e hipercomputación, y, por otra parte, los indies simuladores de lo retro, que si nos pusiésemos, podríamos sacarlos para computadoras de las que originalmente moviesen ese tipo de juegos, o sea, para las que requerirían el nivel 1 de 3 que habría, de potencia para desenvolverse con todos los juegos habidos y por haber (que se creasen siguiendo esta...política) para poder elegir si querer ver algo retro (nivel 1) una obra de arte...que se yo, infantil y de mucha fantasía (nivel 2), como fue siempre, o, por el contrario, un estilo adulto e ''hiper-poligonado'' (nivel 3 - o serie Rtx 6x00 de Nvidia y sus homólogas en Amd).

Simplemente quiero sabersi sería posible que con ordenadores del 2005 pudiésemos acceder al nivel 1 (retro), del 2010 al nivel 2 (mundos abiertos artísticos..., texturas simples pero repartidas correctamente para crear el efecto mágico de los dibujos animados. Imaginación y belleza, leñes) y luego el nivel 3 máximo...cualquier cosa que se nos ocurra, sólo que con gráficas fotorrealistas.

¿Que opinais?.

Yo no estoy para idear ningún tipo de técnica para reducir la necesidad de computación de ur ordenador creando algún algoritmo que reduzca la carga de procesamiento en partes que tienen 1 solo color abundantemente, ni siquiera se programar...aunque nunca se sabe si tendré la oportunidad de volver a ser mi propio dueño con tal de hacer lo necesario para recuperar mis capacidades de sosiego y constancia, y en ese caso, creo que los juegos de nivel 2 tendrían un mercado apasionante, abundante y muy rentable. Y todo con inocuo software en vez de tanta industria de obtención y transformación de materias primas al ritmo desorbitado de ''miles de toneladas'' anuales actuales.

¿Que os parece?.

Con esto que he dicho y que con que con la serie Rtx 6X00 de Nvidia y Amd, sólo hará falta concienciar a los desarrolladores de software libre para que ocurra que una pieza nos dure hasta que físicamente no aguante más, y no lo que la obsolecencia programada que se puede conseguir con software capitalista marque, a parte de ahorrarnos dinero que en principio no deberíamos admitir que nos engañhacen para llevarselo, por muy ''modernos'' que estemos creyendo que nos estamos volviendo  ;D.
« Última modificación: 18 Diciembre 2022, 14:12 pm por EntidadX » En línea

Muerte vs vida.

4.000-3.
Páginas: [1] Ir Arriba Respuesta Imprimir 

Ir a:  

Mensajes similares
Asunto Iniciado por Respuestas Vistas Último mensaje
COMO CAPTURO VIDEO A 30 FRAMES POR SEGUNDO A TRAVEZ DEL PUERTO USB
Multimedia
KNOX 1 1,577 Último mensaje 3 Septiembre 2004, 09:53 am
por Songoku
Ingenio descabellado
Electrónica
g0rk1L1qu1d 1 2,051 Último mensaje 29 Mayo 2005, 10:38 am
por BADBYTE-K
Entra! Ingenio para PostExplotacion en SQL Injection Load_File HELP!
Bugs y Exploits
coldalfred 0 2,791 Último mensaje 29 Abril 2012, 03:16 am
por coldalfred
El blog Microsiervos.org gana el premio Blasillo 2013, que valora el ingenio...
Noticias
wolfbcn 0 948 Último mensaje 4 Marzo 2014, 21:19 pm
por wolfbcn
Frames por segundo.
Java
ignorantev1.1 4 2,156 Último mensaje 10 Mayo 2014, 20:40 pm
por engel lex
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines