[GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Threads related to Google Summer of Code
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

I have continued to work on material files and shaders. They are almost done, I need to add just the named variables to the Hair material files.

For TerrainTessellation I will use a custom TerrainMaterialGenerator and use the created Tessellation shaders. If everything will be ok, I will integrate this methods to the Ogre::Terrain plugin after GSoC. For Island sample I will use the same method - even if I could make a .scene file and use it, because Island sample will be only just a showcase.

Finally, VolumeCSG sample is working fine now on D3D11 Render System.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by PhilipLB »

That's interesting, what was wrong with the VolumeCSG-sample? :)
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

VolumeCSG sample had multiple visual issues. At the first hand it was not working, giving errors. After some fixes all the cubes, sphere's appeared but without being correctly textured. After a few more fixes it is working correctly on D3D11RenderSystem.

VolumeTerrain sample is not working, now there is some mipmap error there when trying to create Texture3D. But will investigate next week.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by PhilipLB »

Actually, the loading of the 3D texture should not generate any mip maps at all... Does it? O_o
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

I know it shouldn't. The bug is most probably in the D3D11 RenderSystem.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by PhilipLB »

Good find! I just fixed that. If you want to try it, see this commit:
https://bitbucket.org/philiplb/ogrevolu ... 1293aeeb02
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by dark_sylinc »

Hi!

Nice work. I'm passing by to ask something.

Does RTT (RenderToTexture) with MSAA work in its current state?
Because I don't see anywhere in the D3D11 code where the MSAA buffer is resolved into a non-msaa buffer (and to double check, find in files only got a hit for 'ResolveSubresource' which is used in something unrelated: D3D11RenderWindowBase::copyContentsToMemory)

While I'm designing the new (null for now) compositor system, I'm taking into consideration that users may want to access the msaa buffer directly (which is something Direct3D 10+ and GL3+ allow). Currently Ogre 1.x assumes all msaa buffers get resolved before being used (they do that in RenderTarget::swapBuffers)

I'm introducing the notion of "explicit resolves" in Ogre 2.0, which basically work like this: by default all RenderTextures are implicitly resolved. This means that if the user draw something on it, it gets flagged as fsaa_dirty. When the user tries to bind it to a texture; Ogre will resolve the dirty texture. This is very similar to Ogre 1.x behavior as it produces the same results (actually 1.x is way dumber, because it resolves every time after rendering each "compositor target" instead of doing it only when needed, which can cause to resolve multiple times unnecessarily on complex compositors). Once resolved, the fsaa_dirty flag is set to false again.

Explicit resolves instead are manually handled by the user. Once the fsaa_dirty flag is set, attempting to bind it as a texture will cause Ogre to send the MSAA buffer directly. Thus the user can access the msaa subsamples from within HLSL.
When the user doesn't want the msaa version, he just needs to resolve the target explicitly (whether with a pass_quad & custom shader or telling the Compositor to do a call to ResolveSubresource), the fsaa_dirty flag will be unset; and now trying to bind it as a texture will send the non-msaa version to the shader.

I know what changes need to be made to D3D9, GL & GL3 RenderSystems, and are very easy. However I don't see where in D3D11 the msaa textures get resolved, which makes me think it isn't working, or we're erroneously sending the MSAA with subsamples and happens to work by chance. I haven't looked deep enough (particularly because I forked from pre-GSoC D3D11, which is very unstable), but it also appears the msaa & non-msaa buffer resources are a bit hidden when trying to access them from D3D11Texture.

For example if binding MSAA textures worked in D3D9, the code changes would look like this:

Code: Select all

IDirect3DBaseTexture9* D3D9Texture::getTexture()
{
	TextureResources* textureResources;			
	IDirect3DDevice9* d3d9Device = D3D9RenderSystem::getActiveD3D9Device();
		
	textureResources = getTextureResources(d3d9Device);		
	if (textureResources == NULL || textureResources->pBaseTex == NULL)
	{			
		createTextureResources(d3d9Device);
		textureResources = getTextureResources(d3d9Device);			
	}
	assert(textureResources); 
	assert(textureResources->pBaseTex);

	if( mFSAA > 0 )
	{
		//Just pretend for the sake of this example D3D9 supports explicit resolves.
		RenderTarget *renderTarget = mSurfaceList[0]->getRenderTarget();
		if( !mFsaaExplicitResolve )
		{
			for( size_t face=0; face<getNumFaces(); ++face )
			{
				renderTarget = mSurfaceList[face * (mNumMipmaps+1)]->getRenderTarget();
				if( renderTarget->isFsaaResolveDirty() )
					renderTarget->swapBuffers( false );
			}
		}
		else if( renderTarget->isFsaaResolveDirty() )
		{
			return textureResources->pFSAASurface;
		}
	}

	return textureResources->pBaseTex;
}
Since D3D9 doesn't actually support explicit resolves (and neither GL2 and below); both rendersystems will assume all textures are implicitly resolved (thus they always get resolved before being bound to a texture unit state). And compositor passes that perform the explicit resolve will just be ignored.

Cheers
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

I have added your changeset @philipb but haven't tested yet as I was working on the samples.
While working I found an other bug of the current Terrain system (not the volume one). It uses pixel format A8_UNORM, which cannot be transformed in any of the D3D11 Pixel Formats. There was the same problem with DynamicTexture sample. There I resolved by making a new shader, used RGBA_UNORM format and made all the blending in the shader. I guess I can make something similar in this case.
To not make any compatibility issues I will add an option on the current terrain material generator that when using D3D11 RenderSystem to use the RGBA_UNORM pixel format and a different material.

As for your question @dark_sylinc of whether Does RTT (RenderToTexture) with MSAA work in D3D11RenderSystem, I couldn't find any other information then you, I did not remember working with msaa, yet. But I will try to investigate more in the next few days and give you an answer then.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

Today I have finished integrating all the samples to the sampleBrowser. The code is compiling, there is still work to make every sample. Tomorrow I will add all the textures and art files. The Terrain Material Generator is mostly done.

I will make a new material generator also for the old terrain sample. By this also the endless world sample will work. The current material and shader generator for the terrain system works only with Shader Model 2.0 which is not supported by DirectX 11. I will make it using CG standards and Shader Model 4.0 to make it compatible also with OpenGL3+ system.

Every idea,advice is more then welcomed.

Lastly, Ogre Volume terrain example is still not working on D3D11RenderSystem. Now there is a bad creation of the D3D11HardwareBuffer.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

While I am working on he new samples I also try to debug the old samples which are not working.

1. Volume Terrain sample: Now I have managed to make this sample to not crash, but it is nothing rendered. Everything is black. There were missing Shader Model 4.0 shaders, I have added/created them but still nothing, everything is black. There is nothing in the output what could help me. All the changes can be seen in at my repository. I do not know what is the problem. I probably miss something obvious.
Image

2. Old Terrain sample: There is a problem when creating input layout for ID3D11Device. The problem is that the provided input signature expects to read an element (POSITION at index 0) with the type of float32 (which is equal to float4 in shader) but the format is R16G16_SINT. This appears at OgreD3D11VertexDeclaration.cpp line 244. I have overriden this problem (very badly) buy changing the format hardcoded if it is R16G16_SINT to R16G16_FLOAT before the input layout creation at the OgreD3D11VertexDeclaration:getILayoutByShader method. I have added this just to be able to test it, to get some new information why this sample is not working. But I get as result just the house meshes rendered and black screen in the rest.

I do not see where does it get this R16G16_SINT format this sample. I have verified everything in the Ogre Terrain component. I need some guidance how to resolve this. I think it has to be somewhere in the RTSS system, but I do not know how to change this.
Image

Here is the output when running the terrain sample and the real time created shaders.
http://pastebin.com/uzA0133z
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

I have created a ShaderHelper for HLSL and Shader Model 4.0. But I get some unexpected warnings, and probably because of them I get the crash from the OgreTerrain sample.
WARNING: Texture instance 'OgreTerrain/1357558352/nm' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
The error I get is this one, because the resource is lost when I try to reload it. I would need some guidance where to resolve this bug. Also please look at the above presented problem - the previous topic - and if you have any ideas what to do with the Pixel Formats or anything else then answer :).
PixelShader is not NULL or Depth/Stencil test is enabled and RasterizedStream is not D3D11_SO_NO_RASTERIZED_STREAM) but position is not provided by the last shader before the Rasterization Unit. [ EXECUTION ERROR #362: DEVICE_DRAW_POSITION_NOT_PRESENT]
Here is the complete output
http://pastebin.com/CNjcnC4k
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

After a lot of discussion @Assaf Raman and I managed to correct the volume terrain sample on D3D11 Render System. There were a lot of minor bugs. Here is a screenshot :).
Image

We are working now on the old terrain sample and hopefully it will be ready today.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

After a lot of debugging I have some results on the terrain sample and the endless terrain sample. There are still some problems with the data transfer and the textures.
I had to disable the vertex compression because of pixel format incompatibility. I will think to make it possible even in D3D11 RenderSystem to use vertex compression. Now the problem is that D3D11 is stricter than the other RenderSystems. In case of the vertex compression in data Ogre send's VET_SHORT2 to the semmantic POSITION but POSITION has a type of float4. D3D11RenderSystem does not let to use this.

But here is the result now. I am debugging terrain sample just to be able to make the new samples with tessellation.
Image
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

Terrain sample seems to be more complicated then I have anticipated it. The lights and the shadows are good now, but the diffuse/specular textures do not want to load correctly.
In the screenshot below you may see a little green. All the height maps are loaded correctly, but none of the diffuse/specular textures do. I have modified a little bit the material generator, as to be able to load the shader from a different file. So in the first pass I have generated the shaders, then saved them, and after it loaded them, using C++ api and strings. (Assaf's suggestion). I have started to simplify the shaders to see what is wrong and how to correct them, addig code like this:

Code: Select all

 outputCol = 0.000001 * outputCol + difftex0.Sample(g_SamLinear, uv0); /** diffuseSpecTex1 * diffuseSpecTex2*/
 
 return outputCol;
But everything went black, the same was with all the textures (there are 3 of them in the basic sample). After that I have output the calculated texcoords as color, and they seemed fine as the whole terrain was in different colors -> so the uv's/texcoords are good.

Now I have no idea why can't I load/sampler the textures correctly. Ideas, suggestion are more then welcome.

Here are the generated hlsl shader codes for high lod:

Code: Select all

struct v2p
{
	float4 oPos : SV_POSITION;
	float4 oPosObj : TEXCOORD0; 
	float4 oUVMisc : TEXCOORD1; // xy = uv, z = camDepth
	float4 oUV0 : TEXCOORD2;
	float4 oUV1 : TEXCOORD3;
	float4 oLightSpacePos0 : TEXCOORD4 ;
	float fogVal : COLOR;
};

cbuffer MatrixBuffer
{
	matrix worldMatrix,
	matrix viewProjMatrix,
};

v2p main_vp(
	float4 pos : POSITION,
	float2 uv  : TEXCOORD0,
	float2 delta  : TEXCOORD1,
	uniform float2   lodMorph,
	uniform float4 uvMul_0 ,
	uniform float4 fogParams
)
{
	float4 worldPos;
	v2p output;
	float toMorph;
	toMorph = -min(0, sign(delta.y - lodMorph.y));
	worldPos = mul(worldMatrix, pos);
	output.oPosObj = pos;
	
	worldPos.y += delta.x * toMorph * lodMorph.x;
	
	output.oUV0.xy =  uv.xy * uvMul_0.r;
	output.oUV0.zw =  uv.xy * uvMul_0.g;
	output.oUV1.xy =  uv.xy * uvMul_0.b;
	output.oUV1.zw =  uv.xy * uvMul_0.a;
	
	output.oPos = mul(viewProjMatrix, worldPos);
	output.fogVal = saturate((output.oPos.z - fogParams.y) * fogParams.w);
	output.oUVMisc.xy = uv.xy;
	
return output;
}

Code: Select all

SamplerState g_SamLinear
{
	Filter = MIN_MAG_MIP_LINEAR;
	AddressU = Wrap;
	AddressV = Wrap;
};
float4 expand(float4 v)
{ 
	return v * 2 - 1;
}

struct v2p
{
	float4 oPos : SV_POSITION;
	float4 oPosObj : TEXCOORD0; 
	float4 oUVMisc : TEXCOORD1; // xy = uv, z = camDepth
	float4 oUV0 : TEXCOORD2;
	float4 oUV1 : TEXCOORD3;
	float4 oLightSpacePos0 : TEXCOORD4;
	float fogVal : COLOR;
};

Texture2D globalNormal : register(s0);
Texture2D lightMap : register(s1);
Texture2D blendTex0 : register(s2);
Texture2D difftex0 : register(s3);
Texture2D normtex0 : register(s4);
Texture2D difftex1 : register(s5);
Texture2D normtex1 : register(s6);
Texture2D difftex2 : register(s7);
Texture2D normtex2 : register(s8);	


float4 main_fp(
	v2p input,
	uniform float3 fogColour, 
	uniform float3 ambient,
	uniform float4 lightPosObjSpace,
	uniform float3 lightDiffuseColour,
	uniform float3 lightSpecularColour,
	uniform float3 eyePosObjSpace,
	uniform float4 scaleBiasSpecular
) : SV_Target
{
	float4 outputCol;
	float shadow;
	float2 uv;
	float3 normal;
	float3 lightDir;
	float3 eyeDir = eyePosObjSpace - input.oPosObj.xyz;
	float3 diffuse;
	float specular;
	float4 blendTexVal0;
	float3 tangent;
	float3 binormal;
	
	float3x3 TBN;
	float4 litRes, litResLayer;
	float3 TSlightDir, TSeyeDir, TShalfAngle, TSnormal;
	float displacement;
	float2 uv0;
	float4 diffuseSpecTex0;
	float2 uv1;
	float4 diffuseSpecTex1;
	float2 uv2;
	float4 diffuseSpecTex2;	
	
	outputCol = float4(0.0,0.0,0.0,1.0);
	shadow = 1.0;
	uv = input.oUVMisc.xy;
	normal = expand(globalNormal.Sample(g_SamLinear, uv)).rgb;
	lightDir = lightPosObjSpace.xyz -  (input.oPosObj.xyz * lightPosObjSpace.w);
	eyeDir = eyePosObjSpace - input.oPosObj.xyz;
	diffuse = float3(0.0,0.0,0.0);
	specular = 0.0;
	blendTexVal0 = blendTex0.Sample(g_SamLinear, uv);
	tangent = float3(1.0, 0.0, 0.0);
	binormal = normalize(cross(tangent, normal));
		
	tangent = normalize(cross(normal, binormal));
	
	TBN = float3x3(tangent, binormal, normal);
	TSlightDir = normalize(mul(TBN, lightDir));
	TSeyeDir = normalize(mul(TBN, eyeDir));
	
	uv0 = input.oUV0.xy;
	displacement = normtex0.Sample(g_SamLinear, uv0).a
		* scaleBiasSpecular.x + scaleBiasSpecular.y;
	uv0 += TSeyeDir.xy * displacement;
	TSnormal = expand(normtex0.Sample(g_SamLinear, uv0)).rgb;
	TShalfAngle = normalize(TSlightDir + TSeyeDir);
	litResLayer = lit(dot(TSlightDir, TSnormal), dot(TShalfAngle, TSnormal), scaleBiasSpecular.z);
	litRes = litResLayer;
	
	diffuseSpecTex0 = difftex0.Sample(g_SamLinear, uv0);
	
	diffuse = diffuseSpecTex0.rgb;
	specular = diffuseSpecTex0.a;
	
	uv1 = input.oUV0.zw;
	displacement = normtex1.Sample(g_SamLinear, uv1).a
		* scaleBiasSpecular.x + scaleBiasSpecular.y;
	uv1 += TSeyeDir.xy * displacement;
	TSnormal = expand(normtex1.Sample(g_SamLinear, uv1)).rgb;
	TShalfAngle = normalize(TSlightDir + TSeyeDir);
	litResLayer = lit(dot(TSlightDir, TSnormal), dot(TShalfAngle, TSnormal), scaleBiasSpecular.z);
	litRes = /*litRes + 0.00001 **/ lerp(litRes, litResLayer, blendTexVal0.r);
	
	diffuseSpecTex1 = difftex1.Sample(g_SamLinear, uv1);
	
	diffuse = /*diffuseSpecTex1.rgb + 0.00001 **/ lerp(diffuse, diffuseSpecTex1.rgb, blendTexVal0.r);
	specular = /*diffuseSpecTex1.a + 0.00001 **/ lerp(specular, diffuseSpecTex1.a, blendTexVal0.r);
	
	uv2 = input.oUV1.xy;
	displacement = normtex2.Sample(g_SamLinear, uv2).a
		* scaleBiasSpecular.x + scaleBiasSpecular.y;
	uv2 += TSeyeDir.xy * displacement;
	TSnormal = expand(normtex2.Sample(g_SamLinear, uv2)).rgb;
	TShalfAngle = normalize(TSlightDir + TSeyeDir);
	litResLayer = lit(dot(TSlightDir, TSnormal), dot(TShalfAngle, TSnormal), scaleBiasSpecular.z);
	litRes = /*litRes + 0.00001 **/ lerp(litRes, litResLayer, blendTexVal0.g);
	
	diffuseSpecTex2 = difftex2.Sample(g_SamLinear, uv2);
	
	diffuse = /*diffuseSpecTex2.rgb + 0.00001 **/ lerp(diffuse, diffuseSpecTex2.rgb, blendTexVal0.g);
	specular = /*diffuseSpecTex2.a + 0.000001 **/ lerp(specular, diffuseSpecTex2.a, blendTexVal0.g);
	
	shadow = lightMap.Sample(g_SamLinear, uv).r;
	
	outputCol.rgb += ambient.rgb * diffuse * specular + litRes.y * lightDiffuseColour * diffuse * shadow;
	outputCol.rgb += litRes.z * lightSpecularColour * specular * shadow;
	outputCol.rgb = lerp(outputCol.rgb, fogColour, input.fogVal);
	
	//outputCol = 0.000001 * outputCol + diffuseSpecTex2;
	outputCol.a = shadow;
	
	//outputCol = 0.000001 * outputCol + uv2.xyxy / 100.0;
	return outputCol;
}
Here is the screenshot:
Image
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

Some better results by forcing the D3D11_TEXTURE_ADDRESS_MODE D3D11Mappings::get(TextureUnitState::TextureAddressingMode tam) to return D3D11_TEXTURE_ADDRESS_WRAP. The texture units are created correctly but they address mode changes in time. The problem is that there are 8 texture units and the first 3 are with texture address clamp. Because of that all the next texture units are treated like having texture address wrap.

Image
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

As discussed with @Assaf Raman I have synchronized my repository with Ogre3D's official one and there was to make a pull request today. But after testing the samples I have found out that there is some problem with the material scripting, as in many times it does not find the right target/profile and the right shader language. For example:

Code: Select all

vertex_program Ogre/Instancing/Misc_vs unified
{
	delegate Ogre/Instancing/Misc_glsl_vs
	delegate Ogre/Instancing/Misc_glsles_vs
	delegate Ogre/Instancing/Misc_hlsl_vs
	delegate Ogre/Instancing/Misc_cg_vs

	default_params
	{
		param_named_auto	viewProjMatrix				viewproj_matrix
		param_named_auto	worldMatrix					world_matrix
		param_named_auto	depthRange					shadow_scene_depth_range 0
		param_named_auto	texViewProjMatrix			texture_viewproj_matrix 0
	}
}
In this case the Misc_hlsl_vs has a target of vs_4_0. And with DirectX 11 SDK also comes the HLSL compiler, so it exist. But when running the sample the Misc_cg_vs shader is called and gives errors. If I force to choose the HLSL shader without delegate then everything renders fine. There are more samples now with this problem. The other thing is that the script sometimes do not find the errors many times even if I put stupid errors in material and there is nothing in the output, but nothing is rendered.

Tomorrow I will give it a try to resolve this problem (I do not think this problem was induced by me, as I just added some new parameters to texture unit, but will see) and after that make the pull request. Suggestions are more then welcome.

I will continue to work on the project. There remained 7 samples which do not render correctly and there is a little more work to do with the new shaders. The debugging of the terrain system took much more than anticipated.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
iamxinbao
Gnoblar
Posts: 4
Joined: Wed Oct 09, 2013 3:06 pm
x 1

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by iamxinbao »

hi :wink: .
the deferred shading problem fix with dx11? :cry:
cannot bind render target view. The system is waiting for it, but it is never bound.
i want to use dx11 for my new project. but, i create deferred shading system fail.(gbuffer cann't create,beacause mrt cann't use for dx11). can you fix this problem? thanks.:wink:
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by holocronweaver »

robert_sasu wrote:As discussed with @Assaf Raman I have synchronized my repository with Ogre3D's official one and there was to make a pull request today. But after testing the samples I have found out that there is some problem with the material scripting, as in many times it does not find the right target/profile and the right shader language.
I too encountered this problem. There were cases where Ogre would select an HLSL method on Linux! Were you ever able to fix this? I will add it to my TODO so I don't forget.
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

@iamxinbao
Deferred shading example is not yet corrected for DirectX 11 Render System. The problem is from shaders. This sample also uses SSAO techniques and shaders so that is the one to debug first. Then the deffered shading. I am working on it, so hopefully will be ready in one week.

@holocronweaver
https://bitbucket.org/sasu_robert/ogre3 ... 03dd3cada9
The thing is that is no way for Ogre to choose hlsl in linux. As all the hlsl compiling part is or in D3D11RenderSystem or in D3D9RenderSystem.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by holocronweaver »

You are right, my memory was in error. The problem involved OGRE detecting ARB vs. DirectX assembly. In the end I decided it would be easiest to add an 'arb' type for ARB assembly and let the current 'asm' indicate DirectX assembly. The alternative is to have OGRE peak at the assembly and attempt to identify it, but that seems more error prone and troublesome than it is worth.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by dark_sylinc »

Hi!

Congrats on the work! Good work I see here.

I've skimmed through the thread, so forgive me if this has already been answered:

I'm here to ask about the state of depth textures: How functional is it? I saw there is now an extra stencil param "read back as texture".

Do depth textures work? Is it hacked into the RS? How abstracted is the interface? does it work with other RS? (i.e. GL, D3D9 through INTZ hack) does it integrate with Ogre::DepthBuffer?

Thanks.
Cheers.
User avatar
robert_sasu
Google Summer of Code Student
Google Summer of Code Student
Posts: 237
Joined: Mon Apr 02, 2012 11:07 am
x 42

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by robert_sasu »

DepthTexture does work on DirectX 11 Render System, and it is fully integrated with Ogre's DepthBuffer. There is the class D3D11DepthBuffer which inherits publicly from Ogre::DepthBuffer.
So everything which is true for Ogre::DepthBuffer it is also true for D3D11DepthBuffer.
As far as I know it should work with all other Render Systems, inheritance is allowed implicitely.
Google Summer of Code 2013 Student
Topic: "DirectX 11 & Tessellation samples"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Assaf Raman
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by dark_sylinc »

OMG Really!? I could kiss you!!!
I'll have to check that out at some point.
User avatar
lunkhound
Gremlin
Posts: 169
Joined: Sun Apr 29, 2012 1:03 am
Location: Santa Monica, California
x 19

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by lunkhound »

After a lot of trial and error, I finally figured out to get many of my DX9 shaders ported to DX11! The key piece I was missing: the pixel shader must have an SV_Position input parameter (even if it isn't actually used), otherwise the pixel shader's other inputs will be all wrong.
Here is an example:

Code: Select all

//
// Vertex shader
//
void skyVertProg(
        // Vertex Inputs
        float4 inPos       : SV_Position,    // Vertex position in model space
        float2 inTexCoord  : TEXCOORD0,
 
        // Outputs
        out float4 outPos       : SV_Position,    // Transformed vertex position
        out float2 outTexCoord  : TEXCOORD0,
 
        uniform float4x4 worldViewProj
        )
{
    outPos = mul(worldViewProj, inPos);
    outTexCoord = inTexCoord;
}

//
// Pixel shader
//
void skyFragProg(
        // Pixel Inputs
        float4 inPos       : SV_Position,    // do not remove! otherwise texCoord inputs are wrong!!
        float2 inTexCoord  : TEXCOORD0,
 
        // Outputs
        out float4 outColor    : SV_Target0,    // Output color we want to write
        out float4 outDepth    : SV_Target1,    // output depth
 
        uniform Texture2D tex
        )
{
    outColor = tex.Sample( gSamplerLinear, inTexCoord);
    outDepth = float4(1e6, 0, 0, 1);   // clear MRT depth texture
}
If the line that says "do not remove" is removed from the pixel shader, (notice that the pixel shader doesn't reference that parameter), then the shader will compile and run fine, however the output will be wrong because the texCoords that are passed in will be all zeros.
Anybody notice this before or have any idea what might cause this? Seems like a bug in the DX11 render system.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013 - accepted] DirectX 11,Tessellation Samples

Post by dark_sylinc »

lunkhound wrote:After a lot of trial and error, I finally figured out to get many of my DX9 shaders ported to DX11! The key piece I was missing: the pixel shader must have an SV_Position input parameter (even if it isn't actually used), otherwise the pixel shader's other inputs will be all wrong.
(...)
If the line that says "do not remove" is removed from the pixel shader, (notice that the pixel shader doesn't reference that parameter), then the shader will compile and run fine, however the output will be wrong because the texCoords that are passed in will be all zeros.
Anybody notice this before or have any idea what might cause this? Seems like a bug in the DX11 render system.
Sounds like we're GCN ready :lol: (On GCN, SV_Position is one of the very few pixel shader inputs we get for free as the rasterizer needs it and the shader math too. More info here)
On a more serious tone(*), yeah it looks like a bug; though I'm not as familiar w/ DX11 as I am with DX9

(*)Actually being GCN-friendly is something I take very seriously, as it seems AMD will dominate for the next 5 years: rules on major consoles Xbox One & PS4U, and has a two-year heads up with Mantle (vs DX 12), also the only company willing to share their arch secrets while Nvidia shuts to itself and won't openly tell what's the best way to optimize for them, and their Adreno drivers are far more stable than Nvidia's ones. Although if Tegra's K1 debut will be as good as their hype is, they'll may turn that point upside down.
Post Reply