CgFx support in OGRE

[Assaf Raman]

This is a "work in progress feature" - so - I don't think it will be the best option to put it in the official stable release.

You can as other done - add it to the 1.6 by hand as it seems you did.

[Evak]

Hey cool. Shaders are always a HUGE stumbling block for artists using Ogre. I use ShaderFX with ofusion since ofusion exports scenes with shaders straight from shaderFX. But you have to have Ofusion pro to use the shaderFX bridge and it's D3D only.

Supporting CGFX really makes things much simpler for artists wanting to use inexpensive tools

[hangchon18]

http://assafogre3dforumfiles2.googlepag ... _fixed.zip
this link can't be downloaded.

[reptor]

That link seems to work fine for me (I'm in Finland).

[Praetor]

Ok, so I've started to look at this once again. There are some important stumbling blocks still. The first is light bindings. They seem very fragile, and Cg doesn't have very robust mechanisms for determining if something is a light binding or not. I'll keep working on this.

The other problem that is not so easy is that some constants are being ignored by our Cg plugin manager, but not by any fault of ours that I can tell. The Cg toolkit actually reports that the parameter is unused, except that it very much is used. Many mental mill shaders use the inverse camera matrix as the basis for their view-dependent lighting effect (like specularity) and the __camera_to_world variable is the culprit. Anyway, by way of testing I pulled the shaders out of the cgfx and put it into cg files and wrote a .material file and loaded them in a more normal fashion. The same problem persists. Now, I haven't run into many Cg Toolkit bugs before, but I know some people here have. The only problem is that I'm sure internally FX Composer is using similar mechanisms. My next avenue is trying different profiles.

[Praetor]

So, I had a small epiphany this afternoon. It kept bothering me that Ogre would have problems with a Cg shader that FX Composer displayed fine, since we should be using the exact same nVidia Cg toolkit to process it. Then I realized "what if we aren't using the same toolkit?" Sure enough, in my dependencies I still had Cg 1.5. After updating and recompiling with 2.1 the phong shader displays fine. The only thing I had to tweak by hand was the profiles. Other than that... exported from mental mill, loaded into Ogre. My attention now will be focused on finding and filling any holes going from CgFX to Ogre. I suspect a lot of that will be focused on general light bindings.

Related to this and what many others were interested in, Kevin Bjorke sent me the current version of his FX Composer -> material exporter. It is rough around the edges and I have yet to tease out its full capabilities and limitations. He warned me that certain internal issues with FX Composer would probably make it hard to robustly export material files. This is a shame. However, we know that everything we need is in the CgFX files, and so I am more confidant now that Assaf and myself are going down the correct road with this importer. Still, I will be investigating further this exporter and let everyone know what I uncover.

[Praetor]

So, I've conquered another sample shader from FXComposer. This being the standard blinn bump shader. There's also an environment map. The normal map isn't easily seen in this screenshot. I rewrote the light binding code, but there is still more to be done.

The problem I'm still dealing with now is that the textures weren't binding properly. I had to manually reorder them to make it look like it does in FXComposer. It was using the normal map as the diffuse map and vice versa. That's because when I write a Cg shader for Ogre I use register(s0) or TEXUNIT0 to explicitly bind texture units. The shader in the FXComposer script doesn't have that. So, I'll have to figure out how to force the bindings in the correct order.

[nikki]

Are there any programs that export to cgfx, and support being run under Linux? mental mill does, but the artist edition doesn't. I'm looking for something hopefully free.

EDIT: I found QShaderEdit, gonna try it out now.

[Assaf Raman]

Do you think we should add a collection of cgfx shader files and a sample that shows them to the base OGRE install?

[Praetor]

That's a possibility. Right now I'm using a modified CelShading demo. I could just break it out with the same code into a new demo.

I'm still investigating the texture issue. I'm fairly certain FX Composer uses a Cg toolkit function which tells Cg to auto-manage texture units. This is something we can't really use, since the concept of textures and texture units is fairly separated from GpuPrograms and even more separated from Cg GpuPrograms. I've got a hunch that the order the texture units are accessed in the shader is determining the order they need to bound. So, even if CgFX defines the diffuse texture first, then the normal map, if the normal map is accessed in the shader first, then the normal map needs to be texture unit 0.

[voxel]

Related to this and what many others were interested in, Kevin Bjorke sent me the current version of his FX Composer -> material exporter. It is rough around the edges and I have yet to tease out its full capabilities and limitations. He warned me that certain internal issues with FX Composer would probably make it hard to robustly export material files. This is a shame. However, we know that everything we need is in the CgFX files, and so I am more confidant now that Assaf and myself are going down the correct road with this importer. Still, I will be investigating further this exporter and let everyone know what I uncover.

FX Composer to .material was something I fought with for a while (months ago). Here's what I wrote to Kevin back in July when I started using .fx (vs. .cgfx):

Okay, I finished a complete HLSL .fx test case and it was more problematic than the CgFX one (which I tried back in April/May):

* "target" vs. "profiles" keyword (OGRE requires the use of target XXXX for hlsl shaders and profiles for Cg shaders - annoying)
* "light_position" vs. "light_position_world_space" (_world_space not needed in the .material)
* "matrix4x4" vs. "float4x4" (float4x4 types in the shader should be converted to matrix4x4 in OGRE)
* Different matrix multiplication order issue (again - had to manually swap order in .hlsl code for everything to work in OGRE)
* FLIP_TEXTURE_Y works in FXComposer (in DirectX mode), but needs be disabled in OGRE (under DirectX)
* .fx not supported by OGRE, but using .cgfx as-is (I tried this before).
* HLSL/CgFX global variable names used instead of vertex/fragment shader parameter names. I cleaned up the shaders before export to avoid global variables (all parameters were passed via uniforms).
* Full texture paths causes OGRE errors (OGRE wants all textures in its resource paths and barfs on spaces in filenames)

Next time, I'll stick with CgFX.

Stuff like order of parameters (especially for matrices), passes, vs/ps profiles have to be dealt with. I found CgFX friendlier than HLSL FX files.

[jacmoe]

Are there any programs that export to cgfx, and support being run under Linux? mental mill does, but the artist edition doesn't. I'm looking for something hopefully free.

EDIT: I found QShaderEdit, gonna try it out now.

Had any luck getting it to run?
It bombs out when trying to compile cgfx..
I'd really like having a shadereditor in Linux.

[Wretched_Wyx]

Howdy,

I asked about creating a hemispherical lighting effect with mental mill some time ago on the mental mill forums. The help I got, and the resulting solution turned into something a little more advanced- what seems to be simple radiosity mapping. I'd like to see if this runs, but haven't implemented the CgFX support yet. That, and I thought I'd share . Included is the shader, the ground color map I made (with a top-down view export from World Machine), and the mental mill workfile.

Please note that the workfile was made with the mental mill beta, not the artist edition. Also, you'll need to grab the shader node from the radiosity mapping thread I linked to above, if you plan on messing with the shader (or create your own later). I have a feeling that this will be implemented in a future shader pack to be released, because it's a pretty cool shader. I was surprised to see my question and little nudge (I'm Derjyn on the mm forums) returned some good results- those guys at mental mill are something else.

Anyhow, if you get this running in Ogre, I'd love to see how it turns out. And I'm a bit curious on the status of this! Great work Assaf, a very welcome addition to Ogre.

Radiosity Files

[edit]
Also, when exporting from mental mill to *.cgfx, are there any particular settings we should know of? I simply did "Custom CgFX", changed the VP/PS40 to 30, and I think that's all I changed. Does it matter if it's 3DSMax, custom, etc? I know coordinates will be different for the various packages, but aside from that I mean...
[/edit]

[Wretched_Wyx]

Any status updates? I'm busting at the seams in anticipation.

[Praetor]

Nothing new yet. Honestly, the more I played with FXComposer and especially mental mill I became quite underwhelmed. The support for CgFx loading is decent at this point. Fully supporting it is kind of difficult, because it just doesn't seem standard or stable enough. Naming conventions seem to be changing or not yet settled. The big problem I had with it is that for someone who regularly writes shaders (me) I can do everything FXComposer and Mental Mill does better and more efficiently just writing the raw code and testing in my own application as I go. Quite commonly I had to use SM3.0 to run shaders from Mental Mill that I could replicate quite easily in SM2.0.

However, for someone who does not regularly write shaders, I can see the usefulness of these tools. I think they are really great, and a good way to make realtime shaders more accessible. I would not say this feature is "dead" but I do have some other priorities right now. I'd say this will be an ongoing effort. CgFX files are complicated and so we'll just have to add support over time.

[Wretched_Wyx]

Understandable. It does seem more beneficial in the long run to have this feature grow, especially since the CgFX format seems to be doing the same.

But how usable is it in it's current state, with the SVN branch? I just pulled Ogre from SVN (trunk) and had a go at getting shaders to work. While the Ogre log reports that it's parsing the shaders, it doesn't return any visual results. At least not results like in those screens posted earlier in the thread.

Personally I'd be more efficient at prototyping shaders in mental mill then optimizing by hand, than writing raw shaders. But that's because my shader writing skills aren't so golden. I remember there was a tutorial for converting FX files to hlsl (I think) and Ogre material/program scripts- I'd be curious to see if this still works per the tutorial...

[Assaf Raman]

can you post the cgfx file you are trying to load and its textures? I may have a look.

[Wretched_Wyx]

Sure thing, here it is.

Another note, it's not just this shader I can't get working. No shaders work. Not from anywhere. I'm thinking I missed something...

What I did was:

1) Compiled Ogre SVN (Cthuga), with new Cg library/headers.
2) Made a basic ExampleApplication based demo.
3) New Cg DLLs are in the demo's folder, along with resources (shaders, models).
4) Setting material name on model like so: "mEntity->setMaterialName("shader.cgfx");"

That should be it right? I'm using the Direct3D9 renderer as well. No errors in the log, shader is seen and parsed/compiled. But the models show up with the default material... I also tried using the models you supplied earlier in the thread.

[Assaf Raman]

I had a look.
First of all your cgfx files didn't compile because of multiple errors.
Here is the error log.
here is the fixed cgfx code.
I fixed all the compile errors and run a sample in opengl with your material – here is what I see:


I don't know why you can't see anything. Try running in opengl – your cgfx uses an opengl profile.

[Wretched_Wyx]

Nice work there. I'm actually surprised you got that shader to work- I actually posted the wrong one! It was the same general shader but I had added some other stuff to it, and wasn't the one that I was testing with.

I'll have another go at this I suppose, and will definitely try using the fixed shader there. Didn't even realize that I had the profile set to OpenGL... but I'm glad it's likely to be something simple like that, rather than something obscure and hard to fix.

I'll be sure to start posting working shaders here that I create. That "radiosity" one is pretty nifty in my opinion... I'm eager to see how well it performs. Though I'm not sure it can really be classed as "radiosity". Maybe sort of pre-computed radiosity I suppose. I had planned to hook it into Caelum some how, for the sky and ambient color.

Anyhow, thanks again. Especially for the work you guys put into the CgFX loading.

[edit]
I modified the original shader I was working on- now it's just the radiosity and diffuse texture. You can find it here. I have this one setup for DirectX, so if you want to view using OpenGL, changed the bottom lines in the technique to read "vp30/fp30" instead of "vs_3_0/ps_3_0"".

How would I go about making the shader compile for both DirectX/OpenGL? Simply add another technique? I ask but I'll probably end up answering my own question by trial and error...

Also, any tips on how to get lights working? If I export a simple phong lighting (illumination_phong or component_phong) shader from mental mill, it doesn't work right.
[/edit]

[Praetor]

One thing I noticed is that when running in DirectX I had to manually change the order to the mul operations for the usual handedness issue. There should be an automatic way to know when to transpose matrices I think. Another thing I noticed is that textures are difficult to manage with CgFx. I'm sure tools like FXComposer allow the Cg runtime to auto-manage the texture units for them. This is something Ogre can't do. What happens is the order textures are declared and the order they are reported by the Cg runtime is not guaranteed. I wasn't able to find the pattern, if there is one. My suspicion at the time was that the order they were used within the shader determined the order they were reported, as opposed to the order they were declared. This caused a lot of headaches and manual editing to make them work.

[Wretched_Wyx]

There is definitely still some manual work involved. I figured out a couple of caveats worth mentioning (when using mental mill):

* Sometimes you have to edit the path to your textures. If you define a working texture folder in mental mill and you use a texture from there, the path shown in mental mill should simply read the texture name, ie "texture.dds", instead of the full path to the texture, ie "C:\textures\texture.dds". When it shows only the texture name, it will write the shader as such, and so long as the texture is in a location known to Ogre (ala resources.cfg for example) it works fine. Otherwise you have to edit the shader and delete the preceding path of the textures (ie modify "C:\textures\textures.dds" so it reads "texture.dds"). This caused me a headache until I figured it out.

* Light positions default to 0, 0, 0 when a shader is exported. Have to manually edit the shader to change the position.

* As Praetor stated, you have to edit shaders to do a transpose sometimes... changing "normal, position" to "position, normal" for example.

* When exporting from mental mill, I found most of my shaders didn't look quite right... changing the coordinate system to use "world" for the internal space seemed to fix this. The default is vertex coordinate space: object / internal space: camera.

* Changing the profiles in the export dialogue works fine. ie, setting vp30/fp30 for OpenGL, or vs_3_0/ps_3_0 for DirectX.

Hopefully those notes help someone save a little time. Now I got lights working (stupid oversight on my end), and so far every shader I could cook up worked. I still plan on sharing some, but I'd like to get a little demo rolling where you can select the shaders and release them with that. Right now my little "lab" is the ogre head, with the only input being the escape key to quit.

I think my last question here would be, how do we communicate with shaders? I mean via program/material scripts. A simple example with say, ambient light in Ogre affecting a color value in a shader would be enough to suffice, then I can figure out the rest. I've been toying with it, but can't seem to get it to work. You know what I mean right? Here is an example:

Code: Select all

fragment_program ambient_ps cgfx
{
	source ambient.cgfx
	entry_point main_ps
	profiles ps_2_0

	default_params
	{
		param_named_auto ambientColor ambient_light_colour
	}
}

Then obviously referencing the defined program in a material file... yeah, just can't seem to get it working. Any help/tips would be great!

[Praetor]

Right now you can't communicate with the CgFX system through material scripts. The CgFX file itself is directly parsed and programmatically turned into an Ogre material. There are no material scripts involved. Once the shader is loaded you can access it using the normal material/shader API as usual.

[Wretched_Wyx]

I see. Thanks for the info Praetor. Is there any chance you could give me a code snippet example of changing say, the position of a light from a CgFX shader? I'm reading over the Ogre manual/api docs, but a little example would go a long way for me.

So far, I'm really liking this. It's actually helped me learn a bit more about shader programming. I spent all day yesterday working on shaders, and was quite happy to find that even the most complex of shaders I could cook up in mental mill worked fine. There are still a few areas I haven't touched, or been able to quite figure out... but I did find some helpful info and resources for mental mill that can make your life easier when exporting for Ogre. For example, this MSL file is an alternative version of the "normal_make_normal" shader, that gives you more control over normal maps. The big thing with it, being able to flip the X/Y orientation of the normal map so they show up in Ogre correctly. I assume we need to flip the X right? That's what I've been doing and it looks correct. Just not sure if it's the same as hand editing and transposing the normal vectors that way...

I hope you guys make further progress here, or at least don't decided to drop it. It really does empower the artists out there to gain a little ground in this area of Ogre.

[Praetor]

The loader attempts to set up the light position as an auto parameter (ACT_LIGHT_POSITION or ACT_LIGHT_POSITION_OBJECT_SPACE). So, it should be linked to your scene's lights.