Home Unreal Engine

Bad Normals, WTF?

Why is UDK doing this? :poly127:

spheres.jpg
http://s20.postimage.org/5qvbm6yel/spheres.jpg

OK, in this first image, you have two identical spheres exported from Blender. The one on the left was exported without a UV map, and the one on the right was exported with one. Why is not having UVs causing the lighting/normals to get all screwed up like this? There is only a dynamic light in this scene, so it's not like its caused by lightmass or something.

spheres2.jpg
http://s20.postimage.org/wpz6hckvh/spheres2.jpg

Here is a better look at the sphere with UVs. While it looks better, you can still notice lines in the specular highlight which sort of resemble gouraud shading. :thumbdown:

This really sucks. Somebody tell me there is a way to fix this.

Replies

  • Jacky
    Options
    Offline / Send Message
    Jacky polycounter lvl 6
    Yeah, that happens when you import an object with no UV's. Just apply a quick sphere or cube UV map even if you aren't going to use texture or use it as a static mesh.
  • lpcstr
    Options
    Offline / Send Message
    Jacky wrote: »
    Yeah, that happens when you import an object with no UV's. Just apply a quick sphere or cube UV map even if you aren't going to use texture or use it as a static mesh.

    But it makes no sense. Why should UVs have any effect on lighting calculations? Plus that doesn't address why the lighting STILL has issues even after a UV has been added.
  • AlecMoody
    Options
    Offline / Send Message
    AlecMoody ngon master
    I don't know if blender can do this but use an XYZ to UVW coordinate set. No splits/seams.
  • lpcstr
    Options
    Offline / Send Message
    AlecMoody wrote: »
    I don't know if blender can do this but use an XYZ to UVW coordinate set. No splits/seams.

    Why?

    Like I said. Why is this happening. It does not make sense.
  • JamesWild
    Options
    Offline / Send Message
    JamesWild polycounter lvl 8
    For normal mapping, you need three lighting normals. One is generated from the face itself, while the other two are perpendiculars pointing along the U and V axes of the unwrap.

    If there's no unwrap data, there's some kind of mathematical breakdown in the importer. The tangents point all over the place (presumably just how floating point inaccuracies bias the generation) and then it tries to make sure these tangents and the normal are perpendicular... In an ideal world, the algorithm would make the tangents conform to the normal and leave the normal alone, but UE3's importers don't seem to do this.
  • Ace-Angel
    Options
    Offline / Send Message
    Ace-Angel polycounter lvl 12
    It's an importer and optimization thing as James mentioned, since UDK also applies it's own 'material ID' to a mesh when imported to keep thing organized.

    Most engines also do this, but they don't show it you, since they're all dirty liars :P
Sign In or Register to comment.