hey, long time lurker on this forum and wanted to ask a question about hard surface topology. I'm taking an online course and it was going pretty well until I reached this part of a GameCube controller.
from my understanding, I thought it was a bad practice to have a lot of poles... and I also understand this is a flat surface which might make it an exception. But I am also wondering if I am learning bad topology? It seems like the bevel to create the hard edges of the octagonal shape surrounding the c-stick is why the poles are coming into the picture.
My brain is fighting the teacher and telling me that this edge flow could be better - but I am also still learning so any insight on this would be appreciated
Replies
however, based on my (admittedly very rusty) subdiv modelling experience this is a perfect case for using ngons over triangles
Always wondered the same thing tbh. I'm not sure if this class is focused on games, but more of the techniques of hard surface modelling. Would like to know this as well. Seems like a lot of the classes use the support edge loops but don't explain preparing game models
Probably planning well in advanced, when-making the loops thinking bout the game res throughout. Also heard about some plugin or application process that can do this for "us/them", idk if its an online only thing, heard about it recently though on some youtube video. (asking me to pull that up will take a bit, better to search it out if it is not already in the wiki.)
And yeah, that's more or less it.
Don't skip learning the fundamentals, folks. If you can't precisely control topology when you need to, you won't get far. But if you know what you're doing, you'll learn when and where you can take shortcuts.
heh - yeah. I dont take what I am learning for granted - I was just more wondering if the topology was good and then everyone said subd wasnt used very much. but I am really enjoying this class and taking in as much as I can. I cant wait to get to the level everyone here is at.
That's probably the most important part to clear up isn't it ?
Let's assume that the end goal is an in-game asset indeed. Well, there are many ways to get there, the main two for detailled and realistically shaded games being :
A : a dense, raw mesh capturing all the details in geometry, and textured in a very straightforward way. You'll see this in high end simulators, some scifi games (Alien Isolation, Death Stranding), and overall in titles requiring somewhat of a clinical look. Of course I am simplifying here but you get the idea. It can be especially appropriate for large assets ; and of course it used for every single game environment out there for buildings, large structures, and so on.
B : a less dense ingame mesh, with its shading altered by a normalmap capturing the surface information from a highres source created just for that purpose. This source is referred to as "the high", and can be built with any appropriate technique - raw geo, subdivision mesh modeling, CAD modeling, freeform sculpting, and any combination of these.
You are currently following approach B.
The model you are currently showing us is a "high", built specifically here as a subdivision model. To get to a final game asset you'll also need a "low", which will receive the surface information of the "high" as a normalmap (and a few other passes). So in this case it can make sense to start from the high, since the subdivision cage you are building is also 80% close to a good "low" for the actual ingame mesh. So you are in essence doing two steps at the same time. Your work on the low will simply consist of taking a copy of your subdiv cage at level0 and tweaking its geometry as needed - perhaps adding edges for a smoother silhouette, and removing unneeded internal geo when not useful, for it to have just the right amount of necessary detail.
Now it would also have been possible to start by doing the final low right off the start, and then using that as a base to create a subdiv version just to source the smooth surface data. The advantage of this reverse approach is that if production is in a rush, and you have no time for endless subdiv/sculpting, you have your final game mesh ready early, and you can also choose to only do a high for the parts that really need baking and leave the rest as "raw" shading. The disadvantage is that you won't have a "pretty" subdiv render to show early on and sign off, and depending on the kind of AD you are working with it can be an issue.
And as said there are plenty of *other* ways to get to the end result, some of which may even be more appropriate for something like this gamepad asset, mostly depending on art direction. But that's irrelevant really since the actual goal of the teacher here is clearly to teach the "low + subdivided high as used in Fortnite" approach in general, and not to teach "the best way to make a game asset of a realistic gamepad" in particular.
Lastly and as mentionned by some people above, it still would have been faster to start with a roughly put together blockout, using booleans and regular modeling - As this could then serve as solid base guide for both the high and low.
Now all that said the above apparently not being explained clearly at the beginning of the class is somewhat worrisome.
that said .. having a buttload of geometry does lead to a larger package size on disk and that's not good for the customer - i don't want a half terabyte download when I buy a game and neither does anyone else.