"gl_VertexID" is not mapped to a semantic in shader definition


#1

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.


#2

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.


#3

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.


#4

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:

shader_err

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


#5

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.