How to get Support for Geometry Shaders?

I have to complety agree here on both,

telling others what to do is time consuming, but without it there is absolutely no way they can just guess the perfect way.
And I also find it usually a little difficult to get feedbacks for pull requests, that is actually meaningful.

I am also unsure how the tess+geo shader support relates to shader nodes in this case. The geo+tess patch was made long before shader nodes even existed, i adapted the patch a few times the the changes.

Beside that, (but i have to say i spendet very limited time investigating this) i am not sure why the shader nodes system has to be so integrated into the core. Not sure if possible but would it be possible to resolve all the required stuff in an asset loader? It would also clean up and simplify the core code…

Just throwing ideas in…

It is OK not to support shader nodes. The entire purpose of those patches would be experimentation anyway, since nothing in the engine would use them.
If we get a PR adding geometry + tessellation shader support with relevant tests I will merge it, even if shader nodes are not supported.

Also I guess we could allow usage of full blown shaders inside a Shader nodes defined technique, with minimal adaptation.
So you could have vertex and fragment shaders built with the shader node system and have a classic shader for tesselation shader.

What should the tests cover?
Just some tests to validate each shader stage works, or a bit more meaningful usecases?

@nehon: sounds good, the biggest problem in my head is how varyings should be managed.

With a hack.
In any shader node you can declare a varying, just before the main() function.
They’ll be declared before the main() function of the generated shader.
But since the generator won’t handle them, you’ll have to be careful of name collision.

Maybe show an example of something that isn’t possible normally without geometry / tessellation shaders. With a pass-through shader it is a little difficult to tell that anything is going on.

Hm a cool testcase would be the cobbestone example we have in parralax, but with tesselation instead.
Maybee in a compare view where you see one with parallax and one with tesselation next to each other.

Use tesselation to generate more vertices, and then use the heightmap of parralax for displacement mapping.


Indeed, a very good example.

Before i start writing the required changes, in what direction should i go?
Adding only relevant lines, or also cleaning up the stuff a bit?

For example, how the ShaderSource is stored currently. I probably have the option to choose:

String vertexShaderSource,fragmentShaderSource,geometryShaderSource,tessControlShaderSource,tessEvaluationShaderSource;

Second does probably require more existing code to be changed but might end up the cleaner solution.
So what would be preferred by you?

The latter seems better. However the main place where this change would be significant is the ShaderKey which is used to lookup the shader in the asset cache.

I have modified the whole shader system to use the EnumMaps, and i got all tests working (Beside the one shader node test). Also i have verified that geometry shaders works as expected. I will write more in depth tests tomorrow.

Whats still on the list:

*Fixing the shader node interop code
*Fixing a few .toStrings as well as .hashCode in ShaderKey
*Adding the remaining javadocs
*Writing tests