.fx files in commercial games
Author
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?
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.
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.
Author
Thank you for your reply :)
Exactly what I think - it is really easy, even for artists, to create new materials and it is a very comfortable way.
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.
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.
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.
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:
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.
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 Entity4This 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.
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]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
