Need an example for OpenGL

[zoran404]

Hi.
Could someone give me a short example in OpenGL with a moving or rotating 3D object?
I'd like to see the source code, to understand how it works. I'll also need that texture for the 3D object, so I could compile and test it.

Thanks

I'm using codeblocks on windows 8.1

[kbw]

http://nehe.gamedev.net/

[Avilius]

If you're going to suggest an OpenGL tutorial, please do not suggest outdated ones. They have no practical use today. (No offense to you, kbw.)

I know I'll probably get bashed for saying this, but I'm prepared to defend what I say. Learn Direct3D 11 instead.

OpenGL is outdated and littered with ancient cruft that made sense in the 90s but doesn't make sense any more. It's due for a massive overhaul (which it will get soon if the committee doesn't act like idiots like they did with OpenGL 3.0). Even if you learn OpenGL now to get familiar with the API when it's overhauled, any knowledge you know now will be deemed irrelevant, so you're wasting your time. Since you're not using Mac or Linux, you have no reason to learn it. If you try learning OpenGL in it's current state, expect getting crap support on Windows.

D3D11 is simply the better API. It's been redesigned from scratch (well, D3D10 was, but D3D11 is like an extension), and it runs on pretty much anything Direct3D 10 runs on (and 9 to an extent).

If you want to learn OpenGL simply because it's cross-platform then you're wasting your time. Porting isn't as simple as using OpenGL. You have to port your window-handling solution, input solution, sound-system, your networking code, etc. And after that, you have to port your renderer. Although some libraries like SDL and SFML can help this, there are not a magic bullet. Doing things non trivial will quickly lock you to the development platform unless you want to have 56 different dependencies and 10 GB executables. Porting is hell, and OpenGL doesn't help.

OpenGL does not have a certification system. Stuff that works on one implementation will not work on another. Pretty much the only vendor that has decent OpenGL solutions is Nvidia. AMD and Intel solutions are shit. Expect to spend several weeks trying to fix a bug only to find out that it's because of the driver developer's half-assed work.

OpenGL's development tools are shit. I haven't found an equivalent to Renderdoc yet.

Learn Direct3D 11 first. Learn OpenGL only when you're worried about porting (which you shouldn't until you have an actual finished product). Use tools like Renderdoc to debug your code. Save your sanity.

When you do learn OpenGL later on in your career (you might not even have to), please do not use OpenGL on Windows. Model your renderer over Direct3D, and then give your engine two render backends.

TL;DR - OpenGL is terrible currently and Direct3D is by far the better API.

[zoran404]

Thanks a lot for the advice.

[anup30]

http://www.cplusplus.com/forum/general/122457/

[Avilius]

That topic is almost a year old. I've learned much more since then. If you're going to use that topic as a reference then let me clarify a few things for you.

S33ds wrote:

Valve are backing up OpenGL which is bringing more driver support to Linux.

The thing is that Valve's games use an old subset of OpenGL. Sure that's great for D3D9 era games, but modern games? Not so much.

Avilius wrote:

Use a cross-platform lib for windowing like SFML 2.1 or SDL 2.0.

While developing my own software I quickly realized that SDL and SFML aren't really helpful when you want to do something non-trivial with the OS. SFML is also pretty much locked to OpenGL (and AFAIK you can't even get a modern core context up and running with it, lol), so it's more or less useless when you want to get a quick window up for D3D. I'm not really fond of SFML myself so it doesn't really matter much to me.

Disch wrote:

But you were actually saying that people can add on to OpenGL itself.

I just want to clarify this a bit. Disch does not mean that any average joe can append to OpenGL. You can't. He means graphics vendors can add proprietary extensions to OpenGL for users using their cards only.

For example... you could write a function "DrawPolygon" that draws a single polygon to the screen. This function would then contain all the DirectX code necessary to accomplish that.

This is an extremely simplified example. Your abstraction layer wont be this close to the underlying API. When learning the API you shouldn't be worried about an abstraction layer btw.

jsbrowndog2013 wrote:

Using Linux, i'd say OpenGL. But really you will probably end up using something like OGRE and use both.

NEVER use Ogre.

BHX wrote:

That doesn't really have anything to do with it. It ultimately comes down to what OSes you want to support for your game or game engine. You can use DX or OGL for games or game engines, but OGL is supported on pretty much all OSes

It's not supported on all OSes. It's barely supported on Windows, and it has support on Mac and Linux. OpenGL ES is supported on phones, but isn't the same thing. It's a subset for embedded devices, and I doubt you'll be porting a mobile phone game to desktop, so that's more or less irrelevant. OpenGL is also not supported on consoles.

while DX is mainly Microsoft only devices and computers. Both have steep learning curves, but are both well documented last I knew.

This may be true, but it's by far the better API.

NT3 wrote:

Either learn both, or use some graphics library to provide an abstraction layer (like Ogre3D or IrrLicht)

Again, stay away from Ogre and IrrLicht. Run away if you see them being used.

[htirwin]

I know I'll probably get bashed for saying this, but I'm prepared to defend what I say. Learn Direct3D 11 instead.

It kind of depends on the use case doesn't it?

[NoXzema]

Avilius, your fallacious and outstretched arguments really bug me... I'm okay with suggesting on API over the other and stating reasons but stating things like, "NEVER use Ogre" isn't even justified. This isn't even an argument, it's negative propaganda that stretches the truth to make another product look bad. Even if OpenGL isn't the best, half the crap you spout is not even realistically or factually true.

While developing my own software I quickly realized that SDL and SFML aren't really helpful when you want to do something non-trivial with the OS. SFML is also pretty much locked to OpenGL (and AFAIK you can't even get a modern core context up and running with it, lol), so it's more or less useless when you want to get a quick window up for D3D. I'm not really fond of SFML myself so it doesn't really matter much to me.

You realize that the only thing those APIs do is abstract parts of the OS right? The only thing that DirectX needs is a window which is mostly what those APIs specialize in... and both APIs allow you to use the underlying window handle to do whatever with for any platform it supports if it doesn't support the operation directly.

NEVER use Ogre.

Is this even real life? People suggest against Dev-C++ because it's so old that it doesn't function properly and the original author can't even be contacted anymore. OGRE is an actively developed engine with several hundred contributors that you completely dismissed Because(tm). Shame on you. Same goes for IrrLicht.

I just want to clarify this a bit. Disch does not mean that any average joe can append to OpenGL. You can't. He means graphics vendors can add proprietary extensions to OpenGL for users using their cards only.

A lot of the core API in OpenGL originally started as extensions from vendors. Not sure if you know that. A vendor has little right to say, "Here's an API, add it to OpenGL because I said so." That isn't how it works. If an extension is useful, the purpose of OpenGL allows other vendors to implement those extensions to their fullest extent. From there, it can be adopted as an ARB or Khronos extension and eventually into core if it's sufficient.

It's not supported on all OSes. It's barely supported on Windows, and it has support on Mac and Linux. OpenGL ES is supported on phones, but isn't the same thing. It's a subset for embedded devices, and I doubt you'll be porting a mobile phone game to desktop, so that's more or less irrelevant. OpenGL is also not supported on consoles.

Barely supported on Windows? OpenGL isn't supported on consoles? Do you even know why OpenGL ES is a subset? Please dude, you're getting ridiculous.

[htirwin]

It depends on what you want to do, but I would personally recommend giving WebGL a try. It's OpenGL ES with a javascript interface. It's nice because you can have your game hosted on your website, and it doesn't really matter that much which OS or device they have, as long as their browser supports it and their hardware can handle it. There are also a few really nice libraries like three.js which can make things pretty easy for you.

[Avilius]

NoXzema wrote:

I'm okay with suggesting on API over the other and stating reasons but stating things like, "NEVER use Ogre" isn't even justified.

I figured I'd have to elaborate. Fair enough.

Is this even real life? People suggest against Dev-C++ because it's so old that it doesn't function properly and the original author can't even be contacted anymore. OGRE is an actively developed engine with several hundred contributors that you completely dismissed Because(tm). Shame on you. Same goes for IrrLicht.

It doesn't matter how many people use Ogre. Both it's code and performance aren't the best.

Of course what I'm about to say applies to Ogre 1.9 since 2.0 hasn't been released yet.

Its inefficient designs of the renderer itself make it a terrible example of what one should look like. The programmers seem to not like sorting very much, and they love to load irrelevant shit deep in the parts where speed matters the most.

A short look in the render system. My comments are in the /**/ tags (is that what they're called? lol.):

/* When have you ever had a single render operation? This is likely going to
   be in a tight loop, so you're going to be calling the function hundreds or thousands
   of times when you can easily just send everything once? Dafuq? I guess they just like unnecessary overhead. */
void D3D11RenderSystem::_render(const RenderOperation& op)
{
	// Exit immediately if there is nothing to render
	
	/* Okay, so you're this far into the renderer and you haven't sorted yet? Wtf?
	   You're also dereferencing a pointer, loading maybe a hundred or so bytes into the
	   cache just to access a single 4 byte integer.
	   R.I.P, cache. */
	if (op.vertexData==0 || op.vertexData->vertexCount == 0)
	{
		return;
	}
	
	/* Oh, so the Ogre devs love global state. Pretty much killed all chances of efficient
	   multithreaded rendering in these two lines. */
	HardwareVertexBufferSharedPtr globalInstanceVertexBuffer = getGlobalInstanceVertexBuffer();
	VertexDeclaration* globalVertexDeclaration = getGlobalInstanceVertexBufferVertexDeclaration();
	
	/*
	   Again with the sorting... is it against your religion?
	*/
	 bool hasInstanceData = op.useGlobalInstancingVertexBufferIsAvailable &&
                    !globalInstanceVertexBuffer.isNull() && globalVertexDeclaration != NULL 
                || op.vertexData->vertexBufferBinding->getHasInstanceData();
	
	/*
	   Ditto.
	*/
	if (op.useGlobalInstancingVertexBufferIsAvailable)
	{
		numberOfInstances *= getGlobalNumberOfInstances();
	}
	
	/*
	   Wut. So now you're calling some polymorphic function in the middle
	   of a render operation. Must love cache misses.
	*/
	// Call super class
	RenderSystem::_render(op);
	
	/* (Cut out the rest to save space) ... */
	
	// Determine rendering operation
	D3D11_PRIMITIVE_TOPOLOGY primType = D3D11_PRIMITIVE_TOPOLOGY_TRIANGLELIST;
	DWORD primCount = 0;
	
	/*
	   Sort, sort, sort!
	*/
	bool useAdjacency = (mGeometryProgramBound && mBoundGeometryProgram && mBoundGeometryProgram->isAdjacencyInfoRequired());
	
	/*
	   I think that's enough for one post...
	*/
}

gg cache :(

Not to mention that both Ogre and Irrlicht designed their code on outdated libraries! (OpenGL 1.x and D3D9? WTF! Irrlicht has support for D3D8!)

The reason why a lot of games are CPU bound is because programmers do stupid stuff like that.

You realize that the only thing those APIs do is abstract parts of the OS right?

How does this contradict

Avilius wrote:

While developing my own software I quickly realized that SDL and SFML aren't really helpful when you want to do something non-trivial with the OS.

?

NoXzema wrote:

...The only thing that DirectX needs is a window which is mostly what those APIs specialize in... and both APIs allow you to use the underlying window handle to do whatever with for any platform it supports if it doesn't support the operation directly.

The thing is that SFML doesn't allow you to get the helper classes that you'd get with OpenGL. It was designed as an OpenGL library. It defeats the purpose of even using the graphics module because it's more or less useless.

It's similar with SDL, but they barely provide anything to help OpenGL either so it doesn't hurt as much.

A lot of the core API in OpenGL originally started as extensions from vendors. Not sure if you know that. A vendor has little right to say, "Here's an API, add it to OpenGL because I said so." That isn't how it works. If an extension is useful, the purpose of OpenGL allows other vendors to implement those extensions to their fullest extent. From there, it can be adopted as an ARB or Khronos extension and eventually into core if it's sufficient.

How does this contradict what I've said?

Barely supported on Windows?

The driver state for modern contexts is pitiful to say the least.

OpenGL isn't supported on consoles? Do you even know why OpenGL ES is a subset? Please dude, you're getting ridiculous.

OpenGL ES is supported on [some] consoles, but no developers will ever use it because the speed is ridiculous. The only people who use OpenGL ES on consoles are homebrew developers. Pros don't use it.

The PS3 doesn't even support GLSL. Lol.

There may be an implementation, but there is no support.

htirwin wrote:

It depends on what you want to do, but I would personally recommend giving WebGL a try. It's OpenGL ES with a javascript interface. It's nice because you can have your game hosted on your website, and it doesn't really matter that much which OS or device they have, as long as their browser supports it and their hardware can handle it. There are also a few really nice libraries like three.js which can make things pretty easy for you.

Sounds neat, but I'm sure the OP already invested some time in C++. Learning javascript is kind of pointless at this state sadly. (He also might not be interested in web programming).

It kind of depends on the use case doesn't it?

Since he's using Windows 8, I don't see why not.

[htirwin]

Sounds neat, but I'm sure the OP already invested some time in C++. Learning javascript is kind of pointless at this state sadly. (He also might not be interested in web programming).

I don't see how learning C++ makes learning javascript pointless. It's actually pretty easy to learn javascript compared to C++. And whether it's javascript or C++, you're still doing 3D graphics programming. It's just a different platform.

[ezchgg]

@Avilius
No no no no, you got that backwards:

Avilius wrote:

While developing my own software I quickly realized that SDL and SFML aren't really helpful when you want to do something non-trivial with the OS.

How does this contradict

You realize that the only thing those APIs do is abstract parts of the OS right?

?

gg cache :(

Not to mention that both Ogre and Irrlicht designed their code on outdated libraries! (OpenGL 1.x and D3D9? WTF! Irrlicht has support for D3D8!)

The reason why a lot of games are CPU bound is because programmers do stupid stuff like that.

This doesn't matter for the majority of games, only AAA games really, which the majority use Unreal/Cry engine anyways. Even then, good looking games don't make fun games, which a lot of AAA developers have forgot, or maybe just their overlords. The reason a poorly programmed game in Java made a company worth Billions of dollars.

The thing is that SFML doesn't allow you to get the helper classes that you'd get with OpenGL. It was designed as an OpenGL library. It defeats the purpose of even using the graphics module because it's more or less useless.

What helper classes are in OpenGL? As far as i'm aware OpenGL's API is written in C, which has no concept of classes. Also in this thread, yes using the 2D graphics module would be useless for a 3D render example.

[htirwin]

It kind of depends on the use case doesn't it?

Since he's using Windows 8, I don't see why not.

OpenGL is preferred for professional 3D graphics software ( scientific visualization, engineering ).

And just because it's possible to get slightly better performance on Windows using D3D, if you are willing to get deep into low level optimization, doesn't mean it makes sense to use D3D in all cases even for Windows development. It's not like someone is going to be a one man team who is going to stay competitive with leading game engines by spending years trying to optimally layout memory and get every little bit of performance out of the hardware, for each supported platform, possible.

It's more likely that, as an Indy developer who is using a graphics API directly, the bottlenecks are not related to choosing OpenGL over D3D. It's not like you are going to have the manpower to have people who do nothing but profile all day long every day and try to find the most optimal way possible to layout memory given a range of devices that will end up running the engine. And even if you did, you would still have a lot of more important tricks to perfect first, like distance based decimation, hidden surface removal, instancing, procedural texture generation, and the list goes on and on.

And if you're making something like Flappy Birds, or even minecraft, and not Crysis 5, then the slight performance benefits you might hope to get from D3D on windows become pointless anyways.

That being said, for developing a real game, you're probably not going to be wanting to use a graphics API directly anyways.

For learning purposes, it doesn't matter too much which you use. The core concepts of 3D graphics programing are the same no matter which API you use, and the shader languages are similar enough that it's pretty easy to port code in one to another. OpenGL is nice and convenient because it's so widely supported.

If you end up working on a team making a cutting edge rendering engine, then you're probably going to be working with either something based on or very similar to OpenGL or both something related to OpenGL and D3D, or possibly neither anyways. What is unlikely however is that you work on an engine that uses D3D exclusively. Then what is the point of learning D3D instead of OpenGL when you might have to know both?

[Avilius]

htirwin wrote:

I don't see how learning C++ makes learning javascript pointless. It's actually pretty easy to learn javascript compared to C++. And whether it's javascript or C++, you're still doing 3D graphics programming. It's just a different platform.

I didn't mean it like that. It doesn't make sense to learn a new language solely to learn graphics programming.

ezchgg wrote:

This doesn't matter for the majority of games, only AAA games really, which the majority use Unreal/Cry engine anyways

The majority of AAA games use Unreal Engine and Cry Engine? What world do you come from?

People who think this doesn't matter is exactly why small programs eat up so many resources. Look at Minecraft for example.

Even then, good looking games don't make fun games, which a lot of AAA developers have forgot, or maybe just their overlords.

What does good looking games have anything to do with what I just said?

The reason a poorly programmed game in Java made a company worth Billions of dollars.

This is not relevant to the conversation.

What helper classes are in OpenGL? As far as i'm aware OpenGL's API is written in C, which has no concept of classes. Also in this thread, yes using the 2D graphics module would be useless for a 3D render example.

You misread what I said. I said that SFML provides helper classes for OpenGL.

@Avilius
No no no no, you got that backwards:

So, how is what I said backwards?

[Avilius]

htirwin wrote:

OpenGL is preferred for professional 3D graphics software ( scientific visualization, engineering ).

This statement is way too vague.

It's not like someone is going to be a one man team who is going to stay competitive with leading game engines by spending years trying to optimally layout memory and get every little bit of performance out of the hardware, for each supported platform, possible.

If you're not worried about providing an optimal user experience then programming probably isn't for you.

Keep in mind I wrote my comments on Ogre in a few minutes after looking at their code. I didn't spend several years thinking about it. This should be common sense.

It's more likely that, as an Indy developer who is using a graphics API directly, the bottlenecks are not related to choosing OpenGL over D3D.

You're right. The bottleneck will probably be from the CPU because of the terrible way programmers generally design their code.

It's not like you are going to have the manpower to have people who do nothing but profile all day long every day and try to find the most optimal way possible to layout memory given a range of devices that will end up running the engine.

If you don't know the hardware that you're working with then you shouldn't be developing for it.

That being said, for developing a real game, you're probably not going to be wanting to use a graphics API directly anyways.

Never said that you would. However, if you're developing your own layer then you should use the best supported API on your platform.

For learning purposes, it doesn't matter too much which you use. The core concepts of 3D graphics programing are the same no matter which API you use, and the shader languages are similar enough that it's pretty easy to port code in one to another. OpenGL is nice and convenient because it's so widely supported.

The shader languages are different enough that you're going to have to painfully rewrite each and every shader from scratch (although the logic will stay the same).

And if you're making something like Flappy Birds, or even minecraft, and not Crysis 5, then the slight performance benefit becomes pointless anyways.

I don't think you properly understood what I was saying.

I want to put emphasis on this:

Avilius wrote:

OpenGL does not have a certification system. Stuff that works on one implementation will not work on another.

As in OpenGL just plain wont work on some systems. I think there was a bug recently in AMD's drivers that broke compatibility with a lot of modern OpenGL programs. I'm not even sure it's been fixed yet.

Avilius wrote:

Expect to spend several weeks trying to fix a bug only to find out that it's because of the driver developer's half-assed work.

htirwin wrote:

If end up working on a team making a cutting edge rendering engine, then you're probably going to be working with either something based on or very similar to OpenGL

Definitely not this.

or both something related to OpenGL and D3D, or possibly neither anyways

It's most likely neither. Each engine has it's own specific requirements, and the engine itself will (hopefully) be modeled around it's requirements and constraints.

What is unlikely however is that you work on an engine that uses D3D exclusively.

And I never said you would.

[htirwin]

If you're not worried about providing an optimal user experience then programming probably isn't for you.

It's not about not caring about the user experience, it's having enough common sense to realize how to better spend your time and money than on things that are going to make very little if any difference in your case. By spending more time on the important things you will give a better user experience.

The comments you posted in the code are irrelevant to the debate about D3D vs OpenGL.

My understanding is that the primary reason most AAA game companies don't use OpenGL is because it doesn't allow for as much low level control. They do a lot of low level optimization. It's just not practical for an individual or even small team to develop their own render engine and do that level of optimization.

[Avilius]

htirwin wrote:

It's not about not caring about the user experience, it's having enough common sense to realize how to better spend your time and money than on things that are going to make very little if any difference in your case.

There is a well defined line between writing code correctly and over-optimization.

I don't think you understand the performance differences in designing your code around your data can bring.

Tell me: How would you design a particle system?

The comments you posted in the code are irrelevant to the debate about D3D vs OpenGL.

I know it's irrelevant to the debate. NoXzema requested I elaborate on why Ogre shouldn't be used, so that's what I did.

My understanding is that the primary reason most AAA game companies don't use OpenGL is because it doesn't allow for as much low level control. They do a lot of low level optimization. It's not practical for an individual or even small team to develop their own render engine and do that level of optimization.

No. They provide more or less the same amount of control. The support is something else entirely however.

It is perfectly practical for someone to develop their own render engine. That's a fairly broad statement to make.

[htirwin]

No. They provide more or less the same amount of control. The support is something else entirely however.

We had a guest lecturer from a lead graphics programmer at EA at my school. He's who gave me this impression. He said specifically it was the ability to have low level control over memory management on the GPU that OpenGL lacked, and that the trend in the latest API's is to give more control over these lower level details which allow them to get better performance on specific target hardware. He was probably talking about features you are not even aware exist.

He mentioned that DirectX is moving in this direction, or currently supports some lower level memory management, but also talked about some other API's that I can't exactly remember. He mentioned that an in house modified version of OpenGL is also a possibility.

Here is an example of a new API like I am talking about.

n existing applications, various buffers are assigned a memory area by the driver in a very rigid way, which makes it difficult to reuse some memory areas and multiply the number of these areas to manage and boost the total memory consumption. This is partly why the memory utilization of 3D rendering on PC is usually much higher than that on consoles, where developers can make the most of available resources.

Mantle allows the application to directly control the transfer of data and management of video memory in order to overcome the existing inefficiencies. Since the application knows exactly what it needs to do, many generic checks are no longer relevant. The application gains control of not only the video memory, but also the system RAM. This, in turn, leverages GPU Memory Virtualization.

http://gearnuke.com/in-depth-look-at-amd-mantle/

It is perfectly practical for someone to develop their own render engine. That's a fairly broad statement to make.

I didn't say it's not practical for someone to develop their own render engine, I'm saying it's not practical for single person to develop one with that level of optimization ( the point at which you have to get lower level than OpenGL supports ). Maybe I'm wrong.

[Avilius]

htirwin wrote:

We had a guest lecturer from a lead graphics programmer at EA. He's who gave me this impression. He said specifically it was the ability to have low level control over memory management on the GPU that OpenGL lacked, and that the trend in the latest API's is to give more control over these lower level details which allow them to get better performance on specific target hardware.

I think he was talking about next-gen APIs such as D3D12 and Mantle. He might have even been referring to the console APIs.

Was this recorded or is there a transcript?

With D3D11 you can not directly control memory management on the GPU.

I didn't say it's not practical for someone to develop their own render engine, I'm saying it's not practical for single person to develop one with that level of optimization ( the point at which you have to get lower level than OpenGL supports ).

Again the only APIs that provide support for hardware access below OpenGL are Direct3D 12, Mantle, and console APIs. D3D11 and OpenGL are roughly equivalent with the control they provide.

[ezchgg]

assilius wrote:

The majority of AAA games use Unreal Engine and Cry Engine? What world do you come from?

People who think this doesn't matter is exactly why small programs eat up so many resources. Look at Minecraft for example.

I know Minecraft eats up resources, but i wouldn't call it a small program, especially not one you just run in the background all the time. Also a very bad example because of how successful Minecraft is, worth Billions, y'know. Unless you are saying that making a less efficient program will make me a billionaire?

What does good looking games have anything to do with what I just said?

What doesn't it have to do with what you just said? Optimization is a huge huge huge part of why games look good. Gameplay does not require as much optimization.

This is not relevant to the conversation.

It is completely relevant, you can make a poorly programmed piece of software, that doesn't matter so long as it is usable. Your arguments as to why not to use Ogre and similar API is that they aren't as efficient as they could be. Ok so they are not as efficient as they could be. What difference does that make? Efficiency does not guarantee anything.

You misread what I said. I said that SFML provides helper classes for OpenGL.

I didn't misread what you said, your words did not correlate to the meaning you intended them to hold.

So, how is what I said backwards?

Your statement doesn't contradict his. You know the whole glass half full, you were looking at his statement from a perspective that benefits your own views.

Avillius wrote:

next-gen APIs such as D3D12 and Mantle

God i hate marketing for consoles.