Change in vertices UV not respected by material shader

Questions
1

I’ve tried to follow the docs to set the UV of a meshes vertices. I suspect it is a problem with the material / shader I have constructed but I can’t see the problem at the moment. I’d be very grateful if anyone could take a quick look. Thank you!

The plane should appear as all red as I have attempted to set the UV values to 0 but it appears as blue-white-red

https://playground.babylonjs.com/#ZKPX1P#9

** edit **

  1. I have experimented with manually connecting the shader to a inputBlock of value 0 in NME and in the code and it works as expected (i.e. the plane is all red).
  2. I have logged out all the uv values of the mesh and they are all 0.

So for some reason the material is receiving the original uv values of the mesh instead of the updated values…

2

Hey

here is your fix: Data on height map | Babylon.js Playground

:slight_smile:

2 Likes
3

Amazing! Thank you so much @Deltakosh . I missed the crucial / 3 in the example and thought it was returning a list of position vectors instead of single numbers.

I doubt I’ll ever get to contribute this but would a PR for a warning if you assign too much / too little data be useful? Though perhaps there are legitimate use cases for this kind-of-shadowing-the-data approach? i.e. the data is there in javascript/typescript but is silently ignored by the shader / material.

1 Like
4

There is actually a warning in the console :slight_smile:

1 Like
5

Ahh the WebGL: INVALID_VALUE: bufferSubData: buffer overflow… nice! I’d seen the other warnings about DevTools failed to load SourceMap and I guess I must have tuned out the rest. My bad.

I noticed there is not a similar warning for underflows which also result in a no-op. Is that intentional / hard / undesirable to warn about or would a PR be welcomed there? Thanks.

6

it is “expected” :slight_smile:
We avoid any check on the main rendering loop (for perf reasons)

1 Like