DX11 support showing on Wikipedia

[LunaRebirth]

I hate to read that Irrlicht is dying, as it's been a great engine for me. I tried Unreal and Unity, but didn't like either of their licenses and they were too complex for me compared to Irrlicht when I was getting into development.

As someone who has never been involved in modifying svn branches, how would you guys suggest new(er) people do this? I'd love to contribute, though I'm unsure where to start.

I'm developing a rather complex engine extended off of Irrlicht, so I'll have changes to be committed to Irrlicht in the future, including some mobile changes I've made.

[CuteAlien]

I'll try to keep it alive some more ;-) Just can't do it always, life & stuff going on sometimes (rarely!).

Contributing to Irrlicht usually starts by fixing things you run into and then creating patches. Creating patches is mostly done with the "svn diff" command. On Windows I have MinGW installed for that so I can run it from command-line (so I'm not sure if it can be done from GUI as well... never really tried).

[masm32]

The problem with missing triangles is easy to explain. TriangleFans are not longer supported by D3D10 and higher. So trying to render tri fans will fall back to tri list or strip with to few vertices or indices.

I have tested the examples. The only examples not working are these below. Some errors in rendering (colors, shadows etc.) are due to shaders without implemented effects.

Example 08. SpecialFX, the shaders for shadow rendering are missing (I think).
Example 10. Shaders , the material for rendering is not implemented. DX11 is missing the fixed function pipeline, so for every material a shader has to be written.
Example 13. RenderToTexture, The RenderTarget is handled differently on DX11 implementation of Irrlicht. Have to check this.

Maybe I should ask cutealien that I can work on shader-pipeline.

https://drive.google.com/open?id=1mVkwV ... F8DEICjmdA

[robmar]

I could do the shader work... both HLSL and GLSL.
Just need CuteAlien to say he wants to manage us

[masm32]

Nice robmar. I fixed the RenderToTexture in the DX11 implementation. In the shader branch the RenderTarget gets automatically a stencil depth buffer attached. This makes no sense, because if I want to make a RenderTarget with 4 Textures, I'll get 4 stencil depth buffers as well, which is a waste of resources. A RenderTarget only needs one depth stencil buffer. So I changed it to work like in the main trunk.

Next is to change the IMeshBuffer to use vertex and index buffer. This will make Hardware Instancing and Hardware Skinned Meshes easier to implement.

[CuteAlien]

Sure, PM me if you want access to that branch. Right now there's no-one working on it, so I'll be fine if someone wants to improve it. Just note that I can't help out much with it (I can only help to tell about existing stuff, but haven't worked with anything > DX9 so far myself).

[robmar]

@masm32 Yes I agree, I think the stencil buffers can be optional if only needed for shadows, that method is really too slow for any real use IMO.
Hardware meshes are supported previously, is that not running in DX11? Skinned h/W meshes... are partial updates to mesh buffers in GPU memory supported under DX11?

@CuteAlien, okay, I guess masm32 and me can start things moving. I´ll PM you now

[masm32]

@robmar I wanted to be as close to the trunk code as possible. For this not all changes from shader-pipeline are used at the moment. The trunk code base uses many dynamic vertices send to the driver. This is something I want to go away from. Main goal is to be as close to Irrlicht trunk as possible, but retain th ease of use.

Usually avoid updates to mesh buffers if possible.

[robmar]

Not sure what you mean, you want to avoid some of the updates in the main trunk, but stay close to the trunk?

We should maybe also look at the bGFX Irrlicht branch, as that will support all the drivers that the bGFX project supports, which might soon include Vulkan.