Carmack Speaks On Ray Tracing, Future id Engines 256
Vigile writes "As a matter of principle, when legendary game programmer John Carmack speaks, the entire industry listens. In a recent interview he comments on a multitude of topics starting with information about Intel, their ray tracing research and upcoming Larrabee GPU. Carmack seems to think that Intel's direction using traditional ray tracing methods is not going to work and instead theorizes that using ray casting to traverse a new data structure he is developing is the best course of action. The 'sparse voxel octree' that Carmack discusses would allow for 'unique geometry down to the equivalent of the texel across everything.' He goes on to discuss other topics like the hardware necessary to efficiently process his new data structure, translation to consoles, multi-GPU PC gaming and even the world of hardware physics."
There is a great disturbance in the source... (Score:5, Funny)
Re:There is a great disturbance in the source... (Score:5, Interesting)
Re: (Score:2, Informative)
Re:There is a great disturbance in the source... (Score:5, Informative)
Tim.
Re: (Score:2, Insightful)
Re:There is a great disturbance in the source... (Score:5, Informative)
And even so, while tracing either photons or eye rays may be the most feasible method at the moment, it is by no mean the only way to solve the rendering equation, nor any kind of theoretical best.
Re: (Score:2)
Re:There is a great disturbance in the source... (Score:5, Informative)
Re: (Score:2, Insightful)
However, straight ray
Re:There is a great disturbance in the source... (Score:4, Informative)
I'm sure there's some market for these things, but there's so much more involved even after these algorithms are implemented. Now you have to add settings (or additional texture maps), for each object (or light). As soon add something with live reflections, you can't even throw away what's not on screen (or facing away from camera). So your memory requirements jump just because of that. There's many things that have to come in to place for these technologies are adopted widely. A lot of these algorithms have been around for over 25 years already and are just seeing wide adoption in feature films (most would be surprised at how much is faked, even today).
I hope there's a class of games that don't use these things or take 1 or 2 of these things and use them in innovative ways. While I like the WW2 (or futuristic) FPS games, I feel all that dev time is better spent on innovative game play.
Sorry that the brief reply I planned turned in to a rant.
Re: (Score:3, Insightful)
Innovation does not require much dev time, it requires one bright mind to come up with a good idea and many managers that won't mind spending money on an unproven concept.
Re: (Score:3, Insightful)
as long as it's got a skateboarding turtle it's sure to be a winner.
Re:There is a great disturbance in the source... (Score:5, Interesting)
Everything light does is a combination of reflections and refractions (shadows are an artifact of those).
So, yeah, what you are in effect saying is that raytracing only provides realistic rendering of things that light actually does.
Color bleeding and caustics are effects of reflection, subsurface scattering is reflection and refraction, depth of field is refraction (through a lens between the viewpoint and the image). Now, its true, that there are shortcuts that provide tolerable approximations of those effects faster than actually tracing rays in most cases, and that even static raytracers often prefer those to what would be necessary to do those effects through raytracing alone. Its also true that some real effects, to do well with raytracing, would require shooting separate rays for different wavelengths of light, which while conceptually possible (and I think some very specialized systems have been made which do this), is probably utterly impractical for realtime systems for the forseeable future (this is a lot bigger load increase than anti-aliasing would be.)
But as for realism (but not necessarily practicality, especially in a realtime setting), I think raytracing still, ultimately, wins on all of those.
Re:There is a great disturbance in the source... (Score:5, Informative)
Except the double-slit experiment. It's based on the fact that light has wavefront qualities, while ray tracing treats it as particles.
I also strongly doubt that the discreet ray approach will ever produce very good global illumination, since the number of rays bouncing between surfaces quickly grows towards infinite as the desired accuracy grows.
You'd need to do "wavefront racing" to fix these, and I for one have no idea how to do this - solve the quantum field equations for each particle in the scene after inventing the Grand Unified Theory ?-)
Re: (Score:3, Insightful)
Oh, maybe I better get cracking on the GUT.
Re:There is a great disturbance in the source... (Score:5, Interesting)
Good point.
Well, yeah, the "raytracing is ideally photorealistic" argument does rely (even ignoring the wave effects that raytracing misses), essentially, on unlimited processing power and memory, and isn't necessarily applicable in any particular practical domain. My reference to shortcut techniques to directly model particular phenomena instead of tracing all the necessary rays being a feature of even static raytracing package, and to many of the idealized advantages of raytracing not being realized in practice was based on that.
That sounds about right, probably using a quantum computer "graphics card" (QGPU?).
Re: (Score:3, Funny)
It's do-able (Score:3, Insightful)
It's just a bit more work, and would be unnecessary for most "realistic" scenes, which is why raytracers designed to produce pretty pictures usually skip those features.
I see phase-based optical effects fairly rarely out in the real world (as oppose
Re: (Score:3, Interesting)
No, raytracing has way too many drawbacks to be used seriously nowadays.
Re:There is a great disturbance in the source... (Score:4, Interesting)
No it's not. Depth of field is a function of aperture, and has nothing to do with either lenses or refraction.
Re: (Score:3, Insightful)
The photon system in POV-Ray would be a backwards raytracing app
Re:There is a great disturbance in the source... (Score:5, Funny)
When that happens, will it also become possible to wield a flashlight and a shotgun at the same time? Or is there some kind of fundamental law against that, like how you can't know the position and velocity of a particle at the same time?
Re: (Score:3, Informative)
No. For starters, the rays are "sparse", that is, there is space between two parallel rays which goes unexplored; furthermore, each beam either hits or doesn't hit any given object, leading to aliasing (jagged edges). A much better solution would be racing a cone from each pixel, with no space between them; however, the mathemathics of calulating reflections when the cone hits something would be horrible.
Another problem is with global illumination. Nor
voxel? texel? But I want a pony! (Score:4, Funny)
OMG Ponies! (Score:2)
Anyone betting on if Ray Tracing will give id.... (Score:4, Funny)
Re:Anyone betting on if Ray Tracing will give id.. (Score:3, Insightful)
Re: (Score:3, Funny)
Re:Anyone betting on if Ray Tracing will give id.. (Score:4, Funny)
Whatever, Just Let RAGE Not Suck... (Score:2)
Why not go back sometime and do Quake the way it was meant to be done? I'd love to see those Lovecraftian references fleshed out properly, along with gameplay mechanics that aren't just a "running short on development time, do it like DooM!" type of scenario.
RAGE might very well be great, if it does truly end up being the open-world game version of Mad Max. After what happened with Doom 3 and Quake IV (not quite Id's fault) however, I'm going to have to
Re:Whatever, Just Let RAGE Not Suck... (Score:4, Interesting)
I guess you haven't seen ezquake (best obtained in the nquake package). A faster, more frantic FPS game you will not find. It's also been substantially improved graphically, so there are many more colours about the place.
Any reworking of quake 1 would be badly received by the old school (by this I mean most people who still play it). New people wouldn't see the need, since most of them have grown up on a different fps style. Why revisit quake 1?
Personally I love the game, and play it often. If I have one criticism its that most of the servers are populated by people who are so good at the game, after playing for so long, that just living long enough to pick up a gun and kill someone can be a real challenge.
Re: (Score:2)
Re: (Score:2)
I'm sick of the "modern" FPS. HL2, Bioshock, never finished em'. I liked Doom3 better, but I won't rave about it.
It just seems these days you have incredible graphics and the inevitable linear progression up to "the Boss."
Further, things really never get any more challenging. I never feel like I need to take my gameplaying skill and reflexes to the next level, as I have grown up doing with simpler games. I'm just shooing more zombies.
I don't get any sense of immersion. Maybe they throw in some token po
Re: (Score:2)
Re: (Score:2)
How does it play with Physics? (Score:5, Interesting)
The problem with this is that we are moving more and more towards interactive environments where everything from the ground to the flowerpots are breakable, bendable or movable. It doesn't sound like this new system will play very nice with physics intensive or highly interactive environments. Now, i could be completely wrong. He doesn't address the point directly. But it is still a point for concern.
Re: (Score:3, Interesting)
The problem with this is that we are moving more and more towards interactive environments where everything from the ground to the flowerpots are breakable, bendable or movable. It doesn't sound like this new system will play very nice with physics intensive or highly interactive environments. Now, i could be completely wrong. He doesn't address the point directly. But it is still a point for concern.
I agree completely. When Carmack can implement even a low-polygon all-things-dynamic wonder like Katamari Damashii using his quartile duplex hectotree algorithm, I'll be impressed. The time of precompiling 99% of the game into a static optimized traversal graph is over. Now you've got a bag of loose models (many of which morph), the sum of which fills the screen.
Re:How does it play with Physics? (Score:5, Insightful)
Yea. Because interactivity trumps photorealism for every single possible type of game. Oh wait, that's false.
You sound like the people who said that StarCraft was crap because sprites were outdated junk and every good game (like Total Annihilation) had already moved to 3D. Different engineers will make different design choices for different applications, and there is no total order of correctness among a single class of design choice.
Re:How does it play with Physics? (Score:5, Insightful)
A (longdistancetypedheretoavoidlamenessfilter) B
A non-tree method would just calculate all the interactions: A-B, A-C, B-C. But you can group B+C together when calculating their interaction with A because, at that distance, the result for (B+C)-A is the same as the result for B-A + C-A. Then the interaction between B & C must be calculated separately. So you've (even in this tiny example) reduced your calculation from 3 to 2.
And, of course, all the 'voxels' between A & B/C that are empty need not be considered at all. If you'd set it up as an NxNxN voxel cube, you'd be wasting time on calculating empty voxels between the occupied items.
So if you want realistic interactive environments, sparse voxel octtrees are the way to go-- you pump all the calculation time into the parts where it matters, and let the other stuff be 'smoothed' when such smoothing is indistinguishable from rounding error.
Typically, you can traverse the tree for a given error percentage, e.g. 'walk the tree and do interactions preserving 99% energy conservation' or similar. So your have predictable error, as well, despite being able to use arbitrary geometries and spacing for your elements.
Re: (Score:2)
Re: (Score:2)
This could be used in a whole host of areas where object-object interactions are important, but testing for those interactions can be very expensive. (e.g., molecular dynamics, agent-based biology modeling) One method we've used to solve these issues are interaction potentials. (the object-object interactions are through gradients of the potentials that can be scaled linearly with the number of objects if cleverly constructed.) However, I'm intrigued at using these data structures as an alternative approach
Re:How does it play with Physics? (Score:4, Informative)
Hmm... well, I write here under a pseudonym so it's hard to look up my work. But you can look up 'TreeSPH' in google for some good references to lots of astrophysical implementation. The 'Tree' part is obviously the voxel octtrees, while the 'SPH' means they added hydrodynamics to it by making 'blobs' that have a variable kernel size for smoothing over neighbors.
Which basically means, for hydrodynamics, if it's uniform density you can use a single large 'blob' to represent it, while in an area where the density is rapidly changing you go to smaller 'blobs' because you need more computation. You then use a kernel function, which basically means how much you smooth over neighbors to get a good distribution. With this, you spend all your hydrodynamic computation time on the rapidly changing, shocky, or active stuff. So it's another example of how to decompose a problem they way Carmack seems to be suggesting.
Funny thing is, in astrophysics, this stuff came out in the late 80s/early 90s, and astrophysics usually lags behind physics by a half a decade, which lags behind pure math by a decade. I think the challenge for getting into gaming is converting codes intended for cluster/supercomputer massive calculations into the realm of fast PC gaming.
Tree codes are already heavily used in computer gaming (browsing through 'Computer Developer' magazine shows they are used for dynamic line-of-sight work a lot), so none of what Carmack suggests is cutting edge comp sci in theory. In fact, he used binary space partitioning with Doom, which is in the same field. Much as with Doom etc, the key is can he come up with a fast implementation (or even approximation). I think that's his real talent-- taking existing methods and concepts and figuring out a 'real world' implementation that's fast enough for gaming. He's a programming engineer of no small talent.
Re: (Score:2)
Re: (Score:2, Insightful)
If you had 32 guys running around shooting rocket launchers at each other that would pretty much dessimate any real-life structure in a matter of minutes. Some things just need limits in a gaming environment. Flying crates and debris is fun, but who wants to play in wasteland of scrapped geometry?
You're right. Playing in a wasteland of scrapped geometry doesn't sound like much fun. OTOH, turning a perfectly good level into a wasteland of scrapped geometry... now we're talkin'.
I'd agree, with a proviso. (Score:3, Insightful)
So... what this tells me... (Score:2, Funny)
Re:So... what this tells me... (Score:5, Insightful)
Meanwhile the rest of us have been enjoying these articles immensely because we get to obtain some insight about what each of the major players are thinking in regards to Real-Time Raytracing. The great thing about obtaining insight from others is that you can then use your newfound insight to come to your own conclusions.
If you're simply looking for a consensus from the industry, don't expect one for a long while. The concept won't entirely be accepted until someone goes out there and proves it out. Just like high-quality 3D graphics were thought to be too slow on the PC. Until game creators proved out a few different methods to make them usable, that is. (Starting with Wing Commander, moving to Wolf-3D, Doom, Duke 3D, and eventually Quake. After that, the industry said, "Welp, we better make some hardware for this." And thus 3DFX was born.
Or, raytracing could work (Score:2)
Re: (Score:3, Informative)
He believes the same thing I do - a hybrid approach is most likely, at least in the short term. A sparse voxel octtree (a voxel is a 3d pixel and an octtree is a uniform 3d structure to hold the voxels - they are sparse because most are empty [hold air]) and would work well for ray tracing because it sounds like you'd need to cast rays to find the vo
Limited graphics (Score:5, Funny)
The Most Telling Quote.... (Score:5, Insightful)
Yet, when I play a game, I'll admit, I'm not playing glaring attention to these faults. The last thing that really bothered me in games was 16-bit color banding and I haven't seen any of that in, oh, like 3 or 4 years.
The gamer side of me agrees with Carmack on things looking cool who cares if it's wrong, the geek side of me is angry and demands it be pixel-accurate.
Re: (Score:2)
CUDA? Not today... (Score:2)
As I've pointed out on the NVIDIA forums [nvidia.com], CUDA/OpenGL interoperability is totally broken from a game or video performance standpoint. Instead of being able to quickly shuffle graphics buffers between your CUDA kernel and your OpenGL graphics engine, you have to waste time and bus throughput copying them fro
Wolf3D (Score:2, Interesting)
http://en.wikipedia.org/wiki/Ray_casting [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Raycasting is basically 3d-esque rendering of a 2d map - one ray is cast for every column on screen. Raytracing is the true 3d version - one ray per pixel (plus reflection rays, shadow rays, etc.).
The point is, Raytracing is far more computationally expensive, and visually impressive, than raycasting.
WRT sparse voxel octree FTFA (Score:2, Insightful)
In all, Carmack hints t
Re:WRT sparse voxel octree FTFA (Score:4, Insightful)
search of the literature [acm.org] shows, I was quite late to the game
One of the most fundamental properties of voxmaps is that the geometry and texture are defined hand-in-hand - they have the same resolution, and every point in the geometry has a unique texture. If you want this, then there are data structures like sparse octrees that store the data quite efficiently.
However, decoupling the geometry and texture opens the door for all sorts of tricks usefull in limited memory situations. It was these tricks that made realtime polygon graphics possible in the past. Things like low resolution polygons with high resolution texture maps, tiled/reused texture maps and layered decals, are all ways to cut down on the amount of data needed while still creating a decent looking scene.
However, as the amount of memory increases, these tricks are less necessary and less desirable. Artists want to be able to paint any part of a scene any way they want - and this is exactly what John has done in id Tech 5, their newest engine. After doing so he did some experimentation and found that storing this data in a sparse octree is even more memory efficient than the way he is doing it now, using pixmaps and polygons. If this approach were to work, artists would then have the same freedom in editing the geometry of the world as they do now with textures - the entire world would have geometry at the resolution of current texture maps with zero additional memory costs. That would be awesome.
For this to work though, you need to be able to render the data efficiently. Raycasting of sparse octrees is one of those embarrassingly parallel problems, and thus hardware acceleration for it is relatively easy. But they don't exist due to lack of market, and unfortunately graphics cards are not well suited for this, IIRC because GPUs mostly accelerate floating point calculations, while descending the sparse-octree uses a lot of integer bit-twiddling (I might be wrong about the reasons here). But with the memory-usage tradeoffs shifting in favor of voxmaps, GPU vendors looking to make their products better suited for general purpose High Performace Computing, and John Carmack pushing for it, this may be an idea whose time has come.
Carmack endorsed the Intel 740 graphics chip (Score:2)
I still remember Quake 2 and buying my own first PC and specing it based on his opinion.
He spoke well of the Intel i740. Which turned out to be a dog compared to the Voodoo2.
While, of course, he speaks of the future here, he got this wrong. Very wrong.
From his
Intel i740
----------
Good throughput, good fillrate, good quality, good features. A very competent chip. I wish intel great success with the 740. I think that it f
Re: (Score:2)
Why is it a great shock that the voodoo 2 was far superior to the voodoo 1?
Re:So, (Score:5, Funny)
Don't feel bad, he has probably never heard of you either.
Re:So, (Score:5, Informative)
You've never heard of any of those? the guys you mention might not even be in gaming if it weren't for Carmack and John Romero.
Re: (Score:2)
Re:So, (Score:5, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Even then that's a silly arguments. How many "Gabe Newell's Half-Life" or "Will Wright's Sim City" games do you know of? The only two people I'm aware of at this moment arrogant enough to label their games with their name are Sid and Richard Garriott (and we know how well that one went.)
Re: (Score:3, Informative)
Re:So, (Score:5, Insightful)
George Washington is pretty legendary, but we don't have a George Washington's America, do we? The name is irrelevant. How could the guy who basically invented the First Person Shooter not be legendary? When it first came out, the original Wolfenstein was the most highly optimized game I'd ever played. I still remember thinking it wouldn't run on my slow-ass computer, and being blown away when it ran fast as can be.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
http://en.wikipedia.org/wiki/Half-Life [wikipedia.org]
Half-Life is a science fiction first-person shooter computer game
Re: (Score:2)
Didn't John Carmack post here some time?
Re:Stunning! (Score:5, Insightful)
Re:Stunning! (Score:5, Insightful)
Re:Stunning! (Score:5, Insightful)
Commenting on the fact that it is unsurprising that someone working on a different technique favors that technique over raytracing is not throwing anything out.
Its not a comment either way on the merits.
Were I to comment on the merits, I would point out that his position is both fairly obviously correct (in that sparse voxel octrees or something quite like them is almost beyond question the key to raytracing that's useful for reasonable quality in realtime), and entirely incorrect in his characterization of what everyone else is pushing: he pretends that "everyone" is pushing the most naive, brute force approach to raytracing, in which you don't use any kind of bounding volume structure and just do intersection tests against triangles. I've seen literally no recommendations that do that: almost all involve some form of bounding volume heirarchy, and sparse voxel octrees are just one instance of that (perhaps a fairly ideal one, and that's great). (Also, raytracing isn't limited to triangles, although most performance comparisons of raytracing to raster-based rendering methods use models constructed from triangles because it allows you to compare same-model performance of the different mechanisms; raytracing engines, however, don't generally need to decomposed curved objects into triangle-based approximations to render them in the first place, although this can sometimes be more efficient.)
TFS further misleads by suggesting that Carmack is proposing an alternative to raytracing, when really what he is proposing is a particular approach to raytracing, and, particularly, a particular approach in one well-known problem area in raytracing to which there are currently a whole array of approaches. And his focus on what he wants to get out of raytracing is a little different. But, essentially, his piece, while there are some potentially good criticisms on some particular aspects of and arguments for Intel's specific approach to raytrace, is in accord with (not opposed to) the general idea that raytracing techniques are going to be increasingly important in gaming.
Is that enough "on the merits" for you?
Re: (Score:2)
he pretends that "everyone" is pushing the most naive, brute force approach to raytracing, in which you don't use any kind of bounding volume structure and just do intersection tests against triangles. I've seen literally no recommendations that do that: almost all involve some form of bounding volume heirarchy, and sparse voxel octrees are just one instance of that (perhaps a fairly ideal one, and that's great).
Skimming over the article, I get the impression that he's not rendering triangles:
Now what is different about this versus a conventional ray tracing architecture is that it is a specialized data structure that you can ray trace into quite efficiently and that data structure brings you some significant benefits that you wouldn't get from a triangular structure. It would be 50 or 100 times more data if you stored it out in a triangular mesh, which you couldn't actually do in practice.
Ray casting voxels obviously not a new thing, but perhaps his supposedly new data structure can make it work on next gen hardware.
Re:Stunning! (Score:5, Interesting)
Give me a little credit here. I am not suggesting that everyone blindly intersects rays with a huge list of triangles. That would be absurd, and I assumed everyone understood that. What you might have missed is that I'm not proposing a sparse voxel octree as some form of bounding hierarchy to reduce intersection tests against triangles, I am proposing that it REPLACE hierarchies of triangles or other primitives for some data sets, and this brings about significant improvements (data size) that you wouldn't have with even infinitely fast conventional ray tracing. I'm also not trying to say that this is some novel brainstorm of mine, but I have some practical experience with the direction, and I think it has promise.
One of my major points is that this is all still theoretical. I don't know what is going to be the right architecture for next gen systems. Neither do you, or Intel, Nvidia, Microsoft, Sony, or Nintendo. If I had to place a bet, it is that rasterization will still be dominant, but it is a Good Thing to have lots of people doing research into various alternatives. All the players have their own agendas, but we will all know the big win when we see it.
John Carmack
Re:Stunning! (Score:5, Funny)
acceleration structures, etc... (Score:3, Interesting)
So, it's like a variable-resolution three-dimensional bitmap? I can see how you might reduce memory consumption that way, but it would also reduce the fidelity of the rendered image. I'd be curious to know if the memory-quality tradeoff is better than if you were to just (intell
Re:acceleration structures, etc... (Score:5, Informative)
The data sets for a game world represented like this would be massive, but it is intrinsically well suited for streaming, even over the internet, which may well be the dominant media distribution channel in the timeframe we are looking at.
John Carmack
Re: (Score:3, Funny)
Re:Senor Carmack, one question (Score:5, Informative)
John Carmack
Re:Stunning! (Score:5, Funny)
Re: (Score:2, Interesting)
Um, no. What I meant to say is exactly what I said. My first comment was intended to be dismissive, but not of either Carmack's position or TFA so much as the presentation in TFS. And not because someone other than me is considered a "primary expert" (whatever that phrase is supposed to mean) on this subject, which
primary expert? (Score:2, Interesting)
Carmack is knowledgeable of 3D rendering in general, but that doesn't mean he's an expert on ray tracing specifically, and I found nothing in the article to indicate that he is. He appears to be unaware of a large body of research into the acceleration structures and optimization techniques commonly employed by modern ray tracers (Kd-trees, Bounding-interval heirarchies, MLRTA, packet tracing). He correctly claims that ray tracing is not used much by movie studios, but fails to identify one of the main re
Re: (Score:2)
Re: (Score:2, Informative)
Note I'm not arguing for the Doom3 engine...
Re:How about.... (Score:5, Insightful)
Its his job, and im pretty sure his passion to think about stuff like this.
Re: (Score:2, Insightful)
Re: (Score:2)
Re:Right... (Score:5, Insightful)
Plusses:
- One of the primary fathers of the FPS genre.
- Wolfenstien 3D
- Doom
- Quake 1
- Quake 2
- Quake 3
- Endless articles and commentary on the field
- A shitload of stuff I'm forgetting
Minusses:- "Thought multiplicative lighting was the way to go, rather than dealing with the performance hit of additive lighting in Quake 3."
Conclusion: Carmack sucks!I mean, seriously, what's your point? The man's not actually a God so we shouldn't listen to him? Is there somebody more experienced I should prefer to listen to? Is "n3tcat" the handle for somebody with thirty years experience in first-person shooter engines or something?
Uhhhh... (Score:4, Funny)
Re: (Score:3, Funny)
Re:Right... (Score:5, Insightful)
Many people with years of experience still make god awful mistakes. Experience can only take you so far considering that experience is also the reason why companies stagnate because people get locked into a certain way of looking at things.
Re:Right... (Score:5, Interesting)
You sound like someone that's had the same thought every serious modder/engine-licensee has ever had; "if they could have just included/modified this ONE feature, my game would be feasible/better."
Yet you haven't encountered that phrase enough times to appreciate the fact that engine developers have to draw a performance line somewhere. Your desired feature just happened to be on the wrong side of that line.
Further, engine-developers of John Carmack's caliber would (I promise you this) love to have supported every feature you've ever thought of (and more). John Carmack's always been on the cutting edge, usually refining it. He sometimes makes decisions that are a matter of taste that you can feel free to disagree with him on, but that particular feature wasn't one of them.