Sign in to follow this  

Simple Design question about fx file classes

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have the following question about designing material classes based on fx. files. Searching in the web I saw that a lot of people are coding each fx file into a class which handles variables, states and all the stuff of a material.This approach is not flexible but its fast .My real problem is in the management of an effect variables,I know that's much faster for the application to hardcode the variables meaning ex ID3D10EffectMatrixVariable* myMatrix=someEffect.GetVariableByName("varName") and using it from inside a class etc myInstance.myMatrix->SetMatrix() But this is approach is not good when you want to update the effect file with new variables therefore each time you have to update the code. The other approach is to get dynamic the variable each time you want to use it ex //inside render code someEffect.GetVariableByName('name')->AsMatrix()->SetMatrix(variable); but this is much slower since the interface searches and casts back a pointer every time you want to use it . A third approach would be to declare a map of type lets say map<std::string,ID3D10Effect*> and store the variables, although i haven't touch it but i consider it as a good idea. I would like to know which approach is more lets say more 'correct' leading to a robust design. cheers

Share this post


Link to post
Share on other sites
Not sure if i understand your problem. However I don't think it will be much of a problem because when you load the fx file, you would have known all the variables.

Even if in the later part of the development cycle, you decided to change the fx variables, upon loading this new fx files all variables are known and can be created in the 1st method you described. The parsing and creation of all variables is probably only done once per load, and it will be reused till the fx is not needed and get destroyed.

Hope this helps you

Share this post


Link to post
Share on other sites
Quote:
Original post by pcostasgr
...but this is much slower since the interface searches and casts back a pointer every time you want to use it.

Define "much slower". Obviously casts involve some overhead which is especially true for dynamic_cast on 64 bit systems. However, you won't notice its impact it all unless you are doing this thousands of times each frame.

If you worry about the runtime performance and backed up your fear by profiler results you could also build map in your effect class that caches all variables you have accessed so far. This lets you combine the dynamic approach with what you call the "hardcoded" approach. Upon changing an effect file you could then erase those parts of the map referring to this particular shader without changing anything else as this combined dynamic-caching approach would rebuild the map variable by variable upon first access of a particular variable.


Share this post


Link to post
Share on other sites
Thanks you both very much for the answer

first a small mistake when I mentioned map I wanted to say
map<std::string,ID3D10EffectValue*> but thats not important

second I dont thing that these calls are going to be thousands of times in each frame,therefore I ll proceed to the second solution although the idea of cached variables
looks interesting.I believe when it comes to scaling up the app the hardcoded solution will become very irritating if u costantly update your shader code.
Thanx again

Share this post


Link to post
Share on other sites
Yes I was also referring to your std map. I just suggested to go with the second version and combine it with your third version thus storing your variables in a map when you actually access them for the first time.

But then again, you would only need this kind of caching if you find the dynamic access to be a bottleneck of your application which I doubt would ever happen ;)

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this