As a side note, I still think you're over-abstracting a bit.
Do you have a genuine need to define a separate class for rendering techniques?
In all the engines I've worked with (including my own), the best approach has turned out to be that both the effect handle (ID3D10Effect*) and the technique handle (ID3D10EffectTechnique*) are stored directly as a member of renderable object interface (or base class), and the concrete object classes store the effect variable handles that they need. The objects then update only those effect variables that they use, no more, no less.
The point being, D3D already seems to introduce a sufficient level of abstraction for most applications in this regard.
"Dynamic" effect files
The problem i am seeing with archtypes for your techniques/effects/shaders is that you lose the ability to add them without changing the rendering code. So for each new techniques/effects/shaders you need to add a new archtype if it's not known to the engine yet.
Why not describe the parameters you use in another file and write a generic way of setting variables into the device. Yes this would require a switch for each shader variable type, but an interger compare is fast. And its code you only write once.
This gives you the abillity to add techniques/effects/shaders on the fly without changing the code base.
Or am I misunderstading the issue you are having?
Why not describe the parameters you use in another file and write a generic way of setting variables into the device. Yes this would require a switch for each shader variable type, but an interger compare is fast. And its code you only write once.
This gives you the abillity to add techniques/effects/shaders on the fly without changing the code base.
Or am I misunderstading the issue you are having?
Quote:Original post by NightCreature83
This gives you the abillity to add techniques/effects/shaders on the fly without changing the code base.
But the question is, is that ability so important that you spend a considerable time to implement it, and lose runtime performance as a result anyway? In most projects I've seen - small, medium and large - the answer is unequivocally "no".
It can be done by inspecting the variables and their types at runtime, but this will result in switch statements and lookups by strings, which (I assume) the OP actually wanted to avoid.
Author
Quote:Original post by Nik02 but this will result in switch statements and lookups by strings, which (I assume) the OP actually wanted to avoid.
Exactly. All of you guys are right. The drawback of writing one Technique-Archetype for every technique "class" is obvious. For every new Technique (or if an existing technique needs a new shader constant) I have to change my host code and in the end it spams my source folder.
I also don't want to use "dynamic" structures like a map or switch statements for something that is actually pure static. At runtime I know how the shader looks and the objects know which shader constants there have to set.
Thus I will do it like Nik02 proposed. I will just use the DirectX effect and technique class and directly add the effect variables (ID3D10EffectXYZVariable) to my objects. The reason why I initially wanted to introduce an additional layer of abstraction: I looked at some engines (ogre, irrlicht) and they all had some kind of Material/Shader classes. So I thought its a good idea to provide such classes. But since the effect framework of Direct already delivers a nice form of abstraction I will just use them without something on top of that:)
The reason why Ogre and similar engines use further abstraction is that they can potentially render with other systems than D3D.
However, if your abstraction classes are tied to D3D anyway, the additional layer is somewhat unnecessary.
Even when you only use D3D, it still probably is a good idea to encapsulate material-specific variables to their own class or structure, but not for abstraction or for direct interaction with Effects - rather, for storage convenience.
However, if your abstraction classes are tied to D3D anyway, the additional layer is somewhat unnecessary.
Even when you only use D3D, it still probably is a good idea to encapsulate material-specific variables to their own class or structure, but not for abstraction or for direct interaction with Effects - rather, for storage convenience.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
