what vast difference? what statement is a fact?
it's safe to say that if you've worked with render clustering transparently then you're not getting anywhere near the performance you should be getting.
Off topic, anyway.
what vast difference? what statement is a fact?
it's safe to say that if you've worked with render clustering transparently then you're not getting anywhere near the performance you should be getting.
Off topic, anyway.
A very funny stuff, unfortunately true...
http://www.youtube.com/watch?v=sddv3d-w5p4
Spread it!!!
I'm almost a newbie to graphics programming, although I've done a few things with opengl some years ago mostly under Linux for some assignments at uni.
Now I wanted to start graphics programming again and I was quite confident, before I read this thread.
I'm still using XP. In fact I've just set it up newly after getting new hardware, installed everything again, compilers, SDKs, other applications, all I need and it took me a day.
I saw that OpenGL 3.0 drivers are ready and that Nvidia is even supplying some nice extra tools, so I was really convinced that jumping straight into OpenGL3.0+shaders and not bothering about depreciated techniques would be the right thing to do now. My thinking was that OpenGL 3.0 is on par with DirectX10, works on my system, is available on Linux etc., is future-proof, so perfect for me.
But now I'm really worried. Not so much about certain special features itself, since I don't have the knowledge to use them right now anyway, but I'm worried about the future. I mean, learning a complicated API and getting pro with it takes a lot of time and if I decide to do it and also write lots of code, I surely ask myself, if it's worth the effort or if I'm doing/learning something that will be of not much use to me tomorrow.
So if I read this thread or that some graphics engine developers, who always had OpenGL support included, are not planning to have it in their newest engines, it really makes me think, if trying to get into OpenGL currently is a wise thing. I don't want to become an expert in something that has become a sinking ship.
I don't say that OpenGL has become that already, but I'm really worried about that possibility and it makes me hesitate to start with it.
This is not about me ofc, but I think it's generally a bad sign to everyone, who has to make a choice between OpenGL and DirectX9,10,11. They are probably all worried after reading this.
So in my opinion, if some companies are slowing the development of OpenGL so much down that it stays behind Direct3D and hardware development, they are killing OpenGL in the long term just to save some work on their existing code base !
I wish, I knew what everyone in that commitee is thinking and if they are really willing to do what's necessary to keep that API competetive or if they are just trying to play out some time for the people with legacy code.
I think that's really an important question for someone, who's just making the decision for or against OpenGL.
OpenGL could never be a sinking ship, it is supported by nearly every operating system and in most cases it is the primary 3D graphics API.Originally Posted by Sledge Hammer
The ES version is becoming more and more widely supported across all sorts of PDA's and cell phones.
I would be more worried about DirectX now that windows has begun its slow decline, especially with the global economic crisis making people less likely to waste hundreds of dollars upgrading windows every few years when they can have a higher performance OS for free.
The most complicated part is writing the shaders, and GLSL, HLSL and Cg are all very similar so if you learn one then you will be able to write shaders for any API.Learning a complicated API and getting pro with it takes a lot of time and if I decide to do it and also write lots of code, I surely ask myself, if it's worth the effort or if I'm doing/learning something that will be of not much use to me tomorrow.
The OpenGL API itself is actually quite simple, once you throw away all the depreciated stuff.
Most of the complaints in this thread relate to the way the ARB suddenly stopped all public communication and then released a spec that was nothing like what most people were expecting.
The restructuring of the API to use immutable objects, missing from the 3.0 spec, is expected to be done in the upcoming 3.1 release.
When combined with the recently released OpenCL spec, which adds the capabilty to manipulate OpenGL buffer data any way you can imagine, OpenGL will quickly surpass DirectX11 in technology and ease of use.
To bring yourself up to date you should first learn to use VBO's to transfer vertex data to the graphics card and then try a few simple shader examples to learn how to use them.
Stay away from anything that mentions glBegin or PBO's or anything else listed as depreciated.
PBO ar not deprecated and it is very normal to use them for various tasks. For example - asynchronous data transfer from/to buffers.
I can't see why one would expect that. If we learned anything from 3.0 it's that GL expectations are fantasies.
3.1 will be a good test of whether the ARB will actually be productive in the future. They have made no promises, no guarantees, so we can all be pleasantly surprised if they remove deprecated functionally, incorporate more extensions into core, or implement any suggestions found on this forum.
It's been almost 7 months since the release of the 3.0 spec. No news in GL land has a track record of not being good news.
Sledge Hammer - you'll find developing in Direct3D to be a far more pleasant experience. Only use OpenGL if you need Linux support or you need Direct3D 10-level capabilities in Windows XP.
Ok, today I tried to inform myself a bit better, googled for 'Modern OpenGL' or something like that and found some slides from Siggraph Asia 2008 presentation. The subject was 'Modern OpenGL: Its Design and Evolution.' by Mark J Kilgard, Nvidia and Kurt Akeley, Microsoft.
Those slides were quite interesting. Then I came to the topic of display lists. glCallList was mentioned as OpenGLs most powerfull command and the way to go for performance reasons. Mark J Kilgard says that that the current mechanism is just not flexible enough and needs to be enhanced. He gives some hints, what needs to change.
Ok, but in OpenGL3.0 displaylists are marked as depreciated. Makes me wonder a bit, how this decision was made. I would have thought that especially the graphics card / driver developers know best, where the bottlenecks/flaws are in the current specification and what is needed to meet the every increasing demands for more detail, realism, graphics power.
I mean, as I see it, the future direction needs to be chosen by those, who need that graphics power/new features in the future and those, who have to build the hardware for it and know best, how the command processing etc. needs to be done to get that high performance and avoid bottlenecks.
Like I say, strange, if some hardware developer says, we need to go this way and enhance it, but the thing gets marked 'depreciated'. Sounds like a communication problem to me.
Yes, i should have been clearer.
I just meant that someone starting to learn OpenGL should stay away from tutorials and and examples that use PBO's, and just use FBO's.
PBO's do have there uses, but for specific purposes that should wait until the learner is comfortable with the core API and ready to move on to more advanced topics.
The reason that display lists was marked for depreciation is that most of the reasons for using them will be relaced by VBO's and immutable objects (if they are introduced in OpenGL 3.1)
They do still have a performance advantage, on NVIDIA hardware especially, for batching draw calls for static geometry.
They were marked depreciated simply because NVIDIA was out-voted by the other companies on the ARB that dont want them.
This does not mean that they will definately be removed, and even if they are, there will probably be new functions that allow you to get the same result a different way, and NVIDIA can still provide display lists as an extension if they want.
OpenGL is in a period of flux at the moment, this is not a bad thing, even if it does seem a bit chaotic.
This is all part of a process that will hopefully make OpenGL the best API it can possibly be.
Most of us here are waiting on the 3.1 spec to discover what direction the future OpenGL will actually take, but that does not mean that you need to wait until then to start learning OpenGL.
VBO's, FBO's and shaders will definately be core components of modern OpenGL, so if you learn these first then you will be ready for the future.
When writing your programs, structure them so that commands that setup the rendering state for each VBO, FBO and shader program are in a separate function, then record each to a display list and use glCallList to change the rendering state.
This should make it easier to convert when 3.1 is released (each display list converted to an immutable object and each function becoming the initialisation routine for that object)
When 3.1 does come out you will probably need a good matrix-math library to replace the old OpenGL matrix functions.
PBO = Pixel Buffer Object, and you should not avoid them. You can not replace them with FBO.
You probably meant PBuffer - platform specific way of rendering to ofscreen buffer.
Posting Permissions
