TilesRenderer: Add shader "chaining" logic for adding and removing visualizations layers

[gkjohnson]

Right now "visualizations" are added via on before compile which makes it difficult to add multiple visualizations on top of eachother and clean up when a plugin is removed (see fade, topo, overlays, user shaders, etc). This also makes users or plugins replacing shaders more difficult to deal with since we don't know when they're added or removed. A built in chaining / material mixin registration system would allow this to work more cleanly.

tiles.registerMaterialLayer( {
  uniforms: {},
  defines: {},
  onBeforeCompile: () => {},
  customCacheKey: () => {},
  name: 'TOPO_MATERIAL_LAYER',
  order: 0,
} );

tiles.unregisterMaterialLayer( layer );

Node materials will likely also need a similar kind of mechanism.

[gkjohnson]

Implementation concept

// wrap the material with the given stack of effects
const stack = new LayerStack( [ ... ] );
const handler = new MaterialExtender( material, stack );

// allow for modification of the wrapped material
handler.setStack( ... );
handler.setDefine( ... );
handler.getUniforms( ... );
handler.needsUpdate = true;

// remove stack and reset the material
handler.dispose();

// initial class
export class MaterialLayerStack {

    constructor( layers = [] ) {

        this.layers = [ ...layers ];

    }

    add( info ) {

        this.layers.push( info );

    }

    delete( info ) {

        const index = this.layers.indexOf( info );
        if ( index !== - 1 ) {

            this.layers.splice( index, 1 );

        }

    }

    sort() {

        this.layers.sort( ( a, b ) => {

            return a.order - b.order;

        } );

    }

}

export class MaterialExtender {

    constructor( material, stack ) {

        if (
            material.onBeforeCompile !== Material.prototype.onBeforeCompile || 
            material.customProgramCacheKey !== Material.prototype.customProgramCacheKey
        ) {

            throw new Error();

        }

        this.stack = stack;
        this.material = material;
        this.uniforms = {};
        this.defines = {};

        // TODO: wrap the material callbacks

    }

    dispose() {

        material.onBeforeCompile = Material.prototype.onBeforeCompile;
        material.customProgramCacheKey = Material.prototype.customProgramCacheKey;

    }

}

[repalash]

Threepipe has a similar material extension system, you can have a look incase it might be useful to check as reference, its mostly standalone and provides helpers for different usecases - https://github.com/repalash/threepipe/blob/master/src/materials/MaterialExtension.ts and https://github.com/repalash/threepipe/blob/master/src/materials/MaterialExtender.ts

[gkjohnson]

cc @shotamatsuda - this issue is somewhat related to what we've discussed on twitter and #1287. The short of it is that I think it would be best to add a "TilesRenderer" function for registering a material "layer" callback which are sorted and responsible for modifying a material in-place to append the necessary functionality. The above concepts are made for ShaderMaterial and string snippets so it would need to be thought through for nodes - something like so:

tiles.registerMaterialLayer( {
  order: 0,
  name: 'TOPO_MATERIAL_LAYER',

  // TODO: what happens if a material is used across multiple tiles? Objects?
  processMaterial: ( material, object, tile ) => {
    // adjust the material
    material.colorNode = mix( material.colorNode, vec4( 1, 0, 0, 1 ), 0.5 );
    return material;
  },
} );

If you're interested in helping with any of this to any extent it would be great. Even feedback is helpful.