Tech - Post-Mortem
Introduction
The goal for the project was to create an Environment pack aimed at the Unreal Engine marketplace. This would consist of a smaller sub-set of packs including:
Large Prop Asset Pack
Clutter Asset Pack
Building Asset Pack
Materials Pack
Particle Effect Pack
Decal Pack
Tools Pack
My responsibilities during the project was to make content for the Tools, Decal and Effects pack as well as contributing to the Material pack. I also aided in fixing any technical issues we came across during the project as well as helping with the visual direction of the project.
Project Details
My time was split between many different aspects of the project at any given point in time during the project. Although I had a main focus for each week I was continuously fixing bugs helping Kit, or doing additional research. This is a breakdown of what my main focus was for the duration of the weeks.
Project Week Main Task Undertaken – (See blog posts for more detail)
2 Prototyping tools
4 Material pack
6 Modular Building Tool
8 Spline Tool
9 Random Asset Placement Tool
11 Decals
13 Particle Effects
14 Random Asset Placement Tool
15 Material pack
16 Random Asset Placement Tool
18 User Guides/ Videos, Post-Mortem
Technical specifics
Our main audience for the project was the Unreal Engine Marketplace. As the marketplace has specific requirements to meet when submitting work to it, I had something to reference to when to make sure it was suitable.
“BLUEPRINT REQUIREMENTS
LAYOUT AND NAMING
All Blueprints submitted should include a video demonstrating how they are used. No Blueprint submissions will be accepted without a video.
LAYOUT AND NAMING
All Blueprints must be neatly laid out and make reasonable use of Blueprint functions to organize the overall logic structure. Functions, variables, and events should all use names that reflect their intended purpose or use in the Blueprint.
COMMENTING AND DOCUMENTATION
Blueprints must be thoroughly commented with explanations of the function and operation of the Blueprints. In general more useful comments will explain the ‘why?’ rather than the ‘how?’, and any comments that merely provide labels should be avoided. “
Tools
My main focus during the project was the development of 3 tools that were created to speed up the process of creating environments using the pack. They were to be developed alongside the rest of the packs, so where made specifically to work with our Environment pack but also should be able to work independently, providing that the user kept to the guidelines provided.
Modular Building Tool
The Modular Building tool came from the need of a way to quickly create buildings using the modular wall and roof tiles found in the 'Building Asset Pack'. This meant being able to create variable sized buildings and choose what meshes you want to apply where on the building to create a variety of different outcomes using the same tool. This also needed to keep everything together so that whole buildings could be moved around without having to move the individual modular pieces.
I managed to achieve this and created a blueprint asset that you can place in the level and build the buildings using it. Although the tool I made worked well when looking into how we wanted to improve and progress the tool I came across some issues this the fact that it is made solely using blueprints. In its current state if you decide to change the size of the building after you have changed the location of meshes it will move their placement. Unfortunately after extensive research into how to change this I came across several roadblocks.
The lack of implementation of 2d arrays with the blueprint system meant that there is no way of creating a user friendly and easy to change way around this problem. We had hoped of creating a floor based system that allows you to pick how many floors you want so that when you change the size of the building, adding or removing floors, it wouldn't move the meshes around. Another solution I tried was finding a way getting the blueprint to place other blueprints. That way it could have a blueprint per floor all controlled by the one blueprint. But as well the ability to create this only using blueprint isn't there. I found this a lot during the project, having to find create solutions to other size easy to code problems if I was using C++. This didn't come to much of a surprise as the blueprint system has only been widely available for less than a year when we started the project.
To help with further development of the system I did send feature requests for these problems to EPIC, which have been noted and added to part of their development of the engine.
Although I wasn't able to add the floor based system to the tool I was however able to add other features alongside the placement of walls and roofs.
Kit found that where different meshes meet on the corners of the building it was difficult to always get it to look realistic as it gave an unrealistic sharp edge to the building. So to overcome this I added the ability to add corner meshes to the building that are placed over the corners to cover the sharp edge and add more variation to the building without taking anything away. This feature is completely optional and can be turned on or off for each instance of the tool.
To break up the modularity of the buildings you need to add extra meshes to the face of it to give it more variation. This is easy to do in engine by just placing assets in front of the building but made it difficult then wanting to move the building as the assets you've dressed the building with won't move with it and require you to individually select all the assets you've placed and move those as well. I overcame this by adding the 'Additional Mesh' feature that allows you to add furniture meshes to the tool and place them in relation to the building, in the same way you would have before. But as they are part of the tool they move when you move the building. It also makes it a lot easier to change the meshes out without changing their location which is much more useful than the standard way of placing and changing meshes outsize of the tool.
Spline Tool
After the initial visual research looking into where we wanted to take the project visually we found out that across all slums from in most parts of the world there is an abundance of exposed and hanging cables. To make that easy to do in engine we wanted an easy way to place cable meshes that could be easily edited and swapped around to give as much visual variation as possible. This is when the 'Spline Tool' was born.
To fulfil these requirements it was going to have to be a versatile tool. So I tried to include as many different ways of placing objects along a spline as I could. The final version allows for all the different ways to be used at the same time all driven by the one spline. This allows the user to compile different meshes together to create a wide array of outcomes.
One feature that was added, after feedback from Kit, was the ability to place light actors. He wanted to be able to use the spline to string up fairy lights in the level. Using a separate meshes for the cable and bulbs but there was no easy way to place the light that would be produced by the bulbs. As he was using the 'Equally Spaced Along Spline' feature to place the bulbs I used the same way to place the lights, meaning you could get them to match the position of the mesh exactly. However as the light actors where being placed by a blueprint, and where therefore children of the blueprint, you aren't able to click on them individually and edit their properties like you would if you placed the light actor yourself. To overcome this I exposed as many of the light actor variables as it would allow but unfortunately this is still slightly restricting as not everything can be edited. It has recently been announced that blueprints child actors will be editable in the details panel in the 4.8 release of the engine, which would be great for moving this tool forward, but has come too late for this project.
Random Asset Placement Tool
The third tool I worked on was the 'Random Asset Placement Tool'. This had a change in direction after getting feedback on it from someone in industry, Jolyon Webb. The prototype I was working on and got feedback on fulfilled the brief for what we wanted it to do but wasn't very smart with regards to how it placed assets.
The tool itself is one that places multiple assets randomly in a level making it quick and easy to populate an environment. I had this working but it was done by you setting an area and it would completely randomly place the assets within the area you've set. Jolyon pointed out that when objects accumulate like this in the world they don’t tend to just be in a set area. You find that objects build up where vertical and horizontal planes meet. Taking this on board I looked into other ways of placing assets in a way that would better represent real world placement of objects.
I finished the first tool so that it met the brief but then continued working on the new one. The aim was to have it so that you again chose the area in which you place the assets but instead it would find where the walls and floor meet and place the assets there, gradually spreading outwards. Given the time restraint of the project and having the rest of the packs to work on I had to pull this one in a bit so that instead of it finding where the walls meet the floor you point it in the right direction. This is done by drawing the spline with the arrows along it pointing towards the faces in which you want the meshes to accumulate under. It then uses a curve to work out how far from the wall it should place the assets. This curve is editable so that the user can change the spread of the assets and how the tool works.
Part of the brief was to make it so that you can tweak the location of the assets after they have been placed to fix any visual bugs. I wasn't able to get this unfortunately as I had many issues with trying to get the tool to be more reliable with its initial placement of the assets. Although this feature does work on the first version of the 'Random Placement Tool'.
This is defiantly something I'd be looking to implement moving forward with this tool as well as finding a way to get it to recognise where the vertical and horizontal planes meet and have it driven by a volume instead of a spline.
Decals
Decals are another section of the project I worked on. The main focus of my work for the decals was making graffiti. This was something that we found was in abundance throughout all our visual research at the start of the project. Given that graffiti is very rarely, if not ever the same, I wanted a solution that would allow the user to have many options to choose from, but without having to use a different texture for each individual piece. As this would take up a vast amount of memory and require loading many texture samples. To overcome this I created a custom decal actor that allows the use of atlased textures that you can input the amount of columns and rows of graffiti and it would then allow you to pick which one you want to use. It also allows you to use textures that have different masks on the separate Red, Green and Blue channels and then set the colour in the actor. That alongside the weathering effects it has become a much more versatile tool that I had first planned it to be, as such I have not only used for graffiti but painted road markings also.
To give the user as many options as possible for making roads without giving them many static meshes all with different textures we wanted to find a solution using the tools we already had. Kit made a generic road mesh to that can be used with the spline tool to draw out the roads and I made a variation of the spline tool that allows you to draw out the road markings. Although this does mean more meshes being placed in the environment it uses less textures and takes up less memory that other options. It also means that the user can create any variation of road layout that they like.
Materials
The meshes we are providing as part of the 'Environment Pack' needed to be as reusable as possible. One way to do this is having variations in the material for each instance of the mesh. Vertex painting is a cheap and easy way to make small variations that change the mesh enough so that it looks different to another instance of it. But it takes time and can be difficult to setup if you are less experienced with shaders. I created a set of material functions that are part of the 'Material Pack' to speed up and streamline the process of implementing vertex painted textures into materials.
As well as the material functions, I made master materials that allow you to input your texture samples in an instance of it and you can vertex paint the different textures without ever having to open the material. This has its benefits as the engine only has to compile the master material once and it can then just call the texture samples from memory for each instance without having to compile the material for every mesh, as well as being easy to use.
One of the materials that changed the most during the project was the Ocean shader. My goal with this material was to create it using as few textures as possible. I started off by using sine waves to create the displacement for the waves and given this doesn't use a texture gave a really smooth wave that worked really well. Unfortunately it tiled really badly. When viewed from lower angles it wasn't too bad but once Kit changed the demo environment to have more verticality we soon realised that it wasn't going to be a viable solution.
Then to avoid using several normal maps I instead opted to have a single texture that utilised the 3 different colour channels to hold 3 different height maps. In the shader itself I was able to convert these height maps to normal information as well as using them for displacement, as masks for colour changes in the water and placement of foam on the peaks of the waves.
Particle Effects
To go with the ocean shader we wanted a particle effect for where the water splashes against any objects the waves collide with. As no wave splashes are ever the same I needed to make them as varied as possible. I used a sprite sheet with 4 different splashes on it to sample from as well as it randomly flipping the UVs to create even more variation. Using random ranges to pick to the height/ intensity of the splash was key to getting that varied feel. The particle worked well but when placed in engine we found it was obvious that the spawn location of the particle system was the same every time. So instead I had it so that you draw a spline and it will spawn at any random location along the spline. I also exposed some variables making it so that you can set the range of the time delay between each splash and also how many splashes would spawn at any given time. This fixed the previous issue but I would have liked to do another particle system with a completely different looking splash, so that I can get it to randomly pick which particle system it would spawn along the spline as well giving even more variation to the overall effect.
Conclusion
Looking back at this project there are somethings I would do differently. Having a clearer view of what the end product is going to be would have made things a lot easier. But I knew going into this project that it was going to be a very research and development based project. I would have liked to be able to use C++ as it would have made a lot of problems effectively disappear. I think though given my very minimal knowledge in the language it would have meant only doing the tools and not had the opportunity to do the work with the other parts of the Environment pack.
Through the research and development done during this project though I have defiantly leant a lot. Things that I can carry across onto other programs and into other projects in the future, whether that’s specific technical knowledge, for example learning about 2d arrays and how they work, alternatives ways of doing things, for instance distorting UVs to create motion in materials instead of using flipbook textures, or just refreshing things I haven’t done in a long time, using vector maths (specifically in the ‘Random Asset Placement Tool’).
This was one of the first projects that I managed to keep on top of my schedule for. Although the schedule was designed to be flexible as the project itself was very nonlinear. I think making sure you I allow for time spent in the unknown is defiantly something I’ll be factoring in to all projects I do in the future.
There are aspects of the project I would like to continue working on. Specifically the tools, with some of the engine features coming in the next release and knowing where I’d like to take them next, I think it would wrong not to see if I can push them to the next level outside of the confines of the final project. Any tool can always be improved and worked on, but as I’ve already know where I want to take them I think it would be good, especially for taking this to perspective employers as I can show them: this is what I can do in a set time, these where the restrictions I had, etc. given more development this is where I’ve got it now.
Otherwise this project was a huge learning curve into tools development and working as a technical artist. Of which I am very pleased with the products I have produced and I look forward to moving thing further in the future and using what I have learnt in new and even more interesting ways on other projects.
