3D Engine 1 - introduction
Hi ! So this is the first part of our long 3D engine series. In advance i'd like to clarify
some facts. Source codes will be written in C (in order to be portable - it's not quite truth
for directX, but i'll be using them only to copy my image to screen so you can replace it with
your favorite graphics interface) Maybe some of you are disappointed. Maybe they're writing
in pascal (you should convert to C !) or they were awaiting some tough hardware accelerated
engine. Almost everything arround here will be software rendering, the last parts will be
about OpenGL, but don't think it's useless ! You can either write your own high-quality
rasterizer (a bit like 3D-Max one) or you will be better understanding principles of 3D and be
able to write better hardware - accelerated engine.
So, let's get back to work. Today i'm not going to write any code, just explain few things. I should say what the 3D engine is. It's program, converting 3-space linear geometrical shapes to raster (so - origin of the word rasterizer) What are "3-space linear geometrical shapes" ? They are mainly polygons. If you played any FPS game, you should know what i mean. Modern commercial engines works with worlds, composed from objects, lights and other stuff. We will focus on these objects. They are made of vertices, connected with polygons. Every polygon is defined with n vertices (n is number greater than 3), but some engines just for simplicity uses triangles (faces). Object, represented by faces is then lit, texturized (covered with some image = texture) and rasterized - and we have our 3D engine ! Eventually it won't be this easy. First problem is our 3D - world is linear space, but we don't sense it much linearly (far objects are smaller than near, etc ...) We also need some system for positioning objects into space. Maybe you experienced rotating vertex arround origin - that's simple, but it won't be enough. Imagine yourself, coding some racing game with only rotation arround origin. You propably find it impossible. So someone clever invented matrices. Every object and camera will have it's matrix, containing it's size, position and rotation. Using matrices you can rotate objects arroud their own origin that moves with them, when translated. So, you have more spaces (more origins -> more spaces) There is objectspace, worldspace and cameraspace (= eyespace). You will transform vertices from their objectspaces first to worldspace or directly to cameraspace, do some perspective correction (far objects will be smaller) and you can draw polygons. Here is a little problem - we can't have too much of polygons if we want to draw images realtime (good animation should have arround 30 frames per second so we have 33.3 mSec for single !) You certainly noticed edgy objects in older games. Today's cards partialy solves that by hardware transformation and lighting (older cards without this capability let this on CPU to do this), but there are lots of methods to reduce necessary polygon count. For example when drawing a spinning cube, you don't have to draw polygons, lying in it's averted side. We say these polygons are backfacing camera. It's propably the simplest way and it reduces arround half of polygons, it's name is backface culling. You simply take the plane of polygon and ... Yes, i propably didn't told you - engines are full of math - so if you get lost dont be afraid to mail me, there is questiion & answer page for every part. You can also get some high-school math book, you will find most of problems inside (i mean rather problem sollutions ;-)) I think it's enough for this time so see your later !
-tHE SWINe-
PS - tutorials will be in microsoft's VC and since this is one-man-show i haven't time to port it to borland C / DJGpp ... sorry
So, let's get back to work. Today i'm not going to write any code, just explain few things. I should say what the 3D engine is. It's program, converting 3-space linear geometrical shapes to raster (so - origin of the word rasterizer) What are "3-space linear geometrical shapes" ? They are mainly polygons. If you played any FPS game, you should know what i mean. Modern commercial engines works with worlds, composed from objects, lights and other stuff. We will focus on these objects. They are made of vertices, connected with polygons. Every polygon is defined with n vertices (n is number greater than 3), but some engines just for simplicity uses triangles (faces). Object, represented by faces is then lit, texturized (covered with some image = texture) and rasterized - and we have our 3D engine ! Eventually it won't be this easy. First problem is our 3D - world is linear space, but we don't sense it much linearly (far objects are smaller than near, etc ...) We also need some system for positioning objects into space. Maybe you experienced rotating vertex arround origin - that's simple, but it won't be enough. Imagine yourself, coding some racing game with only rotation arround origin. You propably find it impossible. So someone clever invented matrices. Every object and camera will have it's matrix, containing it's size, position and rotation. Using matrices you can rotate objects arroud their own origin that moves with them, when translated. So, you have more spaces (more origins -> more spaces) There is objectspace, worldspace and cameraspace (= eyespace). You will transform vertices from their objectspaces first to worldspace or directly to cameraspace, do some perspective correction (far objects will be smaller) and you can draw polygons. Here is a little problem - we can't have too much of polygons if we want to draw images realtime (good animation should have arround 30 frames per second so we have 33.3 mSec for single !) You certainly noticed edgy objects in older games. Today's cards partialy solves that by hardware transformation and lighting (older cards without this capability let this on CPU to do this), but there are lots of methods to reduce necessary polygon count. For example when drawing a spinning cube, you don't have to draw polygons, lying in it's averted side. We say these polygons are backfacing camera. It's propably the simplest way and it reduces arround half of polygons, it's name is backface culling. You simply take the plane of polygon and ... Yes, i propably didn't told you - engines are full of math - so if you get lost dont be afraid to mail me, there is questiion & answer page for every part. You can also get some high-school math book, you will find most of problems inside (i mean rather problem sollutions ;-)) I think it's enough for this time so see your later !
-tHE SWINe-
PS - tutorials will be in microsoft's VC and since this is one-man-show i haven't time to port it to borland C / DJGpp ... sorry
Valid HTML 4.01