So, I’m trying to write a grass vertex shader using the StandardMaterial shader as a base and using shader chunks, but for some reason I can’t use the “gl_VertexID” variable which indicates what Vertex is currently being processed.
“gl_VertexID” is built in WebGL2 ES3, as seen here: https://www.khronos.org/files/webgl20-reference-guide.pdf
But for some reason I get this error when trying to use it:
“Vertex shader attribute “gl_VertexID” is not mapped to a semantic in shader definition.”
As if PlayCanvas thought that it’s actually an attribute when in fact it’s just a built-in variable…
Can anyone shed any light on this? I really need to use it to animate only the top vertices of a quad using a grass texture, it would allow for a cool sway animation.
Never really used that variable, but was curious if it was indeed implemented in GLSL3.0. And it is, here is a sample:
https://jsfiddle.net/highvrahos/2cukf1ra/
I imagine it should be working in PlayCanvas if you set your shader build target to GLSL 3.0.
#version 300 es
I would start with a custom shader to check compatibility if shader chunks seem to break.
When I tried it out with a custom Material the same happened.
And yeah, StandardMaterial uses #version 300 es. Same with the custom Material I made, but the same error happened.
So, I have created a public project where I’m testing out my custom shaders (decided to scrap the idea of using a StandardMaterial just for testing purposes), with a completely custom material and shader, and placing #version 300 es on top of both vert and frag shaders, it still crashes with that error:
In case anybody can help me out, I’ve been stuck in this issue and not able to use WebGL 2 shaders improvements for like a week already.
It’s like even thought I’m placing #version 300 es, the engine is still using the old version. Super weird.
Here’s the project: https://playcanvas.com/project/601311/overview/grass-project
Anyway, I worked around this by “simply” using WebGL 1 with a UV trick to identify which vertices to move around.
Would be nice to have access to builtin gl 3.0 variables thought.
1 Like
