1.15 Model rotation messes with UVs

[Muramasa]

So I'm having trouble baking a model with a rotation matrix. I am trying to create an IModelTransform given an array of Direction as shown here: https://pastebin.com/MjzAHeK9 However while the vertex data seems to be correctly rotated, the uvs are all wrong. I'm really not sure what I could be doing wrong as shown here: https://i.imgur.com/z6dcXBb.png

Edited March 19, 2020 by Muramasa
unsolved

[TheGreyGhost]

Howdy

 

Although I'm not sure exactly what you're trying to do, you might get some useful clues looking at IModelTransform.isUvLock and FaceBakery.

 

-TGG

[Muramasa]

I am trying to implement pipes. I have a model for every unique "shape", and when baking each of those shapes, I'm adding every rotation combination needed to a master map to return in my baked model. Even just rotation some shapes by 90 degrees messes with the UVs totally.

[Alpvax]

Use a multipart model/blockstate is the easiest way to do it:

https://minecraft.gamepedia.com/Model#Block_states

 

Look at how the fence blockstate is defined (client-extra.jar) for an example, and just rotate about the other axis for up/down.

That way you only need a couple of models for all permutations, and don't need a custom baked model.

See mine (wire, has multiple states for each side so is somewhat complicated, but you can just look at the basic structure):

Blockstate file:

https://github.com/Alpvax/AdvancedAutocrafting/blob/1.15/src/generated/resources/assets/advancedautocrafting/blockstates/wire.json

One of the model files (wire_arm is currently just base_wire_arm, but with a texture):

https://github.com/Alpvax/AdvancedAutocrafting/blob/1.15/src/generated/resources/assets/advancedautocrafting/models/block/part/base_wire_arm.json

 

For reference, my wire blockstate has an enum property for each direction (NONE, CONNECTED, INTERFACE, DISABLED) and each state shows something different ("arm"s are visible for both connected and interface, hence the | in the "when" json value.

I would not recommend actually looking at my WireBlock code, it is overly complicated due to some experimentation I was doing with data generation and general messing around).

 

Attached image for end result (before disabled got its own model).

Edited March 17, 2020 by Alpvax
More info on my usage.

[Muramasa]

I really appreciate the detailed response, but I can't go down the vanilla multipart route as I also need to implement covers, side culling and user disable-able connections. I feel like this is way too much to hold in a blockstate. Maybe I could use the vanilla rotations tho

 

However this still highlights the issue that rotating UVs in code seems to be broken, unless I'm doing something wrong, but I don't know what that could be.

Edited March 18, 2020 by Muramasa

[TheGreyGhost]

Hi

I suspect you are using the wrong type of Transform / using SimpleModelTransform in a manner that it wasn't intended.  Without seeing your rendering code I'm not sure.

 

-TGG

[Muramasa]

Here is my model class

 

DynamicModel is just a integer configuration map (dependant on connection state) to baked model that is returned in DynamicBakedModel. When baking the model states, I pass a direction array, which multiples a transform matrix in 90 degree increments.

Edited March 18, 2020 by Muramasa

[TheGreyGhost]

Hi

I think SimpleModelTransform is not suitable for what you're trying to do.  I suspect you need one which lets you control isUvLock().  You could play around with Variant to see if it does what you want, or you could dig into the Forge/Vanilla code to see what is does when loading vanilla blocks which get rotated.

-TGG

[Muramasa]

I have solved the issue. It seems there was some weirdness when transforming the matrix in 90 degree increments. Passing a TransformationMatrix with hardcoded vector rotations did not produce incorrect UVs. I guess it was my fault? I'm not sure.. I don't know if multiplying a matrix rotation in 90 degree increments is incorrect or not.

 

Thank you everyone for your help

Edited March 18, 2020 by Muramasa

[Muramasa]

So I may of been too quick to class this as solved. It seems my initial strategy of rotating the matrix in 90 degree increments worsened the problem, but the issue still exists. It only happens on models that have more than one quad (and uv) per face

Edited March 19, 2020 by Muramasa