smoothing groups, gouraud and mesh-splitting

[Spiney]

I'm asking this here because I wouldn't know where else, and because there's more implementation know-how here than on most artist forums.

Some reference up front:
http://stocktextures.com/archive/articl ... index.html
http://learngamedesign.com/gdt_A2.html

Before per pixel lighting and normal maps were popular; games would use a combination of gouraud shading and "smoothing groups" (3Ds Max terminology) to vary between sharp and smooth edges. In Max this is done by applying an edge threshold to groups of polygons, which as I understand effectively splits the mesh at certain locations. This in combination with gouraud will give the ability to do a mix of sharp and smooth shaded faces. Because afaik a vertex can only store a single normal, as such the mesh needs to be split and vertices need to be duplicated in order to get certain edges to break out of the gouraud interpolation.

I know that the first Unreal engine (up to 1.5) for instance did not support them, and modders for had trouble with that and the lighting bleeding around edges, which is an inherent graphical 'weakness' of the original Unreal engine games -- it probably couldn't afford it at the time. I guess this is simply less pronounced in Quake because the lighting tends to be more diffuse in those games, as opposed to a 'noir' looking game like Deus Ex.

But this would mean that smoothing groups are some kind of meta-feature that needs to be supported by the engine, and the 3D package would not spit out 'pre-split' meshes that should work universally. So my question is: is this true, and what does that imply for content creation? Are smoothing groups a specification of a file format and need to be supported by the engine? This is bothering me because a lot of modelling apps do not have a smoothing groups implementation, most have some kind of way to mark edges as 'creased' though.
Also, what other side effects are there to the mesh-splitting process? I know advice for UV maps is to avoid segmentation where possible, because this causes the graphics API to split the triangle lists into parts, decreasing efficiency. Would that then also imply that it's best to have the UVs conform to the smoothing groups for best performance?

Anyway, regarding where I'm coming from. I've recently started learning to use Cinema4D after a bit of experimenting with 3D apps, eventually settling on it because the the workflow was very close to stuff I've been using on-off in the past. I really dabble in 3D modelling for the most part, starting with Maya, then some Wings and Silo3D -- C4D is fairly close to Maya and Silo in general usage. I know there's probably a bunch of you that are experts at using Blender and knowing how to get this stuff done. I did try Blender a couple of times over the last years, but frankly it's just so unorthodox compared to other 3D packages that it just makes me want to pull my hair out when trying to get stuff out of it. Great piece of work though, it's just that I don't have the patience to unlearn all my old habits which I put in so much effort to learn in the first place. I'm pretty good at 2D and as such that's my comfort zone, 3D is still a bit scary to me

Thanks for reading!

[ceriux]

Well, i dont know how much help i can be. but iv never personally used smoothing groups. i think its mainly for rendering. (i may be wrong) but both programs iv used to model (starting milkshape, and now 3ds max) has the use of smoothing groups. but once again, iv never used them and haven't had any problems not using them.

[mankrip]

[leileilol]

I don't think game engines have to entitle support for native smoothing groups

split edges are enough, and the performance difference between a manually split edge and a smoothing group is barely negligible

[Spiney]

[Spiney]

I haven't tried Noesis yet, but I did try to split a mesh by hand. It might be kind of a worst case scenario for this -- a broken pillar with pieces of shrapnel.
It's a total pain in the ass though, making corrections becomes a pain, not to mention it completely screws over the uv mapping procedure.
I can imagine it taking at least twice as long to finish an average mesh this way. So that's +1 for smoothing groups at the moment.

[mankrip]

[Ace12GA]

I have been creating content for games for a very long time now (15+ years), and I can say without any doubt that splitting a mesh up to fake smoothing groups is a bad work around for engines that perform full mesh phong or gouraud shading all the time. Quake and quake 2 perform full per face flat shading, as did unreal, but moving forward to half life, unreal tournament and beyond, all the commercial engines support smoothing groups. All the decent 3d modeller suites have smoothing groups. Smoothing groups are the way to go, and allow you to get so much more detail out of a mesh. Of course now we also have normal mapping, and other neat tricks, but you still need smoothing groups. Don't think smoothing groups are only for rendering, they most certainly are not.

Yes, the engine and the format must support them. Darkpkaces does, as does the iqm and darkplaces model formats. Use smoothing groups. Splitting up a mesh instead is a bad way to do this.

[goldenboy]

It seems to depend on the engine. Katsbits tutorials suggest splitting the mesh for idtech3 and idtech4 engines to create smoothing groups. Kat also says that different modeling applications have different implementations of smoothing groups.

Anyway, here's a question -- I have a basic understanding of what smoothing groups do on eg a cylinder. I'm not sure how smoothing groups should be used on for example stairs. I have this static mesh:



I'm not sure if I even need to create smoothing groups on this. Any help?

[Spike]

Either you have one vertex on the edge, or you have 2 or 3. If *any* attribute of the vertex is different, you need a separate vertex.
More modern formats are directly specified, with each vertex being explicit (like iqm). Older formats for software renderers (like q1) require lots of preprocessing, including duplicating each vertex for front/back parts of the model, but Q1 is at least explicit in its normals. The preprocessing required might result in some engine programmer trying to merge everything they can though.
Really though, if the engine is a little lazy and doesn't willfully destroy edges by aggressively merging everything then there's no issue with split edges, and its purely a modelling program issue.
The engine has no concept of smoothing groups, only edges that are defined with one vertex (per point) or 3.
Splitting up a mesh guarentees that nothing can merge the verticies, but its not pretty. If you've got proper support in your editor, use that instead.

Sadly hexen2's various hand models contain split edges, and I'm very very tempted to merge those verticies engine-side to stop them looking so uugly!

Note that bumpmaps can be used to distort vertex/surface normals and can be an alternative to split edges. Does need full bumpmapping, however.

[goldenboy]

An experiment answered the question.

Not splitting the mesh:



Splitting the mesh at every hard edge (and there are a lot of hard edges in this model):



It turns out that when not splitting, the entire mesh is smoothed as if it was a rounded surface. To get hard edges properly shaded, splitting the mesh seems to be required.

Note that this is an *.ase model baked into the BSP by q3map2 (FBSP). Not sure if the same would hold true if I loaded the mesh via an entity in a vanilla Quake 1 map, ie if the engine would do this anyway.

Katsbits has a tutorial here:

http://www.katsbits.com/tutorials/idtec ... models.php

[Spike]

those are lightmap lit when inserted as a polysoup surface within a bsp
if you'd inserted it as an md3 or whatever, you'd get a similar differences (split edges vs merged edges), just with the engine doing it instead

[leileilol]

[goldenboy]

[taniwha]

Don't knock realtime shadows in a (quite a good game, actually).