[Hilo Oficial] Efectos gráficos en videojuegos ;)

Ten en cuenta que estamos tratando los efectos de forma "genérica" (dentro de lo posible). El resultado que den en un sistema u otro no lo estamos hablando...

Hemp escribió:

€ñµff_£ïêßt_Ïkð escribió:

Hemp escribió:

Gente corriente jugando a ser expertos




El mundo de los videojuegos solo imita con mucho retraso los render de los programas de modelado.

Hacer una lista de efectos me parece una estupidez

Me parece que esto de los renders es todo un universo, que a las consolas se les esta portando una pequeñisima parte de estos efectos y malamente ¿y pretendeis hacer una lista con ejemplos y tal?

Aprender a modelar y luego venid a contar renders chulos.

Lo que tu quieras, pero es lo mismo que ponerse a hacer una lista de comandos de C que solo se usen en videojuegos

De hecho lo que están haciendo aquí no tiene absolutamente nada que ver con una lista de comandos de C que sólo se usen en videojuegos (?). Se está hablando de efectos gráficos en tiempo real para juegos. Tus renders están muy bien pero es otro mundo. Si quieres ir de sobrao, te recomiendo que dejes de decir "blur motion" y que cambies el estilo; la chulería, los 16 smileys y los tecnicismos baratos no casan bien.

El reporte por mala educación ya lo tienes, y recomendaría a todos que hagáis lo contrario de lo que yo voy a hacer: perder el tiempo contestando a este "ser"
Lo mejor que se puede hacer en este caso es reportar, pero bueno, entraremos al trapo que pocas veces se encuentran en EOL conversaciones de tan alto nivel. <ironic/>

Hemp escribió:Gente corriente jugando a ser expertos

Yo más bien diría un único personaje que pretende ir de experto.

Hemp escribió:Hacer una lista de efectos me parece una estupidez

Y tal vez tengas razón, pero el problema es que lo que se pretende aquí es hacer un GLOSARIO. En cualquier caso lo que a ti te parezca va a marcar poca diferencia, pero siempre se agradecen las opiniones.

Hemp escribió:Aprended a modelar y luego venid a contar renders chulos.

Aprende tú primero educación y luego te pasas por aquí. Quizá siendo más educado tomemos más en serio tus comentarios. O quizá no.

Por cierto, modelar algo es un concepto muy pero que muy distinto a renderizar algo, pero seguro que usted ya sabía eso ¿verdad señor "voy-de-experto"?

PD: Genial el comentario de "lista de comandos C que sólo se usan en los videojuegos", espera que te respondo de una forma que tú puedas comprenderlo:

Hemp escribió:Aprended a programar y luego venid a contar programas chulos.

Ummm no, la frase sigue sin tener sentido alguno

PPD: "blur motion", porque el lenguaje castellano no cumple la propiedad conmutativa.

€ñµff_£ïêßt_Ïkð escribió:

Hemp escribió:

Lo que tu quieras, pero es lo mismo que ponerse a hacer una lista de comandos de C que solo se usen en videojuegos

De hecho lo que están haciendo aquí no tiene absolutamente nada que ver con una lista de comandos de C que sólo se usen en videojuegos (?). Se está hablando de efectos gráficos en tiempo real para juegos. Tus renders están muy bien pero es otro mundo. Si quieres ir de sobrao, te recomiendo que dejes de decir "blur motion" y que cambies el estilo; la chulería, los 16 smileys y los tecnicismos baratos no casan bien.[/quote]


Bua mira tio, eres un trollero que solo busca baza. Si quieres ir de sobrado te recomiendo que trates a la gente de sobrada, asi en plan yo soy mas chulo que tu, y vallas de entendido sin explicar una mierda.
Estais tratando efectos mixtos de render como si fueran puros, llamando a renderizadores comerciales y especificos como si fueran los basicos y repasando panoplias de efectos mixtas para tratar de explicar que son. Jugar con la maya o con el bump es un efecto de render sobre la textura, y como ya han dicho estos van por otras bainas; mientras que tienes efectos puros como la iluminacion, el "efecto fantasma" (visto que no te gustan los anglicismos) y las nieblas que si son efectos del render.

Pero que explicarle a un troll como tu ¿que hay cientos de efectos nativos? ¿que hay cientos de miles de efectos comerciales que solo difieren un poquitin del original? ¿que mezclando efectos sacas efectos compuestos irreconocibles? ¿que hay materiales y texturas y que son cosas distintas? ¿que una foto de ambiente (enviroment map) es lo mas cutre que hay y que solo se usa cuando no tienes recursos suficientes como para materializar la maya y te lo tienes que currar con texturas? ¿que cortar cachos de codigos de C que solo se usen en videojuegos (si, lo mismo que explicar que es un render, un cacho de codigo que usualmente mezclas con otros codigos similares para realizar efectos y que raramente se usan para otra cosa como para el word o el firefox, aunque este ultimo tambien renderize) y ponerlos aqui es lo mismo?

Yo solo digo que esto lleva inventado la de dios, y que a las consolas solo estan portando los efectos mas "lijeros" y afianzados, y que hacer una lista resulta estupido ya que un render dependera de MUCHAS cosas mas que de su genero, como ya se ha visto por el hilo tratais efectos concretos de una compania en concreto y con un motor en concreto como si fuera "el efecto", en este mundo un buen render depende de mil cosas y nunca se usa un solo efecto de render, se suelen mezclar varios para mejor resultado, por eso no vais a poder hacer el hilo, porque solo podreis repasar los efectos concretos del SDK o de la desarrolladora o del motor del juego, pero nunca el efecto puro, para ver los efectos puros necesitas un ordenador, e ir alterando las variables de ese efecto, ya que segun metas mano un mismo efecto da un resultado u otro completamente distinto. En videojuegos solo puedes alucinar (si eres muy n00b) con el bump de la carretera del GTA si no has visto un render con bump en tu puta vida, pero el que modela sabe que eso existe desde hace mil y que es un efecto muy arriesgado para distancias cortas, me parece bien que la peña que no habia visto nada alucine con estos efectos y quiera clasificarlos, pero esque no lo veo viable, hay demasiados y los que llegan a los juegos estan muy retocados, ademas luego esta la pospo, que si los filtros trilineales...
Por eso digo, aprender efectos de render desde los videojuegos es como aprender c desde el codigo fuente de algun videojuego, te vas a liar, y aprenderas mal, si quereis conocer los efectos mas comunes bajate un programa de modelado y ves experimentando, luego cuando jueges al GTA diras "aiva si tiene bump maping, blur, raytrace, soft sadows y no se que mierdas mas!" Pero a la inversa como que lo veo un poco difil.

Vamos no se, te lo dize alguien que ha coseguido engañar a mas de uno con el cuento de "he estado en galicia, mira que fotos mas chulas y que cacho de castillo me encontre" y resulta que no existia ni el cesped, si tu piensas que a base de viciarte vas a poder discriminar igual pues nada...

P.D.:zheo me encanta tu demagogia y me parece asombrosa tu inteligencia, se nota que escribes pensando y razonando.

Hemp escribió:[qmparto]

Gente corriente jugando a ser expertos




A ver, los efectos de render son propios del software y de la plataforma, un mismo efecto de render (blur motion por ejemplo) no sale igual en una 360 que en un ordenador con 3dmax, entre otras cosas porque en un ordenador este efecto es configurable, luego hay mil efectos que varian mazo de un software a otro siendo el mismo efecto, y luego hay millones de trukitos para hacer un render camuflado, como el smoot, el bump, el displaze texture...

En modelado los efectos de render estan MUY MUY avanzados, yo personamente me quede flipando con el final render, en el que con unas texturas de mierda y unas mallas aun mas penosas daban resultados difilmente distingibles de la realidad. El mundo de los videojuegos solo imita con mucho retraso los render de los programas de modelado.

Hacer una lista de efectos me parece una estupidez, porque una 360 y una ps3 nunca tendran ni tan siquiera la misma iluminacion, por lo que no son ni equiparables, habria que hacer una lista con los efectos de cada plataforma, y es sabido que estos efectos solo dependen de la potencia de la consola y del SDK., por lo que no solo habria que valorar el efecto si no la calidad del mismo.
¿y los efectos sobre texturas y los volumetricos? como el antioscopic ( o como se diga) o el fog ya solo dependen del juego, ni del SDK.

Me parece que esto de los renders es todo un universo, que a las consolas se les esta portando una pequeñisima parte de estos efectos y malamente ¿y pretendeis hacer una lista con ejemplos y tal?

Aprender a modelar y luego venid a contar renders chulos.

no habia visto un post tan poco beneficioso para un hilo con buenas intenciones... si eres tan listo y sabes tanto... y esto te parece patetico con no responder sobra, pero venir a intentar desprestigiar a la gente que solo quiere informarse de los efectos y las cosas que se uitlizan o se utilizaron para saber un poco de un tema que desconocen me parece mearse fuera del tiesto, sinceramente, si no tienes ni idea me parece una actitud infantil, inmadura y con una complejidad enorme, si eres una persona que sabe, me parece una actitud bochornosa y fuera de lugar... sinceramente hazte un favor a ti mismo y borra ese mensaje y haz como que no has posteado porque ese post solo demuestra que como usuario dejas mucho que desear y como persona tienes que ser lamentable para venir a un foro de usuarios de videoconsolas a pavonearte de que eres un experto.. gente asi es la que no necesita EOL...

P.D: te podias casar con la señorita pixel plus-ojo bionico, aunque creo que ella aborrecia a los fumetas y tenia algo de buen gusto al menos...

Información

Ya se ha informado este mensaje

Volver al último hilo visitado



Por lo visto no soy el único que considera que te estás pasando de la línea Hemp.

Y multiplataforma también incluye a PC, curiosamente no lo has mencionado.

red0n escribió:no habia visto un post tan poco beneficioso para un hilo con buenas intenciones... si eres tan listo y sabes tanto... y esto te parece patetico con no responder sobra, pero venir a intentar desprestigiar a la gente que solo quiere informarse de los efectos y las cosas que se uitlizan o se utilizaron para saber un poco de un tema que desconocen me parece mearse fuera del tiesto, sinceramente, si no tienes ni idea me parece una actitud infantil, inmadura y con una complejidad enorme, si eres una persona que sabe, me parece una actitud bochornosa y fuera de lugar... sinceramente hazte un favor a ti mismo y borra ese mensaje y haz como que no has posteado porque ese post solo demuestra que como usuario dejas mucho que desear y como persona tienes que ser lamentable para venir a un foro de usuarios de videoconsolas a pavonearte de que eres un experto.. gente asi es la que no necesita EOL...

P.D: te podias casar con la señorita pixel plus-ojo bionico, aunque creo que ella aborrecia a los fumetas y tenia algo de buen gusto al menos...

gente como tu me da pena, yo solo me paso a tratar de decir que estais tratando de clasificar efectos concretos como genericos, te pongo el simil de que programacion no se puede aprender a partir del source de un juego, si no a partir de un compilador. Pues lo mismo me parece este hilo, aprender fundamentos sobre renderizacion a partir de videojuegos, y luego esperas que no me parta, date una vueltecilla por internet ( si hay que salir de EOL, es lo que tiene) y vereis cosas realmente alucinantes que no sabras ni como las han pario, y luego pretendes aprender a discernir efectos a partir de ver videojuegos? lo dicho, tu mismo.

Yo no trato de kitarle flow al hilo, pero mover el everest de sitio nunca me parecio una buena idea, decir que es una burrada y despollarme de quien lo intente es motivo para este acoso y derribo?

Tiene cojones que tú precisamente me digas que trolleo, y que voy de sobrao y de entendido...

Los anglicismos me dan igual, dije tecnicismos baratos. Aprende a leer.

Aunque quizá debería, no me voy a meter con tus lamentables ortografía y redacción porque bastante tienes con lo que tienes y me da pereza.

Te propongo lo siguiente: sal de este hilo un ratito, menéatela, relájate, piensa en por qué y cómo has hecho tantos nuevos amigos hoy, y luego si no te da vergüenza vuelves y nos cuentas más cosas sobre efectos 3D, que por lo visto se te da mucho mejor que la dialéctica y era el tema principal antes de tu barriobajera intervención.

Ah, y la próxima vez cita correctamente o no cites en absoluto, porque a primera vista da la sensación de que uno de mis mensajes lo has escrito tú, y no querrás que te confundan con un troll como yo

Hemp escribió:...

Este hilo "solo" va servir para dar soprte a un artículo del wiki, donde todos pueden colaborar. Si te ves con ganas, pon tu granito de arena; si no, no des por cu**. Se pretende que, aunque sea de forma muy básica, cuando a alguien le dicen que el Halo 8000 o que el Metal Gear Chuminada 6000 usan efectos HDR/bloom/ni lo se ni me importa, sepa más o menos de que co*o le están hablando. Es orientativo.

PD: Si vieses la cantidad de gente que no sabe que es el V-Sync o el bloom ("eso que se ve como se parte la pantalla" , "luz radiactiva" ) este hilo no te parecería una chorrada. Si sigues sin aportar nada útil al hilo y te metes solo a incordiar, reportaré tus mensajes (e informaré en Feedback si la cosa se pone muy mal).

€ñµff_£ïêßt_Ïkð escribió:Tiene cojones que tú precisamente me digas que trolleo, y que voy de sobrao y de entendido...

Los anglicismos me dan igual, dije tecnicismos baratos. Aprende a leer.

de acuerdo, prometo aprender a leer, pero promete tu aprender a comprender.

Aunque quizá debería, no me voy a meter con tus lamentables ortografía y redacción porque bastante tienes con lo que tienes y me da pereza.

No te vas a meter con mi ortografia porque tengo el corrector ortografico del firefox y paso de usarlo (hay que ver cuanto culto hay suelto que valora mas el continente que el contenido... )

Te propongo lo siguiente: sal de este hilo un ratito, menéatela, relájate, piensa en por qué y cómo has hecho tantos nuevos amigos hoy, y luego si no te da vergüenza vuelves y nos cuentas más cosas sobre efectos 3D, que por lo visto se te da mucho mejor que la dialéctica y era el tema principal antes de tu barriobajera intervención.

Pues mira, tienes razon, discutir con gente que no pasa de leer mi primer comentario cansa. en cuanto al contenido, pues yo pienso que esto encaja mas en misce o en PC, y si gente asi de racional pretende ser mi amigo, pues mejor apaga y vamonos.

Ah, y la próxima vez cita correctamente o no cites en absoluto, porque a primera vista da la sensación de que uno de mis mensajes lo has escrito tú, y no querrás que te confundan con un troll como yo

Pues resuleto, me hago una pajilla y vuelvo a ver si este hilo se endereza, si es asi, igual como dizes me paso a aportar algo que tenga sentido aportar, mientras, si salta alguien contestando (despues de lo dicho) mi primer post (truncado o sin truncar), ya sabeis a quien decir que se esta cargando el hilo. y repito mi ultima cita que parece que no queda claro la intencionalidad del primer post: Yo no trato de kitarle flow al hilo, pero mover el everest de sitio nunca me parecio una buena idea, decir que es una burrada y despollarme de quien lo intente es motivo para este acoso y derribo?

P.D.: no se que haze la gente reportandome, me faltan mas el respeto a mi de lo que subjetibamente uno se puede dar por aludido (siendo sensiblero), y lo que es mas grabe y si que recoje la legislacion española, la intencionalidad de la falta de respeto, la cual yo en ningun momento he tenido y muchos "reportadores" han exibido a la par que hacian gala de su educacion, la cual me reprochavan (manda huevos).

wabo escribió:

Hemp escribió:...

Este hilo "solo" va servir para dar soprte a un artículo del wiki, donde todos pueden colaborar. Si te ves con ganas, pon tu granito de arena; si no, no des por cu**. Se pretende que, aunque sea de forma muy básica, cuando a alguien le dicen que el Halo 8000 o que el Metal Gear Chuminada 6000 usan efectos HDR/bloom/ni lo se ni me importa, sepa más o menos de que co*o le están hablando. Es orientativo.

PD: Si vieses la cantidad de gente que no sabe que es el V-Sync o el bloom ("eso que se ve como se parte la pantalla" , "luz radiactiva" ) este hilo no te parecería una chorrada. Si sigues sin aportar nada útil al hilo y te metes solo a incordiar, reportaré tus mensajes (e informaré en Feedback si la cosa se pone muy mal).

De hecho creo que ya están reportados prácticamente todos sus mensajes en este hilo... Sólo espero que no se sigan llenando páginas contestándole a alguien que, obviamente, ni se lo merece...

Por cierto, esta tarde estoy un poco ocupado, lo siento mucho. De todas formas sí que estoy leyendome la ayuda del wiki para saber cómo comenzar.

Hemp escribió:

red0n escribió:no habia visto un post tan poco beneficioso para un hilo con buenas intenciones... si eres tan listo y sabes tanto... y esto te parece patetico con no responder sobra, pero venir a intentar desprestigiar a la gente que solo quiere informarse de los efectos y las cosas que se uitlizan o se utilizaron para saber un poco de un tema que desconocen me parece mearse fuera del tiesto, sinceramente, si no tienes ni idea me parece una actitud infantil, inmadura y con una complejidad enorme, si eres una persona que sabe, me parece una actitud bochornosa y fuera de lugar... sinceramente hazte un favor a ti mismo y borra ese mensaje y haz como que no has posteado porque ese post solo demuestra que como usuario dejas mucho que desear y como persona tienes que ser lamentable para venir a un foro de usuarios de videoconsolas a pavonearte de que eres un experto.. gente asi es la que no necesita EOL...

P.D: te podias casar con la señorita pixel plus-ojo bionico, aunque creo que ella aborrecia a los fumetas y tenia algo de buen gusto al menos...

gente como tu me da pena, yo solo me paso a tratar de decir que estais tratando de clasificar efectos concretos como genericos, te pongo el simil de que programacion no se puede aprender a partir del source de un juego, si no a partir de un compilador. Pues lo mismo me parece este hilo, aprender fundamentos sobre renderizacion a partir de videojuegos, y luego esperas que no me parta, date una vueltecilla por internet ( si hay que salir de EOL, es lo que tiene) y vereis cosas realmente alucinantes que no sabras ni como las han pario, y luego pretendes aprender a discernir efectos a partir de ver videojuegos? lo dicho, tu mismo.

Yo no trato de kitarle flow al hilo, pero mover el everest de sitio nunca me parecio una buena idea, decir que es una burrada y despollarme de quien lo intente es motivo para este acoso y derribo?

a mi me da igual lo que se diga aquí, es un chapuceo para que la gente valla menos perdida, no se habla de aprender y enseñar a renderizar, ni mucho menos, nisiquiera he aportado nada al hilo porque no me parecia apropiado, pero venir, incordiar, no decir nada lucrativo para el hilo, tirarse el moco y poner a parir a la peña para demostrar lo bueno que soy me parece lamentable en muchos aspectos, me da igual el tema que sea, sigue siendo una actitud narcisista, egocentrica y sin sentido, si no te gusta el hilo con pasar de el sobra, aqui solo se dicen efectos y lo que hacen en pantalla, ni como ni porque ni para que, solo para ver cuando se hable de vsync o algo parecido se tenga en la wiki un minimo de informacion para saber de que se habla, si quieres aportar algo empieza a decir las burradas que se dicen, que esta mal y arreglarlo, sino vas a hacer algo parecido no se para que posteas... para subir el ego de uno hay otros metodos...

A tomar por saco un hilo tan interesante. Estamos a tiempo de salvarlo?

GR SteveSteve escribió:De hecho creo que ya están reportados prácticamente todos sus mensajes en este hilo... Sólo espero que no se sigan llenando páginas contestándole a alguien que, obviamente, ni se lo merece...

Por cierto, esta tarde estoy un poco ocupado, lo siento mucho. De todas formas sí que estoy leyendome la ayuda del wiki para saber cómo comenzar.

Yo intentaré echarte un cable para pasar la información, ahora que he terminado el "Project STC" -creo que pronto lo veréis-; y te insisto, ante cualquier duda, al foro del wiki, que Yoda estará encantado de ayudar.

Hemp escribió: P.D.:zheo me encanta tu demagogia y me parece asombrosa tu inteligencia, se nota que escribes pensando y razonando.

Que mi inteligencia te parezca asombrosa no me extraña, no por que yo sea muy inteligente, sino por defecto tuyo: amplifica la diferencia...
Veo que te gusta usar palabras de las que desconoces su significado, tranquilo:
demagogia (Del gr. δημαγωγία).

1. f. Práctica política consistente en ganarse con halagos el favor popular.

2. f. Degeneración de la democracia, consistente en que los políticos, mediante concesiones y halagos a los sentimientos elementales de los ciudadanos, tratan de conseguir o mantener el poder.

Incluso si obviamos la parte de "práctica política", si eres capaz de decirme cómo me gano el favor "popular" con "halagos" te ganas un gallifante.

Pero no te preocupes, se por experiencia que cuando la gente no tiene argumentos insulta o se intenta hacer la graciosa. Sin gracia.
Al menos has elegido la segunda opción. Eso te honra.

Hemp escribió:Bua mira tio, eres un trollero que solo busca baza. Si quieres ir de sobrado te recomiendo que trates a la gente de sobrada, asi en plan yo soy mas chulo que tu, y vallas de entendido sin explicar una mierda.
Estais tratando efectos mixtos de render como si fueran puros, llamando a renderizadores comerciales y especificos como si fueran los basicos y repasando panoplias de efectos mixtas para tratar de explicar que son. Jugar con la maya o con el bump es un efecto de render sobre la textura, y como ya han dicho estos van por otras bainas; mientras que tienes efectos puros como la iluminacion, el "efecto fantasma" (visto que no te gustan los anglicismos) y las nieblas que si son efectos del render.

EL único troll que busca baza aquí eres tú. Y te recomiendo que antes de hablar aprendas un poco. El verbo ir se conjuga con Y, es decir, se dice vaYas no vaLLas. Zoquete.

Aquí no se ha mezclado nada, simplemente se habla de efectos gráficos. Que se realizan por un renderizador u otro es una cuestión distinta, pero el efecto es el mismo.

Pero que explicarle a un troll como tu ¿que hay cientos de efectos nativos? ¿que hay cientos de miles de efectos comerciales que solo difieren un poquitin del original? ¿que mezclando efectos sacas efectos compuestos irreconocibles? ¿que hay materiales y texturas y que son cosas distintas?

Y cómo explicarle a un zoquete como tú, que los efectos que difieren "un poquitín" del original, difieren porque los parámetros que se aplican son diferentes, no porque el método es distinto.
Una parábola surge de una ecuación de segundo grado, y hay infinitas parábolas. Sólo un ignorante diría que x^2 y x^2+3 no son el mismo tipo de función (parábolas). Felicidades, eres ese ignorante.

¿que una foto de ambiente (enviroment map) es lo mas cutre que hay y que solo se usa cuando no tienes recursos suficientes como para materializar la maya

Para empezar te recomendaré que dejes de traducir los términos que todo el mundo usa en inglés. No, no te hace más culto, al contrario. Por otro lado, voy a suponer que decir la maLLa ¿verdad? Muy culto por tu parte. De todas maneras sigo sin saber qué cojones significa "materializar la malla". Supongo que habremos visto mucho Star Trek y claro, se nos pegan las palabras del teletransporte. Sigamos.

y te lo tienes que currar con texturas?

Si supieras lo más mínimo de gráficos en tiempo real, que está claro que no tienes pero ni putísima idea, sabrías que cuando intentas hacer 30 renders por segundo, más geometría implica más carga para la tarjeta y el procesador (al tener que mover más datos usando el bus de datos) y más carga para la gráfica (al tener que procesar más vértices) si lo puedes evitar con operaciones que generan un resultado similar es una maravilla.
Pero claro, olvidaba que hablo con un "experto". A lo mejor su señoría tiene una forma más eficiente de realizarlo. Adelante. Creo que están buscando papers para el GPU Gems 6. No te cortes...

¿que cortar cachos de codigos de C que solo se usen en videojuegos (si, lo mismo que explicar que es un render, un cacho de codigo que usualmente mezclas con otros codigos similares para realizar efectos y que raramente se usan para otra cosa como para el word o el firefox, aunque este ultimo tambien renderize) y ponerlos aqui es lo mismo?

Cortar "cachos de códigos de C que sólo se usen en videojuegos" es una frase que sólo indica que no tienes ni puta idea de programación (otro tema del que vas de "experto")

Yo solo digo que esto lleva inventado la de dios, y que a las consolas solo estan portando los efectos mas "lijeros" y afianzados

Si supieras un poco de lo que hablas -que has dejado claro que no- descubrirías que muchos de los efectos que se usan en tiempo real son (lógicamente) simplificaciones, o incluso mejoras que surguieron para los gráficos en tiempo real (busca por sombras volumétricas y por el famoso "Carmacks reverse", so listillo)

hacer una lista resulta estupido ya que un render dependera de MUCHAS cosas mas que de su genero, como ya se ha visto por el hilo tratais efectos concretos de una compania en concreto y con un motor en concreto como si fuera "el efecto"

Puedes poner un ejemplo de eso por favor. Porque mucho hablas y poco demuestras.

Por eso digo, aprender efectos de render desde los videojuegos es como aprender c desde el codigo fuente de algun videojuego, te vas a liar, y aprenderas mal,

Da la causalidad que aprender del código de otros es la manera más rápida y eficiente de aprender, ya que no tienes que reinventar la rueda.
De nuevo demostrando tu falta de conocimiento en temas que no dominas. No te cortes, yo no lo haré.

Vamos no se, te lo dize alguien que ha coseguido engañar a mas de uno con el cuento de "he estado en galicia, mira que fotos mas chulas y que cacho de castillo me encontre" y resulta que no existia ni el cesped, si tu piensas que a base de viciarte vas a poder discriminar igual pues nada...

VAMOS MEJORANDO: Comparas renders con edición de fotos en 2D que no tiene nada que ver. Poner un castillo de fondo con el potochó lo hace cualquiera con un par de semanas de entrenamiento lechón.
Eres un grande. Un "grande" ignorante quiero decir.

Mecagüen los zoquetes que han cogido el maya para hacer dos putos renders y se creen que ya saben programar un renderizador y un raytracer. Zoquetes!

PD: Que cortemos tu mensaje, a pesar de tu anuncio en la firma, no sé como decirtelo suavemente... me suda la polla. Denunciame.

PPD: Tienes como un gritón de palabras más donde confundes la v y la b. No te las corrigo porque los post de EOL tienen un límite de caracteres. Antes de dar lecciones aprende a escribir. Aunque sólo sea para que te tomen en serio.

A ver si alguien puede explicar el fogging, que supongo que estará relacionado con la niebla, ¿me equivoco?

Por favor, dejad de contestar a Hemp y centraros en el hilo. Gracias por vuestra colaboración.

TDK_16, efectivamente. Fogging (de fog--> niebla en inglés): ya buscaré más información, pero em imagino que se referirá al uso de niebla para "ocultar" objetos sin cargar en pantalla y así aligerar la carga gráfica (Silent Hill o Dinasty Warriors serían 2 buenos ejemplos) pero sin popping, o mejor dicho, para taparlo. (EDITO: Mñn te pongo una explicación un poco más elaborada, que el sueño se empieza a notar ya )
----------------------------------------------------------------------------------------

Y SI, ESTE HILO AÚN ES SALVABLE. CON VUESTRA AYUDA Y APORTANDO COSAS INTERESANTES AL MISMO. NO OS ENZARCEIS EN DISCUSIONES FÚTILES. PUES: "NO HAY MAYOR DESPRECIO QUE NO HACER APRECIO"

TDK_16 escribió:A ver si alguien puede explicar el fogging, que supongo que estará relacionado con la niebla, ¿me equivoco?

Fogging no lo conozco. La niebla es un recurso más que hay para evitar el popping que han comentado antes.
Explicándolo rápidamente (espero que los "expertos" no se mosqueen), el problema es que dada una escena 3D, los objetos que realmente vas a visualizar son los que caen dentro del volumen de visualización. Esto es simplemente una manera de poner limites a la cantidad de objetos a dibujar. Por ejemplo si tuvieras una escena 3D que mostrara varios kilómetros de un espacio abierto, seguramente los objetos más lejanos no merecerá la pena dibujarlos, ya que apenas los verás.

Pues bién, el problema de esto es que si dibujas objetos que estén a una distancia X de la cámara tiene el problema siguiente: los objetos que están a una distancia x+1 no se dibujarán, pero si ese objeto pasa a estar a una distancia x, aparecerá de repente!

La niebla ayuda a paliar ese efecto. básicamente la niebla mezcla cada pixel que ves en pantalla con un color (normalmente blanco, porque la niebla es blanca y tal ) y ese color es más o menos transparente según esté a menos o más distancia de la cámara.
Dicho de otra manera, los objetos más lejanos (casi fuera del volumen de visualización) aparecerán casi blancos, y los que estén relativamente cerca de la cámara no serán modificamos. Esa graduación sirve para que no se note que los objetos aparezcan de repente.

Luego hay niebla mucho más elaborada (volumétrica) que sólo aplican este efecto para pixeles con más restricciones. Por ejemplo,aplicar niebla sólo dentro de un área determinada (una habitación por ejemplo) y sólo para píxeles cercanos al suelo, provoca un efecto de este estilo:

PD: viéndolo un poco mejor esta niebla parece más un efecto de partículas, pero bueno, se entiende.

zheo escribió:

TDK_16 escribió:A ver si alguien puede explicar el fogging, que supongo que estará relacionado con la niebla, ¿me equivoco?

...
PD: viéndolo un poco mejor esta niebla parece más un efecto de partículas, pero bueno, se entiende.

Muy bien explicado; aqui fotos del Silent Hill (varias versiones)



Se ve más oscuro a poca distancia.



El fondo no se ve...



La esquina del hospital ni se ve.



Apartir de la farola ya no se ve nada.



CREADAS LAS SECCIONES DEL WIKI

- Efectos gráficos http://www.elotrolado.net/wiki/Categor%C3%ADa:Efectos_gr%C3%A1ficos
-Defectos gráficos
http://www.elotrolado.net/wiki/Categor%C3%ADa:Defectos_gr%C3%A1ficos

Ambas dentro de:
- Diccionario de términos http://www.elotrolado.net/wiki/Categor%C3%ADa:Diccionario_de_t%C3%A9rminos

Que a su vez está dentro de:
-Videojuegos:
http://www.elotrolado.net/wiki/Categor%C3%ADa:Videojuegos

Muchas gracias por vuestra ayuda!!!

A ver si se anima más gente a compartir sus conocimientos y a leerse los nuestros ^^

Una duda que tengo. El segundo modo de aplicar la niebla, no es equivalente a los efectos de humo, polvo, etc. que se pueden ver en los juegos de coches, por ejemplo? Son en realidad elementos 2-d, no?

Me gustaría hablar de las animaciones relacionadas con la sustitución de polígonos y texturas. Me parece un tema muy interesante porque es algo que se usa también en todos los juegos (la degradación o transformación de objetos).

Muy buen hilo, mis felicitaciones a los que lo hacéis posible, me he entretenido un rato leyendo todas vuestras respuestas. Intentaría aportar algo pero mi conocimiento del tema es nulo. Un saludo y enhorabuena.

Da la causalidad que aprender del código de otros es la manera más rápida y eficiente de aprender, ya que no tienes que reinventar la rueda.

Discrepo. Según mi parecer, si estás 'aprendiendo' es mejor sacar tus propios resultados primero, luego ya mirarás formas alternativas que puedan ser más eficientes.

Buen hilo, no dejéis que decaiga

rintin escribió:Discrepo. Según mi parecer, si estás 'aprendiendo' es mejor sacar tus propios resultados primero, luego ya mirarás formas alternativas que puedan ser más eficientes.

Como todo depende del proyecto. Por ejemplo para estudiar el diseño e implementación de una aplicación o un motor gráfico nunca está de más ver él código de otros para ver por dónde pueden ir los tiros. Y obtener resultados primero puede ser algo inasequible. Cuanto más código veas mejor programador serás.
Pero fíjate que lo que yo digo es que para aprender es más rápido y eficiente tener código, ya que aprendes antes y mejor, pero obviamente en casos concretos de implementaciones; no para adquirir conociemientos teóricos eso es cierto al margen de lo que cada uno considere que es mejor de cara al aprendizaje en si.

zheo escribió:

rintin escribió:Discrepo. Según mi parecer, si estás 'aprendiendo' es mejor sacar tus propios resultados primero, luego ya mirarás formas alternativas que puedan ser más eficientes.

Como todo depende del proyecto. Por ejemplo para estudiar el diseño e implementación de una aplicación o un motor gráfico nunca está de más ver él código de otros para ver por dónde pueden ir los tiros. Y obtener resultados primero puede ser algo inasequible. Cuanto más código veas mejor programador serás.
Pero fíjate que lo que yo digo es que para aprender es más rápido y eficiente tener código, ya que aprendes antes y mejor, pero obviamente en casos concretos de implementaciones; no para adquirir conociemientos teóricos eso es cierto al margen de lo que cada uno considere que es mejor de cara al aprendizaje en si.

Una vez aclarada tu postura, totalmente de acuerdo. Soy programador, y hay mucha gente que intenta aprender viendo código ya finalizado, y eso puede darte unas guías en según que aspectos, pero no se adquieren unos conocimientos profundos de todo el contenido si no se aprende pensando soluciones por uno mismo.

Como todo también dependerá de la persona, pero es mi parecer.

Saludos!

Guau, eres programador, profesionalmente? Es la profesión que espero tener en un futuro. Permíteme preguntarte off topic: ¿Qué clase de aplicaciones desarrollas?

GR SteveSteve escribió:Guau, eres programador, profesionalmente? Es la profesión que espero tener en un futuro. Permíteme preguntarte off topic: ¿Qué clase de aplicaciones desarrollas?

[OFF TOPIC]
Recién titulado pero sí.

Hasta ahora, para empresas he realizado programas de gestión interna y programación web (en mis estudios de todo, juegos tb pero lo que nos permitían los lenguajes dados, que vienen a ser juegos de tablero, tragaperras, didácticos y poco más). Este verano me doy un respiro, y sobre septiembre me buscaré algo en intensiva de mañana o media jornada (que en ese horario como programador está jodido pero es lo que hay, seguramente tenga que pillar algo de helpdesk orientado a programación que es el tipo de trabajo que más flexibilidad de horarios tienen), ya que el próximo año me especializo en un máster en diseño y creación de videojuegos (concepción artistica, guion, 3d, texturas, programación orientada a éstos, game enginyes, desarrollo para consolas nextgen, etc).

Como habrás deducido, mi meta ideal es programar profesionalmente dentro del mundo del ocio eletrónico. Si puede ser, perfecto. Sino, aceptaré dentro de un par de años si sigo teniendo contacto con mi 'enchufe' lo que he rechazado ahora por incompatibilidad de horarios (programador en una multinacional del sector).

Saludos y suerte, puestos no faltan, que se necesita mucha gente buena en este sector
[/OFF TOPIC]

Gracias por responder. Volviendo al tema, que no decaiga el hilo!

Alguien más se apunta a añadir sus conocimientos? O ya no interesa el tema?

¿No había una forma de unir el hilo con el wiki para que al principio aparezca un enlace a la sección correspondiente? Me parece haber visto algo así en hilos de ventas. Queda mejor que tener que editar el primer mensaje, que por otra parte no llama tanto la atención.

Ahora que me fijo, aquí hay un ejemplo de lo que digo: hilo_hilo-oficial-ventas-famitsu-media-create-23-6-29-6_1051375

rintin escribió:Soy programador

No, no lo eres.

Turyx escribió:

rintin escribió:Soy programador

No, no lo eres.

xD Pues mi certificado con 9,78 final y la mención honorifica de mi proyecto dicen que sí ^^

Pd.: Ya vuelvo a tener internet Turyxcillooooooooooo (alfin! xD)

zheo escribió:Mecagüen los zoquetes que han cogido el maya para hacer dos putos renders y se creen que ya saben programar un renderizador y un raytracer. Zoquetes!

que buena frase zheo me la apunto jejeje

Si os interesa no se si muy bien entran dentro de efecto graficos:

Vertex lighting :
Se determinan cuantos polígonos cruzan el vértice, se toma el total de todas las orientaciones de los polígonos (Normales) y se asigna la normal al vértice. Para cada vértice, un polígono dado reflejará la iluminación en una forma levemente distinta. La ventaja es que al hardware le toma menos tiempo el procesarlo, pero este tipo de iluminación no produce sombras.{lo saco de wiki que , creo que queda mejor explicado que si me lio a ello}


problemas de esta tecnica, la mesh { malla}, si no esta mmm a ver el termino es tessellated { dividido creo que es el termino en castellano } y mas cuando son objetos { o mallas como querais llamarlo} son grandes, el reparto de luz no es correcto y pasa a un segundo plano y la luz proyectada no se refleja bien sobre ella.

Ej:


siempre funcionara mejor en la derecha que en la izquierda.

Cosas que hay que tener en cuenta , con Vertex lighting endureciendo las aristas o suavizandolas {hard edges o soft} se colorea de diferente forma siempre dependiendo del angulo de tus vertex normals {normales de cada cara}.
Resumiendo grabar la informacion de la luz en la geometria propiamente creada y que se va a usar, logicamente se utiliza estas tecnicas por que no gastan recursos dentro de los motores de los juegos.

Existen tecnicas como Per-pixel lighting que es como Vertex lighting , solo que esta tecnica colorea cada pixel , es mas precisa pero mas consumo de memoria y procesador.
Y aun asi existen mas tecnicas como lightmaps { Los lightmaps son texturas que contienen la información del color, sombras y dirección de la luz y se utilizan para objetos estáticos},Dynamic lighting y alguna mas que fijo que me dejo {raytracing, normal maps,etc.. }.

Espero que quede mas o menos claro y si he metido la pata por algun lado decirlo y asi aprendo yo tambien

por cierto existen libros { eso si sobre todo en ingles } para quien quiera ganar conocimientos desde el principio sobre todo enfocado a 3d ,como creating the art of the game de matthew omernick.


Un saludo

Darkbatman escribió:que buena frase zheo me la apunto jejeje

pues a pagar por el copyright!!!
No, es coña, esto no es la SGAE

Si os interesa no se si muy bien entran dentro de efecto graficos:

Vertex lighting :
Se determinan cuantos polígonos cruzan el vértice, se toma el total de todas las orientaciones de los polígonos (Normales) y se asigna la normal al vértice. Para cada vértice, un polígono dado reflejará la iluminación en una forma levemente distinta. La ventaja es que al hardware le toma menos tiempo el procesarlo, pero este tipo de iluminación no produce sombras.{lo saco de wiki que , creo que queda mejor explicado que si me lio a ello}


problemas de esta tecnica, la mesh { malla}, si no esta mmm a ver el termino es tessellated { dividido creo que es el termino en castellano } y mas cuando son objetos { o mallas como querais llamarlo} son grandes, el reparto de luz no es correcto y pasa a un segundo plano y la luz proyectada no se refleja bien sobre ella.

Ej:


siempre funcionara mejor en la derecha que en la izquierda.

Cosas que hay que tener en cuenta , con Vertex lighting endureciendo las aristas o suavizandolas {hard edges o soft} se colorea de diferente forma siempre dependiendo del angulo de tus vertex normals {normales de cada cara}.
Resumiendo grabar la informacion de la luz en la geometria propiamente creada y que se va a usar, logicamente se utiliza estas tecnicas por que no gastan recursos dentro de los motores de los juegos.

Existen tecnicas como Per-pixel lighting que es como Vertex lighting , solo que esta tecnica colorea cada pixel , es mas precisa pero mas consumo de memoria y procesador.
Y aun asi existen mas tecnicas como lightmaps { Los lightmaps son texturas que contienen la información del color, sombras y dirección de la luz y se utilizan para objetos estáticos},Dynamic lighting y alguna mas que fijo que me dejo {raytracing, normal maps,etc.. }.

Espero que quede mas o menos claro y si he metido la pata por algun lado decirlo y asi aprendo yo tambien

por cierto existen libros { eso si solo en ingles }

Fixed

Este es EL libro. Tiene DE TODO. Eso si, refresca las matemáticas y la física en la parte de iluminación ..

http://www.amazon.com/Real-Time-Renderi ... 1568811829
Está al salir la 3ª ed.
http://www.realtimerendering.com/

Luego respondo al resto, porque la iluminación digamos que no son "tecnicas" sino modelos.

zheo escribió:Este es EL libro. Tiene DE TODO. Eso si, refresca las matemáticas y la física en la parte de iluminación ..

http://www.amazon.com/Real-Time-Renderi ... 1568811829
Está al salir la 3ª ed.
http://www.realtimerendering.com/

Luego respondo al resto, porque la iluminación digamos que no son "tecnicas" sino modelos.

bah ya sabes estos del 3d siempre cambiando los terminos somos unos impresentables, abra que pedirlo aun que eso de matematicas y fisica que te echo yo jajaja , por cierto en breve empiezo un master MCAD de ms { en plan a ver q tal se me da, Visual C# .NET o me dedico a las canicas }

Revivo el hilo con la siguiente pregunta:

¿En qué consiste el "tearing"? (supongo que será un defecto gráfico como el popping)

Que yo sepa el tearing consiste en que en pantalla aparezca parte del frame anterior y parte del actual. Es un problema de desincronización entre las escrituras en el framebuffer y el refresco de la pantalla.

Tearing. Exactamente como dice Dr.Demencio: por una desincronización a la hora de escribir.

Pero ésta desincronización puede ser por un par de causas. Primero explico un poco como se dibuja en la pantalla.

La tarjeta gráfica tiene una zona de memoria llamada framebuffer que contienen la información que se va a dibujar en pantalla. Es decír, ahí está contenida únicamente información de color por cada pixel de pantalla. Esa información es la que se enviará a la pantalla para que ésta pinte el color correspondiente.

Adicionalmente y por norma general la tarjeta utilizar un buffer idéntico al framebuffer denominado backbuffer. En él es dónde se realiza realmente la modificación de datos, es decir, cuando estamos pintando un frame modificamos el backbuffer, y cuando hemos acabado intercambiamos el backbuffer con el framebuffer. Ésta técnica es bien conocida y se denomina "double buffer", y es poco menos que algo básico a la hora de pintar cualquier cosa en pantalla.

Luego por otro lado, la pantalla está constantemente dibujando información "leyéndola" del framebuffer. La pantalla dibuja de forma secuencial: empieza por el píxel superior izquierdo, y dibuja línea a línea hasta llegar a la última línea y el último píxel: el inferior derecho.
Sin embargo hay un momento en el que no dibuja, el momento en que se produce un vsync. El VSync se producía anteriormente cuando el haz de electrones de los monitores CRT se posicionaba de la parte inferior derecha de la pantalla a la parte superior izquierda para volver a repintar la pantalla completa. Aunque ese tiempo que tarda es del orden de milisegundos, son milisegundos en los que no se dibuja nada en la pantalla, es decir, la pantalla no "lee" información del framebuffer. Ai en el tiempo en que se produce un vsync modificamos los datos del framebuffer, éstos no se harán visibles hasta que el período del vsync finalice.

El VSync aunque en los TFTs no es necesario ya que éstos no repintan la pantalla como un CRT, se produce igualmente si no me equivoco simplemente como medida para medir un período de tiempo (si una pantalla refresca a 60Hz, tendrá 60 VSyncs por segundo) y supongo que por razones de compatibilidad.

Entonces, ¿por qué se produce el tearing?

1) Por no utilizar double buffer. Si escribes información en el mismo lugar de donde lee la pantalla, esos cambios se verán constantemente reflejados en pantalla por lo tanto se verá cómo actualizas el frame cada vez que cambies un sólo pixel.
Esto es un ejemplo perfecto de lo que provoca usar un único buffer:
http://es.youtube.com/watch?v=Rg2A557DoKk

2) Por no sincronizar cambios de frame. Ok, hemos dibujado un frame completo (frame 1) en el frontbuffer, y estamos dibujando el siguiente (frame 2)en el backbuffer. Acabamos de dibujarlo e inmediatamente los intercambiamos.
Desgraciadamente la pantalla estaba dibujando en ese momento del frontbuffer anterior (que contenía el frame1, y que ahora hemos intercambiado con el backbuffer, por lo que contendrá el frame2), por tanto en la pantalla hay dibujado medio frame1, pero comienza a dibujar el frame2... desde el pixel en que se quedó, y no desde el principio.
Por eso, lo que acabará dibujándose en pantalla (y por tanto veremos) es una pantalla compuesta de parte del frame1 y parte del 2, por lo que veremos como un "corte".
Lógicamente esto ocurre terriblemente rápido, pero aún así lo suficiente para que lo veamos.
Cuando decimos que hay que activar el vSync lo que hacemos es sincronizar el cambio del backbuffer al framebuffer con el vsync: como en ese momento no se dibuja nada, el cambio no se notará. Sin embargo eso también provoca que cuando la tarjeta dibuja un frame ha de esperar al siguiente vsync sin dibujar nada. Si la tarjeta puede generar más frames por segundo que el refresco de la pantalla (60 por lo general) no pasa nada, porque eso significa que la tarjeta tiene tiempo de sobra de generar un frame mientras se está pintando el anterior.

Sin embargo si la tarjeta no puede generar los suficientes frames por segundo como para igualar el refresco y activamos el vsync, podría pasar esto:
supongamos que mientras un frame se dibuja ocurren 2.5 vsyncs (a 60 hz de refresco de pantalla, 60/2.5 = 24 FPS genera la tarjeta)
Eso significa que entre que se genera un frame y se MUESTRA pueden pasar 2.5 vsyncs, que a 60Hz de refresco de pantalla, 1000msecs/60 = 16 msecs por vsync * 2.5vsyncs = 41.6ms por cada 2.5 vsyncs. Es decir, entre que se genera un frame y se muestra podríamos tener un LAG de 41.6ms que aunque es un lag por el que muchos mataríamos por conseguir online, es un lag que empieza a ser preocupante para algo mostrado en pantalla y que se supone es en "tiempo real", y además este no es constante, podrías esperar 2.5 vsyncs, 2, 1.5, dependiendo de lo que tarde la tarjeta en dibujar el frame y lo que quede hasta el siguiente vsync
Por tanto la solución es desactivar el vSync. Eliminas el lag aunque provocando el tearing.

Por ejemplo, los halos que están capados a 30FPS, es porque la tarjeta genera +30FPS pero menos de 60. Lo que hacen es limitar los frames dibujados a 30 cada segundo, lo que produce un lag pequeño y además estable. Es una solución intermedia entre eliminar el tearing y el lag provocado.

He encontrado esto... a ver si alguien se anima a pasar lo interesante al wiki.

http://ortihuela.galeon.com/glosario.htm

Hacía mucho que no había tenido tiempo para comentar en mi propio hilo ... ^^

wabo escribió:He encontrado esto... a ver si alguien se anima a pasar lo interesante al wiki.

http://ortihuela.galeon.com/glosario.htm

Con algo de tiempo podría, hay muchos términos que no tienen nada que ver, pero claro, se trata de buscar las definiciones que vienen al caso...