To be fair, it's not exactly a "raytracer", it's a program capable of rendering that specific scene (i.e. bunch of spheres) using a recursive raytracing algorithm, which isn't awfully complex in itself. Not trying to say it's bad or anything, just want to point out that it's not very surprising for something like this to be under 100 loc in a high-level language.
A tiny tip coming from a friendly place, if I may- your comment comes off as slightly pedant and elitist. I'm sure it was not in your intention to bring down the original author of this demo, who is probably very excited about what he worked hard on, but rather to highlight how deep of a field raytracing is and to encourage him to not be content with this first venture into it, and to explore more of it.
A good way to do that is to write your comment from a "Yes and..." perspective, rather than a "Yes but..." perspective. In one case you're showing the author how tall the wall front of him is, in the other you show him how you yourself climbed that wall when you were in his position.
and you find a blog with 1.5 semi-coherent posts and a shitty sidescroller? :-)
I'm not criticizing the author or his work, I'm just saying that writing a recursive function that does p + kv recursively shouldn't take a lot of code. Do I need to end each comment with a smiley face to prevent it from being taken the wrong way?
I agree with you, it's not a very complicated thing. But that's the beauty of it - raytracers are simple but produce stunning images (it is a raytracer, though - it traces rays! Plus it does ambient + point lights, reflections, shadows... the kind of stuff raytracers do)
It doesn't take a lot of code, sure. But "a cross-platform game framework in 100,000 lines of C++" is not the current fad in HN ;)
I don't think it's a matter of adding a smiley at the end of each comment (although I love smileys, so I do that too :-)
I think it's more a matter of saying "Yes, good job on figuring out how to do p + kv recursively! Here are links to {papers|books|lectures|other code} that go further if you want to explore this topic more" rather than saying "Oh, you figured out how to do p + kv recursively, just like millions of other CS freshman. Good for you".
It's the little details that make online communities pleasant :)
To be fair, you are wrong. It is totally a ray tracer, there is the top variable that is the description of the scene and you can hack the positions and see how the scene changes. Also it is proper ray tracing as far as it goes from the point of view of the algorithm used to cast rays, it finds the closest intersection and so forth. The most obvious limitation is just support for a single kind of geometric primitive: the sphere.
Well, to answer that question, let me make an analogy. There's no required set of features for calculators either.
Technically a tiny box that can only add two numbers can be considered a calculator, since it calculates. I guess we might call it so, but it isn't the same, is it?
It's just that people tend to think about povray and renderman when "raytracers" are mentioned, and thus, fitting a raytracer into 30 lines of javascript may seem impossible, while actually it's entirely possible because the core idea of the algorithm is quite simple - this is what this demo shows and it is exactly the reason it's a good demo.
>It's just that people tend to think about povray and renderman when "raytracers" are mentioned, and thus, fitting a raytracer into 30 lines of javascript may seem impossible
Not really. At least neither me, nor (I'd say) the HN crowd, would expect something like povray or renderman given the title of the article.
What we'd expect, an implementation of a ray tracing algorithm, and not a full featured program, we got.
