If that's really the case, don't even think about 3D graphics yet. Don't even think about graphics yet. Or do, but use something like SFML, and only once you think "okay, i think I can throw together some classes now, and use a library written by someone else". That'll just be 2D graphics, but it's a great introduction to dealing with the concept of backbuffer flipping and general concepts of displaying in a render loop.
Once you get more comfortable with that, rastertek.com starts at the basics of 3d (the 3d equivalent of a "hello world" is a blank render window, followed by a single triangle). That's a Direct3D-based tutorial though.
But if you're still working on being comfortable with language syntax and programming approaches, that's not a good place to start learning 3d graphics. There's just too much foundation lacking for any of the 3d stuff to stick.
Hazard Pay :: FPS/RTS in SharpDX (gathering dust, retained for... historical purposes) DeviantArt :: Because right-brain needs love too (also pretty neglected these days)
Yeah, I am working with coding and (completely ignoring the 3D modeling aspect, thats just something I NOW want to get into doing) when I have wanted to start learning to do that. People have said I need a GUI, an API, I need this topic, I need that topic, it just seems like the amount of "topics I need to start making a game are never ending, and I got overwhlemed to the point I didn't know where the heck to begin.
What you need to do is reduce the scope of what you want to accomplish. Sure, there are like 100 topics you'll need to learn to work as a professional game developer, but right now you just need to learn one thing at a time.
Start with a very simple project... create an app that just sets up the 3d environment (DX example: set up D3DDevice, set default render states, set buffers) and draws a box in world space. The box should be a hard-coded set of points, no texturing. Once you've learned that, learn how to move the camera around with user input. Once you do that you can try texturing, or even play around with shaders. After that you might try to learn a little about collision detection... keep your camera from going through the box. Then you can worry about a data pipeline to load 3d objects from files instead of hard-coding them.
See what I mean? You need to break down the problem into small chunks that you can bite off and digest easily, but that build on each other. Dont worry about everything that's out there, it will only overwhelm you.
Blender environment and support software such as GIMP will keep you busy learning the graphics pipeline for quite a while before you need something else, but of course there are many online sources of information in graphics in general so you need to research it. If you intend to get deep into graphics, then you need a course and/or good books on the subject. Mr. Search is very willing to help you.
Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software. The better the workflow pipeline, then the greater the potential output for a quality game. Completing projects is the last but finest order.
Blender environment and support software such as GIMP will keep you busy learning the graphics pipeline for quite a while before you need something else, but of course there are many online sources of information in graphics in general so you need to research it. If you intend to get deep into graphics, then you need a course and/or good books on the subject. Mr. Search is very willing to help you.
I agree with this statement. I use GIMP for making textures and bump maps, character reference layers etc.. I like them because they're open source and fairly stable. Blender can be a bit buggy with there being so many releases and constant updates but its super powerful. The little Geico lizard is made in Blender lol
If you understand linear algebra then the basic idea is that there is no actual 3D space. There's just vertexes that represent primitives based on their order and the primitive type (the most common primitive type is a triangle -> 3 vertexes). The vertexes are stored in "model space", which is what you're probably messing with in Blender if you're making a model. The pipeline uses 3 matrix transforms on your model's vertexes to get them into position for rasterization (conversion to pixel colors). The first changes the model coordinates into "world" coordinates and also applies scaling and rotation. The second rotates the world space such that the "camera" is at the origin and facing along the z axis. (Note that it's moving the world rather than the camera.) The final transform corrects the perspective, since the viewing angle creates a sort of rectangular cone where the near plane is smaller than the far plane. It basically stretches the theoretical space so that the near and far planes are the same size. This causes nearer objects to appear larger than distant ones. Once this is done it just maps the pixel positions to the near and far plane and then goes through all the primitives, checking to see if a pixel intersects the primitive being rendered. If it does then the point of intersection determines the color to place in the pixel.
Matrices are used to describe these three transforms because once the three transforms are set they can be multiplied together to create a single transform to apply to all the vertexes for the model, greatly reducing the number of calculations that the GPU must perform.
There are a lot of optimizations that exist in most renderers. The most common are probably viewport clipping, depth buffering and face culling. Viewport clipping simply means that stuff outside the viewport gets ignored, which is sensible because you wouldn't be able to see it anyway. face culling is slightly more complex, but modelers should definitely know about this one:
When you create a model you need to know whether to use clockwise or widdershins "vertex winding". Basically what that means is that you want the vertexes for every primitive to be either clockwise or widdershins when viewed from the outside of the model. This is because once a model is positioned for rendering the culling test gets applied. If your program is using clockwise culling then any primitive whose verts are in widdershins order when viewed from the camera position will get dropped, since they're assumed to be facing away from the camera. For instance, imagine a single triangle with verts A, B and C, defined in clockwise order starting at the top. Once the triangle is positioned relative to the camera if the vertexes still appear in clockwise order from that perspective then the triangle is facing the camera. If they've become widdershins then the triangle is facing away and shouldn't be rendered. This saves a huge amount of work for the GPU. If you're making models for someone else then ask them what winding order to use. If you're just making them for yourself then just pick an order and stick with it for all your models for that project (which one you choose doesn't matter).
Finally the depth buffer doesn't really have to do with modelling, but it's a good thing to know about if you're involved with rendering. Basically if you have a 640x480 viewport that you're rending to you'll probably have a 640x480 depth buffer lurking in the background. When the rasterizer finds a collision with a primitive for a pixel it stores the color value in the color buffer and it stores the z depth of the collision in the depth buffer. However, before it does this it checks that z value against the z value for that pixel in the depth buffer. If the comparison indicates that the new color is 'underneath' the existing one then the pixel doesn't get rendered. Because of this it's best to render 3D scenes from front-to-back in order to avoid as many color operations as possible (since the nearer objects will 'hide' rather than 'overwrite' the farther objects). The exception is when you're rendering something transparent, in which case it needs to be rendered after the objects behind it so that it can blend with their colors. Because of this it's good to keep in mind that transparency in models requires a bit more work for the rendering to do. It's not a huge hit but you don't want to get carried away - and let your developer know if you use transparency in a model.
void hurrrrrrrr() {__asm sub [ebp+4],5;}
There are ten kinds of people in this world: those who understand binary and those who don't.
Note:
-This is my personal opinion.
-Don't read this if you're not interested in programming.
My guess would be, and I ALWAYS think that when I want to learn a new aspect of programming or anything like that: buy a book. Really, there's no better way to learn something new.
A few weeks ago I knew almost nothing about graphics programming (DirectX as my chosen API), and right now I know really, a lot. Books are written by people who are (or should be XD) very experienced in a certain field, and the books I've read were all written and explained very well, with many examples etc. The problem with learning something online is that a lot of info is widely spread on many places, and often written by "amateurs" (don't really like to use that word). So after have read some things, you may still have problems. You have to find all the info on many places, and you don't always know where. I know there are a lot of online places to learn about programming, and yes they are often good. But reading a book would be even better, and you will be spending your time more efficiently. Of course, it's still a matter of perseverance. You have to want to learn it. Because, when things get difficult, some people tend to give up.
Anyway, that's just my opinion, books may not be the best way for someone to learn something, but for me it has worked very well so far.
And to finish with, some books that may help YOU on the way (so skipping AI etc.) :)
- Ivor Horton's beginning visual C++ 2012 (I have the 2010 version, but I suppose this one will be even better xd): For the complete beginner in the first few chapters to the more experience programmer in the later chapters. This was my first book I ever read about C++, and it has helped me a lot.
- Introduction to 3D Game Programming with DirectX 11, by Frank D. Luna: I've read a big part of this, but I'm often having problems with it. It's a very nice book to start learning to program in DirectX 11 (and it covers quite a lot!), but not for the beginner. It also covers the basic math for computer graphics (especially in the first few chapters). I don't know any good books for OpenGL (I have the OpenGL superbible, but haven't read much in it yet xd).
I've also read good reviews for the following (will read them soon):
-Mathematics for 3D Game Programming and Computer Graphics, Third Edition, by Eric Lengyel
-The C++ Standard Library: A Tutorial and Reference (2nd Edition), by Nicolai M. Josuttis
That'll keep you busy for a few months or years xd. After that you can specialise in AI, algorithms, networking, ot whatever you want.
Have a nice day :)
Nick
Edit1: Oh yeah, my advice: don't use an engine linke Unity or anything like that. If you really want to learn to program, go hardcore and start from "scratch" in an API like DirectX or OpenGL ;) If you just want to make games, without knowing too much of the technical aspect, you can use an engine.
If you want to learn 3D graphics, the best thing to do (in my opinion) is to just research it online and then follow some online tutorials. In addition, you may also want to consider purchasing a book on the topic as they are often extremely informative, helpful and NOT full of bs. This is my general rule for learning anything really, let me know how goes ;)
