# .fx files in commercial games

This topic is 4620 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello! I'm currently designing my new engine and I thought of using only .fx files for the implementation of the material system. So, the .fx files should also be used for switching render states and not just for shaders, this would be a very simple implementation and would allow easy modification for the artists - but what about the performance? I thought of writing a parser that analyzes the .fx file and determines which states are set, so it would be possible to sort the objects before rendering to minimize the number of state switches. I think the method would work, but it is not trivial to implement and I just wanted to hear a few comments about the idea before implementing it. Or is there a simpler method to integrate .fx files in an efficient way?

##### Share on other sites
Hi,

I'm currently going that way and implementing shaders and materials directly in .fx files. I've found that once I've set up some generic semantic bindings to the engine (WORLDTRANSFORM, etc.), annotations (e.g. fallback to a different .fx file, exposing artist variables), and preprocessor defines (e.g. how many vertex blend weights there are), it all fits together pretty damn nicely (and it makes it so easy to add new materials).

As for state switching, well I havn't started done any benchmarks yet and I'm just letting the FX framework to handle state changes (I'm even letting it reset the states back after rendering), and it's still rendering pretty fast.

I don't have much to add on the state tracking, since I still need to do some research on that. Writing your own parser seems a bit overkill, and no to mention tricky to get right (and to match the DirectX implementation, esp. when new versions come out). If anyone else has anything to say about this state tracking stuff, I'm also interested to hear.

But all in all, I heartily recommend FX files :D.

##### Share on other sites

Quote:
 it all fits together pretty damn nicely (and it makes it so easy to add new materials).

Exactly what I think - it is really easy, even for artists, to create new materials and it is a very comfortable way.

Quote:
 As for state switching, well I havn't started done any benchmarks yet and I'm just letting the FX framework to handle state changes (I'm even letting it reset the states back after rendering), and it's still rendering pretty fast.

I think the FX framework is pretty good optimized and as far as I know, the rest will only be performed when it is necessary to render the next primitives. But nevertheless it would be possible to improve performance by rendering objects in the correct order with minimal switches... but maybe it is better to sort the geometry approximative by distance to minimize fillrate problems instead of state switches, I have never tested this, but I think fillrate is more important than state switches.

Quote:
 Writing your own parser seems a bit overkill, and no to mention tricky to get right (and to match the DirectX implementation, esp. when new versions come out).

Yes, I'm sure you are right... it was just an idea to minimize the switches and in fact, I have no better idea to do this. The parser does not need to analyze everything perfectly, i.e. shaders can be completely ignored, it should be enough to analyze state switches... nevertheless, it is definitly much work and I don't know if it is worth the time to implement it.

##### Share on other sites
It is important to keep your state changes organized so that you can minimize the number of changes you can actually make. State changes, like SetRenderState(), SetStreamSource, SetVertexShader() ect... are suprisingly performance-instensive. Check out this KBase article - it lists the most expensive D3D function calls.

I recommend organizing your visible objects in a tree, based on a material. Basically, a material is the set of shaders, set of textures, and set of constants. Like this:
                     Shader1                            Shader2               |--------|--------|                 |--------|--------|           TextureSet1      TextureSet2       TextureSet3        TextureSet4       |--------|--------|      ...               ...               ...   ConstantSet1      ConstantSet2       |                 |     Entity1          Entity5     Entity2          Entity6     Entity3     Entity4

This way, you only need to change the states that actually need changing. This saves a lot, since D3D does not perform redundancy checking. Of course, if you have states being set in the effect itself, these will bypass the application-side tree. However, these effect states will only be set when the effect is enabled, so it will still be okay.

##### Share on other sites
I was just looking at the D3D docs, and found the documentation for ID3DXEffectStateManager. I'd seen it in passing before but never really paid any attention, but I think it could be used to help minimizing state changes.

I think using that interface and simply sorting according to effect is the best bet. Anyway, I'll be doing experiments some time in the (hopefully near) future. [smile]