https://www.youtube.com/watch?v=NuWqORkAKeM Here I have performed some rather quite simple geometry in a youtube video and the end results the normals are quite awkward. I would like to know, how the normals come to behave this way based on the topography habits shown in the video. Renderer is Octane, but initial modeling is Blender and scene work is poser.

When you import the prop into Poser - play around with the settings.

The setting: Make Polygon normals consistent can mess up your normals or can sort them out.

The setting: Weld identical vertices can in some cases mess up your model.

If the crease factor / smoothing is set in Poser (under the prop's properties) - this can either help you to make the model look nicer - or harm you by distorting it - it depends on how it was modelled - it will distort the uv mapping as well.

Another option is to import the models in parts into Poser - for example if your platform isn't perfectly flat on the floor, it could be distorted when brought into Poser - and bringing it into Poser in parts will solve that.

---

Casual games for Windows PC, browsers and Android devices
https://www.evolutionarycasualgames.com/

Short answer ... the "topographical habits" in that video, aren't meant for "smoothing", once smoothing is applied to the surface/material, you'll get the wonky normals you're seeing. Turn off surface smoothing, and your normals issue will resolve.

Longer answer ... render engines can only handle triangles, so all geometry gets triangulated when you render [and when i say "render" i'm including, rendered to the viewport]. Once triangulated you're left with a set of 4 points, two that are shared on a common edge, and two that make up the third point of each triangle in a pair, and those 4 points are used to calculate the smoothing across that shared edge. However, you're also asking your software to calculate smoothing for the other two sides of each triangle, based on the pair of triangles shared by that edge. The more radically that smoothing calculation differs from the original, the more of a mess you're going to get.

In that image, the smoothing is fine across the edge when its just one pair of triangles, but when you add the next side of the cube, you've got a smoothing of 90 degrees [top to front], against a smoothing angle of 0 degrees [top to top], against a smoothing a smoothing angle again of 90 degrees [top to right side], and there just isn't a way to resolve it that looks good, so you end up with the wonky normals you're seeing. This all gets compounded when you look at that front right corner vertex, that gets its smoothing information from the top/front + top/top + top/right + front/right pairings, each of which is smoothed entirely different from the next.

Now as you add more polygons, it becomes less noticeable because you're not asking the software to smooth each pair across as many radically varying angles at the same time as you are with the simple geometry and you're also decreasing the visible size of each smoothing calculation. You'll see the corners still exhibit a bit of a oddness, but they're better than they were, and the straight edges themselves are fine, as is the flat surface making up the sides.

While more geometry IS a solution to your normal issue, the better solution is to just disable surface smoothing, and save rendering that many more polygons, because 12 triangles [in a cube] vs 9000+ probably isn't worth it for your use case.

[EDIT] The conversion of everything to triangles for rendering, is the reason "n-gons" are generally frowned upon because that leaves the decision of how each n-gon is broken up into triangles, entirely up to the computer. When you're working with dynamic geometry, it may not even break the n-gon the same way from one frame to the next, which can cause pretty serious shading issues in a rendered sequence.

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

Lightwave | Blender | Marmoset | GIMP | Krita

Okay so between Blender, Poser, and Octane, what is it I turn smoothing off in? And A+ for such a superb, brilliant explanation!!

In Blender, select your object [object mode is fine] and you set the shading to "smooth" or "flat" depending on your object; in your case, you want flat. Blender's default smoothing angle is set to 180 I believe, which will give you, well, what you got! You can walk it down until things look right if you have an object that has curves and hard edges.

Note - this is a slightly older version of Blender, but things should still be largely the same.

As far as Poser/Octane, I've never used either, and that's where you'll probably have to address this, because that's where you're rendering ...

"OCTANE POSER PLUGIN USER GUIDE - 4.10

Smoothing In the Poser plugin for Octane you can use 2 different methods of smoothing: The Poser smoothing algorithm and the Octane algorithm. In most cases it will not make much difference, but sometimes Poser smoothing leaves artefacts when rendered in Octane. Octane smoothing however has a single smoothing angle for all geometry while you can specify a separate angle in for each mesh in Poser.

Unfortunately, you can only use one smoothing algorithm at a time. The Poser smoothing is turned on when the Smoothing Angle is set to 0 in the Setup Window. If you choose an angle (like 80 degrees), it will use Octane smoothing."

• Page 93 - OCTANE POSER PLUGIN USER GUIDE

Hopefully that at least starts you in the right direction?

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

Lightwave | Blender | Marmoset | GIMP | Krita

So to recap: smoothing is not stored in the OBJ, it is a algorithm by the renderer to express geometry in visual form. 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?

If you use FBX file format, you can retain smoothing group information rather than the explicit vertex normals. I don't know if Poser can import FBX, but it could be a better option for transporting models where you need specific smoothing information from the modeling package in other software solutions.

______________________________________

My Store
My Free Models
My Video Tutorials
My CG Animations
Instagram: @luxxeon3d
Facebook: https://www.facebook.com/luxxeon

BTW, smoothing information (hard or soft edges) can be retained by the OBJ file format itself. Some packages, such as 3dsmax, have specific settings in the export dialogue for OBJ which allow you to save smoothing groups. This is saved in combination with explicit vertex normals. If you look at the OBJ in a text editor, you might see "Vn" in the text, which stands for vertex normals. If you see text blocks starting with "S", these would be smoothing information. Now if the smoothing information is correctly interpreted by a software's OBJ importer is another story, but OBJ can handle them. Here's a screenshot of the OBJ export dialogue in 3dsmax, for example.

So it all depends on the software's import/export features of whichever file format you choose. Many packages only use some of the features OBJ is capable of handling. This is why FBX became the preferred file format for some file exchanges. The import/export plugins for FBX tend to all support the same things (usually), but I did notice Blender's FBX features leave something to be desired when it comes to rigging and animation.

______________________________________

My Store
My Free Models
My Video Tutorials
My CG Animations
Instagram: @luxxeon3d
Facebook: https://www.facebook.com/luxxeon

Thank you

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

Excellent presentation, Warlock279. I don't think I could have explained it as well as you just did. Very good.

______________________________________

My Store
My Free Models
My Video Tutorials
My CG Animations
Instagram: @luxxeon3d
Facebook: https://www.facebook.com/luxxeon

LuxXeon posted at 4:13PM Thu, 30 April 2020 - #4387661

Excellent presentation, Warlock279. I don't think I could have explained it as well as you just did. Very good.

Thanks! :) I try to be helpful once in awhile at least.

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

Lightwave | Blender | Marmoset | GIMP | Krita