Lighting tiled 3d terrains

I'm having a lot of issues with tiled 3d terrains.

Simple case:

I used textured cubes to represented wall areas, and a global light pointing down at 45,45,0. Seams were visible between the cubes. These seams disappear if I point the light straight down -- 90, 0, 0 -- but then everything looks pretty flat.

The situation got considerable worse when I used a tiled floor (eventually infinite planes don't cut it) and had my character carry a point light source.

Sorry I can't post images since I've fixed these things using pretty major hacks (there are now struts covering the seams in the walls, and I'm creating the floor on the fly as a mesh surface.

Now I'm finding that point light sources work very poorly in general and wondering if I should give up on using lights for illumination completely and just use vertex lighting and/or "burn" lighting into my textures for every tile (which seems excessive not to mention costly in textures).



Any suggestions?

Baking the lighting into your textures is really inefficient because then you can't tile your textures. Use lightmaps; tile the main textures, then use a second set of UV coordinates with non-overlapping texture coordinates for lightmap textures. The lightmap textures are greyscale textures which are applied as a multiply blended layer over the main textures. In this way your main textures are still tiled (saving lots of texture memory) but your lightmaps are not tiled (because the lighting information for each polygon must be unique.) Assuming you use small lightmaps (shadows tend to be rather blurry anyway) multitexturing in this way saves a lot of memory. You can generate lightmaps easily using apps like Lightbulb.

As for the problem with cracks, don't use cubes for your walls. Instead model your walls as a seamless mesh. Your reference to an infinite plane for the floor makes it sound like you are trying to construct the level in code. Don't. Model it just as you would model a character and load the model to use for your level.

Incidentally, what does any of this have to do with terrain? The screenshot depicts an indoor scene.

*********

Nice texture on that character. I'm pretty good at painting textures but loose folds in cloth are my downfall.

My system will eventually generate both indoor and outdoor terrain using tiles (I'm not talking about Blitz3D terrain objects; sorry if I caused any confusion) -- note the strange lighting artifacts on the archway in front of the character and along the bases of the walls.

[box]Baking the lighting into your textures is really inefficient because then you can't tile your textures[/box]

Well it would be tricky in other respects too. I wouldn't mind low texture re-use if the terrain tiles themselves still tiled, but even that would be tricky.

[box] Your reference to an infinite plane for the floor makes it sound like you are trying to construct the level in code[/box]

Given that I'm trying to construct content on-the-fly (from pre-made components), I don't have much of a choice. I don't *want* to construct levels by hand in advance; there are plenty of "hand made tunnel of fun" games on the market, and competing with them is, in my opinion, a waste of time.

One other option would be building a bunch of relatively small BSP-style maps and tiling them -- kind of a compromise between completely hand-made levels and completely dynamic levels.

I am also considering doing vertex lighting in code.

Oh sadly the character model model isn't my work -- it's licensed from Geo-Metricks.

Tonio

I might be completely wrong here but for lighting on 3d objects to appear correctly mustn't you make sure that each face has it's own set of normals?
That is, faces can't share any vertices.

If you model your cube with only 8 vertices, 5 of the faces will share the same normal and isn't lighting based on normal direction.
Often the normal projection of such cubes will point from the center out through the corner.(Not actually from the center, but in that plane)

So a cube should have 36 vertices for correct lighting.
Well,not neccesarily 36 as some vertices could be shared when two faces resides on the same plane.
(For a cube 2 faces always reside on the same plane) that will give 24 vertices instead.

Try model your objects like that and see what results you get.

As i said, I may be wrong, but it makes sense to me.(though I could be totally insane)

[Edit]
If you have DirectX SDK installed you can use the meshviewer utility to check lighting on objects. It's also a great tool to view normals and recompute them.
In this tool you could also create a cube with 24 vertices and compare it to a cube with 8 vertices.

A flash back from 2 YEARS AGO!!!! OMG