This is techno-sorcery!
Unite India is here: https://unity.com/event/unite-india-2019
there is no need to create a vdb, but it works yes
4 artists from De Montfort University gave s super detailed look into the production of their amazing complex interactive environment with UE4. It’s a great look into the smallest details of the creative process. The final scene looks absolutely amazing.
We are all 3rd year Game Art students at De Montfort University about to graduate. This was our final major project (FMP) which lasted 20 weeks total. Our team consists of Andrew Simpson & Mark Eastland (environment artists/all 3D work), Denise Jones (concept artist/all 2D work) and Dominic Mathuse (technical artist/functionality).
Video with concepts (no music):
As we’ve just finished our studies, we’ve mostly only worked on university projects, but we have taken part in a couple of game jams. This was the first project we’ve worked on all together, and it was good to have some time focusing on what we want to be.
This project was mainly chosen because it had opportunities for each of us to contribute using our individual specialities. Not only this, it would force us to develop skills in these areas which are essential to have – skills that are standard in industry and vital for employment.
Andrew and Mark were required to learn a few programs, for example, they had used ZBrush in the past at a rudimentary level and therefore needed to develop a better understanding and skills in the program in order to produce good quality sculpts; also, to really speed up their workflow for making assets and add detail that only sculpting can do.
Meanwhile Denise scarcely touched on environment concept art beforehand, but she wanted to broaden her skills and gain experience in her weakest areas, choosing to work in a group as a valuable learning curve in many ways as it requires a different approach to when working on your own.
As for Dominic he wanted to further his knowledge in scripting and get a deeper understanding of shaders, especially in ways that could help support the art teams and make their workflow easier.
We all had areas we needed to get better at and this project offered the opportunity to do this.
For reference, here’s a topdown to identify the areas we talk about:
The main elements involved:
– The landscape. It was all blocked out using the landscape tool in UE4 to get a general composition, but at that point, we didn’t know how to go about making this kind of setting. We knew there were a couple of options we could try, but it had to be fast. World machine was one option which would have worked and probably would have ended up looking much nicer. However, due to the time constraints and other things which needed addressing, mountain billboards and rocks were placed instead. They were a half-placeholder which never got changed as people didn’t notice. The benefit to this is that it’s incredibly cheap and quick to move around should it need changing.
Mountain Billboards – not a pretty angle:
Attempt at World Machine (Didn’t use):
– Hero assets. There were a few assets which were completely unique and originally intended to be used very few times.
These were created from the concepts and the general workflow involved was: Base mesh, ZBrush, Decimate, 3D Coat Retopology, Bake in 3DS Max, then texture in Quixel.
– Inventory/Crafting & Climbing Mechanics. We discussed implementing some gameplay elements into the level and as a result decided to include these. Dominic felt comfortable enough to attempt scripting these using blueprints in UE4 and started off with testing out some simple climbing mechanics, which soon turned into a fully fledged system that uses splines to dictate where the player would move along. This gave the team flexibility to later on adjust the climbable parts within the level. The inventory system was added later on and we originally wanted to include quite a few items to be picked up and different crafting sets, however we fell short on time and instead just included 3 items which could be crafted into a torch to keep it more simple.
The entire project from start to finish was 20 weeks. This included initial ideas, research, planning and presenting. However, we had group meetings about what we wanted our FMP to be a few weeks before the start date so that we could collectively agree on a setting that could showcase what we have to offer.
Whilst blocking out, we knew that whatever ideas we came up with were purely temporary and subject to change. At this point, the environment artists were trying to come up with map layouts and ideas for interaction in the level, climbing paths etc., and quick sketch overs were done to see which ideas were worth pursuing.
Very early on we also realised the map was too big so we had to make some cuts. The biggest one we made was the villagewalk at the beginning. Denise did some quick sketch overs on our block-outs, but the decision was made to make the vista & temple the main focus.
The other idea we wanted to pursue was the Indiana Jones type of adventure where the player picks up the artefact from inside the temple and that’s when it all begins to collapse (that’d be the point our level would end, with a piece of debris falling on top of the player). This also was too ambitious for our speed at the time, meaning that had to be changed half-way through to what we have now.
Very early blockouts for idea generation:
Initially, the general process we wanted to follow looked like this:
This meant that there would always be work to do for everyone and would minimise bottlenecking/waiting around before being able to continue. This unfortunately didn’t happen as things took longer for us to make than expected as we were trying to learn at the same time. Before we knew it, there wasn’t enough time to put as much detail & effort as we wanted to into the ending which meant it was rather rushed and didn’t really make sense.
In terms of tools we used:
Dom made/setup: (Spline tool in UE4, 3DS Max mesh exporter, Setup Perforce, UI 3d widgets which can be adapted for any text + images and include an adjustable destroy radius).
The environment artists used a few free scripts to aid the process. These included:
– ‘Get Baked’: A tool by Mike Pickton to help with baking any kind of map & creating cages.
– ‘Weighted Vertex Normals’ Arrimus 3D:
– ‘Debris Maker 2.0’ by Aaron Dabelow for base meshes of twigs and small stones + used in initial block-out phase.
The biggest elements involved:
– Modular pieces: The temple was constructed through simple modular wall pieces with a width of 0.5m and lengths of 1m, 2.5m, 5m & 10m. To get corner pieces, you can use the symmetry modifier and rotate it 90 degrees.
This meant we could change the scale or layout of the temple for iterative purposes. The base tillable for this was sculpted in ZBrush and textured in Quixel.
– Rocks: The rocks played a similar role, as they are extremely versatile. We intentionally tried to make them look different from all 4 angles, adding to the reusability of them.
– Foliage: The foliage was important for breaking up any repetition, getting some greenery in there, and to add to the cluttered/overgrown look we wanted. The majority of our foliage was made using photographs, editing in Photoshop, and modelling the plants in 3ds Max by hand. The only things we used SpeedTree for were the tree canopy and roots. The reason for this was mostly due to time as it was far quicker to do this than in 3DS Max with splines.
This kind of approach with modular components means you can iterate constantly as they act like Lego blocks when building your environment. There may also be times when you need something to fill in a blank space, but you haven’t got time to make anything new – you can use them as a bash kit and see what you can make using what you’ve already got.
The first scene with the mountain view of the valley looks absolutely incredible. How did you create the background here?
The vista shot was a lot of trial and error, and there’s so much more that could be done with it. None of us had used World Machine before so that was one attempt which looked perfectly good in terms of the shape and forms, but we felt it would be so much cheaper to use a mixture of billboards + rock models instead (again, also partly due to time restraints).
As the mountains were simply photographs, they needed a little bit of tweaking to get them to sit right in the lighting set up we had. This involved a quick colour overlay, brightness and contrast changes to match with everything else.
The rice paddies were made using Dom’s spline tool, so we only needed a cross-section of a paddy which could then be used to create any shaped one we’d like. A similar technique was applied to the vines.
The concepts were also a strong inspiration and helped us decide upon the golden hour lighting that really helps add to the atmosphere. Elements such as the importance of giving the impression of more lush, colourful foliage and hints of other, similar architecture in the distance to increase a sense of scale were inspired by her concepts too.
We modelled all of the foliage ourselves except for the tree canopy and roots in the cave. They were done using SpeedTree which was mind-blowingly fast to get decent results.
The main trunk and roots of the trees were modelled and ZBrush. They were originally going to be part of a modular tree that we would be able to build in engine using the spline tool that Dom made using blueprints, however, due to complications and bugs we opted to rethink the way we approach the Trees. So using SpeedTree we were able to produce a quick fix for the canopy.
The rest of the foliage was done by hand. The general process for this was creating the albedo in Photoshop, then modelling the plants in 3DS Max whilst trying to keep overdraw to a minimum.
Building Natural Materials
In terms of the materials, as mentioned we used Quixel for pretty much everything. Their material library is huge so you should be able to achieve pretty much anything you want. We generally used smart materials for a base, changed the parameters in the albedo & roughness, and then built on top of that by painting in colours and masking in materials by hand.
Did you make as many unique materials as possible, or did you try to reuse different materials in a different way within one scene?
We tried to use everything we made multiple times to ensure we were getting good use out of them. Also, most things had a unique texture sheet as things were very quick to texture in Quixel, and we could easily change it if we needed to.
The modular wall pieces were textured using a sculpted tillable wall texture. This texture was applied to nearly all the wall pieces using different unwraps to coincide the mesh and form of the asset.
As the theme is based around Indonesian (especially Balinese) folklore and religions, the architectural and visual styles needed to fit in with the narrative we wanted to develop. We did take liberties with the design of the temples to give it our own spin – which were explored a lot in the initial concept phase. We saw the patterns in a couple of books which were then remade in Photoshop as stamps to be used for our high poly sculpts. The concepts also reflect specific traditional characters, as they were used as the base of inspiration and their underlying narrative to tie everything together design-wise.
Our concept artist provided the general narrative of the level which is:
“Rangda, demon queen of black magic and creator of disease, has long been imprisoned by the efforts of Vishnu: the preserver and guardian of mankind. Within his loyal subject’s stomach, swallowed and contained by Garuda, the fiend now rests. Yet time has passed, memories in the minds of civilisation have faded and the temple has fallen into desuetude. The seal upon Rangda is weakening.”
We used foliage as a way to break up the repeating elements of the modular pieces which works in favour with the overgrown temple design we had in mind.
Individual temple bricks which matched the tillable texture on the modular temple walls were placed around and intersected with them to break up any repeating elements and gave further shape/form and hide away any obvious geometry. The bricks also provided a nice bash kit to create rubble and crumbling parts to the temple.
One thing we had to consider was the placement of the entrance to the temple. Our original idea was to have one side collapsed creating a natural entrance. However, this didn’t work well with the composition and there weren’t any indications to the player as to where they should be going.
Another thing to consider was the colours. The forms were doing what we wanted them to which was to draw your eyes towards the middle and hopefully the player would clock “I need to get in there”. At the time, everything was just blending into each other not really visually interesting.
In the image below part way through, you can see the wings were just standard stone with some gold trim. This was changed however when it became noticeable that the colour palette just wasn’t working and detracted from the potential of the assets. As a result our concept artist spent a few minutes quickly adding in a much more vibrant range of colours to add interest to the scene to communicate a much more tropical atmosphere while using the complimentary, hot colours in the centre to immediately draw the players’ focus to the desired focal point: the doorway. This quick paintover was enough for the environment artists to re-texture & light the scene better.
Inside the cave, we wanted it to feel a little bit cold, but by making the lanterns really stand out in red providing a warm source, seemed to add a little area of interest which we could use to lead the player where we wanted them to go. The same goes for the skulls; red candle wax and light sources to lead the player through.
Lastly, colour in the vista screenshot was used to lead the eye. The blue sheet for the wooden shack stands out amongst the greens and browns, plus, the flowers dotted around also add a bit of colour to the scene.
There were a lot of static lights placed around with small attenuation radii. We used a dynamic directional light for the sunlight so as the foliage moves in the wind, the shadows move with them. A lot of fake lighting was used in the level in order to lead the players’ eye and give a clearer path as to where they have to go, this is done a lot in games usually without us noticing as we’re drawn to the lighter areas.
For the cave scene, again a lot of faking was used to get the desired effect. The hole with light seeping in is blocked using an emissive plane with a spotlight in front of it to give the impression of a blown-out sky. In the post process, the highlights were crushed in this area for a more dramatic effect.
Subtly coloured lights were used in areas you wouldn’t have thought as they can give the scenes a little bit of a pop to avoid them looking too bland. Without the coloured lights, some areas would be rather bland as most of it is just rock/stone and plants. Admittedly this could be done in a more subtle way, but we’ve still got so much to learn with lighting.
Shaders and Effects
Fire & water can be tricky things to do. A lot of tricks/techniques that we know are down to finding tutorials and learning other people’s approaches, then building from there. The fire was made by following a great tutorial by imbueFX; initially for UDK, but 99% applies to UE4.
imbueFX Fire Tutorial:
In short, it uses: the ‘SubImage Index’ module to spawn randomly 1 of 4 different flames, a very simple smoke alpha, and the ‘RadialGradientExponential’ material for the embers (this can be used for quite a few different effects). The light coming from the fire is a blueprinted point light with varying intensity as this was far cheaper than the particle light module in cascade.
The waterfall material was made by using a series of masks (retrospectively could be made better), multiplied together and panning downwards. The final mask was used for opacity and refraction – we could tweak it by using the following parameters:
The water for the courtyard uses a base water shader with a couple of parameters that we adjusted to achieve the right effect.
For the opacity, we are using both the scene depth and the pixel depth to give us the depth of the water from the surface. This allows for the water to appear more see-through in more shallow areas and opaque in areas where the water is deep. We also added a minimum opacity slider, so that in very shallow areas the water itself is still slightly visible. Finally, we added depth fade, so that the water fades out when it intersects with another opaque material, which gets rid of seams in those areas.
For the roughness we are simply using an inverted opacity, so that in the more see-through areas the reflections would be more rough, while the areas where the water is really deep and opaque will give us nice clear reflections. The base color, emissive and metallic channels are all controlled by parameters that we messed around with until we thought it looked right.
The normal map was another complex part, for which we wanted to have 2 panning normal maps that move in opposite directions to create ripples on the water surface. Dominic decided to have these not only be world aligned, but also made them so they’d work regardless of the rotation of the water plane. For this he used the values of different channels of the vertex normal and used them to lerp between projections of the normal map.
In terms of software, we used 3DS Max for modelling & baking, Bitmap2Material3 for tillable landscape textures, CrazyBump for some foliage normal maps, SpeedTree for the canopy & roots, ZBrush to sculpt + add damage, 3D Coat to retopologise, and Quixel for texturing. Andrew and Mark were both very new to some of these programs and had to quickly learn the basics whilst producing the assets.
To build the materials for our foliage, the process involved processing photos in Photoshop to get the albedo, followed by a height (to extract the normal), then a roughness. In engine, we set up material instance parameters to control hue, brightness, contrast, saturation, roughness, normal map strength. This meant that tweaking things were very quick if it involved minor alterations.
For the rest of the assets, Quixel 2.0 allowed us to produce textures rather fast which looked great as is. Being able to paint directly onto the model using their variety of brushes was great for adding the smaller details and roughness/colour variation. For roughness maps, it is good to have contrasting variation to make it pop a little bit more when the light hits it (this definitely depends on the material and environment it is in, but generally works well).
We initially had a quite a few ideas and puzzles we wanted to do as you progressed. Shortly after beginning though, we realised this wouldn’t be possible at the current progress speed.
Instead we focused on more simple interactive elements, that we could implement to make the level feel a bit more like a game rather than an experience. One of the first things we decided to include were a set of climbing mechanics, which we ended up using on the side of the temple in the finished level. The mechanics allow the player to jump up to a ledge and climb along it, as well as pull themselves up onto it. It also allows for the player to climb from one ledge to another and slide along the top of an edge.
We also decided that we wanted to include a little inventory and crafting system, so we placed a few items towards the beginning of the level that the player could pick up and inspect from all different angles. After picking up all 3 items, the player would then be able to craft a torch out of it, which we used later on in the level to let the player navigate through a cave.
The biggest challenges with these interactive elements were really just creating them. Having only had a bit of experience with scripting previously they proved to be quite challenging from Dominic. The climbing system in particular was actually re-created in the middle of the project, since the original system was not as flexible and we wanted to have greater freedom with how we can use the climbing mechanics.
– Lightmap resolutions – most maps had to be dramatically low for performance, hence the blue colour (aim for green to have ideal texel density).
– Texture resolutions – you can quickly downsize textures and test their effect by using this box below:
– Mesh LODs & Particle LODs – assets used a lot e.g. foliage, will all need LODs. Particle LODs should also be used to increase performance.
– Mesh Culling.
– Static lights only (apart from directional & torch flames) with small attenuation.
– Turned off cast dynamic shadows for anything that didn’t require it in the object details panel.
– Directional light lerp when you enter the cave. Dominic created a quick script that would lower down the intensity as the player enters the cave. This was done by using a collision volume that checks the player’s location while inside it and sets the intensity of the light depending on the location of the player on the Z-axis (up and down).
– We tried to re-use as much as we could rather than creating more individual assets not only to save time, but also as instances are cheaper to use. The objects highlighted are the stone lotus flower and the pagoda/shrine pieces.
In terms of challenges, trying to reach the quality of sculpted assets and tillable textures which today have become a standard in AAA games, was difficult. We knew as the project went along that the more assets we had to take into ZBrush, the more we’d improve. There is still so much to learn but it’s good that the foundation knowledge is there now ready to be built upon. ZBrush is a very versatile program and there are many methods of obtaining the same result, some of which are faster and more efficient than others. Through the project it was basically a trial and error procedure; if one person finds a better way or a nice trick, they would share it so we could always learn from each other.
-We didn’t have a clear cut vision of exactly what we wanted at the beginning. We were planning/blocking out in the first week, but part way through week 2 it was suggested to us that we get a ‘benchmark ‘ area done to get an idea for the timescale; this would help us gauge whether or not what we initially wanted to produce was even possible.
This threw us off a bit as there were parts of the level we weren’t happy with in the block-outs but continued to begin production. These areas then drastically changed halfway through because we knew there wouldn’t be enough time to get what we wanted done, but it then felt it’d be too small if we cut it out. This resulted in a cave tunnel with no ending, and thus, scrambling for ideas on how to end it became a large issue. So, we didn’t completely overcome this, but we all know what not to do in the future.
Time constraints affected the concepting as well. Several times the more impressive concepts had to be cut, in favour of something simpler because they would be too complicated to afford tackling with our given timeframes: though thankfully Denise presented the quick sketches of her ideas first for discussion before spending time on detailed renders which may not be used. For example, as you can see below, the original ideas for the floor of the temple courtyard area were complex (manageable with more time, though). So she produced the third idea on the same sheet, as a compromise.
In addition, things that the concept artist might find obvious may not always be obvious to someone else, as was often proven. Things had to be clear: whether it was through supplying the environment artists with boards of reference material, adding some values to concepts to clearly communicate depth, supplying the group with more orthographic drawings, or just cleaning up linework. You can see the improvement as she revisited a few pieces later on – one example:
Project scale & time + buffer periods. This was our longest project to date and we found that however long you think it’ll take, add an extra 50% on top just to be sure. When blocking out, you may make things way too large because you want to make it an ‘epic’ scale, but unless you know you have the time and resources for it, you’ll probably need to scale down… then some more. That was our personal experience, but we’ve found that this occurred on previous projects also.
Consistent asset pipeline. This helps avoid things looking out of place. Our asset creation process remained consistent throughout. If you establish a benchmark early on as to how you & your team are going to be creating things, it will reduce the number of situations where things don’t sit right in the scene.
Always get critique. Luckily we had tutors to ask as well, but getting consistent crit from your team is so important as it can give a new perspective on things, there were a lot of instances where the person receiving it hadn’t previously considered the things mentioned as feedback.
Don’t be afraid to change things. Getting too attached to your work can inhibit progression. Remember that it is an iterative process so take a step back and analyse what isn’t quite right and fix it. Consider factors such as the composition, colours, shapes/silhouettes, or simply anything that looks out of place for whatever reason and address the problem.
Get the big strokes done first. Ideally you’d want to produce the minimum viable product as soon as you can. We should have made this another focus because if you get the foundation in and it works at a basic level, you’ll be building on something you already knows works, resulting in less confusion later on.
Set regular goals & priority lists (we did ours weekly). There will be times when you get so caught up in the small details that you lose sight of the bigger picture and it’ll seem things are going slower than you’d like. If you set weekly goals, you will be more likely to keep up the pace and it’ll feel as though much more is being achieved.
To see more of our work, and a week-by-week breakdown, please visit our blogs:
- Andrew Simpson: http://andrewsimpson93.wix.com/blog
- Denise Jones: http://denisecjj.wix.com/gameartdesigndmu
- Dominic Mathuse: http://dmathuse.wix.com/blog
- Mark Eastland: http://markeastland.wix.com/blog