next »

[increpare]

Have finally gotten around to compiling the Raycaster Rendering Demos that Terry and I cobbled together (mostly at the airport) at tigjam UK 2008.  There are 12; here's a montage of 10:

OSX 10.5 + Source (5.85 MB)
Windows + Source (3.47 MB)
Source (16 KB)[/b]

[Hideous]

Don't you mean raycasting?

Anyway, this looks mighty interesting, except that the math is burning me.

[increpare]

Don't you mean raycasting?

Convention has it nowadays that there're distinctions between the two (Terry does as well).  I'm a bit more old-fashioned, I guess in my indiscriminate usage of the two terms .

The differences between the various examples involve little or no math.  For stuff about the raycaster itself, see Terry's post here.

[Hideous]

Thing is, my silly school has yet to teach me anything about trig, so I have no idea what sin(x) and stuff really means.

[increpare]

Thing is, my silly school has yet to teach me anything about trig, so I have no idea what sin(x) and stuff really means.

it isn't used in the rendering-example-specific parts of the code at all.

[Hideous]

oh ok.

[Zaphos]

Don't you mean raycasting?

Convention has it nowadays that there're distinctions between the two (Terry does as well).  I'm a bit more old-fashioned, I guess in my indiscriminate usage of the two terms .

The difference is just bounce rays vs no bounce rays, generally ... it's actually a useful distinction.  Although, I think it'd be cool to do a raytracer in this sort of wolfenstein style... wolfenstein's house of mirrors!  And you could throw in some nice translucency and refraction, too.  Because we can't do a house of mirrors in standard rasterization very well, it could actually look pretty unique
edit edit: hmm, I guess it wouldn't really work unless you had orthographic perspective (so the mirrors kept the 2D rays) which wouldn't be nearly as cool.  Oops.

edit: Also, one way to understand trig functions cos(alpha) and sin(alpha) is that they take an angle and give you the corresponding x and y coordinates on a circle with radius one.  So if you want to shoot out a ray at a specific angle, you turn that angle in to a vector by doing (cos(angle), sin(angle)).  (hope that makes sense ...)

[Loren Schmidt]

Thanks for sharing, these are really neat. I'd like to see more people experimenting with alternative rendering styles.

You know, I've always wanted to see a game done with low resolution 1-bit real time raytracing. I'm imagining the engine would randomly dither grays, so the image would have a slightly loose look to it. No specular highlights, just flat shading.

[increpare]

The difference is just bounce rays vs no bounce rays, generally ... it's actually a useful distinction.

Sure.  I just haven't internalized/adopted the usage yet.

You know, I've always wanted to see a game done with low resolution 1-bit real time raytracing. I'm imagining the engine would randomly dither grays,

That would be a pretty easy modification to do with the example above.  You could store an array of dithering-patters, and blit them as appropriate.

[agj]

Beautiful stuff. You'll probably give cactus a hard-on if he sees this thread.

I noticed what is likely a glitch, though: walls parallel to one's line of sight that are toward the left of the screen appear properly deformed as by optics (with a 'convex' shape), but the ones toward the right appear with their deformation reversed ('concave'):

[Terry]

Er, that's my fault The basic raycaster was just a quick hack for that codeblocky thing, it didn't even have a proper fish eye fix.

It happens because all the rays are being cast from a single point, when really they should be cast straight ahead from a line. It's an easy fix on a proper raycaster, but my approach had a small margin of error due to the stepsize in casting each ray, so a fish eye fix would just have made things look worse than they do.

Btw Increpare, this all looks awesome! Maybe we should try doing something more serious with it?

[Zaphos]

It happens because all the rays are being cast from a single point, when really they should be cast straight ahead from a line.

I'm pretty sure casting from a single point is the correct way to do it, for a perspective view?

I noticed what is likely a glitch, though: walls parallel to one's line of sight that are toward the left of the screen appear properly deformed as by optics (with a 'convex' shape), but the ones toward the right appear with their deformation reversed ('concave'):

I think normally people want a planar projection, where straight lines to remain straight?

[Terry]

It happens because all the rays are being cast from a single point, when really they should be cast straight ahead from a line.

I'm pretty sure casting from a single point is the correct way to do it, for a perspective view?

I'm not really sure what you mean - if you work out the lengths to a flat wall straight ahead of you from a single point, the middle of the wall is always going to be distorted because the lines at the edge will be longer than the lines in the middle... If you've gotten the correct distances (which I don't have in this case) you can fix this with a bit of trig, which is basically equivalent to casting your rays from a line rather than a point...

The last part of this tutorial explains what I'm trying to get at clearer than I can, I think.

The distance from the player to the wall at the far left of the screen is greater than the distance from the player to the wall in the centre of the screen, so the wall appears smaller. The reason you don't get this fisheye effect with a traditional 'divide by z' polygon engine is that these engines only consider the distance in the z axis, not the 3D distance. So a polygon engine uses screen_x = global_x / global_z and not screen_x = global_x / distance so it works out the distance to a plane (z = 0 plane) and not to a point.

[Decipher]

Zaphos: If you're talking about the so-called fish-eye effect that's caused because of the FoV<α> (Field of View angle).

[Zaphos]

It happens because all the rays are being cast from a single point, when really they should be cast straight ahead from a line.

I'm pretty sure casting from a single point is the correct way to do it, for a perspective view?

I'm not really sure what you mean - if you work out the lengths to a flat wall straight ahead of you from a single point, the middle of the wall is always going to be distorted because the lines at the edge will be longer than the lines in the middle... If you've gotten the correct distances (which I don't have in this case) you can fix this with a cos scaler, which is basically equivalent to casting your rays from a line rather than a point...

If you did the casting to the full projection plane, instead of just a line of the plane, the height adjustment would happen 'for free' and it would give you a planar projection: straight lines remain straight.  Your error comes in through the height function, not the ray casting.  The cos scale is about measuring the distance along the view vector, which is different from casting along the view vector.

The problem with projecting from a line instead of a point is that it's a parallel projection: you lose the property that things get smaller as they get farther away.  Or, in the case of a wolf-3d like system, you lose the property that they get smaller in width, and then you might keep the fact they get smaller in height (if you didn't change the height function), which would probably be odd.

[Zaphos]

Zaphos: If you're talking about the so-called fish-eye effect that's caused because of the FoV<α> (Field of View angle).

A fish-eye effect should result from a non-planar projection, not a particular field of view ... it is used to get a wide field of view, though ... ?

edit: this is a neat page comparing planar vs fisheye projections in quake as the field of view is increased:
http://strlen.com/gfxengine/fisheyequake/compare.html

[Bad Sector]

The fish-eye effect occurs because the ray distances between the eye and the wall increases as the angle between the ray at center of the screen and the current ray increases. To fix this just multiply the distance with the cosine of the angle between the ray at the center of the screen and the current ray. Page 8 of permadi's tutorial explain this with images, although the wording wasn't very clear the first time i read it. The b in cos(b) there is the angle between the ray at the center of the screen and the current ray you render, which is always the same value for each column. A simple case if you use a

Code:

for (x=0; x<screenWidth; x++) {
...
}

loop, is to do something like

Code:

b = -30;
for (x=0; x<screenWidth; x++) {
...
distance *= cos(b);
...
b += 1;
}

(note: here i assume you use a 60 degree FOV and your cos takes degrees, not radians).

[Zaphos]

It happens because all the rays are being cast from a single point, when really they should be cast straight ahead from a line.

I'm pretty sure casting from a single point is the correct way to do it, for a perspective view?

I'm not really sure what you mean - if you work out the lengths to a flat wall straight ahead of you from a single point, the middle of the wall is always going to be distorted because the lines at the edge will be longer than the lines in the middle... If you've gotten the correct distances (which I don't have in this case) you can fix this with a bit of trig, which is basically equivalent to casting your rays from a line rather than a point...

The last part of this tutorial explains what I'm trying to get at clearer than I can, I think.

The distance from the player to the wall at the far left of the screen is greater than the distance from the player to the wall in the centre of the screen, so the wall appears smaller. The reason you don't get this fisheye effect with a traditional 'divide by z' polygon engine is that these engines only consider the distance in the z axis, not the 3D distance. So a polygon engine uses screen_x = global_x / global_z and not screen_x = global_x / distance so it works out the distance to a plane (z = 0 plane) and not to a point.

I missed the edited version of this!  But it's the same thing ... casting the rays from a line is different from measuring the distance from the line; you want to do the second not the first.

[increpare]

Er, that's my fault The basic raycaster was just a quick hack for that codeblocky thing, it didn't even have a proper fish eye fix.

fwiw, I was quite a fan of the fisheye effect.  (Given the interesting discussion here, a series of studies in perspectives will probably be next on the cards ).

Btw Increpare, this all looks awesome! Maybe we should try doing something more serious with it?

Totally   I've already given it a try solo, but haven't been able to come up with much.  Maybe with our powers combined we can do something 

[agj]

I noticed what is likely a glitch, though: walls parallel to one's line of sight that are toward the left of the screen appear properly deformed as by optics (with a 'convex' shape), but the ones toward the right appear with their deformation reversed ('concave'):

I think normally people want a planar projection, where straight lines to remain straight?

That's not how optics work, though.



But that Quake link up there shows this better.

Since I was a kid I found polygonal 3D to be disconcerting, because perspective is borked so that rotating a camera positioned in a static point makes the geometry flex around to adapt, but we that's not how we actually see stuff with our eyes.