What's wrong with N-Gons???

Hi, I read this article on Blendernation.com: http://www.blendernation.com/2007/10/03/another-blender-comparison/

In it the author is comparing many 3d products, blender being one of them, and he comments a number of times in the article about how N-Gons should be avoided, or he says that blender made a good choice by not allowing N-Gons…

I thought an N-Gon was just a polygon with more than 4 sides… is there something I’m missing???

Quads are best because when you etc apply subsurf quads get smoothed alot better than ngons or tris.
by not allowing ngons you are almost sure to get a mesh wtih only a few quads witch is a good thing.

But if you’re not going to use subsurf then ngons aren’t bad for workflow and speed.

IANAREC [I am not a render engine coder], but what I’ve understood from reading rendering techniques and poligons, renderers convert everything to tris. Even your Blender quads. So, while quad is relatively simple conversion, it’s OK. But imagine a pentagon shape. There are A LOT of ways to convert it to tris. And some of those conversions are doomed to fail your subsurf… or well… how is the renderer to know… maybe you want it to look “non-standard”. It can’t know, there’s not enough data.

Despite of this problem, I think there are number of situations [especially for non-organic models] where n-gons make totally sense.

In any case, I believe that the BMesh code that Briggs is working on will enable Ngons in Blender in the relatively near future. I could be mistaken, but that’s my understanding.

n-gons are very nice to have in the modeling process (including organic models), not to render with (with exceptions).

Imagine having a connect-tool without n-gons, for example… hell on earth.

There seems to be quite a lot of misunderstanding about this issue so I will try to clear some of it up…

Your getting two things confused here, tesselation and subdivision. Tesselation refers to creating a series of triangles from an arbitrary polygon. This can indeed produce ‘strange’ artifacts and some tesselators are better at this problem than others. Generally speaking though, the less planar an n-gon is, the more likely the tesselation will be problematic.

Subdivision is another story. Blender uses Catmull clark subdivision works with n-gons directly and does not rely on tesselation before hand. There are plenty of cases where n-gons (and even triangles) produce perfectly ok meshes after one iteration of CC subdivision.

This is something that gets said a lot, but that doesnt nessecarilly make it true.

Check out these two pictures for examples:

The first image is a simple model I hacked togather in silo to illustrate this very point a while back. Notice that the triangles and n-gons on the subdivision cage create desirable all quad loop patterns on the derived mesh. Theres even six sided polygons on the cage that hold up well under subdivision. Once you understand what sort of loop patterns subdivide certain ways you will be able to save a lot of work by starting with a light cage and then applying your subdivision rather than placing all those loops by hand!

The second image shows an example of how an all quad model can subdivide not so smoothly. (it is all quads, look closely.) You will notice that the incidence of edges on the models vertices plays a very large role in this…

To answer the original posters question:

There is nothing wrong at all with n-gons and there are many problem domains in which they are a lot more appropriate to use than triangles or quads.


wow, that first image looks perfect, the ngons subdivided make perfect loops. yay for Ngons!!!

Bring the NGON and polywire options to the Blender.

It wont hurt you

maybe I expressed myself wrong, but if you look at the the n-gon pic above, maybe you can see that the subsurf always takes a fan shape. I maybe should have stressed that it’s a combination of subdiv algorythm and n-gons problem. If i don’t want a given n-gon to have a fan shaped subdiv, I can’t do anything… or just remodel.

I await seeing Briggs himself finally bring his Bmesh project into an official version of Blender.

Ngons are also good for architectual modeling, if you need a building with an assortment of windows, the whole wall can be just one polygon.

N-gons is in my opinion an essential part of the modeling progress.

allot of people (including myself) use different methods of modeling while working on the same model, being able to create N-gons is something i did ALLOT in 3dsmax.
i made several N-gons and later in the modeling progress i would rework sertain parts of the model, like working out N-gons.
the lack of N-gons is a big reason why i still havent switched to working in Blender fulltime.

hope to see it in 2.50 !

I dont see how this really is relevant. What your referring to are ‘poles’ or vertices that have more (or less) than 4 edges incident upon them. The only way to model a mesh with no poles and all quads is if its topologically equivalent to a torus. The poles on your cage will create poles on your derived mesh, even in an all quad model.


It should be noted that Bmesh does not support holes in faces currently, and probably wont for the forseeable future.


even if you can do that, it is a bad thing to-do…

Why is that? I dont see the problem as long as the tesselator can handle it and the mesh structure and operators are built to handle holes all right.


Because the artist doesn’t know what the tesselator will deliver and can cause shading issues when rendering.

The tesselator should deliver the same thing it shows in the interactive view. this includes the normals.

If the polygon is flat and the tesselator shows ok in the 3d view there is really zero danger of it causing rendering artifacts later on.


True, but one doesn’t know what happens when he/she exports to another program or uses another renderer with a mesh that contains n-gons.

no no no no NO.
You misunderstood again.
Yes, I’m talking of poles, but I’m talking about the location AND number of poles. ngon in your pic has one centered pole. And I’m saying “what if that’s not what I want”, maybe, for me, it makes more sense to have two poles: left and right, or any other number tweeks, not to mention inherent lack of deciding how to subdiv a given face. maybe I want one face loop subdivided differently in say horisontal… anyway