Jump to content
  • Advertisement
Sign in to follow this  
Endurion

OpenGL Shader management with lights

This topic is 2926 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

Hi,

I'm rather new with shaders (I've just managed to get my first shader to compile and work in a game). I however have a neat abstracted library under my belt that for now works with the good old fixed function pipeline.

The library abstracts the renderers in DLLs and thus allows me to exchange DX8, DX9 or OpenGL renderer. The display states are set indirectly, I provide a method SetShader with enum for example render flat (texture modulates with vertex color), render with flat with alpha test, etc. This seems to fit quite nicely with real shaders.

However a nuisance comes with lights. For fixed function I have my 8 lights which I simply enable/disable. Due to abstracting I want to have it working without D3DX. I chose HLSL with precompiled shaders. But how should I approach lights?

As it looks I'd have to compile every shader in at least 8 variantes for every light. That feels cumbersome. Is that really the way to go?

Share this post


Link to post
Share on other sites
Advertisement
Very interesting question indeed, I'd also be interested in knowing more.
In the past, I had some success by setting up internal system-specific conventions ("the engine_lights array contains the lights to evaluate, it counts engine_active_lights entries). Unfortunately, I rapidly went mad at managing the different light used (directional, omni, spot, shadowcasting y/n, projective y/n).
I have then tried various approaches but so far I failed in finding a satisfying generic solution. My best bet is that one should start from final product's requirements and very likely deal with the problem at different levels.
Deferred shading sounds very interesting to this regard but I am still not sold on it.

Share this post


Link to post
Share on other sites
Quote:
Original post by Endurion
As it looks I'd have to compile every shader in at least 8 variantes for every light. That feels cumbersome. Is that really the way to go?
On the last game I worked on, the main shader file was compiled into ~200 different versions (depending on which options were required).
This is sometimes called the "shader permutation problem", and there's no simple answer.

Other approaches include dynamic branching in the shader, or simply always computing 8 lights in the shader (and setting black-coloured lights when you want to disable them).

Share this post


Link to post
Share on other sites
Hmm, I feared as much.

Well, as it seems I'm only using 2 or 3 lights max that might be the way to go then. Thank god I probably won't ever come near a plethora of 200 variations ;)

Thanks for your input guys/gals!

Share this post


Link to post
Share on other sites
Why have you got a boner over D3DX to compile them?

Our engine uses an effect enum for the core material and then makes its own combos of lighting, bump-mapping, shadows etc from a set of flags. To do this the combos are stored in an array indexed by the flags and if that array is empty the handling code goes and constructs a shader (by using strcat to physically write one) for the job.

I have to say that we've tried a number of times to find a way to get us nice effects without needing users to write millions of shaders whilst also having the engine work on something more limited like the Wii/PSP/etc. And this is the first design that ticked all the boxes and felt just right.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!