Facing Everyday Objects
polycounter lvl 6
Hello everyone 
this is my attempt to escape from tutorials and finally build something all by myself. The idea behind this thread is simple: picking objects that are around me and trying to turn them into game assets.
I make mistakes along the entire pipeline, so feel free to critique every aspect of my work (modeling, texturing, UV packing, final presentation, my terrible English...).
Here are the specs:
- The softwares I'm using are Blender (for modeling, retopology, unwrapping), Substance Painter (for baking and texturing), Marmoset Toolbag (for rendering), Affinity Photo or Affinity Designer (for alpha and decal creation).
- I'm texturing all the assets in the PBR metallic workflow.
None of these pieces will be included in my portfolio: they are just part of my learning experience.
None of these pieces will be included in my portfolio: they are just part of my learning experience.
-- all of the above was slightly revisited on 15 May 2017 --
Replies
References
Modeling and Retopology
Unwrapping
Texturing
Rendering
I underestimated the complexity of this project at my current skills level: as a result, it took me an insane amount of time to complete it. But it was fun, and I think I learned a lot.
References
Modeling and Retopology
I created the circular cavities on the front, and the rectangular ones on the back, as floaters: for each one of them, I started with a plane, modified its topology to match the cavities, projected the plane on top of the surface thanks to a shrinkwrap modifier and, finally, performed the necessary extrusions to get the cavities.
Modeling the side details of the radio was tough. Basically, for those details I made a double spline projection (with a tool that in Blender is called "knife project"): I explain further this technique in the image below.
Let's talk now about retopology. In Blender start with a single vertex, activate the snap feature, set the snap on face, and you are good to go. Initially, I completed the entire low poly and then I went through the baking process in Substance Painter: the end result was a complete disaster. There were artifacts everywhere. So I started over but, this time, I adopted this strategy: make one complex piece, run a test bake in Substance Painter, move on to the next piece. It worked.
Unwrapping
To optimize the UV space, I often end up increasing the resolution of pieces that, in the end, are not so important: I'm not sure if this is a good idea, but I guess that as long as the final materials mantain an overall consistency, it should be fine.
Texturing
Not much to say here. As always, playing with the roughness map is the key. I experimented adding color variations in the albedo, in the hope of making the look of the radio more interesting.
Rendering
The radio has some transparency going on:
I must confess that I handled it in the wrong way. Let me explain. In the low poly, I modeled the main body of the radio as a single piece. In Substance Painter, I used the "pbr-metal-rough-with-alpha-blending" shader; once in Marmoset, I plugged the albedo map in the trasparency slot, and set the blending mode on "dither". Later, reading threads like this, I discovered that you should always make the trasparent object as a separate piece, give it a new material in Marmoset, and use the "add" blending mode. Lesson learned for the future.
Edited: oops sorry, you were talking about the radio! In that case, some of the details went too deep inside the main body of the radio (and that was the reason I modeled them), but it is true that others could be solved through alphas, silly me! Thanks for bringing it to my attention
First, this is my low poly:
It's quite dense: 6026 tris. I think that part of the problem is the way I'm dealing with cylindrical parts: a low poly cylinder with 16 segments always seems too blocky to me, so I often end up giving it 20 segments... Am I wrong?
Your bake looks good to me - how big is your map and how much space/pixels do you have between each shell? On your low poly you could possibly loose a few edges loops (you have some double loops at the very edges). If the loop isn't changing the silhouette/shape in any way then you can usually lose them.
As to it looking blocky - well yeah 6000 tris can seem like a lot for something like this however it really depends what you are using it for. Often a prop like this in game engine would appear quite small and so then it won't look blocky from the point of view of the player at a lower polycount. If this is for a portfolio piece and you will see the individual asset up close then going higher with the polycount is fine. I'd say this is good, just remove some more of the loops that don't support the geometry. If this is for an in-game scene test it out to see what polycount is needed.
Now, in your experience, can you tell me if point 1 and point 2 are false problems? Because honestly I don't know...
Edit: Regarding the point 2... I guess that the fact that I add loops to fight the oddities in the normal map has something to do with the synched workflow (one smoothing group across a continouos mesh). In fact, in the "traditional" game asset workflow, the shading of the low poly was controlled by hard edges and, therefore, multiple smoothing groups. In other words: if you are working with the synched workflow you can control the shading, and the cleanliness of the normal map, by adding more geometry, while if you are following the traditional workflow you can use less geometry and control the shading through hard edges/smoothing groups. Again, these are just my suppositions, I'm not so expert when it comes to normal maps... I'd still like to know what you think about that.
Thanks for the confirmation, that's exactly what I thought: for an actual game 6000 is probably not fine (because the controller is a background prop, it's small and the player will not examine it very closely), but for the portfolio should be ok... and yes, in my case I'm treating it like a "potential" portfolio piece.
Seriously though, while there are reasons to want to keep large gradients out of your normalmap (compression, for one), it's at the expense of a lot of tris here, tris that I think would be better used to round out the rest of your mesh (getting it closer in shape to the highpoly).
In a real-world scenario it also depends on where your game's bottleneck lies.
-every uv island needs to have its own smoothing group on the low poly
-you will need to separate uv islands where you have diagonals or close to diagonals (70-90 degrees)
So if you have a cube every side is a uv island and all 6 uv islands have their own smoothing groups. Can't see how your smoothing groups are but it looks like your entire mesh has the same one.
I know, I know, I'm picky...
A synced (and not synched) workflow just means your baker and target rendering engine use the same way to encode/decode normalmaps. This has happened since normalmaps were first around (doom3 came with its own normalmap baker), but only now have tools caught up and there's somewhat of a standard: Mikkt, making it easier to bake in the tangent space that your target engine requires.
Now, using one single smoothing group is fine, but that's in a perfect scenario. As I said, texture compression can be a reason to want to eliminate harsh shading on your lowpoly (which will result in big gradients in your normalmap), which would mean hard edges ('smoothing groups' in max-speak) or bevels to control the shading.
You can start by making every UV seam a hard edge on your mesh, which, if you've modeled/unwrapped with some foresight, will help your asset shade better, which will make it less reliant on the normalmap, and make compression artifacts have less of an impact.
@Eric Chadwick is hosting a nice article about this on his website: http://www.ericchadwick.com/examples/provost/byf2.html#wts
The first part (linked at the top of this one) is also worth reading.
All of this is moot if you've got polygons to burn though. On a real project you'd be able to ascertain where your bottlenecks lie (eg. batches, texturesize, polycount...), and optimise accordingly. As this is a portfolio project (?), I'd just make it look as good as you can, and show that you understand how to create a well-optimised lowpoly mesh that bakes well.
Second, I put aside the whole 1 smoothing group thing, and started to work with hard edges/smoothing groups splits. I set the hard edges, converted them in UV splits, refined the seams where needed. That being said, this is my current situation:
Thanks to the hard edges, it seems like my low poly shading is decent in Blender and my normal map doesn't have extreme gradients:
Crits and comments are welcome, as always.
Using the same amount of sides everywhere means large shapes like the places where the dpad and ABXY are, will look angular even at fairly small sizes like in your last post, and small elements like screwholes get much more than necessary and thus eat up precious resources.
You could use a straight relation between scale and sides; twice as big gets twice the sides. The benefit of this is that large objects get the detail they need and small objects don't use as much polygons. But as you can see, for very small objects this will not end up well. At 4 sides for a cylindrical button or screwhole, you'd probably be better off using only a bumpmap. One interesting benefit of the straight up correlation, though, is that texel density ends up exactly* the same on all cylinders.
Using a ratio of 1,5 is a good middle ground. It gives larger shapes more detail without costing excessive amounts of triangles, and it keeps an acceptable silhouette for even the small details. You'll notice that in my example the topleft (16 sides large) and bottom right (8 sides tiny) look about as blocky. But having small elements look blocky has several benefits:
-you tend to have more of a smaller element. For example, you have 5 round buttons, and half a dozen screwholes, but only two large circles. So optimizing the small elements has a much bigger impact on the overall budget.
-small elements tend to scale much faster in-game. A grenade you throw quickly goes from being 10% of the screen, to 10 pixels in the distance. But that Nuclear reactor cooling tower in the background stays almost the same size on screen, even if you sprint towards it for 10 seconds.
Now obviously the number of 1,5 is just a rough one. In fact, this example divides 1,333 to go from 16 to 12. Because 16/1.5 doesn't give a clean number. And upscaling 12 to 18 may not be ideal either (can't texture in quarts). And you might want to have an upper or lower limit, so you don't end up with 1000 sided silos or triangular screws.
One last thing to keep in mind is how many loops you're using. Your current ABXY buttons are 20 sides, but with an additional loop. So a total of 40 quads and 20 tris; 100 triangles per button. You've kept the loop to have tight edges and a flatter bumpmap, but the buttons are small enough that you won't really notice gradient banding, plus you've already de-looped the dpad and start/select buttons. So why not save yourself 40% per round button, and just use a simple cylinder? That's a total of 200 triangles, 5% of your entire budget. Pretty good savings for a simple tweak.
And some feedback for this specific model:
- the bumpers are almost square, but the triggers are obviously rounded. Cut some (vertical) loops from the former, add to the latter.
- you've got a squareish grid on top, this looks like it could just be a single quad? You're using intersecting geometry anyway.
- with intersecting geometry, delete hidden triangles. And see if there are some loops you can move a slight bit, so you can cut off even more strips.
-Are the insides of the screw holes 20 sides? You can taper them to be 10 sided, saves you 20 tris per hole. 7 holes, another 140 tris saved, 3% of your budget. How many people will look inside the screw holes?
-Or more drastically: consider how important details like a USB and screw holes connector are. Can they be carried by just the normal?
Okay, not exactly due to circle-approximation and rounding. A square with diameter/sides 1 would give an octagon with 8 sides of 0.8284, polygon with 16 sides of 0.7956, 32 sides of 0.7879, 64 sides of 0.7860 and so on. The difference between those last two is 0,2%, which is close enough for most purposes.
I suppose that I can force them to 10 sides, hopefully
From now on, I will take into account your advice for every future projects, thanks again
Good job on the re-bake. I notice you posted separate images for hard edge placement and seam placement. I normally give all seams/UV splits hard edges unless there is a reason you are doing that that I'm not following?
I'm digging the clear progression and goal.
There is a lot of useful information on there about baking if you havn't seen this already.
Now I'm going to export the updated version of the normal map: once re-imported, I will be able to bake the 'additional maps' (world space normal, ambient occlusion, curvature and position) that work in conjunction with the generators inside of Substance Painter. In other words, I think I can start the texturing process