Excellent, I'll have to have another go at using the compositors then, hopefully it'll be a lot easier since I have all the shaders written and working this time and there'll be less guess work as to why something is not being displayed correctly or at all. Keep up the good workholocronweaver wrote:Yes, using the output texture of one pass as the input texture of another is what compositors are all about! Most of my implementation time will be making sure multisample textures are accessible from the compositor.AusSkiller wrote:Will it be easy to reference the multisample textures of one framebuffer as inputs to the shader for another using compositors?
OpenGL 3+ RenderSystem
-
- Gremlin
- Posts: 158
- Joined: Wed Nov 28, 2012 1:38 am
- x 13
Re: OpenGL 3+ RenderSystem
-
- OGRE Expert User
- Posts: 1119
- Joined: Sat Jan 01, 2011 7:57 pm
- x 216
Re: OpenGL 3+ RenderSystem
Just to let you know, I have upgraded to nvidia driver 331.20 and the logObjectInfo issue is indeed gone now.
Code: Select all
nvidia-smi
Tue Jan 28 18:06:47 2014
+------------------------------------------------------+
| NVIDIA-SMI 331.20 Driver Version: 331.20 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 GeForce GTX 560 Ti Off | 0000:02:00.0 N/A | N/A |
| 40% 38C N/A N/A / N/A | 203MiB / 1023MiB | N/A Default |
+-------------------------------+----------------------+----------------------+
+-----------------------------------------------------------------------------+
| Compute processes: GPU Memory |
| GPU PID Process name Usage |
|=============================================================================|
| 0 Not Supported |
+-----------------------------------------------------------------------------+
-
- Gnoblar
- Posts: 2
- Joined: Fri Feb 21, 2014 9:57 am
- x 1
Re: OpenGL 3+ RenderSystem
Hi guys,
my company (http://coherent-labs.com) is building a demo project with Ogre. I'm integrating my voxel polygonization (http://stoyannk.wordpress.com/voxels-library/) library and stumbled upon some limitations of the OGL3Plus rendering system.
I have a couple of feature suggestions that are relatively easy to implement but will give big impact on the rendering system. I'm using the 1.9 branch which as I understand is the most stable.
1. There is a bug in the interpretation of IT_32BIT as GL_UNSIGNED_BYTE when using index buffers - should be GL_UNSIGNED_INT. OgreGL3PlusRenderSystem.cpp:1856 and
OgreGL3PlusRenderSystem.cpp : 1840. It's fixed in the master branch.
2. There is no way to pass integer vertex attributes in the system as integers. glVertexAttribPointer is always used which transforms the integer attributes in floats. A solution that I used because we need this in our demo is to add new Ogre attribute types that use glVertexAttribIPointer and thus allow passing integers in the vertex shader. You can see the changes in https://bitbucket.org/stoyannk/ogre-coh ... d8aae3ab35
All the changes we are making can be found on https://bitbucket.org/stoyannk/ogre-coherentlabs/
I'm unable to provide a full pull request for the feature for the lack of time and full knowledge of the policies for adding features to render systems in Ogre. The forum seems a better choice.
my company (http://coherent-labs.com) is building a demo project with Ogre. I'm integrating my voxel polygonization (http://stoyannk.wordpress.com/voxels-library/) library and stumbled upon some limitations of the OGL3Plus rendering system.
I have a couple of feature suggestions that are relatively easy to implement but will give big impact on the rendering system. I'm using the 1.9 branch which as I understand is the most stable.
1. There is a bug in the interpretation of IT_32BIT as GL_UNSIGNED_BYTE when using index buffers - should be GL_UNSIGNED_INT. OgreGL3PlusRenderSystem.cpp:1856 and
OgreGL3PlusRenderSystem.cpp : 1840. It's fixed in the master branch.
2. There is no way to pass integer vertex attributes in the system as integers. glVertexAttribPointer is always used which transforms the integer attributes in floats. A solution that I used because we need this in our demo is to add new Ogre attribute types that use glVertexAttribIPointer and thus allow passing integers in the vertex shader. You can see the changes in https://bitbucket.org/stoyannk/ogre-coh ... d8aae3ab35
All the changes we are making can be found on https://bitbucket.org/stoyannk/ogre-coherentlabs/
I'm unable to provide a full pull request for the feature for the lack of time and full knowledge of the policies for adding features to render systems in Ogre. The forum seems a better choice.
-
- Google Summer of Code Student
- Posts: 273
- Joined: Mon Oct 29, 2012 8:52 pm
- Location: Princeton, NJ
- x 47
Re: OpenGL 3+ RenderSystem
Unless it has been backported, v1-9 does not include any of my work from the 2013 GSoC which fixed many, many bugs. I would recommend using the default branch if you want GL3+ bug fixes, and then switch to the 1.10 branch when it is released.stoyannk wrote:I'm using the 1.9 branch which as I understand is the most stable.
You mean the default branch? I fixed the IT_32BIT case you mention on the bleeding edge repo - the IT_16BIT I spotted during the GSoC and fixed last year and should be in default.1. There is a bug in the interpretation of IT_32BIT as GL_UNSIGNED_BYTE when using index buffers - should be GL_UNSIGNED_INT. OgreGL3PlusRenderSystem.cpp:1856 and
OgreGL3PlusRenderSystem.cpp :1840. It's fixed in the master branch.
I overlooked this problem, thanks for spotting it! I think a new VET type is unnecessary - simply adding cases to use glVertexAttribIPointer for non-float base VET types should suffice. Unless I am missing something?2. There is no way to pass integer vertex attributes in the system as integers. glVertexAttribPointer is always used which transforms the integer attributes in floats. A solution that I used because we need this in our demo is to add new Ogre attribute types that use glVertexAttribIPointer and thus allow passing integers in the vertex shader.
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
You're right, the INT and UINT VET types were added last year before GSoC but I never got around to hooking up everything else for it.I overlooked this problem, thanks for spotting it! I think a new VET type is unnecessary - simply adding cases to use glVertexAttribIPointer for non-float base VET types should suffice. Unless I am missing something?2. There is no way to pass integer vertex attributes in the system as integers. glVertexAttribPointer is always used which transforms the integer attributes in floats. A solution that I used because we need this in our demo is to add new Ogre attribute types that use glVertexAttribIPointer and thus allow passing integers in the vertex shader.
-
- Google Summer of Code Student
- Posts: 273
- Joined: Mon Oct 29, 2012 8:52 pm
- Location: Princeton, NJ
- x 47
Re: OpenGL 3+ RenderSystem
I have taken care of them in my repo. Looking to merge upstream within the next two weeks.masterfalcon wrote:You're right, the INT and UINT VET types were added last year before GSoC but I never got around to hooking up everything else for it.
-
- Gnoblar
- Posts: 2
- Joined: Fri Feb 21, 2014 9:57 am
- x 1
Re: OpenGL 3+ RenderSystem
Thank you very much for the swift response!masterfalcon wrote: I overlooked this problem, thanks for spotting it! I think a new VET type is unnecessary - simply adding cases to use glVertexAttribIPointer for non-float base VET types should suffice. Unless I am missing something?
You're right, the INT and UINT VET types were added last year before GSoC but I never got around to hooking up everything else for it.
For the new VET types - it depends on how much flexibility you want to provide. The current way things happen is still valid - it's just that INT and UINT attributes get transformed to floats by OpenGL. I suppose somebody might need that. That's why in my impl. I added new types - to cover all cases. I haven't checked how things are handled in your other RenderSystems. If you want to keep the behavior consistent (which I believe you do) and on other systems the attribs are not cast to float - than the new VETs are indeed unnecessary.
-
- Gremlin
- Posts: 155
- Joined: Thu Sep 17, 2009 8:43 pm
- Location: Austria
- x 9
Re: OpenGL 3+ RenderSystem
Ever since I am using the Ogre OGL3+ renderer in my application, I have noticed rendering issue (texture is just black filled with (0,0,0,255) texels according to OpenGL GPU debugger) when CEGUI is rendering to FBOs/RTTs in my application. This bug doesnt appear in said application when using Ogre D3D9 renderer. Since we only access the rendering indirectly via Ogre (except for proving hlsl and glsl shaders) , there must have be some different in the Ogre-OGL3-internal FBOs/RTT rendering that causes this. Specifically, the rendering seems to fail on _only_ the first instance of any FBO ever being rendered. At least this is how it seems. When the window is re-rendered it works fine. I am inconclusive if it is a CEGUI related issue, but since it works with the Ogre D3D9 renderer i dont think it is not. Has anything specifically changed in the behavior of FBOs in OGL3?
I should probably also try the old Ogre OGL Renderer. EDIT: I tried and when only using the interface it works fine with FBOs in Ogre OGL Renderer, but exactly the same setup witrh OGL3+ Renderer results in the first rendered FBO being black again.
Btw i added changes that support the latest default branch version of Ogre to CEGUI v0-8 repo.
I should probably also try the old Ogre OGL Renderer. EDIT: I tried and when only using the interface it works fine with FBOs in Ogre OGL Renderer, but exactly the same setup witrh OGL3+ Renderer results in the first rendered FBO being black again.
Btw i added changes that support the latest default branch version of Ogre to CEGUI v0-8 repo.
-
- OGRE Retired Team Member
- Posts: 972
- Joined: Mon Jun 02, 2008 6:52 pm
- Location: Berlin
- x 65
Re: OpenGL 3+ RenderSystem
I just discovered this:
http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/
Does the GL3+ system utilize the "gems" shown there somehow? Or is this even relevant to the rendersystem?
I'm not really deep into OpenGL low level stuff, but these videos and slides do seem helpful to those that are.
http://blogs.nvidia.com/blog/2014/03/20/opengl-gdc2014/
Does the GL3+ system utilize the "gems" shown there somehow? Or is this even relevant to the rendersystem?
I'm not really deep into OpenGL low level stuff, but these videos and slides do seem helpful to those that are.
-
- OGRE Team Member
- Posts: 4270
- Joined: Sun Feb 25, 2007 4:56 am
- Location: Bloomington, MN
- x 126
Re: OpenGL 3+ RenderSystem
Not really yet but that's definitely something that I'd like to work toward.
-
- Google Summer of Code Student
- Posts: 273
- Joined: Mon Oct 29, 2012 8:52 pm
- Location: Princeton, NJ
- x 47
Re: OpenGL 3+ RenderSystem
@Ident: I apologize for the long delayed reply. To begin, are you using my GL3+ beta repo or the primary OGRE repo?
Interesting. I will look into this on my own, but if you could you provide a reproducible test case that would seriously speed things up.Ident wrote:Specifically, the rendering seems to fail on _only_ the first instance of any FBO ever being rendered.
I am not sure as masterfalcon is the one who implemented it and I have barely touched it.I am inconclusive if it is a CEGUI related issue, but since it works with the Ogre D3D9 renderer i dont think it is not. Has anything specifically changed in the behavior of FBOs in OGL3?
Great!Btw i added changes that support the latest default branch version of Ogre to CEGUI v0-8 repo.
-
- Gremlin
- Posts: 155
- Joined: Thu Sep 17, 2009 8:43 pm
- Location: Austria
- x 9
Re: OpenGL 3+ RenderSystem
I am not sure how to write a reconstruction for this in a simple Ogre demo, because I am not sure what causes this in detail. I can only tell from my own observations. I assume it is too much to ask for, to expect you to build CEGUI and set it up and all that, just for this bug. Basically in CEGUI all that has to be done afaik is to create a FrameWindow or better two, both with autoRenderingSurface (that's the FBO) on, and then, if they are just displayed in default state without anything being done to them that would request a redraw, the one of them would not have its FBO texture correctly drawn (its empty/black as checked in the debugger). Currently I am extremely busy otherwise I would simplify my project and send it to you ):
-
- Halfling
- Posts: 40
- Joined: Thu Aug 30, 2012 1:43 pm
- Location: France
- x 3
Re: OpenGL 3+ RenderSystem
Hi masterfalcon, holoconweaver and others,
I'd like to make the render system (finally) work on Mesa, which unlike nVidia and AMD's proprietary implementations of OpenGL doesn't expose symbols for extension functions:
edit: All things considered that was a rhetorical question, since the old GL plugin used GLEW to initialize the function pointers, i'll be back with a patch
I'd like to make the render system (finally) work on Mesa, which unlike nVidia and AMD's proprietary implementations of OpenGL doesn't expose symbols for extension functions:
Should I use GLEW or mimic the old GL rendersys's way of retrieving them?./SampleBrowser: symbol lookup error: RenderSystem_GL3Plus.so.1.9.0: undefined symbol: glXCreateContextAttribsARB
edit: All things considered that was a rhetorical question, since the old GL plugin used GLEW to initialize the function pointers, i'll be back with a patch
-
- Google Summer of Code Student
- Posts: 273
- Joined: Mon Oct 29, 2012 8:52 pm
- Location: Princeton, NJ
- x 47
Re: OpenGL 3+ RenderSystem
Are you using my cutting edge GL3+ repo? I am pretty sure this has already been fixed there, though the repo is in somewhat of a state of transition at the moment as I finalize the new window system.
-
- Halfling
- Posts: 40
- Joined: Thu Aug 30, 2012 1:43 pm
- Location: France
- x 3
Re: OpenGL 3+ RenderSystem
Your repo is indeed working with Mesa, neat! When will your work be pushed into mainline?holocronweaver wrote:Are you using my cutting edge GL3+ repo? I am pretty sure this has already been fixed there, though the repo is in somewhat of a state of transition at the moment as I finalize the new window system.
There are still many issues on my Evergreen R600 laptop with Mesa built from git (Xorg Edgers):
- Many rendering issues
- (Most) characters are black squares
- Quitting doesn't work, I have to kill the process
-
- Google Summer of Code Student
- Posts: 273
- Joined: Mon Oct 29, 2012 8:52 pm
- Location: Princeton, NJ
- x 47
Re: OpenGL 3+ RenderSystem
I am surprised it runs at all on Mesa. Very happy to hear it! Either today or tomorrow I will be pushing the new windowing system, which should fix at least the problem with Quit not quitting.
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
Re: OpenGL 3+ RenderSystem
Hello !
After years of using the D3D Rendersystem, I just tried the GL3+ Rendersystem to see how it performs.
I'm porting my custom shaders and everything is ok so far.
But I'm trying to add the support of hardware pcf, like in D3D11, as it is now possible with GLSL 330+.
So as specified in the various documentation I've found, I've implemented the functions related to texture comparison in the render system:
And changed my pixel shader shadow sampling code from this :
to this:
Which should do thejob, shadowSampler being a "sampler2DShadow", as requested.
However, the result is always 0, so something must be wrong, but I have no clue, except that this may not work with a texture type different from GL_DEPTH, but it's not clear, and I don't know if it's possible to use PF_DEPTH as a format for shadow textures in Ogre.
After years of using the D3D Rendersystem, I just tried the GL3+ Rendersystem to see how it performs.
I'm porting my custom shaders and everything is ok so far.
But I'm trying to add the support of hardware pcf, like in D3D11, as it is now possible with GLSL 330+.
So as specified in the various documentation I've found, I've implemented the functions related to texture comparison in the render system:
Code: Select all
void GL3PlusRenderSystem::_setTextureUnitCompareFunction(size_t unit, CompareFunction function)
{
if (!activateGLTextureUnit(unit))
return;
OGRE_CHECK_GL_ERROR(glSamplerParameteri(mTextureTypes[unit], GL_TEXTURE_COMPARE_FUNC, convertCompareFunction(function)));
activateGLTextureUnit(0);
}
void GL3PlusRenderSystem::_setTextureUnitCompareEnabled(size_t unit, bool compare)
{
if (!activateGLTextureUnit(unit))
return;
mTextureCompareEnabled = compare;
OGRE_CHECK_GL_ERROR(glSamplerParameteri(mTextureTypes[unit], GL_TEXTURE_COMPARE_MODE, compare ? GL_COMPARE_REF_TO_TEXTURE:GL_NONE));
activateGLTextureUnit(0);
}
Code: Select all
float shadow = (shadowMapPos.z <= texture(shadowMap, shadowMapPos.xy ).r) ? 1.0 : 0.0;
Code: Select all
float shadow = texture( shadowSampler, vec3(shadowMapPos.xy, shadowMapPos.z));
However, the result is always 0, so something must be wrong, but I have no clue, except that this may not work with a texture type different from GL_DEPTH, but it's not clear, and I don't know if it's possible to use PF_DEPTH as a format for shadow textures in Ogre.
-
- OGRE Team Member
- Posts: 5433
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1341
Re: OpenGL 3+ RenderSystem
The GL specs leave using a texture2Dshadow on non-depth formats as undefined behavior. I've seen it work on AMD on a FLOAT32_R format, but I dunno about the other vendors and other formats.Crashy wrote:However, the result is always 0, so something must be wrong, but I have no clue, except that this may not work with a texture type different from GL_DEPTH, but it's not clear, and I don't know if it's possible to use PF_DEPTH as a format for shadow textures in Ogre.
Depth textures support was added to Ogre in 2.1
Btw the comparison modes must be set after setting the textures, which is something you don't need in D3D11. If you're setting the modes first, then the texture, it's not going to work on GL.
Ogre 2.1 also got rid of that annoyance by using the newer GL sampler objects.
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
Re: OpenGL 3+ RenderSystem
Thank you very much. I'll try to change a few things to see how it behaves.
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
Re: OpenGL 3+ RenderSystem
Hi !
I've done some test of my current project that uses the Gl3+ Rendersystem on a computer fitted with an Intel HD 4000, and experienced a few errors during the compilation of shaders, because of that piece of code in OgreGLSLShader.cpp
The Intel HD compiler doesn't like at all using arrays without specified size in programs other than geometry programs.
That said, if I comment this code, everything works fine, on both nVidia and Intel devices.
According to GLSL documentation, the variables added by this piece of code to the shader are built-in, so why are we doing this ?
Thanks.
I've done some test of my current project that uses the Gl3+ Rendersystem on a computer fitted with an Intel HD 4000, and experienced a few errors during the compilation of shaders, because of that piece of code in OgreGLSLShader.cpp
Code: Select all
if (Root::getSingleton().getRenderSystem()->getCapabilities()->hasCapability(RSC_SEPARATE_SHADER_OBJECTS))
{
// Assume blocks are missing if gl_Position is missing.
if (mSource.find("vec4 gl_Position") == String::npos)
{
size_t mainPos = mSource.find("void main");
// Only add blocks if shader is not a child
// shader, i.e. has a main function.
if (mainPos != String::npos)
{
size_t versionPos = mSource.find("#version");
int shaderVersion = StringConverter::parseInt(mSource.substr(versionPos+9, 3));
if (shaderVersion >= 150)
{
size_t belowVersionPos = mSource.find("\n", versionPos) + 1;
switch (mType)
{
case GPT_VERTEX_PROGRAM:
mSource.insert(belowVersionPos, "out gl_PerVertex\n{\nvec4 gl_Position;\nfloat gl_PointSize;\nfloat gl_ClipDistance[];\n};\n\n");
break;
case GPT_GEOMETRY_PROGRAM:
mSource.insert(belowVersionPos, "out gl_PerVertex\n{\nvec4 gl_Position;\nfloat gl_PointSize;\nfloat gl_ClipDistance[];\n};\n\n");
mSource.insert(belowVersionPos, "in gl_PerVertex\n{\nvec4 gl_Position;\nfloat gl_PointSize;\nfloat gl_ClipDistance[];\n} gl_in[];\n\n");
break;
case GPT_DOMAIN_PROGRAM:
mSource.insert(belowVersionPos, "out gl_PerVertex\n{\nvec4 gl_Position;\nfloat gl_PointSize;\nfloat gl_ClipDistance[];\n};\n\n");
mSource.insert(belowVersionPos, "in gl_PerVertex\n{\nvec4 gl_Position;\nfloat gl_PointSize;\nfloat gl_ClipDistance[];\n} gl_in[];\n\n");
break;
case GPT_HULL_PROGRAM:
mSource.insert(belowVersionPos, "out gl_PerVertex\n{\nvec4 gl_Position;\nfloat gl_PointSize;\nfloat gl_ClipDistance[];\n} gl_out[];\n\n");
mSource.insert(belowVersionPos, "in gl_PerVertex\n{\nvec4 gl_Position;\nfloat gl_PointSize;\nfloat gl_ClipDistance[];\n} gl_in[];\n\n");
break;
case GPT_FRAGMENT_PROGRAM:
case GPT_COMPUTE_PROGRAM:
// Fragment and compute shaders do
// not have standard blocks.
break;
}
}
}
}
}
That said, if I comment this code, everything works fine, on both nVidia and Intel devices.
According to GLSL documentation, the variables added by this piece of code to the shader are built-in, so why are we doing this ?
Thanks.
-
- OGRE Team Member
- Posts: 2106
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1132
Re: OpenGL 3+ RenderSystem
They are not predefined with separate shader objects
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
Re: OpenGL 3+ RenderSystem
Indeed, I was looking for some docs and most of examples of separate programs I've found are talking about this, but in my case commenting this code while using separate programs works just the same, and that's pretty confusing.
-
- OGRE Team Member
- Posts: 2106
- Joined: Sun Mar 30, 2014 2:51 pm
- x 1132
Re: OpenGL 3+ RenderSystem
driver quirks..
added RSC_GLSL_SSO_REDECLARE which you can unset as needed:
https://github.com/OGRECave/ogre/pull/3 ... 0872ad6291
added RSC_GLSL_SSO_REDECLARE which you can unset as needed:
https://github.com/OGRECave/ogre/pull/3 ... 0872ad6291
-
- Google Summer of Code Student
- Posts: 1005
- Joined: Wed Jan 08, 2003 9:15 pm
- Location: Lyon, France
- x 49
Re: OpenGL 3+ RenderSystem
Thanks a lot ! I was suspecting a driver related issue. I've not tested it on AMD devices right now but I fear things will be different there too
-
- Orc Shaman
- Posts: 737
- Joined: Fri May 31, 2013 2:28 am
- x 65
Re: OpenGL 3+ RenderSystem
since my cursed "optimus" nvidia 660m started melting my lappy's plastic cover( i think its totaly fried ) i'm left only with my integrated HD4000( until i get rich )
last time i checked( about a year ago ) HLMS port with GL/GL3+ and HD4000 nothing rendered, other samples worked, and with nvidia GL3+ PBS sample also worked, so i assumed that its a driver bug, and carried on with my life but without openGL...
crashy, did you have success with PBS sample GL/GL3+ and HD4000?
is this bug related somehow? is this bug resolved?
can i have now my shiny PBS robots on HD4000 with GL/GL3+???
thanks guys...
last time i checked( about a year ago ) HLMS port with GL/GL3+ and HD4000 nothing rendered, other samples worked, and with nvidia GL3+ PBS sample also worked, so i assumed that its a driver bug, and carried on with my life but without openGL...
crashy, did you have success with PBS sample GL/GL3+ and HD4000?
is this bug related somehow? is this bug resolved?
can i have now my shiny PBS robots on HD4000 with GL/GL3+???
thanks guys...
the woods are lovely dark and deep
but i have promises to keep
and miles to code before i sleep
and miles to code before i sleep..
coolest videos link( two minutes paper )...
https://www.youtube.com/user/keeroyz/videos
but i have promises to keep
and miles to code before i sleep
and miles to code before i sleep..
coolest videos link( two minutes paper )...
https://www.youtube.com/user/keeroyz/videos