Textures mess up when viewed from distance

[saadjumani]

Hi, im trying to make a simple scene loading program in C++. It model loads fine and textures are applied as they are expected to, but they kinda mess up when viewed in distance (those diagonal black lines you see in second pic). On a separate note, can someone tell me why some sides/faces are unusually darker while others are just fine? is it due to light direction? if so, how do I adjust that? im using following code to light up the scene:

Code: Select all

    smgr->addLightSceneNode(0, core::vector3df(-750, 150, 750),video::SColorf(1.0f, 1.0f, 1.0f),2000.0f);
 

[CuteAlien]

Try experimenting with the texture filter options in the materials (in SMaterial.TextureLayer). You get the best results when you enable AnisotropicFilter (is off by default) and BilinearFilter (is already on by default).

Getting good light settings ... is always hard. First the default materials calculate their light at the vertices. So if you have large polygons things will get a little more tricky as the light from one corner to the other can have huge differences. Some stuff you can try to work around it:
- Use ambient light (you can set that in the scenemanager). With only dynamic light you will always get those extremely dark corners, so some ambient light can help to prevent that. You can also think of it as light setting the "mood" of a scene (so experiment with colors, for example those 2 pictures use the same road-textures just with different ambient lights: http://www.irrgheist.com/media/screensh ... raft01.jpg http://www.irrgheist.com/media/screensh ... ft_f06.jpg).
- Don't use point-light but directional light to simulate the sun. addLightSceneNode returns a ILightSceneNode which has setLightType which you can set to irr::video::ELT_DIRECTIONAL
- The best (but somewhat slow) results can often be reached by having several lights from different directions.

For even better result you will need pixel-shaders to calculate the light per pixel instead of per vertex.

[Mel]

Your image looks more like a Z-fighting issue. As if the walls were exported twice, front and backfacing. Check that you "can't see" a wall from the inside

Also, for the lighting, the best approach is to have indeed an ambient and a directional light, but also that the material normalize the normals of the rendered objects.

[CuteAlien]

Yeah, I kinda looked at the wrong place. Mel is right - this looks like Z-fighting. Additional to the mentioned model problems (having 2 polygons in the same place) you might also have accidentally put 2 sceneobjects at the same position.

[saadjumani]

Thank you both for your input. After looking at the obj file of 3D model I see Mel kinda came close, but the issue was not z-fighting (assuming that z-fighting means 2 faces overlapping, hearing this term for the first time actually :p ). It seems my obj files did not have normals defined properly.

The temporary workaround was to scale down the whole level and add ambient light. It made it negligible. The proper solution would be to obviously fix the model's source file but im too lazy to do that right now :p

[CuteAlien]

Yeah, z-fighting mostly caused by 2 faces overlapping. Graphic-cards do write a depth-value (distance to camera) in the z-buffer (bitmap with size of rendertarget) at each pixel when it draws a polygon. And only when a polyon is less deep than the value already in the z-buffer then it's really rendered (that can be changed, just talking about default handling). That's the way of the cards to figure out what is in the front.

Problem is when 2 polygons have the exact same depth-value.. then the result can become kinda random. And because a depth-buffer has only a limited resolution (p.e. 16-bit) that even happens when polygons are just very close together even if one of them should be in front. The larger the difference between the front and back clipping planes of the camera are the worse this gets (because distance larger => each value in the depth-buffer has to cover more units).