Extensible structs as shader pre-preprocessor directive

I am writing a pre-preprocessor directive for our shader loader that would add to the two we have already ( #import and #for ) and i’d like to hear your opinions on it.

The purpose is to create a struct that is based on another struct but adds some fields, you can see it as a very limited class extends.

The implementation is a as follow:

#struct MyStruct1
    float a;
    float b;
#endstruct

#struct MyStruct2 
   float c;
#endstruct

#struct MyStruct3 extends MyStruct1, MyStruct2
   float d;
#endstruct

The jme shader loader will translate it to:

#define STRUCT_MyStruct1 \
    float a;             \
    float b;

struct MyStruct1 {
    STRUCT_MyStruct1
};

#define STRUCT_MyStruct2 \
    float c;              

struct MyStruct2 {
    STRUCT_MyStruct2
};

#define STRUCT_MyStruct3      \
    STRUCT_MyStruct1               \
    STRUCT_MyStruct2               \
    float d;

struct MyStruct3 {
    STRUCT_MyStruct3
};

And then the glsl preprocessor will do the rest.

The end result is that you will have a MyStruct3 that has all the fields of MyStruct1 and MyStruct2.

Usage example

#struct MyStruct1
    float a;
    float b;
#endstruct

#struct MyStruct2 
   float c;
#endstruct

#struct MyStruct3 extends MyStruct1, MyStruct2
   float d;
#endstruct

void main(){
  MyStruct3 s;
  s.a=1.;
  s.b=1.;
  s.c=1.;
  s.d=1.;
}

The goal is to use it for a struct based implementation of #2191 to allow shaders to extend and redefine the default base structs if they need to store more data.

6 Likes

This sounds like a good idea to me. And using a struct like this for refactoring things in #2191 should be better than in/outting every parameter the way I was initially doing it.

1 Like