Skip to main content
GameDev.net gamedev.net
🔒 Locked

Yet Another Shader Implementation Thread

Started by Hamster Oct 4, 2005 at 3:55 PM 3 replies 3.7k views
Original Post
Hamster
Hamster
Hello, In the work on my latest project I've now come to the point of having to implement the rendering system. I've read the "Material and Shaders Implementation" thread, and many of its descendents and was just hoping that people more experienced than myself could clarify something for me. What, specifically, are the advantages of a plugabble DLL based system over the functionality that is provided by DirectX's Effect file system? I had originally started on making a modified version of the pluggable DLL system in the hope that a pre-pass over items within the renderqueue would spawn the additional passes and renders to other targets required for the scene (for say, dynamic cubemapping, or post-processing frame buffer effects). Some magic algorithm (as yet unwritten) would then sort out the order in which everything had to be done on the current hardware. I'm not sure this would be realistically practicable in realtime. At this point, the attraction of the dll system was that shader dlls could query the engine for the information they needed, requesting, for example, the rendering of the 6 frusta full of additional renderables probably outside of the current view volume in the case of dynamic cube mapping. It's becoming apparent though that exposing this sort of functionality to a DLL isn't a million miles away from supplying the data to an FX file based solution having parsed the need for it in some sort of custom template. It therefore seems like less work to use the FX solution. Some part of my brain though is still set on the idea that the DLL based version is the one to go for, although I can't at the minute suggest why. I've learned to my cost, however, that these little instincts (I know there's a less pretentious word, but can't think of it right now) can sometimes be correct, so I just wanted to throw the problem open to the input of people who might be more experienced with either solution. Thank you very much for any help you can give, John
mrbastard
mrbastard
I went for the middle path, and it seems to be working well. I have multiple renderpaths that can be switched at runtime. They're just libs, not dlls (won't need them to be until release, so maybe never) and are quite simple. At the moment I just have generic renderpaths for different eras of hardware, all of which (well, OK... some of which) can render any materials/shaders set up in an fx style xml file. If I need to do something that can't be done in the generic renderpaths, I write a new specialised one for that effect.

This means I get the ease of the fx approach but the flexibility of the dll approach. It's perhaps not the cleanest design, but it keeps my options open as I continue learning. In truth it's quite scruffy and unfinished, but it points out that when designing a renderer you don't nessesarily have to pick from 2 extremes.
[size="1"]
Jason Z
Jason Z
I actually use a hybrid method as well. I use the fx files for managing the vs & ps as well as setting the needed shader parameters, and I use a "CRenderView" class interface for the different rendering scenarios.

So the subclasses of a render view would be something like a Planar Reflection View, a Shadow Map View, a Depth Only View - things like that. So the low level details are handled in the fx file, and the broad semantics are handled by the render view classes.

It seems to work pretty well - the only thing is that it is slightly harder to sort effect files by renderstate changes, but I haven't run into any real performance issues due to this. I sort by shader, then texture and everything is humming along at 150-200 fps on GF3 hardware (only on my test game, but still a good enough test).
Jason Zink :: DirectX MVP   Direct3D 11 engine on CodePlex: Hieroglyph 3 Direct3D Books: 
Hamster
Hamster
Right, thanks very much for the suggestions guys. I might see how far I can get with fx files. It seems a shame to have to implement something hybrid given the fact that creating fx in RenderMonkey is so easy, but I'll step up a gear into a hybrid fx/DLL version if I have to. Thanks again.
Zemedelec
Zemedelec
Quote:
Original post by Hamster
Right, thanks very much for the suggestions guys. I might see how far I can get with fx files. It seems a shame to have to implement something hybrid given the fact that creating fx in RenderMonkey is so easy, but I'll step up a gear into a hybrid fx/DLL version if I have to. Thanks again.


But FX files are just a layer above render states, and as far as I can tell, the managing layer above them is more important to get right - parameter management, exposure shading to artists, adapting shading to different lighting scenarions without rewriting shaders again and again...

But that very depends on what you want... For example - do you want to create object parameters in data-driven way, and bind them to shaders..? If you need it, you goes one way, if you don't - another. And have almost nothing to do with FX files themselves imho.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.