[UE4] Drone Alone
Hi, I'm a technical artist working on a portfolio piece, an Unreal Engine 4 project called Drone Alone. It's about a home security drone who has randomized missions which range from eliminating enemy drones to placing flowers in all the vases. Basically a friendly sandbox with a loose rule set to encourage emergent gameplay and player creativity.
The game takes place in a 70's/80's style retro future (formica punk) apartment, which has four versions for different times of day: morning, noon, afternoon and evening. They are switched on the fly based on player progress.
The project is now mature enough to show my intentions so I'd like to know what you guys think.
This post is to give you an idea about the place:
The apartment is disc-shaped...
...with the garden at the center...
...and the garage on the far right. That room is a "vertical slice" I'm working on at the moment:
This is by far the most asset heavy place in the house so it helps me stress test my workflow.
The rest of the rooms are blocked out just enough to test layout, palettes and environment lighting:
Well, that's the overview of the place. Next time I'll post more images about the garage and the props in there.
If you want to know more about the project then please visit my blog:
http://www.zspline.net/blog/category/myprojects/drone-alone/
The game takes place in a 70's/80's style retro future (formica punk) apartment, which has four versions for different times of day: morning, noon, afternoon and evening. They are switched on the fly based on player progress.
The project is now mature enough to show my intentions so I'd like to know what you guys think.
This post is to give you an idea about the place:The apartment is disc-shaped...
...with the garden at the center...
...and the garage on the far right. That room is a "vertical slice" I'm working on at the moment:
This is by far the most asset heavy place in the house so it helps me stress test my workflow.
The rest of the rooms are blocked out just enough to test layout, palettes and environment lighting:
Well, that's the overview of the place. Next time I'll post more images about the garage and the props in there.
If you want to know more about the project then please visit my blog:
http://www.zspline.net/blog/category/myprojects/drone-alone/
Replies
Right now it's clean, new, like how the rest of the place is going to look like. There is a narrative reason for that: The building is new and partially furnished, no one has moved in yet. The player drone is there to keep things in order as more and more stuff gets delivered. Delivery happens after each successful mission, in the shape of a random dynamic item: pool balls, a pocket radio, a bunch of pillows and so on.
Anyway, the place is new and clean which should be nice in other rooms but here feels kinda off because my idea of a stereotypical garage involves oil, grime and heaps of random machine parts. So I think I will add some dirt decals and a bunch more smaller objects to make the scene more busy.
There are many things still missing, most notably the drone recharge station, which serves as a spawn/save point. However I want its design to match to the drone's so I will have to finally make the final drone first.
I'm also looking for ways to add more 80's feeling. I found an Hungarian calendar from the era which I'm going to rework. Then a door mat with some funky 70's pattern would help too but beyond that... I don't know, I'm open to suggestions.
Next time I'll give an overview of the asset workflow.
Today I'd like to overview the asset workflows.
I'm using Modo 801 for everything 3D (modeling/texturing/baking) while pure 2D tasks are done with PhotoLine and FilterForge.
Before I start modeling I spend some time finding references, not just images but also 3D models. When I have a good idea which pieces I want then I put the related references in the background and start roughing out the thing.
High definition, bake source models use pixar sds. This first pass is for nailing down dimensions and proportions. Functional surfaces (like the top of a table) are snapped to grid so the model can be instantly used by level designers. I also tend to snap to grid most measurements to satisfy my OCD.
The rest of the steps vary based on how complex surfaces I need on the final mesh.
Simple things, like the furniture of the garage, use a low resolution texture set, a material library.
It only contains constants for every surface property in order to keep things consistent (from model to model and between Modo and Unreal) and easy to experiment with. The majority of the detail is actually in the in-game model, no normalmap is used.
I'm using Farfarer's excellent Vertex Normal Toolkit to control normals, which is an essential tool here. The relatively high polygon density makes aliasing a real problem so I rely heavily on temporal AA to fix that.
The advantage of this technique is that it's easy on texture memory and speeds up asset authoring mostly because the baking or texture creation step is omitted. Disadvantages include dependence on FSAA and lack of high frequency surface detail (like wear and tear). Fortunately the latter can be addressed by using decals, procedural micro maps and vertex painting based effects.
Another type of objects have a bit more complex surfaces but only need smallish texture resolution due to their relatively small size. These objects can be combined during the baking process so they share a single set of textures. In the garage these are the tools:
The high definition and in-game meshes are modeled separately then all low poly meshes are selected and UV packing is performed on them. This operation arranges the UVs on the same, shared 0-1 UV space, that is their texture atlas from then on.
It's easy to add new items, the necessary UV repacking and baking are automated. Sure, the more items are cramped in there the less texture coverage each of them gets but when they start to look bad then the bake resolution is bumped.
This method could be inefficient texture usage wise when the items sharing the texture are seen less frequently, separated from each other. In those cases the whole texture is loaded even if only a fraction of it is actually used.
The next installment is going to be about the workflow for hero objects.
It was inspired by Minitel and teleprinters. Its function in game is to describe and start the next mission. It is part of my effort to only use narrative UIs: No menu, no HUD, all the information is delivered through things which are part of the game world.
Anyway, the first problem I ran into when I started authoring assets for UE4 was that Modo doesn't have physically based surface properties: it still uses the old school set of parameters (the specular setting split into amount, fresnel, color, roughness for example). To make the workflow simpler and asset creation more intuitive I made a plugin which closely mimics the looks of Unreal's shading. It's not a pixel perfect match but at the end you get in-game pretty much what you was seeing while working on the model.
(The in-game model in Modo and in Unreal.)
The asset is previewed through Ray-GL mode or using the dedicated viewport. It's not exactly realtime but the render clears up pretty well in a second even when working with 4-5 million polygons.
(Render progress after 1 and 2 seconds.)
The use of micropoly displacement does introduce a 3-4 second delay which is annoying but that can be decreased by using "draft", low quality displacements while previewing.
The "Unreal shader" plugin provides new surface properties with names matching the Unreal equivalents. That data is then baked into the following textures:
*_color: Base color.
*_normal: Normal.
*_meros: MEtallic, ROughness and Specular.
*_emiss: Emissive color. Right now only direct surface light emission is baked but in the future I want to merge that with indirect illumination.
*_aux: Auxilliary RGB data. The red channel is used as AO most of the time while the function of the other two varies. On the Minitel they control the flashing patterns of the lit buttons and the floppy led.
The baking process is aided by a modified version of the Baking UI Kit. I fixed bugs and extended it's functionality so now baking is usually a one click process.
So, hero items. They have their own textures and the high definition source model is as detailed as possible. The bulk of the model is pixar SDS but for greebles I used polygonal models:
(The dense triangulated polygonal geometry on the pSDS model.)
These are cleaned up versions of actual machine parts from tracepartsonline.net. Each raw mesh gets the pivot set properly, extents and important surfaces snapped to grid, unseen polygons removed, ultra dense areas simplified or entirely replaced with a subdivision surface. After these fixes the models are stored as presets so they can be drag&dropped in any scene.
When the HD model is done then the in-game mesh is created. I usually start with the frozen level 1 or 2 geometry of the HD mesh because it tends to maintain the beveled edges which would be lost if I simply used the pSDS cage:
(The subdivision surface, the pSDS cage and the level 1 frozen geometry.)
Sure, there are a lot of vertices and edges which need to be removed but the bulk of the work can be automated. I don't use the polygon reduction tool as it doesn't really work with hard surface models.
When the geometry is done comes UV unwrapping. I go through the bigger parts, select edges which can be split in the UV and run a small "UV unwrap + relax" macro. At this stage I don't care about overlapping polygons, just reasonably distortion free UV islands.
The next step is texture resolution weighting. Using hotkeys I assign one of the following weights to every polygon:
1%: Gets 1% of the coverage it would get if the texture density was the same everywhere. Set on polygons which are not visible. (Those faces are not deleted to prevent GI and shadow artifacts.)
25%: Hard to see areas get this weight like parts of the Minitel facing the wall or mostly covered up by greebles.
100%: Surfaces which are clearly visible with average amount of detail.
400%: Used to dedicate extra amount of texels when required. On the Minitel for example the buttons have this weight so the text on them remains sharp.
The weights are color coded for easier use:
(Black: 1%, orange: 25%, green: 100%, purple: 400%)
The texel size for a 2K texture is also displayed to give an idea how much data will be present.
A macro uses these weights to arrange the UVs for baking. The same procedure is used to generate the lightmap UVs with the difference that the 400% weight is disregarded.
After creating the collision hulls I use a script to export the mesh as an FBX file. The exporter script gathers and properly names colliders, rotates and scales everything for Unreal, stuff like that.
And at the end the mesh is in game:
With the variable texture density 2048x2048 textures hold enough detail so things only start getting blurry reasonably close to the near clipping distance.
Next week I'll post a few images of the high def model for the hero drone.
This is the drone with the propeller engine mounted:
The propeller planes adapt when the core changes pitch or moves sideways:
The base model is a Catmull-Clark subdivision surface:
Most of the details come from a set of related "decoration" textures which are rendered in a scene where a bunch of nurnies are aligned in a 10x10 grid.
Beyond the expected color, roughness, displacement, etc maps there is an extra one, a mask. That mask decides where the decor's surface properties overwrite the final surface (although the displacement map is always applied):
There is also a paint layer bellow the decoration details, using a different UV set and a very simple, color only texture to add stripes and other geometric shapes.
The propeller engine has 5 parts, most of which are instances. The objects are rigged in Modo similarly how they are going to work in-game which helped me a lot while modeling to avoid obvious design flaws.
Finally here is a closeup of the sensor array of the drone core:
Next time we'll take a look at the jet engine.
The fans on the wings produce compressed air which are released through valves underneath to provide lift:
Sideways movement is also possible by opening an air outlet at the outer edge of the wing:
The compressed air based motion is sluggish compared to the propeller engine but the forward speed is way greater.
When breaking or flying backward the thrust reverser engages:
(Please forgive the crude "special effects".
The upcoming update will introduce the ion pulse engine.
Ions are accelerated and ejected from the thruster discs. While the top speed in any direction is not great, this attachment can counteract inertia and outside forces (like air currents) by turning on an off individual discs several times a second. This allows extremely precise movements with instant full speed and practically no overshoot. Combined with the silent operation this engine is ideal for sneaking and sniping.
Next week I'll show off the first and so far only weapon attachment, the .22 Mouse Gun.
The display at the top of the magazine is the only indicator of how much ammo is left because I do not want to have any sort of HUD at the end. (There is some right now for development purposes.) Remaining mission time will be shown on clocks around the house, health is going to be displayed as wear and tear on the drone along with video feed glitches.
My next task is creating the in-game models, baking textures and hacking my way around these two blasted bugs... so I'm not sure when the next update is coming.