Threshroge posted at 4:19PM Mon, 27 April 2020 - #4387508

So to recap: smoothing is not stored in the OBJ, it is a algorithm by the renderer to express geometry in visual form.

As @LuxXeon pointed out, "smoothing" information can be stored in an OBJ, but its a bit of a crap shoot as to what you're going to get on import from one app to another. For example, for a long time, LightWave ignored smoothing groups entirely, then finally added support for them on import only; you could use the imported groups or not, but you still couldn't export an OBJ with smoothing groups, or even create geometry with smoothing groups in LightWave. Same goes for other software, some will use 'em and some won't, so its probably not a bad idea to use a different format that does more universally support those features [like FBX] if smoothing information is something you need. Ultimately, you'll need to figure which modeling methods and export/imports work for you personal pipeline, and this can take a little trial and error.

As for my problem, with wonky normals: if you're making extremely low poly meshes, you want to turn off smoothing per the renderer you're using, because YOURE deciding to be unorthodox by making shapes five polygons long by five polygons wide, and realistically and ideally, a person needs to not really touch program's smoothings mechanisms, and instead should simply add rows and columns of mesh polygons, fair enough?

Hmm ... no, not really. That's almost the opposite of what I meant actually! Its all about control, and being as hands on as necessary. There's times you want smoothing, and times you don't, but that's not something that's tied to the polycount, so don't conflate "low poly" and "no smoothing", its a decision you need to make based on the object you're modelling and how you want it to look. When I mentioned n-gons and triangulation, its something you DON'T want to leave in the computer, that's something you want to be hands on with generally.

Your mesh probably shouldn't use smoothing, because all the angles are 90 degrees or there abouts and the way you modeled it won't support smoothing very well [as you've found out], also, and I'm assuming here, a "smoothed" look probably isn't what you're going for if you're doing a blocky/pixelized sort of thing?

Anything close to or over 90 degrees probably shouldn't be smoothed, there are exceptions of course, but the closer to 90 degrees you get, the more likely you are to get into problems. Personally, I usually like to work with a smoothing angle around 35 degrees, anything that needs to be smoothed beyond would get more geometry to create the smoothing, but that's my preference, and what fits my workflow and end goals for my models.

Making smoothing work for you, might take some practice, and like I said, you'll need some trial and error to get find the right settings and right geometry for your pipeline and goals. Here's a bit of a breakdown to get you started.

In examples A and B the smoothing would extend across all the polygons in the diagram, when that happens, you start to get wonky things happening as that smoothing runs into more edges. In examples C and D tho, because there's a row of "control" edges, the smoothing is confined to the orange polygons, and the rest of the polygons retain their original normals, so you don't get any problems.

For my personal work, I'd use examples A and B without smoothing, or with smoothing below the threshold of those edge [89 degrees in A, and 44 degrees in B]. A would primarily be for mock-ups and block-ins. B would be used for "low poly" stuff that doesn't get a normal map generally. You'll notice in example B, even when the smoothing is set to 135 degrees, because of the extra edge, it doesn't get quite as bad as A does. C and D I'd use with smoothing on, and because of the extra edges I wouldn't have to worry about the smoothing angle, I could set it as high as I want. C is my standard edge flow for subdivison modeling, and D is for most of the rest. Essentially C and D give you a result similar to the increasingly divided cube a couple posts up. The difference being you're not filling the whole surface with extra geometry, you constrain it to just the edges.

Now, there's another option as well. Its not the cleanest option [if you're sending a mesh off to someone to paint weight maps for or rig, they're probably not gonna be your friend after], but it works, and that's to "split" faces [ Y key in edit mode when you have faces selected]. In your model, you'd have to select all the front faces, and all the back faces, and "split" them from the sides. Then you'd need to go around the sides, and select each face [or group of faces if they're "flat"] and split them from any faces that its perpendicular to.

This is, kind of a brute force way doing the same thing as smoothing groups. Smoothing groups create a clone of the vertex and assigns that clone to a different smoothing group than the original based on which face its "attached" to. When you split faces, you're making a clone of each vertex that/those face[s] consists of. This is how I handle low-poly meshes that I'm not using a normal map with but have complex surfaces and smoothing requirements. This also allows you to do stuff where you only want something smoothed in one direction, but not another; you can split the faces, then remerge the verts [by distance] on JUST that edge.

So, I learned Rosty doesn't like animated GIFs apparently? So that last image is the frames from two GIFs side by side. but hopefully still clear enough to follow along.

Core i7 950@3.02GHz | 12GB Corsair Dominator Ram@1600mHz | 2GB Geforce GTX 660

Lightwave | Blender | Marmoset | GIMP | Krita