Reynoso - Complejidad gramatical (sistemas-L)

+4

No comments posted yet

Comments

Slide 1

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

Slide 2

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)

Slide 3

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

Slide 4

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

Slide 5

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

Slide 6

Referencias Libros de Prusinkiewicz-Hanan & Lindenmayer

Slide 7

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

Slide 8

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

Slide 9

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

Slide 10

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

Slide 11

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.

Slide 12

Lenguajes regulares Reglas de transición

Slide 13

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.

Slide 14

Lenguajes independientes de contexto Representación arbolada

Slide 15

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.

Slide 16

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.

Slide 17

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

Slide 18

Sistemas-L

Slide 19

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

Slide 21

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

Slide 23

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

Slide 24

Sistemas-L como gramáticas

Slide 26

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)

Slide 27

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

Slide 28

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...

Slide 29

Modelos procesuales

Slide 30

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.

Slide 31

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.

Slide 32

Colby – Gramática cultural

Slide 33

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

Slide 34

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.

Slide 35

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

Slide 36

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

Slide 37

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.

Slide 38

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

Slide 39

Programas de gramáticas complejas

Slide 40

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

Slide 41

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

Slide 42

TreeBag - Prácticas

Slide 43

*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

Slide 44

*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

Slide 46

*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...

Slide 48

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

Slide 49

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...

Slide 50

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

Slide 51

Modelos tri-dimensionales

Slide 52

Modelos tri-dimensionales

Slide 53

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...

Slide 55

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

Slide 57

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

Slide 58

*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...

Slide 59

A Musical Generator 3.1

Slide 60

Aplicaciones en otras disciplinas

Slide 61

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

Slide 62

kōlaṁ – Sistemas-L

Slide 63

kōlaṁ y simulación

Slide 64

kōlaṁ y simulación

Slide 65

kōlaṁ tamil

Slide 66

kōlaṁ tamil

Slide 67

Pongal kōlaṁ

Slide 74

kōlaṁ rómbicos y nomenclatura

Slide 75

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

Slide 76

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.

Slide 77

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.

Slide 78

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

Slide 79

L-Systems, arquitectura, asentamientos y paisajes

Slide 80

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)

Slide 81

Modular L-Systems

Slide 82

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

Slide 83

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

Slide 84

Simulación

Slide 85

Optimización - Flujo de procesos

Slide 86

Optimización - Flujo de procesos

Slide 87

Permutación

Slide 88

Selección de variantes

Slide 89

Generación de gráfico de tortuga

Slide 90

Generación de gráfico de tortuga

Slide 91

Integración con Maya, CAD, etc

Slide 98

Simulación de ciudades (CityEngine)

Slide 99

Simulación de ciudades (CityEngine)

Slide 100

Simulación de ciudades (CityEngine)

Slide 102

Modelo de Pompeya (Müller - CityEngine)

Slide 104

Jerarquía (CityEngine)

Slide 105

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

Slide 108

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

Slide 109

Simulación en 4 dimensiones (Wonka 2009)

Slide 110

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

Slide 112

Gramáticas de crecimiento GroGra – Growth Grammar

Slide 114

GML Studio

Slide 115

L-Systems + AG

Slide 116

Lsystems + Geones

Slide 117

Shape Grammars (Stiny)

Slide 119

L-Systems y música

Slide 120

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

Slide 121

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

Slide 122

Prusinkiewicz, Hanan

Slide 123

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

Slide 124

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

Slide 127

ImproVisor

Slide 128

Ejercicios posibles

Slide 129

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

Slide 130

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

Slide 131

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

Slide 132

Ver opciones de Export...

Slide 133

Por ejemplo, XML...

Slide 134

Import, Export

Slide 135

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

Slide 136

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

Slide 140

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

Slide 141

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...

Slide 143

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/

Slide 144

GroImp

Slide 145

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

Slide 146

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

Slide 147

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

Slide 148

Conclusiones

Slide 149

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

Slide 150

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

Slide 151

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

Slide 152

Recursos

Slide 153

Recursos

Slide 154

Recursos

Slide 155

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

Summary: sistemas-l, complejidad gramatical, gramaticas generativas, chomsky, kolam

Tags: sistemas-l complejidad gramatical gramaticas generativas chomsky kolam

URL: