Un pequeño lugar donde compartir, aprender y divertirse.

No soy muy dado a este tipo de entradas, pero mientros concluyo con el último capítulo de Encriptación y Autentificación me he animado a decir algunas palabras sobre lo que está por llegar por parte de Firefox.

Firefox abrió la guerra de los navegadores hace unos años. Nadie apostaba por él, pero en cambio demostró no solo ser mucho más seguro que la competencia (IE, Opera y Safari básicamente), sino que también mucho más rapido. Por otro lado, la sustitución de los peligrosos ActiveX por complementos o temas hizo que Firefox ganase adeptos cada día que pasaba.

Tanto Opera como Safari viendo lo que pasaba creyeron que podían seguir los pasos de Firefox e intentar robar cacho a IE, cosa que tan solo Firefox estaba logrando arrancar a base de bocados. Microsoft por su parte no le dió más importancia hasta que Firfox se había convertido realmente en una opción más que viable y con un mercado bastante amplio, lo que hizo a MS sacar su IE 7 y posteriormente IE8, francamente una chapuza cada uno de ellos.

Explotó de nuevo la guerra, Opera y Safari querían tajada y Google quiso unirse a la fiesta con Chrome. Superar a Firefox en cuanto prestaciones y versatilidad resulta imposible a día de hoy, por lo que tanto unos como otros se han centrado los últimos meses simplemente en optimizar código, mejorar el engine JavaScript para mejorar los tiempos de renderizado de webs y cosillas similares. Esto se ha logrado hasta tal punto que a día de hoy sin duda alguna el navegador más rapido renderizando una web es sin duda alguna y con diferencia Chrome, seguido de Safari y Firefox más o menos en igualdad de condiciones, por detrás a corta distancia Opera y en último lugar y muy alejado IE.

Aquí hay que ser realista y tener mucho cuidado con los test que se realizan y quien los haces, así como conocer un poco cada navegador. De no hacerlo, los test no valen absolutamente para nada, y entra el fanatismo y la publicidad gratuita. Esto tampoco significa que cada navegador vaya orientado a un grupo diferente de usuarios, exceptuando quizás IE y Safari, que se quedan descolgados del resto por falta de “utilidad”.

Como hemos dicho, Chrome de Google es con diferencia el navegador más rápido a la hora de renderizar una web, pero en contrapartida también es con mucha diferencia el navegador más simple y menos cargado de todos. Optimizar un código de un millón de líneas es más complejo y difícil que optimizar un código de 100. Esto no hace a Chrome ni mejor ni peor, simplemente es un navegador ligero, actualmente no demasiado versátil si lo comparamos con Firefox, pero es que su planteamiento es muy diferente que el que hizo crear por ejemplo Firefox. Tiene una tasa de mercado entorno al 6%

Tanto Safari como Google usan el mismo motor de renderizado, WebKit, el cual hace que los dos compartan el mismo alma por así decirlo. Esto no quiere decir que sean iguales ni mucho menos, pero por ejemplo comparten prácticamente los mismos estándares y muchas funciones. Safari no es un navegador ya de por sí con muchas funcionalidades y se ha demostrado que es bastante “inseguro” en comparación con la competencia. Esto hace que no tenga un mercado claro, lo mismo que le ocurre a IE, lo que hace que sus usuarios (el 99% usuarios de MAC OS) usen en sus ordenadores (o se planteen) otros navegadores como Chrome o Firefox.Tan solo cuenta con un 4% aproximadamente de mercado, y desde hace ya tiempo va perdiendo cada día mas usuarios, aunque de muy poquito en poco. Resulta curioso que si tenemos en cuenta que tanto Windows como MAC OS usan navegadores predeterminados diferentes, y que tanto Chrome como Safari están disponibles ambos para MAC OS y Windows, es simplemente impresionante que Chrome ya haya superado en índice de mercado a Safari, sin siquiera tener OS propio (quitando Android o el OS Chrome)

Opera es un caso extraño. Opera lleva en el mercado muchos años, y siempre ha tenido un buen rendimiento, seguridad y versatilidad. En cambio por una extraña razón, aun cuando Firefox no era una opción y tan solo existía IE, Opera nunca gozó de “suerte” o siquiera de demasiada aficción. Tengo que reconocer que antes de Firefox era mi navegador por defecto y tenía ciertas cualidades que me parecían bastante interesantes, como en aquella época era el renderizado de webs para móviles por ejemplo. Opera ha mantenido más o menos siempre la misma cuota de mercado, un 2-3%. Aun después de todos los esfuerzos de Opera, tiene en estos tiempos un problema añadido: Firefox y Chrome. El primero por ser con diferencia (desde mi punto de vista) el mejor navegador en términos generales del mercado, y el segundo tiene Google detrás, por no decir que es un navegador actualmente bastante eficiente. Esto me temo que hará que Opera continúe su camino en “solitario”, y sinceramente… tienen todo mi respeto, siempre han estado ahí, y eso se agradece, no hay que olvidar que muchas de las innovaciones que hoy por hoy tenemos en los navegadores se las debemos a ellos.

IE, Internet Explorer… bueno, me temo que microsoft tiene actualmente la guerra perdida. Se mantiene a salvo simplemente por una cuestión llamada Windows, y que actualmente con las nuevas leyes de seleccionar navegador perderá aun otro trozo más de mercado. Día a día IE pierde cuota de mercado, situándose actualmente en torno al 60%. Si tenemos en cuenta que Windows lo tiene preinstalado y que Windows se usa en más de un 90% de los ordenadores, es impresionante que Firefox esté ganando terreno. No es tan impresionante si tenemos en cuenta que IE es una porquería. Quizas ya no en seguridad como siempre se critica (que también), sino por el rendimiento tan pobre que tiene, la falta de estándares que soporta y las pocas funcionalidades que nos ofrece.

En último lugar y lo que me ha hecho escribir estas líneas, Firefox. Firefox no solo comenzó siendo una posible alternativa más rápida y segura q IE, sino que pronto se convirtió en toda una plataforma eficiente para la navegación y desarrollo web. Son innumerables las extensiones ¡ÚTILES! que tenemos, y por supuesto para los amantes de la estética los temas. Firefox es simplemente rápido (aunque no el que más en términos generales), Compatible (aunque no el que más) e increíblemente versátil. Pero tiene otro AS en la manga, y es aun lo que puede dar de sí.

No voy a entrar por tanto si mejor Safari, si mejor IE o mejor Opera. De los tres más cariño a Opera, pero si tengo que ser franco, aunque en su última versión (creo que se ha liberado ya la 10.5) es muy rápida, situándose más cerca de Chrome y por encima de Safari y Firefox, no creo que marque una diferencia significativa, a fin de cuenta la velocidad no lo es todo.

Chrome se diseñó simplemente para dar agilidad a la navegación. Creado de Cero para ello, la preocupación de los desarrolladores no era crear extensiones o añadir funcionalidad, simplemente ser el más rapido. Y lo logró. Y si tu que me lees lo único que quieres o deseas de un navegador es velocidad a la hora de renderizar una web, actualmente Chrome es lo mejor que puedes tener… actualmente. Si deseas algo más, Chrome no te lo va a dar, al menos por ahora y en mucho tiempo.

Firefox… al ser un proyecto de código libre como Chrome tiene muchas ventajas. Primero que es mucho menos vulnerable a ataques externos, con lo que es mucho más seguro. Por otro lado es la propia comunidad quien crea, mejora, aporta… Actualmente el proyecto Firefox tiene una aceptación impresionante, es una plataforma poderosa y eficiente.

En cambio parece que lo que fue una virtud para él, su velocidad a la hora de renderizar páginas, ahora al estar tan de moda en laa competencia parece ser que deja a Firefox en una posición inferior, vulnerable. Ahora parece que todos los navegadores son rápidos y eficientes. Pero como hemos dicho hay mucha trampa en ello. Para comenzar, Firefox es realmente muy rápido, lo que sucede es que casi todo el mundo tiene más de un y dos complementos cargados, muchos de ellos consumen bastante memoria, lo que hace que el navegador sea en su conjunto más lento. Si desechásemos todo aquello que hace de Firefox tan versatil y útil, su rendimiento aumentaría considerablemente. A fin de cuenta no se puede tener todo en este mundo… ¿o si? Pese a ello, es evidente que Chrome está bastante por encima de Firefox y aun arrancando Firefox sin nada, Chrome es más rápido.

En cambio Firefox tiene un par de ases en la manga. El primero, el cual ya ha pasado a versión Alpha, (y que es el motivo de este artículo) se llama DirectWrite, aceleración por hardware para el navegador. El segundo, aun en fases relativamente iniciales se llama Electrolysis.

En las últimas build de Firefox, Firefox 3.7a3pre, se ha incluido ya soporte para DirectWrite, una tecnología que proviene de Directx, soportada por las tarjetas de video (mínimo Directx9, recomendado DirectX10+) y tan solo Windows 7 o Windows Vista. La idea es simple, dotar al navegador la capacidad de usar la tarjeta de video para las siguientes tareas:

• Disminuir notablemente el renderizado del texto e imágenes
• Aumentar exponencialmente el rendimiento al procesar archivos SVG o el manejo de rutinas de transformaciones de objetos
• Aumentar la calidad tanto del texto como de las imágenes visualizadas

básicamente, podemos simplificar todo ello y decir que se logra disminuir de forma notable el tiempo de procesar páginas web de cierto tamaño (este blog es una buena prueba de ello, por la cantidad de texto en cada página), el más que evidente suavizado de las fuentes (lo cual hace que la lectura en el navegador sea más comoda y “bonita”, ya este el texto escrito en horizontal, vertical, diagonal… las fuentes siempre se verán perfectamente), y por supuesto la representación de gráficos 2D, ya sean imágenes, transformaciones de estas o gráficos vectoriales SVG.

Personalmente antes de ponerme con ello pensé que era una mejora relativa, pero la verdad es que el resultado es inmediato. Simplemente la propia estética del navegador mejora con el más que notable suavizado de fuente y otros pequeños detalles. Más tarde, comencé a testearlo con pruebas más concretas, y es cuando en algún que otro ejemplo dije: “Joder…”.

Normalmente estamos acostumbrados a que nos incluyan mejoras de las cuales no solemos percatarnos. Me pueden decir que el navegador es más rápido, pero por muchos test que me enseñen yo quiero ver que esto es verdad cuando navego yo, no cuando ejecuto test especializados. Y por ahora las pruebas que tengo es que efectivamente DirectWrite en Firefox se nota. Es curioso no obstante, ver como muchos de los benchmark que existen actualmente no tienen en cuenta este tipo de factores a la hora de puntuar un navegador. Todo el mundo se está preocupando actualmente en mejorar sin límites los motores JavaScript, pero no es lo único importante. Sí, es evidente que JS es muy importante, pero no lo es todo. Muchos de los test actuales se limitan a comprobar el tiempo de ejecución de los diferentes scripts JS que tienen para comparar resultados… y eso es válido, pero solo para JS. El único benchmark relativamente fiable y completo pueda ser Peaceckeeper, y para el resultado final especifica que no tiene en cuenta el rendimiento 2D, dado que no todos siquiera lo soportan.

Vale, todo esto es mu bonit0, pero ¿donde está la pega? ¿Cuando? ¿Dónde?

Bueno, tiene inconvenientes. Por ejemplo que tan solo es posible usar esta tecnología en Windows Vista o Windows 7, es decir, por ahora entre ambos tienen un 30% quizás de mercado, dado que Windows 7 ya ha superado el 10%. Por otro lado requiere de una tarjeta de video no demasiado antigua y relativamente actualizada, lo cual tampoco debe de ser un problema para todos aquellos que disponen de Vista o 7, dado que lo “normal” es que dispongan de una tarjeta de vídeo que soporta DX9+.

¿Cuando? Actualmente ya ha sido implementada en Firefox 3.7 Alpha. Por experiencia puedo decir que generalmente cuando una función pasa a implementarse a Firefox, normalmente en las fases Alpha, suelen fallar una y otra vez, y poco a poco con las diferentes Builds se van corrigiendo los problemas. En cambio DirectWrite parece ser bastante estable, lo cual agilizará el desarrollo y pulido de este. Cuando pude probar esta nueva tecnología, es cierto que las dos primeras build tenían algunos problemillas, como algún parpadeo que otro del navegador y cosillas por el estilo. Desde ayer no he observado ningún problema ni bug sobre esto, lo cual es más que positivo. Firefox 3.7 está actualmente en fase Alpha 3 desde hace relativamente pocos días. Si todo marcha bien podría ser necesario tan solo una versión Alpha más o incluso liberar ya la Beta 1. Una tres versiones Betas, otras tantas RC (Release Candidate) y dispondremos de Firefox 3.7 final. Las build no obstante las tenemos prácticamente de forma diarias, actualmente como digo, las build corresponden a lo que será dentro de poco la liberación oficial de Firefox 3.7 Alpha 3. Todo ello lo que implica es que todos aquellos que quieran verlo implementado de forma “versión final”, tendrán que esperar hasta el lanzamiento de Firefox 3.7 (o quizás sea llamado Firefox 4).

¿Donde? No obstante, no implica que cualquiera pueda comenzar a utilizar estas funciones, solo tiene que comprender el riesgo y “dificultades” que pueden presentar usar compilaciones diarias. Sí, te garantizan estar usando lo último de lo último, pero evidentemente no siempre todo funciona bien… es más, casi nunca funciona todo bien. Por ejemplo, otra característica añadida, ha estado fallando muchísimo durante al menos una o dos semanas, hasta que se ha ido arreglando poco a poco.

Firefox 3.7 no solo nos dejará este buen sabor de boca. La otra función que ya está añadida a la versión Alpha 2 ha sido el comienzo de lo que será una parte de Electrolysis. En este caso concreto, se ha separado del nucleo del propio navegador los plugins. Con plugins no me refiero a las extensiones, sino a Adobe Flash, Java… anteriormente todos ellos corrían de una forma u otra dentro del propio navegador, lo cual hacía que si por cualquier circunstancia dicho plugins fallaba, el navegador entero sufía las consecuencias. Ahora se ha separado a otro proceso. Si algún plugins falla, el navegador no se verá afectado, simplemente será necesario refrescar la web que ha dado el problema.

¿Como? Todo aquel que quiera comenzar a usar estas características tendrá que una versión Build, lo cual no es recomendable para la gran mayoría:

Firefox 3.7a3pre

Una vez instalada, se debe de habilitar dicha opción. Dado que es una opción aun en desarrollo, no se encuentra activada por defecto. Para ello es necesario acceder a la ventana de configuración avanzada de firefox, que para quien no lo sepa, se accede tecleando en la barra de direcciones lo siguiente:

about:config

Una vez realizado, veremos un listado con cantidad de configuraciones. Buscamos en nuestro caso dos entradas concretas:

a) gfx.font_rendering.directwrite.enabled -> Cambiarlo a True
b) mozilla.widget.render-mode -> Cambiarlo “6″ (sin las comillas)

con esos dos cambios, tan solo reiniciar. Si reunimos las condiciones suficientes, nos daremos cuenta inmediatamente, aunque solo sea por el suavizado de la fuente. Ni que decir tiene que Thunderbird ya incorpora estas mismas funcionalidades en sus build más actuales, y se habilita exactamente igual.

¿Algunos ejemplos sorprendentes?

PNG girando a gran velocidad
Globo -> Esta es realmente sorprende, probarla antes y después. De ir a trompicones y no poder a ir completamente fluido
Google Maps

¿Esto es todo?  No, aun no hemos hablado de Electrolysis, aunque aun tardará en ver la luz.

Aunque en ningún sitio lo dicen, tanto IE, Safari, Opera y Chrome usan las prestaciones de los ordenadores multi-nucleos o multiprocesador. Firefox no. Sí, no es broma, Firefox actualmente tan solo usa un núcleo. El proyecto Electrolysis separará en tres la carga del navegador. Por un lado las pestañas, por otro lado los plugins y por otro la interfaz. Con las últimas build, los plugins han logrado ser separados del nucleo con éxito, es tan solo el comienzo de Electrolysis. Cuando el proyecto haya concluído y todo esté integrado en Firefox, se espera que el rendimiento de Firefox se acerque prácticamente a rozar Chrome, esperando en principio una duplicación/triplicación de rendimiento a la hora de renderizar webs.

Es decir, tiene una carta que ya todos los navegadores han usado. Esto no quiere decir que no se pueda optimizar aun más el motor JS de Firefox o mejorar todo en su conjunto. Esto quiere decir que gracias a Electolysis Firefox será considerablemente más veloz y seguro. Cuando se separe el contenido web del núcleo de Firefox, cualquier pestaña que deje de funcionar no afectará al comportamiento del resto del navegador, será aun más complicado que u exploit afecte al sistema, el sistema responderá mucho mejor en cualquier tarea. Es decir, pensar en lo que se tiene actualmente, y multiplicarlo por 3.

Actualmente se encuentra en la segunda fase de desarrollo. Quitando la separación de los plugions, el resto no ha sido implementado (y no lo será) en Firefox 3.7. Depende de a la velocidad que avance el proyecto podremos verlo antes o después, esperemos que podamos disfrutarlo en este año. Tener en cuenta que no hablamos de una pequeña modificación al navegador, sino tocar en lo más profundo de este y de como está cimentado.

En un par de meses aproximadamente la versión 3.6.2 de Firefox debería de estar terminada. Con ella, la separación de los plugins, ¿soporte DirectWrite,? Actualizaciones no intrusivas, velocidad al arrancar, una GUI un tanto mejorada… no será sino hasta Firefox 4.0 cuando Electrolysis esté integrado completamente en Firefox, junto con una interfaz bastante cambiada (más similar a la de Chrome), JetPack (que será uan nueva forma de crear extensiones) y Weave (Que permitirá poder sincronizar “navegadores”, pudiendo tener en dos disposivitos diferente los mismos favoritos, contraseñas, historiales… todo de ello de forma completamente segura).

Firefox no está muerto, le queda mucho rodaje. Es una de las aplicaciones que tengo que decir más sigo porque sinceramente lo merece. El trabajo realizado sobre él es increible, y mejora cada día. Estoy deseando que la versión 3.6.2/3.7 sea liberada para comenzar a probar Firefox 4.0. Aunque Chrome es una muy buena alternativa, actualmente prefiero Firefox. El tiempo que me ahorra gracias a sus extensiones y a la gran personalización que me da, hace que sea perfecto a mis necesidades. Por supuesto el rendimiento es importante, y es bueno ver que están en ello. No pasará mucho tiempo en que podamos ver a Firefox compitiendo con Chrome por el navegador más veloz también. Y sin olvidar por supuesto que Chrome no es ni la mitad de la mitad de lo que es hoy en día Firefox.

Un saludo a los lectores y a toda la comunidad de Mozilla por su increible trabajo. Da gusto comprobar una vez más que el software libre es la mejor opción. Prometo volver a escribir sobre esto cuando lo dicte el momento.Y con ello, ya puedo volver a terminar el capítulo sobre seguridad.

La noticia llega de forma inesperada para muchos… y es que parece ser que Apple en un intento muy agresivo por su parte estaría comenzando o pensando en suprimir aquellos IDs de dispositivos que están JailBreak. Es decir, que si Apple detecta de modo alguno que tu iPhone o iPod Touch ha sido JB podría añadir este a una lista negra e impedir todo acceso al AppStore, siendo claro el resultado de esto, imposibilidad de poder comprar por iTunes canciones o aplicaciones para tu dispositivo.

Apple se ha visto presionado por las compañías móviles y por sus propias ganancias. Su objetivo es evitar por todos los medios que el iphone o el ipod touch pueda ser un sistema abierto que ellos, Apple, no pueda controlar. Al margen de si es legal o no sus actuaciones, recordemos que el JB no es un procedimiento ilegal a día de hoy, y posiblemente no lo sea nunca. Luego si no es un proceso ilegal, es posible que Apple legalmente no tenga ninguna autoridad para denegar un servicio a un cliente por un acto legítimo, que en todo caso tan solo rompe las condiciones de la garantía.

Al margen de ello, lo que está claro es que Apple está intentando por todos los medios proteger su gallina de los huevos de oro que cada día que pasa pone menos y menos huevos. El índice de adiciones de aplicaciones en el Store de Apple disminuye considerablemente, el iPad (aun cuando hay que esperar) presagia un varapalo para Apple, El Nexus One comienza a asentarse y demostrar que no solo es un hardware muy superior sino que por un lado o otro otro el iphone irá cayendo poco a poco en el recuerdo. Ante todo esto Apple lo tiene claro, moverse rápido e intentar exprimir lo que queda.

De nuevo vemos una política de empresa completamente restrictiva y que cercena la libertad de los clientes. A fin de cuenta lo único que pretende Apple es el control de sus clientes. Cuando compras un iPhone 3GS no tienes BT, el video es malo, los mms son malos, no tienes acceso al sistema, ni siquiera puedes copiar un archivo. En contraste cualquier dispositivo similar actual permite no solo hacer todo ello, sino que algunos como el Nexus One te permite si lo deseas modificar a voluntad el sistema, sin pérdida de garantía, sin crispaciones, sin tonterías.

A fin de cuenta, todo se ve reflejado en números, y los números dicen que Google aumentó sus beneficios en más de un 50% en el año 2009 frente al 2010.  Es una pena que muchas empresas no comprendan que el cliente es al final quien paga tus facturas, y que por mucho que intentes engañarlos, al final responden.

Es por noticias como estas por las que uno se para a preguntar por qué cometio el error de comprarse un iPod Touch (en mi caso particular) o un iPhone, o cualquier producto de Apple. Ya no es una cuestión siquiera de dinero (Que son los productos más caros), ya no es una cuestión siquera de que sea lo mejor o peor (que no es lo mejor)… se convierte simplemente ya en una cuestión de principios.

Hace unos años cuando adquirí mi iPod Touch estaba contento con la compra, tan solo hay que remitirse a mis post más antiguos. Foros, blogs, investigaciones propias, aprendizaje… comprendía en parte las tonterías de Apple o eso creía. Excusas que se da a uno mismo para no tener que aceptar la inversión de un buen capital en algo que no lo vale. Después de un año, de dos… la perspectiva es muy diferente. Te cansas de las noticias inverosímiles, de los fallos de software y de hardware, de las carencias… pero ya no de las que puedas encontrar tu mismo!! sino en las preguntas de siempre de otros usuarios: no hay modo disco? no puedo enviar un archivo por bt? no puedo….? Y por otro lado veo el mercado que ha expandido para ofrecer productos no solo más baratos sino muy superiores!! y aun así tienes que oír a representantes de Apple escuchar frases como: “Muchas de las veces que se queda colgado un MAC es por culpa de Flash” . “La salida de Windows 7 implicará para nosotros un gran incremento en ventas”, “La garantía queda anulada porque su MAC ha estado expuesto a un ambiente tóxico, ambiente de fumadores”… y tantos otros.

Personalmente me pregunto sinceramente en que momento Apple vendió su alma en post de engañar a algunos cuantos. ¿Hoy? Simplemente otro granito más, A bloquear IDs que tengan dispositivos JB. Que por cierto, personalmente no creo que sea una idea mu positiva, lo que lograrían sería que la comunidad usase más Cydia o la búsqueda de aplicaciones piratas, aumentando aun más la piratería.

Pero esto es así. Apple es así. De cada 100 ideas de Apple, 1 revoluciona el mercado y es una idea grandiosa. Las otras 99 ideas hacen que la opinión publica (al menos la mía y la de muchos otros) piense que se cometió el error una vez en comprar algo con una manzana.

Este blog se creó en sus orígenes precisamente por el iPhone y el iPod Touch, creo que no se puede pedir que sea más imparcial, cuando todo fue para ayudar, alentar y aconsejar positivamente. Pero hace ya tiempo que esos tiempos acabaron, y no hizo falta mucho para darme cuenta de ello.

Por mi parte? Nunca Máis Apple, Nunca Máis.

Antes de comenzar, citar posiblemente a quien me inspiró a ello, y en cierto modo me ayudó a comprender algunos conceptos y me enseñó por donde buscar, por así decirlo: Bilalt, aunque desgraciadamente no conozco su nombre real y hace ya años que “desapareció”.

Voy a ir intentando completar este “reto personal”. Entre otras cosas, siempre me sentí atriado por los gráficos 3D, aunque no quiero decir con esto los juegos, sino el diseño 3D, como crear esos mundos increibles que tanto estamos acostumbrados a ver.

Por otro lado debo de decir que no me puedo consuderar ni mucho menos un gurú en la programación. Lo suficiente quizás para ser capaz de crear el programa que sea con algo de tiempo, pero dudo mucho que este pudiese estar a la altura de un verdadero programador como los que hay, auténticos genios en su campo. Pero por el lado positivo, la informática me ha enseñado que todos los campos dentro de ella de alguna u otra forma están relacionados, lo que quiere decir es que para mi es más facil que para la gran mayoría enfrentarme a un problema concreto (claro está, informáticamente hablando), sea de programación, de diseño… hasta el punto que aunque un genio de la programación sea capaz de hacer lo mismo mucho más eficientemente y más rapido que yo (sin duda alguna), yo tengo ideas o caigo en una serie de cosas que para otro normalmente serían muy complejas o siquiera las tendría en cuenta.

Todo esto me ha ayudado a la hora de poner en marcha Adrianne. A todo esto… quien es Adrianne? Esta es Adrianne:

Con cada serie de nuevas tarjetas gráficas, nVidia ordena crear una Demo especialmente diseñada para ella, intentando poner al máximo sus prestaciones. Hace unos años, con el lanzamiento de la serie 8 de nVidia, nos deleitaba con esta Demo. Se trata de Adrianne Curry si no recuerdo mal, creo que era una PlayMate que se prestó para tal exhibición.

Evidentemente no pretendo obtener un resultado similar. Mi idea es ser capaz al menos de renderizar el cuerpo entero de ella poligonalmente con un mínimo de iluminación, y como un “imposible” dejaría abierta la posibilidad de texturizar el modelo.

En realidad el reto que me propuse pasaba simplemente por ser capaz de realizar un parser para los arcihvos nmb, que son archivos propietarios de nVidia en los que se encuentra toda la geometría de los diseños 3D de estos. Es decir, en el caso de Adrianne, el archivo “geo_model.nmb”contiene toda la información sobre el modelo 3D Adrianne. Al ser un archivo propietario, a menos que llame a la puerta de nVidia y les pida por favor la estructura interna de este, el trabajo a mano a realizar es increiblemente grande. Hay que tener en cuenta que para mis ojos, tan solo es un archivo binario de 64MB, sin aparente información usable en su interior. Luego antes de ser capaz de renderizar nada, lo que tengo q hacer es ir interpretando poco a poco cada bloque hexadecimal de tan ingente archivo. Mi proyecto principal no fue con Adrianne, sino con Dawn, una Demo más antigua. Pero a fin de cuenta la estructura de ambos es muy similar, la diferencia es que ADrianne está en 64MB, y Dawn en tan solo 13MB. Es mas, tan solo la cabeza de Adrianne es más compleja que todo el modelo de Dawn.

Antes de poder hacer nada, la primera etapa es por tanto crear un pequeño Engine gráfico, la creación de un pequeño espacio tridimensional en el que poder representar puntos, polígonos… esto no es algo complicado, sobre todo con la cantidad de información que tenemos en internet. El problema claro está es comprender los ejemplos, el código, cada instrucción… y adaptarlo todo de la mejor forma a nuestro proyecto.

En mi caso he usado OpenGL como render, y GLUT para facilitarme el jugar con las coordenadas espaciales y la perspectiva.

Una vez la plantilla principal del engine está creada, el paso siguiente es verificar si dicho archivo, “geo_model.nmb” realmente contiene la información geométrica de Adrianne, y por supuesto verificar si el engine gráfico funciona. Aquí es donde tenemos que poner a funcionar el cerebro.

Lo más simple de todo, como no tenemos idea de la estructura interna del archivo de nVidia, es intentar renderizar todo el archivo como si fuese todo él un array de puntos. Pensar en un polígono. Su esencia última es el triángulo. Un triangulo se representa por 3 vértices. En cualquier archivo de geometría, lo que más debe de abundar con diferencia son vértices. Los vertices posicionarán los polígonos (triángulos) en el espacio tridimensional, los vértices de las normales serán los que indiquen el vector normal, usado para conocer la cara poligonal que recive la luz o por ejemplo también los vertices de los vectores tangenciales. Con esto quiero decir que de dicho archivo, de ser cierto, el 90% deberían de ser coordenadas espaciales.

Un vértice en un espacio de tres dimensiones se representa por 3 coordenadas x, y z. Si es un espacio bidimensional, usado por ejemplo en el mapeo de las texturas hacen falta tan solo 2 coordenadas u, v. Pero volviendo al tema principal, mi primer parser podría consistir simplemente en leer todo el archivo e interpretarlo como he dicho como un array de vértices. Un vertice normalmente se considera un numero de tipo float (numeros en coma flotante), un tipo de representación numérica, que es usada muy comúnmente cuando se necesita una resolución muy grande o muy pequeña. Un float se representa por medio de 32bits, es decir 4 bytes. Dicho esto, la primera aproximación a realizar es interpretar todo el archivo como una hilera de bloques de 32bytes, en el que se repetirá constantemente el patrón: X, Y, Z. Es decir, los primeros 4*3bytes del archivo serían el vértice 1: la componente X la componente Y y la componente Z. Los 3 floats siguientes se interpretarían como el vértice 2 con sus tres componentes… así sucesivamente.

Renderizar esto es facil, tan solo tenemos que cargar el archivo en memoria y desde nuestro engine hacer q se se representen en pantalla los vértices contenidos en nuestro buffer o la estructura creada. En mi caso he usado una estructura de este tipo:

Typedef Struct {

float x, y,z;
}vertices;

vertices *buffer;

Es decir, creo un array buffer de tipo vértices.Una vez todo está preparado, en el mismo engine tan solo tengo que llamar a este buffer y representar todos los puntos con un bucle simple for, que recorra todo el array. Previamente se ha calculado el número de vértices que tendría el archivo. Esto es facil, si he interpretado que todo el archivo en sí es un conjunto de vértitces, tan solo tengo que conocer por medio de ifstream el tamaño del archivo. Una vez conocido el tamaño del archivo en bytes, dividirlo entre 4 bytes (1 float = 4bytes) y después dividirlo por 3 (cada vértice tiene 3 componentes). El número resultante son los vértices. Por medio de new creo un array dinámicamente.

Cuando todo ello está terminado, con un for recorro todo el array, representando en cada momento el supuesto vértice:

glVertex3f (buffer.x, buffer.y, buffer.z);

Pero para poder lograr tener más información de todo ello, hago que dependiendo del puntero de nuestro buffer (la posición de este) me represente cada punto de un color u otro. Para ello divido el numero de vértices en 4, y el resultado será la umbral de cada trozo. De esta forma si el punto representado se encuentra en el primer cuarto del archivo, se representará de color rojo, si corresponde al segundo verde. Blanco si es al tercero y azul si es al cuarto. Esto es simple con una instrucción if y glColor3f.

Por último queda pensar en algo… de funciona, hemos presupuesto que el primer vértice comienza en la posición del archivo 0, y todos los consiguientes en saltos de 4 bytes. Imaginemos por un momento que tenemos realmente un archivo tan solo con vértices, pero que el primer byte del archivo es un identificador. Quiere decir que de representarlo como digo, no tendría nada!! puesto que mi matrón se extiende por todo el archivo, y jamás tendría un solo vértice representado correctamente. Pero esto mismo sucedería no solo si los vertices comenzasen en el primer byte, sino tb con el segundo y con el tercero. Las posibilidades por tanto sería un desplazamiento de 0, 1, 2 y 3 bytes. 4 no haría falta, dado que son bloques de 4 Bytes cada float, si desplazase 4 sería igual que no desplazar. Hablo de localidad dentro del mismo archivo. Con lo que si quiero representar el archivo a pelo, tengo que hacer en realidad 4 representaciones, cada una variando el desplazamiento 1 byte.

Como si de magia se tratase, con un desplazamiento de 0, y con todo lo comentado, esto es lo que obtengo:

Si no me falla la vista, eso parece ser el bañador de Adrianne? Evidentemente no quiere decir que todo lo que vemos sea parte de la geometría, ni mucho menos. Tan solo hemos pasado a nuestro engine un buffer de 64MB interpretado todo ello como vértices y obtenemos eso. Cláramente el bañador en azul, si está en azul quire decir que el bañador se encontraría en el último cuarto del archivo.

Para un desplazamiento de 1 Byte:

Vaya… en este caso hemos acertado en la cabeza de lleno, una pierna, medio cuerpo, un brazo, el ojo izquierdo, un pendiente… La cabeza en Verde nos dice que está en el segundo cuarto.

Para un desplazamiento de 2:

Otra pierna, en azul a la derecha y girado parece que podría ser el collar y un posible ojo? Tener en cuenta que las posiciones no tiene porqué corresponderse, al menos por ahora.

Y por último para un offset de 3:

Por último tenemos otro brazo, collar, cuerpo…

Creo que la mayoría de toda la geometría queda al descubierto.

Como segundo paso se podría acotar aun más la búsqueda de cada malla (parte del cuerpo) por separado, para conocer la ubicación concreta de cada una de las partes. Una vez realizado podríamos comenzar visualizando el archivo en un editor hexadecimal y ver si podemos extraer información directamente de él, teniendo en cuenta lo qye ya tenemos.

Pero ei… de momento el engine funciona, y se ve claramente un voceto muy primitivo de Adrianne diseccionada, en forma de puntos de colores.