"Importing Kenney / CC0 kits into s&box"

You drop a Kenney (or other CC0) kit into the project and get wrong scale, missing textures, or models that face a random cardinal direction when placed.

Kits are just meshes + textures — s&box still needs .vmdl wrappers, inch scale, and material remaps. Kit conventions differ:

• City-style kits often use one shared colormap.png.
• Nature / flat-color kits use flat Kd colors → you need per-color .vmats (white.png + g_vColorTint), not a single atlas.
• Model "front" in kit space is a 50/50 guess relative to your Blender-pipeline facing convention.

You usually don't control native scale, so uniform import_scale = 39.37 is wrong unless the kit was authored in meters.

1. Copy OBJ (+ textures) into Assets/models/<project>/ (and materials under Assets/materials/...).
2. Generate a .vmdl per model (same both-names remap rule as sbox-wont-load-obj-glb).
3. Per-model target size from OBJ bounds:

scale = target_units / native_extent  # target_units already in inches
# write that into RenderMeshFile import_scale

4. Materials:
   • Shared atlas → one vmat pointing at colormap.png (root-relative path under materials/...).
   • Flat Kd colors → one vmat per color: TextureColor = shared white PNG, tint via g_vColorTint "[r g b 0]", g_flModelTintAmount "1.000".
5. Facing: hard-code a facing-yaw constant per model (or per kit family) and verify visually once. Do not assume Blender-pipeline +90 without checking.

Wire sizes into your generated C# catalog so colliders/footprints match the scaled bounds.

CC0 kits aren't a special engine path — they're external OBJs with inconsistent authoring frames. Per-model import_scale from measured bounds absorbs unknown native units; material strategy must match how the kit encodes color (atlas vs Kd); facing can't be inferred reliably from filenames, so a verified yaw table is the only stable fix.