Triangles to Pixels - Computerphile 

***** everyone thinks their voice is horrible

My assumption based on no knowledge on the subject at all is that the computer determines what percent of triangle would be filling that pixel. To keep things easy for myself, its a black triangle with a white background, with 100 shades or color as the total range. If the triangle is only 50% in the pixel, the pixel will be perfectly grey. If theres more triangle in the pixel, it'll be darker grey. This is why in Microsoft Paint, the greatest graphic creation program of all time, if you type a fancy font with nice soft edges, then try to paint it a different color, only the middle of the letter will be painted, as the outer edges are all slightly different shades of the former color

Personally, i'm looking for video of shaders too.. I'm precisely at that point of learning curve myself...

i really wish an episode about shaders

He already kinda covered normals and culling in his last video (about triangle vertices). He doesn't go into explicit detail, but he talks about how triangular vertices are always co-planar, and how we can determine front/back facing through the way we list the order of those vertices. Those pieces of information (and you know, the vertices themselves) are all you really need to calculate normals, and by extension perform back face culling. (Actually, he does explicitly mention back face culling in that video).

I'll share some of the math and routines I wrote long ago. I would suggest exploring Java3D and OpenGL APIs. ;)

Thanks!

any example of calculation? or any site you know whith an example, thanks

Clerison Campos Apologies for the late reply. Here's an excellent tutorial on perspective projection, and how to implement matrices to do the same thing more efficiently: www.scratchapixel.com/lessons/3d-advanced-lessons/perspective-and-orthographic-projection-matrix/perspective-projection-matrix/

My guess (but I don’t know much about this): get the spherical coordinates of every object relative to the camera, each of the two angles is a 2-D coordinate in a plane with the middle of the screen as its origin.

Nicolas M. Mostly we're using matrix multiplication to make these transformations. www.songho.ca/opengl/gl_projectionmatrix.html here's the explanation of the matrix used to do this in OpenGL

Its called rasterisation, en.wikipedia.org/wiki/Rasterisation

ok well after a bit of searching i found a helpful link, so anyone _else_ who wants to know can try this, although you do need a knowledge of algebra and geometry, and basically maths in general: www.scratchapixel.com/lessons/3d-advanced-lessons/perspective-and-orthographic-projection-matrix/perspective-projection-matrix/

The beauty of matrices is that you actually don't have to do everything! Matrices allow you to clump together all the different transformations so that you end up with only a couple of multiplications and additions per vertex.

***** Yes exactly, but despite of that the number of calculations is still mindnumbing. Take for example the number of times per second the pixel shaders are run on a 1920x1080 60 Hz display.

pixel = 2D picture element (screen) voxel = 3D volume element (3D equivalent of pixel) texel = 2D texture element (essentially, the "pixels" that make up a texture) Texels are mapped onto the surface of the triangles, and then projected onto the screen as pixels. Voxels are the solid equivalent of pixels, and must be mapped and projected onto the screen just as any other 3D object would be.

hey thanks buddy. clean and simple :)

There's a funky thing that happens with the projection matrix. Technically, he did explain it, but in a very round about fashion. In simple terms, to convert 3D coordinates to 2D space, you divide the X and Y coordinates by the Z coordinate. This gives you an orthographic representation of the vertices on a 2D plane (the screen). Very simple explanation, but that's the absolute basic idea behind it. In the real world, this is done with another matrix calculation. You remember how earlier in the series he explained how matrices worked, with all the rules of multiplying and adding various columns? Well, if memory serves me right, there is also a /divide/ operation that wasn't mentioned at that time. All the view information (viewport size, field of view, etc...) is compiled into a single matrix. This matrix, again from memory, applies perspective to each vertex, crunching them down into a 2D plane, and converts the vertices into screen coordinates (actual pixel coordinates). Then, the polygons are rasterized (drawn).

He did cover it but it might have been hard to catch because there wasn't much time wasted about it. He said that a simple projection transformation is literally to just discard all Z coordinates of your triangles entirely and you're done. If you went a sense of depth too then the X/Y coords also need to be scaled down by whatever factor you want based on the Z distance you threw away (x/z, y/z like DarkLord just showed)

The trick for getting that divide in a matrix is to go back to the same trick we used for translations, where we've got an extra 1 at the end of the vector, and come up with what it means for a point to have other numbers there. We say that (x, y, z, 1) is the same point as (2x, 2y, 2z, 2) or (10x, 10y, 10z, 10). That is, if you want to reduce a four-number vector to a three-number location, you don't just drop the last number, you divide by it. Then your perspective transform just copies z into the last spot, which turns a point (x, y, z, 1) into (x, y, z, z), which is (x/z, y/z, 1), which is what you want (as others have said). The point of doing this transform is that you can decide whether you want a perspective camera or an orthographic camera (objects don't shrink with distance) by choosing which matrix you use. This is important because your hardware will be set up to do two matrix multiplies and the special divide to every point you give it. So, for every point, you say its local coordinates are and what object it's part of. For each object, you say its world transform. You also say the camera transform. Then the hardware gives you screen coordinates for every point. You don't have to tell it what sequence of operations to do, because that's going to be the same for every scene that every program renders. (In general, computer stuff gets much much slower when you have to tell it what to do, rather than only telling it what numbers to use, which is why hardware 3D is so much faster than software 3D.)

There's an earlier video in this series on this channel that goes over some of the linear algebra techniques used to perform scale/rotation/translation transformations. Pretty much everything is achieved using some combination of those transformations.

Dör Is there's a few ways of doing that but a common one is for each pixel the computers draw an imaginary line either to the left or right. if this line crosses 2 sides of the triangle the pixel is outside the triangle. if the line only crosses one side of the triangle then it's inside. I think this is called scanline rendering, but not sure about that. And yes, for every pixel and furthermore, every pixel against every triangle (not account for optimisations, culling etc).

Yeah, and then import the models into Unity to actually build a game. Also free...

The way I understand it, it's so you don't actually have to analayze every single pixel. By clipping, you can get it down to just the vertices and then just auto fill everything in between them.