• Create Account

# Question about generating rays from camera.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

6 replies to this topic

### #1MrOMGWTF  Members   -  Reputation: 433

Like
0Likes
Like

Posted 29 August 2012 - 02:00 AM

Hey. I just finished doing my ray marcher with distance fields. It supports ambient occlusion, shadows, diffuse lighting. It's pretty basic. Here's render from it: (1024 x 1024)
Spoiler

But ok, let's get to the question. How do you generate eye rays? What's the easiest way to do this?
But it distorts my image even at field of view of 45... The fov on render above me is 22.5.
What's the proper method to generate eye rays?

### #2Bacterius  Crossbones+   -  Reputation: 8494

Like
0Likes
Like

Posted 29 August 2012 - 02:24 AM

There will always be some form of distortion with a perspective plane projection, no matter what field of view you use. Higher fields of view will lead to extreme distortion at edges, and smaller fields of view will lead to loss of depth. Are you sure you are using the factor correctly? In my raytracer, at a field of view of 45 degrees the distortion is not very noticeable except if I had tiny spheres at the edges, and quite acceptable, of course it depends on your standards.

Other solutions involve projecting the scene on a section of a sphere, which eliminate distortion but introduce other artifacts such as straight lines being projected curved and aren't as easy to compute... there is no perfect projection as you necessarily throw away information from a three-dimensional world to a two-dimensional plane.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #3MrOMGWTF  Members   -  Reputation: 433

Like
0Likes
Like

Posted 29 August 2012 - 02:32 AM

@Bacterius:
Here's my camera code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using OpenTK;

namespace SphereTracing
{
public class Camera
{
public Scene BaseScene { get; set; }
public Vector3 Position { get; set; }
private float FovX;
private float FovY;
private float TanFovX;
private float TanFovY;

public Camera(Scene sc)
{
BaseScene = sc;
SetFov(MathHelper.PiOver4);
}

public void SetFov(float fov)
{
float width, height;
width = (float)BaseScene.Renderer.Width;
height = (float)BaseScene.Renderer.Height;
FovX = fov;
FovY = height / width * FovX;
TanFovX = (float)Math.Tan(FovX);
TanFovY = (float)Math.Tan(FovY);
}

public float GetFov()
{
return FovX;
}

public Ray GetRay(int x, int y)
{
Ray r = new Ray();
float width, height;
width = BaseScene.Renderer.Width;
height = BaseScene.Renderer.Height;

float dx = (2 * x - width) / width * TanFovX;
float dy = (2 * y - height) / height * TanFovY;

r.Position = this.Position;
r.Direction = new Vector3(dx, dy, -1.0f);
r.Direction = Vector3.Normalize(r.Direction);

return r;
}
}
}

Here's simple plane rendered at fov 45:

It doesn't look right for me.

### #4Bacterius  Crossbones+   -  Reputation: 8494

Like
0Likes
Like

Posted 29 August 2012 - 02:39 AM

You are ray-marching, not ray-tracing, so your rays die after a certain distance travelled (as far as I can guess - you haven't mentioned what you do with your rays) so that would explain the arcing horizon. A perspective projection cannot by definition cause straight lines to appear curved, so the curved horizon doesn't come from the camera - as far as I can tell anyway, the camera code looks fine, although the camera position and direction are hardcoded.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #5MrOMGWTF  Members   -  Reputation: 433

Like
1Likes
Like

Posted 29 August 2012 - 02:45 AM

You are ray-marching, not ray-tracing, so your rays die after a certain distance travelled (as far as I can guess - you haven't mentioned what you do with your rays) so that would explain the arcing horizon. A perspective projection cannot by definition cause straight lines to appear curved, so the curved horizon doesn't come from the camera - as far as I can tell anyway, the camera code looks fine, although the camera position and direction are hardcoded.

The position isn't hardcoded, there is no rotation. To rotate a camera I have to multiply the ray direction vector by rotation matrix, right?

@edit And yes, I increased the max distance from 100 to 1000, and the plane is now flat. Thanks for the help.

Edited by MrOMGWTF, 29 August 2012 - 02:47 AM.

### #6Bacterius  Crossbones+   -  Reputation: 8494

Like
0Likes
Like

Posted 29 August 2012 - 02:54 AM

The position isn't hardcoded, there is no rotation. To rotate a camera I have to multiply the ray direction vector by rotation matrix, right?

Ah, my bad, correct about position. For rotation, yes that will work just fine.

@edit And yes, I increased the max distance from 100 to 1000, and the plane is now flat. Thanks for the help.

You are welcome. Was your original question about field of view solved too, though?

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

- Pessimal Algorithms and Simplexity Analysis

### #7MrOMGWTF  Members   -  Reputation: 433

Like
0Likes
Like

Posted 29 August 2012 - 02:59 AM

You are welcome. Was your original question about field of view solved too, though?

Yes, I'll use my current method. It's fine.

Edited by MrOMGWTF, 29 August 2012 - 02:59 AM.

Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

PARTNERS