shader programs management

[robmar]

Thanks for the tip, if you know of any references making custom materials renders on Irrlicht, let me know. Thx

[Granyte]

i'm with the above currently in one of my current project i have to load one material per object because the shader has no way of gatering information dependent of the node currently rendered that mean i may have to load 100 of shaders per scene and if the user switch scene then ill get screwed

[robmar]

Can you not load all of the shaders on program init, then call OnSetConstants to initialise each shader as needed? If you´re using a shader per object, and customs settings per shader, how does the shader determine its variable set, as I´m not sure how a shader program can access external variables.

[Granyte]

Can you not load all of the shaders on program init, then call OnSetConstants to initialise each shader as needed? If you´re using a shader per object, and customs settings per shader, how does the shader determine its variable set, as I´m not sure how a shader program can access external variables.

the problem is that the current irrlicht shader call back class does not even handle having variable diferent per nodes( as far as i know) cause the onsetconstant is called for every node using the shader material on every frame and because it never know wich note it's rendering it may never know when to switch constant

[robmar]

yes, that´s how it seems to me, i´m no expert on shader programming, maybe someoen can comment here who knows shaders in depth.

[hendu]

In my LPP demo, since I render each light myself instead of the scene manager, I know exactly what data to get in onsetconstants.

[robmar]

the question is how can you seyup a shader program that is able to know which node it is shading, and access a table of data relevant to each node? you can pass in to the shader a user variable, could that be used to identify the node at run-time, allowing the shader program to switch data for each node, allowing one shader program to handle multiple rendering configurations?

[hendu]

I'm lazy and just used a file-scope pointer.

Code: Select all

static light *lights; //file-scope global ptr
...
virtual void OnSetConstants(IMaterialRendererServices* srv, s32) {
        float col[3] = {lights[curlight].col.getRed() / 255.0,
...
for (i = 0; i < lightcount; i++) { // one of the render passes
        curlight = i;
...
        lights[i].node->render();
 

Hope that clears it up.

[Otaka]

I also didn't find official way to remove compiled shaders, that is why I have following workaround, and it seems it work good:

Code: Select all

 
//add shader
s32 newMaterialType = gpu->addHighLevelShaderMaterialFromFiles(
                vsFileName, "vertexMain", video::EVST_VS_1_1,
                psFileName, "pixelMain", video::EPST_PS_1_1,
                callback, video::EMT_SOLID, 0, video::EGSL_CG);
...
//remove shader
IMaterialRenderer*renderer=driver->getMaterialRenderer(newMaterialType);
renderer->drop();
 

Destructor of the renderer will unload shader from GPU.
Than I made several changes in engine sources, because irrlicht tries to remove all renderers again before shutdown.

[mongoose7]

You've dropped the renderer but retained the material? Wouldn't the correct approach be to drop the material?

[Otaka]

When I debug creating of shader I saw only creation of the new IMaterialRenderer, not material(we add it to our material later, as material type). And Material does not free renderers in destructor. That is why there is no sense to drop material in order to unload shader.
Please correct me if I am wrong.

[devsh]

GUYS GUYS

listen, this is not a problem

You can have F-tons of shaders compiled, OpenGL caches them in driver space .. the programs are less than a few kB


THE REAL PROBLEM... IS THE IRRLICHT INEFFICIENCY

of dealing with them every frame, for example, setting uniforms/constants

right now irrlicht generates a list of name<->registerID key pairs and linearly searches through them each time you do services->setPixelShaderConstant()

I usually have 20 different uniforms, so thats 400 comparisons in the worst case (200 on average as I set the constants in the same order they appear in code).

A similar problem occured in the Hardware Occlusion Queries, after removing the searching (storing occlusion query IDs inside the nodes) the framerate went up from 90 to 120 !!!

[hendu]

devsh, you're behind the times again

Trunk does a table lookup for uniforms. There is no search.

The occlusion queries still do a search in trunk, though.

[Granyte]

I think devsh forked at 1.6 or something

[devsh]

1.8 actually, we merged our 1.7.2 fork