The Acid tests are specifically much harder than what a browser needs to handle to do a good job with web browsing, in fact a few of the tests specifically use broken code IIRC.
The things tested by ACID3 are not in general use because browsers don't reliably support them. Many would be in use if they were actually supported. That is the aim of ACID3, to drive browser makers to actually fix these things so people can finally start using them.
That's the policy of a handful of projects. There's no such thing as an official "FOSS versioning", and if there was, what you described would not be it.
If you're doing it slowly and in software, yes. But to get to realtime speeds you either need to make sacrifices, or use hardware (or even both).
Although if you managed to design hardware that does ray-nurb intersections quickly then you're set. But I'm assuming we'd actually just get simple ray-triangle intersections.
Only for trivial geometry. With real geometry, you'll quickly run into memory bandwidth issues, as every single ray can potentially access any part of the geometry.
So do addition and subtraction, indirection, and object-oriented programming, but you wouldn't argue that a raytracer that used these wasn't a raytracer.
No, what I argue is this: You get a bigger payoff by laying off the raytracing and just staying with rasterizing. Raytracing costs a lot, and the payback small. There are methods to improve rasterizing that give a bigger payback for far less cost.
It does more realistic lighting than rasterization, and it definitely will do caustics... you just need to shoot more rays. What is traditionally referred to as raytracing would require immense numbers of rays to do caustics. To handle those, one needs to combine ray tracing with other methods, such as photon tracing.
"Global Illumination" isn't a lighting effect, it's a heuristic for rasterizing that fakes some effects that require additional rays to calculate. No, global illumination is often implemented through various heuristics, but the term itself is general, and just means taking indirect light into account.
There's also some very good (albeit still expensive) techniques to simulate radiance and other "global illumination" effects in raytracing. And many of those work just as well for rasterizing.
I don't think there is any debate at all, RayTracing is by far superior, there is just the problem of computing power. That's a common misconception. Raytracing gets you some benefits, but the cost is huge. However, there are many things it can't do either. Global lighting is just as hard with raytracing as with rasterization, but the payoff for getting that right is often far bigger than what you'd gain by using raytracing.
Reflections (and various translucency effects) are all they were demoing. It's all they are demoing because it's pretty much all raytracing is actually good at, at least at realtime speeds.
But raytracing doesn't do realistic lighting at all! It won't easily do global illumination, and it won't do reflected or refracted caustics either, at least not in realtime.
Raytracing is an "embarrassingly parallel" task Not quite. Each ray has to access the entire world geometry. Try to do that in parallel, and you'll either need huge separate memories for each processor, or you'll run out of shared memory bandwidth pretty quick.
Rasterizing is far better when it comes to parallel memory access.
Raytracing is just as much of a hack as rasterizing. It's just a different hack. Both are nothing but rough approximations of the rendering equation.
Raytracing is better at rasterizing for rendering silver spheres on checkerboards, but the lack of those aren't the main problem with graphics these days. Raytracing is pretty much as bad at rasterizing at things that matter much more, such as decent global illumination.
The basic assumption made by the "LHC will eat the Earth" crowd is that black holes do NOT emit Hawking radiation. If they do, there is zero danger from micro black holes, as they instantly evaporate.
Slashdot Mirror
Only if you are hoity-toity enough to use the word "erotic" instead of "porn".
but also speaks the language.
You don't seem to speak it quite as well as you believe. "Hentai" is never used in Japanese to refer to porn.
Well, except when making fun of the silly gaijin and their weird word usage.
Actually, "eromanga" is a plain japanese word and not any kind of neologism. It just means "porn manga".
"Hentai", however, is a western neologism that is not used in Japanese.
The earlier Acids were also full of tests against hand-picked bugs in the various browsers, you know.
Once again, are you sure that's not just Flash?
The Acid tests are specifically much harder than what a browser needs to handle to do a good job with web browsing, in fact a few of the tests specifically use broken code IIRC.
The things tested by ACID3 are not in general use because browsers don't reliably support them. Many would be in use if they were actually supported. That is the aim of ACID3, to drive browser makers to actually fix these things so people can finally start using them.
That's the policy of a handful of projects. There's no such thing as an official "FOSS versioning", and if there was, what you described would not be it.
If you're doing it slowly and in software, yes. But to get to realtime speeds you either need to make sacrifices, or use hardware (or even both).
Although if you managed to design hardware that does ray-nurb intersections quickly then you're set. But I'm assuming we'd actually just get simple ray-triangle intersections.
And raytracing is embarrassingly parallelizable
Only for trivial geometry. With real geometry, you'll quickly run into memory bandwidth issues, as every single ray can potentially access any part of the geometry.
Yes, but you're unlikely to do them in realtime. Somewhere down the road it may be possible and worthwhile, but currently it is not.
So do addition and subtraction, indirection, and object-oriented programming, but you wouldn't argue that a raytracer that used these wasn't a raytracer.
No, what I argue is this: You get a bigger payoff by laying off the raytracing and just staying with rasterizing. Raytracing costs a lot, and the payback small. There are methods to improve rasterizing that give a bigger payback for far less cost.
But raytracing doesn't do realistic lighting at all! It won't easily do global illumination, and it won't do reflected or refracted caustics either, at least not in realtime.
Rasterizing is far better when it comes to parallel memory access.
Raytracing is just as much of a hack as rasterizing. It's just a different hack. Both are nothing but rough approximations of the rendering equation.
Raytracing is better at rasterizing for rendering silver spheres on checkerboards, but the lack of those aren't the main problem with graphics these days. Raytracing is pretty much as bad at rasterizing at things that matter much more, such as decent global illumination.
Is the reason that this is Slashdot, where 1984 is pulled out in every single discussion about anything that has to do with the government?
Especially if you make up your own reality to reinforce your cynicism.
Wow, that's some tunnel vision. Stories like this happen all the time. You only hear about the ones that make people angry, because what sells news.
Cynicism is never a substitute for insight.
See, that was one of these "jokes" making fun of the wording of the article.
Good catch! You're most likely the first person to mention this!
The basic assumption made by the "LHC will eat the Earth" crowd is that black holes do NOT emit Hawking radiation. If they do, there is zero danger from micro black holes, as they instantly evaporate.
We can't expect support for Javascript 2 in Firefox until the next version? But I want it to magically appear in the current one!
An electron hole is a lack of positive-energy electrons. A positron in the Dirac model is a lack of a negative-energy electron.