Emotion, el coste hoy día del GL_NORMALIZE es practicamente gratuito, no hay penalización.

Ithaqua.

http://ithaqua.stravaganza.org                                

                                Resumiendo, que un giro de 90º/-90º causa la pérdida de un grado de libertad usando ángulos Euler.

Ethernet, lo que se quiere decir con 'calcular las rotaciones usando quaternions' es que el motor procesa todas las transformaciones (incluidas las rotaciones como tu dices) para finalmente generar una única matriz de transformación por cada objeto/camara/luz de la escena.
Esa matriz de transformación indica la posición/orientación de la entidad en el mundo y es precisamente la que le indicas a OpenGL/Direct3D para que con ella procese todo el conjunto de datos locales.
El coste de calcular la matriz es ínfimo comparado con el coste de transformar con ella todos los vértices de una malla por ejemplo.
El primer proceso lo realiza tu motor (CPU), el segundo si eres espabilado se lo dejas a la tarjeta :ojo:


           Ithaqua.

http://ithaqua.stravaganza.org                                

                                Saludos,

Mchiz, es totalmente imposible calcular valores especulares si no hay una luz y un respectivo material por medio.
Lo único que tienes que hacer es, como ha dicho Grey, darle un valor de color (reflexion) especular al material (1.0, 1.0, 1.0, 1.0 por ejemplo).
Además esta el valor GL_SHININESS, que es para indicar el grado de enfoque de los hilights. A mayor valor, mas enfocado y pequeño, a menor valor mas grande y desenfocado.

Dos cosas a tener en cuenta:
-La fórmula de Drácula no es del todo cierta, ya que en OpenGL por defecto no se post-suma el especular (solo lo hace si se usa convenientemente la extensión de separate specular color).
-Si no usas normales unitarias, verás bastantes defectos de iluminación. Lo mas recomendable es usar siempre glEnable(GL_NORMALIZE).

Saludos,

          Ithaqua.

http://ithaqua.stravaganza.org

                               

                                Como seguro que estamos perezosos:

BASS:
http://www.un4seen.com/music/music_bass.html

FMOD:
http://www.fmod.org/
                               

                                Es para uso comercial?
Si no lo es, podrías plantearte utilizar alguna librería como FMOD o BASS.                                

                                No puedes usar el specular para generar transparencias. ¿Por que no usas un canal alpha para el sprite? Sería lo mas lógico.

Saludos, Ithaqua.

http://ithaqua.stravaganza.org

                               

                                Mas que tutorial, buscaría códigos fuente de ejemplo. La ayuda del maxscript es muy buena (si ya conoces el MAXSDK y la jerarquía de clases de MAX). Lo único ahora es aprender la sintaxis, que es muy sencilla, y saber como acceder a determinados elementos de la escena.

Suerte :sonriendo:


          Ithaqua.


http://ithaqua.stravaganza.org

                               

                                Hola Berserker,

Una posible solución sería hacerte una tool en maxscript. Maxscript es increiblemente potente y la curva de aprendizaje muy muy buena.
Yo era muy reticente a echarle una ojeada al maxscript porque mas que nada me sonaba a que iba a tener que dedicarle mucho tiempo para aprender a hacer la simple tontería.
Nada de eso :sonriendo:

Por proponer algo, podrías hacer algo que asignara un valor de sector a la selección actual (y que dependiendo de este valor de sector, se altere su color). Lo mismo con los portales, asignar la propiedad de portal a la selección, dejando elegir qué sectores comunica.
Esa información la podrías ir guardando en tiempo real en las user defined properties de los nodos (Ej, "Sector=5", "Portal. Sectors=(4,5)" ).
Para el grafista es muy fácil trabajar solo dándole a botoncitos y viendo como cambia el color de los objetos con sus órdenes.
Y ya te digo, que la tool esta la puedes hacer en 2 horas contando que no sepas nada de nada de maxscript.

Como me consta que al final vais a hacer un exportador de MAX, lo unico que debeis hacer a la hora de exportar es exportar tambien la cadena de user defined properties (INode::GetUserPropBuffer(char*)).

Lo de los user defined properties lo podeis utilizar tambien para mas cosas. Yo por ejemplo meto ahi los lensflares (helpers con esa propiedad) y emisores de particulas (un helper sobre una antorcha por poner un simple ejemplo).


Un saludo,

      Ithaqua.

http://ithaqua.stravaganza.org



                               

                                Drácula, sí se puede hacer. Échale un vistazo a estas librerías:
http://graphics.stanford.edu/projects/shading/
Lo único que haces es 'registrar' las luces y ya.

En todo caso, aunque no se pudiese abstraer, el añadir o quitar código de iluminación es bastante trivial. Incluso podrías currarte una tool simple para automatizar el proceso de adaptación de código.


         Saludos,

              Ithaqua.


http://ithaqua.stravaganza.org                                

                                Emotion: Sobre lo de los .h de extensiones, lee mi anterior mensaje :sonriendo:
Sobre lo de Carmack, yo soy de los que opinan que es exageradamente sobrevalorado. De hecho la gente suele contestar enseguida "J. Carmack" cuando les preguntas acerca de su programador favorito. Pero es que solo conocen a ese y a un par mas :ojo:
Por otra parte la tecnología (ojo, solo tecnología) del Unreal siempre me ha parecido mucho mas interesante que la del Quake.
Ah, y otra cosa. Carmack ha innovado en alguna cosilla más de las que tu listas. Por poner un simple ejemplo: El Carmack's reverse en el cálculo de sombras dinámicas usando shadow volumes.
Aun asi, por mucho que digas que se basa en papers del Siggraph, siempre es de los que estan en la cresta de la ola en cuando a tecnologia se refiere. Definitivamente Carmack no es un cualquiera como tu dices, pero si que es desmesurado el grado de fanatismo que genera.

Dracula: Lo de las luces de los vertex shaders se puede abstraer para generalizarlo, y sino échale un vistazo al trabajo que hicieron unos de la universidad de stanford (google: opengl shading language creo).
Una cosa es que en principio no se pueda realizar (= funcionalidad básica) y otra que con un poco de curro no se pueda conseguir :sonriendo:

Nada mas. Un saludo,


           Ithaqua.

http://ithaqua.stravaganza.org

                                         

                                No estoy muy de acuerdo en eso de los gráficos, justo en esta etapa :sonriendo:

Y lo de los vertex shaders ya te lo leí una vez. Sigo sin pillarlo :-? Limitar de que modo? si aparte del fixed pipeline te dan la posibilidad de programar tu mismo el pipe. Y esta flexibilidad/potencia irá aumentando cada vez mas. En que sentido te limita?

Happy coding,

        Ithaqua.


http://ithaqua.stravaganza.org                                

                                Totalmente de acuerdo :sonriendo:

Saludos,

         Ithaqua


http://ithaqua.stravaganza.org                                

                                Por cierto, sobre el tema de las extensiones OpenGL, y el lío que es inicializarlas y luego utilizarlas...
Yo ahora mismo utilizo el sistema de extensiones que viene con el NVidia OpenGL SDK, y ciertamente es un ahorro de curro increible. Olvidaros de wglGetProcAddress, de definir a mano constantes, de funcionar con punteros...etc
Vaya, que es como si tuvieras el header de OpenGL 1.3 y pudieras utilizar todo ese API mas las extensiones como funciones, solo que chequeas primero si existen (d3dcaps?).
Hace un par de días apareció una noticia en Stratos con algo parecido, no lo probé pero tenía buena pinta ya que soportaba también extensiones de ATI.

Es cierto que el tema de las extensiones está fragmentando OpenGL bastante, pero vamos, no es ningún suplicio usarlas. Quejicas :sonriendo:

Sobre el tema de vertex array range, etc.
Con OpenGL no hay nada mejor que las display lists, y siempre seguirá siendo lo mejor ya que es decirle al driver "toma esta geometría y guárdala de tal forma que la proceses lo mas rápido posible". Cada driver optimizará ese proceso según el hardware, y siempre de la forma mas rápida.
¿Que no vale para geometría dinámica? no, es cierto que no vale, pero la proporción geometría estática/dinámica en una escena es abismal. Aparte de que glDrawElements ya de por sí es rápido, y la extensión de compiled vertex arrays la soportan todas las tarjetas ahora.
Y en el caso de que aún no estés contento, te curras 2 o 3 implementaciones distintas de geometría dinámica con las extensiones mayoritarias y listo. Y si es un lío es porque no tienes bien estructurado el código, pero eso no es problema de OpenGL :ojo:

Joer, vaya charla... lo dejo aquí :sonriendo:

Saludos,

        Ithaqua

http://ithaqua.stravaganza.org
                               

                                Tranqui Lessman, para cuando OpenGL 2.0 se estandarice tu ya habrás pasado una larga temporadita programando la 1.3 :sonriendo:


     Saludos,

          Ithaqua.

http://ithaqua.stravaganza.org