Initial support for Terrain SmoothGrid data

[checkraisefold]

DISCLAIMER: THIS IS MY FIRST ACTUAL PROJECT IN RUST. Terrible code will bleach your eyes!
Because of that, this PR also has edits by maintainers on.

This PR adds support for serialization and deserialization to rbx-types for the Terrain object SmoothGrid property data.
This fully permits the creation of external tooling for modification and generation of smooth terrain data, as Roblox Studio, along with RCCService (presumably) generate the additionally-required PhysicsGrid data at runtime/publish-time.

As a bonus, no reverse engineering of the client had to be done here; just a lot of comparing outputs with ImHex peddled by this article.
https://zeux.io/2017/03/27/voxel-terrain-storage/

Rendered spec.

[Dekkonot]

I'd prefer we keep the naming scheme intact and name the spec file for SmoothGrid to be smooth-grid.md.

Otherwise, I've left my comments and questions for the spec file.

[checkraisefold]

further code commits are paused until structure is reviewed so I don't add the deserializer and have to immediately rewrite it

[Dekkonot]

Overall, I'd say that this is a good start to an encoder. The comments up above are more focused on the actual code than things like code structure.

Let's rename the terrain.rs module to smooth_grid.rs. I'd also like it if the TerrainSerializer trait could be killed off, since I don't think it adds anything. The encode and decode methods could be under the same impl blocks as the rest of the methods.

Architecturally I have some things I'd like to change but they involve files outside of this PR so I won't force them onto you.. Stuff like moving smooth_grid and material_colors into a submodule named terrain and having them share a Material enum, as an example. If you want to make those changes you're welcome to but otherwise I'll do it after this is merged.

[Dekkonot]

This isn't really all that rigorous. I don't know if we should expose this without actually checking if the f32 is a valid i32. At the same time though, that's a hard thing to check, so maybe it's fine.

We should for sure document how it converts it though. Something like "naively converts the components to be i32s" would at least make it not surprising.

[checkraisefold]

the truncation is actually desirable behavior imo, supposed to be whole number and rounding down makes the most sense. or could remove this conversion entirely and force you to know exactly what you're doing

[Dekkonot]

...This test doesn't actually do anything. Can we make it panic if the output isn't identical to something Roblox emitted?

[checkraisefold]

this test is solely for development testing purposes while i was making the encoder so I could put it in place files and hence shouldn't make it out of the draft PR stage

[checkraisefold]

Architecturally I have some things I'd like to change but they involve files outside of this PR so I won't force them onto you.. Stuff like moving smooth_grid and material_colors into a submodule named terrain and having them share a Material enum, as an example. If you want to make those changes you're welcome to but otherwise I'll do it after this is merged.

i could give this a shot but I was mainly wondering how the enum should be structured with it being like this? the easiest way would be to just put it in order but you'd have to include air and some other non-colorable materials i think and then implement an error for them??

[checkraisefold]

i could give this a shot but I was mainly wondering how the enum should be structured with it being like this? the easiest way would be to just put it in order but you'd have to include air and some other non-colorable materials i think and then implement an error for them??

for this

[Dekkonot]

i could give this a shot but I was mainly wondering how the enum should be structured with it being like this? the easiest way would be to just put it in order but you'd have to include air and some other non-colorable materials i think and then implement an error for them??

There's a few ways I can imagine this working.

The first is that we just have a TerrainMaterial enum and error if you ever try to use a material that isn't allowed. This seems reasonable, but it's kind of a bummer that it would mean being unable to statically verify that a material was allowed.

Another option is to just say "to hell with it" and have multiple TerrainMaterial enums, which is how it's implemented right now. This solves the static analysis problem but it means that working with Terrain in rbx-dom requires two identically named enums, which is a terrible UX.

The final option I can see is that we have a centralized TerrainMaterial enum and then also module-specific material enums, which can be converted back and forth via from and try_from. I think I hate this idea, since it'd mean SmoothGridMaterial::try_from(TerrainMaterial::Water).unwrap() is a thing.

I'm inclined to go with the first option since it's the easiest and have the least obstructive UX possible. Moving us to a central TerrainMaterials enum is technically breaking because it involves adding variants to the one from MaterialColors, but I think I'm willing to accept it. Curious to know what @kennethloeffler thinks though.

---

In terms of actual implementation, I imagine that each Terrain would have its own internal variant that it used that it just tried to convert into from the central TerrainMaterials. That'd allow each module to do its own thing while still giving a consistent public interface.

[Dekkonot]

Can't wait for Ken for the rest of our days, so I'm gonna go ahead and say go for the plan I gave above with moving us to a central TerrainMaterials enum.