Hi,

I'm working on new asset importer (https://github.com/recp/assetkit) based on COLLADA specs, the question is not about COLLADA directly
also I'm working on a new renderer to render (https://github.com/recp/libgk) imported document.
In the future I'll spend more time on this renderer of course, currently rendering imported (implemented parts) is enough for me

assetkit imports COLLADA document (it will support glTF too),
importing scene, geometries, effects/materials, 2d textures and rendering them seems working

My actual confusion is about shaders. COLLADA has COMMON profile and GLSL... profiles,
GLSL profile provides shaders for effects so I don't need to wory about them just compile, link, group them before render

The problem occours in COMMON profile because I need to write shaders,
Actually I wrote them for basic matrials and another version for 2d texture

I would like to create multiple program but I am not sure how to split this this shader into smaller ones,

Basic material version (only colors):
https://github.com/recp/libgk/blob/master/src/default/shader/gk_default.frag

Texture version:
https://gist.github.com/recp/b0368c74c35d9d6912f524624bfbf5a3

I used subroutines to bind materials, actually I liked it,
In scene graph every node can have different program, and it switches between them if parentNode->program != node->program
(I'll do scene graph optimizations e.g.  view frustum culling, grouping shaders... later)

I'm going to implement transparency but I'm considering to create separate shaders,
because default shader is going to be branching hell

I can't generate shader for every node because I don't know how many node can be exist, there is no limit.
I don't know how to write a good uber-shader for different cases:

Here material struct:

struct Material {
  ColorOrTexture  emission;
  ColorOrTexture  ambient;
  ColorOrTexture  specular;
  ColorOrTexture  reflective;
  ColorOrTexture  transparent;
  ColorOrTexture  diffuse;
  float           shininess;
  float           reflectivEyety;
  float           transparency;
  float           indexOfRefraction;
};

ColorOrTexture could be color or 2d texture, if there would be single colorOrTex then I could split into two programs,
Also I'm going to implement transparency, I am not sure how many program that I needed

I'm considering to maintain a few default shaders for COMMON profile,
1-no-texture, 2-one of colorOrTexture contains texture, 3-........

Any advices in general or about how to optimize/split (if I need) these shaders which I provied as link?
What do you think the shaders I wrote, I would like to write them without branching if posible,
I hope I don't need to write 50+ or 100+ shaders, and 100+ default programs

PS: These default shaders should render any document, they are not specific, they are general purpose...
       I'm compiling and linking default shaders when app launched

Thanks

To split the bigger shader into smaller pieces I'm trying to create small shaders for specific purposes e.g. phong, phong with texture, blinn, lambert...
but I'm not sure how to separate lights from the phong shader because I don't want to add lights[MAX_LIGHTS] to every small shader and also phong requires light vector for phong equation  It would be more easy to render all lights together with separate pass (before or after material pass). This would save me to add light array to every shader

I would like to do something like this:

for each object
  prepare object to render (transform, culling...)

for each object
   render with object's material e.g. apply phong, texture
   render with all lights

any better idea or suggestions? 

Instead of sperating all lights, using one light per render pass will solve render logic,
because light is required in some effects e.g. phong, blinn... I'm going to implement this:

for each object
  prepare object to render (transform, culling...)

for each object
  for each light
     render object

light count will affect performance, but this will make things more clear and easy to maintain I think,

I still would like to hear another ways to handle lights (unknown count)