Antique Desk

Desk_01.png

The goal for this asset focus on a larger prop, which would require more work on the texture/shading side than the modeling side. As with my previous telegraph asset, I started off by taking several photos and measurements of the real desk in order to have adequate reference when working on its digital counterpart.

Desk_02.png

As expected, the modeling portion of this project was very brief. The desk contains many reused shapes (handles, legs, trim, etc.) meaning that only a small fraction of the prop was actually unique in terms of geometry. It also meant that many of the smaller pieces could be stacked on top of each other in UV space, increasing their individual texel density. This ended up being quite important, as recreating many of the minute scratches and other fine details on the desk required a significant amount of texture resolution.

Desk_Materials.png

By far, the most crucial part of this project was the materials. I initially started with the wood material I had created for my telegraph asset, but soon found that the material simply lacked the detail I wanted, and started from scratch.


In particular, procedurally adding the wear to the desk’s wood was an excellent learning opportunity, where I utilized almost all aspects of Substance Painter’s baked maps (AO, Curvature, etc.) to create believable scratches, scuffs and fading. This resulted in a reasonably complex material with nearly a dozen layers. However, since each of these layers controlled only a small portion of the final material, it remained highly adjustable throughout the project, allowing for very quick iterations on the desk’s appearance. I used a similar approach for creating the worn brass and leather, which were the other two key materials for this prop.

WoodGif_Indexed.gif

This animated .gif shows what each layer does, and shows how small variations in multiple layers can be put together to create a much more complex end product.

Lastly, as ever, I continued to improve my presentation and rendering within Marmoset’s ‘Toolbag 3’. This time, I crated a fully white backdrop, which I think helps the prop stand out better, and adds more interesting highlights and reflections onto the desk’s glossy surfaces. Additionally, I performed some minor adjustments within 'GIMP’ (a free image editor, similar to photoshop), such as down-scaling (the images were rendered in 4k) to improve edge details and reduce aliasing, as well as minor adjustments to exposure and color curves. I also used this program created the material .gif above; something I plan on doing for other interesting materials in future projects.

Desk_03.png

My next project, which I am currently working on, is shaping up to be much larger in scale than my last few; it will be a moderately sized outdoor environment, with a focus in production-ready assets and techniques.

Telegraph

“There will be plenty more in the future.” - Feb 2, 2017
Well, I wasn’t expecting a 2.5+ year pause between posts when I wrote that. Shortly after my previous post, I started working in the 3D industry full-time; which can be quite a time consuming occupation. However, I now have some time to work on my own personal projects; so why not a breakdown of one of my recent assets?

Render_Front3Q.png

This is my “Old Telegraph” prop I made a little while ago, and it was a really valuable learning experience. The goal was to focus on realism almost entirely, but keep it within the technical limitations of a modern game hero prop. With those goals in mind, the prop weighs in at 6,974 polygons and is covered by a single 4k texture set.

Render_Front3Q_WF.png
Diffuse, Metal, Rough, Normal maps

Diffuse, Metal, Rough, Normal maps

For this project, there were two major challenges; first was creating a high quality wood material for the base. Until this prop, I was never really satisfied with my wood materials, so this was an excellent opportunity to improve on that type of material. The second challenge was portraying decades upon decades of dust, wear, discoloration and general aging. Fortunately, since I own this particular telegraph (it sat on my desk for the duration of this project), I had excellent reference to take inspiration and notes from.

Front_Close.png

I think I addressed both those challenges quite well; by utilizing a ‘layered’ approach to my materials, I had very fine control of the look the final render. Each material, so the wood, dark metal, light metal, the two different brass metals, and plastic, are each made of around 10-15 layers, each adding very minute detail, such as wood grain, or small wear and gloss variation on the plastic.

Another thing key component for this asset was my ongoing improvement on presentation. I now use a more ‘proper’ light-box setup, allowing for the asset to be shown in a nice white (or any other color) ambient environment. In addition, my lights were further adjusted to highlight variations in gloss and shine, resulting in some nice eye-catching specular highlights. This was done by switching to a more conventional setup, consisting of a key light, two fill lights (left and right) and a back light.

Overall, I think this asset turned out well, and I learned a lot of new techniques that I will be applying to my future projects.

Blowtorch and Controller Breakdown

I've decided to combine my last two props into a single breakdown, as they have shared quite a few techniques and approaches. As always, I tried to apply some new techniques to my work, in hopes of improving quality.

Blowtorch

The blowtorch is a fairly standard game asset; it's usually the 'repair tool' for games with those types of mechanics. In this case, the asset I've created would work well in a first person view, as It comes in at 1,564 polys. In addition, I've also created an 831 polygon 'LOD1' version, which works quite well from a distance (basically, just less rotation segments).

The textures follow the standard PBR format: diffuse, spec, gloss, normal. The base normal map was created in Quixel's 'nDO', a tool I have found to be quite useful for creating simple details such as text or ridges. From there, the normal was imported into 'dDO', where I created the rest of the textures.

Unlike previous assets I've made in 'dDO', this was the first time really utilizing the 'paint' mode, which allows for 3D painting in '3DO'. I used this to add various stains and and material variations to try and improve the overall realism of the asset. 

The final render

Controller

The controller was an interesting project, as it heavily utilized normal maps for a large amount of details. The 'nDO' file for this asset is by far the most complex one I've made so far, but it definitely helped improve the realism and overall appeal of the asset. Everything from embossed text, to stickers, groves, etc. was done in 'nDO'.

Much like the blowtorch, the controller would also work well as a game asset. With the 'LOD0' being 1,211 polygons, in addition to the 'LOD1' variant which comes in at 670 polygons.

Textures were again made in 'dDO', and I made further use of the 'paint' mode to add in lots of details, stains, color variation and so on.

The main criticism I have for myself in this project is based on the decision to model the connecting 'grove' between the front panel and the rest of the object; this created a lot of narrow UVs (top right), which took up a lot of space, meaning the UV map wasn't as efficiently packed as it could have been.

The final render

Conclusion

These projects were a lot of fun to work on. Being able to focus on a specific material type (metallic vs. non-metallic) allowed for some interesting experimentation which I look forward to using in future projects. The creations of proper LODs was also an interesting new addition to my asset pipeline (as opposed to doing it at the end) which will hopefully be quite a time saver. In general, working on smaller assets has been quite fun, as it's allowed for some quick iteration and application of new techniques.

Hopefully you've enjoyed this combined breakdown of my last two assets. There will be plenty more in the future.

Hard Surfaces and Dynamic Rigs

Back in June I posted about my tank rig; a fully real-time rig in Cinema 4D which controlled my 'Panzer 2' tank model, allowing for realistic movement and terrain deformation. Now, I have created a new rig - and it's a bit more detailed.

Much like last time, this rig is entirely driven by dynamics, and of course works in real-time. In addition, this rig uses soft body dynamics to allow for wheel deformation to create a better sense of realism. However, unlike last time, I've modeled all the 'connecting' parts which would control the wheel's movement in a real vehicle, as a continued practice of my hard-surface modelling skills.

The rig. Note the tire deformation.

The rig works in a fairly simple manner; the rubber part of the wheel is the only part actually utilizing any form of dynamics, by way of soft body deformation and a simple 'wheel suspension' connector.  In turn, this rubber wheel then controls everything else via a fairly standard IK chain with some added aim constraints to allow for parts to properly connect to where the rest of the vehicle would be.

The spring works via a 'squash and stretch' deformer, which is then controlled by a very simple 'XPresso' script, which really just uses a distance function (between the 'base' and 'end' objects for the spring) to determine how much the spring should stretch of squash. 

The squash and stretch deformer and it's XPresso script.

I hope you enjoyed this overview on the rig. There will be plenty more models/environments and possibly even rigs this year, so make sure to check back.

CryEngine Lighting

With my focus being on 'realtime' 3d work, one of the most important abilities to have is to quickly interact with and iterate on a scene; changing the lighting, time of day, weather conditions and so on. As I've said before, this is one of the main reasons I use CryEngine for my in-engine renders - it offers very good lighting quality without the need for long periods of 'baking' to get the desired results.

The forest at dawn.

To continue my forest project, I've decided to expand upon the size of the environment (still in progress) and create a full 24hr day/night cycle to light it. As usual, this uses most of the rendering features I've talked about before: some environment probes, SVOGI (global illumination), but also introduces a few new things, like volumetric lighting.

The forest in the late morning.

It is important to note, though; there is still some baking in this scene. SVOGI requires a rebuild for major lighting changes, as do the environment probes. However, this only takes a handful of seconds for the entire scene. With further updates to the rendering systems used, this bake time will likely be almost entirely removed in the near future.

The forest in the late afternoon.

Other small changes have also been made to the scene. I decided to increase the rock texture resolution from 1k to 2k, as I found low angle lighting to cause some small artifacts on the rocks due to specular highlighting. I also further tweaked the grass materials to provide a more accurate look in most situations.

CryEngine Forest Scene

This forest scene has acted as a 'technical test' for my skills: it has combined my knowledge of PBR materials, CryEngine's asset pipeline, and performance focus while also introducing me to proper foliage creation techniques, as well as in depth knowledge of the lighting system and a few other advanced rendering techniques.

The finished scene.

From an artistic standpoint, I think the scene turned out quite well. The lighting is believable, the assets are of good quality and the scene composition seems natural. However, from a technical standpoint, this scene represents quite a bit.

Rendering

If you've never used CryEngine, then the display info command may seem a bit overwhelming at first; but let me explain some of the crucial and interesting aspects. Firstly, on the second line you can see some information on the spec the engine is running at: in this case, it's rendering in DirectX 11 at maximum settings, with a form of 'SMAA' (an anti-aliasing type) enabled and 'SVOGI' enabled as well. While the first 3 settings may appear normal to anyone interested in game-rendering technology, it is that 4th setting which is quite interesting. 'SVOGI' is a voxel based global illumination system which actually runs in real-time; obviously, this is quite a powerful tool for creating realistically lit scenes.

Below this, the 3rd and 4th lines give standard scene information: in this case, the scene has 751 object draw calls, 1083 shadow draw calls (total of 1834), while the entire frame consists of some 124,918 polygons.

Objects and Textures

As for objects, they are all quite simple. In the scene there are a total of 9 unique objects:

  • A Large grass patch (28 polygons)

  • A Small grass patch (30 polygons)

  • A Fern plant (276 polygons)

  • 2x Rock objects (629 and 775 polygons)

  • 4x Tree objects (149 to 365 polygons)

In terms of polygon usage, all of these objects are quite low in count, with the exception of the Fern which could likely be reduced to around half the current size. The trees are obviously very basic, considering they only appear in the distance and behind a fair amount of depth blur.

These 9 objects are then varied with scale and rotation changes while using shared texture maps and materials to further reduce memory and draw calls. For example, the large and small grass patches share the exact same 1024x1024 diffuse grass texture as well as the same shader based material. The trees also work on a similar principle, meaning that there is only 1 tree material (containing 4 sub materials) in the entire scene, heavily utilizing combined texture maps as well as shaders. This tree material contains the usual diffuse/specular/normal/gloss textures (all 1024x1024) for the trunk material, but the leaves, branches and other foliage come from just two textures, one being 1024x1024 and the other 512x512. everything else on the trees is based entirely on shaders.

The only truly "unique" assets in the scene are the rocks and distant ferns. The rocks utilize the usual diffuse/specular/normal/gloss textures (all 1024x1024) whereas the fern is again heavily shader based, utilizing a single 1024x1024 diffuse texture. In addition, there are 5 terrain textures present, all of which are 1024x1024 in size.

In general, it is likely that I could further reduce texture quality to save on memory. The grass could likely be dropped to 512x512, as could the fern, without sacrificing much in the way of quality. The terrain textures could also likely be simplified, since it is barely visible, to a single material type with a few color variations.

Conclusion

In general, I think this scene uses most of the optimization tricks I could think of (or find), and as a result, is quite efficient. As usual, there are likely further things which could be improved, but at some point, the time invested simply won't match the performance gained (at some point, I would be saving fractions of milliseconds). I may post a future update if I find that anything major can be accomplished in terms of optimization, or if I find any interesting tricks, but I feel like this scene is essentially complete.

A Camera

The camera was an interesting project, one in which I started using a bunch of new techniques and tools to try and push my work to a new level of quality. Personally, I think the asset turned out quite well; and the process was quite interesting.

The mesh

Wireframe view of the camera model.

Wireframe view of the camera model.

At only 3,531 polygons, this camera model is fairly lightweight, while maintaining a high degree of accuracy and smoothness in curved areas. Instead, the vast majority of the detail comes from the normal map (which is to be expected of a game asset).

The Normal Map

Creating of the normal map was a bit different than usual, at least for me. Instead of using a high poly model with sculpted details, I instead used Quixel's "NDO" tool. This tool allows for the creation of normal map details using simple black and white masks, and then assigning parameters to the masks (indent or extrusion, curvature, etc.). This turned out to be quite an efficient method of normal map creation, since I could see the changes to normal map being applied to the low-poly mesh in real-time, as opposed to requiring lengthy normal map bakes when using a high poly mesh.

The normal map created in DDO.

The normal map created in DDO.

As you can see, just even with only some details added via the normal map, the asset gains a large amount of definition. However, this is only the beginning; the asset gains many more details when materials are added via Quixel's "DDO".

The Materials

Using the normal map created in "NDO", as well as a baked Ambient Occlusion map, I used Quixel's "DDO" tool to create the materials needed: In this case 19 materials were used, along with a large selection of custom masks and layers.

The diffuse, gloss, spec and normal maps from DDO, and how they appear on the model.

The diffuse, gloss, spec and normal maps from DDO, and how they appear on the model.

Here you can see the materials used for the asset, and how they appear on the actual mesh. Of course, all the materials are pointless if there's no way to render them.

Rendering

Instead of using the built in "3DO" renderer that Quixel comes with, I decided to switch back to Marmoset's "Toolbag 2"; a program I had experimented with in the past, but never really went into that much detail with. This was a good chance to really improve my experience with it: and I think it turned out well.

The final render.

The final render.

The final render uses a fairly standard setup: there are 4 lights (and 2 ambient 'sky' lights), all of the 'lighting' effects have been turned on, and the reflections are calculated using the 'GGX' BRDF type. In addition, the textures have been down-sampled to 2048x2048 (from the original 4096x4096 in 'DDO'); while not necessarily needed, it was interesting to see what could be done with relatively small texture sizes (compared to some game's 4k and even 8k texture sets). The final image was rendered at 7680x4320 (8K) and then down-sampled to 1080p to ensure a clean final image. This was probably entirely unnecessary, but it was nice to see that such excessive resolutions could be rendered without any real problems.

I hope you enjoyed this breakdown. I'll be posting my next one fairly shortly, focusing on my new CryEngine forest scene.

Building A Tank Rig

This is how I created my Panzer 2 'Luchs' dynamics-driven rig. For basic info, it is important to note that this rig is built in Cinema 4D R13 using the default physics system (dynamics) and is then being run on a PC with an Intel Core i7 2600k (early 2011 CPU); so decent hardware, but nothing incredible.

As you can see, the tank (in all it's ~70k poly glory) drives around, reacts to terrain bumps, turns and does pretty much what you would except a tank to do. So, how does this work?

Breakdown

Well, this is it. As you can see, the rig is broken down into a few key components. The overall entity (so you can move it around as a single piece), the Geo (in case you want to change it) and the dynamics (the parts that do the work). On screen we have a single controller (the cross on the left) that the turret points at, and on the right we have the overall controls for the vehicle.

The controls are fairly basic: the RPM controls the speed for each track, the torque controls how much power you are giving the tracks, the breaks can be applied via a percentage, and the suspension stiffness and damping can be easily adjusted. With these controls it is very easy to quickly set up the movements you want the vehicle to perform. Overall, this rig ends up being a 2.8mb file.

The way it actually works is also very simple: physics proxies. This is a techique often used in video games to simplify the physics calculations being done in order to improve performance: you essentially give the engine a rough estimate of the objects being used, and then disguise these basic physics proxies with more complicated objects. In this case, the actual physics rig actually looks like this:

Physics

This certainly seems a lot more simple. What's actually happening is that there are three key proxies being used. Firstly, there are the roadwheels: in this case, very simple cylinders. These are what control the movement and track physics. These wheels are large enough to clip through the tracks and contact the ground directly: thus the tank is actually a 'wheeled' vehicle instead of a 'tracked' one. These wheels provide the traction, the physical interaction and track physics. The tracks are created via a spline (not shown) wrapped around these wheels, with vertices directly above and below each wheel. When a wheel goes up due to terrain variation, these points move up and down with the wheel, bringing the track links up and down as if they were actually contacted by the wheel. To create the movement of the individual track links, each link is actually an instanced object along this spline: the position of each link is then offset via a ratio with the wheel rotation, keeping the tracks in sync with wheel movement.

To handle the vertical movement of the wheels, I have simply used the 'wheel suspension' connector, with it connection the wheel proxies and a locator to which the hull and other parts are attached. The exception to this being the front and rear wheels, which are not attached via suspension (as in the real tank). Each wheel is also given its own motor to give it power, and all these motors are linked to the master controls; as are the suspension connectors.

The large rectangular 'skis' are used to create terrain deformation. When these come in contact with a specific ground plane (must be marked as deformable), the plane is simply pushed out of the way. How? Cloth dynamics. The ground is actually a fairly low poly plane with a cloth deformer attached to it. This 'cloth' is set to have no rebound and no other movement influences: once deformed it stays deformed. With the proper settings, it can create a fairly realistic approximation of snow or mud being displaced by the tank's tracks.

Lastly, the antennas: these are actually just giant 'hairs'. Using a spline with a length segments, each antenna is given a spline dynamics tag and a fairly high degree of stiffness. This results in 'hairs' that act like large wires, or antennas. The turret works on an even simpler system: it's just a target tag with a locator set as the target.

Realtime Use

This is how it looks in practice (this is the first frame from the video at the top). We have a very low poly ground plane (non-deformable base for the wheels to interact with) which can be hidden in the final render (it is in the video). On top of that we have a deformable snow layer, which is being depressed by the 'skis' shown earlier, and finally we have the tank itself, being controlled by the various physics proxies. It ends up being quite simple.

So is it really real time? Yes, it can be. When experimenting with movement, the vehicle is being run entirely in real-time. You can keyframe the controls and each time you run it the simulation will be accurate. However, I would not recommend using real time in the final render: real time physics are by nature not 100% repeatable. As such, there is the option to cache the physics: either entirely (every wheel, terrain, antenna, etc.) or only partially. I usually use the partial option, where only the location of the hull and terrain deformation are cached, leaving the tracks and antenna to run in real-time. This allows for accurate camera placement (since the tank location will not change each run) as well as easy render comparisons (for the same reason).

Regardless, it ends up being fairly fun to create simple test tracks for the tank to drive around in.

Note: The antennas only act 'strange' when seeking through the timeline. During playback/rendering, they are fine.