61–70 of 99 posts
My raycast engine in Javascript needs a few more lines and works a little bit different, but gives also impressive results I think :) . http://simulationcorner.net/index.php?page=comanche
This demo unfortunately uses an incorrect perspective transformation. There is no reason to go to trig if you represent the camera plane as a vector, and step along it one pixel at a time, and allowing the wall height to vary linearly in the distance to the camera vector (taking lines to lines). In addition to being correct[1], it has the added benefit of being faster if implemented well. My (admittedly n00bish and e…
Why is it incorrect? From looking at the demo, it doesn't seem incorrect at all. If it's incorrect, then the incorrectness doesn't affect the end product, which is all that matters. Lines seem to map to lines, so it seems mistaken to call it incorrect. I'd be interested in further explanation about why you feel the underlying math could be improved, though.
A correct formula is on line 485 of my implementation linked above, found the old fashioned way using basic geometry.
It is very interesting to me that you need to multiply the distance-to-wall by the cosine of the angle to transform the image from fisheye to normal. It makes me wonder, why is it that our eye in real life sees straight lines as straight, the way this demo renders the image? To illustrate the question, see https://en.wikipedia.org/wiki/File:Panotools5618.jpg – why do we see the world as in the bottom image instead of…
I was trying to crack exactly the same problem a decade ago - I was very frustrated by "classical" perspective distortions (such as looking up and down at a very tall pole, you notice in 3D projection the projected width at a given height changes depending on the pitch angle, which is counter-intuitive as your eye doesn't do that). I searched for answers, read Denis Zorin's disertation from Caltech, various different…
At any given moment we're only looking at a very small slice of that larger spherical panorama. Our brains are constantly constructing a coherent 3d model, with the help of various schematic constraints, such as expectations about straight lines being straight.
We perceive straight lines. but that's not what we see. But the curvature is usually so slight that it is very difficult to see.
Earlier quoted context omitted.
Why is it incorrect? From looking at the demo, it doesn't seem incorrect at all. If it's incorrect, then the incorrectness doesn't affect the end product, which is all that matters. Lines seem to map to lines, so it seems mistaken to call it incorrect. I'd be interested in further explanation about why you feel the underlying math could be improved, though.
He ought to be using what Wikipedia calls a "perspective projection", or, sufficiently in this case, a restriction thereof. Notice how the edges of walls do not appear straight on the screen, even though he mentioned correcting "a fisheye effect" (tellingly alluding to a popular tutorial on this topic at lodev.org). A correct formula is on line 485 of my implementation linked above, found the old fashioned way using…
On my old laptop, the demo looked fine. But after switching over to a widescreen (and higher FPS) you can tell that it's slightly wrong up close, and noticeably wrong (jittery) in the distance.
I wonder what's causing the jitter...
My raycast engine in Javascript needs a few more lines and works a little bit different, but gives also impressive results I think :) . http://simulationcorner.net/index.php?page=comanche
Love that you referenced Comanche ... my favorite helicopter game ever. Nice work on the JS side also!
Earlier quoted context omitted.
Its gotta be the shape of our eye, for the same reason the effect works in a mechanical DSLR camera, where light is only refracted through the lens.
> for the same reason the effect works in a mechanical DSLR camera The sensor on the back of a camera is a flat plane, which is why (with most lenses) you get an image where straight lines appear straight. The sensor on the back of your eye (the retina) is curved.
This demo unfortunately uses an incorrect perspective transformation. There is no reason to go to trig if you represent the camera plane as a vector, and step along it one pixel at a time, and allowing the wall height to vary linearly in the distance to the camera vector (taking lines to lines). In addition to being correct[1], it has the added benefit of being faster if implemented well. My (admittedly n00bish and e…
However, I would love to see your proposed solution demonstrated. Would you care to fork the raycaster and compute the results with an alternative method?
Earlier quoted context omitted.
I really like how your code uses much less cpu than that of the article. whats the trick ?
Don't know. But here some possibilities: 1. No fullscreen 2. I update the screen only if a key is pressed.(No rain, that has to be rendered all the time) 3. I don't use any costly canvas functions. I render everything myself in a pixelbuffer. 4. Typed arrays
It is very interesting to me that you need to multiply the distance-to-wall by the cosine of the angle to transform the image from fisheye to normal. It makes me wonder, why is it that our eye in real life sees straight lines as straight, the way this demo renders the image? To illustrate the question, see https://en.wikipedia.org/wiki/File:Panotools5618.jpg – why do we see the world as in the bottom image instead of…
https://en.wikipedia.org/wiki/Perceptual_adaptation#Experime...
Earlier quoted context omitted.
Don't know. But here some possibilities: 1. No fullscreen 2. I update the screen only if a key is pressed.(No rain, that has to be rendered all the time) 3. I don't use any costly canvas functions. I render everything myself in a pixelbuffer. 4. Typed arrays
It's #2. Redrawing at 60hz (or as close as the machine can come) is what hits the cpu so hard.
I calculate as close as the machine can but with a window.setTimeout(Update, 0); in order to be responsive.
