Blender and smoothing groups

Dutcheeseblend · 27 Aug 2015

Hi there!

Got inspired to start this thread by this one: http://www.fsdeveloper.com/forum/threads/united-states-navy-all-of-it.434697/page-3

Now I understood from various Blenderartists threads that Smoothing Groups (like we know them from Gmax, Max and such software) are not available in Blender. It is suspected that this is because Smoothing Groups can be regarded as a modifier, like we have the Edge Split modifier. I was a little surprised by Anthony's remark that the number of vertices remains the same, no matter how Smoothing Groups are arranged.

Let's start with a simple 32-vertex cylinder (vertex count is displayed in the upper bar). This is Mesh01.

This is a non-smoothed cylinder. The easiest way to smooth things, is setting certain faces to Smooth shading.
So, in Edit mode, select the wall faces and hit Z, press Shade Smooth.

This will be the result. Looks not very good, but good enough in some cases. Fact is that the faces are smoothed in two directions, because at every side there's a connected face. Here we have Mesh02.

To make it look better, split the edges of the top and lower face. I always call this function from the search function, but there are other ways to find it.

The resulting mesh has doubled the number of verts, because the wall and caps don't share vertices anymore. Result looks better, but optimal vertex count is compromised. This is Mesh03

Now I revert to the original mesh with smoothed walls (so Mesh02). I add an Edge Split modifier to it, giving this result, Mesh04:

In Edit mode, the number of vertices is still the original 32, so not 64.

On export however, all modifiers are applied, so in the final .mdl, the vertex count will be 64. This can be read in the generated .x as well.

A table of the results:

Code:

Mesh# | Bl. V-count | .X V-count | Properties
--------------------------------------------------
Mesh01       32           32       Flat shaded, no smoothing
Mesh02       32           32       Walls smooth shaded, no edge split
Mesh03       64           64       Walls smooth shaded, cap edges split
Mesh04       32           64       Walls smooth shaded, edge split modifier (applied on export)

Please, could someone do the same experiment in Max, Gmax or FSDS? I'm curious, and I expect a few others too.

Thanks, Daan!

JP "Penz" Pedersen · 27 Aug 2015

I'm just a simple beginner in the arts of Blender, but Edge Split totally cured some nasty shading issues I had on a "modified cylinder" - a semicylinder "cap" on a traffic light housing. I had already smooth shaded it, but it looked very weird when rendered. Not anymore.

Before:

After:

Great tip, thanks Daan!

- JP

krispy1001 · 27 Aug 2015

Hi Daan!

I have used smoothing groups when I used GMax and 3dMax when I was modeling Halo maps. So I have some experience with using smoothing groups. Now I know that Blender does not have smoothing groups available. My understand of what a smoothing group modifier is doing is basically just telling the render engine how and what direction to reflect light off of a normal. So you can accomplish the same thing with a normal map. So my question is, I wonder if you could use one normal map for smoothing and then use a second normal map for geometry? I think I will test this and see what happens.

Kris

GaryGB · 27 Aug 2015

Hello:

Some "gratuitous" links I found when researching this topic: :idea:

https://www.google.com/#q=blender smoothing groups

BTW: For those with an interest in a related topic arising within the context of 3D scenery object modeling in Sketchup (but IIRC, with some links to reference documents and tutorials for Blender versus 3DSMAX and Sketchup), here's a couple of recent 'vigorous discussions' on "smoothing groups".

http://www.fsdeveloper.com/forum/threads/decrease-polygon-edges-lines.434139/

http://www.fsdeveloper.com/forum/threads/a-great-extension-or-tool-add-on-for-sketchup.434704/

IMHO, some interesting questions may arise when one considers potential impact on:

* actual model geometry versus statistics ...with and without smoothing groups

* actual model geometry versus run time display ...with and without smoothing groups

* actual model geometry versus run time performance ...with and without smoothing groups

FYI: I recently asked Arno to review the issue of whether (and by what modeling methods) "smoothing groups" might be successfully imported and retained by ModelConverterX (aka "MCX") for those of us who use MCX to process 3D models prior to export for use in FS.

IIUC, Arno's reply was that he does plan to look into this subject further at some time in the future. :pushpin:

And, IIUC, it is apparent from a few end user reports linked from the above threads, that "some" implementation of "smoothing groups" does seem to be successfully imported and retained by ModelConverterX (aka "MCX") for 3D scenery object (as they already do for aircraft "SimObjects" ?) models prior to- and during- ...export for use in FS.

Hope this might prove to be of some interest to Blender users too !

GaryGB

Anthony31 · 30 Aug 2015

As I brought this up in the original thread I thought I'd add some info about smoothing groups.

The following medium resolution nut was made in FSDS. It consists of a six sided, four segment cylinder. It consists of a washer, the nut with a curved top and the bolt protruding through the nut. Once textures are applied it looks rather convincing.

In the picture the nut on the left (called nuttest_smoothing) smoothing groups are used to define the washer, curved top and bolt. Note that even the sides of the nut and end of the bolt have had smoothing groups applied. In the case of the sides of the nut these are alternating to maintain the six sided shape. The middle nut has no smoothing (nuttest_no_smoothing) and so looks very blocky. The right nut has had one smoothing group applied to all polygons (nutttest_all_smoothed) just to demonstrate the effect of smoothing the whole part.

Now Daan asked if someone could do an experiment in other modeling programs.

I exported each individual nut as .x files to determine the file sizes generated and see exactly what is happening with smoothing groups.

nuttest_all_smoothed has 30 vertices
nuttest_smoothed has 66 vertices
nuttest_no_smoothing has 94 vertices

Compiling the models and the MDL file sizes are:

nuttest_all_smoothed 1,774 bytes
nuttest_smoothed 2,926 bytes
nuttest_no_smoothing 3,694 bytes

Notice how the difference between the all_smoothed and no_smoothing is huge.

To me, it looks like the x file doesn't recognise smoothing groups. When you export as an x file any smoothing groups will have their vertices merged and the MeshNormals in the x file are adjusted to account for the smoothing.

Have a look at this vertice list from nuttest_all_smoothed

Code:

    Mesh Tube_2 {
        30;
        0.000036;0.333600;-0.684900;,
        0.288936;0.166800;-0.684900;,
        0.288936;0.166800;-0.434900;,
        0.000036;0.333600;-0.434900;,
        0.288936;-0.166800;-0.684900;,
        0.288936;-0.166800;-0.434900;,
        0.000036;-0.333600;-0.684900;,
        0.000036;-0.333600;-0.434900;,
        -0.288864;-0.166800;-0.684900;,
        -0.288864;-0.166800;-0.434900;,
        -0.288864;0.166800;-0.684900;,
        -0.288864;0.166800;-0.434900;,
        0.535236;0.309000;-0.194400;,
        0.000036;0.618000;-0.194400;,
        0.535236;-0.309000;-0.194400;,
        0.000036;-0.618000;-0.194400;,
        -0.535264;-0.309000;-0.194400;,
        -0.535264;0.309000;-0.194400;,
        0.535236;0.309000;0.250000;,
        0.000036;0.618000;0.250000;,
        0.535236;-0.309000;0.250000;,
        0.000036;-0.618000;0.250000;,
        -0.535264;-0.309000;0.250000;,
        -0.535264;0.309000;0.250000;,
        0.535236;0.309000;0.348300;,
        0.000036;0.618000;0.348300;,
        0.535236;-0.309000;0.348300;,
        0.000036;-0.618000;0.348300;,
        -0.535264;-0.309000;0.348300;,
        -0.535264;0.309000;0.348300;;

and compare it to this one from nuttest_no_smoothing:

Code:

    Mesh Tube_1 {
        94;
        -0.000008;0.333600;-0.684900;,
        0.288892;0.166800;-0.684900;,
        0.288892;0.166800;-0.434900;,
        -0.000008;0.333600;-0.434900;,
        0.288892;0.166800;-0.684900;,
        0.288892;-0.166800;-0.684900;,
        0.288892;-0.166800;-0.434900;,
        0.288892;0.166800;-0.434900;,
        0.288892;-0.166800;-0.684900;,
        -0.000008;-0.333600;-0.684900;,
        -0.000008;-0.333600;-0.434900;,
        0.288892;-0.166800;-0.434900;,
        -0.000008;-0.333600;-0.684900;,
        -0.288908;-0.166800;-0.684900;,
        -0.288908;-0.166800;-0.434900;,
        -0.000008;-0.333600;-0.434900;,
        -0.288908;-0.166800;-0.684900;,
        -0.288908;0.166800;-0.684900;,
        -0.288908;0.166800;-0.434900;,
        -0.288908;-0.166800;-0.434900;,
        -0.288908;0.166800;-0.684900;,
        -0.000008;0.333600;-0.684900;,
        -0.000008;0.333600;-0.434900;,
        -0.288908;0.166800;-0.434900;,
        -0.000008;0.333600;-0.434900;,
        0.288892;0.166800;-0.434900;,
        0.535192;0.309000;-0.194400;,
        -0.000008;0.618000;-0.194400;,
        0.288892;0.166800;-0.434900;,
        0.288892;-0.166800;-0.434900;,
        0.535192;-0.309000;-0.194400;,
        0.535192;0.309000;-0.194400;,
        0.288892;-0.166800;-0.434900;,
        -0.000008;-0.333600;-0.434900;,
        -0.000008;-0.618000;-0.194400;,
        0.535192;-0.309000;-0.194400;,
        -0.000008;-0.333600;-0.434900;,
        -0.288908;-0.166800;-0.434900;,
        -0.535208;-0.309000;-0.194400;,
        -0.000008;-0.618000;-0.194400;,
        -0.288908;-0.166800;-0.434900;,
        -0.288908;0.166800;-0.434900;,
        -0.535208;0.309000;-0.194400;,
        -0.535208;-0.309000;-0.194400;,
        -0.288908;0.166800;-0.434900;,
        -0.000008;0.333600;-0.434900;,
        -0.000008;0.618000;-0.194400;,
        -0.535208;0.309000;-0.194400;,
        -0.000008;0.618000;-0.194400;,
        0.535192;0.309000;-0.194400;,
        0.535192;0.309000;0.250000;,
        -0.000008;0.618000;0.250000;,
        0.535192;0.309000;-0.194400;,
        0.535192;-0.309000;-0.194400;,
        0.535192;-0.309000;0.250000;,
        0.535192;0.309000;0.250000;,
        0.535192;-0.309000;-0.194400;,
        -0.000008;-0.618000;-0.194400;,
        -0.000008;-0.618000;0.250000;,
        0.535192;-0.309000;0.250000;,
        -0.000008;-0.618000;-0.194400;,
        -0.535208;-0.309000;-0.194400;,
        -0.535208;-0.309000;0.250000;,
        -0.000008;-0.618000;0.250000;,
        -0.535208;-0.309000;-0.194400;,
        -0.535208;0.309000;-0.194400;,
        -0.535208;0.309000;0.250000;,
        -0.535208;-0.309000;0.250000;,
        -0.535208;0.309000;-0.194400;,
        -0.000008;0.618000;-0.194400;,
        -0.000008;0.618000;0.250000;,
        -0.535208;0.309000;0.250000;,
        -0.000008;0.618000;0.250000;,
        0.535192;0.309000;0.250000;,
        0.535192;0.309000;0.348300;,
        -0.000008;0.618000;0.348300;,
        0.535192;-0.309000;0.348300;,
        0.535192;0.309000;0.348300;,
        0.535192;-0.309000;0.250000;,
        -0.000008;-0.618000;0.250000;,
        -0.000008;-0.618000;0.348300;,
        0.535192;-0.309000;0.348300;,
        -0.535208;-0.309000;0.348300;,
        -0.000008;-0.618000;0.348300;,
        -0.535208;0.309000;0.348300;,
        -0.535208;-0.309000;0.348300;,
        -0.000008;0.618000;0.348300;,
        -0.535208;0.309000;0.348300;,
        -0.288908;0.166800;-0.684900;,
        -0.288908;-0.166800;-0.684900;,
        -0.000008;-0.333600;-0.684900;,
        0.288892;-0.166800;-0.684900;,
        0.288892;0.166800;-0.684900;,
        -0.000008;0.333600;-0.684900;;

That's 94 versus 30 vertices due to one smoothing group. Obviously applying a single smoothing group to a whole mesh is not going to always be desirable.

I have attached a zip file with the x files and MDL files for each of the three models. The interesting differences are in the vertices list and in the MeshNormals lists in the x files. The differences in the MeshNormals is particularly interesting.

Now, I have for a long time always used smoothing groups. Even on something as simple as a plain aircraft hangar I will smooth the sides with their own individual groups. It won't make any difference to the appearance in FSX if you use a smoothing group on a flat rectangle but as each rectangle is made from 2 triangles by applying a smoothing group to even those 2 triangles it will reduce the number of vertices, the file size and, I presume, the performance, compared to not using a smoothing group.

Arno makes mention of this in his performance tutorial videos from a few years ago which is why I know always use smoothing groups. Here is a youtube link to his first video (of two):

Anthony31 · 30 Aug 2015

Here is the zip file of the above nuttest which contains the .x files and MDL files.

Dutcheeseblend · 31 Aug 2015

Thank you Anthony! I'll try a similar file soon, so be able to compare it to the way Blender does it.

Daan

capt_x · 1 Sep 2015

Hello,

Interesting topic to which I might add the little I have learned about shading with respect to exporting from 3DS Max or Blender to FS.

First, the .X file format stores the shading information in the form of a list of normal vectors, which are referenced by individual polygons giving the normal direction of the surface at the polygons corners (vertices). So, the .X format doesn't keep a record of smoothing groups.

Secondly, 3DS Max and Blender APIs provide direct access to normal vector data as needed by the .X file format, so whether you are seeing "smoothing groups" or "edge split modifier" in your interface, it's only a way of representing the normal vector data to the end user. Of course there are differences in data structure and handling between Max and Blender, but those intricacies don't affect the underlying principle. They do, however, have an effect on things such as file size and model efficiency.

This leads to the following remark: Blender's internal data structure is not as efficient as Max's when it comes to the amount of data that is handled by the engines. In Blender, you either have a flat shaded object or a smoothed object. A flat shaded cube in Blender will have 6 normal vectors as it will have in Max. Now, a smooth shaded cube with an edge split modifier looks the same as a flat shaded cube, but will have 24 normal vectors, repeating each vector 4 times at each corner of the cube's faces. That is four times the data for an object that is the same in appearance. This to say that there are efficiency issues when dealing with the export process from either Max or Blender to FS. In the Blender2FSX tool set, I have had to balance between export duration and optimized file size, i.e. having the export script reduce the amount of data (removing repeated normal vectors) comes at the cost of a lot of "search and compare" operations, often prolonging the export time by more than double. Until now, I ruled out the optimization option because it simply takes too long. This results in bloated .X files due to unnecessary repetition of normal vectors. In the current WIP version of the toolset, I have now added an "optimized file size" option in the export dialog, to reduce the size of the finished product. So, during development, you can still benefit from "faster" export/compile speed and once finished, you can make a definitive version of your product with reduced file size.

Even more important with respect to efficiency are "texture vertices" or "t-verts" in Max jargon. Blender's data structure is absolutely wasteful when it comes to t-verts. Remember, t-verts are points in a 2D-space, the plane representing the texture sheet. So each t-vert is a pair of numbers representing its X and Y location on the texture sheet. Each triangle has three t-verts in Blender and adjacent triangles don't share t-verts, the same t-vert is repeated as many times as there are triangles meeting at the corresponding vertex in the mesh. This leads to an unpredictable amount of data, depending on the topology of the mesh. So, imagine the center vertex of a 64-vertex cylinder's cap. Even if the cap is mapped as one island, that center vertex will generate 64 identical t-verts in Blender data structure. If this data is passed on to XToMDL without optimization, the resulting .MDL file is bound to be huge! 3DS Max is way more efficient with t-verts. When accessing t-verts through the Max API, you get an already optimized list.

Another Blender specificity about normal vectors comes from the "Edge split" modifier. As this modifier is applied on export, each sharp edge gives rise to double the amount of mesh vertices (actual vertices, not t-verts) and each side of the sharp edge gets the corresponding normal vectors assigned. This again leads to unnecessarily big .X files. So what I have learned from my Blender2FSX adventure is that Blender mesh data in its raw state can become an efficiency problem with large models. But then again, optimizing efficiency at runtime means reducing speed at compile time and requires recalculation and re-indexation of almost all the mesh data (vertices, normals and t-verts) only to achieve what the Max API delivers instantly.

I'm not bashing Blender in frustration here, it is a free tool and magnificent for that price. But it is not geared towards maximum gaming efficiency as Max is. You have to keep that in mind when creating game assets in Blender.

Happy Blending!

Dutcheeseblend · 1 Sep 2015

Thank you Felix, that clears up things a little! Comparing would be not very easy, I understand.

capt_x said:
Secondly, 3DS Max and Blender APIs provide direct access to normal vector data as needed by the .X file format, so whether you are seeing "smoothing groups" or "edge split modifier" in your interface, it's only a way of representing the normal vector data to the end user. Of course there are differences in data structure and handling between Max and Blender, but those intricacies don't affect the underlying principle. They do, however, have an effect on things such as file size and model efficiency.

So Smoothing Groups are the same thing as Edge Split modifier (or manual Edge Split operations, which I prefer to play safe)? I'm still getting a bit confused...*

capt_x said:
This leads to the following remark: Blender's internal data structure is not as efficient as Max's when it comes to the amount of data that is handled by the engines. In Blender, you either have a flat shaded object or a smoothed object. A flat shaded cube in Blender will have 6 normal vectors as it will have in Max. Now, a smooth shaded cube with an edge split modifier looks the same as a flat shaded cube, but will have 24 normal vectors, repeating each vector 4 times at each corner of the cube's faces. That is four times the data for an object that is the same in appearance. This to say that there are efficiency issues when dealing with the export process from either Max or Blender to FS. In the Blender2FSX tool set, I have had to balance between export duration and optimized file size, i.e. having the export script reduce the amount of data (removing repeated normal vectors) comes at the cost of a lot of "search and compare" operations, often prolonging the export time by more than double. Until now, I ruled out the optimization option because it simply takes too long. This results in bloated .X files due to unnecessary repetition of normal vectors. In the current WIP version of the toolset, I have now added an "optimized file size" option in the export dialog, to reduce the size of the finished product. So, during development, you can still benefit from "faster" export/compile speed and once finished, you can make a definitive version of your product with reduced file size.

That functionality will be wonderful!

capt_x said:
Even more important with respect to efficiency are "texture vertices" or "t-verts" in Max jargon. Blender's data structure is absolutely wasteful when it comes to t-verts. Remember, t-verts are points in a 2D-space, the plane representing the texture sheet. So each t-vert is a pair of numbers representing its X and Y location on the texture sheet. Each triangle has three t-verts in Blender and adjacent triangles don't share t-verts, the same t-vert is repeated as many times as there are triangles meeting at the corresponding vertex in the mesh. This leads to an unpredictable amount of data, depending on the topology of the mesh. So, imagine the center vertex of a 64-vertex cylinder's cap. Even if the cap is mapped as one island, that center vertex will generate 64 identical t-verts in Blender data structure. If this data is passed on to XToMDL without optimization, the resulting .MDL file is bound to be huge! 3DS Max is way more efficient with t-verts. When accessing t-verts through the Max API, you get an already optimized list.

You're implementing the "optimized file size" function for the t-verts as well? By the way, this t-vert "doubling" in Blender cannot be observed in the UV edit mode, AFAIK.

Thanks again for this excellent explanation!

Daan

* Please be patient with me! I'm only a kid when it comes to difficult things.

bob5568 · 1 Sep 2015

Capt X, thanks for your post. I learned quite a bit!

Bob

capt_x · 1 Sep 2015

Hi Daan,

Dutcheeseblend said:
So Smoothing Groups are the same thing as Edge Split modifier (or manual Edge Split operations, which I prefer to play safe)? I'm still getting a bit confused...*

Well, they are quite different approaches to the same thing: normal vectors. Normal vectors, which are a property of the surface (perpendicular to it at each point of the surface), have to be calculated in some way. This is achieved by having fixed vector values at predefined points of the surface and interpolating the normal vector values for points of the surface in between these predefined points. Usually, the predefined points are the vertices of the mesh. This is the notion of a vertex normal. For instance, a triangle will have three corner vertices, these in turn will have one normal vector each and the normal vector values for the triangle's interior surface points will be interpolated from the three outer/corner vectors. In Blender, there is also the notion of a face normal which appears in flat shaded objects. Here, there is no interpolation and hence, no need for a predefined point of the surface to hold a specific value of the normal vector. Every point of the face has the same normal vector. This approach is very cost-efficient when you deal with an entirely flat shaded object. Vertex normals are most efficient with an entirely smooth shaded object.

Problems arise when you have a sharp edge in an otherwise smooth shaded surface. A sharp edge means a sudden jump or shift of the normal vector at the border between two faces. Have a look at the top vertex in the figure:

For the edge to appear sharp, you need two normal vectors: one for the face on the left and one for the face on the right. In Blender, the edge is literally "split". Because in Blender each vertex carries only one normal, you have to split one vertex into two, to obtain two distinct normals. This is why edge split creates additional hidden vertices. These appear physically only once you apply the modifier but they exist internally as soon as an edge becomes "sharp".

3DS Max's approach is different. In Max, normals are calculated in the same way as in Blender but one vertex in Max can have more than one normal, hence there is no need to "split" the edge. But how do you tell how many normals a particular vertex holds? Well, this is where smoothing groups come in handy. A vertex has as many normals as it has unique smoothing groups (SGs) surrounding it. In the figure above, the left mesh face would be in SG 1 whereas the right one would be in SG 2. That way, Max knows that the top vertex holds two normals, one is calculated from the adjacent faces in SG1 and the other one is calculated from adjacent faces in SG2. The result is the same: the edge appears sharp.

Dutcheeseblend said:
You're implementing the "optimized file size" function for the t-verts as well? By the way, this t-vert "doubling" in Blender cannot be observed in the UV edit mode, AFAIK.

Well, you can see it if you disable the "Sticky selection mode"

in your UV-editor window. You can then move each individual t-vert in your UV-mapping. And yes, the plan is to achieve the same file size optimization for Blender2FSX as Max's exporter. Mind you, the speed of a script based exporter will never rival that of a native binary exporter like the ACES exporter in Max. On the contrary, having file size optimized will cost plenty of compile time, that is why it will be an option (merely used for the final export).

Cheers

krispy1001 · 1 Sep 2015

Thank you Mr. Felix!

hairyspin · 2 Sep 2015

Very interesting, Felix. So the differences between Max/Gmax and Blender for the end user are differences in method only and occasionally in compile times.

Dutcheeseblend · 2 Sep 2015

Great, thanks for the clear explanation! This gets me into some research!

Dutcheeseblend · 25 Feb 2016

Ok, after seeing Luca's post today, I think it would fit in this thread:

http://www.fsdeveloper.com/forum/threads/t-346a.431143/page-2#post-736531

Blender and smoothing groups

Attachments