Horde3D

I was asking in another forum about GLSL, because I've had students with some issues running GLSL shaders particularly under Ogre.

http://forums.indiegamer.com/showthread ... post196597

Anyway, one of the participants suggested using the CgFX framework to compile shaders to GLSL and thence onto shader assembly.

One upside of using Cg, is that its pretty well supported tools wise, has a bunch of demo's and examples and has support on the PS3 of sorts (if I recall).

Any idea how much work it would be to incorporate CgFx as the main shader framework? I might have a look at it over summer if I get any free time (its unlikely given my research workload right now, but you never know).

A side benefit would be that you could compile shaders to HLSL via the Cg runtime and get xbox and better PC compatability as a side effect.

Am I missing something obvious?

A lot of the so-called 'GLSL issues' tend to be caused by people writing shaders on NVidia's (broken) drivers, and expecting them to work on other platforms/vendors. I would suggest making very sure that your shaders actually follow the GLSL specification, to the letter.
Probably not that much - you just have to rip out and replace the shader class and fix some of the shader-related resource parsing.
HLSL doesn't do you any good without a DirectX port. Once a DirectX port is in the works though, it would be a nice feature.

_________________
Tristam MacDonald - [swiftcoding]

The main reason for using GLSL was that we could avoid the realtively heavy Cg dependency. Another reason is that the Cg shader needs to be compiled two times (Cg -> GLSL, GLSL -> internal format) which is not optimal, especially since we support übershaders that could have many permutations. It is also possible to compile Cg to arbvp1/arbfp1 but these profiles are very old and I guess they do not support all newer features.

I don't see the need for CgFX so much. We have a custom FX format that is in theory independent from the shader format (samplers and constants are declared without using any FX syntax). We also have a small pre-processor so include files and defines for the shader combinations are no problem. Regarding the tool support, I don't know if you really need fancy tools like FXComposer, RenderMonkey or shader graphs a la Mental Mill. A text editor with proper syntax highlighting and hot reloading of shaders (e.g. through the Horde Editor) have always been enough for me. Especially since most advanced techniques require render targets and multiple passes and there is no standard for them. BTW, speaking of hot reloading, Horde supports it easily for most resources.

The only real advantage that I see for Cg is the portability. HLSL emerged from Cg, so it is basically the same. And as you already mentioned, Cg is the shader language for the PS3.

Actually it should be fairly easy to implement support for CgFX. We are slowly refactoring the renderer so that all graphics API specific things are abstracted. This abstraction layer should also make it easy to exchange the shading language.

Yeah, I was thinking mainly of a directX port when I asked the question. At least CgFX has a pipeline for all my target platforms.

I'll have a look over the code when I get a spare few hours at work and see how it would work.

GLSL to my mind was a bit out on a limb in terms of how I expected a shader to be setup. Considering I'd used HLSL mostly (and before that shader asm). So it was very weird when my students came up with GLSL code and it looked very different

My main thing, is that I'd rather be compatible with as many major tools as possible because I know that my user base if I ever get to the user-created-content that I need, is going to use those tools.

Please use the latest SF svn trunk since it already has some parts of the abstraction layer. However, the shader abstraction is not yet finished.


It is not so distinct, the main difference is how data (from program to shader and between shaders) is passed. I think the GLSL way is a bit more elegant while the HLSL solution may be a bit more powerful.

The automatic binding seems like a nice idea. Although others in that thread I posted said that certain drivers/cards have issues with it.

I'll get the code from the latest svn when I get a bit of freetime (probably after the ai games workshop in paris in early june) then give it a go.

There used to be issues when GLSL was new but the drivers are much more mature now.

Hmm, well, GL has always been the poor cousin when it comes to driver development sadly. I liked the old GL interface but cant say anything about GLSL because I've never used it in anger.

Seriously though, I think having a DX backend cant hurt.