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 Deus Ex High Definition Texture Package 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]

Are smoothing groups a specification of a file format and need to be supported by the engine?

Yes. You could just split each group's vertexes from the others manually, but implementing this into a file format's specification allows for better performance, since there will be no need for splitting vertexes like that and therefore there will be less vertexes for the renderer to transform.

[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]

Okay, I've seen I should be able to export and run trough Noesis to .iqe/.iqm which listed edge-flag smoothing and smoothing groups as features.
If that fails I might just split the mesh and see if works. I'm not really targeting any specific engine at the moment, but RMQ, DP and Cube2 are likely candidates and they all support .imq.

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

Yeah, I figured as much. GPUs are fast enough for several 10000 poly animated characters onscreen these days.
So I'm assuming a few thousand polys worth of split models shouldn't be a problem.
And the advantage of pre-splitting the mesh would be that it should pretty much work universally.
I'll have to see what gives me the most convenience in the creation process, offset perhaps by engine requirements.

[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]

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.

Yes, which is why engine support for smoothing groups would be nice. I once thought of creating a whole file format containing all the possible optimizations that a software renderer could use (smoothing groups, per-triangle blending settings, UV mapping like in Hexen II onwards, bones and joints for skeletal animation, and a load of other stuff) but that most likely won't happen anymore.

[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]

The difference becomes more apparent, if you, like, used......... realtime lighting.

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!

Split from MDL uv island seams?

Hexen II's models in general are fubar. It's what one of my motivations were....

[goldenboy]

The difference becomes more apparent, if you, like, used......... realtime lighting.

Not going to, my maps are already taxing enough with static lightmaps. My gameplay is a lot more platformey than Doom 3 is, so I'll gladly take extra FPS over realtime shadows.

I also just want to see how good an idtech-based game can look with static lightmaps. I mean Sock's maps look great with just q3bsp. I think I should be able to get visual fidelity similar to the Portal games.

[taniwha]

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