[Ogre 2.1] Porting CEGUI to OGRE 2.1

Discussion area about developing with Ogre2 branches (2.1, 2.2 and beyond)
dermont
Orc Shaman
Posts: 782
Joined: Thu Dec 09, 2004 2:51 am
x 9

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dermont » Tue Oct 17, 2017 6:19 am

@123iamking

The samples framework may not build for 2-1, try disabling the samples, i.e. CEGUI_SAMPLES_ENABLED=OFF
0 x

123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by 123iamking » Tue Oct 17, 2017 8:54 am

dermont wrote:@123iamking

The samples framework may not build for 2-1, try disabling the samples, i.e. CEGUI_SAMPLES_ENABLED=OFF
Thank dermont :) but I got build error for the project CEGUIOgreRenderer-0 which is really important to make CEGUI work with Ogre.
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	
So here I am, stuck with the project CEGUIOgreRenderer-0 :) Please help me

Thanks for reading :)
0 x

dermont
Orc Shaman
Posts: 782
Joined: Thu Dec 09, 2004 2:51 am
x 9

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dermont » Tue Oct 17, 2017 11:51 am

Did you make the changes to the CEGUI OgreRenderer that user _hack provided on the previous page for Hlms cache/pso?
0 x

123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by 123iamking » Tue Oct 17, 2017 11:59 am

dermont wrote:Did you make the changes to the CEGUI OgreRenderer that user _hack provided on the previous page for Hlms cache/pso?
Ops... I didn't see that :oops: Thank dermont, I'll try it now :)

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 :cry:

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	
I really hope CEGUI would officially supports Ogre 2.1 soon.
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.
0 x

dermont
Orc Shaman
Posts: 782
Joined: Thu Dec 09, 2004 2:51 am
x 9

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dermont » Wed Oct 18, 2017 3:52 am

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 40 times
1 x

123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by 123iamking » Wed Oct 18, 2017 6:03 am

dermont 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.
Thank you thank you thank you :D 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 again :D
0 x

123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by 123iamking » Wed Oct 18, 2017 9:14 am

Kohedlo 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!
Now I hit the error that Kohedlo has :cry: Hope this issue get fixed soon :)
0 x

User avatar
Kohedlo
Orc
Posts: 435
Joined: Fri Nov 27, 2009 3:34 pm
Location: Ukraine, Sumy
x 11
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by Kohedlo » Wed Oct 18, 2017 9:09 pm

Is variant OFF cegui error, comment the exception boxes. But CEGUI not visible. Fixing in progress.

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" );
       
       
       
i think error is less count of shader inputs in
//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;
}
}
}
comment: possible need add new shaderDesc.SystemValueType == verification or add from old ogre.2.
1 x
c++ game developer.
current project: Imperial Game Engine 2.5
Image

User avatar
Kohedlo
Orc
Posts: 435
Joined: Fri Nov 27, 2009 3:34 pm
Location: Ukraine, Sumy
x 11
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by Kohedlo » Thu Oct 19, 2017 6:03 pm

Way to Port CEGUI for Ogre DirectX12 Pso finished on 90%. is comming.
1 x
c++ game developer.
current project: Imperial Game Engine 2.5
Image

User avatar
Kohedlo
Orc
Posts: 435
Joined: Fri Nov 27, 2009 3:34 pm
Location: Ukraine, Sumy
x 11
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by Kohedlo » Thu Oct 19, 2017 6:08 pm

- 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:

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));	
	
in result CEGUI runs on OGRE 2.1 DirectX 12 PSO without errors.
But still unvisivle layers.

step3: (fixing unvisiblity) in process. :idea:
1 x
c++ game developer.
current project: Imperial Game Engine 2.5
Image

123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by 123iamking » Fri Oct 20, 2017 1:23 am

@Kohedlo: Awesome! Thanks for your effort :D
0 x

Boost113
Kobold
Posts: 35
Joined: Sun Sep 08, 2013 6:39 pm
x 5

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by Boost113 » Wed Oct 25, 2017 3:41 pm

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
0 x

User avatar
Kohedlo
Orc
Posts: 435
Joined: Fri Nov 27, 2009 3:34 pm
Location: Ukraine, Sumy
x 11
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by Kohedlo » Tue Oct 31, 2017 12:17 am

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.
1 x
c++ game developer.
current project: Imperial Game Engine 2.5
Image

123iamking
Gremlin
Posts: 152
Joined: Sat Aug 12, 2017 4:16 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by 123iamking » Tue Oct 31, 2017 3:24 am

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).
0 x

crancran
Greenskin
Posts: 136
Joined: Wed May 05, 2010 3:36 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by crancran » Fri Apr 06, 2018 8:32 pm

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:

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)
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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4112
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 242
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dark_sylinc » Fri Apr 06, 2018 11:22 pm

crancran wrote:
Fri Apr 06, 2018 8:32 pm

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)
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.
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).
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
0 x

crancran
Greenskin
Posts: 136
Joined: Wed May 05, 2010 3:36 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by crancran » Sat Apr 07, 2018 1:39 am

Here's a screen shot of a frame capture under OpenGL.
Image

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.
Image

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() );
Any idea what I could be missing?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4112
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 242
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dark_sylinc » Sat Apr 07, 2018 2:03 am

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.
0 x

crancran
Greenskin
Posts: 136
Joined: Wed May 05, 2010 3:36 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by crancran » Sat Apr 07, 2018 2:17 am

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.
No they aren't created as BT_IMMUTABLE.

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);
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.
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.

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
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4112
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 242
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dark_sylinc » 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.

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.
0 x

crancran
Greenskin
Posts: 136
Joined: Wed May 05, 2010 3:36 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by crancran » Sat Apr 07, 2018 6:36 am

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.
I added the call to _setRenderOperation and that worked. It appears CEGUI default now works with OGRE 2.1 using both DX11 and OpenGL !!
(That is when I send up my PR and it gets merged in the branch of course).
dark_sylinc wrote:
Sat Apr 07, 2018 5:34 am
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.
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.
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4112
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 242
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dark_sylinc » Sat Apr 07, 2018 6:45 am

crancran wrote:
Sat Apr 07, 2018 6:36 am
I added the call to _setRenderOperation and that worked. It appears CEGUI default now works with OGRE 2.1 using both DX11 and OpenGL !!
(That is when I send up my PR and it gets merged in the branch of course).
Yay! Congrats and good job!
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.
Good luck! Most of the changes revolve around textures and how render targets are set.

Cheers!
Matias
0 x

crancran
Greenskin
Posts: 136
Joined: Wed May 05, 2010 3:36 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by crancran » Sun Apr 08, 2018 1:57 am

While adding support for 2.2, I stumbled across some code that I am unclear how to adapt. The code in question is:

Code: Select all

psoCacheHelper->setRenderTarget( renderTarget );
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:

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);
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:

Code: Select all

RenderPassDescriptor *renderDesc = renderSystem->createRenderPassDescriptor();
renderDesc->mColour[0].texture = renderTexture;
renderDesc->entriesModified(1);
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?
0 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 4112
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 242
Contact:

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by dark_sylinc » Sun Apr 08, 2018 5:24 am

You have to call:

Code: Select all

renderDesc->entriesModified( RenderPassDescriptor::All );
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);
This is correct but incomplete.

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.
0 x

crancran
Greenskin
Posts: 136
Joined: Wed May 05, 2010 3:36 pm
x 3

Re: [Ogre 2.1] Porting CEGUI to OGRE 2.1

Post by crancran » Sun Apr 08, 2018 7:05 am

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 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
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)
I'll definitely give this a read and get back to you.

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.
0 x

Post Reply