Random method from CTM incompatible with natural textures

[Builderb0y]

Obviously randomized rotations aren't particularly desired when using "normal" CTM methods, but for the random method (and probably fixed as well) it can be quite useful.

In this example RP, CTM provides 5 random textures for diamond blocks, and natural textures is configured to rotate and flip them randomly. However, all of them have the same rotation when placed.

[Filmjolk]

try to use models for random and fixed. Either use the models to apply the textures or use blockstates to create the natural textures effect.

[Builderb0y]

There are 8 possible orientations per face with 4F natural textures, which means 8^6 = 262144 models per block if I use models to apply a natural textures effect and use CTM to provide random textures for each face. Alternatively if I use models to provide the textures, and natural textures to rotate/flip them, then that means (number of textures) ^ 6 models instead, which could potentially be even worse if I use more than 8 textures. Given that random textures and natural textures are already built-in to optifine, I would expect them to be compatible with each other from the start.

[Filmjolk]

no, I don't see why it's important to have a different orientation on the same block and you can just make the random orientations with blockstates flip rotate etc just like vanilla minecraft does. This can all be batch processed really fast.

[Builderb0y]

That might work, as the multipart system can also apparently specify random models/rotations. This would allow me to have 2 model files per face (one of which is flipped), then specify 4 rotations for each of them in the blockstates file. This would effectively create 8 variations per face, one of which would be selected at random when actually rendering. This would only require a maximum of 12 model files per block, which is a massive improvement over the 262,144 models mentioned earlier. The problem with this system starts when you have an asymmetric block, or one which has multiple elements (stairs being a good example, as they even have connection rules too). A lot more models would be required for blocks like these.

I wouldn't mind doing it this way if necessary, but unless there's some super complicated internal reason why they can't work together without massive code re-writes or something, then I still think it's worth fixing on optifine's end, simply because it's so much more convenient to just type one line of text into natural.properties than it is to deal with models/blockstates.