[OPTIMIZATION SUGGESTION]: Do heavy calculations on section planes in Vertex Shader instead of Fragment Shader

[tmarti]

The current way of doing section plane clips

This idea is related to a possible optimization about section planes' clipping in GLSL shaders.

Right now, on all xyzDrawShaderSource.js files, this scheme is used on every shader source (take for example https://github.com/xeokit/xeokit-sdk/blob/master/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js):

Step 1

The Vertex Shader (VS) creates 2 varying variables that will be used in the Fragment Shader (FS):

https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L68-L71

Step 2

The section planes uniform variables are loaded from the DrawRenderer into the FS:

https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L174-L182

Step 3

With the varying variables provided by the VS and the section planes uniform variables, the FS calculates, for each fragment, if the fragment world position is effectively clipped by the section plane and if that's the case, discard the fragment:

https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L185-L196

What this way of doing involves

This involves, for each fragment:

• loading 3 uniform variables for each section plane

  https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L178-L180

• interpolating 2 varying variables:

  https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L175-L176

• doing a float comparison + (clamp + dot product for each section plane) + float comparison:

  https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L186

  https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L191

  https://github.com/xeokit/xeokit-sdk/blob/7d2d9b37cb9a2096dc09d469e15c42176b0340a3/src/viewer/scene/PerformanceModel/lib/batching/draw/batchingDrawShaderSource.js#L194

The new idea for doing section plane clips

Currently...

• currently, each FS does some calculating related to clipping, and VS only provides the vFlags2 and vWorldPosition needed for those calculations...

• ... so the clip check math is done for every Fragment

... and the new idea is that...

• the VS could calculate the distance from each vertex to every section plane, providing ONLY a varying float vClipDist_i; variable to the FS, where:

  vClipDist_i = dot(-sectionPlaneDir" + i + ".xyz, worldPosition.xyz - sectionPlanePos" + i + ".xyz);

  (we don't want to clamp here, as we'll be linearly interpolating)

• it is safe that each of those distances is linearly interpolated with a varying variable because of linear relationship betweeen "fragment world positions" <=> "vertex world positions" and "fragment to clip plane distance" <=> "vertex to clip plane distance" distances to the clipping planes (think that the edge between 2 vertices is a straight line linearly weighted between vertices coords).

• the FS would then only load each varying float vClipDist_i and check if any of those is > 0, then discard the fragment

The result

The result with this idea is that the distances from section planes would be calculated in the VS, and interpolated on the FS.

This way we only calculate one distance (per section plane) per each vertex, instead of one distance (per section plane) per fragment.

@xeolabs, what do you think about it? 😀

[xeolabs]

@tmarti great idea - will definitely implement this soon.

[tmarti]

Super! I think the issue description provides enough information for a complete implementation 😃.

Right now just started vacation, but ping me if there is any problem with the implementation 👍