What exactly is it? Can anybody explain to me for what reason surfaces have to be tesselated?
I'd be really interested in this as tesselation is what keeps me from using small texture scales (= more polygons). Other engines, such as q3 for example don't seem to have tesselation or anything similar as, when showing wireframe ingame, even the biggest walls with the smallest texture scales on them only consist of two polygons instead of hundreds. Any ideas?

Cheers

Tessellation is the tiling of textures (link is a dictionary definition). To explain, imagine that you have a block that has a physical space of 256x256x256, a nice, large-sized cube. You apply a 64x64 texture on it. The texture is repeated 16 times on the block per side (totalling 96 repeats). If you scaled the texture to half (0.5), the texture would be repeated 64 times on the block per side (384 total). This is because the texture takes half as much space on the same-sized object and it needs to be tiled more to get this. On the other hand, however, if you scaled the texture to double (2), the texture would be repeated 4 times on the block per side (24 total).

To get finely-scaled textures, use models. For a 0.25 scale, have the texture space coverage 4 times that of the physical size of the particular polygon(s) being mapped. That is, if you have a 256x256 polygon, have the texture space cover 1024x1024 pixels. For odd scales, like 0.375 (3/8), just take the physical size and divide by the scale size (this would give 682.66666... pixels of coverage).

Okay thanks for the reply. That settled, I'm still wondering why then surfaces seem to be split into several polygons on shaded surfaces (just set d3d_lines = 1 to see what I mean) by the compiling process. Why is this necessary? Textures can also tile without this feature, whatever, something ...
Can't they?

In the build dialog, look for "merge across leaves" or something like that (click the >>>). I don't know exactly why the compiler breaks large blocks into multiple blocks.

Quote:

---

Tessellation is the tiling of textures

---

Actually this is wrong. Tesselation refers to breaking a 3D surface into multiple polygons. Texture tiling has nothing to do with it (the compiler may actually tesselate along texture tile edges, but this is incedental).

In WED, when a surface is tesselated, this is done for several reasons.. first it is needed for breaking the blocks up into a form that can be processed by the BSP compiler.

Also, tesselation is needed for vertex lighting..dynamic lighting and such (unless you use shaders) can only be as good as the number of vertices you have.. tesselating a large block into many small polygons increases vertex count, giving you higher quality dynamic lighting.

There may also be a need for tesselation for lightmaping purposes, but i dont know exactly how this may work.

Tesselation can aso be done dynamically in D3D for breaking down higher-order surfaces (NURBS, etc..) into polygons. A6 doesnt suport these surfaces though...

The dynamic lights in older engines like Quake3, Quake2, A5 ,etc, are not done in the same way as in A6. A6 uses standard D3D hardware vertex lights. Older engines used a software method for making dynamic lights, which was basically fake, and also slower than A6 lights, and you couldnt have too many at once.

A lot of poeple complain about the current eight-lights-at-once limit, but in A5 you probably wouldnt want even that many lights, because of slowdown.

Also, Quake 3 uses a different kind of geometry than A5, A6, etc. In fact it does use a kind of higher-order surface, that is tesselated maybe even at runtime, I am not sure. But it is tesselated.

Thanks for your reply once again. I figured q3 must be using some kind of fake software solution for dynamic lights, since there is no limit at all but they don't look thaaat nice. Well, except for those seen in Call of Duty maybe, but there are worlds between the original q3 engine and CoD's

However -excuse me I'm still on it, but I really want to know - I'm still not satisfied as for the tesselation question. I don't want to start the obligatory "other engines are always faster than A6!" thread, but it seems as if q3 was definitely using some algorithm or whatever that is much more efficient, since, in q3-based games, level geometry renders incredibly fast. In A6, level geometry is about the slowest component I can imagine in the whole engine, for whatever reason. Q3 must be doing something quite a bit differently here. If you've still got any ideas left, please let me know

Yes Quake 3 is indeed doing something very different. It doesnt use the kind of geometry that A6 uses. It uses some kind of higher-order surface that is tesselated by the App. Other than that i dont know...

The World geometry in A6 is outdated, everyone knows this.. hopefully soon Octree Will be implimented and you can use any mesh you want. or you can just do what i do and use models and polygon collsion.

...which is what I do at the moment. Level geometry does have advantages for which, sometimes, I'd like to use it instead of models, though

Seems as if we had to wait for whatever update will be next. The only question left is, does anybody know whether level geometry is going to be improved with BSP as well or will only Octree be able to use upcoming improvements? Obviously, it is not BSP that is so slow about it currently, is it?