But I think it's worth considering that:
- "Pixel" is an overloaded term. "Pixel" is a little square, sometimes, because common law - it's being used that way.
- This is an article about art, aimed at artists, and if an artist intends to create a blocky image in two or three dimensions, then what they're doing is "correct" regardless of the terminology they use.
- The pictures are really pretty, IMO. I realize some people don't like the block look, but I'm not alone when I say I love it and it's inspiring. The explanations in the article were nicely done.
- The article does cover sampling. Just not filtering.
- When Alvy Ray wrote his paper, the world was made of blurry CRTs. Now we have really crisp digital LCDs everywhere, and more now than then, pixels on the screen are little squares.
- "pixels" even in the days of CRTs have always meant little squares to a lot of people. Video game art benefitted from a little blur, but tons of artists and programmers have always thought of pixels as squares, and for the most part it's a working analogy.
This is why it's okay to call a pixel a little square, and overly rigid to claim it's not one. (And I think Alvy Ray was being funny and making an important point about math and graphics, for a siggraph audience, not pedantic about what words artists are using.)
Yes, so technically we should probably call the modern rendering technique of pixels and voxels block-based rendering. I would say though it's fair game to call the underlying data "pixels" and "voxels" - in most retro-style games these assets are indeed stored internally at that level of abstraction. The issue now becomes how to render that data on the screen, and blocks are still a way to make this data look good.
While the block is not a pixel or voxel in the strictest sense, I do think it's a reasonable linguistic shortcut to use that word in this context, and it's not unprecedented to use the description of an abstract thing interchangeably for its more concrete representation.
In my opinion, there is nothing to freak out about, and I don't see why this article specifically prompts such a needlessly absolutist response.
As others have said, 8-bit art was made in a context where the "pixels" were viewed through an analogue filter, that being an NTSC display. My understanding is that to a first approximation, such a display (i.e. the electron gun + shadow/aperture mask) acts as a spatial lowpass filter with a resolution of 640x480 pixels, with maybe a 1-pixel-wide horizontal "smearing" effect due to the horizontal movement of the gun. Of course various console + display combinations deviate wildly from this ideal, but the lowpass filtering is the basis for understanding how 8-bit art was expected to be viewed.
I just refer to them as "boxels."
I wonder though, would a lot of 'pixel art' actually look better with a different filter instead?
But once you're in 3 dimensions, triangles do a much better job of approximating arbitrary shapes (also, hardware deals with triangles), plus the voxel dimensions have no relationship to your display. You're essentially picking a very clunky filter that obscures what you're trying to represent, out of some misguided analogy to 2D pixels.
Just to be clear, cubic voxels can be great as a stylistic choice, but are inferior to triangles as a general way to describe 3D scenes.
Rather, it is only an infinitesimally small point (an "impulse" or Dirac delta) which, when grid-aligned and ideally filtered, can rasterize as a single pixel.
The basic problem with being petty is that, while you're right on one level, you're wrong on the global scale. In this case, that pixel are square or not is irrelevant. Do you look at your monitor straight on? Do you sit side-by-side with a friend playing a game? In that case, squares become trapezoid from your POV anyway. I'm going to bet you don't mind it, because our brain is very good are pretending perspective distortions don't exist.
The same apply in many domains: color correction, for example. I use to write in printing and designers would be hung up on proof to verify colors. No matters that reader would read teh final product under varying lights anyway, making precisely 'correct' colors moot.
In both cases, what is important is consistency. For prints, that all runs be the same. For monitors, well, as long as you look at a single monitor at a time, you won't notice distortion.
(In a somewhat related anecdote, the piano my parents own is and always has been out of tune. I learned on it and for me, all other pianos tones were unsufferable. What is the right pitch is mostly learned, even though musicians would like us to believe there is but a single harmonious scale.)
In modern pixel/voxel art, however, the whole point is that they are in fact little squares and cubes. Otherwise you don't get the aesthetic this style is aiming for.
It should be noted for historical accuracy, that the origins of pixel art were displayed on relatively blurry CRT screens, and your pixels didn't actually look like little squares either, more like glowy blobs. That's a different point than the cited paper is making, however, which is about the sampling theorem where pixels and voxels are basically data points (that can be interpolated in various ways).
On the other hand, when I played 16 colour 320x200 games like Commander Keen and Duke Nukem (2D) in the 90s on a VGA CRT monitor, the pixels definitely looked like little squares, not blobs.
Edit: maybe I should mention the oldschool ANSI art as well (BBS/demoscene), which were made with various coloured ASCII-blocks, and there the "pixels" were in fact quite obviously little blocks (and sometimes other characters but that's more ASCII-art than ANSI).
There is a fair amount of graphics whose good looks are based around the fact that pixels are little squares. Like orthogonal lines.
What you want is a non-linear filter - it's pretty obvious that you can invent good upscaling filters (like Waifu2x / NNEDI3) that aren't based on FIR theory and can't be used to downscale.
> Or, you could say, the smaller I want filter regions to be.
And that's the opposite of you get from linear filters. There's a resampling filter called sinc that's "perfect" - it reproduces every frequency in the input signal - but it looks terrible for images because it tries to reproduce pixels based on every other pixel in the image. So you get ringing all over the picture instead of sharpness.
But your intuition isn't wrong. Nearest neighbor can be a bit more "crisp" feeling on certain images, especially natural photos. A lot of photos have enough blurriness in the 1-3 pixels range that nearest neighbor sampling is a good choice if you're just resizing an image by a factor of 2.
But to see why nearest neighbor isn't the best in general, imagine down-sampling a checkboard and what happens as individual checkers become smaller than a pixel. You'll get moire patterns if you don't filter. You'd also expect pixels to turn grey as multiple checkers land there, and maybe not stick to only black or white.
Interestingly, some "sharpening" and up-sampling algorithms do the opposite - they subtract the value of surrounding pixels, rather than add. Those are assuming that some averaging already took place, and trying to un-average, if you will, to restore the original point sample.
The long answer is... really long.
I wonder how far someone could get with that artstyle in general, I haven't seen it that often. There was that RTS game that used it, forgot the name..
Screenshot: http://cdn.dbolical.com/videos/games/1/19/18851/planetary-an...
Do you mean 8 bit armies? [0]
That one looks pretty cute, too, though. :)
Odd that people suggest making it "better" with polygons, as if you're stuck with voxels, as if you didn't choose it consciously, as if you didn't already understand the alternatives. :) Ignore it and keep making awesome games.
For example, voxels can't represent non-right-angle surfaces without adding jagginess, while a triangle can.
(Naturally, one can model a system as a grid but render it as arbitrary shapes, or vice-versa.)
The best thing about voxels is what you can do with fluid simulations.
In Maya you could create a cube made up of voxels, each voxel had a fuel, temperature etc variables.
You could start a fire from a single voxel, and watch is spread ! Changing the values could make the fire behave differently.
I wish front-end javascript was that cool :( fire simulation on a computer is so much more fun.
FDS and SmokeView, are the defacto fire simulator tools used by fire protection researchers/engineers around the world. Not only can you manipulate the fuel sources, you can manipulate the environments and rooms and watch the fluid and thermodynamics dynamics happen. Radiation, convection, conduction, flow gradiants, for you to see and play around with.
http://www.thunderheadeng.com/pyrosim/
Is a nice gui layer for FDS allowing you to import CAD files for your simulations and gives you some visual control rather than programming in Fortan for FDS.
I learned SpriteKit and Swift for fun and started making games with my kids. So rewarding and a nice break away from real world programming. But not something I would want to do for a living.
Until that night I hadn't even imagined that holograms would ever become a reality, and I had also never heard of voxels. It really made an impression on me. I hope they succeed in making their machine viable for consumers because I could tell how passionate they are about it, and how hard they've been working.
Essentially, the object to display is sliced up like you do for 3D printing, and a screen of some sort is moved to the lowest Z position, and the bottom slice is projected up onto it.
Then, the screen increments it's Z position, and the next slice is displayed, repeating until the entire object has been displayed.
Thanks to persistence of vision, it appears as though the image is 3D and floating.
The control scheme was a weird mix of simulator and shooter.
In Minecraft, the drawing primitives are triangles, the map is made of cubic tiles, and the detail is in the texels.
I've always disliked the use of the word voxel when talking about Minecraft, because I think it applies too loosely. They are mostly map tiles.
Also, it's not necessary to take the displayed path, i.e., triangulate a voxel-based representation then use vector-oriented rendering methods to get the displayed image. There have been lots of work rendering a 2d display by ray tracing through voxel space or even directly splatting voxels into display space.
A lot of research has been directed into efficient representations for large collections of voxels. One really cool sparse volume system, OpenVDB, was open sourced by DreamWorks: http://www.openvdb.org/. Nvidia has papers on sparse voxel octrees that work very well on GPUs: https://research.nvidia.com/publication/efficient-sparse-vox...
They can also contain meta information, like color and transparency.
To represent pixels or voxels on a screen you need to to render and interpolate them. Because, if you have an image of 4 pixels that you would like to show on a screen with 1080 leds, you need to interpolate the meta data between those pixels.
