DX11 support showing on Wikipedia

[AReichl]

> Or last week I offered someone to take over maintenance of shader-branch
Shouldn't Nadro continue? - Is he still alive?

> how do we get a PBR pipeline supported which works well with current other tools like Blender
YES!!!

[CuteAlien]

> Or last week I offered someone to take over maintenance of shader-branch
Shouldn't Nadro continue? - Is he still alive?

Nadro got married last month - I suspect that counts as alive ;-) But he didn't like the implementation of the shader branch and started his own implementation. So currently shader branch is without maintainer.

[robmar]

@AReichl - any pointers on the necessary patches would be a great help!

Which branch of Irrlicht does the patch work with?

[AReichl]

> So currently shader branch is without maintainer.
That was announced some time ago.

> ... started his own implementation.
Independent fork or will it be a new Irrlicht version ( let's say 2.0 ) ?
If so, then the shader branch does not have to be maintained any more. See it as an intermediate step or prototype for learning.

[CuteAlien]

It's probably going to be 2.0. That is if Nadro finds time for it - I don't know much work he put into that so far as I've not seen that code yet.

[masm32]

I know that there are issues with the DX11 implementation. Some effects are not showing, texcoord generation not correct, missing faces.
But like I mentioned earlier, its basically a merge from shader-pipeline into the code trunk. I don't wanted to reinvent the wheel with a new own implementation.

Unfortunately i stopped working on DX11 for Irrlicht, because I switched over to Ogre3D. It's also easy to work with and it is more up to date.

It's sad that Irrlicht is almost dead, but over 5 years from last release (only bug fixes) shows that there is nearly no improvement anymore.
I liked Irrlicht all the time, but maintained by only one person is not enough to keep a project going.

[CuteAlien]

We have a lot of improvements in the svn trunk version, just not DX11 (it's simply not something that came up in my projects so far). But getting to a release is indeed hard.

[robmar]

Why bother now that bFGX has been patched in, isn't that the way to go?

Also it supports the SPIRV language for shaders and GPU compute.

[CuteAlien]

Sorry, don't know - I haven't looked at bFGX yet. I'll care about new drivers when I ever get to the 1.9 release.

[robmar]

How's that going by the way?

[CuteAlien]

Well, we missed another year. But I learned a lot about Irrlicht drivers in 2017 (while working on webgl driver), so I'm finally able to work on the core stuff myself. Currently struggling with some Android problems. Hope the same as every year - that I manage that release. Unless too many new things get broken I'm optimistic (and as no one else commits anything currently I guess not much things will get broken).

[masm32]

@robmar I looked at irrlicht_extended from JT90 that included bGFX. To use a render system to abstract away the burden to implement the driver itself is great. Pbr rendering would be great to, but should be implemented after a new renderer, because all new 3d api uses an different approach (shader and buffer creation) than directx9. If the pbr rendering will be modelled after directx9, it will be much harder to implement newer api's.

[robmar]

Good to know CuteAlien

Masm32: is irrlcht_extendexvdx11 good? And what about vGFX, did you try it?

[CuteAlien]

I was so optimistic about this year in January. Now 4 months without really coding successful for Irrlicht. Well, year is still long... will get some stuff done at some point I guess :-)

[robmar]

I think the next step should be to integrate bGFX, at least that way Irrlicht driver support could be offloaded to another team.