soledad penadés

repeat 4[fd 100 rt 90]

Qué lío, todo el día tratando de pintar cuatro objetos cargados de un ASE, y me salen normales poco normales. O algo. A estas horas ya no me acuerdo de si MAX intercambiaba las coordenadas Y y Z, o si era mi imaginación la que lo hacía.
Creo que también he olvidado activar algo en el código de inicialización de openGL; parece como si no hiciera el test de profundidad o algo así (el depth test), y los objetos aparecen raros, como mínimo. Pero si activo el depthTest, empiezo a obtener una serie de parpadeos de lo más marciano, supongo que por la precisión del Z-buffer. Mira que lo puse a 24 bits, creo, pero no sé. Como no sea la función de Depth, que en vez de GL_LESS sea otra… pero mirando en la documentación dice que a) el gldepth está desactivado por defecto b) la función de glDepth por defecto es GL_LESS. En fin, que tengo un cacao mental impresionante.

Sale raro, ¿eh? Help!
Luego he tratado de acordarme de cómo se hacía la inversa de una matriz y me ha costado, bastante bastante. ¡¡Con la de inversas de matrices que he hecho en mi vida!! (Por no hablar de integrales y derivadas, mi pasatiempo en bup xD), y ya ves, pasas un año sin hacer algebra 3D y se te olvida todo. Por poner un ejemplo de lo que se me había olvidado, estaba tratando de recalcular las normales a un triángulo usando sólo dos puntos del triángulo. Así: N = v1 x v2.
¡Lo cual está claramente más que mal! La normal al triángulo es un vector perpendicular al mismo, y para eso necesitas dos vectores que determinen el plano en el que está el triángulo. Al rato me he acordado de que esos vectores se pueden hallar… con los tres puntos del triángulo… V1 = P3-P1 y V2 = P2-P1, o así. Luego le haces el producto vectorial y lo normalizas, y ya lo tienes listo para openGl. Eh, pero me ha costado un horror hacer eso.
Ha sido como tener que aplicarme una autohipnosis mental: te acuerdas de todo, te acuerdas de todo, lo tienes superfresco en la memoria, Gauss Jordan es tu amigo, ¡vivan los adjuntos de las matrices! ¡Determinante for president!
Yo no sé a quién se le ocurrió lo del realismo 3D. ¡Con lo bien que se vive con el sombreado flat! Boh!
¡Nunca seré élite!

I think I am really near to achieve my current goal: parse an impulse tracker file and then use it to generate some useful info for my demos. That info will be stored in an xml file and I'll use that in my loved d.e.m.o., which stands for Discrete Effort to Merely Outstand, i.e. my personal interpretation of a demoengine.

I never liked the idea of calling it a demosystem or a demoengine. It has not almost any feature that you can find in true demosoftware, only simple things to experiment with the art of realtime programming. I prefer to be humble and accept/proclaim that this will never evolve into a tremendous piece of software that I don't ever know how to understand. No. I prefer to keep it simple (once again the magic rule ;)) in a way I still can play with it without turning fool.

At this moment I am trying to play the data I read from the module (the impulse tracker file). I am not referring to produce sounds with it. My aim is not making an audio player. Instead I want to grab the exact time where the events (the notes) are and the use that information for syncronizing, rather than manually enter those data - which is so ANNOYING and boring, specially if you want to syncronize lots of drums which do not follow a classical 4×4 structure.

Once I get this I'll continue porting my old (and quite basic) effects to the new system, mainly because the only effect I have currently is the famous FXFlash (although I have renamed it into EffectFlash to have more self-explaining file names, and for other reasons too but I won't tell them now), and I don't want to produce any epileptic attack by releasing a demo consisting only in flashes (but VERY SYNCRONIZED XD). The part of creating instances of the effects, scenes and playing all of them at the same time is working and ready. I'll give more details about this project in next chapters. Now I must go coding a bit ;)

it's the beginning of a new year, all of us want to be good people… so I'll start finishing my unfinished projects. For example our euskal12 demo code colors. I have fixed some bugs and also improved the quality and detail on the scenes and some textures. Take a look at the images; you can click over them to get a bigger size version, but you could also download the latest version of the demo. You'll need an opengl accelerator and so on, read the included file_id.diz for more details…

I'm starting to believe strongly in my unlucky fate when it comes to programming. It does not matter which language it is, I always find the most unexpected bugs. For example, one of my favourite one was the stream closed exception that appeared during the loading of a .jar file which included certain crypt class, using a certain version of a jdk. It stopped the loading of the .jar file because an unhandled exception was thrown and then the unpackager couldn't finish read the contents of the file because the stream was clased. Quite interesting!
Anyway this time the search for the solution is being much more hard. We are in front of an opengl strange behaviour when it comes for executing my demo blue tuesday/xplsv in geforce cards. When I execute it on my computer (with an ATI radeon9000 mobility) everything goes fine. But hey! when executing it on the geforce cards, I get depressed. A sweet and pretty spiral that falls slowly, behind the credit titles, does simply get hidden by a PLANE! I don't understand why, because there are more scenes in the demo which feature "something behind a plane", and the plane does not overlap and hide everything - as it does in this case.

I will explain the working of this scenes: First everything is cleaned (the color and the depth buffers).
So then I draw the planes with the credits.
Copy it to a texture.
Delete the screen again (color and depth buffers - I was not doing the cleaning of the depth buffer in this case but somehow I thought and some people told me that it could be a cause for the problem, anyway, it has not effect in my computer and on geforce class cards either).
Now draw the spiral. I do PushMatrix and blablabla. Is not a problem of matrix transformations - just because in that case I shouldn't be able to see nothing in my computer.
Next step is redrawing the previous texture, but somehow distorted, by mapping it to a GL_QUADS grid and applying the appropiate texture coordinates to each one of them. (The factors for determining the level of distortion, should be explained in another blog entry I think; they don't matter too much in this case). For drawing the QUADS I set an Ortho view which sets up a frustrum with some Z coordinates range. And then ALL of the QUADS are drawn in such manner that their Z value falls inside this Z range. Ok, so they are inside the frustrum. Everything shows on Ati and Geforce - no problems (I had had problems some months ago with planes that did not get shown when having some Z values on geforce cards only).
But The Problem is that somehow, I don't have a clue why, it seems like, even with the BLEND = true, the quads hide everything behind them - on geforce, of course. So the spiral simply does not show.
The alpha values set when I do the glClear are 0 - so when it reads the buffer for copying to the texture, it should be reading alpha values of 0 when there's nothing drawn. So those zones should be transparent and show whatever is behind them. But it does not work.
I have done some other tests, like making the alpha test pass just when there's a 0.5 level of alpha… It does not work on geforce too. It seems like the drivers are ignoring me. I don't know what to do about it. I would like to, and then I would be able to finish the demo and upload a final version somewhere. Any clue? Send it to supersole aaaaaaaaat gmail.com (by the way, does somebody need invitations? I still have many…)

Well, I have found the mysterious bug that we always have when we code something. The mesh subdivision algorithm is recursive, as you could imagine viewing the images. In each pass, it divides each face in three ones. So we have the old face and two new ones, and then we assign the appropiate vertexes to each face. In the next iteration we have to subdivide too the faces we had created previously, but I had forgotten to change the maximumFaces index, so it didn't divide properly. As you can see in the next images, I have fixed it!! :-)

Mesh subdivision with 2 passes

Mesh subdivision with 3 passes

Mesh subdivision with 5 passes

Next step is playing with the vertexes! ;)