# Lightmap problems with curved geometry

This topic is 4491 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi... I have a little problem with my lightmaps. Here is a screenshot. As you can see, there are some patches that are behind level geometry, which results in invalid calculations. Because i take into account only front facing triangles for the calculations, when the ray first hits a backfacing triangle, there is a problem. What can i do about that? I'm using the hemicube method in case to calculate the patch's value. But i don't think this has something to do with the problem. It would be there even if i did raytracing. The problem is that i don't know if i must calculate a patch's value, or i must take it from its neighbors. Sorry for my bad english but i'm a little confused about the problem, and i can't explain it very well. I hope the screenshot tells more than i did. Does anybody had a similar problem? Is there any way to fix this? If you need more info please ask. I'll try to explain the problem better. Thanks in advance. HellRaiZer

##### Share on other sites
If it is illegal pixels you are referring to (so it seems from the screenshot), then duplicating the nearest neighbor will most probably provide a solution. The "Lightmapping - Theory and Implementation" article on flipCode says:

Quote:
 There's another problem if we use bi-linear filtering. It's the "bleeding" problem.When bi-linear filtering is turned on in your game, then, whenever a pixel is chosen, the final color will not be the color from the pixel alone, but, the average of the pixels around it. (average of how many pixels - depends on the kind of filtering used.)As you know, some of the pixels in our texture map will be illegal. It means, that particular pixel belongs to no polygon.Usually, the color of any illegal pixel will be zero, since no color calculation is being done for that pixel.So, while rendering, whenever a pixel is chosen, the average of the color around that pixel will be considered. In this process, even the "illegal" pixels may be chosen. This is why "bleeding" happens.If we're using bi-linear or tri-linear filtering (which I bet we would be) in ourgame, then, we somehow got to get rid of the illegal pixels.Actually, we can't get rid of them. What we can do is fill every illegal pixel with a color from the closest "legal pixel". This way, during filtering, it is assured that the closest and most appropriate color is chosen.

##### Share on other sites
If I follow you correctly, the problem is with visibility determination of patches that are partially obscured by other geometry?

If that is the case, I am not aware of a well-known fix for this so my reply comes off the top of my head [smile]

You could calculate which patches won't fit entirely inside their corresponding polygon (simple 2d rectangle-vs-polygon check) and then for the relative visibility of the form factor equation you could use that of the nearest neighbouring patch that isn't partially occluded (ie fits fully inside corresponding polygon)

This probably wouldn't be all that expensive in terms of computation but i'm not sure how effective it would be ...so hopefully somebody else will chime in with a better approach [wink]

All the best,
ViLiO

##### Share on other sites
Thanks for the replies.

Unfortunatelly these aren't illegal pixels as the article describes. The problematic patches in the screenshot are completely inside their corresponding polygon. I'm already doing the nearest neighbor "bleeding" in case to avoid filterting artifacts, using the DilateImage() function from ATI's normalmapper source code. Thanks anyway for the article quote.

ViLiO:
Quote:
 If I follow you correctly, the problem is with visibility determination of patches that are partially obscured by other geometry?

Yes this is exactly the problem. Thank you for explaining it better than me :)

Quote:
 You could calculate which patches won't fit entirely inside their corresponding polygon (simple 2d rectangle-vs-polygon check) and then for the relative visibility of the form factor equation you could use that of the nearest neighbouring patch that isn't partially occluded (ie fits fully inside corresponding polygon)

As i said the problematic patches fit exactly inside their corresponding polygon. The extra polygons on the ceiling, which occlude the patches, aren't part of the problematic geometry.

Btw, this is a Doom3 level, which i used in case to test how my lightmap generator will perform on a real game level.

Thanks for your time. Any other suggestion/thought/comment is welcome.

HellRaiZer

##### Share on other sites
Hmm this is quite a puzzler [oh]

I am working with Doom 3 maps as well and had planned to do some radiosity lightmapping on them in the very near future. I'd partially hoped that when compiling the map, radiant would clip brushes against curves ...but that was wishful thinking on my part [wink]

I'll think more on this but in the mean time, for anyone else who passes by and may have greater knowledge of how maybe radiant handled such things in Q3A, here is a picture showing exactly what causes the problem ...I think [smile]

All the best,
ViLiO

##### Share on other sites
For the q3 engines the people from id stated to not overlap curved surfaces with other geometry.

The only option I see to correct this is calculate really high res lightmaps for curved geometry or to rework the geometry to not intersect other geometry

1. 1
2. 2
3. 3
Rutin
18
4. 4
JoeJ
14
5. 5

• 14
• 10
• 23
• 9
• 33
• ### Forum Statistics

• Total Topics
632631
• Total Posts
3007538
• ### Who's Online (See full list)

There are no registered users currently online

×