OpenGL in 10 days !?!?!

Started by
6 comments, last by Zakwayda 12 years, 12 months ago
Hi all,

As the topic says I really want to get the hang of OpenGL in 10 days. I am a newbie but trying to understand OpenGL for some months now. However I do not seem to get it and not confident to write program from scratch.

For now I want to get something working in OpenGL 2 and then move on to GLSL for my final project in the university.

Nehe tutorial ? or what resources on internet I should follow. I have ordered OpenGL superbible 5th edition from amazon so it should be in my hands in 4 days but I would like to know how you guys learned OpenGL programming ?

I want learn how to handle your own matrices ???, how does modeview matrix actually work. How to render and move things in 3D. I do not think I completely understand it TBH.

Please help
Advertisement
its not going to be 10 days but rather at least a year:) (or more, from personal experience)
you might read the bible 5th edition in a month or so, but that's unlikely and even after reading you'll have to practice a LOT until you get comfortable with it and deal with your own ideas.
even after doing the aforementioned practice you'll likely run into lot of problems, that usually will come from not being experienced enough.
to add, if you aren't comfortable with C++ than it will likely take much longer time to accomplish this.

I'm not trying to persuade about don't start to learn OpenGL, but I'd like to emphasise that it will take a long-long time to get to the end of it
NeHe is probably one of the faster ways to get something up and running, and it shouldn't take too long to make some working prototypes.

Actually completing a more advanced game, or learning all the internals, will take a long time. I wouldn't recommend starting with learning the math if you want to see quick results, unless you already have a very solid university math background.

I want learn how to handle your own matrices ???, how does modeview matrix actually work. How to render and move things in 3D. I do not think I completely understand it TBH.


Two simplifications:
A matrix describes a coordinate system, the columns are x,y,z and origin. That's all there is to it (unless you add scaling or shearing). Don't worry about mathematical details of what happens when you multiply, just think "M = A*B" means "apply transformations in A after applying transformations in B". The result can still be directly read as coordinate system.

The mysterious w-coordinate on vectors can be thought of like this: w = 0 -> direction vector, w = 1 -> position vector (yes, it applies to matrices, the axes have w=0, the position/translation has w=1). If you do the math yourself you will see how it removes the translation part when multiplying with a matrix and when you look at GLs lighting model you will see how it makes the difference between a point light and a directional light.


More bla:
OpenGL is actually hiding stuff in a way that is both convenient and confusing. glRotate isn't magic, it just creates a rotationMatrix and does modelview = rotation * modelview. Same with glTranslate. D3D forces you to do it yourself, so you can't ignore what really happens. Seems more tedious, but ignorance isn't always bliss (look at the kind of questions arising from trying to achieve everything with these to glCursed functions). You want to forget about them if you handle your matrices yourself. If you don't move the point of view (or "camera", though technically such a thing doesn't exist) you can just directly glLoadMatrix your objects matrix and render it. Else you first need to apply the inverse of your "imaginary" camera's matrix (and yes, it simply transforms everything rendered afterwards -aka "the world"- in the opposite way).


"How to render and move things" suggests a wrong order. You can't move stuff after rendering it (it's just a bunch of pixels in the frame buffer now). First you setup your matrix to have it drawn in the right place, then you render. If you move it, you use a different matrix when drawing the next frame.
f@dzhttp://festini.device-zero.de
Thanks for reply all. Yeah I will go through tutorials as it is defintely faster way to get things moving. Reading booking and practising will definitely take months.


[quote name='playstation' timestamp='1302883778' post='4798822']
I want learn how to handle your own matrices ???, how does modeview matrix actually work. How to render and move things in 3D. I do not think I completely understand it TBH.


Two simplifications:
A matrix describes a coordinate system, the columns are x,y,z and origin. That's all there is to it (unless you add scaling or shearing). Don't worry about mathematical details of what happens when you multiply, just think "M = A*B" means "apply transformations in A after applying transformations in B". The result can still be directly read as coordinate system.

The mysterious w-coordinate on vectors can be thought of like this: w = 0 -> direction vector, w = 1 -> position vector (yes, it applies to matrices, the axes have w=0, the position/translation has w=1). If you do the math yourself you will see how it removes the translation part when multiplying with a matrix and when you look at GLs lighting model you will see how it makes the difference between a point light and a directional light.


More bla:
OpenGL is actually hiding stuff in a way that is both convenient and confusing. glRotate isn't magic, it just creates a rotationMatrix and does modelview = rotation * modelview. Same with glTranslate. D3D forces you to do it yourself, so you can't ignore what really happens. Seems more tedious, but ignorance isn't always bliss (look at the kind of questions arising from trying to achieve everything with these to glCursed functions). You want to forget about them if you handle your matrices yourself. If you don't move the point of view (or "camera", though technically such a thing doesn't exist) you can just directly glLoadMatrix your objects matrix and render it. Else you first need to apply the inverse of your "imaginary" camera's matrix (and yes, it simply transforms everything rendered afterwards -aka "the world"- in the opposite way).


"How to render and move things" suggests a wrong order. You can't move stuff after rendering it (it's just a bunch of pixels in the frame buffer now). First you setup your matrix to have it drawn in the right place, then you render. If you move it, you use a different matrix when drawing the next frame.
[/quote]

Thanks, I was looking at some matrixes and it is definetly confusing. OpenGL handles so I guess we do not have to worry about it. I like your example M= A*B and how OpenGL handle matrix in reverse order. I am not sure about the model and view matrix. Model handle from objecr space to world space and view from world spcae to eye space. It is confusing

Thanks, I was looking at some matrixes and it is definetly confusing. OpenGL handles so I guess we do not have to worry about it. I like your example M= A*B and how OpenGL handle matrix in reverse order. I am not sure about the model and view matrix. Model handle from objecr space to world space and view from world spcae to eye space. It is confusing


If you're a university student try to take linear algebra, it helps alot.
[size="1"]I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

Nehe tutorial ? or what resources on internet I should follow. I have ordered OpenGL superbible 5th edition from amazon so it should be in my hands in 4 days but I would like to know how you guys learned OpenGL programming ?


Maybe you know this already, but be aware that NeHe uses the old fixed pipeline of OpenGL 2, but the Superbible 5th edition uses OpenGL 3.3. Assuming that you're just starting out, this can be very confusing because the book will not use most of the functions found in NeHe's tutorials as they are deprecated. Everything is done with shaders in the Superbible and that is why the author provides the GLtools library. Basically the GLtools is providing the functionality from OpenGL 2 that was deprecated in 3.3. I'm a beginner at OpenGL so It took me a bit to figure this out.
Good judgment comes from experience; experience comes from bad judgment.

I like your example M= A*B and how OpenGL handle matrix in reverse order.

OpenGL doesn't handle matrices in reverse order. (If you're referring to the transforms being applied in the order B->A rather than A->B, this is simply a consequence of the fact that most OpenGL references use column-vector notation. But, it's not 'reversed' with respect to anything in particular.)

This topic is closed to new replies.

Advertisement