DirectX 11 render system - work-in-progress

[Assaf Raman]

He wrote the he started also to work on it - in his blog. - but a long time ago.

[Assaf Raman]

I can't see anything, but I am getting closer.
Here is a backup snapshot of the code: http://assafogre3dforumfiles.googlepage ... 0_pre2.zip

I need to implement the serialization of the shader parameters, until then I won't be able to see anything.

In dx 10 you have to have a shader when ever you render – you can’t render without a shader. So – to see anything that OGRE draws - you need to map some parameters.

I had a lot of problem also with mapping of the vertex buffers – in DX 10 you must have a shader in order to map a vertex buffer – and OGRE has lots of buffers without a shader – so – I created a test shader with only a pos – to test that I can map, well, I couldn't, it turns out that structure of the vertex buffer must be the same as the parameters that the shaders get, so if I have a vertex buffer with a position and a texcord – if you have a shader like this:

Code: Select all

float4 VS( float4 Pos : POSITION ) : SV_POSITION
{
    return Pos;
}

With only a position – you won't be able to map the buffer (the CreateInputLayout will return an error) . For now - I wanted to move on and not deal with it – I created all of the common OGRE demos combustion – one shader for each – pos+tex, pos+tex+color, pos+normal+tex, pos+normal+color. Looks bad – right? I will deal with it later and auto-create it or solve it somehow.

I also have a problem to compile and get the parameters from the assembly shaders, but I don't want to deal with it now. The HLSL shaders compiles fine and I can query the parameters of the shader – so I am doing fine for now.

Lots of messy code all around – when I will get it working I will start to sort it out.

[sinbad]

Isn't Sinbad plugging away at this as well?

It's still on my TODO but I haven't had much time for it lately. I'm still of the opinion that Dx10 is overrated and relevant to a niche audience right now, so it's not my top priority.

Dx10 is actually a pain in the ass. They've tightened a number of the APIs to the extent that they're actually quite painful to work with, particularly things like buffer access modes, state block management and input layout management (the latter harkens back to the Dx8.1 API which was one of the nastiest). There will need to be lots of derived-and-cached state objects in the final Dx10 implementation, for example hanging custom structures off Pass. It'll be a while yet - work like Assaf's will certainly help and I'll merge ideas / techniques from others into our final version when I get time.

[Assaf Raman]

I found this quote:

Direct3D 10 Shaders are Authored in HLSL
Direct3D 10 limits the use of assembly language to that of debugging purposes only, therefore any hand written assembly shaders used in Direct3D 9 will need to be converted to HLSL

here: http://msdn2.microsoft.com/en-us/library/bb205073.aspx

So - how do we do use Cg shaders?

Then I found this quote:

The 2.0 release of Cg introduces several new features and improvements:
…
These expose new DirectX 10-class features including geometry shaders, bindable constant buffers for uniforms, texture arrays, first-class integer support and more

In the features of Cg 2.0 - http://developer.nvidia.com/object/cg_toolkit.html

I had a look at the Cg 2.0 toolkit – and there are no DX10 samples… Strange.

It seems they added to openGL API that is corresponding to DX10.

SO – I guess there is no Cg support in DX 10. Also no assembly shaders. (Today - Jan 2008)

That is bad new.

I will be happy if anyone will prove me wrong.

[Assaf Raman]

A friend found also this link for me:
http://developer.nvidia.com/forums/inde ... wtopic=636

Direct3D 10 support is not planned until after Cg 2.0

So - one day - but not now.

[Assaf Raman]

It seems that my vertex and index buffer are not built correctly from some reason, I will continue to work on it this week and next weekend. I am very close – I created the parameter serialization – but something is off with the buffers, I integrated the third tutorial code from the DX10 tutorials in order to see what is wrong – and I see that when ever I bind my buffers – it doesn't render, so – I will keep trying to find the problem. I really wanted to have it rendering by tonight.

The code is messed up – I turned most of it off to find this problem – so I am not posting it for now.

[Kojack]

It seems they added to openGL API that is corresponding to DX10.

There are nvidia-only opengl extensions which expose the geometry shader and other dx10 style stuff to CG 2.0.
OpenGL itself won't have DX10 features finalised until OpenGL 3.1.

Hmm, I didn't realise CG 2.0 won't work in dx10.

[Assaf Raman]

I guess I will use the "FixedFuncEMU" sample that comes with the DX 10 samples to emulate certain aspects of the Direct3D 9 fixed function pipeline.

http://msdn2.microsoft.com/en-us/library/bb205062.aspx

This sample attempts to emulate the following aspects of the Direct3D 9 fixed-function pipeline:
Fixed-function Transformation Pipeline
Fixed-function Lighting Pipeline
AlphaTest
User Clip Planes
Pixel Fog
Gouraud and Flat shade modes
Projected texture lookups (texldp)
Multi-Texturing
D3DFILL_POINT fillmode
Screen space UI rendering
Fixed-function Transformation Pipeline

I just need to add an auto generator to fit the vertex buffer declaration of the input struct and an auto generator for the use of them - easy then you think. I will add a class to handle the FixedFuncEMU, I will name it - FixedFuncShaderManager.

Any better ideas for this? Did anyone do it already and can share the code with me?

I hope I am not in over my head with this...

[Assaf Raman]

I was sick the last few days, so I didn't go to work. I was too sick to work on this also.

Today I was feeling better so I continued the work on the DX 10 render system.

I can render tutorial 2 of the DX 10 tutorials but not much more.

I wanted to finish some more "state set" functions, so that is what I did for now.

I also found out how to get the errors description of errors and how to log them, so that’s help, I can see it in the debug output and I am going to add it also to the OGRE log.

I also wrote the shader parameters code, that should set the parameters for the shaders, I don't know yet if it works – I can't see anything yet as I wrote.

Here is a snapshot for the current code if someone wants to have a look or save a backup of all the work I have done: http://assafogre3dforumfiles.googlepage ... 0_pre3.zip

[sinbad]

I'm still very short of time to look at this in much detail but you can rest assured I'm backing your work up

[Assaf Raman]

I am having a problem with the vertex buffers in OGRE, specifically with a color vertex element, in DX 9 and GL – it didn't matter if you used a uint for the color with one byte for each color and then declared the color in the shader as float4, but it doesn’t work in DX10, it has to be a float4 value in the vertex buffer if you want to declare " float4 inDiffuse: COLOR0" in the shader.
So what should I do? Correct the shaders? Convert the buffer in runtime? What else so we can support existing mesh files and existing shaders?

I can do the runtime conversion – but then I will have to create a whole system to track this conversion, any ideas?

[Assaf Raman]

I have and idea for my last post – use a geometry shader for the conversion.
OGRE doesn't support geometry shaders for now – so I can detect this case, dynamically build the shader code to fit the vertex buffer structure, and then convert the color part of the buffer to float4 or what ever the shader expects in the output of the shader.

It will work. Sadly it will be a lot of work.

This is the best generic solution for the problem that I can think of.

Any other ideas or views on this?

[Assaf Raman]

I couldn't get the geometry shader solution to work no matter what.
It turns out that the input and output structure that the geometric shader gets must be with the same vertex structure.

But I know the solution – there is no need for geometry shader, the solution is to append a new function to the end of the vertex shader to do the conversion then call to it as the entry point, that new function will call the original vertex function.

Sample:
If this is the function you have and want to work:

Code: Select all

row_major float4x4  World;
row_major float4x4  View;
row_major float4x4  Projection;


struct VS_INPUT
{
    float4 Pos : POSITION;
    float4 Color : COLOR;
};

VS_OUTPUT VS( VS_INPUT input )
{
    VS_OUTPUT output = (VS_OUTPUT)0;
    output.Pos = mul( input.Pos, World );
    output.Pos = mul( output.Pos, View );
    output.Pos = mul( output.Pos, Projection );
    output.Color = input.Color;
           
    return output;
}  

(Taken from tutorial 4 of the dx tutorials)

You need to append this code to the shader source:

Code: Select all

struct OGRE_COLOR_TYPE_VS_INPUT
{
    float4 Pos : POSITION;
    unsigned int Color : COLOR;
};

VS_OUTPUT VS_FOR_OGRE( OGRE_COLOR_TYPE_VS_INPUT input )
{
    float4 newColor;
    unsigned int val32 = input.Color;
     newColor.x = ((val32 >> 24) & 0xFF) / 255.0f; 
     newColor.y = ((val32 >> 16) & 0xFF) / 255.0f; 
     newColor.z = ((val32 >> 8) & 0xFF) / 255.0f;
     newColor.w = (val32 & 0xFF) / 255.0f;
    
    VS_INPUT original_VS_input;
    original_VS_input.Pos = input.Pos;
    original_VS_input.Color = newColor;
    
    return VS(original_VS_input);  
}

And change the entry point from VS to VS_FOR_OGRE.

It works.

Here is my tutorial 4 with a change to OGRE buffer type and still working with the new entry point: http://assafogre3dforumfiles.googlepage ... rial04.zip


To auto-generate the new function won't be easy.

[Assaf Raman]

Got it to render a simple cube. I will post an exe demo later today.

[sinbad]

Yuck, that's nasty - so Dx10 won't convert from a declared vertex format to a shader binding on its own if the types are different? Talk about a backwards step....

There's quite a few things like this that make me think Dx10's API design is a bad idea. They made some similar design decisions in Dx8.1 (where you had to generate vertex declarations from a shader if it was in use) and it just made everything a hell of a pain to work with. I'm sure it makes driver writing much easier and the shader invoking faster but dang, thanks for pushing that complexity on to the application / engine instead chaps. Couldn't they just have left it like it was and said 'it'll be faster if you precisely match vertex buffers and vertex shader inputs'?. Seems like a bit of a cop-out to me.

[Assaf Raman]

I posted the demo here (with a screenshot): http://www.ogre3d.org/phpBB2/viewtopic.php?p=26671

Here is the latest code: Direct3D10_pre4.zip

[Assaf Raman]

I am having a problem with manual mipmaps.

If you create a 2D texture with the CreateTexture2D function of DX 10 and use the D3D10_USAGE_DYNAMIC flag so you can update the mipmaps later – you get this error if the MipLevels parameter is not 1:

D3D10: ERROR: ID3D10Device::CreateTexture2D: A D3D10_USAGE_DYNAMIC Resource must have MipLevels equal to 1

I guess there is a different way to do this.

Can anyone help?

UPDATE: I found howto do this - you use ID3D10Device::UpdateSubresource.

[Assaf Raman]

I hacked the texture loading to work; it uses the D3DX10CreateTextureFromMemory utility for now. It is all I need for now.

There is a new demo in the showcase thread of this project.

Latest code here: Direct3D10_pre5.zip

[Assaf Raman]

Got the texture loading with FreeImage working.
Got the basic fixed func working.

Now you can see the stats.

There is a new demo in the showcase thread of this project.

Latest code here: Direct3D10_pre7.zip

[sinbad]

Nice work Assaf, I feel your pain when it comes to navigating the Dx10 API.

For what it's worth, I did some work in the vertex / index buffers area you might want to merge into your version, since I notice right now you've made them very simple. In CVS I abstract it all via D3D10HardwareBuffer which handles things like how to manage locking resources that aren't dynamic via temporary scratch copies, and similar issues. Each of the D3D10HardwareIndexBuffer and D3D10HardwareVertexBuffer classes holds a D3D10HardwareBuffer internally as the underlying implementation which does all the work, since D3D10 uses the same code for index and vertex buffers now.

[Assaf Raman]

Thanks, I was thinking of doing the same thing. It will save me the time.
I am still thinking what is the best way to go about the fixedFunc - any tips?

[Assaf Raman]

Got the texture mipmaps working.
Got the stats to the right size.

Still having problems with non shader geometry.

There is a new demo in the showcase thread of this project.

Latest code here: Direct3D10_pre8.zip

[Assaf Raman]

I am having problems with ShadowVolumeExtrudeProgram (a class containing source for vertex programs for extruding shadow volumes), there are hard coded assembly shaders in the OgreShadowVolumeExtrudeProgram.cpp, and as I wrote – assembly shaders are not supported in DX10, so, we have a problem here…

In the header of this class the CG source of the assembly programs exists, I guess I can hack it – so I will compare in "D3D10GpuProgramManager::createImpl" the assembly code, then compile the appropriate hlsl program and return it.

I don't like this hack.

I also don't like the ShadowVolumeExtrudeProgram class, I think it should request the shader from the render system – and let the render system build an appropriate program.

Or – ShadowVolumeExtrudeProgram should let the render system overide the default program.

[Assaf Raman]

Got the non shader geometry working for some of the OGRE demos.
Now the stats have a color issue now.

Having problems with shadows and skyboxes.

There is a new demo (Demo_ParticleFX.exe) in the showcase thread of this project.

Latest code here: Direct3D10_pre9.zip

[Assaf Raman]

I am working today on merging the code of the CVS and my code. It is taking more time then I wanted it to take, but - I think I am doing a good job. More updates in the next few days.