Hilbert Curve Procedural Project

View fullsize

Click for better view

Problem

The last project for Tech Art class was to do anything with the only requirements being weekly updates. I’ve always liked the idea of procedural content especially when it comes to dungeon/level layouts. Oddly enough, I felt like I had more experience C++ coding in Unreal Engine 4 than working with Houdini and I felt that any time I spent learning more Houdini would take away from my research time. So for the project I needed to make a procedural dungeon maker in UE4.

Solution

At the end of the day the project goal wasn’t to make a dungeon maker but something that could make the golden path for a level and add dead ends to that path to make it interesting. There are many ways to do this and the solution really depends on the game. However, I was doing this as a fun way to learn about procedural content generation and not to for a game. So I picked a pre existing solution that really intrigued me. I would make the golden path based off of a Hilbert Curve algorithm much like what was used in Galak-Z.

Process

The beginning of the project was focused heavily on collecting and examining resources on the subject. After settling on approaching the problem the same way as Galak-Z I began making prototypes just for producing a Hilbert Curve. I will note I looked into other methods such as using 2d physics to blaw the rooms into place or cell automata. Once I could successfully produce a Hilbert Curve of varying dimensions I looked into how I could walk along that path to make the golden path.

The approach is probably the same as Galak-Z minus specific rules for picking points along the Hilbert Curve. That is we walk along the hilbert curve and only mark points that fall within a specific area on the curve. Say the Hilbert Curve is a size of 16x16 then we would use an area, a sample size, of 8x8. So we have a curve path we walk and a path specific to the sample size that we will use for the golden path. When the curve path we are walking exits the sample size we just continue the golden path when the curve path re enters the sample size. Sometimes a point on the curve path will never lead back into the sample size. These points are marked for later and can be used as dead ends to add variety to the golden path.

Once I got the golden path running with dead ends I was happy. However, I still needed a visually appealing way to show this in engine. I tried approaching this as if I had to take everything I did for this project and hand it off to a level designer or environment artist to use. In engine the algorithm would randomly pick from premade rooms to place along the path. The question then was would you use level streaming or blueprints to make these premade rooms. I used blueprints for testing and level streaming for the actual rooms themselves. I think from a user perspective it’s more time consuming to make edits in a blueprint and compile than it is to make changes to a sub level especially when lighting is involved. The only issue I ran into was getting level streaming to work in C++. Eventually I had scrap it and have all the streaming code in a blueprint that would talk to containers or functions I made in C++.

View fullsize

Test Path

View fullsize

Test Path with premade rooms

Code

Github link to view the code.

The main class in the code is the LayoutGenerator. It talks to or knows about the Cell, Grid, and Hilbert. The LayoutGenerator contains a Layout which is a Grid and a Grid contains a couple collections of Cells. The Cells know a few things like what Cell came before them, what type of Cell, the direction of the Cell, etc.

UE4 Mannequin Importer

Problem

This tool was made on project lead request. The initial request was a shelf button for Maya that could import the UE4 mannequin into the scene. The idea was the environment artist would have an easy way to scale assets in Maya to what would be in game. Since the project was a virtual reality game in UE4 the mannequin was already at a good scale for the project.

However, this was the first tool I made for the team so the problem wasn’t as simple as making a shelf button. The tool and future tools would need to be available for any member on the team. In addition some of these team members where working remote and had different computer setups compared to the environment artist who would mainly be using this tool.

Solution

The solution begins with the common factor on the project. We all use Perforce. I understand distributing tools this way is undesirable since perforce is a version control software and not a tool for distribution but it’s all I had at the time and seemed like the best fit for the team. On the teams Perforce we had a directory for Tools that contained several folders accessible from Maya thanks to the mod file which is a way of telling Maya to look in other places for scripts and other directory files. You can even add environment variables with mod files that persist for Maya and not the system.

This means instead of installing each Maya tool all a user would have to do is install the mod file into their version of Maya. This is taken care of with a bat file which also sets environment variables that point to the Perforce directory. For the majority of the team the Perforce directory was located on the same drive but this was not the case for the rest of the team. I would have liked to kept this functionality to the mod file itself but I couldn’t find any documentation on getting directory locations within a mod file.

Lastly a UserSetup.py file loads up the shelf that holds the tool. The tool itself imports an fbx file located in the directory the mod file points to. If needed the tool could be extended to support selection of different object for scale.

Feedback

There was no feedback for this tool. Instead, the tool produced an interesting outcome for the environment artist. This artist changed their workflow on the project for the better. Previously they would keep all meshes in a single ma file to keep the scale consistent. However, being able to easily import an object for scaling allowed them to keep meshes separated. This allowed the artist to be more organized and even sped up the export process while working.

Process

This tool wasn’t gui heavy so the it was more important to talk to teammates than to plan out on paper what needed to be done. Specifically, I needed a better understanding of what type of tools would be needed in the future. Beyond that I would spend time with the artist walking them through the installation process and making sure to test the tool on their machine with them.

Code

Github Link to view the code.

The meat of this tool is the fbx_helper.py. At the time I was under the assumption I would need to make some form of exporter tool so I wanted to try and start a library now for latter. The fbx_importer.py calls the helper and imports the mannequin. The glasscat.mod file is what Maya reads to know where the extra directories are located. Since the teams Perforce directory could be anywhere I’m using an environment variable to point to the directory that contains the extra directory. Lastly the Glasscat_Mod_Installer.bat looks for a modules folder on the users documents Maya directory and makes one if none exists. The mod file is copied to this directory and then some environment variables that point to the Perforce directory on the machine are set.

Renamer Tool

Third Pass

Problem

At the time of creating this tool the environment artist on my team had always spent tedious amounts of time renaming texture maps once they were imported into Unreal Engine 4. The specific problem is each texture name would have some part that is similar or not needed but each could only be edited individually. As it turned out this was a time sink that all artists on the team had.

Solution

At the the time the solution was to create a single executable tool that could be used to rename multiple files in one go. The tool was made with PyQt and Python. The tool works by dragging and dropping files into the application window. These files are then placed in a list view so changes can be previewed before being committed. The user has the option to find text within the names and then replace that text with nothing or something.

Feedback

After the initial pass on the renamer tool I got various and similar feedback from the artist that would use it. The biggest request was the ability to select and copy text from the name in the preview list. Other feedback consisted of changing the color and some design considerations with the buttons. Particularly the artists wanted a look similar to Photoshops dark theme.

Process

The creation of the renamer began on paper. This wasn’t just to do a rough sketch of some gui but to get a better idea of what I might need to code. I say might because I often abandon most of the ideas I start with and pivot to different ideas. This usually means the sketches and notes I have quickly devolve into nonsense. Useful nonsense!

Code

Github Link to view the code.

The code itself is broken into different py files all with their own classes. In fact the gui_helper.py has many classes that inherit from QWidget since I’m not using QT Designer to make the gui. As one would guess the gui_helper.py handles anything involving the gui, the file_helper.py handles anything involving file management, the renamer.py contains the main function used to kick everything off, the style_holder.py holds the css information used for the gui, and the pyinstaller_renamer.bat creates the executable for the application.

First Pass

Second Pass… If your curious those are builds for a Qt application made with C++