next »

[whilefun]

This is such a good thread 

[DrTurkey]

This...this looks amazing.

If only there was a way of talking more directly. Oh well 

Best of luck boys, big fan.

[C7]

Dr Turkey, I'm always available if you'd like to chat more directly. You can message me on the forums, send me a message on twitter, or
send me an email at chad @ tetragonworks.com

Whilefun, Thanks! We're trying to make sure we have lots of interesting content in the dev log. Especially if you like technical details.

Superb Joe, thanks, Artyom is indeed quite skilled with computers.

Lugalias, thank you! Glad you're enjoying the devlog. We're aiming to have new ones out every week.

[bac9]

■ List of all posts
■ Part 4:
Under the armor

Let's take a break from talking about the scene system and take a look at the mechs.

■ 2490x1292

As is customary for every single game involving giant robots, we must invent our own way to call them. All the catchy ones like "heavy gears" are taken, so for now we call them "walker platforms" (WAPs). But recounting the search for tech names would probably make a pretty boring devblog post, so let's take a look at the art work instead. And it starts not with the flashy armor, but with the underlying skeleton.

We had a couple of requirements in mind from the get go:

• First of all, the bodies of our mechs have to be very customizable. Customization is a necessity for two reasons - first, it gives players an opportunity to control brigades that looks exactly to their preference, and secondly, it greatly simplifies work for us as a small team. If you can create a new enemy type by creating a new customization preset instead of authoring and exporting a new unified model, that's worth a lot in terms of development speed.
• Mechs have to be able to wield a sizeable selection of varied weapons

Next, there are some constraints we wanted to impose on our style.

• The mechs should not be small enough to look like armored suits, but should not be gigantic to the point of making normal points of size reference like cars, doors and windows unreadable from frames they fit in. We decided on a ballpark of 6-8 meters, or around two building floors.
• The game needs expressive characters, since we want the player to have at least some emotional investment into the squad. Since it's not a game about infantry, like XCOM, or a first person game, or a game with frequent and elaborate character-driven cutscenes, motion captured animations and so on, we'd like the mechs themselves to be expressive. They need to support a wide range of poses - they need to be able to recoil, point at things, run, slide, jump, dodge, crouch and so on. They need to work as fluidly moving characters in closeup action scenes. In short, we need as many degrees of freedom as possible.
• Another thing we want to improve relatability with is proportions and structure - we want vaguely human-like structure for our mechs. Two legs and two arms. A head. It shouldn't be a futuristic biomechanical design with tentacles, cloth-covered arms with twice the leg length and so on; it shouldn't be a tank with tracks; it shouldn't be a MechWarrior-like glass cockpit mounted onto inverted legs.
• We want the pilots to sit in a standardized pod, not directly in the mechs. Because it looks cool (duh), and because it simplifies the artwork we have to do: after all, what is easier - to make hatches, animated jaw-like openings, individual cockpit designs for each torso piece, or to just design a single armored capsule with a single interior, and leave a neat cavity for it in every torso piece?
• We wanted to avoid hidden 3d joints and make all poses mechanically believable.

So, with that, I modeled some 1d joints and took some stabs at the modeling of a "skeleton", mostly trying to get the degrees of freedom right first.

■ 2490x1292
■ 2490x1292

As I quickly discovered, though, you really need a mountain of 1d joints to give your skeleton human-like degree of freedom. Take a close look at your arm when you outstretch it horizontally, for example - it wouldn't have been possible to do that if your shoulder had a single joint rotating on a single plane. Your hand simultaneously rolls, twists and yaws in different places. I attempted to solve that by adding more twist joints and a new 2d joint into the mix, then doing tests like crouch poses to see how easy it would be to animate the skeleton.

■ 1920x1080
■ 1920x1080

Then I looked some more at that design, taking a look at possible weapon setups and posing the frame with them. We also had to start looking at the pod enclosure as soon as possible - after all, they were integral part of every mech, so they might as well be a part of the base frame. Here you can see, for example, one of the ideas for pod placement, with the torso skeleton acting as a frame flowing around the "casket" with a pilot, and an early weapon attachment idea (lazy wrist pose of sorts):

■ 1024x558
■ 600x426

Here is an example of a model with that weapon setup and a backpack-like attachment of a cylindrical pilot pod.

■ 2493x1268
■ 2493x1268
■ 2486x1268

Another test, with a coffin-like pod enclosure that acts as an attachment point for shoulders and the head:

■ 1920x1080

We ended up with four distinct joint types: a flat joint (for twists), a biaxial joint, an L shaped flat joint (for shoulders and hips) and a plain old single-axis joint (for knees, elbows and other places like those):

■ 1920x1080

The frame designs themselves never really felt entirely satisfying, though. This is something we'd have to lock down, something that will be the base for many armor pieces in the game, so it has to be right from the get go. Mostly, we were dissatisfied with flexibility (some poses worked badly, like outstretching hands to the left and right, grabbing two-handed weapons), proportions (limbs were a bit too long), weapon grip (lazy wrist didn't make sense for much outside of heavy weaponry) and pod integration. We wanted something that looked closer to bulky, grounded designs from Front Mission. So I tried again and came up with this skeleton:

■ 1920x1080

Outside of the really rigid torso section, this was much a much more versatile skeleton. It also mapped more closely to the standard humanoid rig, giving us an opportunity to use humanoid inverse kinematics. So, let's improve it by adding a waist pitch joint, proper subdivided feet, tweaked proportions, a torso with a pod enclosure, and armor attachment frame:

■ 1920x1080

The pod enclosure is one of my favorite parts. Next images are based on an older version of the model, so feet are incorrect and armor is in a draft phase, but you can see how the pod and other parts work in more detail there:

■ 2492x1268
■ 2492x1268
■ 2492x1268
■ 2492x1268

As you can see, this setup is nicely poseable:

■ 2492x1268
■ 2492x1268
■ 2492x1268

There is also a question of hands. Some games opt not to use them at all, attaching weapons directly to wrists or even replacing forearms with them, but we thought that it's important to have human-like hands to make the mechs more relatable, to allow them to be, in a way, mirrors of their pilots. Here is how our hand looks up close:

■ 2492x1268
■ 2492x1268

Ingame model of the hand is less detailed, of course, but we felt it was important to figure out where every joint should be to make the right decisions in design. We don't want to hide the mechanics behind cloth or "cheat" through use of deformable skinned geometry - we want the designs to be mechanically sound, after all. In the same vein, here is the feet design - we've decided to split that area into multiple pieces, including a rotatable tongue-like section for mounting additional armor around a joint which can rotate away from the leg when it bends:

■ 2492x1268

And that's how we've ended up with our current frame proportions and designs. Some work remains, though - for example, we want to make special designs for joints depending on the load they bear - wrist joint shouldn't look identical to the waist yaw joint, and ankle joint should look more bulky than a shoulder joint. This won't change the proportions of the mechs, though, so we've postponed that work for a bit in favor of armor tests.

■ 1920x1080

Initially I wanted to take a look at the armor design in this post too, but I guess it's too long as it is. It's an interesting subject for a number of reasons (tons of repetitive details up close, huge bulky shapes requiring proper shading to be readable from afar, the need for heavy customization support), and we came up with a ton of workflow and shader tricks to speed up the process, so it warrants it's own post full of shader gifs and baking tips.

See you next time!

[cykboy]

Idea and concept seems familiar.. best of luck on the development.

[bac9]

■ List of all posts
■ Part 5:
Mech shaders and more workflow tricks

■ 1920x1080

Pretty early in development, we've realized that we'll need an awful lot of stuff from our surface shaders. First of all, we needed to support the as much customization as possible. Secondly, we needed the surfaces to show location damage our mechs can take. Thirdly, we needed, if possible, to reduce the amount of art work required for our mechs - the less texture work and special assets required, the better.

The shaders we came up solve those goals neatly, at least for now. First of all, let's take a look at the "reducing amount of work" part of the question. What are the most time-consuming and unrewarding parts of a day of a production artist?

• Unwrapping the models
• Producing the cages, configuring baking, managing baking results, e.g. creating packed maps
• Painting edge highlights, wear, color blocks and other repetitive stuff over your unwrap

So let's automate everything.

The most obvious optimization many developers do is baking of some maps and using them to drive the shader output. For instance, hardly anyone creates ambient occlusion maps by hand - baking them is much more reasonable. We do that too, but more importantly, we are baking a per-mesh curvature map and processing it (e.g. adding world space radius-consistent edge blur). Here is a simple example of a curvature map:

■ 1920x1080

It's pretty much a combined map of concavity and convexity, with cavities occupying 0-127 range and exposed edges occupying 127-255 range. Such an image is immensely useful - it describes the shape of an object, and it's no coincidence software like Quixel DDO and Substance Designer is frequently using it to drive generation of edge wear, cavity dirt masks and other shape-sensitive texture elements.

We asked ourselves, though - do we really want to use bakes like those to author PBR textures at all? We don't want a particular albedo, particular roughness, particular metalness locked down in a bitmap - we want a user to be able to customize everything, choose between ceramic and metallic coatings, various tints, various wears and so on. So why not build a tiny SD-like algorithm right into our shader, pushing out PBR outputs for deferred renderer based on nothing but a set of simple floats and context information from curvature/AO bakes?

Also, we want most objects to have multiple parts with different surface properties. That's just common sense and good design - no one likes a box made out of monotonous plastic, but add some metal insets, rubber seams and polymer panels, and we're talking. Traditionally, that's achieved with multi-material meshes. But since our mechs are made out of quite a few pieces, all of which should be independently movable and swappable, going that route will quadruple (or worse) the drawcalls per mech. Isn't there any other way to render a mesh split into zones with different PBR attributes?

So, at first, we made a surface shader that grabs the following inputs:

• 4 albedo colors - primary, secondary, tertiary, background
• RGB vertex colors
• Curvature/AO packed map

And does this:

• Samples the vertex color and takes the values in RGB channels as lerp factors for overlaying primary, secondary and tertiary albedo over background albedo
• Separates the curvature map into cavity mask and edge mask
• Washes out albedo and increases smoothness on edge masked areas
• Darkens the albedo and descreases smoothness on cavity masked areas

If we author meshes deliberately containing only red (255,0,0), green (0,255,0), blue (0,0,255) and black (0,0,0) RGB vertex colors, and never let vertices in the same triangle to differ in color (leaving UV-like seams between sets of faces with particularly colored vertices), then voila - we now have a powerful way to drive mixing of up to four sets of PBR properties, at almost no cost. The idea isn't restricted to albedo - you can mix smoothness values, metalness values, overlays and so on with the very same principle. Basically, you get four materials at the cost of one, which is similar to tricks often used for detail mapping in terrain shaders.

To help visualize, here are some examples of those vertex colors on a mesh:

■ 494x456
■ 723x622

And here is the result:

■ 2272x1268
■ 2272x1268

The results here looks a bit better than the description above would suggest, though. In particular, there is neat high-frequency variation in smoothness and edge wear, and there is some detail which would be awkward to pack into a lightmap UV used by AO and curvature. Where does that come from?

First, we started using a globally shared texture map with some helpful stuff packed into it's channels:

■ 640x640
■ R Basic high-frequency detail for albedo and smoothness variations

■ 640x640
■ G Rectangular shapes, useful for peeling (we'll get to that in a bit) and color blocking

■ 640x640
■ B Regular noise, useful for alpha clipping, height based blending, brightness variations and other stuff

■ 640x640
■ A Cross-hatched mask for material blending and smoothness variations

Using the alpha channel of that shared texture to modulate the edge-peeling mask or using level-adjusted cavity mask combined with red channel to drive dirt gives obvious improvements to the result. And those operations are so simple that it makes no sense to do them externally and render them into a texture - instead, we leave everything configurable.


_____________________________


To get to the subject of workflow for a minute, here are some interesting bits. For example, UVs: since hardsurface shapes are relatively simple to split and since we need boring, non-overlapping UV mapping for curvature/AO bakes, we automatically generate all our UV mapping. That's right, not a minute is spent on it - we do color blocking, detail placement, shape changes and so on, while UVs are generated either by IPackThat packing of splits by hard edges, or by Enlighten lightmapping UV generator, or even by simple Flatten mapping.

And vertex colors. They can be very inconvenient to author, so it's preferrable to bake them, of course. The most obvious workflow is to create four materials (primary, secondary, tertiary and background), then bake diffuse into vertex color using something like VertexPaint modifier. There is a small problem with that approach, though - materials belong to submeshes, or triangles, not to individual vertices. So, in contrast with UV coordinates and normals, material edges do not actually create seams, which will lead to undesirable vertex color leaking when you directly bake multi-material colors to vertex colors of a mesh:

■ 546x565

There is a straightforward way to solve that, of course - detaching every face with a particular material into a separate mesh, baking vertex colors, then merging everything back. To hell with that, though: do you really want to edit 3 separate instances if you want to add an extrusion passing through 3 materials? Do you want to deal with 3d software losing your smoothing groups on detach operations? Yeah, neither do we. So, Instead, I wrote a Unity script that takes a Mesh instance and does the following:

• Unity treats multi-material meshes as "submesh" collections, where every submesh is a separate triangle array. So, we iterate through those submeshes, and on every iteration, fetch their triangles (trios of vertex indexes)
• From those triangles, we build a list of all vertex indexes used by that submesh
• Then, we create new vertex entries in pre-created UV/position/normal/tangent/color lists, determining new vertex index from new length of one of those lists and copying the info from old vertex indexes referenced in triangles (since that happens per submesh, new vertices arise on material borders)
• We map old vertex indexes to new vertex indexes with a dictionary as we go through that process
• By using that dictionary, we can convert every single triangle of every single submesh into new vertex indexes
• Those converted triangles are then used to build a single triangle list, which is used to assemble a mesh with no submeshes

This operation cleanly creates duplicate vertices for sharp vertex color borders - at every point where the same vertex was reused by more than one submesh.

Ah yeah, and let's not bake vertex colors at all - instead, at the very same step, we can exploit the fact that submesh arrays in meshes and material arrays in mesh renderers mirror each other, parse material name of material from index of a submesh, get a color from it (for example, asset processor can have a method that returns color 255,0,0 from material name "vc_red" or "vc_primary"), and apply that color to every single vertex we take out of a submesh. Voila, free material to vertex color conversion, simultaneous with edge fixing.


_____________________________


Back to the shaders. We now have a way to cheaply render nice surfaces with edge wear, cavities, dirt, different attribute zones and so on, and assets for that are easy to author: we make a multi-material shape, export it, auto-generate UVs, then bake it, then feed it to our asset processing script which fixes the edges, assigns vertex colors, creates a material, and assigns inputs to it.

That's neat state of things. It's as close to an ideal workflow with a "do all production art for me" button as you can probably get. Design untextured shapes all day, get a production ready result from them in minutes.

Problem is, hardsurface designs aren't all about low-frequency shapes. They also require details: rivets, hatches, panels, seams, bolts, fasteners and so on. Those little things have some very inconvenient properties:

• They are very frequently repeated, used in pairs, dozens or even hundreds over a hardsurface design
• They waste a lot of UV space with their tiny, incredibly numerous UV islands, especially due to margins preventing mip bleed in auto-generated UVs
• In contrast with the main shape, they very rarely get exposed to different ambient occlusion and always have the same curvature in all copies, which makes them even less palatable in the main UV space
• While geometry curvature-based texturing is fine for surfaces, you still want stuff like labels, highpoly-baked rivets, intricately detailed vents and other detail sometimes, and that's where it won't be enough.

We want, at the very least, this kind of detail and density:

■ 2272x1256
■ 2272x1256
■ 2272x1256

So let's solve those issues. Most obvious solution to the problem of wasted UV space is splitting details into a separate, manually authored UV map, used to create a PBR material that is reused for every single instance of every single detail type. Great for performance too - we can dynamically batch all detail elements in the mech then, if conditions are right.

There are some problems with that approach, though. The detail rendered with a shared material using an atlas:

• Won't have surface colors and PBR properties
• Won't have transitions to surfaces, making it impossible to insert it seamlessly, in an unnoticeable way
• Will z-fight with the surface at every opportunity
• Won't have any way of blending with baked ambient occlusion of the surface, looking jarringly lit in dark, occluded areas

All that is solvable.

We can assign vertex colors to our detail mesh in the very same way we do with a surface mesh, through material recognition, but since we're working in software where UV mapping is attached to materials and detail has pre-authored UV mapping, that would be inconvenient. Instead, we export a file with multiple child meshes inside, each grouping detail over a particular zone of a surface mesh and named in the same way as parseable surface materials. Our asset processing script goes through the detail mesh, finds the parents determining vertex colors of all the meshes inside, applies them, then merges everything into a single mesh. And when we have vertex colors following the surface, it's easy to replicate exactly the same approach to zone rendering as in the surface shader described above.

Z-fighting is easy to solve - we just tell the shader to offset vertices towards normal and towards camera a bit - a trick common to most decal shaders.

Transitions between details and surfaces are a bit trickier. We obviously can't completely match a surface, especially if it has some overlay like a camo pattern applied on top, so we want the next best thing - blending color and PBR attribute matched details into the surfaces over a smooth border. There is a tiny problem with that, though - we're using deferred rendering, so traditional alpha blending is impossible to use. And alpha testing looks bad. It can be improved with dithering, but without a screen-space postprocessing effect similar to one in GTAV, dithered borders look bad too, and get extremely ugly with a distance:

■ 2272x1256

It stays somewhat passable when blending occurs against a coplanar flat surface, but when we need to blend in a sharp cavity, like a seam, it falls apart as a pixelated mess. We need true alpha blending, somehow.

Thankfully, there is a way to get it, thanks to the little-known finalgbuffer function introduced to deferred renderer in Unity 5.3. Basically, all surface shaders in deferred rendering output results to four render targets, ignoring alpha, with the only way to avoid output being alpha testing/clipping. But if we get access to a point where surface shader outputs are being blended with four render targets, we can modify their alpha and blending mode in a way that will keep some portion of existing RT content intact - and that's exactly what finalgbuffer function offers. You can't do stuff like properly ordered glass and vegetation with that trick, but blending two coplanar surfaces together can be done. In fact, that function was initially introduced for Unity 5.3 terrain shader, where it's used to allow splat mapping to work in multiple passes. But it happens to be perfect for our deferred decals. Here is how blending looks:

■ 2272x1256

What probably raises concern is world space normal render target. While interpolation between two albedo colors yields a valid color still, interpolation between two normals usually gives you a broken normal, as there is no way to normalize the result without access to the underlying pixel color in a blending operation. We completely avoid that issue, though, since we only ever need the transitions to occur on areas coplanar with an underlying surface. A result of linear interpolation of two identical normals is still the same vaild normal, no matter the lerp factor:

■ 2272x1256

Only remaining issue is smoothness blending - very inconveniently, Unity packs it into alpha of the specular render target, which makes it impossible to blend specular correctly without also writing 100% smoothness value everywhere. We solve that by defining a separate blending mode for alpha channels (which only affects specular+smoothness render targets, since no other targets use alpha), and performing an additional, simple additive pass restricted to writing to alpha. That still won't allow us to blend smoothness with a semi-transparent border, but it's good enough and unnoticeable, considering that all other PBR components are blended smoothly.

Back to the last issue of detail being unable to match the baked ambient occlusion from surface mesh textures. That problem has a very simple solution: since detail meshes have quite a bit higher vertex density and small surface area, using a unique unwrap and texture is completely unnecessary: baking AO per-vertex and packing it into vertex color alpha actually looks good enough. Here is an example:

■ 2272x1256
■ 2272x1256



_____________________________


With detail shader and meshes out of the way, let's take a look at some of the things we can do with the information fed into the surface shaders. We needed damage? Let's do it by combining a noise map with structure map and peeling map (all sourced from a single global texture) and some coefficients and points. This can be improved by some changes like timed emissive on edges (molten damage outlines), but it looks good enough for now (very big gifs next):

■ GIF, 1300x800
■ GIF, 1300x800

Customizing properties (like albedo) of each zone of each mech part is, obviously, trivial, since vertex colors express zone masks, not PBR properties themselves:

■ GIF, 1300x800

Introducing an overlay is also a good way to add variation - e.g. camo patterns:

■ GIF, 1300x800


_____________________________


As you can see, our shader and conent pipeline make it pretty easy to author content while giving us pleasant visual results and supporting all the features we want. I can go into more detail on the shaders or pipeline details if anyone wants them.

[thekosmonaut]

you guys rock!

[bac9]

■ List of all posts
■ Part 6:
Iterating on walker designs

■ 2272x1273

Since the workflow for parts and other similar assets is more or less established now, it's time to take a look at our mechs again. On the promo images, we had nothing but shoulder pads done with a proper amount of detail, and overall, the designs of the armor and underlying frame weren't entirely satisfying to us. To remind, here is how they looked before:

■ 1920x1080

Let's jump into the issues we can see here!

• Biaxial joints looked too flimsy, at least in thigh and feet
• Uniform limb width on the frame looked strange, as if limbs were Canadarm-like manipulators bearing no load
• Waist joint was too small, especially since it was topped by two pitch joints of exactly the same radius
• Neck wasn't properly covered, creating an impression of a head hanging in air, and head design itself wasn't that nice
• Torso looked like a beer gut, betraying no hint of an actual function behind the shape (housing the pod), it's solid structure clashed visually with the airy supports on the limbs (thin elements with cutouts)
• Transition from arms to palms is very abrupt, with the cross section area jumping down dramatically

So, as usual, we started fixing the issues. First, the joints. We've thought a bit about it, and came up with a better shape that kept most of the rotation range intact while looking more sturdy:

■ 1724x1021
■ 1600x662

Next, the limbs. There was a practical reason for uniform width and simple shape of of the frame limbs: to allow for see-through designs and proper damage visualization, armor never clips with the limbs and must have proper internal surfaces:

■ 1440x677

Obviously, the more simple our limb shape, the less time we'll have to spend modeling the internal surfaces of the armor that are hugging them. Inward-facing surfaces will take UV space and polygons that way. Still, since armor can be shot through, blown off, or simply removed in the hangar, we have to make the naked frame look presentable. So we've settled on a compromise shape:

■ 2148x1220

In a nutshell, we've made limbs thicker around some joints, where human limbs typically are - on an opposite site of a shoulder joint, on an opposite side of a pelvis joint, at the knees and over the elbow. We've also extended the armor supports out, closer to the joints, since armor pieces will typically stretch there to protect the joints anyway.

With the torso, the process was a bit more complicated. We've decided to add armor support panels (colored in red on images above) into the torso, to bridge the visual disconnect with the limbs. But slapping the support frame on top of existing torso surfaces would've made this already large body part even thicker - and in contrast with the limbs, that's really undesirable - we want to keep lean armor designs possible. So, instead of slapping those on top of existing surfaces, we've used the existing thickness of the torso, burrowing the panels in it where possible. The most important touch is see-through cuts similar to ones on limb panels: they make the torso visually lighter, and allow the function behind the torso shape to be seen from any angle - the pilot pod hull will be clearly visible through those new cuts:

■ 1583x1105

As you've probably already noticed, the waist joint has a more appropriate radius for supporting the torso above:

■ 1037x526

With the neck, though, it's hard to do the same. We want the head and neck to have the smallest footprint possible on the armor below, since it directly impacts how close the armor can hug the neck. Also, a bottom heavy shape you'd intuitively expect from a human neck makes little sense with a simple joint structure we have here. So, the compromise was to design the head pieces with the heavy downward-rotated elements which will partially occlude the neck joints. That improves the silhouette - even more so if there is a bulky armor as a backdrop.

■ 1200x1149

The hand transition now has a biaxial joint part variant that gets thinner towards the palm. This makes the silhouette smoother - and as a bonus, gives an additional pitch point for nicer hand poses (e.g. for a palm-forward "stop" gesture).

■ 1746x1132

All in all, the frame looks better now. Especially when we bring everything into engine and texturing/lighting highlights the shapes further.

■ 1669x1024
■ 1920x1080


_______________________________________

That's it for the walker frame. But we don't send mechs into battles naked, and old armor pieces had some issues of their own:

■ 1399x723

For one, that armor isn't very consistent visually. A bit of shape language is shared between the pieces (e.g. surfaces usually meet at a 45 degree angle), but overall, the pieces aren't complementing each other all that well. An obvious solution here is to start with that language, a set of shared elements and tropes that can be reused across all pieces - instead of diving into modeling straight in. So we did that, starting with a set of reusable detail.

■ 2275x976

As you remember from the previous post, we've moved all complex detail (that ends up cluttering UVs with pointlessly repeated tiny islands) out from auto-mapped surfaces. Instead, that kind of detail is authored once, mapped to an atlas, and rendered on top of surfaces using a deferred decal shader. We've looked at the shader before, so instead, let's look at the modeling process. This is how we place the details - using normal snapping, we easily glue pieces to any surface orientation:



Beyond that set of consistent details that should be used on every surface in an armor set, we've also settled on some basic shape for those surfaces. Shape tropes, if you will. For example, in a certain set, each piece should incorporate panels extruded by 7cm, flowing between two planes and clamped in at least two points with a particular detail mesh attached over a particular bevel. Err, hard to describe it, let's just illustrate:

■ 2235x910

When every element in the armor has something like this in it's shape, everything starts to belong together, even if the silhouettes and sizes between the parts are wildly different. A torso armor will never look very similar to a shoulder pad, but when they both use the same shape language and details, they start to mesh together really well.

■ 1829x650

Ah, and lets not forget the best part about real-world modeling - plastering your stuff with fancy decals. Arrows, serial numbers, warnings, sensor and port markings and so on - you can't have a proper mech without that goodness. So we made some of those too:

■ 577x754

I swear, slapping those decals onto surfaces is the best part, there is something deeply satisfying about the act. Anyway, to sum things about the armor up:

• Armor needs to share some shapes between the pieces
• It's great for detail density to jump from lows to highs, but every piece should have areas of both - don't leave a torso without any detail at all while keeping a shoulder densely packed with it.
• Atlased, reusable detail is love - it saves you UV space, it makes the look of an armor set consistent, it allows you to edit all instances of any given detail bit with a single brush stroke in a unified atlas, and it dramatically speeds up the modeling process.

Okay. Since we now know what to look at, let's drop the final images.

■ 2272x1273
■ 2272x1273
■ 2272x1273
■ 2272x1273
■ 2272x1273
■ 2272x1273


_______________________________________

And that's it for today! I hope you've enjoyed the details. As always, feel free to ask any questions, I'm happy to talk more about the workflow.

■ 2272x1273

P.S.: Some stuff that didn't make the cut but is worth noting anyway:

• We've sped up the workflow for multi-part meshes like hands. SU can't export pivots to FBX, and it was an issue for a while, forcing us to export elements like those with all hierarchy flattened and all pieces moved to local 0,0,0. Now we simply pack a special helper mesh into each part, which is then used by asset processor script in Unity to produce three points from mesh bounds, which then provide reconstructed position and rotation. In other words, we can now smuggle pivots through environments completely unable to handle them. I don't miss setting up positions and rotations of 67 frame pieces for even a second, I tell you.
• We've implemented an intelligent blur for curvature maps, which takes UV island map, derives flow vectors from it, and blurs the curvature inward, into the UV islands. That's amazingly useful for pixel-wide lowpoly curvature bakes from Substance Designer - we can now extract smoothly featered cavity and edge highlights of any radius from them.
• We've improved the auto-rotated joints, now they bridge to any orientation of feet, thigh and shoulder joints correctly. To remind, those pieces are freely rotated by animators on XYZ axes, and biaxial joints I have modeled aren't manually animated at all - instead, a special script adjusts their two-step rotations automatically:

■ animated GIF

[Alec S.]

Very cool stuff!

[craigz]

This is a fantastic thread! AHHH got so excited drilling through this!! :D 

[Deidril]

 

Devlog of the year.

And a promising very interresting game.

Keep this way ! 

[bac9]

Glad to hear you're liking it!

Here is a peek at the animation work Dan R. Paulsen is doing

[Graphicalgeek]

Super cool looking game and thread!  Thanks for sharing!

[kruxus]

Really inspiring work! I would be interested in hearing more about the rigs you used for animation.

I've tried to set up IK-rigs for similar designs without great success. Traditional IK-rigging setups doesn't really apply when you don't use ball-joints everywhere. When you instead have several 1d-hinges those would usually break using the same methods.

[JShrum.Composer]

Wow. I'm going to have to agree with just about everyone else and say this looks amazing.

It's been a long time since I played any Front Mission, but this is bringing back some good memories.

[McMutton]

Holy crap; this is some technical voodoo shit, here! I'm incredibly envious of your modular prowess.

[bacon]

These technical pipeline posts are amazing. I've got a question about the scene one though — how do you avoid the "tileset" look, even in light of easily combinable component voxel-like pieces.  From a player's perspective, the issue with the Skyrim tileset approach wasn't that the tiles themselves were hard to place on the developers end, but that, when using all the pieces, everything had a sense of "sameness" to it, and the repetition got tiring. Even if you can build whatever out of your approach, it seems right now like you would still be running into the same issues. Do you have any workflows or pipelines that mix up the fundamental geometry/material combinations to make for more novel structures?

[jordanchin]

What an awesome devlog! Loving the look and feel so far. The world needs more mecha right now.

[sbeast]

I keep checking back every now and again to see the progress you've been making.
Although there's not been an update in a while, I hope it's still being made.

[The Armorman]

I will break kayfabe to tell you that I am legitimately excited about this videogame that genuinely appeals to my interests