El grupo al cual envías entradas es un grupo Usenet. Si envías mensajes a este grupo, cualquier usuario de Internet podrá ver tu dirección de correo electrónico
Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se han cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los push/popMatrix y push/popAttrib, TODO el fixed-function vertex processing (glTranslate, glRotate,glScale...), glLight, glLightModel, glMaterial ... se han cargado hasta el modo de GL_QUADS y GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
El asunto es que han deprecado cosas como gl_FragData o gl_FragColor, y te dicen que utilices user-defined variables para conseguir el mismo efecto... pero no entiendo cómo demonios funciona el asunto de asignar una output variable a un rendertarget. He estado rebuscando en el spec y no encuentro nada
¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
Sobre lo de la fixed, ya habian avisado, y me alegro, sinceramente. Si miras
en la lista, hay una discusión larga del asunto, creo que mejor evitar
repetirla,
aunque ten en cuenta que los QUADs hace mucho que deberian haber
desaparecido, que ninguna GPU soporta ya quads de forma nativa (y no sé
si alguna lo soportó en algun momento).
Adeu,
shash
El 25 de marzo de 2009 15:45, Jon Valdés <juan...@gmail.com> escribió:
> Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se han
> cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
> push/popMatrix y push/popAttrib, TODO el fixed-function vertex
> processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
> glMaterial ... se han cargado hasta el modo de GL_QUADS y
> GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
> Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
> El asunto es que han deprecado cosas como gl_FragData o gl_FragColor, y
> te dicen que utilices user-defined variables para conseguir el mismo
> efecto... pero no entiendo cómo demonios funciona el asunto de asignar
> una output variable a un rendertarget. He estado rebuscando en el spec y
> no encuentro nada
> ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
Le he hechado un vistazo y la cosa está bastante guay :)
Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos avisados (en
3.0 estavan deprecated, igual q el alpha test). Ahroa todo va por shaders,
pero bueno, en mi opinión mejor así, es todo más sencillito
Lo q mola tres pueblos son los UBO, q viene a ser algo así como una manera
eficiente de setear uniforms ale, a cascoporro (sólo he leído el resumen de
la spec) y luego el ogl con la extensión de compatibility o algo así (lo
digo de memoria) que viene a ser "si tu implementación tiene esta extensión
implementas tb el ogl antiguo).
Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la vida...
creo q esta vez se lo han currado bastante (las cosas que ponen tienen
bastante sentido) y ya están con que dentro de poco sacan la 3.2... (a ver
si se ponen las pilas de nuevo y tenemos una api limpita)
> Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se han
> cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
> push/popMatrix y push/popAttrib, TODO el fixed-function vertex
> processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
> glMaterial ... se han cargado hasta el modo de GL_QUADS y
> GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
> Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
> El asunto es que han deprecado cosas como gl_FragData o gl_FragColor, y
> te dicen que utilices user-defined variables para conseguir el mismo
> efecto... pero no entiendo cómo demonios funciona el asunto de asignar
> una output variable a un rendertarget. He estado rebuscando en el spec y
> no encuentro nada
> ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
me parece perfecto!!! la mejor manera de poner nuevos estándares es
cargándose lo viejo (de hecho, nunca he entendido mucho el concepto de
"deprecated", par mi, o está o no está.... :D).
El 25 de marzo de 2009 16:38, Até <ignot...@gmail.com> escribió:
> Le he hechado un vistazo y la cosa está bastante guay :)
> Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos avisados (en
> 3.0 estavan deprecated, igual q el alpha test). Ahroa todo va por shaders,
> pero bueno, en mi opinión mejor así, es todo más sencillito
> Lo q mola tres pueblos son los UBO, q viene a ser algo así como una manera
> eficiente de setear uniforms ale, a cascoporro (sólo he leído el resumen de
> la spec) y luego el ogl con la extensión de compatibility o algo así (lo
> digo de memoria) que viene a ser "si tu implementación tiene esta extensión
> implementas tb el ogl antiguo).
> Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la vida...
> creo q esta vez se lo han currado bastante (las cosas que ponen tienen
> bastante sentido) y ya están con que dentro de poco sacan la 3.2... (a ver
> si se ponen las pilas de nuevo y tenemos una api limpita)
>> Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se han
>> cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
>> push/popMatrix y push/popAttrib, TODO el fixed-function vertex
>> processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
>> glMaterial ... se han cargado hasta el modo de GL_QUADS y
>> GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
>> Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
>> El asunto es que han deprecado cosas como gl_FragData o gl_FragColor, y
>> te dicen que utilices user-defined variables para conseguir el mismo
>> efecto... pero no entiendo cómo demonios funciona el asunto de asignar
>> una output variable a un rendertarget. He estado rebuscando en el spec y
>> no encuentro nada
>> ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
Lo que estoy pensando ahora es si algunos de estos cambios no van a hacer más difícil la adopción de OpenGL por principiantes.
Es decir, en los cursillos de introducción a OpenGL, en todos los tutoriales, etc, se da siempre glBegin, glTranslate, glRotate, glScale, glPushMatrix, glColor, glLight... Es decir, todo lo que se ha eliminado en OpenGL 3.1
Ahora, para mostrar algo por pantalla habrá que montar un vertex buffer, llamar a drawarrays, y tener el vertex shader con su modelviewprojectionmatrix como un uniform (también la han deprecado al parecer), mas el fragment shader. Y no se vosotros, pero yo he estado 5 años programando tranquilamente en OpenGL sin tener ni guarra de matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y a trabajar directamente con ellas.
Vamos, que si a un chaval de 16 años le dices que para mostrar 4 polígonos en pantalla se tiene que currar una matriz de 4x4 y transformarla para cambiar la posición, rotación y tamaño de las cosas... se va a largar de allí cagando leches.
Até wrote:
> Le he hechado un vistazo y la cosa está bastante guay :)
> Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos avisados > (en 3.0 estavan deprecated, igual q el alpha test). Ahroa todo va por > shaders, pero bueno, en mi opinión mejor así, es todo más sencillito
> Lo q mola tres pueblos son los UBO, q viene a ser algo así como una > manera eficiente de setear uniforms ale, a cascoporro (sólo he leído el > resumen de la spec) y luego el ogl con la extensión de compatibility o > algo así (lo digo de memoria) que viene a ser "si tu implementación > tiene esta extensión implementas tb el ogl antiguo).
> Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la > vida... creo q esta vez se lo han currado bastante (las cosas que ponen > tienen bastante sentido) y ya están con que dentro de poco sacan la > 3.2... (a ver si se ponen las pilas de nuevo y tenemos una api limpita)
> 2009/3/25 Jon Valdés <juan...@gmail.com <mailto:juan...@gmail.com>>
> Bueeenas,
> Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se han
> cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
> push/popMatrix y push/popAttrib, TODO el fixed-function vertex
> processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
> glMaterial ... se han cargado hasta el modo de GL_QUADS y
> GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
> Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
> El asunto es que han deprecado cosas como gl_FragData o gl_FragColor, y
> te dicen que utilices user-defined variables para conseguir el mismo
> efecto... pero no entiendo cómo demonios funciona el asunto de asignar
> una output variable a un rendertarget. He estado rebuscando en el spec y
> no encuentro nada
> ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
la última vez que hice algo en OpenGL fue hace como 4-5 años.. cuando
vuelva (espero hacerlo esporádicamente) voy a flipar un poquito por lo
que veo :D
> Lo que estoy pensando ahora es si algunos de estos cambios no van a
> hacer más difícil la adopción de OpenGL por principiantes.
> Es decir, en los cursillos de introducción a OpenGL, en todos los
> tutoriales, etc, se da siempre glBegin, glTranslate, glRotate, glScale,
> glPushMatrix, glColor, glLight... Es decir, todo lo que se ha eliminado
> en OpenGL 3.1
> Ahora, para mostrar algo por pantalla habrá que montar un vertex buffer,
> llamar a drawarrays, y tener el vertex shader con su
> modelviewprojectionmatrix como un uniform (también la han deprecado al
> parecer), mas el fragment shader. Y no se vosotros, pero yo he estado 5
> años programando tranquilamente en OpenGL sin tener ni guarra de
> matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y
> a trabajar directamente con ellas.
> Vamos, que si a un chaval de 16 años le dices que para mostrar 4
> polígonos en pantalla se tiene que currar una matriz de 4x4 y
> transformarla para cambiar la posición, rotación y tamaño de las
> cosas... se va a largar de allí cagando leches.
> ¿O no?
> Un saludoo
> Até wrote:
>> Le he hechado un vistazo y la cosa está bastante guay :)
>> Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos avisados
>> (en 3.0 estavan deprecated, igual q el alpha test). Ahroa todo va por
>> shaders, pero bueno, en mi opinión mejor así, es todo más sencillito
>> Lo q mola tres pueblos son los UBO, q viene a ser algo así como una
>> manera eficiente de setear uniforms ale, a cascoporro (sólo he leído el
>> resumen de la spec) y luego el ogl con la extensión de compatibility o
>> algo así (lo digo de memoria) que viene a ser "si tu implementación
>> tiene esta extensión implementas tb el ogl antiguo).
>> Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la
>> vida... creo q esta vez se lo han currado bastante (las cosas que ponen
>> tienen bastante sentido) y ya están con que dentro de poco sacan la
>> 3.2... (a ver si se ponen las pilas de nuevo y tenemos una api limpita)
>> 2009/3/25 Jon Valdés <juan...@gmail.com <mailto:juan...@gmail.com>>
>> Bueeenas,
>> Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se han
>> cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
>> push/popMatrix y push/popAttrib, TODO el fixed-function vertex
>> processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
>> glMaterial ... se han cargado hasta el modo de GL_QUADS y
>> GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
>> Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
>> El asunto es que han deprecado cosas como gl_FragData o gl_FragColor, y
>> te dicen que utilices user-defined variables para conseguir el mismo
>> efecto... pero no entiendo cómo demonios funciona el asunto de asignar
>> una output variable a un rendertarget. He estado rebuscando en el spec y
>> no encuentro nada
>> ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
> Lo que estoy pensando ahora es si algunos de estos cambios no van a
> hacer más difícil la adopción de OpenGL por principiantes.
> Es decir, en los cursillos de introducción a OpenGL, en todos los
> tutoriales, etc, se da siempre glBegin, glTranslate, glRotate, glScale,
> glPushMatrix, glColor, glLight... Es decir, todo lo que se ha eliminado
> en OpenGL 3.1
> Ahora, para mostrar algo por pantalla habrá que montar un vertex buffer,
> llamar a drawarrays, y tener el vertex shader con su
> modelviewprojectionmatrix como un uniform (también la han deprecado al
> parecer), mas el fragment shader. Y no se vosotros, pero yo he estado 5
> años programando tranquilamente en OpenGL sin tener ni guarra de
> matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y
> a trabajar directamente con ellas.
> Vamos, que si a un chaval de 16 años le dices que para mostrar 4
> polígonos en pantalla se tiene que currar una matriz de 4x4 y
> transformarla para cambiar la posición, rotación y tamaño de las
> cosas... se va a largar de allí cagando leches.
> ¿O no?
> Un saludoo
> Até wrote:
> > Le he hechado un vistazo y la cosa está bastante guay :)
> > Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos avisados
> > (en 3.0 estavan deprecated, igual q el alpha test). Ahroa todo va por
> > shaders, pero bueno, en mi opinión mejor así, es todo más sencillito
> > Lo q mola tres pueblos son los UBO, q viene a ser algo así como una
> > manera eficiente de setear uniforms ale, a cascoporro (sólo he leído el
> > resumen de la spec) y luego el ogl con la extensión de compatibility o
> > algo así (lo digo de memoria) que viene a ser "si tu implementación
> > tiene esta extensión implementas tb el ogl antiguo).
> > Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la
> > vida... creo q esta vez se lo han currado bastante (las cosas que ponen
> > tienen bastante sentido) y ya están con que dentro de poco sacan la
> > 3.2... (a ver si se ponen las pilas de nuevo y tenemos una api limpita)
> > 2009/3/25 Jon Valdés <juan...@gmail.com <mailto:juan...@gmail.com>>
> > Bueeenas,
> > Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se
> han
> > cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
> > push/popMatrix y push/popAttrib, TODO el fixed-function vertex
> > processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
> > glMaterial ... se han cargado hasta el modo de GL_QUADS y
> > GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
> > Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
> > El asunto es que han deprecado cosas como gl_FragData o gl_FragColor,
> y
> > te dicen que utilices user-defined variables para conseguir el mismo
> > efecto... pero no entiendo cómo demonios funciona el asunto de
> asignar
> > una output variable a un rendertarget. He estado rebuscando en el
> spec y
> > no encuentro nada
> > ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
Hola Eduardo, jeje recuerdo cuando implementaba los shaders en Cg. No usaba
el acceso al estado de ogl, asi que tenía q implementarme todos los
parámetros a manija (recuerdas Shash?).
Para una spot, pues serán unos cuantos, no? La matriz de transformación, el
color, los radios de atenuación, el ángulo o angulos :) Sí, unos poquitos,
no es tan fácil como un glLight, pero oye, lo haces una vez y te olvidas :)
Y para un material, pues no sé, pero la gracia esta precisamente en eso, no?
que puedes diseñarte el material o la luz A MEDIDA.
Por lo que estoy viendo, cada vez tiran más ogl hacia un modelo de
"transferencia de datos de forma masivamente paralela con un proceso entre
medio". Esto es, que lo mismo puedes usar ogl para en roto que un descosido
(o dicho de otra manera gráficos o computación general).
Es en esta tendencia donde creo q deprecar tanta funcionalidad redundante
tiene sentido. Seguramente los glLight o los glMaterial acababan
convirtiéndose en pseudo-uniforms q se rellenaban por defecto y que se
podían acceder mediante el acceso al estado peeeeeeero esto amigos parece
que se acabó :)
Se simplifica todo en pro de unos drivers más sencillos, más velocidad y una
API no ya para aprender sino para usar en el Mundo Real (tm) con, supongo,
rendimientos acorde con lo que se espera. Evidentemente se pierde semántica,
y posiblemente, un comienzo más fácil con la librería, pero bueno, aqui
somos todos unos tíos cojonudos y nos podemos hacer nuestras librerías para
q poner una luz, o setear un material o incluso especificar los arrays de
vertex, texcoords o normales se pueda hacer de forma sencilla, verdad?
>> Lo que estoy pensando ahora es si algunos de estos cambios no van a
>> hacer más difícil la adopción de OpenGL por principiantes.
>> Es decir, en los cursillos de introducción a OpenGL, en todos los
>> tutoriales, etc, se da siempre glBegin, glTranslate, glRotate, glScale,
>> glPushMatrix, glColor, glLight... Es decir, todo lo que se ha eliminado
>> en OpenGL 3.1
>> Ahora, para mostrar algo por pantalla habrá que montar un vertex buffer,
>> llamar a drawarrays, y tener el vertex shader con su
>> modelviewprojectionmatrix como un uniform (también la han deprecado al
>> parecer), mas el fragment shader. Y no se vosotros, pero yo he estado 5
>> años programando tranquilamente en OpenGL sin tener ni guarra de
>> matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y
>> a trabajar directamente con ellas.
>> Vamos, que si a un chaval de 16 años le dices que para mostrar 4
>> polígonos en pantalla se tiene que currar una matriz de 4x4 y
>> transformarla para cambiar la posición, rotación y tamaño de las
>> cosas... se va a largar de allí cagando leches.
>> ¿O no?
>> Un saludoo
>> Até wrote:
>> > Le he hechado un vistazo y la cosa está bastante guay :)
>> > Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos avisados
>> > (en 3.0 estavan deprecated, igual q el alpha test). Ahroa todo va por
>> > shaders, pero bueno, en mi opinión mejor así, es todo más sencillito
>> > Lo q mola tres pueblos son los UBO, q viene a ser algo así como una
>> > manera eficiente de setear uniforms ale, a cascoporro (sólo he leído el
>> > resumen de la spec) y luego el ogl con la extensión de compatibility o
>> > algo así (lo digo de memoria) que viene a ser "si tu implementación
>> > tiene esta extensión implementas tb el ogl antiguo).
>> > Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la
>> > vida... creo q esta vez se lo han currado bastante (las cosas que ponen
>> > tienen bastante sentido) y ya están con que dentro de poco sacan la
>> > 3.2... (a ver si se ponen las pilas de nuevo y tenemos una api limpita)
>> > 2009/3/25 Jon Valdés <juan...@gmail.com <mailto:juan...@gmail.com>>
>> > Bueeenas,
>> > Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se
>> han
>> > cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
>> > push/popMatrix y push/popAttrib, TODO el fixed-function vertex
>> > processing (glTranslate, glRotate,glScale...), glLight,
>> glLightModel,
>> > glMaterial ... se han cargado hasta el modo de GL_QUADS y
>> > GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
>> > Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
>> > El asunto es que han deprecado cosas como gl_FragData o
>> gl_FragColor, y
>> > te dicen que utilices user-defined variables para conseguir el mismo
>> > efecto... pero no entiendo cómo demonios funciona el asunto de
>> asignar
>> > una output variable a un rendertarget. He estado rebuscando en el
>> spec y
>> > no encuentro nada
>> > ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
> Y no se vosotros, pero yo he estado 5
> años programando tranquilamente en OpenGL sin tener ni guarra de
> matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y
> a trabajar directamente con ellas.
Y ¿como te las has arreglado para no lidiar con ellas? :P
Vamos, que si a un chaval de 16 años le dices que para mostrar 4
> polígonos en pantalla se tiene que currar una matriz de 4x4 y
> transformarla para cambiar la posición, rotación y tamaño de las
> cosas... se va a largar de allí cagando leches.
El problema que veo con esto, es que el chaval no esta aprendiendo los
conocimientos fundamentales. Precisamente, lo chulo de mostrar 4 poligonos
en pantalla es que es algo sencillo de enseñar que ademas te permite enseñar
algo tan basico en 3d como son las transformaciones. Aunque tambien es
cierto que a un chaval de 16 años tampoco le vas a marear mucho con
matrices. En fin, basicamente se reduce a que no me gustan mucho los
tutoriales/how-tos, porque nos hacen ir a por la solucion mas facil, y no
nos permiten desarrollar esa herramienta interna nuestra que nos hace
sacarnos las castañas del fuego nosotros mismos...
> Lo que estoy pensando ahora es si algunos de estos cambios no van a
> hacer más difícil la adopción de OpenGL por principiantes.
> Es decir, en los cursillos de introducción a OpenGL, en todos los
> tutoriales, etc, se da siempre glBegin, glTranslate, glRotate, glScale,
> glPushMatrix, glColor, glLight... Es decir, todo lo que se ha eliminado
> en OpenGL 3.1
> Ahora, para mostrar algo por pantalla habrá que montar un vertex buffer,
> llamar a drawarrays, y tener el vertex shader con su
> modelviewprojectionmatrix como un uniform (también la han deprecado al
> parecer), mas el fragment shader. Y no se vosotros, pero yo he estado 5
> años programando tranquilamente en OpenGL sin tener ni guarra de
> matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y
> a trabajar directamente con ellas.
> Vamos, que si a un chaval de 16 años le dices que para mostrar 4
> polígonos en pantalla se tiene que currar una matriz de 4x4 y
> transformarla para cambiar la posición, rotación y tamaño de las
> cosas... se va a largar de allí cagando leches.
> ¿O no?
> Un saludoo
> Até wrote:
> > Le he hechado un vistazo y la cosa está bastante guay :)
> > Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos avisados
> > (en 3.0 estavan deprecated, igual q el alpha test). Ahroa todo va por
> > shaders, pero bueno, en mi opinión mejor así, es todo más sencillito
> > Lo q mola tres pueblos son los UBO, q viene a ser algo así como una
> > manera eficiente de setear uniforms ale, a cascoporro (sólo he leído el
> > resumen de la spec) y luego el ogl con la extensión de compatibility o
> > algo así (lo digo de memoria) que viene a ser "si tu implementación
> > tiene esta extensión implementas tb el ogl antiguo).
> > Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la
> > vida... creo q esta vez se lo han currado bastante (las cosas que ponen
> > tienen bastante sentido) y ya están con que dentro de poco sacan la
> > 3.2... (a ver si se ponen las pilas de nuevo y tenemos una api limpita)
> > 2009/3/25 Jon Valdés <juan...@gmail.com <mailto:juan...@gmail.com>>
> > Bueeenas,
> > Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se
> han
> > cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
> > push/popMatrix y push/popAttrib, TODO el fixed-function vertex
> > processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
> > glMaterial ... se han cargado hasta el modo de GL_QUADS y
> > GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
> > Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
> > El asunto es que han deprecado cosas como gl_FragData o gl_FragColor,
> y
> > te dicen que utilices user-defined variables para conseguir el mismo
> > efecto... pero no entiendo cómo demonios funciona el asunto de
> asignar
> > una output variable a un rendertarget. He estado rebuscando en el
> spec y
> > no encuentro nada
> > ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
Sí Sí... todos los que usamos OpenGL estamos de acuerdo en eso
(deprecated mola), pero nos estamos dejando una cuestión que comenta
Jon que es de sumo interés:
- a) la especificación del nuevo GLSL es caótica, y deja entrever
que se "deprecan" los gl_FragData y gl_FragColor (esto no lo he mirado
bien, me he centrado en leer la especificación 3.1 por el momento).
- b) Alguno sabe algo de los varying output de los fragment
shaders? a qué tipo de buffer Object se bindean ?
Yo estoy ahí intentando desgranarlo, como siempre las especificaciones
cuesta entenderlas por partes, hay que entenderlas todo-a-la-vez.
La impresión que me da es que los fragment shaders tienen ahora
"varying outputs", que se fijan/consultan con los [Get/ Bind]FragDataLocation(...) ... después con DrawBuffers(n, *bufs)
eliges sobre qué color-attachment se escribe la salida de los fragment
colors (supongo que si no usas DrawBuffers el 0 va al attachment0, el
1 al attachment1, etc...)
Si tiras a más de uno es porque tienes un FBO con varios
RenderBuffersObjects o bien con Texturas (directamente), enganchadas a
los color_attachments ( para este caso ), otras opciones del FBO son
el stencil, y depth.
> me parece perfecto!!! la mejor manera de poner nuevos estándares es
> cargándose lo viejo (de hecho, nunca he entendido mucho el concepto
> de "deprecated", par mi, o está o no está.... :D).
> El 25 de marzo de 2009 16:38, Até <ignot...@gmail.com> escribió:
> Le he hechado un vistazo y la cosa está bastante guay :)
> Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos
> avisados (en 3.0 estavan deprecated, igual q el alpha test). Ahroa
> todo va por shaders, pero bueno, en mi opinión mejor así, es todo
> más sencillito
> Lo q mola tres pueblos son los UBO, q viene a ser algo así como una
> manera eficiente de setear uniforms ale, a cascoporro (sólo he leído
> el resumen de la spec) y luego el ogl con la extensión de
> compatibility o algo así (lo digo de memoria) que viene a ser "si tu
> implementación tiene esta extensión implementas tb el ogl antiguo).
> Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la
> vida... creo q esta vez se lo han currado bastante (las cosas que
> ponen tienen bastante sentido) y ya están con que dentro de poco
> sacan la 3.2... (a ver si se ponen las pilas de nuevo y tenemos una
> api limpita)
> Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto curioso: se
> han
> cargado todos los glBegin/glEnd, glVertex, glColor, glTexCoord, los
> push/popMatrix y push/popAttrib, TODO el fixed-function vertex
> processing (glTranslate, glRotate,glScale...), glLight, glLightModel,
> glMaterial ... se han cargado hasta el modo de GL_QUADS y
> GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
> Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
> El asunto es que han deprecado cosas como gl_FragData o
> gl_FragColor, y
> te dicen que utilices user-defined variables para conseguir el mismo
> efecto... pero no entiendo cómo demonios funciona el asunto de asignar
> una output variable a un rendertarget. He estado rebuscando en el
> spec y
> no encuentro nada
> ¿Alguien le ha echado un vistazo y tiene idea de cómo va el asunto?
> Y no se vosotros, pero yo he estado 5 >> años programando tranquilamente en OpenGL sin tener ni guarra de >> matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y >> a trabajar directamente con ellas.
> Y ¿como te las has arreglado para no lidiar con ellas? :P
> Ostias, no habia leído eso de los 5 años sin tocar matrices... no me quiero
imaginar la ristra de translates / rotates / scales...
Ruben Penalva wrote: > Y no se vosotros, pero yo he estado 5 > años programando tranquilamente en OpenGL sin tener ni guarra de > matrices, y sólo hace unos meses que me he puesto a leer sobre el tema y > a trabajar directamente con ellas.
> Y ¿como te las has arreglado para no lidiar con ellas? :P
Pues no haciendo demasiadas cosas animadas, y siempre haciendo cosas en plan amateur xD
El día que ves que la integridad de un proyecto real depende de que de verdad entiendas lo que estás haciendo... es cuando te compras un libro de álgebra y lo lees y relees hasta que ves la luz (además de hacer lo propio con un par de libros de OpenGL y 4 de C++) xDD
> Vamos, que si a un chaval de 16 años le dices que para mostrar 4 > polígonos en pantalla se tiene que currar una matriz de 4x4 y > transformarla para cambiar la posición, rotación y tamaño de las > cosas... se va a largar de allí cagando leches.
> El problema que veo con esto, es que el chaval no esta aprendiendo los > conocimientos fundamentales. Precisamente, lo chulo de mostrar 4 > poligonos en pantalla es que es algo sencillo de enseñar que ademas te > permite enseñar algo tan basico en 3d como son las transformaciones. > Aunque tambien es cierto que a un chaval de 16 años tampoco le vas a > marear mucho con matrices. En fin, basicamente se reduce a que no me > gustan mucho los tutoriales/how-tos, porque nos hacen ir a por la > solucion mas facil, y no nos permiten desarrollar esa herramienta > interna nuestra que nos hace sacarnos las castañas del fuego nosotros > mismos...
Yo lo que pasa es que soy partidario de la filosofía de "primero hay que atraerlos con algo interesante, y luego si les interesa ya profundizarán", que es mas o menos como me metí yo en esto.
Mi preocupación por todo este tema viene básicamente de que llevo un par de veranos impartiendo un cursillo de OpenGL, y aunque este año ya tenía previsto desechar los glBegin y evitar en lo posible la parte fixed-function... no me esperaba que quitaran tantas cosas! Y si en un curso de 4 días tengo además que explicar teoría de matrices... la llevo clara :(
Voy a tener que replantearme bastantes cosas de ese cursillo xDDDD
> Sí Sí... todos los que usamos OpenGL estamos de acuerdo en eso > (deprecated mola), pero nos estamos dejando una cuestión que comenta > Jon que es de sumo interés:
> - a) la especificación del nuevo GLSL es caótica, y deja entrever > que se "deprecan" los gl_FragData y gl_FragColor (esto no lo he mirado > bien, me he centrado en leer la especificación 3.1 por el momento).
> - b) Alguno sabe algo de los varying output de los fragment > shaders? a qué tipo de buffer Object se bindean ?
> Yo estoy ahí intentando desgranarlo, como siempre las especificaciones > cuesta entenderlas por partes, hay que entenderlas todo-a-la-vez.
> La impresión que me da es que los fragment shaders tienen ahora > "varying outputs", que se fijan/consultan con los [Get/ > Bind]FragDataLocation(...) ... después con DrawBuffers(n, *bufs) > eliges sobre qué color-attachment se escribe la salida de los fragment > colors (supongo que si no usas DrawBuffers el 0 va al attachment0, el > 1 al attachment1, etc...)
Vaya, no había visto esta parte del spec de OpenGL. Creo que es justo lo que no entendía. Gracias por la info ;)
> me parece perfecto!!! la mejor manera de poner nuevos estándares es > cargándose lo viejo (de hecho, nunca he entendido mucho el concepto de > "deprecated", par mi, o está o no está.... :D).
Hombre, cuando tu aplicación tiene que sobrevivir al paso de los años, mejor que no anden jodiendo mucho con los API, cuanto más estable sea, mejor. El tema de deprecated te ayuda a migrar progresivamente, en plan "mira, que vamos a quitar esto, vete cambiando tu código", sin que deje de funcionar de golpe. Cuando programas como amateur, en tu casa, da lo mismo, te pegas el palizón y lo cambias, pero cuando trabajas en una empresa y el cambio cuesta n-mil euros, pues la cosa cambia un poco...
De hecho es una de las ventajas principales de OpenGL frente a otras alternativas (lease Direct3D): que una aplicación programada en 1992 (hace casi 20 años) todavía se puede compilar hoy en día contra las especificaciones recientes (si acaso con algún cambio menor, pero nunca una reescritura). Es estupendo que el API evolucione, pero no se debe perder de vista las aplicaciones que ya existen y deben seguir funcionando sin exigir un coste desmedido a los desarrolladores.
Por eso a mi me parece estupendo que coexistan OpenGL y Direct3D, porque cada uno ofrece un modelo de versiones totalmente diferente. Direct3D cambia más rápidamente sus API, sus requisitos, sus funcionalidades, ofreciendo siempre la última tecnología. Eso está genial para desarrolladores de videojuegos, tecnológicamente exigentes, y cuyas aplicaciones tienen una vida útil de unos pocos años, y para investigadores, que necesitan estar siempre en la cresta de la ola y tienen recursos para mantenerse ahí aunque haya que reescribirlo todo cada X tiempo (o actualizarte a Windows Vista).
Pero por otra parte, para aplicaciones estilo XSI, Maya, Blender, simuladores, CAD, etc. que tienen una longevidad mucho mayor, es más práctico tirar de OpenGL, que te garantiza que no te va a costar mucho o nada que siga compilando todo dentro de dos años.
Ojalá Direct3D funcionase también en Linux / Mac, para poder elegir en cada situación el API que más convenga.
> El 25 de marzo de 2009 16:38, Até <ignot...@gmail.com > <mailto:ignot...@gmail.com>> escribió:
> Le he hechado un vistazo y la cosa está bastante guay :)
> Veamos, lo de cargarse todo lo de glBegin y glEnd ya estabamos
> avisados (en 3.0 estavan deprecated, igual q el alpha test). Ahroa
> todo va por shaders, pero bueno, en mi opinión mejor así, es todo
> más sencillito
> Lo q mola tres pueblos son los UBO, q viene a ser algo así como
> una manera eficiente de setear uniforms ale, a cascoporro (sólo he
> leído el resumen de la spec) y luego el ogl con la extensión de
> compatibility o algo así (lo digo de memoria) que viene a ser "si
> tu implementación tiene esta extensión implementas tb el ogl antiguo).
> Para haberlo sacado 8 meses después que 3.0 q fue el fiasco de la
> vida... creo q esta vez se lo han currado bastante (las cosas que
> ponen tienen bastante sentido) y ya están con que dentro de poco
> sacan la 3.2... (a ver si se ponen las pilas de nuevo y tenemos
> una api limpita)
> 2009/3/25 Jon Valdés <juan...@gmail.com <mailto:juan...@gmail.com>>
> Bueeenas,
> Acabo de ver que han sacado OpenGL 3.1 [1] y es un tanto
> curioso: se han
> cargado todos los glBegin/glEnd, glVertex, glColor,
> glTexCoord, los
> push/popMatrix y push/popAttrib, TODO el fixed-function vertex
> processing (glTranslate, glRotate,glScale...), glLight,
> glLightModel,
> glMaterial ... se han cargado hasta el modo de GL_QUADS y
> GL_QUAD_STRIP!!! Y bueno, unas cuantas cosas más.
> Y también han sacado GLSL 1.4, que tiene una cosa que me escama.
> El asunto es que han deprecado cosas como gl_FragData o
> gl_FragColor, y
> te dicen que utilices user-defined variables para conseguir el
> mismo
> efecto... pero no entiendo cómo demonios funciona el asunto de
> asignar
> una output variable a un rendertarget. He estado rebuscando en
> el spec y
> no encuentro nada
> ¿Alguien le ha echado un vistazo y tiene idea de cómo va el
> asunto?
A mí sí que me han llevado la escalera y dejado colgado de la brocha. En álgebra sí que estoy frito, ni matrices, ni vectores ni nada. Menos mal que vengo trasteando Ogre desde hace un año, la verdad que ahora OpenGL no será tan fácil de aprender como era antes.
Una cosa es el glBegin que tiene un claro sustituto y otra la pila de
matrices. En su día tuvo su razón de ser y no sé qué es lo que ha cambiado
para que deje de tenerla.
Tampoco veo por qué no se puede hacer un grafo de escena basado en la
gestión de transformaciones de opengl. La necesidad de gestionar las
transformaciones aparece cuando quieres aplicar colisiones, culling,
impostores o picking... Features que no son imprescindibles en una
aplicación basada en opengl, como puede ser un sistema de visualización, un
paseo virtual por un museo, un generador de caracteres, una presentación o
el propio interfaz del iphone. Hablo de aplicaciones que tienen una salida
comercial tan válida como la de cualquier videojuego.
Yo veo perfectamente factible estar 5 años con OpenGL sin gestionar tú mismo
las transformaciones. De hecho, opengl esta(ba) pensado para eso ¿no? Yo
estuve 2 años haciendo interfaces en opengl y todo era popMatrix y
pushMatrix para cambiar entre contenedores. Igual no hay campos que explorar
en gráficos, sin tener que atender a las transformaciones de vertices.
El concepto de matriz de transformación se puede entender perfectamente sin
saber cómo se multiplican dos matrices. No creo que, conceptualmente, aporte
nada. ¿Cuántos de los que mantienen sus propias transformaciones sabrían
deducir la gl_NormalMatrix? Seguro que aprenderán mucho más que yo a los
16, cuando perdía semanas, dibujando circulitos para calcular las ecuaciones
de transformación, porque no sabía lo que era una matriz.
Siempre he pensado que los gráficos se aprenden mejor de fuera a dentro.
Até, las luces y materiales a medida están muy bien. Pero creo que GLSL está
un poco limitado en ese sentido, ya que no permite includes y te obliga a
hacer un preproceso del shader antes de subirlo. En un motor generalista, es
un problema proporcionar una biblioteca de shaders al usuario. Tienen que
soportar todas las luces, algunos parámetros de materiales, los planos de
clipping posibles, si la textura es 1D, 2D o 3D, etc... Si encima quieres
abrir los tipos de luces y materiales tienes que generar el codigo del
shader al vuelo... Ni siquiera sé cómo lo hace blender.
> Ruben Penalva wrote:
> > Y no se vosotros, pero yo he estado 5
> > años programando tranquilamente en OpenGL sin tener ni guarra de
> > matrices, y sólo hace unos meses que me he puesto a leer sobre el
> tema y
> > a trabajar directamente con ellas.
> > Y ¿como te las has arreglado para no lidiar con ellas? :P
> Pues no haciendo demasiadas cosas animadas, y siempre haciendo cosas en
> plan amateur xD
> El día que ves que la integridad de un proyecto real depende de que de
> verdad entiendas lo que estás haciendo... es cuando te compras un libro
> de álgebra y lo lees y relees hasta que ves la luz (además de hacer lo
> propio con un par de libros de OpenGL y 4 de C++) xDD
> > Vamos, que si a un chaval de 16 años le dices que para mostrar 4
> > polígonos en pantalla se tiene que currar una matriz de 4x4 y
> > transformarla para cambiar la posición, rotación y tamaño de las
> > cosas... se va a largar de allí cagando leches.
> > El problema que veo con esto, es que el chaval no esta aprendiendo los
> > conocimientos fundamentales. Precisamente, lo chulo de mostrar 4
> > poligonos en pantalla es que es algo sencillo de enseñar que ademas te
> > permite enseñar algo tan basico en 3d como son las transformaciones.
> > Aunque tambien es cierto que a un chaval de 16 años tampoco le vas a
> > marear mucho con matrices. En fin, basicamente se reduce a que no me
> > gustan mucho los tutoriales/how-tos, porque nos hacen ir a por la
> > solucion mas facil, y no nos permiten desarrollar esa herramienta
> > interna nuestra que nos hace sacarnos las castañas del fuego nosotros
> > mismos...
> Yo lo que pasa es que soy partidario de la filosofía de "primero hay que
> atraerlos con algo interesante, y luego si les interesa ya
> profundizarán", que es mas o menos como me metí yo en esto.
> Mi preocupación por todo este tema viene básicamente de que llevo un par
> de veranos impartiendo un cursillo de OpenGL, y aunque este año ya tenía
> previsto desechar los glBegin y evitar en lo posible la parte
> fixed-function... no me esperaba que quitaran tantas cosas! Y si en un
> curso de 4 días tengo además que explicar teoría de matrices... la llevo
> clara :(
> Voy a tener que replantearme bastantes cosas de ese cursillo xDDDD
El problema de los includes es de sobra conocido. Por eso se han
desarrollado tecnicas como el ubershader, o alternativas como deferred
shading y otros. El problema no es de
GLSL, sino un problema inherente a la programación de shaders. Ademas,
cualquier motor decente tiene un preinclusor de shaders, se hace en dos
patadas, asi que no tener
includes no es un motivo serio para no usarlo.
Como con glBegin y otros, si lo que quereis es no tener que tocar cosas
complejas, usad un wrapper. Se hace en direct3D, y se puede hacer en openGL.
Al limitar toda la funcionalidad
que da openGL (y por dios, que se carguen la mutabilidad de los objetos YA),
los vendors tendrán menos problemas para implementar drivers, y juro que
firmaria ahora mismo por una
API menos compleja pero con drivers más decentes, cosa que a dia de hoy no
tenemos. Cualquier programador de 3 al 4 que haya programado unos años en
openGL te dirá lo mismo:
hasta el mismo Carmack se quejaba de ello, por dios.
> Una cosa es el glBegin que tiene un claro sustituto y otra la pila de
> matrices. En su día tuvo su razón de ser y no sé qué es lo que ha cambiado
> para que deje de tenerla.
> Tampoco veo por qué no se puede hacer un grafo de escena basado en la
> gestión de transformaciones de opengl. La necesidad de gestionar las
> transformaciones aparece cuando quieres aplicar colisiones, culling,
> impostores o picking... Features que no son imprescindibles en una
> aplicación basada en opengl, como puede ser un sistema de visualización, un
> paseo virtual por un museo, un generador de caracteres, una presentación o
> el propio interfaz del iphone. Hablo de aplicaciones que tienen una salida
> comercial tan válida como la de cualquier videojuego.
> Yo veo perfectamente factible estar 5 años con OpenGL sin gestionar tú
> mismo las transformaciones. De hecho, opengl esta(ba) pensado para eso ¿no?
> Yo estuve 2 años haciendo interfaces en opengl y todo era popMatrix y
> pushMatrix para cambiar entre contenedores. Igual no hay campos que explorar
> en gráficos, sin tener que atender a las transformaciones de vertices.
> El concepto de matriz de transformación se puede entender perfectamente sin
> saber cómo se multiplican dos matrices. No creo que, conceptualmente, aporte
> nada. ¿Cuántos de los que mantienen sus propias transformaciones sabrían
> deducir la gl_NormalMatrix? Seguro que aprenderán mucho más que yo a los
> 16, cuando perdía semanas, dibujando circulitos para calcular las ecuaciones
> de transformación, porque no sabía lo que era una matriz.
> Siempre he pensado que los gráficos se aprenden mejor de fuera a dentro.
> Até, las luces y materiales a medida están muy bien. Pero creo que GLSL
> está un poco limitado en ese sentido, ya que no permite includes y te obliga
> a hacer un preproceso del shader antes de subirlo. En un motor generalista,
> es un problema proporcionar una biblioteca de shaders al usuario. Tienen que
> soportar todas las luces, algunos parámetros de materiales, los planos de
> clipping posibles, si la textura es 1D, 2D o 3D, etc... Si encima quieres
> abrir los tipos de luces y materiales tienes que generar el codigo del
> shader al vuelo... Ni siquiera sé cómo lo hace blender.
>> Ruben Penalva wrote:
>> > Y no se vosotros, pero yo he estado 5
>> > años programando tranquilamente en OpenGL sin tener ni guarra de
>> > matrices, y sólo hace unos meses que me he puesto a leer sobre el
>> tema y
>> > a trabajar directamente con ellas.
>> > Y ¿como te las has arreglado para no lidiar con ellas? :P
>> Pues no haciendo demasiadas cosas animadas, y siempre haciendo cosas en
>> plan amateur xD
>> El día que ves que la integridad de un proyecto real depende de que de
>> verdad entiendas lo que estás haciendo... es cuando te compras un libro
>> de álgebra y lo lees y relees hasta que ves la luz (además de hacer lo
>> propio con un par de libros de OpenGL y 4 de C++) xDD
>> > Vamos, que si a un chaval de 16 años le dices que para mostrar 4
>> > polígonos en pantalla se tiene que currar una matriz de 4x4 y
>> > transformarla para cambiar la posición, rotación y tamaño de las
>> > cosas... se va a largar de allí cagando leches.
>> > El problema que veo con esto, es que el chaval no esta aprendiendo los
>> > conocimientos fundamentales. Precisamente, lo chulo de mostrar 4
>> > poligonos en pantalla es que es algo sencillo de enseñar que ademas te
>> > permite enseñar algo tan basico en 3d como son las transformaciones.
>> > Aunque tambien es cierto que a un chaval de 16 años tampoco le vas a
>> > marear mucho con matrices. En fin, basicamente se reduce a que no me
>> > gustan mucho los tutoriales/how-tos, porque nos hacen ir a por la
>> > solucion mas facil, y no nos permiten desarrollar esa herramienta
>> > interna nuestra que nos hace sacarnos las castañas del fuego nosotros
>> > mismos...
>> Yo lo que pasa es que soy partidario de la filosofía de "primero hay que
>> atraerlos con algo interesante, y luego si les interesa ya
>> profundizarán", que es mas o menos como me metí yo en esto.
>> Mi preocupación por todo este tema viene básicamente de que llevo un par
>> de veranos impartiendo un cursillo de OpenGL, y aunque este año ya tenía
>> previsto desechar los glBegin y evitar en lo posible la parte
>> fixed-function... no me esperaba que quitaran tantas cosas! Y si en un
>> curso de 4 días tengo además que explicar teoría de matrices... la llevo
>> clara :(
>> Voy a tener que replantearme bastantes cosas de ese cursillo xDDDD
Al principio, quería decir el problema de soportar diferentes
materiales/luces/tipos de textura en un shader, los includes solo son una
herramienta posible para solucionarlo (aunque al final es mas importante un
preprocesador decente).
shash
El 26 de marzo de 2009 9:41, shash <shash....@gmail.com> escribió:
> El problema de los includes es de sobra conocido. Por eso se han
> desarrollado tecnicas como el ubershader, o alternativas como deferred
> shading y otros. El problema no es de
> GLSL, sino un problema inherente a la programación de shaders. Ademas,
> cualquier motor decente tiene un preinclusor de shaders, se hace en dos
> patadas, asi que no tener
> includes no es un motivo serio para no usarlo.
> Como con glBegin y otros, si lo que quereis es no tener que tocar cosas
> complejas, usad un wrapper. Se hace en direct3D, y se puede hacer en openGL.
> Al limitar toda la funcionalidad
> que da openGL (y por dios, que se carguen la mutabilidad de los objetos
> YA), los vendors tendrán menos problemas para implementar drivers, y juro
> que firmaria ahora mismo por una
> API menos compleja pero con drivers más decentes, cosa que a dia de hoy no
> tenemos. Cualquier programador de 3 al 4 que haya programado unos años en
> openGL te dirá lo mismo:
> hasta el mismo Carmack se quejaba de ello, por dios.
> Una cosa es el glBegin que tiene un claro sustituto y otra la pila de
>> matrices. En su día tuvo su razón de ser y no sé qué es lo que ha cambiado
>> para que deje de tenerla.
>> Tampoco veo por qué no se puede hacer un grafo de escena basado en la
>> gestión de transformaciones de opengl. La necesidad de gestionar las
>> transformaciones aparece cuando quieres aplicar colisiones, culling,
>> impostores o picking... Features que no son imprescindibles en una
>> aplicación basada en opengl, como puede ser un sistema de visualización, un
>> paseo virtual por un museo, un generador de caracteres, una presentación o
>> el propio interfaz del iphone. Hablo de aplicaciones que tienen una salida
>> comercial tan válida como la de cualquier videojuego.
>> Yo veo perfectamente factible estar 5 años con OpenGL sin gestionar tú
>> mismo las transformaciones. De hecho, opengl esta(ba) pensado para eso ¿no?
>> Yo estuve 2 años haciendo interfaces en opengl y todo era popMatrix y
>> pushMatrix para cambiar entre contenedores. Igual no hay campos que explorar
>> en gráficos, sin tener que atender a las transformaciones de vertices.
>> El concepto de matriz de transformación se puede entender perfectamente
>> sin saber cómo se multiplican dos matrices. No creo que, conceptualmente,
>> aporte nada. ¿Cuántos de los que mantienen sus propias transformaciones
>> sabrían deducir la gl_NormalMatrix? Seguro que aprenderán mucho más que yo
>> a los 16, cuando perdía semanas, dibujando circulitos para calcular las
>> ecuaciones de transformación, porque no sabía lo que era una matriz.
>> Siempre he pensado que los gráficos se aprenden mejor de fuera a dentro.
>> Até, las luces y materiales a medida están muy bien. Pero creo que GLSL
>> está un poco limitado en ese sentido, ya que no permite includes y te obliga
>> a hacer un preproceso del shader antes de subirlo. En un motor generalista,
>> es un problema proporcionar una biblioteca de shaders al usuario. Tienen que
>> soportar todas las luces, algunos parámetros de materiales, los planos de
>> clipping posibles, si la textura es 1D, 2D o 3D, etc... Si encima quieres
>> abrir los tipos de luces y materiales tienes que generar el codigo del
>> shader al vuelo... Ni siquiera sé cómo lo hace blender.
>>> Ruben Penalva wrote:
>>> > Y no se vosotros, pero yo he estado 5
>>> > años programando tranquilamente en OpenGL sin tener ni guarra de
>>> > matrices, y sólo hace unos meses que me he puesto a leer sobre el
>>> tema y
>>> > a trabajar directamente con ellas.
>>> > Y ¿como te las has arreglado para no lidiar con ellas? :P
>>> Pues no haciendo demasiadas cosas animadas, y siempre haciendo cosas en
>>> plan amateur xD
>>> El día que ves que la integridad de un proyecto real depende de que de
>>> verdad entiendas lo que estás haciendo... es cuando te compras un libro
>>> de álgebra y lo lees y relees hasta que ves la luz (además de hacer lo
>>> propio con un par de libros de OpenGL y 4 de C++) xDD
>>> > Vamos, que si a un chaval de 16 años le dices que para mostrar 4
>>> > polígonos en pantalla se tiene que currar una matriz de 4x4 y
>>> > transformarla para cambiar la posición, rotación y tamaño de las
>>> > cosas... se va a largar de allí cagando leches.
>>> > El problema que veo con esto, es que el chaval no esta aprendiendo los
>>> > conocimientos fundamentales. Precisamente, lo chulo de mostrar 4
>>> > poligonos en pantalla es que es algo sencillo de enseñar que ademas te
>>> > permite enseñar algo tan basico en 3d como son las transformaciones.
>>> > Aunque tambien es cierto que a un chaval de 16 años tampoco le vas a
>>> > marear mucho con matrices. En fin, basicamente se reduce a que no me
>>> > gustan mucho los tutoriales/how-tos, porque nos hacen ir a por la
>>> > solucion mas facil, y no nos permiten desarrollar esa herramienta
>>> > interna nuestra que nos hace sacarnos las castañas del fuego nosotros
>>> > mismos...
>>> Yo lo que pasa es que soy partidario de la filosofía de "primero hay que
>>> atraerlos con algo interesante, y luego si les interesa ya
>>> profundizarán", que es mas o menos como me metí yo en esto.
>>> Mi preocupación por todo este tema viene básicamente de que llevo un par
>>> de veranos impartiendo un cursillo de OpenGL, y aunque este año ya tenía
>>> previsto desechar los glBegin y evitar en lo posible la parte
>>> fixed-function... no me esperaba que quitaran tantas cosas! Y si en un
>>> curso de 4 días tengo además que explicar teoría de matrices... la llevo
>>> clara :(
>>> Voy a tener que replantearme bastantes cosas de ese cursillo xDDDD
|
