GSoC Proposal Draft: Shaderland

[Loonride]

Hello,

Can I please get comments and reviews on my Shaderland proposal? Thanks in advance!

GSoC 2019 Proposal: Terasology

Kirill Nagaitsev GitHub: Loonride (https://github.com/Loonride) Terasology: Shaderland 9 April 2019 Project Summary This project will aim to make shaders more readable, break shaders into smaller components, and ultimately remove the complex system that involves compiling many permutations of a...

docs.google.com

 

[Cervator]

So I have read your proposal, and I recognized some of the words! ... that's probably about as far as I'll get hehe.

I can't weigh in on the technical details but your overall proposal format is outstanding. Everything seems to be covered very well and you've clearly put in some time and research. Well done!

 

[Loonride]

So I have read your proposal, and I recognized some of the words! ... that's probably about as far as I'll get hehe.

I can't weigh in on the technical details but your overall proposal format is outstanding. Everything seems to be covered very well and you've clearly put in some time and research. Well done!

Thanks for taking a look! I'm still not at the comfort level to write my own complex shaders, but I am at the point where I can tweak existing shaders and move around their logic. Over the next few weeks I'm planning to increase that comfort level by experimenting and doing more fixes!

 

[Loonride]

In response to vampcat's comments:

1. Is my #include shader proposal the optimal way to simplify shaders? The thought with that was we have this big function includes file https://github.com/MovingBlocks/Terasology/blob/dbfe54ea07bcecabe90a1fae5bdd67e1e0380b38/engine/src/main/resources/org/terasology/include/globalFunctionsFragIncl.glsl. I think it should be split into smaller files. Then shaders can just #include the small set of files with the functions they need. This is like the "selective include" mentioned here https://github.com/MovingBlocks/Terasology/issues/3251.

2. My idea for debugging is simply that the exact shader string thats being compiled should be outputted to some debug folder (I saw a function that already does something like that if some debug setting is on). The more we alter a shader beyond its source file, the more difficult it will be to debug it. Will the system I propose make it easy enough to debug, or should we prioritize debugging over atomicity?

3. As for the "multiple shaders in one node" idea, that was just my way of thinking to avoid dealing with dag too much, since someone else might be working on it. But it is easy enough to make new nodes and just chain them together, do you think that is the better way to go when I am testing smaller shaders?

 

[Michael]

1. This seems to be more of a problem with functionality rather then the need to just split stuff up. Looks like we just need to reorganize stuff to be in a more sensible location. That single file you linked has some trivial utility stuff and some things that are directly related to lighting. The shaders are a bit of a mess and I don't think just moving stuff around necessarily cleans up the problem. that's my 10cents on your include problem you mentioned.

 

[Loonride]

I agree, functionality definitely needs improvements in some spots, especially like the chunk shader program. There are also some places where just splitting stuff up could be enough though, such as parts of prePostComposite https://github.com/MovingBlocks/Terasology/blob/dbfe54ea07bcecabe90a1fae5bdd67e1e0380b38/engine/src/main/resources/assets/shaders/prePostComposite_frag.glsl. The file I provided is just an example of how "includes" are currently, but the idea of moving stuff into library function files definitely does not just apply to stuff there. The #include idea would come in handy more, for example, if you broke chunk into like opaqueChunk and reflectiveChunk shaders, then they might both find some use in having a getColor function to #include for example, where they can then pass in some values. They could even pass in some bools to make conditionals cleaner than the current way of using #define'd statements. That's where I'm thinking a way of bringing in dependencies could be handy, when two shaders are very similar but still serve different purposes.