Finally, a DirectX 10 video driver for Irrlicht

[Mel]

Yeah, i have noticed it. What i have noticed also is that there is some connection between the shadow volumes calculated and this Z fighting. While it is always present, the Z fighting problem evidences some times the silouette of the extruded volumes, hence the connection. But what does it mean, i can't tell.

Given it is a driver issue, the most probable is that there is some render state that isn't properly set.

[Nadro]

Nice work Mel!

[Mel]

Thanks! A question. Isn't it posible to use a shader for standard vertices on tangent vertices? why the shaders are triplicated? i get an error that complains about the "layout" or something, as it is in spanish, i guess it is an error caused by the DirectX runtime.

Also, i had to disable the 11.1 level, or else i couldn't compile it ^^U

[zerochen]

Also, i had to disable the 11.1 level, or else i couldn't compile it ^^U

what is the error msg? maybe this one (added this to the first error):
//! If you got an error here that 'D3D_FEATURE_LEVEL_11_1' is undeclared you have to download an appropriate DXSDK
//! Download: http://msdn.microsoft.com/en-us/windows ... 52363.aspx

The project files for Visual Studio Express 2010 don't include the sources needed for the DX11 driver compilation. I can manually add them, though, but it could be better if they were already included on the branch

i guess nadro, granyte and me only uses vs2012. but you can provide a patch for that, so the next one doesnt run into this problem:)

For the programmable pipelines could be a good idea that the users could replace the fixed pipeline shader with custom ones . That way, the whole looks of the engine could change according to the needs of the users

do you mean to put the fixed function shader in a file and load it on startup? i think that isnt a good idea because the end user can change everything eg in a fps game make walls transparent and so on.

What is the transparent material problem?

not sure if it is the same problem but you can see in example 16 also a bug there. you can see the flames of the torches and lamps only if you are in a lamp or look from above to the torch.

[Mel]

No, i meant to provide the user with the ability to replace the shaders, not like the compileshaders, but to substitute the current ones, the current system is fine, no need to change that But, for instance, that the EMT_SOLID material changed, at user's will, to a per pixel phong instead of a per vertex and or to a cellshader, or to any other thing just providing it. It is just a thing that poped into my head.

With regard to the downloadable WindowsSDK... well, i browse using Linux and develop with an offline Windows 7 machine as i don't trust any microsoft operative system connected to Internet, nor i wish any other software spying my memory during work. Besides, although i already have it, for me switching to Visual Studio 2012 is risky, as i have all my projects on VS2010, i don't want to lose the backwards compatibility with DX9 very fast, my other option would be to install Code::blocks also...

I saw the transparency issue on example 8. And saw more problems with the extruded volumes of the shadows, so, take a look at that. Are you disabling the ZBuffer writting with the transparent materials? The example 10 (shaders example) tells me the mesh rendered with the shader using the transparency is rendered prior to the solid ones. The transparent materials need to be rendered with ZTesting but with the ZWrite disabled and later than all the solid meshes.

[Granyte]

i used vs2012 for a very short amount of time it's just that kept working on the vs2012 solution with my vs2010

[Nadro]

No, i meant to provide the user with the ability to replace the shaders, not like the compileshaders, but to substitute the current ones, the current system is fine, no need to change that But, for instance, that the EMT_SOLID material changed, at user's will, to a per pixel phong instead of a per vertex and or to a cellshader, or to any other thing just providing it. It is just a thing that poped into my head.

I think that any special modifications in this case aren't require, because it's open source project, so user can recompile engine with different shader. Other option is just add next material (eg. phong shading) via addHighLevelShaderMaterial interface.

[Mel]

No, they aren't required. And compiling via addHighLevel... will provide you with an identifier to apply to change the material, all that is nice. My point is. What if i want that the EMT_SOLID material behaved diferent so i don't have to apply the materials? But it isn't a modification i want to the engine, or the like... in the worst case i can do that myself modifying the sources

[hybrid]

Yes, I think it would be better to keep such a thing basically out of reach for the average user. I'd suggest you to add an access to the renderers array internally, that would allow you to change the shader implementation also for existing materials. However, since the shader interface might improve over time, you might also get access via the engine to some extent in later versions. Nothing planned so far, though.

[Mel]

I wasn't asking for a modification for the engine at all just pointing out an idea.

[bdpdonp]

I have been following this thread and reread it. My question, is this at a point I could make the changes to my Windows deployment of irrlicht and test out DX 11 drivers?

[Mel]

All the examples are working, and really, this video driver only covers the functionality of the interface of the video driver, so it is posible to switch to this, but it still doesn't cover the functionality 100%, perhaps, the blending modes (additive materials...) still need some polishing. So, for the time being, it is better to stick to DX9c, or OpenGL

[kaliber]

where we can download and try the latest patched one ??
when will it merged to irrlicht trunk ?

[Granyte]

its included in the shader pipeline branch of irrlicht

[kaliber]

ow ok, let's check!!!!¡¡¡