Perspective Camera functions incorrectly.

[VioletAlixe]

After a good long look at the options with the various cameras, I've concluded that the Perspective Camera does not work. Now, before you jump on me telling me that you can see it working, let me show you what I mean.

It is common knowledge that perspective differs from othro cameras because perspective cameras take into account that things that get further away become relatively smaller in appearance.

I know what you're thinking. "Hey. I'm running a perspective camera, and things I look at in front of me are getting smaller when they get further away."

Unfortunately, that's the problem. The perspective camera in Irrlicht takes into consideration only what's far away from the perpendicular horizontal line to the Z axis.

You may be thinking, "Okay, well, what else should it be taking into account? The Z axis is depth."

Well, think for a moment about it. Things don't only get smaller as they get further away you in the direction you're facing. They get smaller as they get further away from you in all directions. If something is farther away to your left than an object right in front of you, but they both have the same size, then something's definitely wrong right? But they're on the same axis as your X, and no further away in your Z!

If this is confusing, I made a quick picture to show you what I mean.

http://img490.imageshack.us/my.php?imag ... ivenx1.png

Things that get further away are not only not smaller, but they're also stretched out of proportion! What's up with that?!

This has been brought up before, but never addressed formally.




Note: For those interested in altering through given functions for fixing the problem, there are none, this is what the actual functions do:

setFOV() Increases how much can fit in the camera field, normally this might fix this is the other axises were taken into account, but since they don't, it has an affect that doesn't alter how small things are as they go left or right, only fits more on screen.

Aspect ratio does something similar as you go higher, but doesn't have any effect on how small things get as they move away in a direction other than the one you're facing.

Matrices can't alter this without altering each pixel through a function of where it has been transformed to on your 2D screen.

[Cardinal4]

I'll just use art instead of logic to show that yes, that is perspective view.

That straight line to the left is correct. Stuff will only curve upwards if its a fish-eye view.


As for the ellipsoid getting bigger when its x position increases, check the below picture:

The cuboids grow in size because you see more of it from a slightly sideways view.

It actually depends on what do you consider as perspective view, i suppose. But Irrlicht cameras definitely are perspective. It's harder to make it orthogonal.

[VioletAlixe]

For one, art mimics life. Both of those pictures are ONE-POINT perspective. Which is a point, not a horizon. The problem is also that spheres are not cubes, they're spheres, and are more or less spherical regardless of where they are on an axis.

check this out:

http://www.tawbaware.com/Sigma_Tokina_U ... v_comp.jpg

You're saying it's "Fish-eye" but fish-eye is just wider FOV than our eyes. It's still correct perspective type though for three dimensions.

ALSO, notice that your "art" picture has a small FOV, extremely thin.

If we look at a normal photograph, we can see that same effect with a very thinned out FOV, but when we see the whole picture, we notice that the curve is in fact there.


http://img392.imageshack.us/img392/3629/fovob5.png

[vitek]

I'm fairly certain that you are wrong. The default FOV used by the irrlicht cameras is no good and it causes distortion of objects that are near the edges of the view. A default is 72 degrees, but a more reasonable value is about 60 degrees.

It would be difficult for Irrlicht to be doing these calculations wrong. All Irrlicht does is pass the world, view and projection matrices to the driver. The driver [D3D, OGL, or SOFT] will use the matrices and the vertex data to determine the position of each pixel on the screen.

I'll create a testcase tomorrow that might convince you.

[VioletAlixe]

I'll reiterate. The FOV isn't wrong, the camera set up for a perspective matrix is wrong. The FOV would still function perfectly if the other planes were taken into account. Presently the FOV doesn't have the effect a field of vision extension should have because of the camera type alone.

Example: If you have a field of view of 180 degrees, you should be able to see ninety degrees counterclockwise and clockwise from zero around the Y axis.

Take a look at the "FishEye" Quake which runs at 90+ FOV. (READ FISHEYE IS JUST AN EXPANDED FOV) If you were to set the FOV to the 60-75 degree range, you would actually only notice extremely minor changes in the image displayed. The only difference would be that, again, things further away from you would be slightly smaller than those closer to you.

I've had this "bug" (not really a bug, just a weird way of faking perspective) checked by people like CuteAlien who acknowledge that the origin should not be a plane but a point. The main issue would be whether or not people would want the new camera after ahving worked with the old one, and I have this to say to that: You can easily swap back to the old camera by adjusting the FOV on the new camera. The problem is that presently, you cannot do so with the old camera to get a proper new camera.

[CuteAlien]

I've had this "bug" (not really a bug, just a weird way of faking perspective) checked by people like CuteAlien who acknowledge that the origin should not be a plane but a point.

That's not exactly what I said. I said something along the line that I _get_ what you are talking about, but that I might not be the best person to discuss this, as I'm rather insecure because I'm not an expert if it comes to perspective drawing.

Still without knowing too much about that, I actually think that VioletAlixe might be right here. Maybe the current functions do not care about the distance to objects, but only about the depth along the z-Axis.

[VioletAlixe]

I've had this "bug" (not really a bug, just a weird way of faking perspective) checked by people like CuteAlien who acknowledge that the origin should not be a plane but a point.

That's not exactly what I said. I said something along the line that I _get_ what you are talking about, but that I might not be the best person to discuss this, as I'm rather insecure because I'm not an expert if it comes to perspective drawing.

Still without knowing too much about that, I actually think that VioletAlixe might be right here. Maybe the current functions do not care about the distance to objects, but only about the depth along the z-Axis.

Thank you CA, and sorry for any misquotings.

[vitek]

I'm sorry, but I'm unable to understand what you are actually saying. That is either because I can't understand your jumping around, or you are just wrong.

I believe that you are trying to say that in Irrlicht objects at a distance appear smaller when they are directly in front of the camera than they do if they are off to the side.. i.e. a sphere of radius 1 at 10 units in front of the camera appears smaller than a sphere of the same size that is 10 units to the side. If that is what you're saying, I'm pretty sure you're talking about perspective distortion. As the field of view is expanded, the distortion becomes more noticeable.

If we look at a normal photograph, we can see that same effect with a very thinned out FOV, but when we see the whole picture, we notice that the curve is in fact there. http://img392.imageshack.us/img392/3629/fovob5.png

In the image, the blue outlined rectangle has a small fov [say 30 degrees] and everything is fine and straight lines are straight. If you look at the entire photograph, it has a large fov [say 80 degrees]. The objects near the edges are distorted and seem curved [notice the chairs near the edges seem to curve forward and that the top of the curtain seems to curve downward]. That is perspective distortion. You should click the link and read the section Distortion caused by projection and have a look at Figures 4-6.

The FOV isn't wrong, the camera set up for a perspective matrix is wrong.

If you're sure, can you point us to a perspective matrix calculation that is correct? They sure look right to me... msdn and sourceforge.

that the origin should not be a plane but a point

I have no idea what you're talking about. The 'origin' of what? The view frustum? That still doesn't make any sense. The camera is oriented at a point.

If it is a broken projection matrix, you should be able to easily write a testcase that illustrates and fixes the problem. The camera interface exposes methods for setting the projection matrix directly, so you can stuff whatever values you want in there. Since I am having such a problem understanding what you are saying with words, a testcase is much better.

Travis

[vitek]

Source code for fov test example...

Code: Select all

#include <irrlicht.h>
#pragma comment(lib, "Irrlicht.lib")

using namespace irr;

class MyEventReceiver : public IEventReceiver 
{ 
  scene::ICameraSceneNode* Camera; 

public: 
  MyEventReceiver(scene::ICameraSceneNode* camera) 
    : Camera(camera) 
  { 
    Camera->grab(); 
  } 

  virtual ~MyEventReceiver() 
  { 
    Camera->drop(); 
  } 

  virtual bool OnEvent(irr::SEvent event) 
  { 
    if (event.EventType == irr::EET_KEY_INPUT_EVENT && 
      event.KeyInput.PressedDown) 
    { 
      f32 newFOV = Camera->getFOV(); 

      switch(event.KeyInput.Key) 
      { 
      case irr::KEY_PLUS: 
        newFOV = core::min_(newFOV + core::DEGTORAD, core::PI * .75f); 
        Camera->setFOV(newFOV); 
        return true; 

      case irr::KEY_MINUS: 
        newFOV = core::max_(newFOV - core::DEGTORAD, core::PI * .0125f); 
        Camera->setFOV(newFOV); 
        return true; 
      } 
    } 

    return false; 
  } 
}; 


class CCircleSceneNode : public scene::ISceneNode
{
public:

  static ISceneNode* addCircleSceneNode(f32 radius, u32 points, video::SColor color,
    scene::ISceneNode* parent, scene::ISceneManager* mgr, s32 id = -1,
    const core::vector3df& position = core::vector3df(0,0,0),
    const core::vector3df& rotation = core::vector3df(0,0,0),
    const core::vector3df& scale = core::vector3df(1.0f, 1.0f, 1.0f))
  {
    if (!parent)
      parent = mgr->getRootSceneNode();

    ISceneNode* node = new CCircleSceneNode(radius, points, color, parent, mgr, id, position, rotation, scale);
    node->drop();

    return node;
  }

  CCircleSceneNode(f32 radius, u32 points, video::SColor color,
    scene::ISceneNode* parent, scene::ISceneManager* mgr, s32 id,
    const core::vector3df& position,
    const core::vector3df& rotation,
    const core::vector3df& scale)
    : scene::ISceneNode(parent, mgr, id, position, rotation, scale)
  {
    video::S3DVertex v(0, 0, 0, 0, 0, 0, color, 0, 0);

    u32 n;
    for (n = 0; n < points; ++n)
    {
      const f32 radians = (2.f * core::PI) * n / points;
      v.Pos.X = radius * sinf(radians);
      v.Pos.Z = radius * cosf(radians);

      Buffer.Vertices.push_back(v);
      Buffer.Indices.push_back(n);
    }

    Buffer.BoundingBox.addInternalPoint( 0, 0, radius);
    Buffer.BoundingBox.addInternalPoint( 0, 0,-radius);
    Buffer.BoundingBox.addInternalPoint( radius, 0, 0);
    Buffer.BoundingBox.addInternalPoint(-radius, 0, 0);

    Buffer.Material.Lighting = false;
  }

  virtual void OnRegisterSceneNode()
  {
    if (IsVisible)
      SceneManager->registerNodeForRendering(this);

    ISceneNode::OnRegisterSceneNode();
  }

  virtual void render()
  {
    video::IVideoDriver* driver = SceneManager->getVideoDriver();

    driver->setMaterial(Buffer.Material);
    driver->setTransform(video::ETS_WORLD, AbsoluteTransformation);

    driver->drawVertexPrimitiveList(Buffer.getVertices(),
      Buffer.getVertexCount(),
      Buffer.getIndices(),
      Buffer.getIndexCount() - 1,
      video::EVT_STANDARD,
      scene::EPT_LINE_LOOP);
  }

  virtual const core::aabbox3d<f32>& getBoundingBox() const
  {
    return Buffer.BoundingBox;
  }

  virtual video::SMaterial& getMaterial(u32 i)
  {
    return Buffer.Material;
  }

  virtual u32 getMaterialCount()
  {
    return 1;
  }

private:

  scene::SMeshBuffer Buffer;

};

int main()
{
  // create device and exit if creation failed 
  IrrlichtDevice* device =
    createDevice(video::EDT_DIRECT3D8, core::dimension2d<s32>(800, 600), 32, false, false, false);
  if (!device) 
    return 1; // could not create selected driver.

  video::IVideoDriver* driver = 
    device->getVideoDriver();

  scene::ISceneManager* scene =
    device->getSceneManager();

  gui::IGUIEnvironment* gui =
    device->getGUIEnvironment();

  scene::ICameraSceneNode* camera = 
    scene->addCameraSceneNodeFPS(0, 40.f, 50.f);

  const u32 nrings = 10;
  const u32 nspheres = 10;

  u32 n;
  for (n = 1; n < nrings; ++n)
  {
    const f32 radius = (n * n * n);
    const video::SColor rcolor(255, 0, 127 + 128 / n, 0);
    const core::vector3df rpos(0, -10.f, 0);

    scene::ISceneNode* ring = CCircleSceneNode::addCircleSceneNode(radius, 64, rcolor, 0, scene, -1, rpos); 
    ring->setMaterialFlag(video::EMF_LIGHTING, false);

    if (n < 2)
      continue;

    u32 m;
    for (m = 1; m <= nspheres; ++m)
    {
      const f32 radians = (2.f * core::PI) * m / nspheres;
      const core::vector3df pos(radius * sinf(radians), 0, radius * cosf(radians));

      scene::ISceneNode* sphere = scene->addSphereSceneNode(5.f, 16, ring, -1, pos);
      sphere->setMaterialFlag(video::EMF_LIGHTING, false);
    }
  }

  MyEventReceiver receiver(camera);
  device->setEventReceiver(&receiver);

  f32 p_fov = 0;
  while (device->run())
  {
    if (device->isWindowActive())
    {
      if (driver->beginScene(true, true, video::SColor(255, 64, 64, 64)))
      {
        scene->drawAll();
        gui->drawAll();

        driver->endScene();
      }

      const f32 fov = camera->getFOV() * core::RADTODEG;
      if (fov != p_fov)
      {
        wchar_t caption[64]; 
        _snwprintf(caption, 64, L"fov=%0.2f", fov);
        p_fov = fov;

        device->setWindowCaption(caption);
      }
    }
    else
    {
      device->sleep(125);
    }
  }

  device->drop();

  return 0;
}

[VioletAlixe]

Source code for fov test example...
...

Copied and pasted and it didn't compile. Just got this:

1>------ Build started: Project: 01.HelloWorld, Configuration: Debug Win32 ------
1>Compiling...
1>main.cpp
1>c:\users\violetalixe\desktop\irrlicht-1.4beta\irrlicht-1.4beta\examples\01.helloworld\main.cpp(165) : warning C4244: 'initializing' : conversion from 'irr::u32' to 'const irr::f32', possible loss of data
1>c:\users\violetalixe\desktop\irrlicht-1.4beta\irrlicht-1.4beta\examples\01.helloworld\main.cpp(186) : error C2259: 'MyEventReceiver' : cannot instantiate abstract class
1> due to following members:
1> 'bool irr::IEventReceiver::OnEvent(const irr::SEvent &)' : is abstract
1> c:\users\violetalixe\desktop\irrlicht-1.4beta\irrlicht-1.4beta\include\ieventreceiver.h(256) : see declaration of 'irr::IEventReceiver::OnEvent'
1>Build log was saved at "file://c:\Users\VioletAlixe\Desktop\irrlicht-1.4beta\irrlicht-1.4beta\examples\01.HelloWorld\Debug\BuildLog.htm"
1>01.HelloWorld - 1 error(s), 1 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

Repost real quick?

Also... Well first of all, it's called Perspective distortion because it's distorted because of the reality of our eyes using lenses; we have perspective-percieving eyes. Cameras mimic this based on their field of view. This IS a distortion, but it is a natural one that is well-explained in the Wiki article.

The problem is simply that the nearZ and farZ values are only being applied to the vector for the aim of the camera's Z. If you load up the source, you can see how it's applied. Also, the camera is oriented on a point, yes, but the view is linear. It only takes into consideration the Z, or depth, vector.

Okay, if you want to use code, I think you should take a look at the D3D perspective cameras used today in games for Xbox, PC, 360, etc. (Anything that uses DirectX, really.)

Their camera initializations use this format:

Code: Select all

d3d_set_projection(argument0,argument1,argument2,argument0+(t1+t2),argument1+2*(argument4*argument5+argument3*argument6),argument2+2*(argument4*argument6-argument3*argument5),2*(argument4*argument6+argument3*argument5),2*(argument5*argument6-argument3*argument4),t1-t2);

#define d3d_quaternion_set_projection_neg_ext
/** \def d3d_quaternion_set_projection_neg_ext(x,y,z,q0,q1,q2,q3,angle,aspect,znear,zfar) 

It's explained in the bottom part. It's pretty simple. Camera vector, target vector, angle of FOV, the aspect ratio for the screen, the near value and the far value. (READ)Seems familiar, right?

Irrlicht has those same options! That's -so- cool!

Irrlicht definitely offers a lot of options for your camera, except that for a FishEye (WARPED FOV) camera, in D3D, all you have to do is change the zfar aspect to a very high number, and change the angle of your FOV to match how large your FOV should show, sometimes changing the aspect ratio is necessary. But it all depends on what kind of values you throw in.

READ: No matter what values you change the FOV, ASPECT, or ZFAR to in Irrlicht, you will not achieve a FishEye camera. Why? Because unlike DirectX's (READ: PEOPLE WHO MAKE REAL GAMES) perspective cameras, Irrlicht's perspective is only taking into account one direction!


Edit: so you know I'm not pulling this out of my arse; http://www.codeproject.com/cpp/mfcd3diii.asp

[VioletAlixe]

Okay, update. I fixed your source code, which I suspect was just an accident or some such (just had to change the irr::SEvent event to const SEvent& event), and it ran fine except for it's not really a fish-eye lens, although you used the same altered attributes I mentioned above about how it SHOULD have to be altered to make a fish-eye lens. Even at 135 degrees visible, there's absolutely no curvature in your "fish-eye" lens, and there's absolutely no scaling difference as things move left or right of the origin.

VISUAL:

http://img187.imageshack.us/my.php?image=nfesh5.jpg

See, while it may seem like a fish-eye in your example at first, it's only because you rotated it in such a manner that you can't see those spheres right next to eachother aren't getting smaller, because they're in the distance. Good try though.


EDIT: I should mention that your source was valuable in that when I got to try the D3D (standard) recommended FOV of 45 degrees, I noticed that it eliminated all the skewing diagonally for those spheres. (But of course, still did not scale or curve) It would seem that that big professional DirectX thing has it down. I wonder why...?

[vitek]

Repost real quick?

Uh, no. It works quite well with the publicly released Irrlicht 1.3.1. If you want to fix it, make the param const ref.

The problem is simply that the nearZ and farZ values are only being applied to the vector for the aim of the camera's Z.

No, the problem is perspective projection. Go back to wikipedia... Please.

Perspective projection distortion is the inevitable misrepresentation of 3-Dimensional space when drawn or "projected" onto a 2-Dimensional surface...It is impossible to accurately depict 3D reality on a 2D plane. However, there are several constructs available which allow for seemingly accurate representation...

I think you should take a look at the D3D perspective cameras used today in games for Xbox, PC, 360, etc. (Anything that uses DirectX, really.)

Really? I linked you to the documentation for the perspective projection function provided by Direct3D. You must have skipped right past it. It uses exactly the same projection matrix calculations as Irrlicht does. Big surprise.

Their camera initializations use this format:...

The code you snipped was GameMaker script. Here is the body of that function [part of the comment removed]...

Code: Select all

#define d3d_quaternion_set_projection_neg_ext
/** \def d3d_quaternion_set_projection_neg_ext(x,y,z,q0,q1,q2,q3,angle,aspect,znear,zfar)
 */

var t1,t2;
t1=sqr(argument3)-sqr(argument5)
t2=sqr(argument4)-sqr(argument6)

d3d_set_projection_ext(argument0,
                       argument1,
                       argument2,
                       argument0-(t1+t2),
                       argument1-2*(argument4*argument5+argument3*argument6),
                       argument2-2*(argument4*argument6-argument3*argument5),
                       2*(argument4*argument6+argument3*argument5),
                       2*(argument5*argument6-argument3*argument4),
                       t1-t2,
                       argument7,
                       argument8,
                       argument9,
                       argument10);

If you looked at the documentation for d3d_set_projection_ext you'd see that it just defines both the view and projection transforms. So the function d3d_quaternion_set_projection_neg_ext you are describing takes the vector [x, y, z] that is the position of the camera and a quaternion [q0, q1, q2, q3] that represents the camera orientation, and creates a view matrix. It then uses the fov [angle], the aspect ratio [aspect] and the znear and zfar values [znear, zfar] to build a standard projection matrix. That's it. Nothing different than Irrlicht does. Wow, cool! I'm curious why you bothered posting at all.

in D3D, all you have to do is change the zfar aspect to a very high number

There is no Direct3D function that takes a 'zfar aspect'. The zfar value passed to all Direct3D perspective projection functions is the distance to the far plane along the Z axis.

Because unlike DirectX's perspective cameras, Irrlicht's perspective is only taking into account one direction!

I still haven't seen anything [documentation, source code, screen shots, demos] that shows this Direct3D function you keep talking about. Every Direct3D perspective projection function suffers from the perspective distortion problem. Please link us to something that describes this special projection. Please!!!

READ: PEOPLE WHO MAKE REAL GAMES

What, all games that don't use this mythical perspective correct projection aren't real games?

The only thing that I think you're going to find about fisheye projections in realtime is the the fisheye quake project. It uses several [3-6] 90 degree perspective projections and combines them onto the resulting image. Not something you can do by tweaking the perspective transform.

Travis

[VioletAlixe]

Okay, ignoring all the nonsense you just spewed, the perspective "problem" isn't a problem. It's a reality of curved lenses. I don't want to keep reiterating myself. Look at your own example, you FAILED at creating a fish-eye. I took a screenshot to show you what's wrong with it. Why did it fail? Because it didn't take into consideration that the things that are further to the left and right become smaller.

If you feel like testing whether or not it's a "problem" with translating 3D, go ahead and open your eyes and put your hand in front of it while looking forward. Now move your hand out to your side while still looking forward. Notice anything? Oh! It got smaller!

I believe the problem lies here, in the matrix4.h

Code: Select all

	//! Builds a left-handed perspective projection matrix.
	template <class T>
	inline void CMatrix4<T>::buildProjectionMatrixPerspectiveLH(f32 widthOfViewVolume, f32 heightOfViewVolume, f32 zNear, f32 zFar)
	{
		M[0] = (T)(2*zNear/widthOfViewVolume);
		M[1] = 0;
		M[2] = 0;
		M[3] = 0;

		M[4] = 0;
		M[5] = (T)(2*zNear/heightOfViewVolume);
		M[6] = 0;
		M[7] = 0;

		M[8] = 0;
		M[9] = 0;
		M[10] = (T)(zFar/(zFar-zNear));
		M[11] = 1;

		M[12] = 0;
		M[13] = 0;
		M[14] = (T)(zNear*zFar/(zNear-zFar));
		M[15] = 0;
		definitelyIdentityMatrix=false;
	}

[vitek]

Look at your own example, you FAILED at creating a fish-eye.

Never once did I claim to be attempting to implement fisheye distortion. My code shows that the distortion occurs at large field of views. I said, and I quote... The default FOV used by the irrlicht cameras is no good and it causes distortion of objects that are near the edges of the view.

Nope, that one isn't wrong. The D3DXMatrixPerspectiveLH documentation shows the exact same matrix. Not that it really matters because buildProjectionMatrixPerspectiveFovLH() is the one that is used by the Irrlicht cameras by default. That one is correct also. Compare it to D3DXMatrixPerspectiveFovLH.

Obviously you don't read anything I post. I don't know why I'm wasting my time trying to tell you that Irrlicht isn't doing anything any differently than any other engine. Any issues you have with perspective projections on Irrlicht will exist when using perspective projections.

Travis

[VioletAlixe]

Look at your own example, you FAILED at creating a fish-eye.

Never once did I claim to be attempting to implement fisheye distortion. My code shows that the distortion occurs at large field of views.

Nope, that one isn't wrong. The D3DXMatrixPerspectiveLH documentation shows the exact same matrix. Not that it really matters because buildProjectionMatrixPerspectiveFovLH() is the one that is used by the Irrlicht cameras by default. That one is correct also. Compare it to D3DXMatrixPerspectiveFovLH.

Obviously you don't read anything I post. I don't know why I'm wasting my time trying to tell you that Irrlicht isn't doing anything any differently than any other engine. Any issues you have with perspective projections on Irrlicht will exist when using perspective projections.

Travis

That's utter nonsense. I'm giving an example as to where the issue of only one plane near/far is being used. You even said yourself that you found that gamemaker doesn't do it this way, so how can you say that none do? And why would you make an implementation of the FOV system when it won't change the outcome that you can't account for the other axises when you're trying to make a the correct perspective?

Look, I realize that it's essentially the same for the other cameras. YES, that's what it is by default, because it's an error built in to irrlicht. All of the perspective-based cameras are like this in that they only take into consideration the depth in the direction you're looking!