OpenGL 3+ RenderSystem

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

OpenGL 3+ RenderSystem

Post by masterfalcon »

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.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: OpenGL 3+ RenderSystem

Post by Klaim »

Followed :D

So by OpenGL 3+ , do you include 4+ or is it bound to 3.x ?
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

Yeah, supporting from 3 and above.
arrowdodger
Gnoblar
Posts: 11
Joined: Sun Mar 27, 2011 12:23 pm
x 1

Re: OpenGL 3+ RenderSystem

Post by arrowdodger »

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
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

Is that on linux? I don't think anyone has tried to get it compiling there yet.
arrowdodger
Gnoblar
Posts: 11
Joined: Sun Mar 27, 2011 12:23 pm
x 1

Re: OpenGL 3+ RenderSystem

Post by arrowdodger »

Kind of, it's FreeBSD. I'm not familiar with glew, so i don't know how to fix this.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

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.

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
	}
}
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.
th3flyboy
Gnoblar
Posts: 10
Joined: Sun Aug 16, 2009 3:52 am
x 1

Re: OpenGL 3+ RenderSystem

Post by th3flyboy »

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.
User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy
x 6

Re: OpenGL 3+ RenderSystem

Post by boyamer »

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
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

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.
User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy
x 6

Re: OpenGL 3+ RenderSystem

Post by boyamer »

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.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

We should keep the RTSS as a component. But it is being used for FFP emulation here too.
th3flyboy
Gnoblar
Posts: 10
Joined: Sun Aug 16, 2009 3:52 am
x 1

Re: OpenGL 3+ RenderSystem

Post by th3flyboy »

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.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

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.
evandropaulino
Gnoblar
Posts: 10
Joined: Mon Jun 06, 2011 9:42 pm

Re: OpenGL 3+ RenderSystem

Post by evandropaulino »

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?
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

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.
nenchev
Gnoblar
Posts: 1
Joined: Wed Jun 15, 2011 9:34 pm

Re: OpenGL 3+ RenderSystem

Post by nenchev »

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 ?
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

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.
End
Gnoblar
Posts: 13
Joined: Sun Feb 28, 2010 6:50 pm
x 1

Re: OpenGL 3+ RenderSystem

Post by End »

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.

Code: Select all

#core 330
I didn't look at the 3+ RenderSystem source, yet (4 am right now), but I would gladly help/test it.
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

You should have no problem specifying shader language versions. Let me know if you do.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: OpenGL 3+ RenderSystem

Post by dark_sylinc »

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
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

Thanks for the heads up! Got it fixed here locally.
User avatar
sleo
Gremlin
Posts: 171
Joined: Sun Jun 05, 2011 6:49 am
Location: Vodka Federation
x 18

Re: OpenGL 3+ RenderSystem

Post by sleo »

So it is still only fork? Why not in 1.8?
User avatar
masterfalcon
OGRE Team Member
OGRE Team Member
Posts: 4270
Joined: Sun Feb 25, 2007 4:56 am
Location: Bloomington, MN
x 126
Contact:

Re: OpenGL 3+ RenderSystem

Post by masterfalcon »

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.
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13
Contact:

Re: OpenGL 3+ RenderSystem

Post by sparkprime »

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).
Post Reply