Extension for Procedural textures

Investigating interest in an extension for procedural textures - IKEA_procedural_images

The purpose of this extension is to enable procedurally generated images that can be used as texture references.
The proposed solution will offer the possibility of generating textures at load time by defining new texture sources and a way of describing image generation from a set of image parameters.
One goal of this is to reduce transmission size, another goal is to be able to offer dynamic output depending - for instance altering the exact look of a wood texture at loadtime.

The initial proof of concept was to verify if the quality of procedurally generated wood textures is good enough - we are convinced that we achieved this.
The goal of this extension is to provide a generic enough descriptive syntax that other types of textures can be created.

It is NOT to create a flexible material graph, neither is forcing implementations to do texture generation in shaders (on the fly).
This shall certainly be possible, however it is not the goal for the first iteration.
Think of it as taking a subset of a procedural graph and then locking the operations so that implementations are simpler.

## Overview

* The procedural image specification will define a set of operations to be carried out in order to produce texture source images.
You may see this as a compiled (or locked) subpart of a material nodegraph.
* The produced source images may contain basecolor, normal, roughness and possibly occlusion.
It is estimated that metalness is not needed since the procedural specification targets one material - but this is somewhat undecided.
* The default behavior is that the textures are generated at load-time and sampled as any 'normal' texture source.
It is up to implementations to dynamically generate the textures, for instance in the fragment shader, however this behavior is not mandated nor is it the goal of this first iteration of the extension.

## Way forward

* Define a list of graphical operators (add, mul, noise, stretch etc) needed to generate procedural images.
* Define a list of known materials we believe can be represented using these operators.
* Define a list of DCC tools / material systems that are or may be compatible with this definition.
* Supply a detailed list of the operator declaration - what the inputs are and what the expected output is.
* Supply some sort of test framework for implementers to validate the implementation of operators.

## 1: Texture reference
For a procedurally generated texture to be able to be used as a source it must be possible to reference it.
This can be done on an image level, where the procedural file is referenced.
The following will add two procedurally generated textures as source, generating the basecolor and normal when the image is loaded.
A fallback is specified, however this is probably not wanted.

"textures": [
{
"source": 0,
},
{
"source": 1,
}
]

"images": [
{
"uri": "fallback_wood_basecolor.png",
"mimeType": "image/png",
"extensions": {
"IKEA_images_procedural_wood",
"uri": "ikea_wood.ipw",
"target": "basecolor"
}
},
{
"uri": "fallback_wood_normal.png"
"mimeType": "image/png",
"extensions": {
"IKEA_images_procedural_wood",
"uri": "ikea_wood.ipw",
"target": "normal"
}
}
]

## Procedural generator
This part will specify some sort of declarative syntax for understanding the data provided to the generator.
Input will be one or more datasets - output is the generated image (for each of the texture maps)
It shall be (resonably) easy to implement, provide sufficient performance for real world load time usage and be able to guarantee that the visual output is the same.
It shall be possible to output different target maps such as color, normal, roughness etc.

The procedurally generated image is specified in the images array using the extension, it is recommended to require this extension or only provide a very basic image fallback (otherwise the whole purpose of reducing transmission size is lost)

Sourcecode (C99) and wasm will be provided for the generator, reducing the implementation overhead.

One part of this project will be to define the (graphic) operators that are needed to create the procedural textures.
Another important part will be to create a test and verification suite so that implementers know that they are getting the textures right.

Begin with the issue's Way forward and Procedural generator sections; no implementation files or entry points are named. Define the required operators, material coverage, operator declarations, and implementer test framework, with C99 and wasm generator sources considered; the work is done when the extension specification and verification approach are sufficiently defined.

Written by the indexing model from the issue text.