Project Log

Jacob made some minor improvements to the bibliography of the report according to the feedback the group received from the examiner. More references now also show the journals and issues rather than just a DOI. There remains some references which could use more such details but we were not able to find these details online.

The previous cover image for the report was replaced with an updated version. Anton rendered a new cover image for the report with updated materials that render correctly in Blender.

Jacob also made an official release version of CityCraft and the report. The code release is available here.

The week of the final presentation the whole group presented, planned, and rehearsed the final presentation. The group received a lot of appraising comments from our supervisor as well as the opposing group on the presentation. This was at least some confirmation that the presentation was well presented which the project group felt as well.

Finally, after we had done our presentation, it was time to receive our opposition. The opposition we received ended up focusing mostly on structural suggestion, which we and our supervisor felt were somewhat subjective. However, we did also get some interesting feedback regarding the questions in our introduction and user testing in discussion. These comments were resolved by the end of the week.

Our opposition sub-group, consisting of Viktor and Anton, prepared questions and comments for their opposition. Viktor and Anton also presented these to the opposing group and many of the comments were well received and brought about a good dialog.

Every group member also wrote and submitted their second self-evaluations.

Previously, the rooftops of buildings were displayed incorrectly and the ocean appeared gray when rendered in Blender. This was solved by changing the shader for the ocean and the rooftop buildings into the Standard Unity Shader that is compatible with the .glTF specification, and hence, are displayed correctly in Blender.

It was soon time for a part of the group to do the final presentation. Alexander, Theodor, Marcus, and Jacob were the ones to do the presentation, and we decided to use Google Slides for it. Adding content and manuscripts for the presentation was the primary focus of this week, practicing together, as well as helping each other through feedback. By practicing the presentation quite a few times, we could ensure that the presentation would go smoothly without any hiccups, which it fortunately did. Our supervisor and examinator were happy with our presentation, which was good to hear.

It was time to get all the different branches into our master branch, so a lot of the code needed to be rebased and merged. This took a longer time than expected, because some branches were quite old, such as the parking generator and road mesh improvements.

The deadline for the final report was this week, so the group spent lots of time to finish it and managed to get it to a state where we were happy with it. The report was submitted and we were awaiting the opposition from the other group.

We received the report from the other group and everyone went through it and left feedback which would later be turned in and sent to the other group. There were some confusion in regards to how the other group should receive the opposition, as well as when we would receive ours. We found out that it was our responsibilty to mail it to the other group, which we did, albeit after the deadline had passed (again, due to lots of confusion and missing information from the examinators). Lots of other groups seemed to have been confused by this as well. The group we opposed did not seem to mind that they got it a bit late though.

Level of detail for roads and intersections were finished this week, which resulted in a nice performance boost.

Jacob spent some time fixing various aesthetical bugs, such as skyscrapers being very thin and the broken plot division from week 10. The library that was chosen to perform plot division had some problems, and we had to implement some algorithms ourselves. More details how these algorithms work can be found in the Methods chapter in the report, specifically under the plot generator section.

Buildings also received some level of detail attention, since the buildings make up a big part of the city, it made much sense to optimize them as well.

Alexander decided to improve the parking generator by using textured quads instead of creating white lines individually. This was mostly to reduce the amount of game objects in the application. There were also a lot of discussion within the group and the supervisor that the parking generator did not have a very good generation of asphalt below it. So, Alexander researched and developed a terrain mesh projector class. Basically, it extracts a portion of the terrain and applies an asphalt texture, and slightly raising it to avoid z-fighting (a common problem where triangles in computer graphics where triangles are overlapping). More details is found in the parking generator in the report.

We had our third and final fackspråk meeting with the Chalmers Library which gave us some feedback and recommendations in regards to our writing and final presentation structure. So, the group went through this to improve the content of our report and presentation.

Continuing like the last couple of weeks with the writing to finalize it, so that it would be ready for the hand-in deadline which was approaching.

The terrain color was adjusted by Jacob to correctly contain snowy mountains. We also found some issues in the park generator which caused no trees, stones or bushes to generated, which Jacob managed to fix.

Anton spent a lot of time this week improving the road mesh, creating better textures for intersections. However, it lead to lots of issues that turned out to be very difficult to fix, so we decided to delay and eventually abandon it due to the time requirement of fixing it. We simply decided that there were other, more important things to focus on instead, such as the report, opposition and final presentation.

Lots of focus was placed on writing the results chapter and other sections, such as the discussion. Anton and Viktor were primarily focusing on the discussion chapter, while the others focused on methods and results. Jacob also wrote the Related Works subchapter.

Marcus spent time on the GUI for the terrain generator, and it is now possible to change the size of the terrain from the GUI. There were a few bugs with the camera movement which Marcus also sorted out this week.

Alexander moved his logic for the road user input to its own class called RoadUIHandler. This class is completely independent from the generators and the application, and easily hooks into the GUI of the application without any problems. This was useful because it demonstrated an approach of creating UI independent handlers for different inputs. However, the only thing that required world level input is the city placement, so there were no other UI handlers needed. For future work, it could be useful for others to look at this class to implement inputs for their own specialized generators, if needed.

Jacob noticed that all textures in our application were imported at an extremely high resolution. By reducing the resolution that the textures are imported as in the game, we achieved a significant boost in performance. Because the export function handles meshes and textures independently from the game rendering, the textures are still exported in full resolution, causing no downsides for the end goal of exporting the cities.

This problem was not something we anticipated would cause such a huge bottleneck in performance. However, because the L-System based building generator had not been implemented into the application yet, the performance loss would not be dramatic until that was merged into master. Fixing this caused the application to run much smoother and requiring way less memory, since buildings were previously relying on lots of textures. So, it makes sense that performance would be a huge problem if this optimization was not implemented.

Much like last week, this week involved a lot of writing to document the different parts of the application. Most writing was related to the Methods and Results chapters.

Alexander worked on improving the function for approximating rectangles within polygons. Since rectangles have 4 edges, it would mean that it should be much easier to approximate rectangles within polygons with 4 edges as well. Thus, Alexander spent a lot of time investigating in better approximation methods for these cases, and developed a method that gave much better results than the general method used previously. This method is only used if the rectangle have exactly 4 edges.

Theodor has managed to get his L-System based building generator working with the application and the terrain. The buildings now create basements that align with the terrain as well, after some trial and error with transformations. He also noticed the overhead his generator caused because of creating a huge amount of GameObjects. Each segment of the building had its own GameObject, which Unity has to handle independently. By merging each segment of a building into one GameObject, we can let Unity handle the rendering much more efficiently. In other terms, less GameObjects, less calls to the graphics card, more performance.

The due date for the report was closing in, so writing the report was part of the focus this week. The background chapter was finally mostly finished this week. The meeting with fackspråk resulted in lots of feedback for our existing chapters and text, some conflicting with specifications and supervisor recommendations, and some very useful. The conflicting feedback were mostly because of personal preference, and we eventually found a format and solution that we, as well as our supervisor, were satisfied with.

Lots of progress were made on the Methods and Results chapters among all group members, each member describing their own section as described in the decisions above.

Jacob has continued his report writing and spent almost the entire week writing on the final report. Some chapters have gotten a good start already, such as the theory, introduction and the background chapter. So far, 12 pages has been written. Our goal is that everyone gets started writing on the final report next week.

At this point, most of our generators were implemented into the full pipeline resulting in a pretty good looking city. We spent a lot of time tuning parameters to improve the overall look of the city and analyzed the results to find bugs and inconsistencies.

Jacob has spent some time this week on the report, notably on the theory chapter which now has descriptions of Noise, L-systems, Search-based PCG and Voronoi diagrams.

Most generators have received updates to allow them to project their results onto the mesh terrain now, such as the ParkGenerator which will project the paths in the park up to the terrain, similar to what the roads do.

Jacob has started working on the final report and has setup the structure and written about noise in the Theory chapter so far. The plan is that the next upcoming weeks should be a mix of writing on the report, as well as implementing more features and bugfixes in the application.

This week consisted of a lot of individual work to get the generators working on their own. Since we had trouble exporting the model, which was a main goal of the project, Jacob continued to work on the exporter (now exporting glTF instead of FBX). However, since the terrain still depended on the UnityEditor package because of the dynamic mesh that we were using, this week he mainly focused on finding alternative solutions to the terrain.

So, with the addition of Alexander’s work on the generalized Noise component, Jacob integrated the new noise into the terrain generator. The dynamic mesh can be converted to a regular mesh that the exporter would work with, but that also requires the UnityEditor package. So the only alternative is creating the mesh entirely on our own, which is not a problem in itself since it is a pretty trivial task. However, a lot of complex features that the dynamic mesh offers will not be supported in the new terrain mesh, but that is a compromise we need to take to achieve our exporting goal.

Jacob modifed the terrain generator to produce a custom mesh instead, and this new mesh resulted in a very reliable export feature that supported everything that would be required in the project.

The application needed a way for the user to move around, so Marcus worked on implementing a camera movement script.

The current FBX exporter is still depending on the Unity Editor. This is a major concern and currently blocks us from our goal of having a standalone binary. We need to look into alternatives or else we have to change our goals and explain why it would not work. Jacob is searching for other ways at the moment and hopefully has a solution next week.

Another meeting with Staffan resulted in very constructive feedback regarding our current project plan up to this week.

We decided we wanted to find some tools for spell-checking and grammar-checking, so we tried a few different tools. Grammarly turned out to be the most useful one because it helped us phrase our sentences more consistently and more “scientific”, basically giving our report more credibility.

Another tool we investigated was textidote, which is a tool for LaTeX for spelling, grammar and general LaTeX syntax checking. We mostly used this for the syntax, since grammarly did a much better job at spelling and grammar.

By this time, most of us had finished and passed the Chalmers Library Education Online assignment which consisted of a variety of writing technique questions, such as how to reference sources properly, evaluating source credibility and more.

This week we discussed more methods and algorithms that are commonly used in procedurally generated content. Wave Function Collapse came up as a possible algorithm instead of the current road generation algorithm, but we decided to not pursue it given that the Agent-based generator would give suitable results.

Some of the eventual problems that could pose an issue for our project if we were to use Wave Function Collapse is that our city is not really two-dimensional, but that could be avoided. The biggest issue is that from what we found during our research of Wave Function Collapse is that it often results in rectangular results, but we did not want that type of consistency in our city which is why we decided to stick with our current Agent-based method.

We also talked about machine learning and Search-based AI, but we realized that there is not really a clear definition of how “good” a road is, and that is needed for the AI to be taught. One could potentially input real world data which would teach the AI to generate similar cities, however, none of us were very experienced in the machine learning field and thus we decided to skip this.

Unity and C# are by far the easiest tools to use for our project, and it suits our needs completely. Some of us are already familiar with Unity and C#. Everything that the project needs (and more) is offered within Unity, as well as very powerful debugging and profiling tools. Lots of features that we want to implement can easily be done with Unity compared to other tools available.

Some alternatives that were researched up to this week was C++ Raylib, Java LWGJL, and Java jMonkeyEngine, but these were ruled out mostly because they lacked most of the tools that we would need which Unity already had. Choosing one of those alternatives would mean we would have to reimplement a lot of basic functionality that would only postpone actual development of the project.

Jacob wrote and held a presentation of Unity and some potential techniques that could be used for certain generation parts. This helped the group get started with some Unity concepts.

For the most part, this week was spent writing the project plan and the first draft was quickly completed in order to get feedback from our supervisor.

Something that we quickly realized would be important for writing the project plan and report was terminology. Even within our group, we realized that there were inconsistency in the meaning of words and that meant that we had to define these very strictly in the report in order to avoid confusion for the reader and ourselves. We spent a while carefully defining these and they can be found in the glossary of the project plan.

The first method of road generation turned out to be best suited for our project, but the second method will be considered for plot generation in the future. A lot of progress was made on making the road generation as flexible as possible, as well as tuning the results.

The road generator now lets each agent to have its own strategy for generation which they will follow. One example of a road strategy that is used is the Paris or Manhattan strategy, which basically means the agents will walk around and place roads that mimic the structure of these cities.

For the world generator, we defined an architecture that the program will follow which basically means that we have created a design for the algorithm as a whole. This architecture treats each subgenerator as an isolated function.

It was useful to get a lot of work done this early and we quickly got a perspective of how the city generation would work. Lots of great feedback from our supervisor resulted in a better writing technique and better results from the algorithm.

Lots of subjects were brought up during the workshops this week, such as what methods we wanted to use for different parts of the world generation. We quickly came up with two methods of generating roads, and because we could not all agree on one method we decided it was best to create two separate demos that would demonstrate the pros and cons of each approach.

The first demo would make use of road building Agents that would be deployed onto a 2D-plane, and they would place down roads while interacting with the road network. This would initially be a very basic system that would simply have Agents walk in straight lines and sometimes branch off into more Agents.

The second demo would use a recursive approach where it splits the world into small cells, and each cell would further be subdivided. The idea was to place down a lot of points, split the cell into two by creating a line between each point, and then recursively applying that algorithm into more detail.

We decided to postpone selecting which tools to use for our project until next week, because we wanted to research which tool would suit us best and needed more time.

We decided to use Google Calendar for scheduled meetings, and that we should have two lunch meetings as well as 3 opt-out workshops every week. The lunch meetings were usually an hour long, over lunch, while all the workshops were 4 hours long, placed during Thursday afternoon, Friday morning and Friday afternoon. The purpose of the workshops is to meet up with the group to sit down and get work done, while also being able to get help from each other.

For communication, we decided to use Slack as everyone was familiar with it, which also gave us a more organized form of communication than other platforms would offer (for example, Messenger).

File sharing and development ended up being Google Drive and Github respectively. All our documents and resources we collect during the projects lifetime would be placed in Drive for ease of access, while the project code and report will be stored in two separate Github repositories for version control.

We got to meet our supervisor, Staffan, during this week which guided us to get a good start with the project, and we were also able to ask any questions we had before getting started.

Most of us who were available also attended the introductory seminars during this week.

The rest of the time was spent invididually, researching different aspects of the project to get a deeper understanding of what requirements and specifications our project would need.