Complejidad gramatical Sistemas-L Carlos Reynoso UNIVERSIDAD DE BUENOS AIRES http://carlosreynoso.com.ar

Objetivos (1/2) Comprender aspectos de la complejidad Definir complejidad gramatical Profundizar en modelos gramaticales de tipo sistemas-L Idem en jerarquía de la complejidad y sus autómatas Ejemplificar investigaciones en arquitectura, arte, antropología y ciencias sociales que usan formalismos semejantes Clarificar diferencias con modelos rizomáticos (Deleuze & Guattari)

Objetivos (2/2) Identificar recursos bibliográficos y examinar herramientas de modelado Experimentar y producir objetos novedosos Fachadas, caminos, edificios, ciudades o cosas complejas que haya en ella Proyectar transformaciones de objetos e híbridos estilísticos

Referencias Carlos Reynoso. 2006. Complejidad y caos: Una exploración antropológica. Bs. Aires, Editorial Sb Antropología Estudios culturales Lingüística-Semiótica Computación Inteligencia Artificial Modelos complejos Lenguajes Arquitectura de software Ciencias cognitivas Musicología http://carlosreynoso.com.ar

Referencias Reynoso, Carlos. 2010. Análisis y diseño de la ciudad compleja. Perspectivas desde la antropología urbana. Buenos Aires, Editorial Sb Capítulo 4, págs. 159-207

Referencias Libros de Prusinkiewicz-Hanan & Lindenmayer

Agenda Prehistoria – Freeman: chain coding Definiciones de sistema-L – Gramáticas Lenguajes artísticos Posicionamiento entre los sistemas basados en gramáticas (o reglas de reescritura de strings, o gramáticas basadas en formas) Tipos de sistema-L Software de modelado Ejemplos culturales Reconstrucción arqueológica, diseños, patrones de asentamiento, simulación musical, GIS, gramáticas culturales, diseño de edificios y plantas urbanas Conclusiones – Recursos – Desafíos – Trabajos

Prehistoria Chain coding (Freeman, 1961) Correspondencias entre cadenas de símbolos e imágenes Narasinham (1970s) – Primera aplicación Reconocimiento de patrones en fotografía aérea, reconocimiento de firmas, OCR Almacenamiento de datos gráficos y su comparación Examinemos la nomenclatura

Ejemplo – Chain coding Izquierda: Brújula de referencia Mesh o malla regular Cartesiana  22020200 Circular  221010 De intersección  221100

Ejemplos Generación de imágenes basadas en sistemas-L ...

Jerarquía de la complejidad Chomsky Gramáticas regulares (Tipo 3). Pueden consistir sólo de reglas de re-escritura de tipo Ab, o AbC. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas deterministas de estado finito. Estos autómatas no tienen memoria. Reconocen o generan lenguajes regulares. Gramáticas independientes de contexto (Tipo 2). Sólo tienen reglas de forma A, y por lo tanto no tienen restricción en cuanto a la forma que pueden tomar las reglas de producción de la derecha. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas no deterministas de almacén o de pushdown (PDA). Estos autómatas tienen una memoria limitada y pueden, por ejemplo, llevar a cabo una comparación. Reconocen o generan lenguajes independientes del contexto. Gramáticas sensibles al contexto (Tipo 1). Pueden tener reglas de forma A, donde  no es un elemento vacío. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas ligados linealmente. Poseen una memoria auxiliar semi-infinita, proporcional a la cantidad de elementos que deben tratar. Reconocen o generan lenguajes sensibles al contexto. Gramáticas irrestrictas (Tipo 0). Son idénticas a las anteriores, excepto por el hecho que  puede ser nulo. Corresponden a los lenguajes y conjuntos susceptibles de ser tratados por máquinas de Turing. Poseen memoria irrestricta y pueden efectuar cualquier computación. Reconocen o generan lenguajes recursivamente enumerables.

Lenguajes regulares Reglas de transición

Jerarquía de la complejidad Chomsky Gramáticas regulares (Tipo 3). Pueden consistir sólo de reglas de re-escritura de tipo Ab, o AbC. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas deterministas de estado finito. Estos autómatas no tienen memoria. Reconocen o generan lenguajes regulares. Gramáticas independientes de contexto (Tipo 2). Sólo tienen reglas de forma A, y por lo tanto no tienen restricción en cuanto a la forma que pueden tomar las reglas de producción de la derecha. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas no deterministas de almacén o de pushdown (PDA). Estos autómatas tienen una memoria limitada y pueden, por ejemplo, llevar a cabo una comparación. Reconocen o generan lenguajes independientes del contexto. Gramáticas sensibles al contexto (Tipo 1). Pueden tener reglas de forma A, donde  no es un elemento vacío. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas ligados linealmente. Poseen una memoria auxiliar semi-infinita, proporcional a la cantidad de elementos que deben tratar. Reconocen o generan lenguajes sensibles al contexto. Gramáticas irrestrictas (Tipo 0). Son idénticas a las anteriores, excepto por el hecho que  puede ser nulo. Corresponden a los lenguajes y conjuntos susceptibles de ser tratados por máquinas de Turing. Poseen memoria irrestricta y pueden efectuar cualquier computación. Reconocen o generan lenguajes recursivamente enumerables.

Lenguajes independientes de contexto Representación arbolada

Jerarquía de la complejidad Chomsky Gramáticas regulares (Tipo 3). Pueden consistir sólo de reglas de re-escritura de tipo Ab, o AbC. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas deterministas de estado finito. Estos autómatas no tienen memoria. Reconocen o generan lenguajes regulares. Gramáticas independientes de contexto (Tipo 2). Sólo tienen reglas de forma A, y por lo tanto no tienen restricción en cuanto a la forma que pueden tomar las reglas de producción de la derecha. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas no deterministas de almacén o de pushdown (PDA). Estos autómatas tienen una memoria limitada y pueden, por ejemplo, llevar a cabo una comparación. Reconocen o generan lenguajes independientes del contexto. Gramáticas sensibles al contexto (Tipo 1). Pueden tener reglas de forma A, donde  no es un elemento vacío. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas ligados linealmente. Poseen una memoria auxiliar semi-infinita, proporcional a la cantidad de elementos que deben tratar. Reconocen o generan lenguajes sensibles al contexto. Gramáticas irrestrictas (Tipo 0). Son idénticas a las anteriores, excepto por el hecho que  puede ser nulo. Corresponden a los lenguajes y conjuntos susceptibles de ser tratados por máquinas de Turing. Poseen memoria irrestricta y pueden efectuar cualquier computación. Reconocen o generan lenguajes recursivamente enumerables.

Jerarquía de la complejidad Chomsky Gramáticas regulares (Tipo 3). Pueden consistir sólo de reglas de re-escritura de tipo Ab, o AbC. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas deterministas de estado finito. Estos autómatas no tienen memoria. Reconocen o generan lenguajes regulares. Gramáticas independientes de contexto (Tipo 2). Sólo tienen reglas de forma A, y por lo tanto no tienen restricción en cuanto a la forma que pueden tomar las reglas de producción de la derecha. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas no deterministas de almacén o de pushdown (PDA). Estos autómatas tienen una memoria limitada y pueden, por ejemplo, llevar a cabo una comparación. Reconocen o generan lenguajes independientes del contexto. Gramáticas sensibles al contexto (Tipo 1). Pueden tener reglas de forma A, donde  no es un elemento vacío. Corresponden a los lenguajes y conjuntos que pueden ser tratados por autómatas ligados linealmente. Poseen una memoria auxiliar semi-infinita, proporcional a la cantidad de elementos que deben tratar. Reconocen o generan lenguajes sensibles al contexto. Gramáticas irrestrictas (Tipo 0). Son idénticas a las anteriores, excepto por el hecho que  puede ser nulo. Corresponden a los lenguajes y conjuntos susceptibles de ser tratados por máquinas de Turing. Poseen memoria irrestricta y pueden efectuar cualquier computación. Reconocen o generan lenguajes recursivamente enumerables.

Ejercicios: Comprensión de las Máquinas de Turing

Sistemas-L

Sistemas-L Aristid Lindenmayer – Sistemas-L, ca. 1968

Sistemas-L Gramáticas recursivas de crecimiento Smith, Prusinkiewicz: gráficos de tortuga Axioma: B Reglas: B F-[B]+B F FF

Sistemas-L En principio fue un modelo topológico No había monitores gráficos en 1968 Es posible aplicar una interpretación geométrica (p. ej. gráfico de tortuga*) *Inventado por Seymour Papert para Logo (1967) – Versión simplificada de LISP – Antecesor de StarLogo También interpretación sonora (música karnática en base a modelos D0L) Es un sistema de re-escritura, igual que una gramática chomskyana context-free Szilard y Quinton (1979): Teorema – Los sistemas D0L pueden generar fractales

Sistemas-L como gramáticas

Gramáticas - ¿No van más? Demostración de Stanley Peters y Robert Ritchie (1969) Aún los autómatas más simples son demasiado poderosos Chomsky abandonó las gramáticas ulteriormente Ahora se definen más bien constreñimientos (constraints)

Gramáticas vs Rizomas Deleuze & Guattari – Mil mesetas Rizomas análogos a colecciones de autómatas finitos igualitarios Gramáticas análogas a jerarquías Solamente representación ocasional en lenguajes independientes de contexto Los árboles nunca han sido aplicados (ni son aplicables) a lenguajes naturales Culturas “rizomáticas” China – Yingzao Fashi, esclavos del Zenj India – Pāṇini, código de leyes de Manu Eventuales usos de la metáfora en la teoría urbana posmoderna Conclusión obligada: Los autores no demuestran tener una imagen sólida de la lingüística chomskyana Idem en lo que respecta a los modelos de auto-correlación espacial La ejemplificación es antropológicamente ofensiva

Algunos tecnicismos Cuando se reescribe F o algunos de sus equivalentes, el sistema es “edge rewriting” Cuando se reescribe X, se habla de “node rewriting” Este último se utiliza generalmente para estructuras ramificadas. Analogía con percolación de vínculo [bond] y de sitio respectivamente Recursividad...

Modelos procesuales

Ejemplares teóricos Benjamin Colby – El Contador de los Días. Robert Randall – Modelo de toma de decisiones (pesca Samal). Young, 1980 – Modelo de decisiones de diagnóstico de enfermedad entre los Tarasco. Schoepfle, Burton & Morgan 1984 – Los Navajo y el desarrollo energético – Decisión económica bajo incertidumbre política.

Colby – Gramáticas culturales El contador de los días (1981) Los cuentos Ixil están regidos por una gramática. Idones o unidades narrativas. Cartas eidocrónicas Reynoso: Esta gramática no tiene valor predictivo.

Colby – Gramática cultural

Crítica de la GC de Colby Una gramática IC consiste (básicamente) en un conjunto de reglas de reescritura: O  SN+SV SN  A + N SV  V + SN O SN SV A N V SN A N Los fenomenólogos distorsionan la antropología

Crítica (Continuación) Un template de posiciones posibles no es una gramática. Una gramática independiente de contexto no puede generar un texto. Sólo puede generar frases. Un texto no se reduce a un conjunto de frases. Al no especificarse constraints complejos y conocimiento enciclopédico, el relato de una gramática simple no tiene coherencia. En el caso de la GC de Colby, el protagonista se puede morir primero y casarse después, escaparse sin haber sido atrapado, resucitar sin haber muerto.

Alan Turing [1912-1954] Problemas computables Máquinas de Turing – Modelos ideales Dispositivo de manipulación de símbolos que puede simular la lógica de cualquier computadora Proporciona una definición precisa de un algoritmo o procedimiento mecánico Sistemas-L – Modelo de autómata mucho más simple que las máquinas de Turing (aunque extensible) Ejemplo: Visual Turing – Prueba: multiplicar 2x2

Problemas formales Prueba de [Kurt] Gödel (1931) Escasa consecuencia práctica Problema de la detención (o decisión) (Entscheidungsproblem) Planteado por David Hilbert, 1928 1936: Alonzo Church, Alan Turing Es imposible decidirlo a priori, algorítmica y generalmente Inmensas consecuencias prácticas Problemas NP-completos, NP-duros, etc Elaboración de métodos inspirados en evolución y biología

Definición de problema (Hopcroft) Determinar si una expresión pertenece a un lenguaje (o si un elemento  a un conjunto) Gramática narrativa ixil de Benjamin Colby No se puede generar un texto con gramáticas independientes de contexto. Epistemología de la complejidad de Morin No define problemas ni objetivos – El “método” no establece procedimientos de resolución. No existen criterios de validación, ni implementaciones de referencia. Análisis estructural del mito (Lévi-Strauss) La determinación de pertenencia de elementos a clases incluye elecciones indecidibles, que tampoco pueden resolverse al azar. Modelo axiomático de matrimonio Kariera de Kemeny, Snell & Thompson Sistema axiomático mal construido.

Tipos de Sistemas-L Deterministas (D0L) Formas más simples, trayectorias Sensible al contexto (IL) L-Systems con corchetes [bracketed] Permiten modelar ramificación Estocásticos Paramétricos Tabulados Temporales, Propagativos, Ambientalmente sensitivos, etc* * Stelios Manousakis, tesis

Programas de gramáticas complejas

Programas de Sistemas-L **Fractal Grower **Treebag *Fractree *Fractal Play (Fractal Games) *Lyndyhop Lsystems 4 LinSys 3D LStudio (Prusinkiewicz) *LS Sketch Book *L-Systems Application applet JFLAP – Programa de teoría de autómatas A Musical Generator *Visions of Chaos

Fractal Grower - Prácticas http://cs.unm.edu/~joel/PaperFoldingFractal/

TreeBag - Prácticas

*Fractree Antiguo y discontinuado (1993), pero decente Permite probar iteraciones con teclado, lo cual es práctico No posee prestaciones demasiado elaboradas (p. ej. 3D) pero se puede avanzar sin escribir Admite una sola sustitución No se puede saber cuál es la secuencia de comandos de una iteración A los archivos básicos agregué algunos que comienzan con BR que son modelos culturales Polvo y Alfombra de Cantor, kōlaṁ s, Espirales

*Fractal Play (Fractal Games) Requiere JRE – No hay datos de autoría Buen programa simple en 2D Interface un poco incómoda, pero con información sobre el estado del string Útil para comprender la complejidad recursiva Formato de archivo y comando no documentado A los archivos originales, agregué modelos de kōlaṁ (Krishna y Serpiente) y espirales complejas

*Lyndyhop Requiere JRE Muy simple pero práctico para aprender Tiene visualización de evolución, mejor que la de Fractal Play También se visualiza el sistema a medida que se lo compone con botones (único) No tiene movimiento sin escritura (f) – No puede modificarse el tamaño del paso Ejercicio: Curva de Koch (F+F—F+F, 60°) Go...

LSystems 4 Capacidad tridimensional Propósito general Sintaxis incompatible Formato de archivo imposible de migrar Texturas, pero no ray tracing (POV) Go...

LinSys 3D Programado en 2001 y discontinuado ahora Sistema bracketed, sensible al contexto, estocástico y paramétrico Permite examinar evolución del sistema Lenguaje de comandos complejo, con alfabeto y reglas de producción Cargar Spiral.lsys y examinar Go...

Fractal Studio El más elaborado y poderoso, tal vez demasiado Evaluación expirada – Usar con fecha anterior a 2005 Utiliza lenguaje L+C, que combina constructos de L-System (módulos y producciones) con C++ Cargar objeto de directorio interno y probar

Modelos tri-dimensionales

Modelos tri-dimensionales

LS SketchBook Poderoso, profesional y bien documentado, pero un poco peculiar Discontinuado hace años, pero técnicamente vigente Sintaxis y formato de archivos incompatibles Buena documentación geométrica y evolutiva *Ejecutar secuencia de desarrollo una vez visualizado (de buen efecto con espirales o con sympodial pruning) Go...

LSystems Application Applet Interesante, con ejemplos raros Puede procesar rectas o curvas Hermitte, Bspline 38 muestras excelentes, incluidos kōlaṁ s con curvas No puede procesar muchas iteraciones

JFLAP Modelado de autómatas No es particularmente apto ni bien documentado, pero permite alinear gramáticas y autómatas dentro de un mismo concepto L-Systems: Ejemplos de capítulo 10

*Visions of Chaos Programa de fractales de propósito general El módulo de L-Systems es excelente Posee la mayor colección de ejemplos de la industria Único que puede generar música y figuras simultáneamente Go...

A Musical Generator 3.1

Aplicaciones en otras disciplinas

Gift Siromoney [1932-1988] Matemático, teórico de la información, arqueólogo y etnógrafo Picture languages, 1972 – Array languages, 1974 Los L-Systems no tenían entonces implementación gráfica Identificó procedimientos regulares para el diseño de kōlaṁ s: kōlaṁ de matriz finita, kōlaṁ de matriz regular, kōlaṁ regular independiente de contexto Los sistemas-L son más simples, pero las ideas de Siromoney fueron avanzadas para su época

kōlaṁ – Sistemas-L

kōlaṁ y simulación

kōlaṁ y simulación

kōlaṁ tamil

kōlaṁ tamil

Pongal kōlaṁ

kōlaṁ rómbicos y nomenclatura

Nomenclatura La matriz del kōlaṁ se considera como una serie de rombos de 5 pulli, con 1 punto en cada extremo de la cruz y un punto en el medio. En figuras 1-5-1 hay 9 rombos Se empieza de arriba y de la izquierda Se examina si existen cruzamientos de líneas en torno al rombo central Cada cruzamiento vale 1, si no es 0. El 1er rombo es 1010 – Eso es 10 decimal, A hexadecimal La cantidad de variantes para rombos 1-5-1 es FFFFFFFFF=68.719.476.735dec + 1

Cómo se hace un kambi kōlaṁ Primero se construye la grilla Luego se trazan líneas en un disño simétrico, dejando claros Después se añaden líneas diagonales Desde cualquier punto se traza una línea sobre la grilla Se dobla cuando termina o cuando sólo hay dos líneas que se cruzan Cuando todos los puntos se cierran, la línea se encuentra consigo misma.

Ejercicios posibles Establecer nomenclatura hexadecimal para dos kambi kōlaṁ definidos. Trazar dos figuras de kōlaṁ simétricos diferentes a los de los ejemplos.

Casos culturales Ron Eglash – African fractals, 1999 – Cruces etíopes http://www.ccd.rpi.edu/Eglash/csdt/african/fractal/ethiop.htm

L-Systems, arquitectura, asentamientos y paisajes

Metáforas arquitectónicas Christopher Alexander 1977. A Pattern Language: Towns, Buildings, Construction. Oxford, Oxford University Press. 1979. The Timeless Way of Building. Oxford, Oxford University Press. Patterns arquitectónicos Revolución en técnicas de programación Revolución en ingeniería y arquitectura de software AS – Promovido en CMU – SEI (Instituto de ingeniería de sistemas de Carnegie Mellon)

Modular L-Systems

http://www.mh-portfolio.com/L_Systems/lsi.html

Arquitectura algorítmica (cont.) Simulación Simulación algorítmica de flujos para evaluar funcionalidad de diseño Optimización Uso de algoritmo genético para optimizar configuración y diseño de edificio/zona Permutación Proceso de diseño paramétrico Generación Desarrollo de lenguaje de diseño algorítmico generativo basado en sistemas-L Transformación Diseño mediante traslación y visualización de sitio

Simulación

Optimización - Flujo de procesos

Optimización - Flujo de procesos

Permutación

Selección de variantes

Generación de gráfico de tortuga

Generación de gráfico de tortuga

Integración con Maya, CAD, etc

Simulación de ciudades (CityEngine)

Simulación de ciudades (CityEngine)

Simulación de ciudades (CityEngine)

Modelo de Pompeya (Müller - CityEngine)

Jerarquía (CityEngine)

Müller & al – Shape grammars Reconstrucción a partir de datos de GIS Basada en la gramática de partición [split] de Peter Wonka

Programas de shape grammars Shaper 2D – Realizar ejercicio Generar un diseño islámico en estrella (ver Taprats)

Simulación en 4 dimensiones (Wonka 2009)

Derivaciones Combinaciones con AG y autómatas Lechner & al – Modelos basados en agentes

Gramáticas de crecimiento GroGra – Growth Grammar

GML Studio

L-Systems + AG

Lsystems + Geones

Shape Grammars (Stiny)

L-Systems y música

Interpretación musical Longitud como duración, altura como agudo/grave, espesor como volumen, color como timbre, líneas angulares como glissando Ramificación como polifonía Axioma (fijo) Reglas de producción Interpretación de gráficos de tortuga (bidimensional) Imagen Intérprete musical (mapeado espacial) Partitura MIDI Comandos de tortuga Datos gráficos

Aplicaciones en música (1/2) Prusinkiewicz, Hanan, Siromoney – Música karnática, 1986 Stefanie Mason, Michael Saffle – Música y L-Systems, 1994 David Sharp – LMUSe, 1995-1998 John Belcher, James Murrel – Teorías rítmicas africanas Goodall y Watson – Lsys2MIDI, 1998 Luke DuBois – Jit.linden, 2003

Prusinkiewicz, Hanan

Aplicaciones en música (2/2) Stelios Manousakis – Musical L-Systems (tesis), 2006 Peter Worth, Susan Stepney – Growing music

Programas L-Systems / Música *LMUSe *A Musical Generator *ImproVisor The Symbolic Composer FractMus 2000 Fractal Tune Smithy Combinaciones diversas con autómatas celulares y algoritmo genético

ImproVisor

Ejercicios posibles

Requisitos Instalar City Engine en entorno Windows Configurar en Control Panel – Configuración internacional, de modo que la numeración considere el punto como separador decimal. CityEngine requiere hardware NVIDIA. Si no se cumple este requisito, la representación gráfica puede ser defectuosa. Si no se puede instalar o ejecutar City Engine, otras dos opciones de modelado urbano y arquitectónico son: GRO Imp – El instalador se encuentra bajo el directorio de Fractals-Lsystems. Funciona en Win32. Para otros sistemas operativos, consultar sitio de Web. GML Studio – Instalar en directorio de nombre corto, cercano a la raíz (p. ej. C:\fractal\GmlStudio). El instalador se encuentra en el directorio de Software del folder Diseño Urbano – Lo que se ejecuta es GMLStudio.Net.exe

Opción #1 – City Engine Ejercicio de creación de ciudad compleja Correr File/New Escoger opción de City Wizard Seguir los pasos del procedimiento, al inicio con los valores por defecto para evitar mayores incongruencias Generar otro workspace con valores distintos Una vez generada la ciudad, moverse por ella mediante controles de cursor y tecla Alt Consultar intensivamente los archivos de ayuda para explorar opciones de drill down En breve se agregarán instrucciones adicionales

Opcion #2 – City Engine Creación de red de calles urbanas Ejecutar wizard correspondiente Investigar posibilidad de importar desde OpenStreetMap Sobre Bogotá, ver http://www.openstreetmap.org/?lat=4.653&lon=-74.084&zoom=10&layers=B000FTF O bien http://osm.org/go/YJ5jViAA Ver documentación de CityEngine y OpenStreetMap sobre importación y exportación de datos Ver posibilidad de contribuir al mapeado faltante Hay datos sobre las reglas del juego de OpenStreetMap (Creative Commons, gratuito) en artículo de wikipedia http://es.wikipedia.org/wiki/OpenStreetMap A menudo alcanza con un GPS y recorridos en bicicleta

Ver opciones de Export...

Por ejemplo, XML...

Import, Export

Extrusión de edificios a partir de lotes Crear lotes en las manzanas Graph  Create lot shapes Seleccionar manzana(s) Initial shapes  Subdivide En elevation elegir EVEN_ANG para generar lotes horizontales Seleccionar lotes Finish

Extrusión de edificios a partir de lotes (1/2) Seleccionar un lote en el Scene Editor Asignar archivo de regla: Initial Shapes → Assign Rule File... and select the rule file rules/simpleBuildingShells_01.cga Ver resto de procedimiento en Map Control Tutorial – CGA Shape Attributes

Opcion #3 – City Engine Creación y transformación de fachadas Más información en las próximas horas...

Opcion #4 – City Engine Creación y transformación de edificios Véase la documentación en los DVDs distribuidos y en el sitio de CityEngine Más información en las próximas horas...

Opción #5 - GroImp Elaboración de conjunto de edificios Ver requisitos de instalación en este slide Entorno Java 2 JRE, 1.4 o posterior Requisito adicional: programación en Java Hay documentación sobre el producto y sus modelos en el directorio del software Fractals-LSystems\GroImp Instalar modelos de prueba zipeados G1 – G2 – G3 - Structure9 – Skycraper – Treppe – Wandwohnblock Crear un archivo de ejemplos y armar otros archivos donde desempaquetar los ejemplos Para abrir proyectos, seleccionar archivo de proyecto con extensión project.gs Leer cuidadosamente la documentación Hay ejemplos y galerías en: http://www-gs.informatik.tu-cottbus.de/grogra.de/software/groimp/

GroImp

http://www.grogra.de/ http://www.grogra.de/

Opción #6 – GML Studio Transformación de edificio complejo Ver requisitos de instalación en este slide Requiere experiencia previa en modelado en tres dimensiones y comprensión de programación declarativa de tipo XML Los archivos de prueba y los documentos que detallan los tecnicismos se encuentran en el directorio del disco de Diseño Urbano \ Software \ GML Generative Modeling Language Leer en particular la disertación de Sven Havemann

Plan B Si todo falla: Realizar ejercicio de práctica sobre Sintaxis Espacial Nivel Ciudad Nivel Campus Nivel Edificio Complejo Ver materiales sobre Sintaxis Espacial en página de Carlos Reynoso

Conclusiones

Conclusiones Uno de los formalismos más poderosos en geometría fractal y ciencias de la complejidad Epistemológicamente importante, aunque no se utilice esta clase de modelos en el trabajo empírico Infinidad de aplicaciones posibles Un poco difícil de implementar, pero no imposible

Tareas a realizar Averiguar si existen muchos diseños culturales regidos por “gramáticas” Pongal kōlaṁ , rangoli, alpana, aripoma, lusona, mandala Verificar analogías en los métodos constructivos a través de las culturas Ejercitar definición de axiomas y reglas (no es fácil) Es un problema inverso Realizar composición musical usando sistema-L Investigar modelos derivados de simulación para reconstrucción virtual de sitios, paisajes, objetos, ciudades y patrones de asentamiento

Recursos Przemyslaw Prusinkiewicz, Aristid Lindenmayer. The algorithmic beauty of the plants. Springer, 2004 Przemyslaw Prusinkiewicz. L-Systems and beyond. 2003. Prusinkiewicz, P., K. Krithivasan and M. G. Vijayanarayana. Application of L-systems to algorithmic generation of South India folk art patterns and Karnatic music, 1989 Stelios Manousakis. Musical L-Systems, 2006

Recursos

Recursos

Recursos

¿Preguntas? http://carlosreynoso.com.ar