fix: P:R Toggle Latch client crash

[dequbed]

The renderer in use can't deal with vertices that are not face-aligned to block orientations and thus crashes on the inclines faces of the lever model. Changing the lever model to have straight faces with a sliding lever instead of a gyrating one fixes this crash.

Fixes: #1959

[covers1624]

Whops, guess I accidentally exposed this bug with a CBMultipart update :harold:

[dequbed]

Whops, guess I accidentally exposed this bug with a CBMultipart update :harold:

I'm surprised it ever worked to begin with ^^
As I understand it the Minecraft renderer is really quite optimised for orientation-aligned faces and really doesn't like more complex models, so I think this change is also potentially sensible even outside the crash because it allows making use of more optimisations ^^'

[covers1624]

Previously it was using CCL's renderer and lighting engines, which use the encoded normals in the model for lighting, so it likely did not care.

The change I did in CBMultipart was to require parts to return BakedQuads (this improves sodium compat) and let vanilla handle everything, the path ProjectRed is going through is the compat fallback where it will try and create baked quads from the old api endpoints, which requires it to compute an orientation for the quad.

[dequbed]

Previously it was using CCL's renderer and lighting engines, which use the encoded normals in the model for lighting, so it likely did not care.

The change I did in CBMultipart was to require parts to return BakedQuads (this improves sodium compat) and let vanilla handle everything, the path ProjectRed is going through is the compat fallback where it will try and create baked quads from the old api endpoints, which requires it to compute an orientation for the quad.

Oh that's cool. Would it work to have CBMultipart/CCL calculate the nearest Direction normal for unaligned normals or would that mess up rendering in some way? I saw that something like that was done in some other paths of the render code.
Or is the best solution to move P:R to a more modern render path in CBMultipart/CCL?

[MrTJP]

Thanks for looking into this! @covers1624 should we switch to using the non-fallback path? I can merge this for now but I don't want to just work around the core of the issue. There's likely many models in PR that don't have direction aligned quads

[covers1624]

Yes, we should, but the models likely need to be fixed regardless.

We may be able to make CCL slightly smarter with the auto-compute of the orientation here too.

[MrTJP]

Merging this new model. Once we move to the modern render path, I'll decide if I want the classic one back. Kinda like this new one though.

[dequbed]

Kinda like this new one though.

It fits the aesthetics of the mod pretty well, doesn't it? ^^
After all gyrating levers are very rare for electronics compared to sliding levers, especially at smaller scales. That's also why I immediately thought of making it a sliding lever and was pretty happy when that turned out to fix the crash ^^