[Ogre 2.1] Porting CEGUI to OGRE 2.1
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
@123iamking
The samples framework may not build for 2-1, try disabling the samples, i.e. CEGUI_SAMPLES_ENABLED=OFF
The samples framework may not build for 2-1, try disabling the samples, i.e. CEGUI_SAMPLES_ENABLED=OFF
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Thank dermont but I got build error for the project CEGUIOgreRenderer-0 which is really important to make CEGUI work with Ogre.dermont wrote:@123iamking
The samples framework may not build for 2-1, try disabling the samples, i.e. CEGUI_SAMPLES_ENABLED=OFF
I got error like: 'OT_TRIANGLE_LIST': is not a member of 'Ogre::v1::RenderOperation'. Here is the full 8 errors I got:
Code: Select all
Severity Code Description Project File Line Suppression State
Error C2039 'OT_TRIANGLE_LIST': is not a member of 'Ogre::v1::RenderOperation' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\GeometryBuffer.cpp 99
Error C2039 'pixelShader': is not a member of 'Ogre::HlmsCache' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1106
Error C2039 'unbindGpuProgram': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1118
Error C2039 'unbindGpuProgram': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1119
Error C2039 'vertexShader': is not a member of 'Ogre::HlmsCache' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1105
Error C2039 '_setHlmsBlendblock': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1034
Error C2039 '_setHlmsMacroblock': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1074
Error C2039 '_setProgramsFromHlms': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1107
Thanks for reading
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Did you make the changes to the CEGUI OgreRenderer that user _hack provided on the previous page for Hlms cache/pso?
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Ops... I didn't see that Thank dermont, I'll try it nowdermont wrote:Did you make the changes to the CEGUI OgreRenderer that user _hack provided on the previous page for Hlms cache/pso?
Edit:
I have tried _hack's post: cegui-ogre-2.1-pso.cpp (got it from pastebin - I paste it here in case anyone can't access pastebin)
Code: Select all
Index: cegui-0.8.7/cegui/src/RendererModules/Ogre/GeometryBuffer.cpp
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- cegui-0.8.7/cegui/src/RendererModules/Ogre/GeometryBuffer.cpp (revision 6f5c3e82eb608c5119a671efe675f6cceedb768e)
+++ cegui-0.8.7/cegui/src/RendererModules/Ogre/GeometryBuffer.cpp (revision )
@@ -96,7 +96,7 @@
// basic initialisation of render op
rop.vertexData = OGRE_NEW VertexData();
- rop.operationType = RenderOperation::OT_TRIANGLE_LIST;
+ rop.operationType = OT_TRIANGLE_LIST;
rop.useIndexes = false;
// setup vertex declaration for format we will use
Index: cegui-0.8.7/cegui/src/RendererModules/Ogre/Renderer.cpp
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- cegui-0.8.7/cegui/src/RendererModules/Ogre/Renderer.cpp (revision 6f5c3e82eb608c5119a671efe675f6cceedb768e)
+++ cegui-0.8.7/cegui/src/RendererModules/Ogre/Renderer.cpp (revision )
@@ -308,6 +308,8 @@
const Ogre::HlmsBlendblock* d_hlmsBlendblock;
//! HLMS block used to set sampling parameters
const Ogre::HlmsSamplerblock* d_hlmsSamplerblock;
+ //! HLMS cache used to store pso
+ Ogre::SharedPtr<Ogre::HlmsCache> d_hlmsCache;
#endif
//! What we think is the current blend mode to use
BlendMode d_activeBlendMode;
@@ -988,13 +990,25 @@
d_pimpl->d_pixelShaderParameters =
d_pimpl->d_pixelShader->createParameters();
-}
+
+#ifdef CEGUI_USE_OGRE_HLMS
+ d_pimpl->d_hlmsCache = Ogre::SharedPtr<Ogre::HlmsCache>(new Ogre::HlmsCache);
+ d_pimpl->d_hlmsCache->pso.vertexShader = d_pimpl->d_vertexShader;
+ d_pimpl->d_hlmsCache->pso.pixelShader = d_pimpl->d_pixelShader;
+ d_pimpl->d_hlmsCache->pso.blendblock = const_cast<Ogre::HlmsBlendblock*>(d_pimpl->d_hlmsBlendblock);
+ d_pimpl->d_hlmsCache->pso.macroblock = const_cast<Ogre::HlmsMacroblock*>(d_pimpl->d_hlmsMacroblock);
+#endif
+ }
//----------------------------------------------------------------------------//
void OgreRenderer::cleanupShaders()
{
#ifdef CEGUI_USE_OGRE_HLMS
Ogre::HlmsManager* hlmsManager = d_pimpl->d_ogreRoot->getHlmsManager();
+ if (d_pimpl->d_hlmsCache != NULL) {
+ d_pimpl->d_renderSystem->_hlmsPipelineStateObjectDestroyed(&d_pimpl->d_hlmsCache->pso);
+ d_pimpl->d_hlmsCache.setNull();
+ }
if (d_pimpl->d_hlmsBlendblock != NULL)
hlmsManager->destroyBlendblock(d_pimpl->d_hlmsBlendblock);
@@ -1036,10 +1050,7 @@
d_pimpl->d_activeBlendMode = mode;
-#ifdef CEGUI_USE_OGRE_HLMS
- // Apply the HLMS blend block to the render system
- d_pimpl->d_renderSystem->_setHlmsBlendblock(d_pimpl->d_hlmsBlendblock);
-#else
+#ifndef CEGUI_USE_OGRE_HLMS
if (d_pimpl->d_activeBlendMode == BM_RTT_PREMULTIPLIED)
d_pimpl->d_renderSystem->_setSceneBlending(SBF_ONE,
SBF_ONE_MINUS_SOURCE_ALPHA);
@@ -1076,10 +1087,7 @@
using namespace Ogre;
// initialise render settings
-#ifdef CEGUI_USE_OGRE_HLMS
- // Apply the HLMS macro block to the render system
- d_pimpl->d_renderSystem->_setHlmsMacroblock(d_pimpl->d_hlmsMacroblock);
-#else
+#ifndef CEGUI_USE_OGRE_HLMS
d_pimpl->d_renderSystem->setLightingEnabled(false);
d_pimpl->d_renderSystem->_setDepthBufferParams(false, false);
d_pimpl->d_renderSystem->_setDepthBias(0, 0);
@@ -1108,10 +1116,8 @@
if (isUsingShaders())
{
#ifdef CEGUI_USE_OGRE_HLMS
- Ogre::HlmsCache hlmsCache;
- hlmsCache.vertexShader = d_pimpl->d_vertexShader;
- hlmsCache.pixelShader = d_pimpl->d_pixelShader;
- d_pimpl->d_renderSystem->_setProgramsFromHlms(&hlmsCache);
+ d_pimpl->d_renderSystem->_hlmsPipelineStateObjectCreated(&d_pimpl->d_hlmsCache->pso);
+ d_pimpl->d_renderSystem->_setPipelineStateObject(&d_pimpl->d_hlmsCache->pso);
#else
if (Ogre::GpuProgram* prog = d_pimpl->d_vertexShader->_getBindingDelegate())
d_pimpl->d_renderSystem->bindGpuProgram(prog);
@@ -1122,8 +1128,12 @@
}
else
{
+#ifdef CEGUI_USE_OGRE_HLMS
+ d_pimpl->d_renderSystem->_setPipelineStateObject( 0 );
+#else
d_pimpl->d_renderSystem->unbindGpuProgram(Ogre::GPT_VERTEX_PROGRAM);
d_pimpl->d_renderSystem->unbindGpuProgram(Ogre::GPT_FRAGMENT_PROGRAM);
+#endif
}
}
but now I get 10 build errors
Code: Select all
Severity Code Description Project File Line Suppression State
Error C2039 'setLightingEnabled': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1085
Error C2039 'setShadingType': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1091
Error C2039 '_setColourBufferWriteEnabled': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1090
Error C2039 '_setCullingMode': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1088
Error C2039 '_setDepthBias': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1087
Error C2039 '_setDepthBufferParams': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1086
Error C2039 '_setFog': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1089
Error C2039 '_setPolygonMode': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1092
Error C2039 '_setSceneBlending': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1049
Error C2039 '_setSeparateSceneBlending': is not a member of 'Ogre::RenderSystem' CEGUIOgreRenderer-0 E:\Source\cegui\cegui\src\RendererModules\Ogre\Renderer.cpp 1053
According to this post
Kulik wrote:I think using the macro is fine. We never supported Ogre 2.1 anyway so if we "break" ABI for Ogre 2.1 it's not really a break.
-
- Bugbear
- Posts: 812
- Joined: Thu Dec 09, 2004 2:51 am
- x 42
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
You've not made the changes correctly. See attachment, you should double check if I've applied the changes correctly. Also included a demo, uses OIS but may be of some help to you.
- Attachments
-
- cegui.zip
- (20.41 KiB) Downloaded 121 times
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Thank you thank you thank you You are awesome! The project CEGUIOgreRenderer-0 is successfully built. About the demo, I don't know what to fill in the field PKG_CONFIG_EXECUTABLE for CMake, anyway I think I'll figure it out soon. But the important thing is: I can use CEGUI for Ogre 2.1 now, thank againdermont wrote:You've not made the changes correctly. See attachment, you should double check if I've applied the changes correctly. Also included a demo, uses OIS but may be of some help to you.
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Now I hit the error that Kohedlo has Hope this issue get fixed soonKohedlo wrote:is shader generator on DirectX 11 renderer give errors:
Code: Select all
OGRE_EXCEPT( Exception::ERR_RENDERINGAPI_ERROR, "The shader requires more input attributes/semantics than what the " "VertexArrayObject / v1::VertexDeclaration has to offer. You're " "missing a component", "D3D11HLSLProgram::getLayoutForPso" );
according HLSL code from dx11 shader generation. OpenGL variant works fine!
- Kohedlo
- Orc
- Posts: 435
- Joined: Fri Nov 27, 2009 3:34 pm
- Location: Ukraine, Sumy
- x 32
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Is variant OFF cegui error, comment the exception boxes. But CEGUI not visible. Fixing in progress.
i think error is less count of shader inputs in
Code: Select all
Dx11 render system
CEGUI
// OGRE_EXCEPT_EX( Exception::ERR_RENDERINGAPI_ERROR, hr,
// "Unable to create D3D11 input layout: " + errorDescription,
// "D3D11HLSLProgram::getLayoutForPso" );
// OGRE_EXCEPT( Exception::ERR_RENDERINGAPI_ERROR,
// "The shader requires more input attributes/semantics than what the "
// "VertexArrayObject / v1::VertexDeclaration has to offer. You're "
// "missing a component", "D3D11HLSLProgram::getLayoutForPso" );
// OGRE_EXCEPT_EX(Exception::ERR_RENDERINGAPI_ERROR, hr,
// "Failed to create sampler state\nError Description: " + errorDescription,
// "D3D11RenderSystem::_hlmsSamplerblockCreated" );
// OGRE_EXCEPT_EX(Exception::ERR_RENDERINGAPI_ERROR, hr,
// "Failed to create blend state\nError Description: " + errorDescription,
// "D3D11RenderSystem::_hlmsBlendblockCreated" );
// OGRE_EXCEPT_EX(Exception::ERR_RENDERINGAPI_ERROR, hr,
// "Failed to create rasterizer state\nError Description: " + errorDescription,
// "D3D11RenderSystem::_hlmsMacroblockCreated" );
comment: possible need add new shaderDesc.SystemValueType == verification or add from old ogre.2.//Account system-generated values which don't require a match in the PSO.
for( size_t j=0; j<numShaderInputs && numShaderInputsFound < numShaderInputs; ++j )
{
D3D11_SIGNATURE_PARAMETER_DESC shaderDesc = mD3d11ShaderInputParameters[j];
if( shaderDesc.SystemValueType == D3D_NAME_VERTEX_ID ||
shaderDesc.SystemValueType == D3D_NAME_PRIMITIVE_ID ||
shaderDesc.SystemValueType == D3D_NAME_INSTANCE_ID )
{
++numShaderInputsFound;
}
}
}
c++ game developer.
current project: Imperial Game Engine 2.5
current project: Imperial Game Engine 2.5
- Kohedlo
- Orc
- Posts: 435
- Joined: Fri Nov 27, 2009 3:34 pm
- Location: Ukraine, Sumy
- x 32
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Way to Port CEGUI for Ogre DirectX12 Pso finished on 90%. is comming.
c++ game developer.
current project: Imperial Game Engine 2.5
current project: Imperial Game Engine 2.5
- Kohedlo
- Orc
- Posts: 435
- Joined: Fri Nov 27, 2009 3:34 pm
- Location: Ukraine, Sumy
- x 32
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
- steps to update is next:
forst: inject to Ogre Cegui Renderer.cpp - PsoCaheHelper.
second: correct initialize Helper (see PsoCaheHelper.h help comments )
second step in detail:
in result CEGUI runs on OGRE 2.1 DirectX 12 PSO without errors.
But still unvisivle layers.
step3: (fixing unvisiblity) in process.
forst: inject to Ogre Cegui Renderer.cpp - PsoCaheHelper.
second: correct initialize Helper (see PsoCaheHelper.h help comments )
second step in detail:
Code: Select all
d_pimpl->d_hlmsCache = Ogre::SharedPtr<Ogre::PsoCacheHelper>(new Ogre::PsoCacheHelper(d_pimpl->d_renderSystem));
d_pimpl->d_hlmsCache->clearState();
Ogre::GpuProgramPtr vsConverted = d_pimpl->d_vertexShader;
Ogre::GpuProgramPtr psConverted = d_pimpl->d_pixelShader;
d_pimpl->d_hlmsCache->setVertexShader(vsConverted);
d_pimpl->d_hlmsCache->setPixelShader(psConverted);
CEGUI::OgreGeometryBuffer* gb =
CEGUI_NEW_AO CEGUI::OgreGeometryBuffer(*this, *d_pimpl->d_renderSystem);
d_pimpl->d_geometryBuffers.push_back(gb);
d_pimpl->d_hlmsCache->setVertexFormat(gb->d_renderOp.vertexData->
vertexDeclaration->convertToV2(),gb->d_renderOp.operationType,false);
d_pimpl->d_hlmsCache->setBlendblock(const_cast<Ogre::HlmsBlendblock*>(d_pimpl->d_hlmsBlendblock));
d_pimpl->d_hlmsCache->setMacroblock(const_cast<Ogre::HlmsMacroblock*>(d_pimpl->d_hlmsMacroblock));
But still unvisivle layers.
step3: (fixing unvisiblity) in process.
c++ game developer.
current project: Imperial Game Engine 2.5
current project: Imperial Game Engine 2.5
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
@Kohedlo: Awesome! Thanks for your effort
-
- Kobold
- Posts: 35
- Joined: Sun Sep 08, 2013 6:39 pm
- x 6
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
I'm using CEGUI (the unstable, 'default' branch version) with Ogre 2.1 and I've pushed my changes to the CEGUI repo. It is quite different compared to the v0-8 version, but might be useful to someone https://bitbucket.org/cegui/cegui/src/3 ... ew-default who can't switch to using the default branch version of CEGUI
- Kohedlo
- Orc
- Posts: 435
- Joined: Fri Nov 27, 2009 3:34 pm
- Location: Ukraine, Sumy
- x 32
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
i foresee and test in all ways coded, and variant with last repo souce not fix problem.
CEGUI 2.1 dx12 still unworkable.
I suggest that need write shader, or stydy difference of opengl and dx processes in deep, and watch every steps.
ps: this is major function. status unfixed. finding of way can take years.(open way working in opengl) Therefore need be in non-stop-action and make minor works, on projects. This is sumbling block lead to deep-deadline. only if need of function is criticall- then vote, and be organised additional code-stydy and seeking way to fix.
For example: I see microsoft support, where in one clearminded attitude were finded fixes in few seconds, that people cant write this same code in ten-years.
CEGUI 2.1 dx12 still unworkable.
I suggest that need write shader, or stydy difference of opengl and dx processes in deep, and watch every steps.
ps: this is major function. status unfixed. finding of way can take years.(open way working in opengl) Therefore need be in non-stop-action and make minor works, on projects. This is sumbling block lead to deep-deadline. only if need of function is criticall- then vote, and be organised additional code-stydy and seeking way to fix.
For example: I see microsoft support, where in one clearminded attitude were finded fixes in few seconds, that people cant write this same code in ten-years.
c++ game developer.
current project: Imperial Game Engine 2.5
current project: Imperial Game Engine 2.5
-
- Gremlin
- Posts: 152
- Joined: Sat Aug 12, 2017 4:16 pm
- x 4
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
I don't know but I'm just asking, CEGUI supports DirectX 11, and Ogre 2.1 supports DirectX 11. Is there any way we can just take Ogre 2.1 as a DirectX 11 program and use CEGUI DirectX 11 support?
IMHO, DirectX 12 is not much better than DirectX 11 in favor of performance (Except for AMD cards).
IMHO, DirectX 12 is not much better than DirectX 11 in favor of performance (Except for AMD cards).
-
- Greenskin
- Posts: 138
- Joined: Wed May 05, 2010 3:36 pm
- x 6
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
If you're working with the CEGUI default branch, the first thing that needs to be addressed is to update the Shaders.inl file to use the correct syntax for pixel shader model 5 under DX11. There is a small PR here that illustrates the changes for that.
But once I got past that, the issue was as @Kohedlo points out the fact that OGRE then complained about the vertex declaration:
My solution was a bit different than his but in the end the goal was to make sure that the vertex format was being set on the PSO.
Unfortunately I am still unsure why DX11 does not render while OpenGL does.
Back t a point @dark_sylinc made earlier wrt performance, I can definitely see how this is less than ideal. Even when CEGUI isn't drawing anything visually on DX11, there is a significant frame rate drop. I'll address the performance concerns during a code refactor step later; just need to get DX11 rendering at the least at this point.
But once I got past that, the issue was as @Kohedlo points out the fact that OGRE then complained about the vertex declaration:
Code: Select all
12:44:26: OGRE EXCEPTION(3:RenderingAPIException): The shader requires more input attributes/semantics than what the VertexArrayObject / v1::VertexDeclaration has to offer. You're missing a component in D3D11HLSLProgram::getLayoutForPso at C:\Personal\C++\Libraries\Ogre3D\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp (line 2087)
Unfortunately I am still unsure why DX11 does not render while OpenGL does.
Back t a point @dark_sylinc made earlier wrt performance, I can definitely see how this is less than ideal. Even when CEGUI isn't drawing anything visually on DX11, there is a significant frame rate drop. I'll address the performance concerns during a code refactor step later; just need to get DX11 rendering at the least at this point.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
That error happens when, for example, the shader declares TEXCOORD1 (even if it's not used) but the Vao does not have a second UV set (the first UV set would be TEXCOORD0).crancran wrote: ↑Fri Apr 06, 2018 8:32 pmMy solution was a bit different than his but in the end the goal was to make sure that the vertex format was being set on the PSO.Code: Select all
12:44:26: OGRE EXCEPTION(3:RenderingAPIException): The shader requires more input attributes/semantics than what the VertexArrayObject / v1::VertexDeclaration has to offer. You're missing a component in D3D11HLSLProgram::getLayoutForPso at C:\Personal\C++\Libraries\Ogre3D\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp (line 2087)
Unfortunately I am still unsure why DX11 does not render while OpenGL does.
Likewise if you use "COLOR" but there's no VES_DIFFUSE in your Vao, same error ensues. And so on...
Under OpenGL & D3D9, if the vertex declaration didn't properly provide the data to the shader; the API itself would patch that and provide a default value. Some libraries purposely relied on this behavior (I don't know if CEGUI is doing that) because it was convenient (i.e. if the shader uses "COLOR", and there is no VES_DIFFUSE; the same shader can still be used because the API will still provide a default white value) which was a very bad practice (the driver incurs in a lot of overhead to fix this). And D3D11 simply doesn't provide a default. It's just an error.
So that's likely the reason GL renders but DX11 doesn't. Check with RenderDoc the vertex declaration in GL. If a buffer is missing at the vertex format, then the slot will be in red. If everything's OK, then there's something wrong with DX11's shader or with the vertex declaration
-
- Greenskin
- Posts: 138
- Joined: Wed May 05, 2010 3:36 pm
- x 6
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Here's a screen shot of a frame capture under OpenGL.
So when I click on each of the glDrawArray calls, I see the same vertex declaration for them all with an associated buffer linked to the specified buffer slot in the vertex attributes area. I assume this means that all the data which should be there, is there.
Here's a screen shot of a frame capture under DirectX 11.
If I understand correctly, that means that the ID3D11InputLayout buffers aren't be set?
There was an issue with CEGUI where the call into OgreD3D11HLSLProgram.getLayoutForPso() failed because the vertex format was not being supplied. I modified the CEGUI code to provide the vertex format by doing this before I asked the PsoCacheHelper for the PSO:
Any idea what I could be missing?
So when I click on each of the glDrawArray calls, I see the same vertex declaration for them all with an associated buffer linked to the specified buffer slot in the vertex attributes area. I assume this means that all the data which should be there, is there.
Here's a screen shot of a frame capture under DirectX 11.
If I understand correctly, that means that the ID3D11InputLayout buffers aren't be set?
There was an issue with CEGUI where the call into OgreD3D11HLSLProgram.getLayoutForPso() failed because the vertex format was not being supplied. I modified the CEGUI code to provide the vertex format by doing this before I asked the PsoCacheHelper for the PSO:
Code: Select all
cache_helper->setVertexFormat( vertexElements, renderOperation, false );
render_system->_setPipelineStateObject( cache_helper->getPso() );
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
OK, that certainly was not what I was expecting.
By any chance, are your buffers BT_IMMUTABLE? GL doesn't care, but D3D11 RenderSystem will delay the actual creation of the vertex buffer(s) to attempt to batch & pack as much data as possible into the same buffer.
This happens in D3D11VaoManager::createDelayedImmutableBuffers, which is called every frame in D3D11VaoManager::_beginFrame (called by RenderSystem::_beginFrameOnce). It will also be forced-called if createAsyncTicket is called.
However if you're creating the immutable vertex buffers while inside Ogre's render loop, the createDelayedImmutableBuffers call won't catch your recently created buffers and chaos will ensue.
Another suggestion I can make is to step inside D3D11HLSLProgram::getLayoutForPso too see what semantics the shader is asking, and what is present in vertexElements.
By any chance, are your buffers BT_IMMUTABLE? GL doesn't care, but D3D11 RenderSystem will delay the actual creation of the vertex buffer(s) to attempt to batch & pack as much data as possible into the same buffer.
This happens in D3D11VaoManager::createDelayedImmutableBuffers, which is called every frame in D3D11VaoManager::_beginFrame (called by RenderSystem::_beginFrameOnce). It will also be forced-called if createAsyncTicket is called.
However if you're creating the immutable vertex buffers while inside Ogre's render loop, the createDelayedImmutableBuffers call won't catch your recently created buffers and chaos will ensue.
Another suggestion I can make is to step inside D3D11HLSLProgram::getLayoutForPso too see what semantics the shader is asking, and what is present in vertexElements.
-
- Greenskin
- Posts: 138
- Joined: Wed May 05, 2010 3:36 pm
- x 6
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
No they aren't created as BT_IMMUTABLE.dark_sylinc wrote: ↑Sat Apr 07, 2018 2:03 am By any chance, are your buffers BT_IMMUTABLE? GL doesn't care, but D3D11 RenderSystem will delay the actual creation of the vertex buffer(s) to attempt to batch & pack as much data as possible into the same buffer.
Right before CEGUI draws geometry, it determines whether a VBO has been allocated and has enough space. If nothing has been allocated or the space required in the existing VBO isn't sufficient it creates a new VBO using the following:
Code: Select all
d_hwBuffer = Ogre::v1::HardwareBufferManager::getSingleton().
createVertexBuffer(getVertexAttributeElementCount()*sizeof(float), count,
Ogre::v1::HardwareBuffer::HBU_DYNAMIC_WRITE_ONLY_DISCARDABLE,
false);
The shader requests 3 inputs and that is precisely the number found. The input vertex element vector contains a single item which has the defined layout of { POSITION, COLOR, TEXCOORD }. This leads to these values for each element type.Another suggestion I can make is to step inside D3D11HLSLProgram::getLayoutForPso too see what semantics the shader is asking, and what is present in vertexElements.
Code: Select all
Type VET_FLOAT3, Semantic Name POSITION, Index 0, Format: 6, Input Slot 0, Offset: 0
Type VET_COLOUR, Semantic Name COLOR, Index 0, Format: 2, Input Slot 0, Offset: 12
Type VET_FLOAT2, Semantic Name TEXCOORD, Index 0, Format: 16, Input Slot 0, Offset: 28
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
I think I know what the problem is. I had a quick glance on the repo default branch, and the call to _setRenderOperation is nowhere near to be found.
That's when I realized, CEGUI is using the D3D11RenderSystem::_render(const v1::RenderOperation& op) path, which has been kept for compatibility reasons, but it appears it's not working; because I don't see it calling IASetVertexBuffers anywhere. It must be broken.
Try calling _setRenderOperation and _render( const v1::CbDrawCallIndexed ) or _render( const v1::CbDrawCallStrip *cmd ) instead
If you're doing v1 rendering, you need to call that function. See RenderQueue::renderSingleObject. It must be called after _setPipelineStateObject and before _render.
Perhaps calling _setRenderOperation and then the broken D3D11RenderSystem::_render(const v1::RenderOperation& op) may just work. Though I suggest _render( const v1::CbDrawCallIndexed ) or _render( const v1::CbDrawCallStrip *cmd ) if possible since they are waaaay faster.
That's when I realized, CEGUI is using the D3D11RenderSystem::_render(const v1::RenderOperation& op) path, which has been kept for compatibility reasons, but it appears it's not working; because I don't see it calling IASetVertexBuffers anywhere. It must be broken.
Try calling _setRenderOperation and _render( const v1::CbDrawCallIndexed ) or _render( const v1::CbDrawCallStrip *cmd ) instead
If you're doing v1 rendering, you need to call that function. See RenderQueue::renderSingleObject. It must be called after _setPipelineStateObject and before _render.
Perhaps calling _setRenderOperation and then the broken D3D11RenderSystem::_render(const v1::RenderOperation& op) may just work. Though I suggest _render( const v1::CbDrawCallIndexed ) or _render( const v1::CbDrawCallStrip *cmd ) if possible since they are waaaay faster.
-
- Greenskin
- Posts: 138
- Joined: Wed May 05, 2010 3:36 pm
- x 6
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
I added the call to _setRenderOperation and that worked. It appears CEGUI default now works with OGRE 2.1 using both DX11 and OpenGL !!dark_sylinc wrote: ↑Sat Apr 07, 2018 5:34 am I think I know what the problem is. I had a quick glance on the repo default branch, and the call to _setRenderOperation is nowhere near to be found.
That's when I realized, CEGUI is using the D3D11RenderSystem::_render(const v1::RenderOperation& op) path, which has been kept for compatibility reasons, but it appears it's not working; because I don't see it calling IASetVertexBuffers anywhere. It must be broken.
Try calling _setRenderOperation and _render( const v1::CbDrawCallIndexed ) or _render( const v1::CbDrawCallStrip *cmd ) instead
If you're doing v1 rendering, you need to call that function. See RenderQueue::renderSingleObject. It must be called after _setPipelineStateObject and before _render.
(That is when I send up my PR and it gets merged in the branch of course).
The next step on my todo list is to include OGRE 2.2 compatibility. Part of that step is going to also involve reviewing the entire render pipeline that CEGUI uses under OGRE and see what we can optimize to use the newer/faster choices you've added thus far.dark_sylinc wrote: ↑Sat Apr 07, 2018 5:34 amPerhaps calling _setRenderOperation and then the broken D3D11RenderSystem::_render(const v1::RenderOperation& op) may just work. Though I suggest _render( const v1::CbDrawCallIndexed ) or _render( const v1::CbDrawCallStrip *cmd ) if possible since they are waaaay faster.
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
Yay! Congrats and good job!
Good luck! Most of the changes revolve around textures and how render targets are set.crancran wrote: ↑Sat Apr 07, 2018 6:36 am The next step on my todo list is to include OGRE 2.2 compatibility. Part of that step is going to also involve reviewing the entire render pipeline that CEGUI uses under OGRE and see what we can optimize to use the newer/faster choices you've added thus far.
Cheers!
Matias
-
- Greenskin
- Posts: 138
- Joined: Wed May 05, 2010 3:36 pm
- x 6
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
While adding support for 2.2, I stumbled across some code that I am unclear how to adapt. The code in question is:
I see this method now accepts a RenderPassDescriptor pointer rather than a RenderTarget pointer and I'm not sure what is the correct way by which I should construct the descriptor for this method call.
In one use case, I have the Ogre::Window object of which I am attempting to build the descriptor as follows:
The other use case is when I have an existing Ogre::TextureGpu pointer that represents a Ogre::TextureFlags::RenderToTexture object. In this case I am simply doing the following:
Are these approaches valid?
I ask because I have tested my code above or skipping setting the render target entirely and the rendered output remained unchanged and identical. On OpenGL, the GUI widgets & cursor are being drawn entirely black while on DX11 they seem to be transparent. I don't see anything different in Renderdoc that points me to something specific.
Any suggestions on what I should check?
Code: Select all
psoCacheHelper->setRenderTarget( renderTarget );
In one use case, I have the Ogre::Window object of which I am attempting to build the descriptor as follows:
Code: Select all
RenderPassDescriptor *renderDesc = renderSystem->createRenderPassDescriptor();
renderDesc->mColour[0].texture = window->getTexture();
renderDesc->mDepth.texture = window->getDepthTexture();
renderDesc->mStencil.texture = window->getStencilBuffer();
renderDesc->entriesModified(1);
Code: Select all
RenderPassDescriptor *renderDesc = renderSystem->createRenderPassDescriptor();
renderDesc->mColour[0].texture = renderTexture;
renderDesc->entriesModified(1);
I ask because I have tested my code above or skipping setting the render target entirely and the rendered output remained unchanged and identical. On OpenGL, the GUI widgets & cursor are being drawn entirely black while on DX11 they seem to be transparent. I don't see anything different in Renderdoc that points me to something specific.
Any suggestions on what I should check?
- dark_sylinc
- OGRE Team Member
- Posts: 5296
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1278
- Contact:
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
You have to call:
The Load & Store actions are set to 0 (which correspond to "DontCare"). Basically you're telling Ogre "I don't care what was in the RenderWindow before drawing the GUI; and I also don't care you keep what I write to it after I'm done so you can discard what I just did". Obviously this is invalid.
Set renderDesc->mColour.loadAction & storeAction (same for depth & stencil) to LoadAction::Load and StoreAction::StoreAndMultisampleResolve which are the safest approaches. I suggest you read the "What's new in Ogre 2.2" section from the manual (you'll have to build it using doxygen, or read it raw from Docs/src/manual/Ogre2.2.Changes.md; the December report has the same explanation of Load & Store actions though it may be missing some stuff as I wrote it earlier)
If CEGUI is being rendered inside a CompositorPass, that compositor pass should already have created a RenderPassDescriptor you can grab via mRenderSystem->getCurrentPassDescriptor() (this is ideal; because assuming LoadAction::Load and StoreAction::StoreAndMultisampleResolve works for most stuff, but can be bold, specially if the user is doing advanced MSAA rendering).
Compositor Passes call renderSystem->beginRenderPassDescriptor() and renderSystem->executeRenderPassDescriptorDelayedActions (and endRenderPassDescriptor, which for performance reasons should not be called unless if there's going to be another pass that calls again beginRenderPassDescriptor); but you may have to call them yourself if you're not doing it rendering inside a CompositorPass
You can construct a RenderPassDescriptor yourself, but I strongly recommend you leave it to a Compositor Pass as there are many small details to handle (see the docs on 2.2 porting), and thus CEGUI rendering should happen inside a compositor pass.
Code: Select all
renderDesc->entriesModified( RenderPassDescriptor::All );
This is correct but incomplete.crancran wrote: ↑Sun Apr 08, 2018 1:57 am In one use case, I have the Ogre::Window object of which I am attempting to build the descriptor as follows:Code: Select all
RenderPassDescriptor *renderDesc = renderSystem->createRenderPassDescriptor(); renderDesc->mColour[0].texture = window->getTexture(); renderDesc->mDepth.texture = window->getDepthTexture(); renderDesc->mStencil.texture = window->getStencilBuffer(); renderDesc->entriesModified(/*1*/ RenderPassDescriptor::All);
The Load & Store actions are set to 0 (which correspond to "DontCare"). Basically you're telling Ogre "I don't care what was in the RenderWindow before drawing the GUI; and I also don't care you keep what I write to it after I'm done so you can discard what I just did". Obviously this is invalid.
Set renderDesc->mColour.loadAction & storeAction (same for depth & stencil) to LoadAction::Load and StoreAction::StoreAndMultisampleResolve which are the safest approaches. I suggest you read the "What's new in Ogre 2.2" section from the manual (you'll have to build it using doxygen, or read it raw from Docs/src/manual/Ogre2.2.Changes.md; the December report has the same explanation of Load & Store actions though it may be missing some stuff as I wrote it earlier)
If CEGUI is being rendered inside a CompositorPass, that compositor pass should already have created a RenderPassDescriptor you can grab via mRenderSystem->getCurrentPassDescriptor() (this is ideal; because assuming LoadAction::Load and StoreAction::StoreAndMultisampleResolve works for most stuff, but can be bold, specially if the user is doing advanced MSAA rendering).
Compositor Passes call renderSystem->beginRenderPassDescriptor() and renderSystem->executeRenderPassDescriptorDelayedActions (and endRenderPassDescriptor, which for performance reasons should not be called unless if there's going to be another pass that calls again beginRenderPassDescriptor); but you may have to call them yourself if you're not doing it rendering inside a CompositorPass
You can construct a RenderPassDescriptor yourself, but I strongly recommend you leave it to a Compositor Pass as there are many small details to handle (see the docs on 2.2 porting), and thus CEGUI rendering should happen inside a compositor pass.
-
- Greenskin
- Posts: 138
- Joined: Wed May 05, 2010 3:36 pm
- x 6
Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1
I used this but unfortunately that did not change the outcome. I did inspect the descriptor and it seems to have a single color texture with a load action of Load and a store action of Store. I'm not sure I am convinced at this point if the problem lies with this or something else.dark_sylinc wrote: ↑Sun Apr 08, 2018 5:24 am If CEGUI is being rendered inside a CompositorPass, that compositor pass should already have created a RenderPassDescriptor you can grab via mRenderSystem->getCurrentPassDescriptor() (this is ideal; because assuming LoadAction::Load and StoreAction::StoreAndMultisampleResolve works for most stuff, but can be bold, specially if the user is doing advanced MSAA rendering).
I'll definitely give this a read and get back to you.dark_sylinc wrote: ↑Sun Apr 08, 2018 5:24 am I suggest you read the "What's new in Ogre 2.2" section from the manual (you'll have to build it using doxygen, or read it raw from Docs/src/manual/Ogre2.2.Changes.md; the December report has the same explanation of Load & Store actions though it may be missing some stuff as I wrote it earlier)
It seems like something simply isn't being given to OGRE under the 2.2 code path that could easily be a side affect of thinking one could easily just replace the 2.1 equivalent with the 2.2. I admittedly had hoped the port to 2.2 would have been straight forward but it seems to be much more involved than I had originally anticipated. Most of it was a shift from RenderTarget to a Window in certain contexts and in others a shift from RenderTarget and TexturePtr to the new TextureGpu objects.
Either way, I'll do some research and try to come back with a bit more in-depth and specific questions.