Ezequiel_Pozzo->rand()

Algoritmo Marching Squares

noreply@blogger.com (2b) — Sat, 27 Oct 2012 20:24:00 +0000

En el post anterior, comenté que no hay solamente una forma de representar voxels en pantalla. Mostré las formas mas simples y mencioné el algoritmo Marching Cube como una posibilidad para suavizar el renderizado de voxels.

En este post, en lugar de mostrar el algoritmo Marching Cubes voy a mostrar su versión 2D: Marching Squares. El algoritmo Marching Squares permite hacer una analogía directa con Marching Cubes y puede ser comprendido mas fácilmente.

La idea entonces, es que tenemos un campo de voxels 2D. Una posible representación de ese campo de voxels es un simple array bidimensional de números enteros:

  v = [[0,     0,   0, 0],
       [30,  100,  30, 0],
       [100, 100, 100, 0],
       [ 30, 100,  30, 0]];

Una forma de representar esto sería utilizando una escala de grises con 0 = blanco y 100 = negro. Pero para evitar un resultado pixelado sería necesario un array de mayor dimensión.

Si lo que buscamos es usar un array de tamaño reducido para representar los voxels, pero a su vez un resultado no tan pixelado, podemos generar una "curva de nivel". Esto es, un contorno continuo de este campo usando segmentos de lineas. Es ahi donde entra Marching Squares.

Algoritmo Marching Squares

Este algoritmo permite obtener una "curva de nivel" de una función discreta (en este caso, los voxels). Los pasos a seguir son:

Convertir los voxels a un campo de valores 0 o 1 según un isovalor predeterminado.
Seleccionar un sub cuadrado 2x2 del campo de valores 0/1 y determinar un caso utilizando una tabla de casos (ver table mas adelante).
Utilizar los valores del campo de voxels original junto con el caso determinado en el paso 2 para obtener una linea interpolada.
Repetir desde el paso 2 para cada subcuadrado 2x2 del array original.

Utilizando el ejemplo anterior sería:

1. Convertir a campo de valores:

En este paso elijo un isovalor de 50 (punto medio entre 0 y 100) y creo un nuevo array que tiene 0 cuando el valor v[i][j] es menor o igual a 50 y 1 cuando v[i][j] es mayor a 50.

  v_iso = [[0, 0, 0, 0],
           [0, 1, 0, 0],
           [1, 1, 1, 0],
           [0, 1, 0, 0]];

2. Determinar casos:

Viendo cada subarray de 2x2 y comparando con la siguiente tabla de casos, determino el caso.

Tabla de casos. Un circulo negro corresponde a un voxel con valor superior al isovalor, uno blanco corresponde a un valor inferior. Los extremos de la linea resultante tienen que ser interpolados utilizando los valores de los voxels

En nuestro ejemplo, volviendo a v_iso, el primer subarray de 2x2 es

  [[0, 0], 
   [0, 1]

Comparando con la imagen, esto corresponde al caso 2. Ese caso es una linea diagonal de abajo hacia la derecha.

3. Interpolar usando voxels:

Si miramos en la tabla, cada extremo de las lineas celestes tiene una flecha que indica que ese extremo deberá ser ubicado teniendo en cuenta los valores de los extremos del lado. Tomemos el ejemplo encontrado en el paso anterior. Los valores de cada voxel eran 0, 0, 30 y 100, que resultaron en un Caso 2:

En este punto, hay que tener en cuenta que lo que estamos buscando es una linea correspondiente a un valor de 50. Si la distancia vertical y horizontal entre voxels es L y los valores en la posición de cada voxel son los valores dados por el voxel, entonces podemos interpolar las posiciones de cada extremo de la linea usando una proporción.

(100-30)/L = (50-30)/x

que implica que x es L*(50-30)/(100-30) = 0.28L

De la misma manera, para obtener la coordenada Y de la posición del otro extremo, podemos usar una proporción similar. En este caso, dado que los extremos corresponden a 0 y a 100, el valor de y es en el centro exacto de los voxels, o sea y=L*(50-0)/(100-0) = 0.5L

4. Repetir cada paso:

Si repetimos los pasos anteriores para cada subarray de 2x2 obtenemos el siguiente gráfico:

En el dibujo ya están las posiciones interpoladas de cada linea y un sombreado marcando el interior del polígono resultante. El interior del polígono se puede determinar fácilmente modificando la tabla de casos para mostrar cual es el interior en cada caso.

Ejemplo interactivo

La mejor forma de entender el algoritmo es utilizando un ejemplo interactivo y viendo el código. Hice un pequeño widget para poder experimentar. El ejemplo está realizado completamente en HTML5 usando webgl y javascript, por lo que es necesario un navegador moderno. El código fuente está disponible en google code.

Para usar el ejemplo solamente hay que asignar valores en la tabla. Se puede desactivar y activar el renderizado de voxels y de la isolinea.

Mostrar Voxels Mostrar Isolinea

Isovalue

En el próximo artículo voy a mostrar cómo se generaliza esta idea a un caso 3D con el algoritmo Marching Cubes.

Introducción a Voxels

noreply@blogger.com (2b) — Wed, 17 Oct 2012 21:57:00 +0000

Una forma utilizada frecuentemente para representar objetos tridimensionales es mediante triángulos en un espacio tridimensional. Esto es, conjuntos de vértices que forman triángulos en el espacio. Esta es la forma en que las placas de video actuales reciben los datos antes de representarlos en pantalla y por lo tanto es la forma en que se almacenan los polígonos que se utilizan en aplicaciones gráficas.

Un ortoedro representado mediante triángulos. Representación gráfica y formulación matemática.

Una forma alternativa de almacenar información tridimensional es el uso de voxels. Así como un pixel es un elemento 2D que indica el estado (color) de un punto en una pantalla, un voxel es un elemento 3D que asocia un valor (o valores) a cada posición de un espacio tridimensional. El voxel puede contener información de "cantidad" de materia (0 a 1 con 0 = vacío y 1 = lleno) así como información mas compleja como tipo de material, textura, etc.

Representación gráfica y matemática de los voxels. Solo se muestran 4 voxels "vacíos" pero se supone que hay voxels vacios en todas las posiciones en que no hay voxels llenos.

En la imagen se ve una representación de la figura de antes, pero ahora usando voxels. Así como antes se almacenaban vértices y uniones entre estos para formar triángulos, en la representación de voxels se asignan valores a los distintos puntos del espacio tridimensional. En la representación anterior se almacenaba información de la superficie de la figura, en la representación actual se almacena información del volumen.

Esta representación es solo una forma de almacenar información. La ventaja de esta forma de representar la información es que permite editar el objeto representado simplemente agregando o removiendo voxels.

En la figura de arriba se puede ver cada voxel como un cubo. Esta representación asume que un voxel solo puede tener el valor 0 o 1 (lleno/vacío), pero en general podríamos asignar cualquier valor entre 0 y 1 a cada voxel. Por otro lado, está el problema de convertir los voxels a un formato que pueda ser manejado por una placa de video (o sea, una serie de triángulos).

Formas de Representación

Izquierda: alta densidad de voxels representados mediante cubos de colores.
Derecha: baja densidad de voxels con la misma representación. (fuente: Google Images)

Si uno se limita a reemplazar puntos por cubos de color (así como en una imagen 2D se reemplazan puntos por rectángulos), el resultado es una imagen pixelada. Al igual que en una imagen 2D (pantalla o impresión) la calidad de la imagen depende de la densidad de pixels, la calidad de la representación 3D dependerá de la densidad de voxels. Es posible aumentar la resolución de voxels tanto como el hardware lo permita y obtener objetos fotorealistas. Esta forma de representar voxels no es eficiente para renderizado en tiempo real (por ejemplo un videojuego) si lo que se busca es fotorealismo ya que una alta densidad de voxels se traduce en una alta densidad de vértices incluso si evita renderizar las caras de los voxels que no son visibles por la cámara.

Una alternativa a lo anterior, para bajas densidades de voxels, es utilizar cubos con textura para reemplazar cada voxel. Esto permite darle una ambientación retro a un juego 3D, ver por ejemplo Minecraft.

Mincraft renderiza voxels usando cubos texturados.

Si lo que se busca es evitar formas "pixeladas" pero a la vez evitar usar altas densidades de voxels, hay que recurrir a algoritmos que utilicen el estado del voxel y el estado de sus vecinos para generar una superficie suave.

En el próximo post voy a explicar el algoritmo de Marching Cubes usando un ejemplo 2D para simplificar la explicación.

noreply@blogger.com (2b) — Thu, 01 Apr 2010 17:08:00 +0000

Se acerca el momento de desempolvar la Wii

Probando Unity3D

noreply@blogger.com (2b) — Fri, 05 Mar 2010 23:58:00 +0000

Estuve probando Unity3D como una forma de hacer juegos web. En el espíritu de "dejar todo asentado", muestro y explico los resultados.

Después de implementar el tutorial de plataformas, me largué a hacer un pequeño asset.

El desafío:

Hacerlo con scripts en C# (lenguaje que desconozco)
Interactuar con algún servicio web, usando JSON como tecnología

El resultado:

Lector de twitter en Unity3D

La primera impresión es que hacer scripts es extremadamente intuitivo. Si a alguien le interesa le puedo exportar el asset completo para que lo examinen en detalle.

Para comunicarme con Twitter, usé JSON. Existen muchos parsers JSON para C#, pero el que yo usé es "LitJson". Usarlo es tan simple como hacer un drag and drop de todos los archivos .cs de la distribución al árbol del proyecto Unity.

Paso a explicar el script:

using UnityEngine;
using System.Collections;
using LitJson;

public class TwitterPlatform : MonoBehaviour {
 public Camera camera;
 public Transform player;
 public string queryString="pozzoeRand";
 private Transform messageBoard;
 private ParticleEmitter emitter;
 private string twitterText;
 private MeshRenderer meshRender;
 private bool active=false;

No hay mucho de decir. A diferencia de Unity+Javascript, todo nuestro código debe ser implementado en una clase hija de MonoBehaviour. El nombre de la clase debe ser igual al archivo donde se encuentra el script.

Gracias a la magia de Unity, todas las variables públicas de la clase, son puestas en el object Inspector de Unity y pueden ser configuradas como parámetros del script. Instalar un script en un objeto implica haber instanciado un objeto de la clase del script. Y cada objeto tiene su propia variable. Eso hace que uno pueda tener un "query string" distinto en cada lector Twitter.

La variables "camera" y "player" deben ser configuradas al momento de instanciar un objeto que hace uso de este script. La forma de configurarlas es simplemente arrastrar una cámara y un jugador al slot correspondiente en el inspector de objetos. La cámara y el jugador se usan para permitirle al script acomodar el mensaje de texto de modo tal que sea siempre visible por el jugador.

El flag active indica si la plataforma está activada. El string twitterText es el texto a mostrar en el cartel de texto.

void Start () {
  this.emitter=this.transform.Find("CommunicationEffect")
    .GetComponent();
  this.messageBoard=this.transform.Find("TextRenderer");
  this.meshRender=this.messageBoard.GetComponent();
  this.meshRender.enabled=true;
  this.setDefaultText();
 }

La función Start es llamada automáticamente cuando se inicia la escena (el juego en este caso). En este script ajusto algunas variables privadas. Los detalles son mas evidentes al ver la estructura del objeto en si. El objeto donde está ubicado el script, tiene objetos hijos que se pueden acceder con la función Find. El objeto CommunicationEffect es un "efecto especial" que utiliza partículas para mostrar al usuario que está "pasando algo".

Por otro lado, el objeto "TextRenderer" es un cartel de texto que va a ser usado para mostrar el resultado de los queries al Api Twitter y también para mostrar el querystring antes que el jugador haya activado la plataforma.

void Update () {
  this.meshRender.transform.forward = this.camera.transform.forward;
  if (this.active==false)
   return;

  this.meshRender.transform.position = 
  this.player.transform.position 
  + this.camera.transform.forward*20
  + this.camera.transform.up*8;
 }

La función update es llamada automáticamente en cada frame del juego. Lo primero que hace es asegurarse que el cartel está paralelo al plano de la cámara, para que sea visto claramente.

Después, si la plataforma está desactivada (el jugador no ha pisado la plataforma), termina.

Si la plataforma está activada, la función update se asegura de que el cartel de texto esté puesto en un lugar de la plataforma que permita al jugador leer el texto. Las variables forward y up son vectores en las coordenadas locales del objeto (en este caso la cámara).

void OnTriggerEnter(){
  this.emitter.Emit();
  StartCoroutine(this.readTwitter());
  this.messageBoard.GetComponent().transform.position=this.player.transform.position+this.camera.transform.forward*20+this.camera.transform.up*8;
  this.active=true;
 }

La función OnTriggerEnter es llamada cuando el engine detecta una colisión con el mesh del objeto en el que se encuentra el script. Mas adelante muestro dos funciones relacionadas.

La función Emit() es llamada sobre el emisor de partículas. Hace que se emita un chorro de partículas. Luego, se inicia una corrutina que es la que se encarga de interactuar con twitter. Una corrutina es una función que puede interrumpir su ejecución para luego resumir en el mismo punto. La función StartCoroutine, usada de esta forma, ejecuta la corrutina readTwitter en paralelo a la función update, y continua ejecutando la funcion update.

IEnumerator readTwitter()
 {
  while (true) {
   string url="http://search.twitter.com/search.json?q="+this.queryString;
   this.twitterText="Loading";
   WWW tweets = new WWW (url); 
   
   int retries=0;
   bool  reload=false;
   while (!tweets.isDone){
    if (retries>20) {
     /*Will retry after trying 0.2*20 seconds*/
     this.twitterText="Loading";
     retries=0;
     reload=true;
     break;
    }
    this.twitterText+=".";
    yield return new WaitForSeconds(0.2f);
    retries++;
   }
   if (reload)
    continue;

Esta función es la que lee de Twitter. Recordemos que se está ejecutando en paralelo con el resto de las funciones. Y en particular, esta corrutina se está ejecutando en un loop infinito.

Lo que se hace es crear una petición al servidor de Twitter. Y después esperar hasta que Twitter responda. El problema es que no sabemos cuanto se puede demorar Twitter (con sus magnificos servers) en responder. Y aca es cuando entra la magia de las corrutinas. Cada "yield" es como un return, que devuelve la ejecución para que el engine sigua funcionando, con la particularidad de que al llamar la corrutina en el próximo frame la ejecución se continua en el yield, como si nunca se hubiera abandonado.

En particular se puede hacer otras cosas como yield return new WaitForSeconds(0.2f), hace que unity suspenda la ejecución de la corrutina y espere 0.2 segundos antes de continuar. De esta manera, en cada paso se le pregunta al objeto "tweet" si ya terminó de cargar todo lo que twitter le devolvió. Si no, se aumenta un contador y se espera 0.2 segundos antes de volver a preguntar. Si el server tarda mas de 4 segundos en responder, se vuelve a empezar desde el principio, o sea, se envía otro query (al menos es lo que teóricamente debería pasar, no lo probé, si alguien piensa lo contrario que hable).

En caso contrario, la corrutina continua su ejecución.

JsonData queryResult=JsonMapper.ToObject(tweets.data);
   JsonData tweetList=queryResult["results"];
   for (int i=0;i<tweetList.Count; i++)
   {
    this.messageReceived();
    this.twitterText=wrap((string)tweetList[i]["text"]);
    yield return new WaitForSeconds(4f);

   }

  } 
 }

Esta parte de la corrutina usa el parser de JSON para leer uno a uno los tweets. No hay mucho que sea especifico de Unity. Solo que nuevamente se espera 4 segundos entre tweet y tweet, para darle tiempo al jugador de que lea cada uno.

Este lector de twitter es absolutamente precario e ineficiente. Lo ideal sería que se muestren los tweets de mas viejo a mas nuevo y luego se actualizen los nuevos tweets a medida que la gente los va publicando. Todo eso es posible, pero no tiene sentido perder mas tiempo en este script que es solo de prueba.

La función MessageReceived simplemente activa el efecto del emisor de partículas. Se puede extender para que también reproduzca un sonido, por ejemplo.

void OnTriggerStay() {
  this.messageBoard.GetComponent().text=this.twitterText;
  
 }
 void OnTriggerExit(){
  StopAllCoroutines();
  this.active=false;
  this.setDefaultText();
 }

La función OnTriggerStay es ejecutada una y otra vez mientras el jugador está en contacto con la plataforma. Lo único que hace es mantener actualizado el texto de la plataforma. Tranquilamente podría haberse hecho en la función Update, luego de comprobar que la plataforma se encuentra activa.

La función OnTriggerExit es ejecutada automáticamente cuando se abandona la plataforma. En este caso, se detiene la ejecución de todas las corrutinas de este objeto y luego se vuelve a mostrar el texto con el querystring ubicado en el centro de la plataforma.

void setDefaultText()
 {
  this.meshRender.transform.position=this.transform.position+this.meshRender.transform.up*1;
  this.messageBoard.GetComponent().text=this.queryString;
 }
 void messageReceived(){
  this.emitter.Emit();
 }
 string wrap(string text)
 {
  string newText="";
  text=text.PadRight(140);
  for (int i=0; i<text.Length-28; i+=28)
  {
   newText+= text.Substring(i, 28)+"\n";
  }
  return newText;
 }

Estas son funciones de ayuda. La única que no mencioné es wrap, que simplemente distribuye el mensaje en varias lineas.

Este script es incompleto. Sería adecuado considerar errores como que twitter no devuelva tweets, y probar algunos detalles del funcionamiento.

Pero esto no es nada mas que un proyecto descartable para probar algunas de las características de Unity.

La idea inicial era implementar el automata celular mostrado anteriormente en Unity. Pero no estoy seguro de que sea lo mejor la performance de los scripts para ese tipo usos. Lo ideal sería extender la funcionalidad de Unity usando C++, pero esa es una característica disponible solamente en la version Pro (i.e. paga).

Automatas Celulares para simulación de explosiones en juegos

noreply@blogger.com (2b) — Fri, 12 Feb 2010 01:27:00 +0000

Ayer me puse a implementar un Autómata Celular. El objetivo final es simular una explosión en tiempo real. Voy a mostrar unos resultados preliminares que obtuve con Python, pero primero explico la idea.

En general, simular fenómenos físicos como explosiones, fluidos y fuego, en forma realista es demasiado costoso numéricamente como para que se pueda hacer en tiempo real en un videojuego. Sin embargo, hay una técnica que permite obtener aproximaciones visualmente plausibles utilizando los llamados Autómatas Celulares (AC).

Autómatas Celulares

Un Autómata Celular se puede pensar como una grilla cuyas celdas tienen asociado uno o varios valores. Cada celda tiene vecinos, generalmente 4. Al principio, se asignan valores iniciales, y luego se va haciendo evolucionar el AC siguiendo una regla matemática predefinida. Con este esquema general se pueden simular muchos fenómenos biológicos y físicos interesantes. Ver por ejemplo una implementación en Flash

Este concepto se puede generalizar mediante grafos dinámicos. Un grafo es en conjunto de Vértices, unidos mediante conexiones llamadas Aristas. Tanto los Vértices como las Aristas pueden tener propiedades asignadas.

Ejemplo de grafo: mis contactos de Facebook. Cada Vértice (círculos) es un amigo. Cada Arista (lineas) indica que mis contactos se tienen en sus respectivas listas de contactos. También hay propiedades asociadas: cada Arista tiene un tamaño dado por la actividad del contacto, una foto y un color que indica que el contacto pertenece a un "cluster". Los lados tienen un numero relacionado que indica la cantidad de fotos en la que ambos aparecen juntos.

Usando ese concepto general, se puede generalizar un Autómata Celular. El ejemplo básico de una grilla 2D, se traslada a un grafo en que cada Vértice tiene una posición (lo que originalmente era una coordenada en la grilla) y cuatro Aristas que conectan al Vértice con sus vecinos.

Esquema básico de un grafo que reemplaza a una grilla. Cada vértice de las paredes está conectado con un vértice de la pared opuesta, para crear un "mundo infinito". Todo lo que "sale" por la derecha "entra" por la izquierda.

Este esquema es mas general en varios sentidos. Primero, permite desacoplar fácilmente el espacio "real" de nuestro Autómata Celular, de esa forma ahora cada nodo del grafo puede estar en posiciones arbitrarias del espacio y, en particular, ubicados en forma no uniforme. Se puede entonces simular con mas detalle la física en algunas partes que en otras. Solamente es cuestión de ser cuidadoso a la hora de crear nuestro algoritmo. Otra virtud que tiene este esquema es que se pueden generar obstrucciones en el grafo para simular obstrucciones reales. Por ejemplo

Simular obstrucciones es solo cuestión de romper Aristas o Vértices. La imagen muestra cómo se puede relacionar un grafo con un mapa de nuestro juego. En esquemas mas complicados se pueden mantener todos los Vértices y Aristas y asignar pesos a las Aristas. De esta forma se pueden simular distintos tipos de "rigidez" o incluso destrucción de paredes.

Simulando explosiones

En este post explico como usar este esquema para simular explosiones plausibles en un juego, con poco costo numérico. El primer código que uso es python puro, con fines demostrativos. Incluso con la lentitud de implementar un algoritmo que recorre nodos en python, es posible ejecutar en tiempo real una grilla de 30x30 que ya presenta resultados interesantes.
Para simular una explosión se necesita un grafo que tenga definida una presión en cada Vértice. En cada paso de tiempo, se mira Vértice por Vértice y se compara la presión del Vértice con la presión de sus vecinos. Luego se calcula un flujo de "aire" entre el Vértice y el vecino y se lo utiliza para modificar sus presiones.
El esquema es básico e intuitivo: El nodo que tiene mas presión le entrega un poco a cada uno de los vecinos que tienen menos. Y así, paso por paso, se genera una frente de presión.

Voy a mostrar los resultados primero, y dejar el código comentado al final para quien quiera leerlo.

Explosión al lado de un obstáculo pequeño. Los tiempos son t=1, 4, 10, 20, 40, 80 y 200.

Explosión en una "puerta". La linea marrón es una pared. La simulación es para tiempos t=1, 4, 8, 20, 100 y 200.

Trasladando los efectos de la explosión al juego

Supongamos que el objeto que nos interesa se encuentra cerca de la explosión. Podemos calcular el vector de flujo sumando los vectores de flujo entre un Vértice y sus vecinos. En el ejemplo de la imagen siguiente, el vector de flujo sobre el nodo en que se encuentra el personaje tiene dirección sur oeste. Ese flujo, multiplicado por algún valor que represente la sección de área del personaje, nos indica una fuerza que actúa sobre el personaje.

Es interesante notar que en una explosión, todo sucede muy rápido en los primeros instantes de tiempo. En un juego uno podría simular decenas de pasos de un CA por cada frame del juego y utilizar un promedio en el tiempo del vector de flujo. Este promedio es el impulso a transferir a los objetos del juego en cada frame. De esta forma se puede simular el efecto medio de la onda expansiva en los jugadores, objetos ubicados en el mapa y en el mapa mismo.

También se puede sumar las magnitudes de flujo, para simular efectos como sordera momentanea, ruptura de vidrios, o daño general.

Cómo trasladar el efecto de la onda expansiva al personaje: Las flechas azules son los vectores de flujo entre el nodo del personaje y sus vecinos. La flecha roja es la suma de los vectores azules, que multiplicadas por el cross-section del personaje dan la fuerza que actúa sobre el personaje debido a la explosión. Promediando esta fuerza durante varios pasos del AC se obtiene el impulso sobre el personaje.

Código Python

Este es el código de los dos ejemplos mostrados. El próximo paso es convertir el loop principal a código C y exponer funciones para calcular los impulsos transmitidos a objetos del mapa.

def iterate_fl(N=30, steps=10):
    '''Automata Celular simple para calcular una explosión.
    Implementación de algoritmo de Tom Forsyth.
    Mas detalles:
    http://home.comcast.net/~tom_forsyth/papers/cellular_automata_for_physical_modelling.html'''

    from itertools import product, combinations
    def clamp(value, max, min):
        '''
        Función clamp, devuelve value si value está entre min y max, devuelve min o max si no.
        '''
        if value<min:
            return min
        if value>max:
            return max
        return value
   
    class Node():
        '''
        Decidí usar una implementación python pura para las pruebas preliminares.
        Este modelo permite CA en 3D y simular paredes u objetos inmoviles mediante desconexiones de nodos.
        '''
        pressure=0.0
        new_pressure=0.0
        t=0
       
        def __init__(self, position):
            self.position=position
            '''Los grafos tienen un conjunto de vecinos.'''
            self.neighbours=set()
           
        def __repr__(self):
            return 'node pressure: %s'%self.pressure
   
   
    '''Mantengo un diccionario posicion->nodo para poder acceder los nodos facilmente'''
    nodes=dict([(position,Node(position)) for position in product(range(N),range(N))])
   
    '''Cada nodo representa una celda en un espacio 2D, cuyo vecino es el vecino físico'''
    for node in nodes.values():
        '''En este ejemplo muestro dos tipos de condiciones de contorno en un grafo:
        paredes rígidas y condiciones periodicas'''
        if node.position[0]+1<N-1:
            '''Hay paredes rigidas a la derecha del mapa.'''
            nodes[node.position].neighbours.add(nodes[(node.position[0]+1, node.position[1])])
        if node.position[0]-1>0:
            '''Hay paredes rígidas a la izquierda del mapa'''
            nodes[node.position].neighbours.add(nodes[(node.position[0]-1, node.position[1])])

        '''La funcion mod (%) me asegura que la parte superior e inferior del mapa están
        conectadas. Lo que sale por arriba, aparece por abajo.
        '''
        nodes[node.position].neighbours.add(nodes[(node.position[0],(node.position[1]+1)%N)])
        nodes[node.position].neighbours.add(nodes[(node.position[0],(node.position[1]-1)%N)])
   
    '''Crea pared, removiendo nodos del grafo. Se pueden hacer paredes removiendo solamente conexiones
    Tipos de pared:'''
    wall=product((10,),range(0,15)+range(17,N)) #pared que cruza el mapa en x=10, con un agujero
    #wall=product((10,),range(14,17)) #pared de tamaño limitado en x=10
    for edg_pos in wall:
        node=nodes[edg_pos]
        for neigh in node.neighbours:
            neigh.neighbours.remove(node)
        del nodes[edg_pos]
   
    '''La explosión propiamente dicha.'''
    #explosion=product(range(4,10),(5,15)) # Un rectangulo
    explosion=((9,15),) #Solo un punto
    for node in explosion:
        nodes[node].pressure=300.0 #La explosion son puntos de alta presion
        nodes[node].new_pressure=300.0 #Este es un detalle del algoritmo
   
       
    '''Ejecutar CA'''   
    i=0
    while i<steps:
        i=i+1
        '''Algoritmo CA para explosiones'''
        for node in nodes.values():
            '''
            Recorremos todo el grafo
            '''
            if node.t!=i:
                '''Detalle de implementación: iteramos por todo el grafo aplicando las reglas del CA,
                los calculos se realizan con el estado actual del grafo y se almacenan los resultados en
                new_pressure, en el siguiente paso de tiempo, se actualizan los valores de la presion usando
                los valores calculados en el paso anterior.'''
                node.t=i
                node.pressure=node.new_pressure
               
           
            for neight in node.neighbours:
                '''Para cada nodo, se miran los vecinos. Este ejemplo es 2D, pero se puede hacer
                3D. En 2D tenemos 4 vecinos por cada posicion del espacio, pero puede haber menos
                vecinos si hay una obstrucción.'''
                if neight.t!= i:
                    '''Nos aseguramos de estar usando los valores de presion
                    calculados en el paso anterior'''
                    neight.t=i
                    neight.pressure=neight.new_pressure
                   
                '''Se calcula la dif. de presion entre el nodo actual y su vecino'''
                dpres=node.pressure-neight.pressure
               
                '''Calculamos el flujo como una fracción de la diferencia de presion.
                0.12 es un numero magico que indica la fluidez del medio. Un valor muy chico
                hace que la presion se propague mas lentamente.
                Usamos la funcion clamp para evitar valores negativos en el nodo.
                Se hace que el flujo no produsca una presión negativa'''
                flow=clamp(0.12*dpres, node.pressure/4.0, -neight.pressure/4.0)
               
                #Actualizamos la presion (usando new_pressure en lugar de pressure) substrayendo
                #presion del nodo actual y agregandola a su vecino. Un flujo negativo implica
                #que la presion del nodo actual aumenta y la del vecino disminuye.
                node.new_pressure -= flow
               
                neight.new_pressure += flow
       
    return nodes

Instalando Django a la par de un sitio PHP en Apache2 Ubuntu

noreply@blogger.com (2b) — Mon, 01 Feb 2010 22:03:00 +0000

Estoy comenzando a portear el sitio www.cruzandoelsuquia.com.ar, hecho en Joomla, a Django. Para eso necesito instalar Django en mi server de desarrollo (Una instalación básica de Ubuntu 9.10).

El objetivo es mantener la instalación actual del sitio Joomla, http:// localhost:80/ , y agregar una instalación de Django en el puerto 8000.

Los siguientes pasos son triviales, pero los dejo asentados para cualquiera que le pueda interesar.

Paso 1 - Instalar los paquetes
Instalar los paquetes de django, python para apache2 y los paquetes para acceder a mysql:

sudo apt get install libapache2-mod-python python-django python-mysqldb

Paso 2 - La configuración de Apache2
Suponiendo que el sitio de django se encuentra en la carpeta /home/usuario/django/sitio, debemos agregar el siguiente archivo:

# /etc/apache2/sites-available/django

 MaxRequestsPerChild 1

<VirtualHost *:8000>

    DocumentRoot /home/guillermo/django/cruzandoelsuquiaDJ/

    <Location "/">

        SetHandler python-program

        PythonHandler django.core.handlers.modpython

        SetEnv DJANGO_SETTINGS_MODULE cruzandoelsuquiaDJ.settings

        PythonDebug On

    PythonPath "['/home/guillermo/django'] + sys.path"

    </Location>

    <Location "/media">

        SetHandler None

    </Location>

    <Location "/feincms_media">

        SetHandler None

    </Location>

    <LocationMatch "\.(jpg|gif|png)$">

        SetHandler None

    </LocationMatch>

</VirtualHost>

Luego, para activar este host virtual, es necesario agregar el sitio a la lista de sitios activados:

cd /etc/apache2/sites-enabled/

ln -s ../sites-available/django 001-django

En mi caso particular, tengo el sitio predeterminado 000-default, que es mi instalación de Joomla en el pueto standard 80.

Paso 3 - Activar los puertos

Agregar lo marcado en rojo en el archivo /etc/apache2/ports.conf

# /etc/apache2/ports.conf


...

NameVirtualHost *:80
  Listen 80

NameVirtualHost *:8000
  Listen 8000
...

Paso 4 - Reiniciar Apache

cd /etc/init.d

sudo ./apache2 restart

Paso 5 - Servir los media del admin de django a travez de Apache

Hay varias opciones, una es linkear la carpeta "media" de la instalacion de django, para tener los css e imagenes del backend:

cd /home/usuario/sitio

ln -s /var/lib/python-support/python2.6/django/contrib/admin/media media

Esto es una solución provisoria, la solución final es usar la carpeta admin_media, previamente configurada en settings.py.

Espero que esto le sirva a alguien. A mi me hubiera servido.

Creando un directorio joomla en un par de semanas

noreply@blogger.com (2b) — Wed, 20 Jan 2010 20:20:00 +0000

A veces uno comienza un proyecto que no es necesariamente divertido, o intelectualmente recompensante, sino que es necesario realizar por razones prácticas.

Tal es el caso de un proyecto al que me dediqué las ultimas semanas. La idea es simple y ya recorrida: un directorio de locales comerciales (si, ya se, soy un SEO whore). La diferencia con otros directorios es que este solo tiene el modesto objetivo de contener la información de todos los locales comerciales del barrio general paz y barrios aledaños. Digo modesto porque no pretende ser un directorio a nivel pais y mucho menos mundial. Pero es un sitio que se me hace necesario (y supongo que a otras personas del barrio).

Relevar un barrio no es solo un problema tecnológico, implica también caminar por el barrio y recolectar la información necesaria. Pretender que un 80% del barrio se abalance a mi página a cargar su local (y que lo hagan correctamente) es fantasioso. Pero este es un tema que no voy a tratar en este post.

La razón de este post es explicar la "tecnología" detrás del sitio y la razón para usarla.

Como este no es una novela de suspenso, voy a empezar revelando el misterio.

Tecnología usada en el sitio

La solución es mas bien "enlatada" y consiste en:

El sistema gestor de contenidos Joomla.
Un componente de directorio comercial para Joomla (sitio en ingles) llamado SOBI2.
Un componente de avisos clasificados (sitio en ingles) llamado AdsManager.
Un componente de tags (sitio en ingles) integrable con los componentes anteriores.
Google maps.
Una herramienta útil para hacer backups y deployments en Joomla llamada JoomlaPack.
Y algunas herramientas de SEO básicas para Joomla: shSEF404 para generar urls search-engine-friendly y un componente para generar sitemaps que sea integrable con SOBI2 (xmaps).

Con estas partes pude cumplir el objetivo de hacer lo que podríamos llamar "un bosquejo" del sitio que me propuse. Esto en solo unas 3 semanas, utilizando tiempo libre.

¿Por qué Joomla?

Antes que nada, tengo que aclarar algo que mucha gente que no usa Joomla piensa: Joomla no es solamente un sistema gestor de contenidos, también tiene un framework PHP que permite programar cualquier funcionalidad en forma de nuevos componentes, módulos y plugins para Joomla, usando la filosofía MVC. Una vez aclarado esto, no es esta la razón por la que usé Joomla. La razón para usar Joomla es que quería obtener un producto funcionando en el menor tiempo posible.

El sitio necesitaba tener un gestor de usuarios, de categorías, de locales comerciales, de tags. Y a la vez tener un nivel básico de seguridad.

Una vez instalados los componentes, módulos y plugins, solo me restó crear un template, o sea la parte visual del sitio. Todavía hay partes incompletas, y las partes completas fueron diseñadas por mi, con lo cual hay mucho que desear. Creé un template yo mismo para que sea lo mas simple posible.

El resto del tiempo dedicado al proyecto fue en parte configuración de los componentes para que funciones entre ellos (por ejemplo, que el sitemap muestre las categorias y avisos del componente de directorio comercial, o que las busquedas devuelvan locales, o que los tags cambien según el contexto de la categoría de SOBI2 que el usuario está mirando, etc).

Pero el mayor consumo de tiempo vino de pulir la parte visual de los componentes. Y esto nos lleva a los problemas de Joomla (o mas bien de sus componentes).

Los problemas de Joomla

En principio, el framework PHP que provee Joomla permite utilizar el paradigma MVC de diseño. Con lo cual adaptar los componentes visualmente para un sitio propio debería ser tan simple como crear un view. El problema es que Joomla no obliga al programador a usar MVC y me atrevería a decir que la mayor parte de los componentes de Joomla no están programados usando dicha filosofía. La razón principal, me imagino, es que muchos componentes fueron creado para versiones viejas de Joomla que no poseían herramientas para desarrollar en MVC y luego adaptado para nuevas versiones.

Uno de los puntos que me llevó mas tiempo fue unificar el componente de directorio comercial y el componente de avisos clasificados para que tuvieran una estructura html similar y que utilizaran las mismas hojas CSS (esto para unificar ambas partes visualmente y para disminuir el numero de hojas de estilo descargadas por el usuario).

Por alguna razón que desconozco, ambos componentes utilizan tablas para posicionar las categorías y subcategorías. Pero en el caso de SOBI2 la situación fue especialmente odiosa, con las instrucciones que corresponderían al view "desparramadas" por varios archivos, entre queries sql y llamadas a funciones.

Básicamente tuve que hackear a travez del componente para cambiar lineas del estilo "echo ''", incrustadas entre llamadas a la base de dato, a funciones de otros archivos e includes.... Y esto en múltiples lugares, ya que al no abstraer el view hay una repetición de código según el contexto en que se muestran los distintos elementos. Todavía se puede ver en el código fuente del sitio, vestigios de tablas que no sé en que momento son mostradas.

Por otro lado, varios queries SQL son impenetrables: JOINS muútiples concatenados, múltiples niveles de SELECT, etc. Lo cual me llevó a preguntarme: ¿No hay una abstracción de la base de datos en el framework Joomla? En general los frameworks modernos proveen algún tipo de abstracción, por ejemplo Rails y Turbogears permiten al usuario programar usando objetos, los cuales son mapeados en forma semiautomatica a tablas en la base de datos. Entonces, en lugar de tener que escribir un query sql que use JOINS entre tablas puedo manejarme con objetos, con los JOINS abstraidos convenientemente como una composición de objetos. Probablemente Joomla tenga dicha abstracción, pero los programadores de SOBI2 no la hayan usado.

En principio podría haber usado otro componente en lugar de SOBI2. Pero según lei en internet SOBI2 es "el" componente de directorios para Joomla. Y claramente, desde el punto de vista del usuario que no va a modificar el código del componente, SOBI2 es una excelente herramienta, altamente configurable.

Esto es un problema principalmente de SOBI2, no de Joomla. Es interesante comparar, por ejemplo, con el poco trabajo que tuve cuando quise adaptar el componente nativo de busqueda de Joomla para mostrar los resultados en un Google Map. En este caso solo fue cuestión de buscar el modelo, insertar código para sacar de la base de datos la información geográfica de los resultados de busqueda y luego buscar el view e insertar el código para mostrar dicha información en un mapa. En un rato ya tenía el problema de los mapas solucionado.

A pesar de todos estos inconvenientes, es claro que la opción de programar el componente o el sitio yo mismo hubiera sido mucho mas costoso en tiempo.

Seguridad

Desconozco si existe algún tipo de agujero de seguridad en mi sitio. Dejo como tarea al lector tratar de hackear mi sitio. Todo se encuentra adecuadamente backupeado y listo para ser restaurado ante cualquier eventualidad. Solamente le pido que tenga en consideración describir la técnica usada en un comment de este blog.

El sitio es tan fuerte como el mas débil de sus componentes. Y teniendo los componentes distintos orígenes (y habiendo visto el código fuente de alguno de ellos), no me extrañaría que exista alguna vulnerabilidad.

Conclusión

Utilizar las herramientas que mencioné es una buena opción porque me permitió tener un sitio funcionando con poco tiempo de programación. Esto me permite empezar a dedicarme a promocionar el sitio y encontrar el set de funcionalidades óptimo para los posibles clientes.

Por otro lado, los cambios que tuve que hacer en los componentes hacen que se me haga imposible aplicar las actualizaciones oficiales sin romper mis cambios. Con esto en mente, es posible que en un futuro, cuando solucione o encamine el tema del "Business model" , se haga conveniente reimplementar el sitio desde 0 usando algún framework web. Hasta entonces, esta solución es adecuada.

Sería interesante saber si alguien conoce una mejor solución.

Un Modelo básico: Integrando ecuaciones de movimiento con el método de Euler

noreply@blogger.com (2b) — Wed, 09 Dec 2009 02:58:00 +0000

En los anteriores posts, expliqué las razones para usar MVC y la estructura general de un programa simple usando este patrón de diseño. Ahora voy a explicar la versión mas básica de un modelo: un simulador de partículas. Bajo ninguna circunstancia este modelo es un modelo aplicable directamente para un juego, pero es una primer iteración para poder implementar algunas cosas básicas como Steering Behaviors (que voy a explicar en otro post).

Este modelo considera partículas puntuales que se mueven libremente o bajo la acción de una fuerza, en un espacio de 2 dimensiones. Con este modelo simple se pueden implementar muchos tipos de juegos 2D: Juegos de plataforma, Arcanoid, Galaga, juegos de carrera o los juegos que sugirió Juan Pablo: Choplifter, Desert strike y Cannon Fodder. Que el Modelo sea 2D no implica usar gráficos 2D (el View), incluso se pueden usar gráficos 3D. Ejemplos clásicos de esto es el Wolfenstein 3D, donde en realidad el mapa es 2D, no existe la altura en el modelo, y sin embargo la representación es 3D. Un juego como Diablo, también tiene gráficos 3D siendo el modelo 2D. Con esto quiero aclarar que tener un modelo 2D no implica para nada utilizar gráficos 2D.

Derivadas

Antes que nada voy a explicar muy básicamente lo que es una derivada. Se puede encontrar una definición mas avanzada en la Wikipedia.

La derivada de la posición respecto al tiempo es el cociente entre la variación de la posición y la variación de tiempo. Si un auto avanza 10 km en 1 hora, podemos aproximar la derivada como 10km/1h=10km/h.

Pero la derivada es más que eso, la derivada implica que la variación en el tiempo sea muy pequeña. En nuestro caso, tendríamos que ver cuanto avanzó el auto en, por ejemplo, un segundo. Si el auto avanzó 3 metros en un segundo, entonces la derivada de la posición respecto al tiempo es más precisamente 3 m/1s=3m/s=10.8 m/s.

Se puede refinar el experimento, midiendo el desplazamiento para intervalos de tiempo aun mas pequeños. La derivada es el valor que obtenemos cuando el intervalo de tiempo es infinitamente pequeño:

En esta ecuación el triángulo es una forma de escribir "La variación de". O sea que la ecuación puede ser leída como "La variación de la posición, dividido la variación del tiempo". Cuando la variación del tiempo es infinitamente pequeña, el cociente se llama derivada. El caso de la derivada de la posición respecto al tiempo, es denominada "la velocidad". Pero uno puede derivar la velocidad, o sea, dividir un cambio de velocidad por el intervalo de tiempo en que ocurre este cambio. Esta última derivada se llama "aceleración".

Cuando derivamos dos veces, se suele decir que obtenemos "la derivada segunda". Entonces, la derivada segunda de la posición es la aceleración.

Una forma de escribir la derivada es poniendo un punto sobre la variable que se deriva. Y la derivada segunda se escribe con dos puntos sobre la variable que se deriva. Pero el significado es el mismo: el cociente entre la variación de una magnitud y la variación de tiempo durante el cual ocurre el cambio.

Ecuaciones de movimiento

Supongamos que tenemos un objeto que se mueve con una fuerza FX, FY aplicada. La ecuación de movimiento mas general que se puede escribir es:

Donde m es la masa del objeto. X e Y son las coordenadas de la partícula, y los dos puntos sobre la variable X es la derivada segunda de la posición respecto al tiempo (o sea, derivar la posición dos veces respecto al tiempo). Como dijimos anteriormente, esta derivada segunda se conoce como aceleración. "Fuerza igual masa por aceleración" es la llamada segunda ley de Newton.

Esta fórmula debe ser resuelta para obtener ecuaciones de movimiento que podamos usar. En el caso de una fuerza constante, las ecuaciones pueden ser resueltas en forma exacta:

Para quien sepa derivadas, es fácil ver que si derivamos la expresión de X dos veces, obtenemos la segunda ley de Newton con una fuerza constante (a0 es la fuerza dividida la masa).

Estas ecuaciones consideran solo la coordenada X. En las ecuaciones, el tiempo aparece en forma explicita como t, y los subindices 0 en la posición, velocidad y aceleración indican que se trata de la posición, la velocidad y la aceleración iniciales. En esta ecuación, la aceleración es constante, por tratarse de una fuerza constante. La segunda ecuación es la velocidad en función del tiempo, que en algunas situaciones es útil.

Las ecuaciones para las coordenada en Y son idénticas, pero reemplazando X por Y y utilizando las velocidades en la dirección Y en lugar de usar las velocidades en X y la aceleración en Y en lugar de la aceleración en X.

Estas ecuaciones tienen la limitación de que solo son válidas mientras la fuerza se mantiene constante. De cambiar la fuerza, cambia la aceleración, y las ecuaciones dejan de ser válidas. Si en general la fuerza varía en forma complicada con el tiempo, se hace imposible resolver las ecuaciones de movimiento en forma exacta.

El caso de fuerza que varía con el tiempo debe ser resuelto para cada caso particular. Las ecuaciones que resultan son en general mas complicadas. En un juego, necesitamos utilizar algún método general para resolver las ecuaciones independientemente de como varíe la fuerza.

Para hacer esto, lo mas simple es usar el llamado Método de Euler. El método de Euler es un método numérico para resolver ecuaciones diferenciales de primer orden, o sea que solo tienen derivadas primeras. La primer ecuación que mostré es una ecuación de segundo orden, pero eso puede ser resuelto fácilmente introduciendo la velocidad. La velocidad, como dijimos, es la primer derivada de la posición:

Utilizando esta definición, es posible convertir nuestra ecuación de movimiento en varias ecuaciones de primer orden, ya que la aceleracion es la primer derivada de la velocidad:

Con estas cuatro ecuaciones, tenemos solo derivadas primeras, con lo cual podemos aplicar el método de Euler.

El método de Euler consiste simplemente en volver a la definición de la derivada, y "olvidarse" que la derivada requiere que la variación del tiempo sea infinitamente pequeña. En lugar de eso, se utiliza una variacion de tiempo finita.

Usando esa aproximación, las ecuaciones anteriores resultan ser:

La ventaja de estas ecuaciones es que podemos resolverlas algebraicamente para obtener la posición de la partícula en un tiempo t, un instante de tiempo anterior t- Dt. Simplifiquemos un poco la notación, para que sea mas evidente como resolverlas:

Llamemos a la posición a tiempo t utilizando un subíndice: Xt es la posición a tiempo t.
Llamemos h a la variación del tiempo (también llamado paso de tiempo).
La variación de la posición no es mas que la diferencia entre dos posiciones. O sea:
Lo mismo puede decirse de la velocidad. La velocidad es la diferencia de la velocidad en dos tiempos distintos:

Teniendo eso en cuenta, resultan las siguientes ecuaciones (considerando solo las coordenadas en X):

Lo bueno de estas ecuaciones, es que solo requieren una multiplicación y una suma. Además, son absolutamente generales, pueden ser usadas para cualquier tipo de fuerza(aunque en algunas situaciones puede fallar).

La desventaja, es que es el método mas simple, y el mas impreciso. En general, la precisión de este método depende del tamaño de h (el intervalo de tiempo). Si usamos un h mas pequeño, el resultado va a ser mas preciso, pero van a ser necesarios mas cálculos para encontrar el valor de la posición.

El algoritmo en Python

Veamos como se traducen las ecuaciones anteriores para el caso de un modelo con una sola partícula, en Python.

class ParticulaSimple():
   def __init__(self, x0, y0, vx0, vy0, masa):
      self.x=x0
      self.y=y0
      self.vx=vx0
      self.vy=vy0 
      self.t=0
      self.masa=masa
      
   def get_force(self):
      '''
      Devuelve la fuerza a tiempo self.t.
      '''
      ...
      return force_x, force_y

   def update(self, h):
      t, x_prev, y_prev= self.t, self.x, self.y,
      vx_prev, vy_prev=self.vx, self.vy
      masa =  self.masa
      #Obtener la fuerza a tiempo t
      fuerza_x, fuerza_y=self.get_force()

      #Actualizar el tiempo, posición 
      #y velocidad usando el método de Euler.
      #Actualiza a tiempo t+h
      self.t = t+h
      self.x +=vx_prev*h
      self.y +=vy_prev*h
      self.vx += (fuerza_x*1.0/masa) *h
      self.vy += (fuerza_y*1.0/masa) *h

El código es bastante simple. En caso de ser más de una partícula, se debe iterar sobre todas las partículas. Usando librerías como numpy todo esto puede hacerse en una sola instrucción (multiplicando matrices por vectores). Pero eso no importa ahora.

Una parte clave del algoritmo es la función get_force, que devuelve las fuerzas en la dirección x e y. Esta función puede depender del tiempo, y en situaciones mas complejas puede depender de la velocidad (por ejemplo, la fricción es proporcional a la velocidad) o también puede depender de la posición (por ejemplo, la fuerza que hace un resorte depende linealmente del estiramiento del resorte).

Para ejemplificar muestro tres tipos de fuerzas:

Gravedad cerca de la tierra

Esta fuerza es la fuerza que experimentan todos los objetos cercanos a la superficie de la tierra. Es una fuerza constante, con dirección "hacia abajo".

...
   get_force(self):
      #La constante gravitatoria es un valor 
      #que depende solamente del planeta
      #donde se está parado. 
      #Para la tierra es g=9.8 m/s^2
      #Para la luna es g=1.6 m/s^2
      
      g=9.8
      return 0, -self.masa*g  #La fuerza es vertical
      #, apuntando hacia abajo(y<0 es abajo)

   ...

Fuerza gravitatoria general

Si el objeto en cuestión se encuentra alejado del planeta, la fuerza depende de la distancia al centro del planeta. La dirección de la fuerza es directamente apuntando al centro del planeta.

...
   get_force(self):
      #En este caso, la fuerza depende 
      #de la distancia al planeta y 
      #de la masa del mismo. 
      from math import sqrt
      #Un planeta en la coordenada (0,0)
      planetaX, planetaY= 0, 0 
      #Un planeta de la masa de la tierra
      k=3.98*10^14 

      distancia_X=planetaX-self.x
      distancia_Y=planetaY-self.y
      distancia_al_cuadrado=distancia_X*distancia_X\\
         +distancia_Y*distancia_Y

      F_magnitud=k*self.masa*1.0/distancia_al_cuadrado

      x_dir=distancia_X/sqrt(distancia_al_cuadrado)
      y_dir=distancia_Y/sqrt(distancia_al_cuadrado)

      return F_magnitud*x_dir, F_magnitud*Y_dir

   ...

Fricción de aire

Esta fuerza es una fuerza que depende de la velocidad. Para velocidades pequeñas la dependencia es lineal y puede programarse de la siguiente manera:

...
   get_force(self):
      #El coefficiente de fricción 
      #es un indice de cuanta fricción hay
      # si es 0 no hay ninguna fricción 
      #(la fuerza de fricción es siempre 0)

      fric_coef=0.1
      return -fric_coef*self.vx, -fric_coef*self.vy
   ...

Por razones que no voy a explicar ahora, esta fuerza no funciona muy bien con el método de Euler. Pero se puede usar si se mantiene el coeficiente de fricción muy chico o el paso de tiempo suficientemente pequeño. Lo mejor para un juego es probar distintos coeficientes hasta encontrar un valor que dé resultados plausibles.

Errores

Este método, como cualquier otro método de integración numérica, tiene errores. Para mostrar la diferencia entre el método exacto y el método aproximado voy a usar el ejemplo de la gravedad cercana a la tierra, que tiene solución exacta. Supongamos que un personaje de un juego de plataformas viene corriendo a 7 metros por segundo, y salta adquiriendo la misma velocidad. La velocidad inicial es 7 m/s. vertical y 7 m/s horizontal La trayectoria del personaje va a estar dada en forma exacta por:

Comparemos la solución exacta con la solución numérica usando h=0.05

Comparación de resultados para una fuerza constante en dirección vertical.

Claramente hay un error. Generalmente, para juegos este tipo el resultado sea suficiente, ya que el movimiento es cualitativamente correcto y el algoritmo usado es rápido.

Si se usa un h mas chico, el error va a ser menor (pero van a ser necesarios más FPS del modelo). Existen otros algoritmos que resultan en valores mas precisos para iguales valores de h.

Aun más, en algunas aplicaciones el método de Euler no funciona adecuadamente. Para estas aplicaciones es necesario utilizar otros algoritmos como Verlet Velocidad.

Conclusiones

Quizá la matemática de estos algoritmos sea un poco complicada. Pero programarlos es casi trivial. Existen algunas aplicaciones en las cuales el paso de tiempo h necesario para tener un resultado adecuado es demasiado pequeño, con lo cual se deben utilizar otro tipo de métodos de integración.

En una aplicación normal, la fuerza y velocidad varían según las instrucciones del controlador. En cada paso de tiempo, se llama a la función update del modelo para actualizar las posiciones y al update de la vista para utilizar las posiciones para ubicar los sprites en pantalla. A pesar de que en el modelo utilizo unidades "reales" como metros, en la vista estas unidades se transforman en pixels de pantalla.

Por ahora, para explicar Steering Algorithms, es suficiente con este método de integración. En el próximo post voy a explicar como se crea un controller que utilize fuerzas para dirigir un vehiculo a su destino.

MVC en la creación de videojuegos II - Esquema general

noreply@blogger.com (2b) — Fri, 04 Dec 2009 23:35:00 +0000

En el post anterior expliqué la razón que tuve para utilizar MVC en mi proyecto de inteligencia artificial. Pero si alguien leyó el post completo, seguramente el final fue anticlimático, por no explicarse nada concreto. En este post me encargo de dar una vista a ojo de pájaro de como implementé un sistema MVC. La idea me surgió gracias al tutorial de sjbrown para escribir juegos en pygame (en ingles), por lo que hay varias similitudes. Sin embargo esa guia es un tutorial básico de pygame, que no implementa mucho mas que lo mínimo y necesario para entender el sistema MVC con Mediador. Como expliqué en el anterior post, la idea es hacer un sistema para implementar algoritmos de inteligencia artificial (IA), pero siempre con la creación de videojuegos en mente.

La primer versión de mi programa se pude representar esquemáticamente de la siguiente manera:

Esquema MVC general para un sistema de videojuegos. (click para agrandar)

El Modelo

La parte mas importante de este programa es el modelo, por ser (junto a la IA) la razón de la existencia de todo el programa. Esencialmente es una simulación física. Dentro de lo que son las simulaciones físicas, este modelo es por el momento un simulador de dinámica molecular. Básicamente un conjunto de partículas puntuales que tienen posición, velocidad y fuerzas. Hay varias formas de implementar esto, y para muchas partículas es uno de los puntos críticos de eficiencia del sistema.

La función del modelo es actualizar las posiciones y velocidades de todas las partículas en cada frame. También permite acceder agregar, quitar y acceder a las partículas y aplicarle fuerzas.

Por el momento, el modelo es 2D. Pero puede ser fácilmente adaptado a 3D.
Con este modelo se pueden implementar juegos de varios tipos: Shooters, Tower Defense, Pacman, FPSs a la antigua como el Wolfenstein y sidescrollers. Pero en general va a ser necesaria una abstracción del concepto de "Mapa" y mas adelante de "cuerpo rígido" que incluya la posibilidad de colisiones para realizar juegos con física mas avanzada.

La Vista

La vista es una representación del modelo. Actualmente hay dos vistas, una vista gráfica y una vista que solamente almacena los valores del modelo en un archivo de texto. La primera es la pantalla gráfica que todos conocemos y la segunda es utilizada para hacer un análisis mas detallado del modelo y su correcto funcionamiento.

En cada cuadro, la representación gráfica se encarga de obtener directamente del modelo la información necesaria para actualizar la pantalla. Por una razón de eficiencia, la vista accede al modelo directamente.

La vista tiene también una "cámara" que abstrae las coordenadas del modelo de las coordenadas de la pantalla. La cámara es una simple transformación de rotación, translación y escala que convierte de las coordenadas del modelo a las coordenadas de la pantallas. La cámara puede ser manipulada en tiempo real para hacer zoom, rotaciones y translaciones.

La vista actual es 2D, implementada en pygame, por ser lo mas simple. Manteniendo la misma interfaz, se puede realizar una implementación en Java o incluso una implementación 2D+1 (2D isometrica con una tercer dimensión falsa) utilizando pygame mismo o mejor aun python-ogre u otra librería 3D para python.

Actualmente, debido a que pygame posee una implementación, la colisión entre objetos se calcula en la vista. En el futuro esta funcionalidad se va a pasar al modelo, agregando el concepto de "forma" al mismo. La colisión solo se usa por el momento para funciones del mouse y otros controladores. No hay colisiones estrictas (o sea, las partículas pueden superponerse).

El Procesador de Eventos

El procesador de eventos es una implementación del patrón de diseño Mediador. Este objeto es un mensajero que media en la comunicación entre todas las partes del sistema. Es muy importante para generar una aplicación modular y de comportamiento altamente configurable. Este patrón de diseño se suele utilizar por ejemplo para programar GUIs, donde uno crea widgets que generan eventos al ser activados.

Utilizando el procesador de eventos, se pueden registrar tipo de eventos, que son asociados a funciones que "escuchan" estos eventos. Durante la ejecución del programa, los distintos componentes del programa publican eventos en el procesador de eventos, el procesador de eventos se encarga de distribuir estos eventos a las distintas funciones registradas.

Por ejemplo, se puede asociar una función que termina el programa para que se ejecute cuando se publique un evento "Tecla escape apretada", durante la ejecución del programa; cuando el usuario presione la tecla escape, el controlador de teclado publicará el evento en el procesador de eventos y el programa terminará. La ventaja de este esquema es que el teclado no tiene que conocer ningún detalle del resto de los componentes, ni quién escucha el componente. Por otro lado, se puede cambiar el comportamiento del programa fácilmente sin afectar los componentes involucrados, simplemente cambiando qué objeto escucha qué tipo de eventos.

La implementación básica del procesador de eventos no distingue entre tipos de eventos (todos los componentes escuchan todos los eventos). Mi implementación agrega "tipos de eventos". En el futuro tengo planeado implementar el concepto de prioridad y orden de eventos (el orden en que se llama a las AI puede ser importante, como descubrí recientemente).

Los controladores

Los controladores son objetos que manipulan el modelo. En un diseño general del patrón MVC un controlador puede acceder a la vista y al modelo directamente. En la práctica depende del controlador. Yo intenté mantener los acoples directos entre MVC al mínimo necesario, utilizando el Procesador de Eventos donde fuera posible.

El mouse y el teclado

Los controladores obvios son el mouse y el teclado. El mouse es por el momento el único objeto que requiere acceder a la vista en forma directa. Mas allá de eso, ambos controladores son completamente basados en eventos. En la sección de Procesador de Eventos explico las funciones.

En cada update del mouse, el objeto lee la posición del mouse y el estado de los botones y de haber alguna actualización, envía un mensaje utilizando el Procesador de Eventos. El mouse recibe del sistema operativo, posiciones en coordenadas de la pantalla, por esta razón se necesita el View para convertir estas coordenadas a coordenadas del modelo.El mouse emite eventos cuando se presiona un botón, cuando se lo deja de presionar y cuando se mueve el mouse. Cada botón tiene un tipo de evento distinto, así hay eventos "BUTTON_1_DOWN", "BUTTON_1_UP", "BUTTON_2_DOWN", etc.

El teclado es puramente basado en eventos. Genera mensajes indicando si se ha presionado/soltado una tecla en particular del mouse. Se emiten mensajes cuando se presiona una tecla y cuando se la suelta. En el mismo mensaje se indica si hay teclas modificadoras (ctrl, shift, alt) presionadas. Cada combinación de teclas tiene un tipo de evento distinto.

La inteligencia artificial

Este objeto es una abstracción del "cerebro" de las entidades del modelo. No es obvia la razón por la que la IA es un controlador en lugar de ser parte del modelo. Se puede pensar que la IA es parte de las reglas del modelo. Así como en el modelo las fuerzas modifican en forma determinista las posiciones de las partículas, uno puede pensar que la inteligencia artificial es una regla más, que modifica el modelo en forma determinista. Esta forma de ver la IA es obvia en reglas simples como los Steering Algorithms (que voy a explicar en futuros posts). Pero a medida que uno usa técnicas de IA mas elaboradas (redes neuronales, partículas), esta forma de ver las cosas se torna menos obvia. Aun mas, separar la IA del modelo es atractivo por varias razones:

Facilita simular el desconocimiento que tiene una IA del mundo, si la IA fuera parte del modelo sería muy tentador hacer IAs omniscientes.
La IA se maneja en escalas temporales distintas al modelo. Por un lado, es útil que el modelo se actualice con la mayor frecuencia posible, por ejemplo 60 cuadros por segundo. Es fácil darse cuenta que una persona no tiene reacciones inmediatas, si un enemigo aparece en el rango de visión, la persona tardará en reaccionar (por ejemplo dispararle). Es sumamente atractivo transladar esta limitación a las IA, para ponerlas en igualdad de condiciones. En lugar de llamar al update de las IA 30 veces por segundo se puede llamar 10 veces por segundo, simulando un retardo en las reacciones de la IA similar al de un humano.
Una misma IA puede actuar con los mismos algoritmos sobre distintos modelos. Asi, si en el futuro hago un modelo 3D, las IA pueden permanecer (en muchos casos, pero no todos) sin cambio y aun ser útiles.
La IA no es tan prioritaria como el modelo. Se pueden aplicar técnicas avanzadas sobre las IA para balanceo de carga del CPU. [1] Ya que la evaluación de las IA no es prioritaria en ciertos contextos.

Por una razón de eficiencia, la IA posee acceso directo al modelo.

Para explicar el esquema MVC mas fácilmente supuse que hay una sola IA en este post. En realidad hay muchos tipos de IA implementadas en mi proyecto (10 al momento de escribir esto), todas pertenecientes a la categoría "Steering Algorithms". En un post futuro voy a explicar en detalle eso.

El reloj de sistema

Este objeto es el "corazón" del programa. Es un objeto muy simple que solamente se encarga de generar eventos indicando un nuevo frame del programa. Es una abstracción ingeniosa del bucle principal del programa. En lugar de hacer un bucle infinito en el cual se llama a cada objeto del programa, se generan eventos a una frecuencia dada, que luego son distribuidos por el procesador de eventos entre los distintos componentes que requieren un update periódico. Para inicial el programa, se ejecuta el reloj de sistema. Para pausar el programa, se detiene el reloj.

En la implementación actual del programa el reloj de sistema emite un mensaje "TICK" en cada frame del programa, a un ritmo predefinido. En próximas implementaciones, el reloj de sistema va a tener distintos tipos de TICK para distintas frecuencias, permitiendo actualizar distintos componentes del sistema a distintas frecuencias. Así será posible actualizar, por ejemplo, el modelo a 40 FPS, el view a 30FPS y los controllers a 10FPS.

Conclusión

Como dije al principio, esta es una vista general del programa que estamos programando. El código se puede descargar del repositorio SVN público.

En próximos posts voy a explicar mas concretamente varios puntos que no necesariamente están relacionados con el esquema MVC. Voy a explicar las bases de una simulación física de dinámica molecular, incluyendo algunos algoritmos concretos, voy a explicar también qué es un Steering Algorithm. Volviendo al tema MVC también voy a explicar algunos problemas que encontré en las implementaciones iniciales y como fuí solucionandolos.

[1] "An Efficient AI Architecture Using Prioritized Task Categories" Alex W. McLean - AI Game Programming Wisdom 1. Capitulo 6-3 p290 [volver]

MVC en la creación de videojuegos - Introducción

noreply@blogger.com (2b) — Mon, 30 Nov 2009 18:56:00 +0000

En el último tiempo, estuve muy interiorizado en la programación de aplicaciones web utilizando Frameworks como Ruby on Rails y Joomla Framework (me refiero al Framework PHP detrás del CMS). Ambos tienen una característica en común, que están diseñados siguiendo una filosofía Model-View-Controller (Modelo-Vista-Controlador).

Este tipo de arquitectura se basa en separar una aplicación en tres módulos independientes. El Modelo son los datos que se manejan en la aplicación, las Vistas son las distintas formas de presentar los datos al usuario, el Controlador es la forma que tiene el usuario de manipular los datos. También se suele agregar un Mediador que no es mas que un objeto que se encarga de coordinar la comunicación entre los componentes. De esta forma se evitan dependencias fuertes entre las interfases de cada componentes, y mas importante, se genera una reusabilidad sorprendente en las aplicaciones que programamos.

Hace poco, con un amigo decidimos empezar un pequeño proyecto para probar distintas técnicas de inteligencia artificial en tiempo real. La idea es comenzar con los clásicos Steering Behaviors de Craig Reynolds, extenderlo a Flocking y Squads y después implementar técnicas mas avanzadas (aunque tampoco totalmente novedosas) como Automatas Celulares, para simulación de fenómenos físicos como explosiones, y filtros de partículas para simular el conocimiento que tiene la AI del mundo que la rodea. Todo esto, ejemplificado con pequeños juegos que muestren las técnicas. Voy a ir mostrando en este blog las distintas técnicas, ejemplificandolas con Applets cuando sea posible.

El primer problema que hace años que no programo en Java y no tenía ganas de empezar inmediatamente a refrescar esos conocimientos. En lugar de eso me propuse utilizar Python, un lenguaje que permite programar en forma veloz, generalmente para realizar prototipos de programas que luego pueden ser reimplementados en lenguajes "de gente seria" o, mi preferida, optimizados implementando solamente partes críticas en lenguajes de mejor rendimiento.

Otra ventaja que tiene Python, es la posibilidad de crear Applets Java mediante la utilización de Jython. Utilizando esta implementación de Python en Java, es posible compilar código Python puro (que no depende de bibliotecas externas) e incluso utilizar bibliotecas externas de Java (imprescindible si se quiere mostrar gráficos y acceder al mouse).

Mientras tanto, y hasta tener algo para mostrar en este blog, voy a utilizar Python para programar, Pygame para acceder al hardware (mouse, teclado, display y reloj del sistema) y numpy para los cálculos que requieran mayor eficiencia.

Viendo ese spaghetti de requerimientos, necesitábamos asegurarnos una buena separación de lo que es Pygame y Numpy (librerías externas que no pueden ser llevadas a Java) de lo que es código Python puro. Y a la vez, necesito que sea fácil introducir Java y sus bibliotecas cuando decidamos implementar Applets.

Elegir una arquitectura MVC pareció la solución mas atinada. De esta forma, el View principal y los Controllers del mouse y el teclados serían implementados usando Pygame, heredando de una clase abstracta general. En un futuro se puede reimplementar la misma clase abstracta en Java. El modelo y el mediador, por otro lado, no tendría ninguna dependencia de este tipo de librerías.

Veamos ahora la estructura mas concreta y los dilemas típicos que surgen al utilizar MVC para juegos. Voy a utilizar como ejemplo la aplicación que tengo desarrollada hasta el momento. Por supuesto que iré refactorizando en el futuro y cuando sea necesario explicaré los cambios en este blog. El código al día se puede descargar en el repositorio SVN, no soy ningún gurú de programación, con lo cual se aceptan sugerencias e ideas.

En el siguiente post voy a explicar a grandes rasgos como diseñé la primer versión de la aplicación (Casi un esqueleto con capacidades mínimas en el momento de escribir este post) utilizando MVC.

Ver siguiente post.

Tarde pero seguro: Sidewiki para Google Chrome

noreply@blogger.com (2b) — Sat, 07 Nov 2009 08:09:00 +0000

Es raro esto de usar Google Chrome.

El navegador en sí es rápido, pero le faltan muchos de los agregados de Firefox. Seguramente ambas cosas estén relacionadas. Y encima uno se siente un ciudadano de segunda en el mismo mundo Google, ya que varias aplicaciones que google desarrolla tardan en estar disponibles en Chrome.

Ahora llegó Sidewiki para Google Chrome. No es lo mismo que en Firefox, donde el sidewiki es realmente un sidebar. Esta versión es un bookmarklet que se arrastra de la página de ayuda de Chrome hasta la barra de bookmarks (la barra se activa con ctrl-b en Chrome). Una vez puesto el bookmarklet en la barra, uno puede activar un "popupwiki" donde se tiene las misma funcionalidad que en el sidewiki... algo es algo.

Para ver mis, pocos, comentarios en sidewiki: http://www.google.com/profiles/ezequiel.pozzo#sidewiki

Lo concreto y lo etereo

noreply@blogger.com (2b) — Sun, 27 Sep 2009 08:21:00 +0000

Acabo de leer una nota de Horacio Verbitsky y una de Eliseo Verón. Veo por un lado que hay una repetición de las mismas consideraciones entre los artículos de opinión que se oponen a la ley. Y por el otro, entre los que están a favor, siempre encuentro nuevos argumentos y puntos de vista, en particular encuentro que se focalizan en puntos concretos y los analizan.
La nota de Verbitsky tiene una primer parte que gira alrededor de los argumentos legales que se le hace a la ley. Y luego los refuta en forma concreta y documentada. Luego sigue con una consideración sobre la influencia de los medios en la sociedad y el punto de inflexión entre la relación Clarín-gobierno. Y termina con una pequeña reseña histórica sobre el proceso mediante el cual, parafraseando a los genios de marketing de TN "1800 cables y varios canales 'desaparecieron'". Esta ultima parte me hizo recordar de mi tan querido "Cablin" y me acordé que Morgado era conductor de ese canal.

La nota de Verón es mas académica. La cuestión de fondo es la que ya se ha dicho mil veces "los K son malos, autoritarios y están atacando al grupo Clarín". Pero en el caso de Verón es justificable que haga este análisis ya que Verón es un semiologo, con lo cual es natural que haga un analisis de los significados.

Es importante recalcar, que un análisis de significado es en mayor o menor medida subjetivo. Y mas alla del enfoque académico, y la prosa que recuerda a un libro de filosofía, el contenido concreto no es nada que no se haya dicho y escrito miles de veces en forma mas chapucera (ver Joaquín Morales Solá o Silvina Walger en un post anterior)

Algunos puntos para destacar:

[Darle el dinero a los pobres no ocurrió] y los 600 millones de pesos fueron usados para pagar a la AFA:

Este es el viejo argumento que esconde los supuestos de que el fútbol es un negocio que da perdida. Yo no tendré una prosa tan refinada como la del semiólogo, pero se notar cuando se esgrime un argumento pedorro que ya fue criticado. Veremos que pasa en unos años, cuál es el saldo del negocio del fútbol cuando se hayan vendido las licencias, publicidad y demás. Por ahora, es un simple golpe de efecto.

a los componentes del tercio privado sin fines de lucro (comunidades, entidades no gubernamentales, sindicatos, etc.) difícilmente se los puede imaginar adoptando actitudes de crítica hacia un gobierno que les ha otorgado la explotación de ciertos medios, y la liberación de numerosas licencias permitirá colocar en el tercer tercio, comercial privado, a buen número de aliados actuales y potenciales del kirchnerismo.

Acá el semiólogo abandona toda pretensión de explicación y simplemente tira el cliché de "se van a quedar con los medios" sin mas. No trata de analizar la autoridad de aplicación, o considerar los mecanismos precisos mediante los cuales un gobierno corrupto podría coercionar a los licenciatarios. El postula "difícilmente se los puede imaginar" y "permitirá [beneficiar a muchos aliados] actuales y potenciales del NK" y deja el resto a la imaginación del lector. Seguramente un lector convencido pueda llenar los blancos de este razonamiento con mil fantasías y expectativas, pero uno esperaría que el rol de un analista es analizar, y no estimular la imaginación.

Todo discurso es sintomático y el de Cristina Kirchner no escapa a esta regla.

Supongo que el lector promedio del diario Perfil entiende perfectamente lo que esa frase significa.

Considerados en sí mismos, nadie puede estar en desacuerdo con estos principios, que son la base de las legislaciones que reglamentan el campo de los medios de comunicación en la mayoría de los países “centrales” y particularmente en los países de la Unión Europea, cuya legislación fue ampliamente utilizada por los redactores de la ley aprobada en la Cámara de Diputados. Pero es un grave error olvidar que las consecuencias de la aplicación de una ley no pueden ser evaluadas sin tomar en cuenta la cultura política del país en que se la discute y las metodologías que se ejercitan desde el Ejecutivo.

El problema de esta frase es doble. Primero por ser una falacia de ataque ad-hominem, luego de este párrafo se procede a explicar que el gobierno tiene malos motivos para impulsar la ley. Yo digo que si bien el fin no justifica los medios, los medios tampoco refutan el fin. Podemos atacar todo lo que se quiera los motivos ulteriores de la presidenta y como hace las cosas, pero eso en ningún momento es una refutación de la ley en si. (mas allá de algún punto concreto que se pueda llevar a la justicia o se pueda demostrar violatorio de las reglas de juego de la democracia)
El segundo problema de esta frase es que se centra, básicamente, en argumentar que no somos un pais Europeo. No explica específicamente las diferencias entre la cultura política de Argentina y un pais Europeo (también lo deja a la imaginación del lector), pero algo es claro: los problemas de la cultura política de este pais no van a terminar con este gobierno ni con el siguiente, con lo cual es poco constructivo utilizar ese argumento para refutar los puntos objetivos de una ley. Porque se desprende de allí que para tratar esta ley tendríamos que tener un sistema de políticos probos e interesados por el bien común, un acceso libre a la información y una visión clara y no parcial sobre el asunto. O sea, no podríamos sancionar la ley nunca.

Lo que hay que entender es que estas tres lecturas se adicionan, y que el proceso político en curso (como todo proceso político-social) es multidimensional. Focalizarse en los contenidos ideológicos del proyecto, descuidando las otras dimensiones (todas las intervenciones de la señora presidenta han estado destinadas a empujar en esa dirección) es precisamente caer en la trampa de la metodología kirchnerista. Ese parece ser el caso de los socialistas –si hacemos de su actitud la evaluación más benévola posible, a saber: que han sido políticamente ingenuos.

Acá el escritor parece olvidar que además de los contenidos ideológicos y los contenidos "de otras dimensiones" (o sea, consideraciones propias del escritor que apelan a millones de argumentos aledaneos), además de esos puntos, están los puntos concretos, objetivos y numéricos de la ley. El intelectual se pierde en sus propias consideraciones y llega a una conclusión que olvida lo fundamental en una acción: los resultados concretos y materiales que de ella se desprenden. Quizá sea esto una deformación profesional. No lo se.
Por lo tanto, hay una evaluación mas benévola que la que hace el escritor sobre el voto socialista. Esta evaluación es considerar que han incurrido en el pragmatismo de votar una ley que corresponde cuantitativamente (además de ideológicamente) con su propio parecer y con las leyes que ellos mismos han defendido en el pasado. Esto es todo lo contrario a ser ingenuo. Ser ingenuo sería, luego de varios intentos fallidos de promover una ley de la democracia, frenar el avance de esta ley argumentando que "algo huele mal". Algo siempre va a oler mal en este país lamentablemente.

En la oposición, todos se han vuelto un poco semiólogos con este gobierno. Tratando de analizar los significados detrás de cada discurso, acción o gesto de la presidenta y el ex presidente. Pero no olvidemos que mas allá de los motivos ulteriores, están los hechos concretos.

Y en ese juego, muchos fallan en explicar de que manera concreta esta ley puede llegar a ser usada por el gobierno, para en el plazo de 2 años tomar las riendas de las telecomunicaciones argentinas y utilizarlas a su favor. Fallan en explicar como un gobierno con una reputación en descenso puede lograr en 2 años crear y aceitar una maquinaria que le llevó al grupo Clarín 30 años de construcción, para luego llevar a cabo su supuesto plan de ser reelectos en las próximas elecciones, sin encontrar en el camino ninguna oposición de parte de diputados, senadores, jueces, partidos políticos opositores. En todo este juego etéreo de argumentaciones, retórica e "hipnopedia" (gracias Verbitsky) se olvidan dar dos pasos al costado y analizar lo concreto y material.

El espejo

noreply@blogger.com (2b) — Tue, 22 Sep 2009 05:38:00 +0000

Hoy leí un articulo en un blog que me dejó pensando

A mi me parece interesante el concepto de que las propuestas son generalmente universales, porque corresponden a lo que el político cree que los votantes piden. La campaña de un político en tiempo de elecciones es una épica creada por un asesor de marketing. El político en tiempo de elecciones es un espejo de las esperanzas del electorado.

Es así, que votar por "propuestas" puede ser un acto de vanidad: Una persona puede cometer el error de votar al candidato que mejor refleja sus expectativas, sin tener en consideración lo razonable de sus expectativas o qué tan probable es que sean satisfechas. Por esto es mas importante ver el desempeño de los candidatos en actos concretos fuera de campaña que la campaña en si.

Me parece que hay algo que está perdido (si es que alguna vez lo hubo) en el proceso democrático, y es el uso de la información. No parece haber en la población una necesidad de datos concretos. Los programas políticos actuales, por ejemplo, son mas bien una serie de entrevistas y encuestas. Las notas periodísticas se enfocan mas en el lado humano de los hecho, lo subjetivo, que en el contexto cuantitativo. En esta situación, no es extraño que un candidato apoye su campaña en lo general y ambiguo mas que en lo concreto.

Internet, y estoy consciente de que esto es un cliché, es una herramienta que puede mejorar notablemente el acceso a la información. Las redes sociales y los blogs permiten desenterrar en forma eficiente los cadáveres que cada político con trayectoria tiene en su haber. Uno podría soñar con un sitio utópico de internet que permita obtener un CV "no autorizado" de cada político, o una serie de links para adquirir un contexto sobre una determinada situación. Es en parte esa idea que me llevó a escribir este post.

Pero hay una ingenuidad en ese concepto. Porque lamentablemente, en cierto modo no es tan importante la posibilidad de acceder a la información si no hay voluntad de utilizar esa información. La vanidad es la excesiva confianza en la propia capacidad. Y una persona que es vana intelectualmente, no siente la necesidad de buscar la información fuera de su propia persona. A una persona vana le basta con su ser y un espejo para poder tomar todas las decisiones.

2090

noreply@blogger.com (2b) — Sun, 20 Sep 2009 18:24:00 +0000

¿Que significa el consenso? Si yo no puedo ceder a mi enemigo sin que sea puesta en duda mi integridad y se me acuse de estar cooptado.

¿Que significa consensuar? Si no puedo otorgar sin que esto sea visto como un signo de debilidad, una marcha atras, un mero "juntar voto".

Por qué esa contradicción de gritar a cuatro vientos, y de forma espontánea, "Alguien tiene que ceder", salir a la calle a clamar "alguien tiene que ceder", pero nunca ceder.

Son épocas como estas en las que me siento desesperanzado. Veo como la opinión de personas que se supone que deben iluminar sobre la realidad se tiñe de una antiintelectualidad trágica, que tilda de "monos y progres" a quien da su voto sincero. Un párrafo después de vanagloriarse de la deshonestidad de discutir las personas antes que las ideas. Sin siquiera detenerse a explicar ningún tipo de afirmación, por mas increíble que sea, justamente porque la credibilidad es hoy en día una cuestión meramente subjetiva.

Estamos en una época donde las leyes ya no se discuten por sus artículos, si no que se discuten con nombre y apellido y esgrimiendo consideraciones y argumentos infalsables. Los artículos de opinión periodística son un trabajo de construcción Ptolomeica, que apelan a lo que sobreentiende (pero nunca se demuestra), a lo que no se define (pero se repite hasta el hartazgo) y a lo que no puede ser refutado (y sin embargo se lo considera intelectualmente honesto, por alguna magia de la retórica).

Mi teoría es que estamos gestando una neolengua. Donde dialogar significa "callar"y ceder significa "resistir". Donde la oposición solo puede oponerse, y el que acompaña solo puede ser cómplice. Donde la magnitud de la evidencia necesaria disminuye proporcionalmente a la magnitud de la afirmación esgrimida.

Un país donde no se admiten los principios, solamente las alineaciones.

La necesidad de OpenID

noreply@blogger.com (2b) — Sun, 23 Aug 2009 08:20:00 +0000

¿Cuantas veces uno llega a un sitio que podría resultar interesante, pero lo abandona en el momento de registrarse?

En algunos sitios, el proceso de registrarse surge como una manera de garantizar privacidad y permitir personalización. Sin embargo en otros sitios, se exigen datos privados (email, nombre, dirección) sin que haya una necesidad verdadera. Un ejemplo de sitios donde es necesario identificarse puede ser un webmail, para mantener la privacidad del correo. Un ejemplo de un sitio donde es innecesario es un diario online, donde no hay razón para exigir al usuario identificarse antes de leer una noticia.

Sea cual sea la razón, el proceso de registración implica varios puntos negativos para el usuario:

Pérdida de tiempo en el proceso de registrarse.
Entregar información privada a desconocidos.
Encontrarse ante la situación de tener que manejar una cantidad cada vez mayor de nombres de usuario y contraseñas o...
Tener que conformarse con recurrir a un numero reducido de contraseñas que son reutilizadas en distintos sitios.

El primer punto es solo una perdida inmediata, pero los siguientes tres puntos pueden llevar a una pérdida mayor de datos (hackeo de cuentas).

Esto hace que uno se plantee muchas veces evitar conocer nuevos sitios. Personalmente, me encontré en la situación de descubrir 5 redes sociales sobre un mismo tema pero finalmente entrar solo a un par, para evitar el problema de tener que registrarme 5 veces.

Es aquí donde entra OpenID. OpenID es una tecnología reciente, que permite a los usuarios obtener una identificación reutilizable. La idea es que uno registra su nombre de usuario y password en un sitio de confianza, y luego lo utiliza para ingresar en cualquier sitio que soporte esta forma de identificación.

Asi, por ejemplo, uno puede crear un OpenID en Google Accounts y luego utilizarlo para ingresar a Scribd, StackOverflow, StumbleAudio, o cualquier otro.

Es asi que cuando llego a uno de estos sitios, especifico que poseo un OpenID de Google, para luego ser redirigido a Google Accounts, donde verifico mi nombre de usuario y contraseña. Una vez que termina el proceso de identificación, Google me envía nuevamente al sitio inicial.

En forma efectiva, OpenID es una tecnología para delegar el proceso de registro e identificación de usuarios a una empresa en la que el usuario confíe.

Pero... ¿No es poner todos los huevos en una sola canasta?

Efectivamente, uno puede utilizar esta tecnología para tener un solo usuario/password. En caso de que alguien descubra estos datos, puede ingresar a cualquier sitio donde el usuario esté registrado.

Sin embargo, en la actualidad la situación no es mejor. Los métodos de recuperación de password mediante una cuenta de email presentan la misma vulnerabilidad. Un intruso que descubra el nombre de usuario y password de tu cuenta de email puede usarlo para "recuperar" la contraseña de cualquier sitio donde estés registrado con ese email. Mucha gente se preocupa en mantener distintos usuarios y contraseñas para miles de sitios, pero usa el mismo email en cada una de las cuentas, lo que implica que efectivamente solo tienen un password (el de la cuenta de email) mediante el cual se puede acceder a todas las otras cuentas.

La solución es... no poner todos los huevos en una sola canasta. Esto significa que uno puede crear distintos OpenIDs y utilizarlos en distintos contextos. Uno puede tener un OpenID para utilizar en sitios prescindibles, con un password fácil de recordar, y tener un OpenID para usar en sitios donde la seguridad es crítica.

OpenID es una herramienta destinada a simplificar la vida del usuario e incrementar la seguridad en muchos aspectos. Pero no es una solución invulnerable.

¿Cómo conseguir un OpenID?

Eso es fácil, probablemente ya tengas un OpenID sin saberlo:

Si tenés una cuenta de Google (gmail, google docs, analytics, etc) o Yahoo ya tenés un OpenID.
Si tenés un blog en blogger o Wordpress, tu OpenID es la dirección misma del blog (Por ejemplo, ezequielpozzo.blogspot.com es un OpenID válido)

Pero también hay muchos otros proveedores de OpenID, en particular hay empresas cuya única función es proveer OpenID de manera segura.

¿Cómo instalar OpenID en mi sitio?

Eso depende del sitio. Si uno tiene un blog en blogger, es posible activar OpenID para permitir a los lectores dejar comentarios identificándose con su OpenID.

Pero todos los sistemas gestores de contenido como Joomla o Drupal y Frameworks como Django o Ruby on Rails tienen agregados que permiten soportar OpenID.

En otros posts voy a explicar otros planteos frequentes contra OpenID y como OpenID es parte de una serie de tecnologías como Open Social que otorgan mas libertad al usuario sobre sus datos privados e información personal.