Irrlicht and the Fixed Function Pipeline

[Radikalizm]

I think the time is here to start a discussion about irrlicht and the future (and present) technology related to real-time rendering
As you may know, Irrlicht uses an approach for rendering which relies on the fixed function pipeline provided by the Direct3D9 and OpenGL libraries, a legacy pipeline introduced back in the day when shader-based graphics programming was not a viable practice (due to hardware/technology limitations)
The pipeline provides fixed algorithms for doing things such as transformations, lighting calculations, etc. causing different results when using different rendering libraries, eg. lighting in OGL will look different as in D3D

These days graphics hardware has become more flexible and programmable with the introduction of the Programmable Pipeline, where transformations and other calculations can be done by using shaders, giving you complete control over your output
Microsoft abandoned the fixed function pipeline completely in favor of the programmable pipeline when it introduced DirectX10 together with Windows Vista, which went RTM about 5 years ago (OpenGL introduced the programmable pipeline with its 2.0 release)

Keeping this in mind we can see that the fixed function pipeline is severely getting outdated, creating a limiting factor in the further development of the irrlicht engine (Direct3D9 will get outdated completely some day in the near future, so a switch to a newer version seems inevitable)
While the switch to a programmable pipeline might be a very intrusive operation on the current irrlicht structure, most of the end-user functionality could remain the same provided that the appropriate shaders are written to rebuild the features available in the FFP
This would create a good consistency between rendering libraries, since the devs and/or the end-users (if they choose to) can now be in control of all basic algorithms needed to solve the rendering equation (this could become even more powerful when used in combination with a library like Cg, allowing you to write 1 shader for both OGL and D3D)

Of course, this could cause problems when looking at irrlicht's software renderer, or when looking at rendering libraries aimed at mobile development (I am not up-to-date on the pipeline capabilities of these libraries, so I can't really make any statements here)

I don't know whether our awesome devs have already looked into this matter (they probably have), but shader-driven engines are the future, the FFP is nearing obsoletion (is that the right word?) and I'd hate to see irrlicht fall behind

[hendu]

While the fixed functionality is gone from hardware (implemented in shaders by the driver), both AMD and Nvidia have said they will support the OpenGL Compatibility Profile for years to come.

It's a fact that the fixed pipeline is easier to use for many purposes, and it's not going anywhere anytime soon.


Your point about mobiles stands, too. It would need a different set of shaders for them, Cg can't target GLES.

[mongoose7]

1. Surely Cg is nVidia specific?
2. Parallax mapping is standard in Irrlicht but requires shaders
3. The fixed-function pipeline should be the default as it could provide a fallback when shaders are not working (due to some kind of meddling). Also, there would be many posts about bad performance from user-level shaders and you need to be able to say, "What framerate do you get with the fixed-function pipeline?"

I think all that is required is a shader interface with some example shaders. There must be a parallax shader in Irrlicht already, as I said. If this could be present in forms for HLSL, GLSL and Cg it could be a good example. Examples for post-processing would also be required, I think.

[Radikalizm]

While the fixed functionality is gone from hardware (implemented in shaders by the driver), both AMD and Nvidia have said they will support the OpenGL Compatibility Profile for years to come.

It's a fact that the fixed pipeline is easier to use for many purposes, and it's not going anywhere anytime soon.


Your point about mobiles stands, too. It would need a different set of shaders for them, Cg can't target GLES.

While this is true for OpenGL, it is not for D3D
I know there are a lot of OGL fanboys on this forum who wouldn't mind the absence of D3D, but D3D has a very large userbase, and is supported very well on windows-based machines (and face it, windows still is the #1 platform for pc gaming, and it will remain that way for a while)

The fixed function pipeline is easier to user, you're right about that, but it does not provide the possibility of complete freedom, while this freedom is available on all current-generation hardware
Although I must say that after implementing and using a PPP in my own engine for about 1,5 years now, I'm having a hard time working with a FFP
Using a PPP is not as hard as some people might think, I believe that most people are intimidated by the fact that they'll have to rely on shaders to get basic things done, although this is not something to be intimidated about since you'll get used to this way of working relatively fast

Removing the fixed function pipeline completely would not be beneficial for irrlicht, since all existing irrlicht-based applications require the fixed function pipeline to be available, instead I'd propose to move the FFP emulation layer to the engine itself, instead of relying on the FFP provided by the video driver, this would not break backwards compatibility with current applications, it would provide a greater consistency between library switches (OGL <-> D3D), and it would provide greater freedom for those who choose not to use the emulated FFP since they could rely on their own shaders in the PPP

[hybrid]

We already have this to some extent in the ogl-es 2.x driver. Moreover, this does not really remove the fixed function pipeline or anything like that, but (as already pointed out somewhat) simply changes some internals to do their job differently.
Once you drop the logic layer, which was already more generalized in Irrlicht than provided by the fixed function pipeline, you are once again down at the low-level graphics programming. Even if that's now easier with shaders, you still need lots of management and administration by the engine.
I doubt that we will get a fully featured, completely configurable shader based engine at some point. Simply because that would be almost no easier than bare HLSL or GLSL interface. It will be more an addition of certain aspects in the API, which allows all necessary effects to be implemented. Such things include the flexible vertex format, better material management and properties, etc.
But we're still heading for easy usage and a braod range of devices. So don't expect yet another Horde3D or something for the future of Irrlicht. But of course also not yet another click'n'drop game maker. It's somewhere in between where Irrlicht will stay, just as before.

[Radikalizm]

@hybrid:

That sounds very reasonable, you are right about the fact that irrlicht should remain what it is today, an easy to use cross-platform library, that's exactly what makes the engine so great

If you ever need any help with these possible additional features, I'd be glad to help out (as mentioned, I'm designing my engine to be completely shader-driven, so I've gathered a good amount of knowledge on the subject)

[3DModelerMan]

I think all we really need is a DX10/11 driver, the flexible vertex format, and cubemap support and maybe 3D textures, and it would be great. Does Irrlicht support compressed textures? If it doesn't I think I might write a patch that makes it. The one problem I ran into when trying to write a directx 10 driver on my own was the fact that you can't switch one render state at a time. And another thing that would be nice is easier multipass rendering support.

[Mel]

But Irrlicht supports already the programmable pipeline. If you don't want to use the fixed function rendering, it is perfectly posible, though i get what you (Radikalizm) mean.

I think that a small step forward would be, perhaps, to replace all the current materials with shader based specific ones. And add fallbacks to fixed function pipeline materials for those which couldn't be created.

There are many articles regarding to flexible material systems. In the ShaderX6 book there is an article regarding to this. Here is a link where it explains more or less how would work, i can't provide any link to an implementation though.

http://www.coretechniques.info/2008/Material.zip

[3DModelerMan]

I think that a flexible vertex format would need to be similar to the input layout system in D3D10.