Lighting Problems

[hybrid]

Can someone provide an example level for such behavior? Please also note that slight differences occur due to the radius setting, which does not exist for OpenGL. So for strong lights, you get a very strong difference also beyond the light radius distance, because d3d won't add any light beyond this point, while OpenGL will fade already a little before, but continue with lighting calculations far beyond this distance. All the other screenshots that we produce in our regression suite are fairly similar across all drivers.

[greenya]

Testcase:

Code: Select all

#include <irrlicht.h>
#include <iostream>

using namespace irr;

#ifdef _MSC_VER
#pragma comment(lib, "Irrlicht.lib")
#endif

void main()
{
   video::E_DRIVER_TYPE driverType;

   printf("Please select the driver you want for this example:\n"\
      " (a) OpenGL 1.5\n (b) Direct3D 9.0c\n (c) Direct3D 8.1\n"\
      " (d) Burning's Software Renderer\n (e) Software Renderer\n"\
      " (f) NullDevice\n (otherKey) exit\n\n");

   char i;
   std::cin >> i;

   switch(i)
   {
      case 'a': driverType = video::EDT_OPENGL;   break;
      case 'b': driverType = video::EDT_DIRECT3D9;break;
      case 'c': driverType = video::EDT_DIRECT3D8;break;
      case 'd': driverType = video::EDT_BURNINGSVIDEO;break;
      case 'e': driverType = video::EDT_SOFTWARE; break;
      case 'f': driverType = video::EDT_NULL;     break;
      default: return;
   }

   IrrlichtDevice *device = createDevice(driverType, core::dimension2d<u32>(640, 480));

   video::IVideoDriver* driver = device->getVideoDriver();
   scene::ISceneManager* smgr = device->getSceneManager();

   for (int i = -8; i < 8; i++)
   {
      for (int j = -8; j < 8; j++)
      {
         scene::IMeshSceneNode* n = smgr->addSphereSceneNode(10.0f);
         n->setPosition(core::vector3df(i * 20.0f, j * 20.0f, 0));
      }
   }

   scene::ILightSceneNode* lightNode = smgr->addLightSceneNode();

   scene::ISceneNodeAnimator* lightAnimator = smgr->createFlyStraightAnimator(
      core::vector3df(), // startPoint
      core::vector3df(0, 0, -200.0f), // endPoint
      2000, // timeForWay
      true, // loop
      true); // pingpong

   lightNode->addAnimator(lightAnimator);
   lightAnimator->drop();

   smgr->addSphereSceneNode(2.0f, 10, lightNode)->setMaterialFlag(video::EMF_LIGHTING, false); // we add this to see the light source

   scene::ICameraSceneNode* camera = smgr->addCameraSceneNodeFPS();
   camera->setPosition(core::vector3df(-100, 0, -200));

   while(device->run())
   {
      driver->beginScene(true, true, video::SColor(255, 0, 0, 64)); // we make a bit blue background to see all black objects
      smgr->drawAll();
      driver->endScene();
   }

   device->drop();
}

Results:





P.S.: and the video for OpenGL and Direct3D9 only - http://www.youtube.com/watch?v=YxxpTZdWCik

[Kortalh]

I tried it in OpenGL, and it actually made things worse:


However, on a whim, I thought to use the example dwarf models, since they clearly worked fine when I went through the tutorial.

This is what I found:


As you can see, the dwarfs look exactly how they should, but my own models still look bad.

I don't know what that model's author did differently from me, or how I can change my own models to work right.

I'm using the latest version of Blender (2.57) and the .x exporter Add-On that comes with it.

Since these are just simple stationary models, I didn't add a skeleton. Could that be the problem?

[mongoose7]

Well, you are loading them as animated meshes. It would seem that a static mesh format would suit your purpose better.

[Kortalh]

Okay, so... I feel like an idiot. It's always a simple fix that I overlook.

After playing with settings a while, I did two things:
- Checked the "Export Armatures" box when exporting from Blender.
- Added the EMF_NORMALIZE_NORMALS flag to each of the models.

And now the result is this:


So everything's great, except for one problem... the shadows are way oversized for the models.

I've tried playing with Blender, I've turned on NORMALIZE_NORMALS, but it always comes out the same.

Here's another shot, but with normals debugging enabled:


Any ideas?

[mongoose7]

Is this a bug in the .x file loader? Look at the 12 normals in the bottom right. Presumably they relate to the character in the bottom right. But they are not attached to the vertices. Also, if one tries to imagine the "ghost" vertices, they seem to belong to a much larger model. Also, the shadows seem to relate to these ghost vertices.

You wouldn't like to try the exercise using, say, .obj meshes? And maybe using the static mesh loader.

The upward normals don't look normalised. But then, the previois normals all looked normalised but the scene looked better when you "normalised" the normals.

[hybrid]

The debug rendering is not affected by the normalize_normals setting. So the actual normals will get normalized, but the drawn lines are not.

[mongoose7]

Of course! It is a mode, not an action.