Hemos realizado una serie de cambios que afectan al blog en cuanto a subdominio se refiere. O lo que es lo mismo, ahora la dirección del blog hace honor al nombre del mismo: No Smoke (ahora que lo pienso, al menos debería haber una explicación de por qué el nombre de “No Smoke” en nuestro “A cerca de” … y no, aunque haya diferentes opiniones al respecto, no tiene que ver con el tabaco )

Si no os habéis dado cuenta, nuestro subdominio principal es ahora nosmoke.cycle-it.com. Ahora esperamos que No Smoke tome la entidad y el peso que le corresponde, en lugar de ser simplemente el blog de Cycle-IT. Este cambio ha tenido un par de efectos colaterales:

• Hemos perdido el conteo de retweets de Tweetmeme.
• Hemos perdido el conteo de “Me gusta” de Facebook.

Esto no quiere decir que hayamos perdido completamente estos valores, sino que al cambiar a nosmoke.cycle-it.com, estos sistemas entienden que no aplican los anteriores. Así que por esto no os preocupéis (si es que os preocupaba claro). Además, en el caso de Tweetmeme hemos aprovechado para incluir el botón Tweet, que es la versión oficial y que incluso recomiendan desde Tweetmeme.

En definitiva, No Smoke es No Smoke y podéis difundir la palabra, ayudándoos de los diferentes botones de medios sociales repartidos por el blog.

Una de las cosas que me gustaría ver es un CycleFramework libre de dependencias del SDK de Flex. Si os preguntáis el por qué de este deseo, la respuesta es sencilla: haciéndolo independiente del SDK de Flex podremos utilizarlo sin ningún problema en otros proyectos ActionScript puros, sin mencionar con que la librería quedaría bastante más ligera (no obstante si la compilamos como referencia externa este problema de peso, nos lo quitamos de encima).

Hasta ahora la mayoría de nuestros proyectos los hemos realizado en Flex, si bien ciertas partes ActionScript puras acaban teniendo su pequeño hueco en ellos, nunca hemos tenido la necesidad de utilizar un micro-framework MVC para ActionScript3. Pese a esto, tengo la espina clavada de querer liberar a CycleFramework, y aunque ahora mismo tenga más fuerza la cabezonería que la necesidad, me puse manos a la obra.

Actualmente la versión principal de CycleFramework tiene dos dependencias importantes con el SDK de Flex:  ArrayCollection y ChangeWatcher.

Recordando nuestro propio ejemplo para ponernos en situación:

• utilizamos ArrayCollection para almacenar el camino visual que queremos representar en nuestra aplicación en un determinado momento. Este camino visual no es más que un lista elementos que identifican de forma unívoca nodos en nuestra jerarquía de vistas.

new ArrayCollection(['vm','userManager',"retrieve"])

donde ese ArrayCollection identifica que deseamos realizar una navegación hacia la vista ‘retrieve’ que cuelga de ‘userManager’ que a su vez cuelga de ‘vm’: vm > userManager > retrieve.

• ChangeWatcher se utiliza para observar cambios en la vista actual que se está visualizando, de tal modo que podamos navegar hacia una vista diferente.

El primer paso para eliminar estas dependencias ha sido deshacernos de la clase ArrayCollection. La clase ChangeWatcher implica un trabajo extra adicional para poder eliminarla ya que en ActionScript puro no existen las clases de utilidad para binding con lo que hay que llegar a alguna solución a medida − ya he empezado a investigar en este sentido, pero lo dejaremos para más adelante.

Las razones por las cuales queremos deshacernos (y podemos) de esta clase son:

1. Nos hace dependientes del SDK de Flex y no lo necesitamos (ni lo queremos).
2. Se trata de una clase que envuelve a la clase Array (mantiene la lista en el atributo source). Esto implica una capa adicional para acceder a la fuente, añadiendo tiempo de acceso y procesamiento que empeoran el rendimiento.
3. No necesitamos ninguno de los métodos que ArrayCollection hereda de ListCollectionView.
4. Las operaciones necesarias para realizar y gestionar navegaciones son mucho más rápidas con la clase Array.
5. No necesitamos manejar cambios provocados en la colección: COLLECTION_CHANGE. Una de las ventajas de ArrayCollection es que permite añadir manejadores para detectar inserciones, borrados, modificaciones en la lista. Esto facilita el trabajo a la hora de modificar el comportamiento de nuestra interfaz, pudiendo incluso bindar variables con expresiones tales como: arrayCollection.getItemAt(index);. No obstante, no lo necesitamos en CycleFramework.
6. Hace engorrosa la tarea de querer lanzar navegaciones. Cada vez que queremos navegar, necesitamos hacer un new ArrayCollection(['vm','userManager','retrieve']);. Utilizando simplemente un Array, ahora nos bastará con hacer ['vm','userManager','retrieve']. Escribiremos menos líneas de código, y además será más rápida la instanciación.

En nuestro caso es fácil deshacernos de esta clase, ya que realmente nosotros solo necesitamos un lista de identificadores que refleje la navegación que se quiere realizar. Para esto nos basta simplemente con utilizar la clase nativa Array. En el propio CycleFramework, supuso eliminar todas las operaciones sobre ArrayCollection y sustituirlas por las operaciones “pares” en Array:

1. new ArrayCollection([]) => []
2. list.getItemAt(index) => array[index]
3. list.removeItemAt(list.getItemIndex(item)) => array.splice(array.indexOf(item),1)
4. list.addItem(item) => array[array.length] = item
5. etc.

Ahora, en nuestras aplicaciones, simplemente debemos sustituir:

new ViewStateChangeEvent(ViewStateChangeEvent.MODIFY_VIEW,new ArrayCollection(['vm','init'])).dispatch();

por:

new ViewStateChangeEvent(ViewStateChangeEvent.MODIFY_VIEW,['vm','init']).dispatch();

Y esto es todo; en breve hablaré de cómo quitar la dependencia con ChangeWatcher. De momento, este código no está incluído en la rama principal del proyecto en Google Code. Se ha creado una rama específica para el mismo, que muy pronto se incluirá en la rama principal. Si queréis jugar con ella, os dejo aquí los datos de acceso. Esperamos vuestros comentarios al respecto

# Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://cycleframework.googlecode.com/svn/branches/CycleFrameworkArray cycleframework-read-only

Hace ya tiempo que tenemos un ojo puesto en los tablets y otro en los smartphones y cada vez me parece más emocionante el momento que se vive en el mercado de los dispositivos móviles.

Actualmente está claro que el actor con la posición más relevante en este mercado es Apple, pero el asalto está preparado y parece ser que todos los fabricantes van a llegar casi a la vez con sus nuevos dispositivos en un periodo muy corto de tiempo.

Por los últimos anuncios que he ido leyendo, los primeros tablets en salir serán los de Dell, Samsung, ExoPC, Hewlett Packard y Asus, aunque también hay anuncios de Cisco y otros fabricantes menos conocidos, como por ejemplo WeTab GmbH.

Dell Streak

La salida del Dell Streak será a finales de julio en EEUU, por lo que puede ser el primer tablet en lanzarse para competir con el dispositivo de Apple. De ser así, también será el primer tablet con Android 2.2 que se lance al mercado.

También parece que Samsung prepara la salida de Galaxy Tape para finales de verano. Incluiría también un sistema operativo Android 2.2.

Para septiembre está también planificada la salida de ExoPC Slate, un tablet de fabricación canadiense que en este caso confía en Windows 7 como su sistema operativo.

HP Slate

Posiblemente también para después de verano, Hewlett Packard tiene preparados, a falta de uno, dos tablets.
Su estrategia se basa en sacar un dispositivo orientado a empresa (con Windows7) y otro orientado a “usuario de a pie” (con WebOS, adquirido tras la compra de Palm). Esto lo sabemos desde hace un par de días, ya que leímos la noticia donde se hablaba del abandono del tercer tablet, el cuál iba a incluir Android como sistema operativo.

Por último, comentar que Asus (ver noticia de su Eee Pad en Xataka), Lenovo LePad, Cisco Cius e ICD Vega también preparan la salida de sus tablets con Android, aunque de estos no tenemos noticias sobre las fechas.

Asus Eee Pad

Como podéis observar, a finales de este año y principios del que viene dispondremos de una amplia gama de tablets para todos los propósitos, y lo que es más importante, se dispondrá de una amplia gama de dispositivos plenamente funcionales y sin restricciones para su uso.

Todos estos dispositivos son capaces de ejecutar una amplia variedad de aplicaciones al igual que lo puede hacer un ordenador personal, con la diferencia de que añade características adicionales y limita otras por su propia naturaleza, por lo que el desarrollo de aplicaciones orientadas a los mismos es fundamental para su éxito.

Pensémoslo, un dispositivo sin una gran variedad de aplicaciones, al alcance de todos los bolsillos, y que le saquen el máximo partido no acaba siendo más que un gadget bonito que sólo sirve para decorar.

Por este motivo, muchos de estos dispositivos ya nacen integrados con algún tipo de tienda online al estilo Android Store y permiten la ejecución de aplicaciones web a través del navegador. Esto habilita el acceso desde el primer día a aplicaciones ya desarrolladas para smartphones y aplicaciones web, tanto de intranet como Internet,  disponibles a través del navegador.

Pero a día de hoy, no sólo existen aplicaciones desarrolladas con la mente puesta en otros dispositivos (PCs, portátiles o smartphones): ya hay grandes apuestas por aplicaciones ideadas para sacar el máximo partido a los tablets. Un caso a remarcar es el de la revista WIRED.

Pinche aquí para ver el vídeo

En el vídeo se puede ver toda la potencia de la aplicación ejecutándose en un tablet, y aquí es donde aparece una de las grandes ventajas de Adobe AIR y de Adobe Flash. El poder publicar una misma aplicación en cualquier pantalla (véase Open Screen Project) permite desarrollar a menor coste y llegar con el mismo producto software a cualquier usuario final, utilice el terminal que utilice.

Gracias a esto, si ya estais pensando en adquirir alguno de estos tablets, podreis contar con esta gran aplicación desde el primer día, ya que permitirán la instalación y ejecución de aplicaciones desarrolladas en Adobe Flash (a través del navegador) o Adobe AIR (descargadas de alguna tienda o directamente de Internet).

En definitiva, se abre un nuevo mercado de hardware y Adobe Flash y Adobe AIR parten con ventaja por su propia naturaleza.

Continuamos con la serie de entradas que estamos dedicando al panorama de proyectos Flash para visualización en 3D fijándonos esta vez en Away3D.

Como Papervision3D, Away3D es software libre: se publica bajo una licencia Apache 2.0.

La referencia oficial de las clases en formato HTML se encuentra en http://away3d.com/livedocs/3.5.0_lib/ (versión 3.5.0 para Flash Player 10). De nuevo, el código fuente y otros documentos básicos están alojados en la página del proyecto en Google Code. El dominio oficial en cambio funciona como una bitácora colectiva en la que los programadores más implicados en el proyecto comparten reflexiones, noticias y ejemplos destacados de uso del software. Away3D se distribuye preferentemente en forma de archivos comprimidos con las fuentes completas. En caso de que se quiera mantener una copia local del código fuente en nuestros proyectos Flex, el repositorio Subversion es http://away3d.googlecode.com/svn.

Un holamundo en Away3D — Flash, fuente

El enfoque de nuestro holamundo en Flex 4 para Away3D será totalmente análogo al holamundo que explicamos para Papervision, así que no vamos a entrar en muchos detalles, salvo en aquellos puntos donde haya diferencias relevantes.

También en este caso tenemos una clase principal (spark.components.Application) que se limita a instanciar la clase Away3DWorld y a definir un refresco esperado para la aplicación de 60 cuadros por segundo. Cuánto es capaz Away3D de aproximarse a esta tasa de refresco, lo veremos más adelante en la prueba de rendimiento.

La vista más simple que podemos crear para nuestro ejemplo se llama View3D; la instanciamos sin parámetros y nos provee de los elementos necesarios que ya nos son familiares (en este caso, cámara, escena y motor; Away3D no espera cambios en el visor, así que ni siquiera existe esa categoría en la jerarquía de clases). En realidad, podemos encontrar en la documentación la vista SimpleView, que está pensada precisamente para casos sencillos. Esta vista contiene a su vez un objeto protected View3D, objeto que podríamos usar si escribiésemos una clase que heredase de ella. Como queremos limitar el número de clases al mínimo, en este caso no vamos a hacerlo.

Si definimos las mismas geometrías que teníamos en Papervision, veremos que la proyección del cilindro no coincide con la que vimos antes. El motivo puede estar en las propiedades del visor, sobre las que ahora no tenemos control, o bien en la interpretación diferente que una y otra biblioteca hacen del campo visual de la cámara. Para mejorar la apariencia del ejemplo, vamos a variar un poco la posición de la cámara y su campo visual:

_view = new View3D ();
_view.camera.moveTo (0, 0, -800);
_view.camera.fov = 45;
addChild (_view);

Otra diferencia que nos encontramos en seguida es que un mundo definido con Away3D está, por defecto, a oscuras. Es decir, necesitamos colocar y orientar correctamente al menos una fuente de luz para poder apreciar volúmenes. Si no lo hacemos así, el objeto aparecerá como una silueta negra:

var light:DirectionalLight3D = new DirectionalLight3D ();
light.direction = new Number3D (0, 1, 100);
_view.scene.addLight (light);

La manera de inicializar objetos también es un poco distinta en Papervision y en Away3D: mientras que en el primer caso los constructores en general admiten un gran número de parámetros, en Away3D se prefieren constructores con una signatura minimalista, a menudo con un único parámetro Object que contiene todas las propiedades del objeto:

// Papervision3D:
new Cylinder (new FlatShadeMaterial (null), 200, 800, 100, 1, 200, true, true);
 
// Away3D:
new Cylinder ({radius: 200, height: 800, segmentsH: 1, segmentsW: 100, material: mat});

Pruebas de rendimiento con Away3D — Flash, fuente

De nuevo vamos a modificar el ejemplo inicial para mostrar no uno, sino un conjunto de objetos rotando.

Como es lógico, para que las pruebas de rendimiento que hagamos sean representativas, y para que podamos comparar con otras bibliotecas, necesitamos asegurarnos de que la carga de trabajo es en principio similar en todos los casos. Al intentar reproducir con Away3D el mismo ejemplo que escribimos con Papervision (aquella matriz de 20×20 prismas de colores rotando) nos encontramos con otra diferencia: mientras que Papervision aproxima cada prisma con 4n-4 triángulos (donde n es igual al número de lados de la base, o sea 4), Away3D mantiene un número ligeramente mayor de polígonos para la misma figura. En concreto, 4n. (Para quien esté interesado, la diferencia está en la forma de aproximar los dos polígonos regulares de las bases: Papervision parte esas superficies trazando segmentos en forma de acordeón, mientras que Away3D las construye con n triángulos, todos ellos compartiendo como vértice el centro del polígono.)

Esto no supone mayor problema, pero para no dar «ventaja» a Papervision en las pruebas de rendimiento, vamos a ajustar ahora el número de prismas para que la cantidad total de triángulos a renderizar sea la misma. Omitiendo un cuadrado de 10×10 objetos en el centro de la estructura se consigue esto, y el número de triángulos en la escena sigue siendo 4800:

Para vaciar esa región, simplemente hemos añadido una condición especial al doble bucle que genera el array de prismas:

for (var i:int = -475; i <= 475; i += 50) {
    for (var j:int = -475; j <= 475; j += 50) {
        if (i < -250 || i > 250 || j < -250 || j > 250) {
            // Crear un prisma en esta posición
        }
    }
}

La clase que nos facilita estadísticas internas del motor gráfico de Away3D se llama AwayStats:

var a:AwayStats = new AwayStats (_view);
addChild (a);

El cuadro que aparece arriba a la izquierda (aquí ampliado) nos da información sobre la tasa real de cuadros por segundo frente a la deseada (6 sobre 60 en este instante). Haciendo clic en la parte inferior o superior de  la gráfica podemos reducir o incrementar, respectivamente, la frecuencia de refresco. Obviamente, cuando el motor gráfico no consigue alcanzar el refresco deseado, aumentar el valor de éste no tendrá ningún efecto práctico. También podemos ver aquí información acerca del consumo de memoria y el número de polígonos que son visibles en la escena en un momento determinado. En una futura entrega, cuando comparemos entre sí las distintas bibliotecas, explicaremos el porqué de estos números.

Próxima entrega: Sandy 3D Engine.

De las tres opciones para gráficos 3D en Flash que mencionamos en la entrada anterior, la primera que vamos a presentar con detalle es Papervision3D.

Una característica interesante del proyecto (y que comparte con los otros proyectos 3D que analizaremos más adelante) es que es software libre. En concreto, Papervision se publica bajo una licencia MIT, que está considerada una licencia open source. Este detalle es especialmente interesante para nosotros porque, al tener acceso al código fuente, podemos leer directamente el código para averiguar cómo usa exactamente la biblioteca algunas propiedades de clase y parámetros de métodos que por desgracia no están descritos en la documentación oficial de las clases.

El sitio web principal de Papervision es papervision3d.org (la intro Flash de esta página es en sí misma un buen ejemplo de Papervision, aunque demasiado pesado). Si embargo, el grueso de los recursos —código fuente, binarios, documentación, etc.— se encuentra en la página correspondiente de Google Code. La última versión empaquetada de la biblioteca es la 2.1.932 y el SWC correspondiente ocupa unos 485 KB. La URL del repositorio Subversion con el código fuente es http://papervision3d.googlecode.com/svn/trunk.

Un holamundo en Papervision3D — Flash, fuente

Veamos cuáles son los elementos mínimos que deben existir en cualquier mundo 3D (esta terminología es común a la mayoría de sistemas):

• Vista. Es el componente que sirve de base y que va a contener al resto de elementos.
• Escena. Son todos los objetos y efectos que se van a mostrar, o sea la definición del entorno en tres dimensiones.
• Cámara. Obviamente, se trata de una cámara virtual; una abstracción que nos permite introducirnos en el mundo 3D y observarlo desde un determinado punto de vista.
• Visor (viewport). Podemos pensar en el visor como en una pantalla de cine, o de televisión. Es la superficie plana de forma rectangular sobre la que se proyecta la imagen.
• Motor (renderer). Es el proceso que hace todos los cálculos necesarios para generar sobre el visor una representación de la escena tal y como se vería desde la cámara.

Como primer contacto con Papervision, vamos a escribir un ejemplo lo más pequeño posible en Flex 4. Escribiremos dos clases: una que llamaremos Papervision3DWorld y que se ocupará de crear y de animar un pequeño mundo 3D, y la típica clase principal (subclase de spark.components.Application) que se limitará a instanciar a Papervision3DWorld.

Como ya hemos dicho, el componente principal a través del cual vamos a ver el mundo 3D que creemos es la vista. En Papervision, las vistas son subclases de flash.display.Sprite. En Flex 4 no es posible añadir un hijo a Container mediante addChild(child:DisplayObject), así que no podremos añadir una vista directamente a Application. Lo que vamos a hacer es envolver la vista en un UIComponent, e instanciar este último dentro de la aplicación. (Mantendremos este mismo enfoque para las otras dos bibliotecas que veamos más adelante).

La escena que vamos a crear es un simple cilindro gris que va a rotar indefinidamente frente a nosotros (siga el enlace del pantallazo para ver el ejemplo en acción; puede hacer clic con el botón derecho sobre la película Flash para ver el código fuente y descargarlo):

Para hacer esto, podríamos crear y configurar a mano los cinco elementos mencionados arriba. Sin embargo, Papervision facilita la creación de vistas simples mediante una vista ya «precocinada»: basta con instanciar la clase BasicView con unos pocos parámetros. Entre esos parámetros, y dado que esto es una prueba básica, vamos a especificar una cámara de tipo depuración, que tiene la ventaja de que nos permitirá algunos movimientos con el teclado y el ratón. Añadimos la vista como hija de Papervision3DWorld:

private var _view:BasicView;

_view = new BasicView (width, height, true, true, CameraType.DEBUG);
addChild (_view);

Cualquier objeto que se cree en Papervision (incluyendo objetos especiales como una cámara) se coloca por defecto en el centro del sistema de coordenadas. Como pensamos dejar el cilindro en (0, 0, 0), vamos a alejar la cámara 1000 unidades hacia atrás en el eje z (ese es el eje que va perpendicular a nuestra pantalla, hacia dentro de ésta). También vamos a ajustar el campo visual de la cámara a 60°.

_view.camera.z = -1000;
_view.camera.fov = 60;

A continuación, vamos a crear el cilindro. Como la mayoría de sistemas de modelado y visualización 3D, Papervision nos ofrece unas pocas «primitivas»: objectos simples, generalmente poliedros, que podemos usar como bloques con los que construir escenas más complejas. Vamos a usar la primitiva Cylinder (que es en realidad un tronco de cono) dándole 200 unidades de radio tanto en la base como en la parte superior, y 800 unidades de altura. El resto de parámetros definen el material (un color plano) y el número de polígonos que se usarán para aproximar las superficies planas y curvas del objeto. Si no rotamos el cilindro, lo veremos de frente y en vertical, como si estuviésemos delante de la columna de un edificio. Para poder ver sus bases y hacerlo más interesante, lo rotamos sobre dos ejes. El último paso es añadir el cilindro a la escena (que, recordemos, es parte de la vista).

private var _object:DisplayObject3D;

_object = new Cylinder (new FlatShadeMaterial (null), 200, 800, 100, 1, 200, true, true);
_object.rotationX = 30;
_object.rotationZ = 60;
_view.scene.addChild (_object);

Finalmente, para que el objeto se mueva necesitamos alterar su orientación ligeramente cada vez que Flash dibuje un cuadro nuevo, y pedirle explícitamente a Papervision que renderice de nuevo la vista para reflejar los cambios en la escena. Esto se consigue asociando un manejador al evento enterFrame:

addEventListener (Event.ENTER_FRAME, render);

private function render (e:Event): void {
    _object.rotationY += 1;
    _view.singleRender ();
}

El cuadro negro de la parte superior izquierda es otra consecuencia de usar org.papervision3d.cameras.DebugCamera3D: muestra la posición y la orientación de la cámara, así como algunas otras propiedades de ésta. Pruebe a hacer clic sobre la escena y a usar el ratón y el teclado para moverse dentro de ella.

Pruebas de rendimiento con Papervision3D — Flash, fuente

El holamundo que acabamos de escribir incluye sólo un objeto con pocos polígonos. En concreto, si miramos los valores que pasamos como parámetros al constructor del cilindro, veremos que la superficie curva se está aproximando con n=100 segmentos. Ese nivel de detalle produce n×2=200 triángulos recubriendo toda la altura del cilindro, mientras que cada una de las dos bases está compuesta por n-2=98 triángulos. Esto arroja un total de 200+(2×98)=396 triángulos.

La forma en la que un objeto como este se aproxima usando únicamente triángulos queda más clara si cambiamos un poco la llamada al constructor del cilindro para asignarle un material de tipo alambre negro y bajamos mucho el número de segmentos para simplificar la figura:

_object = new Cylinder (new WireframeMaterial (0, 1, 2), 200, 800, 10, 1, 200, true, true);

Vamos a poner a prueba a Papervision3D aumentando el número de polígonos: crearemos 400 objetos dispuestos en un cuadrado de 20×20 objetos. Seguiremos usando la primitiva Cylinder, pero esta vez reduciremos el número de segmentos a n=4, obteniendo en la práctica prismas de base cuadrada.

Siguiendo la fórmula anterior, cada prisma estará compuesto por 4×n-4=12 triángulos. En total, 400×12=4800 triángulos en la escena. A cada objeto le asignaremos un color ligeramente diferente, creando un degradado, y una rotación inicial también distinta (siga el enlace del pantallazo para ver la prueba de rendimiento en acción; puede hacer clic con el botón derecho sobre la película Flash para ver el código fuente y descargarlo):

Para medir la eficiencia del resultado, usaremos la clase StatsView, que muestra en tiempo real algunas estadísticas internas de Papervision:

private var _stats:StatsView;
_stats = new StatsView (_view.renderer);
addChild (_stats);

En este caso, en lugar de una propiedad _object de tipo DisplayObject3D, tendremos una propiedad _objects de tipo ArrayCollection. Cada prisma que se crea se añade tanto al vector _objects como a la escena:

private var _objects:ArrayCollection;

var cylinder:DisplayObject3D;
var colour:uint;
 
_objects = new ArrayCollection ([]);
 
for (var i:int = -475; i <= 475; i += 50) {
 
    for (var j:int = -475; j <= 475; j += 50) {
        colour = (((i + 475) * 191 / 950 + 64) << 16) +
            (((j + 475) * 191 / 950 + 64) << 8);
        cylinder = new Cylinder (new FlatShadeMaterial (null, colour, 0x808080),
            10, 40, 4, 1, 10, true, true);
        cylinder.x = i;
        cylinder.y = j;
        cylinder.rotationX = (i + 475) * 360 / 950;
        cylinder.rotationY = (j + 475) * 360 / 950;
        _objects.addItem (cylinder);
        _view.scene.addChild (cylinder);
    }
 
}

El tipo de cámara, así como su posición y orientación, son distintas a las del programa anterior para mejorar un poco la apariencia y garantizar que todos los objetos de la escena son visibles dentro del visor.

El último cambio es que el método render ahora necesita recorrer todo el vector de objetos para actualizar sus orientaciones uno por uno:

private function render (e:Event): void {
 
    for each (var cylinder:DisplayObject3D in _objects) {
        cylinder.rotationX += 4;
        cylinder.rotationY += 4;
    }
 
    _view.singleRender ();
 
}

Como vemos, el número de cuadros por segundo que Papervision es capaz de manejar ha bajado notablemente al complicar la escena. En próximos artículos prestaremos atención a las estadísticas que muestra StatsView y analizaremos la bondad de esta prueba de rendimiento en relación a otras biblioteca Flash para 3D.

Próxima entrega: Away3D

La plataforma Flash nació como un medio de dos dimensiones. Durante aquellos primeros años, las animaciones Flash que nos encontrábamos en la web eran sobre todo a base de sprites o figuras planas, muy similares a los dibujos animados de la televisión.

Sin embargo, ya hace un tiempo que surgieron unas pocas iniciativas de bibliotecas para hacer 3D en ActionScript. Esta progresión nos ha llevado de aquel lienzo plano de los inicios a un verdadero espacio con profundidad dentro del navegador. Dos avances en los últimos años han hecho posible esta transformación: por un lado, la mejora sustancial en el rendimiento del hardware de nuestros equipos; por otro, las sucesivas versiones de Flash Player. Estos dos factores han sido decisivos para que los programadores puedan permitirse los costosos cálculos matemáticos que son necesario para recrear objetos en un espacio de tres dimensiones, darles texturas, moverlos e iluminarlos.

En el panorama de proyectos de bibliotecas 3D para ActionScript nos encontramos principalmente tres opciones: Papervision3D, Away3D Flash Engine y Sandy 3D Engine.

Desde Cycle IT queremos presentar cada uno de estos proyectos en un breve artículo. En cada entrega vamos a resumir las características principales de una de estas tres bibliotecas y a enlazar algunos recursos online donde ampliar información. Incluiremos también un holamundo específico para esa biblioteca y mostraremos el código fuente. Finalmente, haremos algunas mediciones básicas sobre ese código de ejemplo: rendimiento en cuadros por segundo, impacto en memoria de los objetos 3D, etc.

Para que las comparaciones entre bibliotecas sean más significativas, el ejercicio será siempre el mismo: crear un cilindro de un color plano y hacerlo rotar delante de la cámara. Se trata de un ejemplo mínimo pero completo de modelado 3D, asignación de materiales y animación.

Próxima entrega: Papervision 3D

Parece ser que el gran actor del vídeo en Internet comienza a sacar sus propias conclusiones sobre el estado de madurez de HTML5.

Hace un par de días se publicó un post en el blog oficial de YouTube donde quedan claras las carencias de HTML5, y que mientras estas existan no se podrán abordar soluciones de vídeo complejas y profesionales mediante esta tecnología.

We need to do more than just point the browser at a video file like the image tag does

La frase es bastante clara y creo que resume de forma concisa la totalidad del artículo. Desde hace años, todo el mundo ha conocido las limitaciones de HTML y JavaScript a la hora de implementar aplicaciones web mínimamente complejas. Por este motivo, aparecieron en escena tecnologías como Flash, que dan solución a dichos problemas de una forma eficiente.

La problemática de un Proyecto como YouTube es muy compleja y desprende unos requisitos inabordables con tecnologías poco maduras o inadecuadas. Por este motivo, para dar solución a dicha problemática se han de combinar distintas tecnologías (por ejemplo HTML y Flash, sin contar tecnologías server-side) y así poder llegar a una solución satisfactoria para usuarios y clientes, que al final son quienes realmente importan.

El análisis no deja lugar a dudas: La aparición de HTML5 no cambiará YouTube, al menos a corto plazo.

El pasado jueves 16 de junio firmamos con ENISA (Empresa Nacional de Innovación, SA) un préstamo preferente, libre de avales, orientado a la inversión en activos fijos y en activo circulante requerido para el desarrollo de la actividad.

Para optar a esta línea de financiación se ha exigido la presentación de un proyecto empresarial innovador y viable; en este marco Cycle-IT cuenta con las características necesarias y así ha sido reconocido por esta empresa de capital público adscrita al Ministerio de Industria, Turismo y Comercio.

Este voto de confianza reafirma, más si cabe, nuestra convicción sobre lo innovador de nuestro Proyecto, y nos permite mirar hacia adelante con optimismo y avanzar con paso firme. En este sentido, Cycle-IT dedicará parte de estos recursos a inversión en tecnologías que permitan aumentar el volumen de negocio a la vez que optimicen la productividad.

Queremos agradecer una vez más a AJE Madrid (Asociación de Jóvenes Empresarios de Madrid), y en particular a Raúl Jiménez Frías, por facilitarnos en todo lo posible las gestiones y trámites administrativos que siempre conllevan este tipo de proyectos.

Desde nuestra experiencia, animamos a jóvenes con talento que hayan comenzado recientemente una actividad empresarial de carácter innovador a solicitar estas líneas de financiación. Una ayuda de gran valor especialmente para afrontar con garantías el primer año de actividad de toda nueva empresa.

Según podemos leer en sus blogs oficiales, ya tenemos disponibles para descarga las versiones definitivas de Adobe AIR 2 y Flash Player 10.1. Hemos podido disfrutar, durante sus respectivas fases beta, de las notables mejoras respecto al rendimiento que aportan, a parte de las nuevas capacidades y funcionalidades que presentan. Entre ellas:

• Rendimiento y eficiencia
• Mejoras en vídeo
• Multi-touch
• Modo de navegación privada
• Mejoras específicas para Mac
• Integración en dispositivos móviles
• etc.

Además, desde Adobe, se han preocupado de ir moviendo el lanzamiento de estas versiones con seminarios por internet, cursos, posts para ir mostrando y demostrando la potencia de estas nuevas versiones:

• Video tutorial: Create native installers in AIR 2 por Serge Jespers
• Using Growl in AIR applications with AIR 2 NativeProcess por Serge Jespers
• What’s new about HTML, HTML5, CSS and JavaScript in AIR 2 por Mihai Balan
• Security changes in Flash Player 10.1 and AIR 2
• Using the AIR 2 NativeProcess API to create a screen recorder por Benjamin Dobler
• Multi-touch water simulation example por Lee Brimelow

Lo único de lo que no se han preocupado de momento es de ofrecer las versiones de depuración de Flash Player 10.1. ¿Nos han dejado a los desarrolladores para más adelante?

¿A qué esperáis para descargaros las nuevas versiones y descubrir toda su potencia? Os lo dejamos algo más fácil

• Flash Player 10.1
• Adobe AIR 2

PD: Como nota de humor y jocosidad, os dejamos también una pequeña mofa comparativa entre html5 y flash. Espero que la disfrutéis con humor

Ya hace una semana de Google IO 2010 donde se presentan las últimas novedades tecnológicas de la compañía. Esta presentación será recordada por un gran discurso de Vic Gundotra, vicepresidente de ingeniería de Google y ex-evangelista de Microsoft, donde defendía la libertad de elección en el mundo del software y la necesidad de un sistema operativo abierto.

Obviamente, lo más interesante de toda la presentación fue Froyo (Android 2.2), que incluye grandes mejoras respecto a su predecesor Eclair (Android 2.0/2.1) como compilador JIT, integración del motor de Chrome o soporte para Adobe Flash Player 10.1, entre otras muchas novedades.

Desde mi punto de vista, me parece que Google lo está haciendo muy bien con Android y eso se refleja en el mercado. Si nos fijamos en el número de fabricantes que ya han adoptado Android da escalofrío. Revisando sus terminales podemos ir desde un Nexus One hasta IVY, el SmartPhone low-cost de Telefónica + Huawei. Y eso que aún no ha empezado la batalla de los tablets.

Cabe destacar que Android no se queda ahí, ya se está preparando la nueva versión con soporte para WebM. Para los que no conozcáis WebM, es un proyecto dirigido a crear un formato de vídeo abierto de alta calidad para la web. Este proyecto está apoyado por Mozilla, Opera, Adobe, Google y otras cuarenta empresas.

Para concluir, aquí os dejamos con Vic Gundotra

Pinche aquí para ver el vídeo