OpenGL 3+ RenderSystem
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
OpenGL 3+ RenderSystem
Hey everyone! I'd like to introduce the OpenGL 3+ render system. It's still very early of course but here's a rundown of what I'm aiming for and other notes:
* Core profile only. Meaning that no legacy functionality is supported. Most notably, fixed function rendering. This leverages the RTSS to emulate it in the same way as OpenGL ES 2 and DX11.
* Some features will require new core constructs, hopefully they can also be implemented for DX11. For example, shared parameters(Uniform Buffer Objects)
* For now, Cg support is disabled. This is because it is not working on OS X yet and that's the platform that I'm using.
* OpenGL 3.0 is the minimum for this render system.
* On OS X, Carbon is gone. This greatly simplifies the windowing code and it has been reworked to only use Cocoa. This includes full screen. Yes this means that it works on Mac OS X 10.7. And no, your questions regarding 10.7 will not be answered until it is no longer under NDA.
The code and other status can be found here:
https://bitbucket.org/masterfalcon/ogre-gl3plus
UPDATE!: This is now available in the main Ogre repo in the 1.9 branch.
https://bitbucket.org/sinbad/ogre
More info and design thoughts coming soon.
* Core profile only. Meaning that no legacy functionality is supported. Most notably, fixed function rendering. This leverages the RTSS to emulate it in the same way as OpenGL ES 2 and DX11.
* Some features will require new core constructs, hopefully they can also be implemented for DX11. For example, shared parameters(Uniform Buffer Objects)
* For now, Cg support is disabled. This is because it is not working on OS X yet and that's the platform that I'm using.
* OpenGL 3.0 is the minimum for this render system.
* On OS X, Carbon is gone. This greatly simplifies the windowing code and it has been reworked to only use Cocoa. This includes full screen. Yes this means that it works on Mac OS X 10.7. And no, your questions regarding 10.7 will not be answered until it is no longer under NDA.
The code and other status can be found here:
https://bitbucket.org/masterfalcon/ogre-gl3plus
UPDATE!: This is now available in the main Ogre repo in the 1.9 branch.
https://bitbucket.org/sinbad/ogre
More info and design thoughts coming soon.
-
- Old One
- Posts: 2565
- Joined: Sun Sep 11, 2005 1:04 am
- Location: Paris, France
- x 56
Re: OpenGL 3+ RenderSystem
Followed
So by OpenGL 3+ , do you include 4+ or is it bound to 3.x ?
So by OpenGL 3+ , do you include 4+ or is it bound to 3.x ?
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Yeah, supporting from 3 and above.
-
- Gnoblar
- Posts: 11
- Joined: Sun Mar 27, 2011 12:23 pm
- x 1
Re: OpenGL 3+ RenderSystem
I get this when i try to compile:
/home/arr/projects/ogre-gl3plus/RenderSystems/GL3Plus/include/GL/glew.h: In member function 'virtual void Ogre::GL3PlusSupport::initialiseExtensions()':
/home/arr/projects/ogre-gl3plus/RenderSystems/GL3Plus/include/GL/glew.h:15453: error: too few arguments to function 'GLenum glewContextInit(GLEWContext*)'
/home/arr/projects/ogre-gl3plus/RenderSystems/GL3Plus/src/OgreGL3PlusSupport.cpp:83: error: at this point in file
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Is that on linux? I don't think anyone has tried to get it compiling there yet.
-
- Gnoblar
- Posts: 11
- Joined: Sun Mar 27, 2011 12:23 pm
- x 1
Re: OpenGL 3+ RenderSystem
Kind of, it's FreeBSD. I'm not familiar with glew, so i don't know how to fix this.
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Design idea for Uniform Buffers:
The main goal here is to enable the use of Uniform Buffer Objects of course, but there are also a couple subgoals.
1. Enable the functionality across platforms. If I understand correctly, Constant Buffers off similar functionality under Direct X.
2. Let the implementation function in a way that will use the shared parameters if they are available but transparently function as usual if they are not. Treating the parameters listed in a block as if they were declared inside the program definition, i.e. identical to how it works now.
Here is a small example of the syntax that I'm proposing.
One item that I haven't ironed out yet is how to use the shared params across resource files. Where a file may be processed that references them before the file that defines them.
Any thoughts, ideas or comments would be awesome.
The main goal here is to enable the use of Uniform Buffer Objects of course, but there are also a couple subgoals.
1. Enable the functionality across platforms. If I understand correctly, Constant Buffers off similar functionality under Direct X.
2. Let the implementation function in a way that will use the shared parameters if they are available but transparently function as usual if they are not. Treating the parameters listed in a block as if they were declared inside the program definition, i.e. identical to how it works now.
Here is a small example of the syntax that I'm proposing.
Code: Select all
shared_params myParams
{
param_named_auto worldViewProj worldviewproj_matrix
param_named_auto inverseView inverse_view_matrix
param_named_auto ambient ambient_light_colour
}
vertex_program MyVertexProgram glsl
{
source MyVertexProgram.glsl
default_params
{
shared_params_ref myParams
param_named pixelSize float 0.0031
param_named scale float 1.0
}
}
vertex_program MySecondVertexProgram glsl
{
source MySecondVertexProgram.glsl
default_params
{
shared_params_ref myParams
param_named pixelSize float 0.0261
param_named scale float 4.0
}
}
Any thoughts, ideas or comments would be awesome.
-
- Gnoblar
- Posts: 10
- Joined: Sun Aug 16, 2009 3:52 am
- x 1
Re: OpenGL 3+ RenderSystem
I was actually just starting to look at doing this myself. One thing I think would be wise however would be to make the render systems in a fashion similar to the way DirectX is handled, meaning you have a render system for each version (I was thinking major, however the revisions may also be wise to have separate render systems as well for debugging and compatibility purposes).
For how I was thinking of setting it up I was thinking along the lines of:
RenderSystems
| OpenGL2
| OpenGL3
| OpenGL4
This would allow for easier maintaining of the various versions of OpenGL as it would account for the depreciation model removing something between say, OpenGL 3 and OpenGL 4 or OpenGL4 and OpenGL 5. I personally think that just having one render system for 3+ is a bad idea because what happens when something in 3 gets depreciated, you get the idea.
For how I was thinking of setting it up I was thinking along the lines of:
RenderSystems
| OpenGL2
| OpenGL3
| OpenGL4
This would allow for easier maintaining of the various versions of OpenGL as it would account for the depreciation model removing something between say, OpenGL 3 and OpenGL 4 or OpenGL4 and OpenGL 5. I personally think that just having one render system for 3+ is a bad idea because what happens when something in 3 gets depreciated, you get the idea.
-
- Orc
- Posts: 459
- Joined: Sat Jan 24, 2009 11:16 am
- Location: Italy
- x 6
Re: OpenGL 3+ RenderSystem
Hi masterfalcon,
I have some questions.
Why you've created a new plug-in for OpenGL 3+ support?
Would be possible to have it in the current GLRenderSystem and check is graphics card supports higher 3+ feature?
Thanks,
Amer
I have some questions.
Why you've created a new plug-in for OpenGL 3+ support?
Would be possible to have it in the current GLRenderSystem and check is graphics card supports higher 3+ feature?
Thanks,
Amer
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
The answer to both boyamer and th3flyboy's questions is the same. The reason for separating 3+ out as it's own rendersystem is not simply a change in version or functionality. But rather, a change in architecture. If you look at our rendersystems you see a pattern emerging.
DX9->DX11 lose fixed function
ES1->ES2 lose fixed function
GL is next.
DX9->DX11 lose fixed function
ES1->ES2 lose fixed function
GL is next.
-
- Orc
- Posts: 459
- Joined: Sat Jan 24, 2009 11:16 am
- Location: Italy
- x 6
Re: OpenGL 3+ RenderSystem
Thanks for clarification, but as i know directx 11 uses the RTSS component for simulation FFP, so basically would be possible to have the RTSS embedded into the OgreMain and generate shader (vertex,fragment,geometry) whether no shader is specified into the material and simulate the same functionality of DX11.
Maybe i'm wrong.
Maybe i'm wrong.
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
We should keep the RTSS as a component. But it is being used for FFP emulation here too.
-
- Gnoblar
- Posts: 10
- Joined: Sun Aug 16, 2009 3:52 am
- x 1
Re: OpenGL 3+ RenderSystem
I understand the removal of FFP, however what I'm more concerned about is the ability to specify the shader model version in use. There are certain methods I've been doing research on that require shader model 5, however if you say OpenGL 3 or above, with no way to specify the shader model in use by the render system, then you have the problem of the possibility of a shader model 4 card trying to use something that's restricted to shader model 5. The other issue I see is that it would be helpful to have separate ones for 3 and 4 because then you can optimize the render system for new features implemented in the newer specs, rather than having one which is limited by compatibility for an older spec. A perfect example of this would actually be the additional OpenCL compatibility added in OpenGL 4.1 rather than trying to keep the render system compatible with an older system and restricting the possibility for implementing things that may help but are restricted to a higher version than the lowest spec in the render system (in this case 3.x).
*edit:
Thinking about it a little more, it may be possible to set flags for various OpenGL spec numbers, for example, a flag for OpenGL 4, and a flag for OpenGL 4.1, and allow for certain aspects of the render system to be determined on how it's handled by the flag, however I'm not sure how that would impact performance.
*edit:
Thinking about it a little more, it may be possible to set flags for various OpenGL spec numbers, for example, a flag for OpenGL 4, and a flag for OpenGL 4.1, and allow for certain aspects of the render system to be determined on how it's handled by the flag, however I'm not sure how that would impact performance.
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Hmm. I see your point. The way that the render systems work right now is with the goal of providing maximum feature coverage. So if the features are available at runtime then their support will be enabled. Some of those features can be turned on per material or program using script directives.
The system is quite dynamic, a specific feature set is not always available. It depends on the OS, drivers and support for those features in Ogre. If they are available on a specific system, then you can use them otherwise they are automatically disabled.
A couple of the main reasons for choosing to begin at 3.0 are that Ogre has traditionally tried to support as wide a range of hardware as possible and that there is a lot of work to do to get us up to 4.1 support. Best to start incrementally.
The system is quite dynamic, a specific feature set is not always available. It depends on the OS, drivers and support for those features in Ogre. If they are available on a specific system, then you can use them otherwise they are automatically disabled.
A couple of the main reasons for choosing to begin at 3.0 are that Ogre has traditionally tried to support as wide a range of hardware as possible and that there is a lot of work to do to get us up to 4.1 support. Best to start incrementally.
-
- Gnoblar
- Posts: 10
- Joined: Mon Jun 06, 2011 9:42 pm
Re: OpenGL 3+ RenderSystem
Hi people.
I'm trying to finish Direct3D 11 Render System, and we can share too much ideas between these projects.
For example, shared parameters only makes sense if uploaded once in the frame, and to the same constant/uniform buffer.
For this to work, why not add another type of hardware buffer? In this way, GpuProgramParameters can upload constants in these buffers once AND share these buffers among GpuPrograms?
I'm trying to finish Direct3D 11 Render System, and we can share too much ideas between these projects.
For example, shared parameters only makes sense if uploaded once in the frame, and to the same constant/uniform buffer.
For this to work, why not add another type of hardware buffer? In this way, GpuProgramParameters can upload constants in these buffers once AND share these buffers among GpuPrograms?
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
I've gotta think it through a little bit more tonight but that sounds like an ok way to go about it.
And I agree, DX11 and GL 3+ are going to be sharing a lot of concepts. Best to get on the same page.
And I agree, DX11 and GL 3+ are going to be sharing a lot of concepts. Best to get on the same page.
-
- Gnoblar
- Posts: 1
- Joined: Wed Jun 15, 2011 9:34 pm
Re: OpenGL 3+ RenderSystem
I've only recently started working with the new OpenGL 4.1 specification and have left behind the FFP. What I've done is used all of my own GLSL vertex/fragment shader programs to perform all transformations and rendering and used GLM for all matrix handling etc on the C++ side. I've decided to not create my own engine but rather to start with Ogre to easy the development process of my first game projects. That being said, I'd like to continue completely without the FFP and fully utilize things like VBOs, VAAs and GLSL for rendering. Is this possible with the current state of Ogre and would using your new RenderSystem be the approach I should take ?
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Yes, the new rendersystem uses the existing VBO and GLSL support(with a couple minor tweaks) and uses the RTSS to emulate FFP. But you can certainly use your own shaders for everything. VAO support(is that what you mean by VAA?) is already in there.
And just a reminder: this is still early on and I would not recommend using it for any production work yet.
And just a reminder: this is still early on and I would not recommend using it for any production work yet.
-
- Gnoblar
- Posts: 13
- Joined: Sun Feb 28, 2010 6:50 pm
- x 1
Re: OpenGL 3+ RenderSystem
Awesome! This is exactly what I would like to see in Ogre. I was amazed to find out this isn't already implemented in Ogre when I returned from OpenGL, most (all?) major graphics engines (like Unigine) already have a separate layer supporting core 3.3/core 4.1
A few comments, I think its critical to implement UBO's and layouts, as this eases development a lot! It would be nice if you could specify the shader versions like you would normally do in raw opengl, i.e.
I didn't look at the 3+ RenderSystem source, yet (4 am right now), but I would gladly help/test it.
A few comments, I think its critical to implement UBO's and layouts, as this eases development a lot! It would be nice if you could specify the shader versions like you would normally do in raw opengl, i.e.
Code: Select all
#core 330
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
You should have no problem specifying shader language versions. Let me know if you do.
-
- OGRE Team Member
- Posts: 5433
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1341
Re: OpenGL 3+ RenderSystem
Hi! Just passing by to say I've fixed quite a bug in GL render systems (rev. 2886) where FBOs wouldn't use stencil buffers. If your GL3 code is based in that part (OgreGLFrameBuffer.cpp) it probably has the same bug. Don't worry, it's just a few lines.
Cheerio
Dark Sylinc
Cheerio
Dark Sylinc
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Thanks for the heads up! Got it fixed here locally.
-
- Gremlin
- Posts: 171
- Joined: Sun Jun 05, 2011 6:49 am
- Location: Vodka Federation
- x 18
Re: OpenGL 3+ RenderSystem
So it is still only fork? Why not in 1.8?
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Because it's not nearly ready and was never planned to be ready for 1.8. See our roadmap in, it's slated for 1.9.
-
- Ogre Magi
- Posts: 1137
- Joined: Mon May 07, 2007 3:43 am
- Location: Ossining, New York
- x 13
Re: OpenGL 3+ RenderSystem
I'm interested in these uniform buffers. I've not seen them before because I only use D3D9 and the current GL rendersystem.
I presume uniform buffers allow you to avoid having to upload a new set of uniforms with each draw call? You could allocate one for each renderable right?
As I understand it, with old gl and d3d9, you don't have to upload a new set if they don't need to be changed from the previous draw call, and you can also change only a subrange of that memory block if e.g. you have some scene parameters (shadow matrixes, lights, fog, time, etc) that are fixed for the whole frame buffer, but some other per draw call things that do change. You would put the scene stuff at the front and only change the rest of the buffer.
But with these explicit buffers, you could have per-material and per-object uniforms that are not uploaded to the GPU each draw call, and are also not consistent from one draw call to the next, by switching from one predefined buffer to another.
With that in mind, I would expect to have a buffer that has these different sections with different update characteristics.
* Scene uniforms, changing once per frame (fog, view matrix, proj matrix, lighting params, animation time offset, etc)
* Material uniforms, changing only when materials change (colour, texture params, shadow biases, etc)
* Object uniforms, (world matrix, bones, custom parameters, etc)
Is it possible to share buffers so that e.g. the scene uniforms can be updated once each frame and used by everyone? The material buffer modified once and automatically used by all users of that material? While still allowing per object stuff to be mutated when necessary (i.e. when the object moves).
I presume uniform buffers allow you to avoid having to upload a new set of uniforms with each draw call? You could allocate one for each renderable right?
As I understand it, with old gl and d3d9, you don't have to upload a new set if they don't need to be changed from the previous draw call, and you can also change only a subrange of that memory block if e.g. you have some scene parameters (shadow matrixes, lights, fog, time, etc) that are fixed for the whole frame buffer, but some other per draw call things that do change. You would put the scene stuff at the front and only change the rest of the buffer.
But with these explicit buffers, you could have per-material and per-object uniforms that are not uploaded to the GPU each draw call, and are also not consistent from one draw call to the next, by switching from one predefined buffer to another.
With that in mind, I would expect to have a buffer that has these different sections with different update characteristics.
* Scene uniforms, changing once per frame (fog, view matrix, proj matrix, lighting params, animation time offset, etc)
* Material uniforms, changing only when materials change (colour, texture params, shadow biases, etc)
* Object uniforms, (world matrix, bones, custom parameters, etc)
Is it possible to share buffers so that e.g. the scene uniforms can be updated once each frame and used by everyone? The material buffer modified once and automatically used by all users of that material? While still allowing per object stuff to be mutated when necessary (i.e. when the object moves).