Currently each terrain type hard-codes its asset categories and their placement behavior. DemTerrain is a forest (tree/rock/bush/grass/sand); CropRowTerrain is crop/weed/irrigation. The category vocabulary lives in default_categories() / default_strategies() / default_densities() on each terrain class.
This is fine while terrain types are few and stable. It becomes limiting once users want custom biome mixes (e.g. a DEM mesh hosting a desert, or "forest with more categories"), today that requires subclassing in Python + extending DensityConfig.
Currently each terrain type hard-codes its asset categories and their placement behavior. DemTerrain is a forest (tree/rock/bush/grass/sand); CropRowTerrain is crop/weed/irrigation. The category vocabulary lives in default_categories() / default_strategies() / default_densities() on each terrain class.
This is fine while terrain types are few and stable. It becomes limiting once users want custom biome mixes (e.g. a DEM mesh hosting a desert, or "forest with more categories"), today that requires subclassing in Python + extending DensityConfig.