Iâve been thinking about a âshader generatorâ some time now. Register it to the assetManager and then generate materials, matdefs and shaders dynamicallyâŚ
Itâs currently just a rough idea, gonna try a simple implementation when I have time and get the spirit
I think everyone who has made more than one shader and had to go back and add something to every one of them has probably thought about fixing this problem.
I, too, have designed a âshaderletâ system where you can write code snippets (fraglets and vertlets) and have them assembled into composite shaders with auto-wiring. Tweaking my existing shaders has still been quicker than writing a shader composition system and so I havenât done anything beyond a design. Done properly, the code chunks are still editable in existing GLSL editors because they are still 100% valid GLSL code on their own.
I keep telling myself âsomedayâ but motivation and time are at a premium right now. If my game income ever pays the bills then maybe.
Iâve been thinking about a âshader generatorâ some time now.
Me too... and did you planning writing some codes for a "shader generator"...
Here is my design for such system:
Concept:
+ Composing from Nodes (Input, Operator, Output) -> A graph tree-> Travel the graphTree and make a ParseTree
+ From ParseTree
> ToCode ( C++ syntax by a template system, my idea is using Veclocity or Groovy Template System_both good! )
> Some Node has Previews ( should using CPU Computing ... I thought )
UI:
+ Netbean Platform and VisualLibrary to visualize Node
Now I can produce some simple C++ code like:
Input NodeA named varA,
Input NodeB named varB ,
Operator AXB ,
Output = AxB => result=varA+varB ... which have a Veclocity template like this : result={varA}x{varB}
Anyway such system can become un-usable or un-efficient because the procedured code somehow not really easy to read and also a fixed uber-shader the result become!
@atomix. Hmm, Iâve been thinking along those lines.
I think a visual library would be nice, surely it would make shaders more accessible. Iâm not sure I would use It myself though since I canât sleep with badly written shadersâŚ
I once settled on building such a system, but failed since I did not find a way to generate code. Iâm no expert in either parsing nor language theory.
This is a bit like Unreals material editor
@pspeed I think your approach is valid. Writing small reusable shader fragments and then combine them, great! Actually atleast I dont mind writing GLSL at all so I like this one.
Setekh three people is usually smarter than one, so it might be a good idea.
I still think you guys have come more far than me in this âprocessâ so I might not be that helpful atm
@nehon said: @pspeed really we should do that once and for all!!
I, too, have designed a "shaderlet" system where you can write code snippets (fraglets and vertlets) and have them assembled into composite shaders with auto-wiring. Tweaking my existing shaders has still been quicker than writing a shader composition system and so I haven't done anything beyond a design. Done properly, the code chunks are still editable in existing GLSL editors because they are still 100% valid GLSL code on their own.
I keep telling myself "someday" but motivation and time are at a premium right now. If my game income ever pays the bills then maybe.
So true... I used RenderMonkey and NvidiaFX and find that too "easy" to compose a general shader. The point is as our engine heavily based in shader, and manual tweak in shader can also cause a bad Exception... That's why I want to make such things...
@zzuegg said:
The good thing is, something gets injected, the bad thing is, it gets injected in every shader used :(
Another bad thing is that for each shader âinjectedâ an additional render pass is performed.
Is it real that the "bad thing" can't be fixed, or else, we just waste our time... BIG ONE! :p
@atomix said:
Is it real that the "bad thing" can't be fixed, or else, we just waste our time... BIG ONE! :p
Without any runtime modification at the shaders code not, i assume this can't be fixed since only one shader/geometry/renderpass is processed.
Correct me if i am wrong, all i know about rendering i have from a 2 day experience in the jme source :D
A better approach would be to keep a list of injected shaders and generate the used shader automatically.
I am thinking of something like:
Nothing offensive but âŚthe approach sound a little bit ⌠crazy, how can jme, then lwjgl and opengl understand such shader code like that? and the two main function can confict eachother immediately, which is useless againâŚ
Some thing like :
[java]Shader1.frag
void main(){
//some shader stuff
gl_color = vec4(0,0,0,0);
}
Shader2.frag
void main(){
//some shader stuff
gl_color = vec4(1,1,1,1);
}
becomes:
UsedShader.frag
void Shader1_main(){
}
void Shader2_main(){
}
void main(){
Shader1_main();
Shader2_main();
// OK , produce only the last shader,
// We can tweak the code to understand passes, but somehow this approach leaves us too much manual things to do
The varying and attributes can be clearly identified (as they are declared with the attribute) and modified int both, the vert and the frag.
The problem staying are the uniforms, because they have to be synched with the material definitions.
An option would be to rewrite their names in the material loader so that they include a Material/Shadername.
Instead of adding the return value, we could easily introduce new helper varialbes. like, vec4 gl_FragColorTemp. Replacing all gl_FragColor=something with gl_FragColorTemp=something is easy. In the real main afterwards we could simply write gl_FragColor=gl_FragColorTmp;
I know that this is just the beginning of a more complex rewriting system. I wanted only to share the idea for discussion, if someone knows a argument why this would not work at all, i do not need to spend the time trying to implement it.
@kwando said:
We can't be the first ones encountering this problem. Maybe we should take a careful look at other engines to see how they solved it?
I'd just pay more attention to what pspeed said.
We don't need to over complicate ourselves with language translation that wont mean shader injection what so ever.. what we really need is an engine which loads the shader and it's code blocks (uniforms, if defs, etc) so we will be able to write inside the code block or replace/ remove it.
Take for example Java Assist: http://www.csg.ci.i.u-tokyo.ac.jp/~chiba/javassist/tutorial/tutorial.html
It's a kind of injector too, tho it inject's byte code.
Also jme3 is coded pretty, so adding new techniques defs and changing material defs isn't a problem what so ever >.> i bet we wont even need to change anything in the LwjglRenderer what so ever.
