Calculating new normals in TSL shader

Questions
41

Hello again,

I’ve spent more time than I like to admit getting this process to work. It is now functional but with some quirks, resulting in a few new questions, of course! I’ll point these out as I get to them in the following explanation, which may be useful to others with similar requirements.

Huge thanks to everyone who posted suggestions above, particularly to @dubois for the exercise you posted which formed the basis of my exploration.

Here is a JSFiddle with the currently most evolved version.

It looks like this:

Screenshot from 2025-02-21 12-07-51
Screenshot from 2025-02-21 12-07-51937×512 82.1 KB

Yellow = shifted vertices, regular texture
Red = dataTexture + Normal calculation
Green = dataTexture only

To save you re-reading this whole thread, the process is as follows:

  1. Get an incoming map of heights for a ‘real world’ terrain
  2. Turn these values into a dataTexture
  3. With TSL, create a shader which can use the dataTexture to:
  • Update the Z-value of the vertices
  • Provide values to a Normals calculation

height_map->texture->shader->vertex process+normals calculation

Notes on the code.

  1. At line 148, within createDataTexture()
const texture = new THREE.DataTexture(
    data,
    curve_points,
    curve_points,
    THREE.RedFormat,
    THREE.FloatType,
  )

Question. This allows the incoming values to remain in Float32 format. But I read in some posts that the values will be ‘clamped’ between 0 and 1. Is this true? Is there a way around that, if so?

  1. At line 156 texture.flipY = true
    The texture image needed to be flipped so the redMaterial result matched the yellowMaterial. Yellow being the ‘traditional’ method of moving the actual vertices.

Question: No idea why this is necessary. Is there a reason for it? I found this quite late on, so it could be that I’m correcting something I’ve inadvertently done myself…

Hope this has been an interesting or useful read.

All the best
B