Is your feature request related to a problem? Please describe.
Having to implement Custom Noise takes up a valuable colortex Channel, so it would be best to pack as much into a single tex as possible.

Describe the solution you'd like
I propose creating a custom noisetex that combines the random noise used currently in thel, a random perlin heightmap for smooth noise when that is required in the alpha channel and a 2 channel normal map of that noise to get faster normals (e.g. for wave genereation). using .r and .g for normals is the most common implementation so i would stick to that, put the heightmap into .b and the old Random.nextBytes into .a

Describe alternatives you've considered
If using a vec4 noisetex is impractical, the normalmap can be left out, and instead replaced with something like simplex or brownian noise, or a musgrave/voronoi texture as those have applications aswell.

Additional context
3 Channels of the same Noisetype is pretty redundant, as you could always just sample again at a shifted location instead of using a second channel. The performance difference can be neglected.

Why do you believe that this would be a superior approach to using a custom noise texture through texture.noise that has these properties?

These properties seem highly specialized to a given shader pack, so it makes more sense to me for a shader pack to create a texture with these properties through a custom noise texture, so that Iris doesn't need to worry about every possible specialized use case for the noise texture.

While indeed the user can choose to use a custom noise as the noisechannel, i just think that having 3 channels of the same noise as default is kinda redundant. and while obviously 3/4 channels of different noise arent gonna statisfy everyone, its an upgrade to the current implementation and offers the users some more choice. Having the noisetex generated at startup can save some loadtimes compared to uploading a .png i think. i understand that changing the noise gen could cause some problems with existing calls to the noise, but that could be circumvented with a flag to set to get the new noise.

It isn't redundant though, because it's often useful to have multiple random values at the same noise coordinate, without having to do weird precise coordinate offsets. Getting three completely random values at each pixel in the noise texture is a sensible default, in my opinion, and also makes sense given the need to have OF parity.

Adding another flag to control noise texture generation when there's already a more extensible way just doesn't make a ton of sense to me, especially considering the additional complexity associated with defining, documenting, implementing, and testing a new noise texture layout that is clearly tailored to a single shader pack or shader pack author rather than being more general. I get adding more choice, but there's already a mechanism for that that works more nicely and more clearly.

If loading a 128x128 PNG is contributing meaningfully to load times at all, then PNG loading should be optimized. Iris regenerates the default noise texture every time you reload the shader pack anyways, if you don't specify a custom one.

That being said, we could potentially provide standalone tools for generating custom texture PNGs and similar things with these kinds of properties, though thus far pack authors have generally written their own scripts in Python or similar languages.

OF Parity makes sense, but i dont understand why the offset needs to be precise. just adding 1 and or multiplying by 2 should be enough.

i agree with you that its likely not worth the hassle then because OF parity. a standalone tool would be cool :)