DirectX 11 render system - work-in-progress

[Xavyiy]

@FlorianGeorge
Maybe I'm missunderstanding you, but if you want to get correct results using post-processing effects in wireframe mode you can set mat->pass->setPolygonModeOverrideable(false); (or the equivalent in the material script) for each pass of each material used in your compositor(s).
If that's what you want, then it's not an Ogre bug, it's working as expected.

That's how I do it in my engine, works very well:
Solid:

Wireframe:


Xavier

[FlorianGeorge]

@FlorianGeorge
Maybe I'm missunderstanding you, but if you want to get correct results using post-processing effects in wireframe mode you can set mat->pass->setPolygonModeOverrideable(false); (or the equivalent in the material script) for each pass of each material used in your compositor(s).
If that's what you want, then it's not an Ogre bug, it's working as expected.

This is working quite well, thanks!

Checking the Samplebrowser, the issue seems to occur with most or maybe all Compositors in Wireframe mode, due to the Compositor being rendered to a quad. What is the downside to setPolygonModeOverrideable(false), at least for all Compositors, why or when would someone not want to set it to false by default?

[Xavyiy]

This is working quite well, thanks!

What is the downside to setPolygonModeOverrideable(false), why or when would someone not want to set it to false by default?

It defines if the material should or not to use the default polygon mode set via Camera::setPolygonMode. If set to false, the scene manager will always use the polygon mode defined via Pass::setPolygonMode when using the material, if set to true then the secene manager will use the camera's polygon mode.

It should be false when you want to render it always in solid (== the pass polygon mode, usually will be solid) independently of the camera's default polygon mode. So, in brief, for all GUI elements and compositor materials.

Xavier

[Xavyiy]

Checking the Samplebrowser, the issue seems to occur with most or maybe all Compositors in Wireframe mode

Well, as I've said before it's not a bug or issue. It's just that the user should define carefully the compositor's materials. But that's not not a bug that should be fixed - maybe we should set it to false in the sample browser compositor's material scripts, just for "visual consistence", but nothing related to any required fix in the Ogre core.

Edit: I've contacted via twitter with masterfalcon and wolfmanfx so that -set the override property to false in all compositor's scripts of the sample browser- will be evaluated by the ogre team.

[FlorianGeorge]

Checking the Samplebrowser, the issue seems to occur with most or maybe all Compositors in Wireframe mode

Well, as I've said before it's not a bug or issue. It's just that the user should define carefully the compositor's materials. But that's not not a bug that should be fixed - maybe we should set it to false in the sample browser compositor's material scripts, just for "visual consistence", but nothing related to any required fix in the Ogre core.

Edit: I've contacted via twitter with masterfalcon and wolfmanfx so that -set the override property to false in all compositor's scripts of the sample browser- will be evaluated by the ogre team.

Yeah, patching all materials that start with "material Ogre/Compositor/" should be quite easy.

Thanks a lot, you solved a mystery that was bugging me for quite some time!

[masterfalcon]

So you're suggesting adding

Code: Select all

polygon_mode_overrideable false

to every render_quad pass in Examples.compositor?

[Xavyiy]

So you're suggesting adding

Code: Select all

polygon_mode_overrideable false

to every render_quad pass in Examples.compositor?

Nope, adding "polygon_mode_overrideable false" too all passes of the materials used in compositors, not to the "compositor passes". (The quivalent in code is Ogre::Pass::setPolygonModeOverrideable(...))

Edit: example:

Code: Select all

material PEngineCore/PointLightDebugBillboard
{
	technique
	{
		pass
		{
			lighting off
			
			scene_blend alpha_blend
			
			cull_hardware none
			cull_software none
			
			depth_write off
			depth_check off
			
			polygon_mode_overrideable false // !!!
			
			texture_unit
			{
				texture PointLightDebugIcon.png
				tex_address_mode clamp
			}
		}
	}
}

To understand what the problem really is, just run the compositor sample and switch to wireframe mode, you'll see that the compositor quad is being rendered too in wireframe mode so you get an "incorrect" result. Adding "polygon_mode_overrideable false" to the materials that are used in the compositors will result in a solid compositor quad, so you'll have the scene rendered in wireframe mode and then the compositor chain rendered as expected taking as origin the wireframe scene (since the materials used in the scene objects "have polygon_mode_overrideable true" by default).

[Assaf Raman]

It was just the compositor sample, the heat vision, oldTV and motion blur compositor . I have just started to work on instancing sample, so if I will be more stacked then today I will tell it . If you have time, you can also look over that

Fixed "Old TV" to work, was hard to find the issue, but seems you must have a float4 "POSITION" as the first parameter, and you can't use it See my fix in the 1-9 repo.

[Transporter]

Code: Select all

1>  OgreD3D11MultiRenderTarget.cpp
1>src\OgreD3D11Mappings.cpp(695): error C2065: 'DXGI_FORMAT_AYUV': undeclared identifier
1>src\OgreD3D11Mappings.cpp(695): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(696): error C2065: 'DXGI_FORMAT_Y410': undeclared identifier
1>src\OgreD3D11Mappings.cpp(696): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(697): error C2065: 'DXGI_FORMAT_Y416': undeclared identifier
1>src\OgreD3D11Mappings.cpp(697): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(698): error C2065: 'DXGI_FORMAT_NV12': undeclared identifier
1>src\OgreD3D11Mappings.cpp(698): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(699): error C2065: 'DXGI_FORMAT_P010': undeclared identifier
1>src\OgreD3D11Mappings.cpp(699): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(700): error C2065: 'DXGI_FORMAT_P016': undeclared identifier
1>src\OgreD3D11Mappings.cpp(700): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(701): error C2065: 'DXGI_FORMAT_420_OPAQUE': undeclared identifier
1>src\OgreD3D11Mappings.cpp(701): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(702): error C2065: 'DXGI_FORMAT_YUY2': undeclared identifier
1>src\OgreD3D11Mappings.cpp(702): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(703): error C2065: 'DXGI_FORMAT_Y210': undeclared identifier
1>src\OgreD3D11Mappings.cpp(703): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(704): error C2065: 'DXGI_FORMAT_Y216': undeclared identifier
1>src\OgreD3D11Mappings.cpp(704): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(705): error C2065: 'DXGI_FORMAT_NV11': undeclared identifier
1>src\OgreD3D11Mappings.cpp(705): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(706): error C2065: 'DXGI_FORMAT_AI44': undeclared identifier
1>src\OgreD3D11Mappings.cpp(706): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(707): error C2065: 'DXGI_FORMAT_IA44': undeclared identifier
1>src\OgreD3D11Mappings.cpp(707): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(708): error C2065: 'DXGI_FORMAT_P8': undeclared identifier
1>src\OgreD3D11Mappings.cpp(708): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(709): error C2065: 'DXGI_FORMAT_A8P8': undeclared identifier
1>src\OgreD3D11Mappings.cpp(709): error C2051: case expression not constant
1>src\OgreD3D11Mappings.cpp(710): error C2065: 'DXGI_FORMAT_B4G4R4A4_UNORM': undeclared identifier
1>src\OgreD3D11Mappings.cpp(710): error C2051: case expression not constant

Configuration: Win7 + VS2012 + DirectX SDK June 2010

Solution: line 683

Code: Select all

#if defined(_WIN32_WINNT_WIN8) && (_WIN32_WINNT >= _WIN32_WINNT_WIN8)

to

Code: Select all

#if defined(_WIN32_WINNT_WIN8) && (_WIN32_WINNT >= _WIN32_WINNT_WIN8) && defined(DXGI_FORMAT_AYUV)

[Assaf Raman]

Ok, thanks.

[robert_sasu]

Fixed "Old TV" to work, was hard to find the issue, but seems you must have a float4 "POSITION" as the first parameter, and you can't use it See my fix in the 1-9 repo.

Your fixes are not really working at any device. On my devices (laptop, office PC) I have the latest CG, NVidia compilers, drivers but some compositors which use shader written in CG and use shader model 4.0 are incompatible - one of the being heat vision. This is one of the reasons I am writing new hlsl shaders for some of the compositors. Another thing I consider important is the capability of hlsl for dynamic linking. It offers a good performance boost when using Shader Model 5.0, for this I will just put target ps_5_0 and vs_5_0 in materials.
I have made OldTv and HeatVision work for directX 11 RS with hlsl shaders. One of you're changes in Compositor.h file broke Dither compositor (line 692 when creating texturePtr for this compositor you have to leave that to PF_A8 and there is no need for TU_DYNAMIC_WRITE_ONLY).

There are 2 more compositors which are not working HDR and MotionBlur. At some stage of these compositors DirectX 11 tries to render without both vertex and pixel shaders. I haven't figured out yet why is this. All the changes and shaders you can see at my repo, link at my signature.


u.i. I was on a vacation for 10 days, this is why I were inactive.

[robert_sasu]

Today I have corrected IsoSurf sample, now it is working on DirectX 11 Render System - there were some issues in its shader.
I have moved on to resolve SSAO sample, I have added new shaders (hlsl). But there are still some problems, fxc.exe compiles these shaders well but Ogre log says that there is no supported technique for them. I've compiled with fxc for SM 5.0 and SM 4.0 without any problem.

There are still 2 more compositors which are not working, namely: HDR and MotionBlur. If anyone has time, please clone my repo and try to resolve some of these bugs. I have added new shaders for some of the samples, and they are still not working, because DX 11 does not have fixed pipeline, so the samples are needed to be modified.
Here is the list of samples which are not working:

1. Compositor - 98% resolved - carsh for HDR and Motion Blur - it says missing shaders, on of the compositor passes misses pixel shader.
2. Deferred shading - crash on start
3. Dual Quaternion - crash on start
4. Dynamic Texture - _resolved_
5. Instancing - there is just only one model rendered per row if the model is razor, for every other model the sample is working fine
6. Isosurf - _resolved_
7. NewInstancing - a lot of visual bugs, you can't see any of the models.
8. SSAO techniques - crash on start - non of the techniques are supported - says ogre log, thus I have added new shaders written in hlsl for SM 4.0 and 5.0
9. Shader system - sometimes bad skybox, error when trying multiple viewports or shadows.
10. Shader system texture fog - sky box does not appear on initializing, if you deselect and select again it will work
11. Grass sample - there is no animation on the grass if the fallback technique exist, no normal mapping on ogre head
12. Shadow sample - missing shaders which are supported by D3D11RS (there is no fixed pipeline in D3D11)
13. Terrain sample and volume rendering with LOD aimed terrain - crashes on start
14. Facial animation, multiple visual issues when changing anything to the face

[vilgeits]

I've put this http://www.ogre3d.org/forums/viewtopic.php?f=1&t=76572 on the General forum but maybe people from this post could be the proper ones to add light to the question.

[robert_sasu]

As I am out of ideas for certain bugs, I started to implement PN-Triangles tessellation as a sample in the sample browser - sources are from ja0335 http://ogre3d.org/forums/viewtopic.php?f=11&t=72139.
He gave me the sources a while ago and gave permission to make a sample out of it.

I simplified it for the first runs, but I am getting a strange error that the sample plugins were either missing, corrupt or invalid.


I verified that there is no mistype anywhere, but I do not get anything else from ogre/log files. Does anybody encountered such a problem ? You can look at the sources in my repo https://bitbucket.org/sasu_robert/ogre3d-directx11.

u.i. If anyone has time, you can have look also at the other errors described above.

[robert_sasu]

I had a lot of work to do in the past 2 weeks, and this is why I couldn't make any more bugfixes. Moreover my windows put on a platform update, so I needed to get Visual Studio 2012 license and rebuild everything there.
I hoped that someone will help me with this issues I posted above. In the next days I will finish implementation of the PN-triangles tessellation.

[lunkhound]

Robert,
I was looking at some of the changes in your repo, and I noticed some things that looked wrong to me. You have some changes to material files like this one:

Code: Select all

fragment_program SSAO/CreaseShading_fp_hlsl hlsl
 {
-    source CreaseShading.cg
+    source CreaseShading.hlsl
     entry_point CreaseShading_fp
-    target ps_3_0 
+    target ps_4_0 ps_3_0 
 }

Here you are trying to specify multiple assembler targets, which is not supported for HLSL (see http://www.ogre3d.org/docs/manual/manual_20.html#HLSL). My guess is that in this case Ogre will see the target as "ps_4_0 ps_3_0" and find no matches, therefore the technique is unsupported.
I hope this helps.

[robert_sasu]

Thanks I will correct these and see what happens. Ogre responded that shader is incompatible and I didn`t know where it came from.

[robert_sasu]

I have started to work with Visual Studio 2012 and I got some strange errors from compositor sample, did anyone see this before:

Code: Select all

D3D11 ERROR: ID3D11DeviceContext::Draw: The Shader Resource View dimension declared in the shader code (TEXTURE2D) does not match the view type bound to slot 0 of the Pixel Shader unit (TEXTURE2DMS).  This mismatch is invalid if the shader actually uses the view (e.g. it is not skipped due to shader code branching). [ EXECUTION ERROR #354: DEVICE_DRAW_VIEW_DIMENSION_MISMATCH]
First-chance exception at 0x000007FEFD429E5D in SampleBrowser_d.exe: Microsoft C++ exception: Ogre::RenderingAPIException at memory location 0x0000000000B0DDB0.

I have no clue why is this. Did Microsoft rename TEXTURE2D to TEXTURE2DMS in his latest platform update ?

[lunkhound]

Thanks I will correct these and see what happens. Ogre responded that shader is incompatible and I didn`t know where it came from.

I made the same mistake when converting some of my shaders from Cg to HLSL a while back.
I'm wondering why you need to convert the shader code to SM 4.0 syntax though. Shouldn't it work to compile the old syntax in backwards compatibility mode (D3DCOMPILE_ENABLE_BACKWARDS_COMPATIBILITY flag)?

In my own project, I've got my DX9 shader code compiling and running with the DX11 rendersystem with no errors, warnings or exceptions. However, the shaders don't work as expected--some don't draw anything at all, others have messed up texturing. Is the HLSL backwards compatibility broken in some way?

[robert_sasu]

Microsoft brake some of the compatibility between dx9 and dx11. See sampling issues, the syntax is stricter in SM4 than in older shaders. Some of the functions are not more working like tex2d, and you cannot use simple sampling inside a for cycle. And there are also the mapping incompatibilities between dx9 and dx11 and so on.
When I am working on shaders to convert to SM4 I write them from 0 and conform the newest regularities.

[lunkhound]

Microsoft brake some of the compatibility between dx9 and dx11. See sampling issues, the syntax is stricter in SM4 than in older shaders. Some of the functions are not more working like tex2d, and you cannot use simple sampling inside a for cycle. And there are also the mapping incompatibilities between dx9 and dx11 and so on.
When I am working on shaders to convert to SM4 I write them from 0 and conform the newest regularities.

The HLSL compiler for DX11 has a special compatibility mode.
http://msdn.microsoft.com/en-us/library ... s.85).aspx

Shader Compilation
The Direct3D 10 HLSL compiler brings enhancements to the HLSL language definition and therefore has the ability to operate in 2 modes. For complete support of Direct3D 9 style intrinsic functions and semantics, compilation should be invoked using the COMPATIBILITY MODE flag which can be specified on a per compile basis.

For the fxc.exe tool, invoke it with the "/Gec" flag (and target either vs_4_0 or ps_4_0). For Ogre shader definition scripts, its enabled with "enable_backwards_compatibility true". For example:

Code: Select all

fragment_program SSAO/CreaseShading_fp_hlsl hlsl
 {
     source CreaseShading.hlsl
     entry_point CreaseShading_fp
     target ps_3_0
     enable_backwards_compatibility true
 }

In Ogre C++ you can turn the mode on with:

Code: Select all

D3D11HLSLProgram* prog;
prog->setEnableBackwardsCompatibility( true );

So it seems like it would be much easier to turn this mode on rather than rewrite all of the HLSL shaders for DX11 (and still need to keep the DX9 versions around as well)...
Is there something wrong with how Ogre handles this compatibility mode?

[robert_sasu]

No, Ogre handles backwards compatibility mode right.

I have many strange things going on now with Ogre Samples, using DirectX 11 Render System - I am using the code from my repo. As I described also on other posts, I had to change from Visual Studio 2010 to Visual Studio 2012 on Windows 7 64bits, because of a platform update which changed some of the DirectX11 .dll files. I wanted to change them back, so I tried to reinstall DirectX 11 SDK, but it couldn't be done.
Now, for the same code - samples - the new build is not working. On of them being the compositor sample, if I run it and choose any of the compositors Ogre stops and gives me this error:

Code: Select all

D3D11 ERROR: ID3D11DeviceContext::Draw: The Shader Resource View dimension declared in the shader code (TEXTURE2D) does not match the view type bound to slot 0 of the Pixel Shader unit (TEXTURE2DMS).  This mismatch is invalid if the shader actually uses the view (e.g. it is not skipped due to shader code branching). [ EXECUTION ERROR #354: DEVICE_DRAW_VIEW_DIMENSION_MISMATCH]
First-chance exception at 0x000007FEFD429E5D in SampleBrowser_d.exe: Microsoft C++ exception: Ogre::RenderingAPIException at memory location 0x0000000000B0DDB0.

There are also other samples, which were working with the Visual Studio 2010 build, and they are not more working on the new build - like BumpMapping.

Did anyone have such problems ? I am trying to debug all the samples and to add tessellation samples to sample browser, you can see it from my repo, but now I am stuck with these things.
I would need help.

Thanks.

[robert_sasu]

I know it is not 100% ready, but here is a screenshot from Parametric PN-Triangles sample, integrated to the sample browser. You can clearly see how tessellation works, when the part of the object is close to the camera the object becomes more and more tessellated .


The sample is working like the Bump Mapping one, I will add more shaders, but I need to debug them as they are not complete, some of the features are not working. But the tessellation part does work

[havokentity]

Excellent work robert_sasu,

there are many who are actively following your progress. I regularly compile and build and test all the demos in the sample browser with your new dx11 rendering plugin.

[Oceax]

Awesome!
Just tried it and it works great.
I need this tessellation stuff for a water shader i am working on.