DX11 broken on latest 2.1 Topic is solved

Design / architecture / roadmap discussions related to future of Ogre3D (version 2.0 and above)
Post Reply
User avatar
AshMcConnell
Silver Sponsor
Silver Sponsor
Posts: 605
Joined: Fri Dec 14, 2007 11:44 am
Location: Northern Ireland
x 2
Contact:

DX11 broken on latest 2.1

Post by AshMcConnell » Wed Jan 03, 2018 4:45 pm

Hi Folks,

I have come across an error that happens in the tutorials as well as my own game. There are a number of these errors in the log file: -

Code: Select all

15:43:17: OGRE EXCEPTION(-2147467262:RenderingAPIException): Cannot reflect D3D11 high-level shader Ogre/Compositor/Quad_vs_HLSL in D3D11HLSLProgram::compileMicrocode at C:\Dev\3rdParty\cmake\Ogre\RenderSystems\Direct3D11\src\OgreD3D11HLSLProgram.cpp (line 575)
15:43:17: High-level program Ogre/Compositor/Quad_vs_HLSL encountered an error during loading and is thus not supported.
Eventually it ends in an exception (that I get when running the tutorials in DX11)

Code: Select all

15:43:18: OGRE EXCEPTION(5:ItemIdentityException): Cannot find best technique for material 'Ogre/DPSM/CubeToDpsm' in CompositorPassQuad::CompositorPassQuad at C:\Dev\3rdParty\cmake\Ogre\OgreMain\src\Compositor\Pass\PassQuad\OgreCompositorPassQuad.cpp (line 101)
It runs fine with GL3+

Thanks!
Ash
0 x

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

Re: DX11 broken on latest 2.1

Post by dark_sylinc » Wed Jan 03, 2018 10:47 pm

Hi,

I could not repro your problem. My testing environments were:

x86
Visual Studio 2008
DirectX June 2010 SDK
Running on Windows 10 ver. 1703 15063.786 (x64)

x64
Visual Studio 2015
Windows SDK version 10.0.14393.0 to target Windows 10.0.15063
Running on Windows 10 ver. 1703 15063.786 (x64)

The kind of error you are seeing suggest some DLL mismatch. It's possible that:
  • Your PC got a severe misconfiguration (DirectX) or one of the latest Windows 10 updates broke things (again)
  • Your build is targetting a Windows / DirectX version newer than the one installed in your system. Run Windows Update.
  • Your Build system is kapput. Like for example mixing VS 2015 with the June 2010 SDK, or something like that. Or the Windows SDK from two different versions are being mixed. This is more likely.
I suggest you clear the whole CMake build folder and build it again. There were recent changes in how DirectX11 is found in CMake, and if you updated from an old version it's possible settings got mixed up.

If deleting the build folder entirely and regenerating CMake from scratch again doesn't solve the problem, try checking commits before these changes to find the culprit.
1 x

User avatar
AshMcConnell
Silver Sponsor
Silver Sponsor
Posts: 605
Joined: Fri Dec 14, 2007 11:44 am
Location: Northern Ireland
x 2
Contact:

Re: DX11 broken on latest 2.1

Post by AshMcConnell » Sun Jan 07, 2018 11:33 am

Sorry I haven't had a chance to look at my env yet. I will hopefully get a chance today. Thanks for the tip, I wouldn't have thought of it (as I haven't manually updated any SDKs).

Thanks!
Ash
0 x

User avatar
AshMcConnell
Silver Sponsor
Silver Sponsor
Posts: 605
Joined: Fri Dec 14, 2007 11:44 am
Location: Northern Ireland
x 2
Contact:

Re: DX11 broken on latest 2.1

Post by AshMcConnell » Sun Jan 07, 2018 9:40 pm

I have managed to track it down to a single commit. Strange thing is that all the DirectX 11 entries are the same before and after the commit. I must be missing something.

The samples work if I switch to a previous commit. I tried switching back and forth a couple of times, so there must be something in that commit that my env is not happy with. I'll try and figure it out :)

FYI: I'm on Windows 10 ver. 1703 15063.786 (x64) with Windows SDK version 10.0.10240.0 and Visual Studio 2017 Community Edition
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Wed Jan 10, 2018 10:07 pm

the cmake script is a bit broken for me, and looking at it, it may work for some but not others depending what SDKs you have installed, what your environment is targeting and what Ogre decides to use! And when I say not work I mean not compile, but I guess could cause runtime issues in theory....

If using the Windows SDKs for directX you should not be including the the full path. It would be equivalent to including the full path to windows.h. So if using windows SDKs for directX then DirectX11_INCLUDE_DIRS should be blank, DirectX11_LIBRARIES should be 'd3d11.lib dxgi.lib dxguid.lib'

Looking at the Cmake, its half way their, but seems to do something different if it finds a win 10 SDK which I dont really understand. Ill try and look back at the commits and understand if its covering an odd edge case.
1 x

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

Re: DX11 broken on latest 2.1

Post by dark_sylinc » Wed Jan 10, 2018 11:19 pm

Ah... you're saying two different Windows SDKs are being mixed? (one for Windows.h and stuff, another for DX stuff)
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Thu Jan 11, 2018 9:58 am

dark_sylinc wrote:
Wed Jan 10, 2018 11:19 pm
Ah... you're saying two different Windows SDKs are being mixed? (one for Windows.h and stuff, another for DX stuff)
In short yes. Although its not really one for windows and one for directX, its just mixing 2 different windows SDKs, or 'Windows kits.

Its fairly obvious in VS2017 because you have to select the 'Windows SDK version' on other version of VS its not so obvious. One of my builds (Win7 VS2013) Ogre includes 'C:/Program Files (x86)/Windows Kits/10/Include/10.0.15063.0/um' and similar libs, but Visual studio is using the win 8.1 SDK and bad things happen including mixing headers
1 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Fri Jan 12, 2018 12:10 pm

Any chance someone can have a go at fixing this, as Ogre build is effectively broken at the moment! Happy to create a pull request for what I understand, but not sure why there are different logic for windows phone, and different logic between win 10 SDKs and win 8 SDK..?

My version just looks to see if a Windows Kit is installed if so just list the libs needed to link to, if not found then then look for the June 2010 SDK and add the include dir and full path of libs to link to.
1 x

User avatar
AshMcConnell
Silver Sponsor
Silver Sponsor
Posts: 605
Joined: Fri Dec 14, 2007 11:44 am
Location: Northern Ireland
x 2
Contact:

Re: DX11 broken on latest 2.1

Post by AshMcConnell » Sun Jan 14, 2018 9:02 pm

Thanks al2950, I managed to get the latest commit compiling and demos running by manually selecting DX11 to match the targeted Windows SDK version (In Configuration Properties -> General -> Windows SDK Version).

I'm not sure what the best solution would be for the CMAKE file. How is the SDK version selected in cmake?

Unfortunately MYGUI is now not compiling (issues with OGRE_MUTEX), but hopefully I can fix it with a fresh head tomorrow

Thanks!
Ash
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Mon Jan 15, 2018 6:04 pm

Well I have created a pull request that works nicely on all the different versions of windows and VS I have :D
3 x

User avatar
AshMcConnell
Silver Sponsor
Silver Sponsor
Posts: 605
Joined: Fri Dec 14, 2007 11:44 am
Location: Northern Ireland
x 2
Contact:

Re: DX11 broken on latest 2.1

Post by AshMcConnell » Mon Jan 15, 2018 6:07 pm

Good work! 😀
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Mon Jan 15, 2018 7:18 pm

Yay, merged already. Fastest PR ever! Now, as dark_sylinc said in PR, lets hope this works for all windows dev environments :roll:.

Please report any issues here, or link other post that have issues here so I am aware and ill try and understand and fix.
2 x

User avatar
AshMcConnell
Silver Sponsor
Silver Sponsor
Posts: 605
Joined: Fri Dec 14, 2007 11:44 am
Location: Northern Ireland
x 2
Contact:

Re: DX11 broken on latest 2.1

Post by AshMcConnell » Sun Jan 21, 2018 3:57 pm

Thanks al2950 (that seems very formal :P ) :)

I had a problem when I tried it the other night (after clearing all CMake cache), but I updated Visual Studio 2017 to the latest version and it has worked perfectly (perhaps installed the latest Windows SDK?)

Thanks again!
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Mon Jan 22, 2018 1:13 pm

AshMcConnell wrote:
Sun Jan 21, 2018 3:57 pm
Thanks al2950 (that seems very formal :P ) :)
I probably posted at the end of a difficult work day!

For everyones reference, if you have odd compile issue with DirectX here are a few tips of places to look to try and resolve them. Most issues are caused by including multiple Windows SDKs.

If you have June 2010 SDK installed and no Windows Kits (most likely windows 7), then bring up the inlcude directory of your Ogre Dx11 project and make sure it inlucdes the full path to the June 2010 SDK, and also full paths for the linked libs. If you have a windows kit installed, then there should be NO reference to include directories, and it should just define the libs to link without the full path.

To try and work out what version of windows SDK Visual studio is using you can do the following; (NB if using VS2017 just go to Configuration Properties->General->Windows SDK Version)
Go to the project properties and under 'Configuration Properties' select 'VC++ Directories' there you should see something like

Code: Select all

Inlcude Directories $(VC_IncludePath);$(WindowsSDK_IncludePath);
Now you will want to check what those variables actually point to, which I do by going to 'Configuration Properties' -> General->'Output Directory'->edit then click on 'Macros'

I am still at a loss however as to how those macros are set!
0 x

User avatar
AshMcConnell
Silver Sponsor
Silver Sponsor
Posts: 605
Joined: Fri Dec 14, 2007 11:44 am
Location: Northern Ireland
x 2
Contact:

Re: DX11 broken on latest 2.1

Post by AshMcConnell » Mon Jan 22, 2018 1:16 pm

Heh, I mean al2950 seems like replying to me with "Thanks AshMcConnell" instead of "Thanks Ash" :).
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Mon Jan 22, 2018 1:43 pm

AshMcConnell wrote:
Mon Jan 22, 2018 1:16 pm
Heh, I mean al2950 seems like replying to me with "Thanks AshMcConnell" instead of "Thanks Ash" :).
Ha... Yes my internet pseudonym forces formality!
0 x

hedphelym
Greenskin
Posts: 148
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: DX11 broken on latest 2.1

Post by hedphelym » Mon Jan 22, 2018 1:51 pm

I'll try and explain as best I can (let me know if something is unclear), I'm in a rush to get home from work so I'm posting this right before I leave.

I spent the whole day today trying to sort out my Dx11 compilation issue.
We have all our 3rdparty libraries in a specific folder outside ogre, meaning it's not installed into 'program files', but a copy of that folder is located in our 3rdparty folder).
I do however also have the platform sdk installed in programfiles - but I do no want to use that I want to use my custom DirectX SDK folder for cmake..

This means I have to point cmake to reflect this, however no matter what I did I could not get it to compile properly after generating the cmake project files.

In the end I discovered that cmake does indeed set the cmake directory for directx like I want, but it also appends
the path to the kit to the solution, and this seems to cause the compilation issues.

Code: Select all

'C:\Program Files (x86)\Windows Kits\8.1\Include\um'
What I wanted was for it not to include the path for the kit, just point directly to my directX 3rdparty folder when I override it in cmake.

So, if I do this with cmake:

Code: Select all

-DDirectX11_INCLUDE_DIR="D:/SimulationHIL/Products/myproject/Source/3rdParty/Microsoft/DirectX SDK/Include"
it still added the search path:

Code: Select all

'C:\Program Files (x86)\Windows Kits\8.1\Include\um'


This then gave a ton of error messages like this during compilation:

Code: Select all

9>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\ole2.h(221): error C2370: 'HOLEMENU' : redefinition; different storage class (D:\development\Ogre21\ogre\RenderSystems\Direct3D11\src\OgreD3D11EngineDll.cpp)
9>          c:\program files (x86)\windows kits\10\include\10.0.16299.0\um\oleidl.h(2335) : see declaration of 'HOLEMENU'
9>C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um\ole2.h(221): fatal error C1003: error count exceeds 100; stopping compilation (D:\development\Ogre21\ogre\RenderSystems\Direct3D11\src\OgreD3D11EngineDll.cpp) 
So, what I had to do now as a workaround was to manually remove that include in the project inside visualstudio.
(right click the 'RenderSystem_Direct3D11' and remove the path to the kit).
Then I was able to compile and run some dx11 samples.

So - if you override the directx search directory - It seems to me as if it should not append the 'kit' to the include path in the project.

I do not have access to windows at home (only use linux there), so if more information is needed I can provide that tomorrow morning.
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Mon Jan 22, 2018 6:22 pm

Well the short answer is Ogre DirectX11 cmake scripts makes the assumption that no-one would ever want to supply their own custom DirectX paths. This could be fixed, however I am curious still by the results you are getting.

Are you using the latest version of Ogre with the recent cmake fixes? Also what directX libs does it point to (link settings), does it reference just the libs or the full paths to the libs? (d3d11.lib dxgi.lib dxguid.lib)
0 x

hedphelym
Greenskin
Posts: 148
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: DX11 broken on latest 2.1

Post by hedphelym » Mon Jan 22, 2018 10:16 pm

Yes, the latest with those fixes.
we had the same isdue with 1.9 and had to do all kinds of tricks to make our buildscripts work, since our 3rdparty stuff is in its own folder.
and since we are now porting everything to 2.1 I try to get rid of as much custom stuff as possible (including this cmake stuff).

It would help us a lot if we could get this fixed.

It points to the libs you mention, in their correct folder (3rdparty folder).

Ill post some more details and such when I get in at the office tomorrow morning.
0 x

hedphelym
Greenskin
Posts: 148
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: DX11 broken on latest 2.1

Post by hedphelym » Tue Jan 23, 2018 10:01 am

I've spent some time this morning figuring out the exact steps and what is going on.

So, my cmake command is now:

Code: Select all

D:\development\Ogre21\buildx64>"C:\Program Files\CMake\bin\cmake.exe" -DOGRE_DEPENDENCIES_DIR="..\Dependenciesbuildx64\ogredeps" DirectX11_INCLUDE_DIR="D:/Products/Source/3rdParty/Microsoft/DirectX SDK/Include" -G "Visual Studio 11 2012 Win64" ../ogre"
This then adds the path to the SDK in the cmake file like I expect:

Code: Select all

DirectX9_PREFIX_PATH_INT_CHECK:INTERNAL="D:/Products/Source/3rdParty/Microsoft/DirectX SDK/"
And cmake output enables the project:

Code: Select all

Building rendersystems:
  + Direct3D 11
  + OpenGL 3.3+
  
(If I do not have 'DirectX11_INCLUDE_DIR' in my cmake command it does not enable the Direct3D rendersystem).


I then open the solution, remove the reference to platform sdk in project settings for 'RenderSystem_Direct3D11' (right-click->properites->c++->additional include directories-> delete the last line ('C:\Program Files (x86)\Windows Kits\8.1\Include\um'))

Then it compiles.
If the windows kit is not removed I get all the errors described earlier.
So (correct me if I'm wrong), if you override the 'DirectX11_INCLUDE_DIR' cmake property, then it should not add the platform sdk path if that also is installed.
0 x

al2950
OGRE Expert User
OGRE Expert User
Posts: 1090
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 40

Re: DX11 broken on latest 2.1

Post by al2950 » Tue Jan 23, 2018 1:01 pm

Your 3rd party DirectX SDK, is that in the format (directory layout) to the June 2010 SDK? If we added a DIRECTX_SDK_DIR, a bit like OGRE_DEPENDENCIES_DIR, I assume that would be helpful. We would just need to update the cmake scripts to assume that if DIRECTX_SDK_DIR is set then just use that as a path hint for the June 2010 SDK path.

If you override DirectX11_INCLUDE_DIR then it will do different things depending on the platform, as its used as a internal reference as to if something has been found ornot. Basically read FOR INTERNAL USE ONLY!

But can I ask, why on earth would you not want to link to the proper DirectX SDKs!?
0 x

hedphelym
Greenskin
Posts: 148
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: DX11 broken on latest 2.1

Post by hedphelym » Tue Jan 23, 2018 1:23 pm

It is the same layout style yes.

The reason why we do it this way is because we are 3 developers working on the same project on different machines \ locations.
And we have everything checked into our source control, so no matter what machine you use you can always just pull latest and build, and
the build on my machine will be exactly the same as on the two others.
No installation of any SDK's \ libs and so on is needed, because it's all in the repository we use to manage our projects.
We then have complete control over all external libraries used, and there is no way it can link against a wrong version for example.
We have tools that builds everything from scratch, with specific versions of all dependencies.
This is because customers require that we know exactly what version \ commit is used for every part of the project,
code, 3d models, dependencies etc. (we make Simulators for oil industry \ equipment).
0 x

Post Reply