We must not use vectors in `extern` structs

[IntegratedQuantum]

They don't have a guaranteed memory layout, see ziglang/zig#24179 (comment)

this is a requirement for #1583

Problematic places:

• QuadInfo in models.zig
• ChunkData in chunk_meshing.zig
• Particle in particles.zig (this one is even missing the extern declaration)

I think the best solution for now is probably just to use e.g. align(16) [3]f32 instead of Vec3f and coerce them in all use-cases

[jingkaimori]

could zig make some optimization by altering layout of vector? if so, only vectors passed into pipeline should be changed to aligned fix-width array.

[IntegratedQuantum]

This is only about extern structs, which are used to communicate with e.g. glsl, where we must, at all cost, have a fixed memory layout.

[jingkaimori]

It seems like most vector is decomposed like here before passing into glsl:

Cubyz/src/renderer.zig

Lines 314 to 315 in 9c33f81

	c.glUniform3i(deferredUniforms.playerPositionInteger, @intFromFloat(@floor(playerPos[0])), @intFromFloat(@floor(playerPos[1])), @intFromFloat(@floor(playerPos[2])));
	c.glUniform3f(deferredUniforms.playerPositionFraction, @floatCast(@mod(playerPos[0], 1)), @floatCast(@mod(playerPos[1], 1)), @floatCast(@mod(playerPos[2], 1)));

However, vectors could be passed in as a pointer to aligned buffer:

Cubyz/src/renderer/chunk_meshing.zig

Line 213 in 9c33f81

c.glUniform3fv(transparentUniforms.@"fog.color", 1, @ptrCast(&game.fog.skyColor));

Therefore only some vector should be changed to given layout, which is passed into APIs ending with a v like glUniformxxv

[IntegratedQuantum]

Again, this is only about extern structs, as far as I'm aware you can still safely @ptrCast from a vector to an array pointer, so there is no problem with the glUniform calls.