Difference between OpenGL and programs like Unity?

Open GL is a language, these other programs listed are animation/game dev suites.

 

OpenGL is an API actually, not really a language. GLSL is a language. It has bindings for many different languages, including C and Java.

Unity is a game engine/game development environnement. It uses OpenGL to display graphics on your target (be that Android, iOS, OS X, Linux, etc...).

Maya is a graphics creation/animation package.

 

Yes, that is basically correct.

 

A game is much more than graphics. It depends what you want to do, do you want to make a game or do you want to learn what needs to be done to make a full fledged game engine up to the point of making a usable game from it ?

Unity will enable you to make a game fast.

OpenGL will enable you to write a renderer that could be used in an engine that could then be used to make a game.

 

OpenGL is hard. Really hard. Expect to spend 6 months of fairly intense study in order to become proficient.

 

GLKit makes it much easier, by restoring the fixed function pipeline to OpenGL ES 2.0 and by providing GLKBaseEffect for lighting/texturing/transformations. OS X added SceneKit to provide loading of COLLADA models (like those produced by SketchUp, a free app by Google that is darn easy to use), which is a shame, since that's basically the only difficulty left in iOS.

With just those 2 frameworks and what Apple has already built, you can be up and running a month with no GLSL required and very little OpenGL knowledge.

But again, that only covers graphics. A game requires AI, sound, physics, UI, input, data storage, etc.. etc.. Unity solved all of these things. If the goal is to get a game made and out there, Unity is the way to go. Writing all the OpenAL, OpenGL ES, SQLite/CoreData code after learning all those frameworks, not to mention architecting a few objects/algorithms of your own for physics/AI/input is going to be a much bigger endeavour.

I've been working on my own game engine/game for the last 2 years actively after switching focus to iOS and it's been a hobby project of mine for the last 10. I've rewritten it I don't know how many times anymore. The iOS version did progress much quicker, but I made use of a lot of Apple frameworks in there (even though I skipped a lot of 'em to roll my own too). If the goal was to make money off of this thing on the app store, then I was pretty much wrong in every choice I've made. But for me, the goal was always to just have fun and learn stuff, and for that writing everything from scratch and using lower level APIs has paid off big time.

 

months? It takes months to learn Cocoa. OpenGL takes on the range of years to lifetimes, in my experience, to learn. I spent months trying to learn it and got NOWHERE. I couldn't make a few spinning textured cubes right now (which is where trying to learn for six months or so got me, I've lost it all since.)

My tools of choice for making a 3D game are:
1 - Blender for making your models
2 - GIMP for skinning your models
3 - OGRE 3D for your game's rendering engine.

Blender takes a few weeks. GIMP takes a few weeks. OGRE 3D takes... well, a few weeks to be good enough with it. It seems pretty extensive; I suspect I'm only scratching the surface of what it can do with my games. The beauty of it is that the first tutorial has you drawing actual textured graphics to screen. OpenGL would like to talk to you about pipes and shaders and other abstract things that aren't FREAKING ANYTHING ON THE SCREEN. IT'S A GODDAMN GRAPHICS LANGUAGE WHERE NOTHING HAS ANYTHING TO DO WITH GRAPHICS AND AREAJKJ:SLJDF:LKJSDF:LJK:GK - I have so much rage towards how much time I wasted trying to get anywhere with that crap. It's not worth it.

Ogre 3D. Check it out. It's free. It's your friend. Learning OpenGL so you can make a video game is like learning how to build a mechanical computer so you can write a word processor. Or something similarly retarded.

 

Oh come on, the fixed function pipeline isn't that hard (OpenGL ES 1.1 or GLKit/OpenGL ES 2.0).

Let's not exaggerate here. OpenGL is quite simple actually, it's writing a renderer with all the bells and whistles that is going to be hard. Unity provides that.

Heck, with GLKit, I wrote a very small renderer in about 3 nights. Loading 2 meshes, setting up a skybox, perspective viewport, moving the camera about. All pretty simple between GLKBaseEffect, GLKSkyBoxEffect and OpenGL ES 2.0. I made the illusion of scrolling by using OpenGL's GL_REPEAT attribute for textures and playing around with S/T coordinates, I curved a mesh through using a parabola function to recaculate my vertex positions after loading a straight tile like model from file, etc...

Just get a good book. The thing is, you're going to be very very very very far from a game even after you learned OpenGL and wrote a renderer with it. I know I am, still have some good ways to go. It always depends what the goal is though, the OP has not come back to offer up what he's trying to achieve.

Now I get why you destroyed my thread about GLKit and OpenGL earlier which is a shame because if you don't like the API, you shouldn't participate in threads about it and discourage people, it's not as hard as you make it sound. Please don't ever do that again.

 

The only way to make fast and efficient code, even in a game engine, is to know how a computer works. Video Games are an excellent context to learn that knowledge. Hell, to make good and interesting shaders, you HAVE to know how the graphics pipeline works and how OpenGL/Direct3D interacts with the GPU. Even if he only does it once, he'll learn invaluable knowledge.

Oh and sorry you don't understand OpenGL, it's why smart cookies at iD Software, Blender Foundation, Apple, Unity Inc etc get paid to do it instead. But they're too busy working instead of raging at some non existent issue.

 

I'm going to assume your end goal is to make games.

If you want to make games, start learning a regular programming language. (C, C++, Java, etc) Although tools like Unity, Corona, and such *can* be used without prior programming experience, it'll be very difficult to grasp the more advanced concepts when using those packages.

Also you won't be able to use OpenGL without knowing another programming language. Although OpenGL is actually pretty easy on the surface, without knowledge of functions, classes, pointers, data types, etc you won't get very far.

Also, although you can create games from scratch, most people use pre-built tools (like Unity or UDK) and extend them. Its far too much work to create something with todays standards from scratch.

If you want to learn programming, I'd suggest this:

1. Learn a language like C, C++, Objective-C, or Java.

2. Learn to work in an API like OpenGL, SDL (not used much anymore from what I hear), or even Cocoa if you went the Objective-C route). I say "work in" because when you get to API's you'll be relying on documentation a lot. No one can remember every call from every API (although I'm starting to think Knight comes close to that )

3. Learn a game engine like Unity (my personal favorite). When you get to Unity chances are you'll get caught in asset creation. This is where tools like Maya come in. Maya (or Blender, or Modo) is for creating 3D graphics and animation. You'll use Photoshop for texturing. This is usually where you either buy assets or have someone who is a 3D artist create them because 3D is an entire other complex discipline. I won't say its not possible to make your own graphics (I do it) but you'll spend a ton of time learning how to do it right and your programming will likely suffer.

Its a lot of work to make a game but the reward is well worth it. Its amazing seeing people play something you made and having fun with it.

 

I don't know what it's like learning OpenGL today. I would say it's more difficult to lean OpenGL now,
because beginners dive right into vertex/program shaders and hit a brick wall. It's a pill they have
to swallow even if they don't know what it does. I started learning OpenGL when there was no such thing.
I wrote programs in immediate mode, and that is why people say OpenGL is easy to learn. Not because of
the other stuff. But nobody writes games in immediate mode anymore if they want to take advantage of
graphics hardware.

 

That's why Apple made GLKit basically. To slowly ween you into OpenGL ES 2.0 and GLSL. GLKBaseEffect covers transformations, lighting and texturing pretty much on par with OpenGL 2.1 and it's all you really need to get something great on screen.

Beginners that try to jump right into GLSL probably don't understand enough yet of the graphics pipeline to get up to speed quickly. They're very likely to spend 6 months to a year and then give up and say Ogre 3D is the way to go.

 

Hmmm.

I'd say if you are really bright and motivated, have a good understanding of computer graphics, a very strong understanding of C, and a strong math background (esp. matrix math) you might get up to speed on OpenGL in a month, but that's going to be the exception.

 

GLKit pretty much looks like the Apple version of the XNA graphics library. If that's the case then that's great, gets rid of a lot of boiler plate code.

 

Have you seriously tried GLKit to say that ? No need for math as GLKBaseEffect takes care of it and no need to understand the entire pipeline of graphics since there are no shaders to write.

GLKView and GLKViewController do most of the leg work for you and you're right into drawing in a couple of hours with the right book. I was surprised at how much work Apple put into it.

 

The right choice. If the end goal is shipping, use as much of what is already out there as possible and adapt it where needed. Much faster than rolling your own, which often is just some form of mental masturbation.

 

I'm not sure how much luck you'll have with modo books, especially given that some features were only recently added to that program. Prior to version 6 or so, it had no skeletons or animation tools, so I suspect they're still quite primitive. Rigging is also much more difficult than just modeling out game art. Modeling stuff is easy, even in great detail, if you understand how many edges it takes to describe a certain shape and understand what you want in base geometry as opposed to baked into maps. It just requires a lot of organization and some awareness of the shortcomings of game lighting. If you're using any detailed character animations or anything of that sort, that stuff is a pain in the ass. A big problem I see here is that you're focusing on programs and frameworks rather than the subject. It's important to be comfortable with the tools you'll use, but you do need to know about the subject itself beyond the subject of programming. You could probably learn modo in a week, but that won't teach you any of the real subjects involved.

To be clear I'm not talking about the underlying physics engines or anything like that. Understanding the shader math and dynamics is great if you are weird and obsessive (I think I've read the math for every brdf shading model in existence), but I'm not really talking about that stuff.