Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 17 Apr 2012
Offline Last Active Jun 26 2014 08:34 AM

#5162451 Help on learning OpenGL! (Especially perspective projection)

Posted by on 23 June 2014 - 07:58 PM

I'm going slightly mad on this.


I've been trying to learn OpenGL. I've never learnt 3D programming / math (in a very solid way, anyway). I do know some basics about vectors, matrices, matrix multiplication, the identity matrix, how matrices store rotations, scaling and other transformations. I've read a couple hundred pages from 3D Math Primer for Graphics and Game Development, but that was at least a year ago. Furthermore, I guess there probably are some gaps in my 3D knowledge.


Lately, I tried to learn OpenGL through the Red Book. However, the book isn't very beginner-friendly. So after googling for a while I tried to learn from the arcsynthesis.com tutorials. I was doing very good until the perspective projection tutorial (http://www.arcsynthesis.org/gltut/Positioning/Tut04%20Perspective%20Projection.html). I don't get all that math on the "Camera perspective" section, tbh I think it's poorly explained (the rest of the tutorial is top-quality, though, gotta be fair).


From arcsynthesis I jumped to scratchapixel.com. The perspective projection matrix lesson (http://scratchapixel.com/lessons/3d-advanced-lessons/perspective-and-orthographic-projection-matrix/perspective-projection-matrix/) got me understanding things a bit better, but I'm starting to get really confused as scratchapixel.com and arcsynthesis.com seem to take slightly different approaches.


From what I understand, the homogeneous coordinates (as scratchapixel.com calls them) are acquired by dividing x,y and z by w. Those will then be the NDC (normalized device coordinates, as arcsynthesis calls them), right? Arcsynthesis seems to say that we "prepare" the perspective projection by setting the correct w coordinates for each vertex and letting the hardware do the rest:



The basic perspective projection function is simple. Really simple. Indeed, it is so simple that it has been built into graphics hardware since the days of the earliest 3Dfx card and even prior graphics hardware.

You might notice that the scaling can be expressed as a division operation (multiplying by the reciprocal). And you may recall that the difference between clip space and normalized device coordinate space is a division by the W coordinate. So instead of doing the divide in the shader, we can simply set the W coordinate of each vertex correctly and let the hardware handle it.

This step, the conversion from clip-space to normalized device coordinate space, has a particular name: the perspective divide. So named because it is usually used for perspective projections; orthographic projections tend to have the W coordinates be 1.0, thus making the perspective divide a no-op.


Suffice it to say that there are very good reasons to put the perspective term in the W coordinate of clip space vertices.


However, the same Arcsynthesis states:


Recall that the divide-by-W is part of the OpenGL-defined transform from clip space positions to NDC positions. Perspective projection defines a process for transforming positions into clip space, such that these clip space positions will appear to be a perspective projection of a 3D world. This transformation has well-defined outputs: clip space positions. But what exactly are its input values?

We therefore define a new space for positions; let us call this space camera space.

...then it proceeds to explain how to feed the clip space with already-processed vertex coordinates (in a way that gives the sense of perspective). I'm confused... Isn't that effect achieved by setting the correct w values for the perspective divide, which happens during the conversion from clip space to NDC???


Scratchapixel.com, on the other hand, defines the perspective divide as some sort of process of making w equal to z, so that dividing the coordinates by w will simultaneously make them homogeneous and fit into the z = 1 plane (which is considered the image plane in their example, or projection plane as arcsynthesis calls it).




Also remember from the beginning of this lesson, that point Ps, i.e. the projection of P onto the image plane, can be computed by dividing the x- and y-coordinates of P by its z-coordinate. So how do we compute Ps using point-matrix multiplication? First, we set x', y' and z' (the coordinates of Ps) to x, y and z (the coordinates of P). Then we need to divide x', y' and z' by z. Transforming x', y' and z' into x, y, and z is easy enough. First set the matrix to the identity matrix (The identity matrix is where the pivot coefficients, or the coefficients along the diagonal of the matrix, equal 1. All others coefficients equal 0). But why do we divide x', y' and z' by z? We explained in the previous section that a point expressed the homogeneous coordinate system (instead of in the Cartesian coordinate system) has a w-coordinate that equals 1. When the value of w is different than 1, we must divide the x-,y-,z-,w-coordinates of the point by w to reset it back to 1. The trick of the perspective projection matrix thus consists of making the w'-coordinate in Ps be different than 1, so that we have to divide x', y', and z' by w'. When we set w' to z (z cannot equal 1), we divide x', y' and z' by w' (which is equal to z). Through division by z, the resulting x'- and y'-coordinates form the projection of P onto the image plane. This operation is usually known in the literature as the z or perspective divide.


So technically, the perspective projection occurs from the conversion from clip space into NDC, NOT before feeding the clip space coordinates (as arcsynthesis stated)! Am I right?


Things are starting to get really messy in my mind, and I'm wondering if I should just pick a textbook on this subject and learn it all the hard way. Subsequent concepts mentioned by scratchapixel.com like far view and near view are also unclear to me, though there are previous tutorials on scratchapixel.com that should enlighten me about those. The question is... should I keep on hopping from place to place to figure out stuff one thing at a time, or would I better grab a textbook? If so, which one?


Any help would be very appreciated. This is starting to harm my motivation to learn OpenGL. It really gives the sense of overwhelmingness (just made up a new word).

#5160946 Re-learning C++ and some help with learning it.

Posted by on 16 June 2014 - 06:07 PM

Hi, Zero_Breaker. I feel exactly like you. And I understand why you feel so demotivated. The thing is, you're probably (subconsciously, anyway) thinking you'll be learning all this C++ again and forget it again soon. Other reason for your low morale is you don't get to see results of what you've learned. Finally, the third factor is probably you don't feel trully commited to the whole process of digging in, learning and doing.


Programming is a very, very demanding task. You have to learn C++ (considering your approach now). Then, you need to learn 2D/3D math. Then you need to learn how to use a graphics library (OpenGL, or SDL, or a 3D engine...). In the meantime you need to learn how a game is actually coded - the logic of the game loop, how to integrate several source and header files, how to organize the whole code... The list goes on and on.


Don't feel guilty because you're not getting to the finish line. It does take a long, long time. The important thing here is you like the journey, not just the final destination. I'm saying this but I'm on the same boat... I also keep getting lost on what to do next, what to learn next. Maybe we could learn together? I'm sure it would boost the heck of our morales, to share thoughts, maybe even programming stuff together?


If anyone else reading this is on the same boat, drop me a msg or reply to this topic, maybe we could gather a "beginners" group to keep everyone motivated and to help each other learning stuff.


That being said, and replying to your post, I'd say the book you chose (C++ Primer 5th Edition) is a very, very good choice. It's the book I chose too. It gets very deep into C++, and it may be tiring to finish it, but believe me, it will be worth it. It helps to really understand how C++ works. It will help you to avoid magical bugs and compiler warnings/errors popping out of nowhere because you will trully master the dirty details of it all. So be easy on yourself. You're going the right path, but it's also the hardest one. My approach to your problem (feeling demotivated, bored...) was this: taking notes on the details that will most probably be forgotten in a couple of days (because they're not used enough) but represent potential pitfalls when it comes to code. I made a kind of personal "cheat sheet" with some 15 pages of notes about everything I'll need to remind myself of when I want to code. The book itself has over 1000 pages iirc, so bringing it down to 15 pages is a major sense of accomplishment by itself. Heck, I'll share my cheat sheet with you if it helps you, no problem :)


Concerning the bookstore stuff, I can help you with that if you want. Send me PM if you're interested


Cheers ;) 

#5118467 Fellow beginner game programmers

Posted by on 20 December 2013 - 07:10 PM

I'd enjoy programming with other people while we learn, and/or share ideas and thoughts. [snip]
Who's interested? You can add me on skype, my email is [deleted]
I've tried posting this in the classifieds but didn't get replies, so I'm trying here now, [snip]

#5117636 Please tell me there's a way to set line width in SDL

Posted by on 17 December 2013 - 01:09 PM

I can't find a way to set a line width for the SDL_RenderDrawLine function, but I can't believe there's no way to set it. That's just... basic. Is there really no way to do so? Are the lines always 1 pixel wide, or what?


EDIT: Found an extension library (SDL_GFX) that provides that feature. It's wierd native SDL doesn't have that, though...

#5115360 Completely overwhelmed - should I just give up?

Posted by on 08 December 2013 - 07:39 AM

Thanks for all the input! It's helped a lot. Yeah, I think I should drop books and start making some simple games with C++ and SDL. As for dropping C++ and using a simple language, I think I'd rather take advantage of the huge effort I made when I learnt C++ thoroughy, so that doesn't go to waste. 


I just graduated (my professional field has nothing to do with computers whatsoever btw), so in a couple of months I'll start working and I'll buy a laptop with a better GPU. So the OpenGL 2.0 restriction shall fade away soon, I hope. In the meantime I may just take baby steps with SDL + pong / pacman / tetris clones, etc. 


Indeed, my goal is actually to turn my game ideas into reality. Therefore I might consider using a game engine, or at least a higher-level graphics engine...


Btw, one of my game ideas was deliberately simple: it's a 2D multiplayer soccer game played online with the mouse + keyboard, like netsoccer  (http://www.youtube.com/watch?v=lrzN4_rkziw) and soccer kiekko (http://www.youtube.com/watch?v=WfAd92Eo8Wc). I believe I'd only need to learn SDL and netcode. Am I right?


Again, thanks for all the advice smile.png

#5115268 Completely overwhelmed - should I just give up?

Posted by on 07 December 2013 - 10:00 PM

Hey there. I'm posting this for some motivation guidance, more than for tehnical advice. Please don't see it as a rant, it's more of getting some stuff off my chest while I explain my question.

Here's the thing: I've been learning to program games for about a year. What really got me fired up for it was a couple of exciting game ideas I had (no, no MMORPG LOL). Since I'm a relatively reasonable guy I wouldn't expect to tell someone to do the heavy lifting for me, I realize the world is full of so-called "great ideas"... So I started by picking up C++ again about a year ago (I had already learnt C++ basics a long, long time ago). I took it seriously - by this i mean no shortcuts - so I read C++ Primer. That's a huge but excellent book, as I really understood C++ deeply with it, but it also took me a long time to read (I read it thoroughly, taking notes, making sheets for memorizing and personal reference, etc). By a long time I mean i just finished it a couple weeks ago.

After C++ and a lot of "fishing" (searching the web and looking by trial and error for a right approach to learning game programming), I went on to SDL, as it seemed like a very good place to start to learn the game design/coding principles. SDL 2.0 came out recently, so tutorials to learn this version (which includes hardware-acceleration) are pretty scarce. Anyway, I found a book named "SDL game development" that uses SDL 2.0. So I picked that one up too.

I realized that, even though I was able to write custom classes and all that jazz according to the principles taught in the SDL book, learning SDL seemed too much of a detour for something that only handles 2D. "Maybe I could just get on with it and jump straight into OpenGL, which does SDL stuff and much more", I thought to myself. Besides, the fact that I was staying clueless as to how to implement 3D and even 2D on some subjects started to bug me.

So I looked for a good place to learn OpenGL. Being life as it is, my computer only supports up to OpenGL 2.0, which uses fixed pipeline (for whatever that is lol) - a feature that is either tolerated or hated to death by people who discuss it... Anyway, found some good sources to learn OpenGL... I had already picked some information here and there about vectors, matrices, but besides that I was in complete darkness. So when I was learning OpenGL, I was pretty much learning the API without knowing how 3D math actually works. Not very useful...

So I decided I should get some solid grounds on 2D/3D math too. So I put SDL and OpenGL on hold and looked for good books on that subject. "3D Math primer for graphics and game development" seemed like a very good book, and reviews were good too. So I started reading this book a couple of days ago.

Now I'm reading an 800 pages book that teaches math 3D thoroughly until I'm grabbing my hair and tearing it out lolol...

I must admit it... I'm getting burnt out, demotivated and downright lost in the middle of all this learning process. It's just too much to be done single-handedly... I need to know 3D math, then SDL, then either OpenGL or a graphics API like Ogre 3D, then Blender in order to make the models, then God knows what else... In my life I've learnt to play the guitar all by myself, to write and manage a blog all by myself, I've learnt a lot about guitar equipment all by myself, but learning to make games seems too much to bear. Maybe I'm tired of pushing so hard on myself...

Recently I've joined a team of programmers and contributed a bit as a game designer. I wrote a Game Design Document (it wasn't 100% finished, but it was well on its way), so I got a grasp of how a GDD needs to be written, etc. On that team, one of the hardest parts was to find 2D artists - it was so hard that the project was actually shifted to 3D because there seems to be more 3D artists than 2D ones. That also contributed to my shift to OpenGL after some SDL experiments...

So my question is: Should I just give up? I really enjoy the game ideas I have in mind, but I'm starting to believe I simply can't pull it off... On the other hand, I'd be glad to write a thorough Game Design Document for each game idea, and if I could get some folks to help me out I think the games would have some success. But... Is it realistic to expect some people to join me and pick up the GDD and get things started? Because right now that seems like the only way out...

TL;DR - I have some exciting game ideas in my head (none of them are MMORPGs, lol). So to get my hands dirty I've learnt C++ thoroughly during the last year. Then I started learning SDL, but shifted to OpenGL to know more 2D and 3D. I needed 3D math background for OpenGL, so I started learning 3D math from a book - it's boggling my mind after so much self-teaching... So I'm getting burnt out, demotivated and lost. Should I
A) give up my ideas,
B) change my approach to learning game programming (if so, how? Give me some advice, pls)
C) write a Game Design Document and try to get some folks interested in joining my project?