# arbitrary-sized vectors in hlsl?

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

## Recommended Posts

I've just begun implementing some lighting-models in hlsl, but i just can't figure out how to solve the arbitrary-sized light-vectors...
[source lang = "cpp"]
struct PointLight
{
float4 position;
float4 ambient, diffuse, specular;
float roloff, range;
float att0, att2, att4;
};

int iNumActivePointLights : PointLights;
PointLight MyArbitrarySizedArrayOfPointLights[???] : PointLight;


I sure could pre-allocate a constant max-available lights like this
[source lang = "cpp"]
PointLight MyArbitrarySizedArrayOfPointLights[255] : PointLight;


but that is not that wise, because the hlsl-compiler requires a whole lot of constant registers during the compilation and even though my app requires 1 active lightsource at the moment, i can't compile this with ps_1_1 target so my question is if there is any way to dynamically allocate arrays in a shader? edit: omg, the gibberish :)

##### Share on other sites
I dont think you either want nor need to do it this way.

Even on a decent SM3 part its unlikely you'll do more than 4-8 lights per pass. Thus keep the effect file simple and offload the calculations to the CPU.

If you write up shaders to do 4 lights per-pass but have 10 lights then just do:

Pass 1: lights 0,1,2,3
Pass 2: lights 4,5,6,7
Pass 3: lights 8,9,-,-

hth
Jack

##### Share on other sites
hmm... what do you mean with "offload the calculations to the CPU"? Some kind of pre-pipeline light combination or simply just exclude the lights that does none or little differential illumination? Or should I just find a good "Lights-per-pass" ratio?

##### Share on other sites
I dont mean offloading the actual lighting calculations to the CPU - just the management of them.

Unless you're doing dirt-cheap N•L lighting you'll probably want less than 10 active lights per scene/frame - otherwise performance will start to drop off.

So, if your game world is defined with 1000 lights... In the same stage where you examine what geometry to render (with whatever culling system you have) you determine which lights also affect that particular view. You can just select all lights (even if it is very high) or you can then re-order this subset and pick the N most influential lights.

When you've got your list of lights you can break it up into a number of passes according to the current hardware and available effects.

SM1 hardware will probably be limited to 1-per-pass, maybe 2-per-pass with SM2 and then upto 4-6 with SM3 (you get the advantages of flow-control). Thus you'll end up with a number of passes and a number of lights for each... so between each pass you update the lights (like I listed in my first post), CommitChanges() and then re-render the scene.

There are many other possibilities for this sort of work - it all depends how much effort you want to put into it [smile]

Bottom line though - the actual shaders (and FX framework) dont need to know about all the lights in the game-world - just the currently relevant/active ones.

hth
Jack

##### Share on other sites
No, just as I figured. I'll just begun in the funny end where I can write shaders, how and which lights are sent to the pipeline is the dirty and boring work. So instead of binding 8 lights on a per-technique basis, I'll bind 1-6 lights (depending on current hardware) och a per-pass basis. hmm.. that seems pretty logical.