Toward Procedural Generation
Updated 2 months ago
A brief article about preliminary work concerning the procedural generation of diverse environments for complex autonomous (mobility) systems
[DRAFT 0.0.1] Still quite a b of TODOs ...

Preliminary Notes

*This is all very much an "in development" work, and as such may one find various "incompleteness-es", notes, general thoughts (and perhaps questions), and maybe even (but hopefully not) errors by the author spread throughout this document. Shall the final paper of this work be a more complete, rigorous, concise, unambiguous and correct (as the work can possibly be made to be) product. This work, as is said about all of these early works on this field of study, is a "living draft", and is therefore not yet a "formal treatment" of the subject matter, but the (incipient) means to eventually arrive at such a final, formalized product.
*A paper on this work of procedural generation is also currently in the works. This is to say that this article shall serve as more of an introduction to some of the most important concepts surrounding the procedural generation methodology, and the paper shall give a significantly more rigorous exposition of the method.
*"key words" sections have two purposes here: 1. to provide a point of reference of relevant topics for further investigation that contribute to the goals wanting to be achieved by this work 2.
*The exact definition and nature of "complex autonomous mobility systems" is explicated in more depth in [1] (though there does not exist a "formal" definition as of this moment (future work to come).
*Duplication article on Medium: [TODO: WRITE / COMPLETE MEDIUM ARTICLE]
*A precedent set in previous works (see [1]), does the asterisk (*) symbol denote side notes or special (separate) points of interest or consideration.
*A follow-up article is to come which goes another brief introduction into the AgentSim simulation component platform, and further explains the role of this work on procedural generation has in the larger context of autonomous agent simulation.
*Is the use of the word "components" used rather heavily in this work, and as shall be mentioned later in the article, is a goal here to develop a system (pipeline, algorithm) that has a high degree of modularity, extensibility and interface-ability (and in general compose-ability ), and the fundamental unit of structure that creates the system is captured by the word "component".
*It should be noted that this article is purely introductory, and a significant amount of detail is amounted in a (somewhat difficult) attempt to maintain a sense of brevity and clarity of higher level, overall ideas.


Here, shall I give a brief introduction to some initial work being done in terms of procedural generation of environments. The goal is merely to introduce the work and not give too much of a detailed account of the entire project, which shall be done at a later time. Today, may one find many works aimed at recreating the "real world" as a way to allow for the development and testing of complex autonomous system (autonomous vehicle for example [complex autonomous mobility agent systems]). As with any problem, however, there exist more than one ideal solution. Toward the problem of generating a sufficient amount of suitable data of variety and diversity, of which has the purposes of development and testing of autonomous system related technologies, perhaps the approach of automation (procedural generation) may also be of great utility. Much work is also being done in the field of procedural generation (see [2-8]), and so a point of this work is to not necessarily create a completely novel approach to procedural generation of complex environments, but to just create a significantly more comprehensive one.
Given a standardized method for procedural generation, is there the hope to then create a formalized simulation system (a formal methodology) for the simulation of complex autonomous (mobility) systems. In general, does this work have the goal of (from the high level perspective) of finding suitable control mechanisms for such complex autonomous systems. In any given control problem, does one first need to perform some type of system identification (finding suitable system representation [model]), before a suitable control law can be created. It is a desire that the procedural generation methodology of this work shall be a solid first step forward in the direction of designing, developing, and testing appropriate control mechanisms for any given complex autonomous system.
Quick Overview
This work then aims at devising a procedural generation tool that can create environments, starting from a truly empty space (a four dimensional Haussdorff 4-dimensional manifold [3-dimensions of space and 1 dimension of time [Minkowski spacetime] representing the spacetime continuum) , from which a procedural world is then built. This procedurally generated world then allows for the generation of increasingly more complex static structures (roads, parcels, buildings, settlements, etc...). Given this procedurally generated static world, is a dynamic world filled with "intelligent" agents then generated (pedestrians, vehicular traffic, etc...). These agents, in one sense, can then present a challenge to some complex agent (or network of agents) under study (an autonomous ego vehicle for example, or a flock of such vehicles). This methodology of procedural generation presented in this work is hoped to completely automate the process of creating all necessary components involved in developing and testing autonomous system technology, where a user would only need to change some parameters, options, or settings list or file, and the user would not need to concern themselves with the many details involved in creating such environments of satisfactory complexity and variety.
This work of procedural generation and automation of environment and design and testing scenarios is, in fact, the first part of a larger body of work (AgentSim, see [1 ]), where this larger work hopes to create a more complete and comprehensive tool, environment, and ecosystem for complex autonomous system simulations. This work, and the larger work, are still both very much in their infancy, yet it is hoped that the final tool will be a first step toward streamlining the development of complex autonomous systems and allow for more "standardized" approached to developing these systems which also, ideally, allow these systems to be created with great ease.


I shall only put high level references and basic information here, as each of the topics has vasts amounts of information associated with them, and it is desired currently to just briefly demonstrate the roles that each subject has to play in this work. As such for now, more information about each subject can be found in the References section.

Space, Time and Change

There is a significant amount of information to be studied and discussed here (which I shall do at a later period of time [likely in the technical paper outlining the work of procedural generation]), and as such, out of pure desire to not fall into a "black hole of information/knowledge" and so shall I just give a high level allusion to some reasons for even looking into this field for consideration.
The method of procedural generation that is hoped to be created here is one such that shall be of great comprehensiveness and shall provide an accurate model of the physical reality and all things contained within. Though the exact nature of reality is still not necessarily completely understood, it may still be worth the effort to at least take some of the most fundamental conclusions from the field of (theoretical) physics and apply them in our method of procedural generation of realistic environments. The main purpose here for even having such considerations is more so as to form a theoretical foundation for formally devising a method for procedural generation and suitable representation (through rigorous mathematics and physics).
The subjects of Topology, Differential Geometry, Geodesics, Spacetime, and Chaos Theory are all points of study and interest for this work, as it is believed that crucial insights about foundational and rigorous representations and manipulations of topological / geometric structures can be gained and that could allow for a formal exposition of the procedural generation process (from both a static and dynamic perspective).
A rather large subject that concerns itself with techniques related to geometry from a perspective of continuity (in conjunction with differential geometry), does this work aim at applying the conventions of this field (and that of differential geometry) in a manner as to formally define the method of procedural generation of (topological / geometric) environments. Here are topics such as metric spaces (an intuitive / generalized notion of distance in a given space, and is a central concept in both topology and differential geometry) , homotopy (shape / path deformation characteristics), ..., and several other topics become relevant. Through the consideration of various ideas of topology, is it hoped that basic intuition about how one could begin to compose and morph shapes in a given space (manifold) given some concept of distance between these shapes (the metric space) can become possible. (see [])
key words: metric spaces, topological spaces, compactness, homology theory, cohomology, homotopy, homeomorphism, Hausdorff space, sequences, nets (generalization of sequences), spatial continuity, spatial transformation in-variance, frame of references
Differential Geometry
Extending a bit beyond vanilla topology, does the study of Differential Geometry lead to notions about the nature of curves and surfaces (see []). Space (from spacetime), the planets contained within the space, and the environments that exist within the planets are all "curved", and do methods and study of differential geometry naturally apply to geometric objects in this setting.
key words: manifolds, geodesics, cartography, atlas, charts
Is it really not a goal (at least for now) to include or use the deep intuitions about the current understandings surrounding the theory of relativity (or special relativity), but really just to use some of the basic (mathematical) machinery and notations for modelling and representing various geometric and topological objects with respect to space and time.
(M, g) M - spacetime manifold g - metric tensor (rule of distance)
key words: spacetime
[TODO: complete section...]
Chaos Theory
Dynamic systems who are capable of highly random behavior (due to sensitivity of initial conditions) are of focus in the theory of chaos.
(M, f) M - spacetime manifold f - evolution (rule) of state
key words: inertial frames
[TODO: complete section...]


Tensors are of particular interest for many reason (not just for the procedural generation of road networks) as they provide a concise representation of physical state in mathematical terms. So though in this work, only information relevant to road generation is presented, in reality the use and study of tensors shall likely be seen in many other areas as well (such as the representation of the complex system of study itself (see [9])).
Representations and Bases
Much of the work toward the procedural generation of roads is based from the work of [14], and its derivative works.
[TODO: complete section...]
keywords: Hyper-streamlines, Degenerate Points

Computational Geometry

Computational Geometry provides a series of algorithms and methods for performing the algorithmic manipulation of geometric elements, which is especially useful in producing and manipulating meshes in 3D computer graphics.
The creation of a polygonal "mesh" in a virtual 3D environment requires the triangulation of such an object. Triangulation (with respect to this work) essentially involves taking a series of points which represents some geometry 3D (or 2D) object and finding an optimal set of triangles (which is what Delauney triangulation method attempts to do [there exist other methods for triangulation as well]) that can cover the surface of the object. Given an object with an optimized set of triangulation, can a renderer produce a "mesh" in the virtual environment. This figure below is just a random example of the Delauney triangulation method, but does Figure [] show an example triangulated road mesh (which can be rendered in Unreal 4 [and eventually in Unity / Blender...], via the code in the Github repository: "TransitCreator-AVSIM_Module" ),
key words: ear clipping,
Convex Hull
The idea of convex hulls is to find a the outermost boundaries of a set of points (which can clearly be seen by the red lines in the figure below, given a set of blue points). This algorithm can alle be used for 3-Dimensional points, and so an idea here is to be able to find a set of points that represent the outer (closed) bounds (so the outer surface, in a 3D object for example) of a geometric object, and then produce a triangulation of this which shall allow for the procedural generation of the object in a virtual environment. Introducing convex hull methods is more for allowing the creation of more arbitrary geometric objects (such as geometric objects produced from a random (coherent) noise function).

Interpolation essentially amounts to methods that seek to "fill in gaps" between a set of points. Interpolation can be extended to arbitrary dimensions and has many uses throughout this work (such as in the generation of Simplex Noise, or the approximation of arbitrarily curved surfaces). Similarly to the reasons for introducing convex hull methods, is a reason for having a generalized interpolation method such that approximations of arbitrarily curves or edges (for the examples some procedurally generated curved edge of a piece of a building [or road], created from coherent noise) can be found.

Polygon Partitioning
[TODO: complete section...]

Numerical Methods

Numeric methods involve "discretized" algorithms for approximated various concepts of calculus, such as integration. The calculation of hyper-streamlines of tensor-fields requires integration along a path of a given field, and in this work (see []), the RK4 method of integration is used for this.
key words: Runge-Kutta Numerical Integration
[TODO: complete section...]

Road Geometry Design

In an attempt to keep the realistic element to the procedural road generation algorithm, an idea is to generate roads based actual, real world, computational methods used to create the geometry of real roads. One can find the details (the equations and explanations of creating road and highway geometry) in the references [ ], but here do I just want to give some brief details on how more realistically procedural generated roads could be created.
The computation of the hyper-streamlines of some given tensor-field basis produces "station points" (centering points used to determine road alignment), and the idea here is, after this process, to produce approximate road geometry based on the equations used in road and highway construction engineering, some of which are described below.
[TODO: complete section...]
key words: Horizontal Alignment, Vertical Alignment, Super-elevation, Cross-Sectional Alignment

Procedural Generation Techniques

The procedural generation of 3-Dimensional virtual environments is certainly not a new concept, and as has been stated before, much work has been done already in various areas of this field. As such, shall only give a brief overview of the most immediately relevant concepts to this work be stated here, and more information can be found in the references [2-12].
Lindenmayer Systems...
[TODO: complete section...]
key words: Parceling, Shape Grammars

Coherent Noise

An important aspect of procedural generation is the concept of "coherence " (and consistency), where elements produced by the procedural generation methodology must have the characteristic of diversity, but must not have to great of deviation from physical reality. A sense of "connectedness" must exist between created elements in the pipeline (an interesting and possibly related concept may be that of "percolation" in statistical mechanics), yet also must there be a stochastic element of chance to achieve the desired variability. Naturally, does one come to consider the theory of coherent noise as a framework for producing such elements. The work of [16] began toward a more formal treatment of coherent noise, and it is hoped to extend these concepts into the larger context of this work.
[TODO: complete section...]
key words: Perlin Noise, Simplex Noise, Fractal Noise


Though it is not explicitly mentioned in this work, probability, statistics, and in general stochastic modelling are a very integral part to the creation of highly diverse (and probabilistic) environments. Shall not anything more beyond this be said here, but does a point wish to be made that the field surrounding probabilistic modelling and its various techniques and methods are of great consideration and importance in the process of procedural generation.
key words: cumulants, moments, central moments, moment generating functions, probability distributions, conditional probability, qeueing theory, renewal process, Brownian motion, Poisson process, Markov chains, discrete event simulation

Procedural AI Concepts

Here is just a highlight of some of the concepts and ideas used in the creation of the procedural artificial intelligence module. This work currently presents a more theoretic framework for the procedural generation of AI agents, and future work includes the development of a more standard architecture and pipeline for the generation of procedural AI.
[TODO: complete section...]
key words: Hierarchical Tree Planners (HTP), Blackboards, Behavior Trees, Influence Maps, Utility Theory, Observer Design Patterns, Publish-Subscriber Design Patterns


The overview section gave a high level description of the basic functionality of the procedural generation pipeline. As the currently, the work on the pipeline is still not yet complete, shall I only give some brief highlights on current work, and expand a bit further about some of the details of the pipeline.
The procedural generation methodology used to create diverse environments can be subdivided into three main components: the PWG, PAI and PCG components. The static elements and morphology (shape) of the environment are produced by the PCG module. Dynamic elements (pedestrians, and other moving agents of "intelligence") are produced by the PAI module. Detailed elements (textures, animations, etc...) are then finally produced by the PCG module. This pipeline (algorithm) is implemented through the GE component of the larger AgentSim Simulation component (all of which is further encompassed within the larger AgentSim Ecosystem). Consummate automation and streamlining the creation of complex and diverse environments is hoped to be achieved through the development of this procedural generation method, which shall further be used for the development of complex autonomous (mobility) systems. Though this work emphasis more of the system design for the procedural generation methodology, does the paper (to come) and the final work aim at providing a complete and standardized procedure for procedurally generated any environment (this has been stated before, but does emphasis want to be given to how these ideas all come together to form an automation continuum [complete automation tool]).
key words: PWG-Procedural World Generation, PAI-Procedural Artificial Generation, PCG-Procedural Character (Agent) Generation

The Pipeline

An initial outline of the algorithm [pipeline] is presented in the figure below. The is the first part of the total pipeline, that represents just the generation of static elements in a given environment.

Procedural World Generation (PWG)

The pipeline begins with an empty space-time manifold object, and then the algorithm begins to populate this object with static elements, the first of these being worlds, terrestrial environments, and terrains. Terrain morphology (and the later development of Settlement formation) are to be principally generated according to user input (information maps (semantic maps, see [2]), options, settings, input parameters [in the form of json / yml files most likely])
Given a procedurally generated terrain, and using the information maps (generated from the user) are tensor (scalar --> vector) fields generated on the terrain, and from these fields are settlements generated. Settlements are divided into two main components, road networks and buildings, where the pattern / placement of these elements are based directly on the generated tensor field. Tensor-field generation and hype-streamline computations share parallels with the ideas of real world road geometry development, namely, land surveying and stationing. The hyper-streamline points represent the center-lines of the roads in the road network and, through use of the road geometry equations, are the road geometries approximated and generated and are placed into the terrain.
Currently, are the tensor-fields being generated through first deriving the characteristic vector fields (eigen decomposition) and then generated then two vector fields and superimposing them on one another (this is what is shown in the following two figures below).
In the work of [14], is there described a method for blending together different street patterns, in order to form a single cohesive road network. A road network then has the characteristic of composability, and more complex road network structures can be generated from the tensor-field bases (grammar).
Upon the generation of the road networks, can plot generation (the space between the roads in the road network) and parcels (the subdivision of plots for which buildings shall be generated upon) can be done. Inside of each parcel building structures (as generated according to the zoning (smart code) information map) can be created. Building footprints are generated as to create the foundation of which the building is built on top (plants and other ornaments are to be generated in a separate, concurrent thread). Given a building footprint and foundation, is a building to be generated as according to some shape grammars (the [probabilistic] rules of composition and the geometric objects used to construct a building). Building interiors are not of particular concern in this work at the current moment, but may become of more interest later (if needed). At the moment, are buildings just to be considered "rabbit holes", where dynamic elements (for example, procedurally generated vehicles [or pedestrians]) can freely enter or leave a building's exits / entrances. So these buildings operate as spawn points for procedural dynamic elements. An idea here is, for example, given a test scenario that involves an ego autonomous vehicle, the ego vehicle can have a certain (user specified) "radius of activation", where this activation radius (or ring) can activate the spawn points located within buildings (or other civil structures). So, when an ego vehicle enters into a new region. the spawn points activate, and procedurally generated dynamic elements begin to leave and enter the building structure (the behavior of the dynamic elements can also be specified by user defined information maps and models).

Procedural Artificial Intelligence (PAI)

Beyond just static elements, does this work also aim at creating a generalized framework for the procedural generation of "intelligent" dynamic agents. These agents are composed of components and (data /event driven) models. The models, which represent various facets of the agents (behavior, decision making, senses, etc...) provide the template for creating an given agent. From these model template are components made, and a hierarchical chain of components eventually build up into a complete procedural generated "intelligent" agent.
A goal here is to create a system that can produce a series of intelligent agents that can provide a sufficient challenge for a given autonomous agent (or network of agents) under study and development (Quite similar to the use of artificial intelligent agents in video games that are to challenge a player [in this case a "player" is an autonomous system (vehicle)]). Beyond the ability to provide a "challenge" to a complex autonomous agent, is there concurrently the goal to develop a framework that shall facilitate the study and development of networks of complex autonomous systems. A distinction is to be made here between the PAI component and the AI Platform component in the architecture of the Simulation component of AgentSim. the PAI has the purpose of accomplishing the first goal mentioned here (provide a challenge to autonomous system), and the AI Platform Component aims at accomplishing the second goal (studying, developing and testing networks of complex autonomous systems / agents).
Procedural intelligent agents are divided into two main internal components and an external component. The internal components include the Body component and the Brain (Mind / Controller) components, and the external component includes the AI Coordinater component (which includes the Blackboard, Influence Map and Pub-Sub coordination (Publisher-Subscriber [and Observer [sub]components]) sub-components).

Procedural Character Generation (PCG)

Eventually, shall it be ideal to have a system that streamlines the process of creating dynamic intelligent agents (so procedurally creating characters with automatic rigs, animations, and detailed textures), and all of this functionality is to be included in the PCG module.

AgentSim Simulation and "GE" Components

As is to be further explained in the follow up article to this one, is one of the goals of the simulation platform to have high modularity, extensibility and interface-ability with existing software (as was stated in the preliminary notes). With this in mind, may one find some particular patterns in the system design process (this is really just a side note to raise awareness of this goal of simplistic composition to engender complexity).In any case,
To give a bit of context (which shall be explained in more detail in future articles) diagrams depicted the larger AgentSim Ecosystem and Simulation component are depicted below. The AgentSim Ecosystem has the purpose of providing a tool for creating, developing and testing various complex autonomous (mobility) agent components, which mainly include devices (and systems), controllers, and simulation related environments. This work focuses on the creation of a "master" simulation component (but in reality is the idea allow for the creation of a series of simulators [which is the same for the device and controller components]).
Going down the ecosystem taxonomy (abstraction) chain, does one arrive the "master" simulation component. Depicted in the diagram one, does one see the GE module component (the focus of this work), whose functionality includes all of the 3D rendering, physics simulation, and general visualization modelling. Each software module component (Core, Device Platform, GE, etc...) has the same basic structure (depicted on the right sided diagram), which includes a core software package (generally written in c++ (and tested with java / python)). The modules connect and communication with one another through upper and lower interfaces, and, in general, is there an API the provides a standard set of functions and method of interaction between core software packages and external software packages (external software packages of the GE component includes [or will include] code implementations in Unity, Unreal 4, and Blender Game Engine [BGE] that are wrapped inside of internal software containers) [*Note: this same pattern of design applies to all of the software component modules]. External software package containers are further subdivided into applications and libraries (for example, the procedural generation external software package includes the applications such as PWG, PAI, and PCG and libraries such as MathLib (really, the core mathematics library for the entire simulation platform) and PhysicsLib [and many others as well]).

As has been stated before, the procedural generation pipeline is implemented through the GE (Game Engine) component. The heart of the GE component is made from a combination of a scenario component and a management component. These two components work in conjunction to produce a scene (level, scenario, environment) full of static and dynamic elements. These static and dynamic elements are produced using the plugin modules, where each plugin module provides a different aspect of the procedural generation pipeline.
Each plugin module has the same basic anatomy, which is depicted below. The runtime component of the plugin module is mainly for the "real time"or "online" related functionalities, and the developer component is for "off line" functionality, whose details can be seen in the figure. The editor component is dependent upon the visualization platform used (for example whether Unity, Unreal 4 or Blender is being used).
The management system of the GE component handles many aspects of the simulation platform (as can be seen in the diagram below). The managers coordinates between all of the various elements in the platform (more details shall be available in the executive summary of AgentSim to come...).
The basic file structure of the core system of the GE component is depicted below. One of the reasons for introducing these diagrams is to give the reader a brief glimpse into the code structure (as the code structure (of the entire AgentSim Ecosystem [and AVSIM]) found in the Github repositories is (mostly) directly reflected by these diagrams).
The basic GE component data and workflow model was originally meant for the development of control systems for control vehicles (hence the emphasis on optimal control (and reinforcement learning) methods in the pipeline.As per the discussion of [2], did a larger purpose (use case) become clear for the AgentSim Ecosystem (a topic digression of which shall not be discussed here). In general, is the data and workflow presented in the diagrams below a reflection of the original (AVSIM) system purpose mainly.

These data and workflow diagrams are by no means product, but are just an initial sketch of what how data is to move through the system ideally.
The final depicted diagram is a quick side note about the idea of context in reference to the scenario-agent-environment relation of the procedural generation pipeline. Procedurally generated environments are aimed at providing the means to create complex scenarios (for experimentation, etc...) and so, in general, is there a desire to form contexts (a generalization of [complex] scenarios). Contexts are abstractly built and represented by levels, which are further decomposed into scenes, worlds, actors (static and dynamic elements), relevant scenario state (information) and other (user defined) externalities. Experiments, specific testing (the general formation of [a series of] tests), applications, services, and things of this nature are all captured and encapsulated within context (components).

Conclusion and Future Work

As was stated in the introduction, this is preliminary work and there is still many things to be done toward completing the final pipeline / algorithm of procedural generation of complex and diverse environments. Upon the finishing the creation of environments of static and dynamic elements, can work begin (or continue as there is concurrently work being done on developing complex autonomous systems) on the development of the complex autonomous mobility systems themselves. Here considerations such as networking (vehicle ad-hoc networks and V2V communications), distributed vehicular systems, vehicular edge computing, distributed machine learning applications (for optimal control purposes mainly), and many other services and applications shall be integrated into the environment of automation, whose foundation is based on the procedural generation pipeline of this work. Also, there is concurrent work being done on the more theoretic and philosophic nature of complex autonomous systems, which is summarized in [1]. The reference [1] gives an overview of the entire project, and it is hope that the work done here with procedural generation shall be of significant utility in achieving the final, overall objectives outlined in [1]. A key point of the procedural generation (for which shall be the focus of future work) shall be that related to the procedural generation of dynamic agent details (so procedural animation, materials, and other [detailed] assets, with emphasis on dynamic procedural agents [this is the "Procedural Character Generation" App module component in the Github "PG" repository]).


  3. Smelik, Ruben. (2019). A Declarative Approach to Procedural Generation of Virtual Worlds.
  4. Elinder, Tobias General Methods for the Generation of Seamless Procedural Cities (2017) In LU-CS-EX 2017-30 EDA920 20171
  5. Kelly, George & Mccabe, Hugh. (2006). A survey of procedural techniques for city generation. Institute of Technology Blanchardstown Journal. 14.
  6. Yoav I. H. Parish and Pascal Müller. 2001. Procedural modeling of cities. In Proceedings of the 28th annual conference on Computer graphics and interactive techniques (SIGGRAPH '01). ACM, New York, NY, USA, 301-308. DOI:
  7. KELLY, G. AND MCCABE, H. 2007. Citygen: An interactive system for procedural city generation. In Fifth International Conference on Game Design and Technology. 8–16.
  8. Hendrikx, Mark & Meijer, Sebastiaan & Van Der Velden, Joeri & Iosup, Alexandru. (2013). Procedural Content Generation for Games: A Survey. ACM Transactions on Multimedia Computing, Communications, and Applications (TOMCCAP). 9. 10.1145/2422956.2422957.
  9. Ruben M. Smelik, Tim Tutenel, Rafael Bidarra, and Bedrich Benes. 2014. A Survey on Procedural Modelling for Virtual Worlds. Comput. Graph. Forum 33, 6 (September 2014), 31-50. DOI:
  10. Najahi, Yakin, "Urbis Terram - Designing and Implementing a Procedural City Generation Tool for Unity3D Game Engine" (2017). Masters Theses (All Theses, All Years). 398.
  11. Hwang, Rachel. “Procedural Building Generation with Grammars.” YouTube, 9 Nov. 2017,
  12. Dang, Minh. “Interactive Design of Probability Density Functions for Shape Grammars.” YouTube, YouTube, 23 Sept. 2015,
  13. Minh Dang, Stefan Lienhard, Duygu Ceylan, Boris Neubert, Peter Wonka, and Mark Pauly. 2015. Interactive design of probability density functions for shape grammars. ACM Trans. Graph. 34, 6, Article 206 (October 2015), 13 pages. DOI:
  14. Schwarz, M., & Wonka, P. (2015). Practical grammar-based procedural modeling of architecture. In SIGGRAPH Asia 2015 Courses, SA 2015 [13] Association for Computing Machinery, Inc.
  15. Guoning Chen, Gregory Esch, Peter Wonka, Pascal Müller, and Eugene Zhang. 2008. Interactive procedural street modeling. In ACM SIGGRAPH 2008 papers (SIGGRAPH '08). ACM, New York, NY, USA, Article 103, 10 pages. DOI:
  16. Grøn Øyvind, Hervik Sigbjørn; Einstein's General Theory of Relativity; [TODO: Complete reference]
  17. Ares Lagae, Sylvain Lefebvre, Rob Cook, Tony Derose, George Drettakis, et al.. A Survey of Procedural Noise Functions. Computer Graphics Forum, Wiley, 2010, 29 (8), pp.2579-2600. <10.1111/j.1467-8659.2010.01827.x>. <hal-00920177>
  18. T.F. Fwa, The Handbook of Highway Engineering; September 28, 2005 ; 888 Pages - 373 B/W Illustrations ; ISBN 9780849319860 - CAT# 1986
  19. Steven Rabin. 2013. Game AI Pro: Collected Wisdom of Game AI Professionals. A. K. Peters, Ltd., Natick, MA, USA.
  20. Wu, San-Yuan & Sahni, Sartaj. (1994). Fast Algorithms to Partition Simple Rectilinear Polygons. VLSI Design. 1. 10.1155/1994/16075.
  21. Mark de Berg, Otfried Cheong, Marc van Kreveld, and Mark Overmars. 2008. Computational Geometry: Algorithms and Applications (3rd ed. ed.). TELOS, Santa Clara, CA, USA.
  22. Eric Lengyel. 2011. Mathematics for 3D Game Programming and Computer Graphics, Third Edition (3rd ed.). Course Technology Press, Boston, MA, United States.
  23. Robbin, J. W., Salamon, D. A., Introduction to Differential Geometry, ETH, Lecture Notes, preliminary version, January 2011,
  24. Bredon, Glen E.; Topology and Geometry (Graduate Texts in Mathematics) Springer New York; 10.1007/978-1-4757-6848-0; ISBN 9781475768480

Further Reading and Resources

Further Readings

  1. Hawking, S., & Ellis, G. (1973). The Large Scale Structure of Space-Time (Cambridge Monographs on Mathematical Physics). Cambridge: Cambridge University Press. doi:10.1017/CBO9780511524646
  2. J. W. Gibbs; "On the equilibrium of heterogeneous substances"; Am J Sci December 1878 Series 3 Vol. 16:441-458; doi:10.2475/ajs.s3-16.96.441
  3. N. Bourbaki, Elements of Mathematics Algebra I: Chapters 1-3 [TODO: Complete reference]
  4. Sheldon M. Ross. 2006. Introduction to Probability Models, Ninth Edition. Academic Press, Inc., Orlando, FL, USA.
  5. Kardar, M. (2007). Statistical Physics of Particles. Cambridge: Cambridge University Press. doi:10.1017/CBO9780511815898

Resources and References


Code Repositories

  7. [an interesting dynamic agent generation java-script code base]
  8. [statistical mechanics percolation theory java visualization code base]
  9. [an O(n) polygon partitioning algorithm]
  17. [discrete even simulation for vehicles (V2V communications, in Omnet++)]

Code Repositories and more Information

More information about this work (and the large encompassing work) can be found at the medium publication sites:
Code for the generated figures as well as code for the entire procedural generation project can be found at the Github repositories (all initial testing work is done in python / Blender (for "quick and dirty" development and testing), and then converted [*still currently being converted] into c++ / java (java is for visualization testing purposes mainly)): [contains the code for all the entire AgentSim Project (though many repositories have yet to be filled as of late ["complete the project" is on the TODO list...])]
The Original Procedural Generation project code (The "GE" module component, procedural world generation, and procedural AI were all done in Unreal 4 initially (this was the old project called "AVSIM", and the new project is now called "AgentSim"), and this work is to be eventually be converted to Unity [and Blender Game Engine (BGE) at some future point in time ...]) all of which can be found at the following Github repositories:

End Notes

*WARNING: Some of the code repositories are still not well organized yet (at all) as the project still in that "raw development" stage, something for which shall be on the top of list of things to do as the project continues further.
*FINAL NOTE: As always, this work, its ideas and concepts, are very much open and are continuously changing, growing and developing. Comments, inquiries, questions, concerns, general thoughts, responses, reactions or feedback of any kind are always very much appreciated and welcome.