pvsyst_create_house_pv_scene

[Projects & Variants] Write a complete AI-authored house/PV scene in one call; prefer house.kind='mesh'. AI supplies all named architectural meshes (vertices in metres, explicit zero-based triangle indices): walls, multiple roof faces, eaves, chimney, window/door geometry, porch and other parts of the same house. The serializer does not reconstruct the house from flat/gable templates, invent dimensions, or require a rectangular footprint. Each name is unique ignoring case; total ceilings are 128 parts, 50000 vertices and 100000 triangles (adapter ceilings, not PVsyst limits). No external assets or code run. For a mesh house use layout.origin_m=[x,y,z] for the PV table's low local corner and layout.roof_mesh for its named planar, upward-facing support surface. That surface's normal must match the source fixed PV plane. Checks cover four corner projections, not full solid topology, holes, panel intersections or architectural certification. Alternatively layout={tables:[{name,...placed-layout fields},...]} defines 1..64 named PV regions on the same source orientation, with independent rows/columns and origins. Their SUM of module_rows*module_columns must equal the source module total. All use the same source PAN. Table names must be unique ignoring case. Coplanar overlapping PV rectangles stop; no automatic packing or physical shading approximation is used. Candidate-only dual-plane authoring accepts exactly two ordinary fixed-plane source subarrays with complete exclusive8.1.0/8.1.6 branches, the same PAN/OND and distinct orientations1/2. Use exactly two named tables with strict orientation_id=1/2, one region per source plane, and each region's count must equal that source subarray. House vertices and every origin_m stay in orientation1's local frame; only each PV node gets its source-relative standard Z rotation. Roof normal/corner checks use that frame. Grouped XY bounding footprints must be disjoint (adapter restriction, not a collision/engineering limit). Writes version2 metadata; native auto-import remains needs_context until per-table identity/geometric verification is bridged. Structured diagnostics locate invalid parts, vertices, triangles or table entries with repair hints. Fix those inputs and preview again; authored geometry is not patched. module_rows/columns, orientation and row/column_spacing_m remain explicit. Legacy house={length_m,width_m,eave_height_m,roof} plus the original margin/clearance layout stays compatible; do not mix its layout with mesh mode. House parts share the source anchor azimuth rotation. The tool only serializes official COLLADA1.5/PVCollada2.0 geometry and PV semantics; native project, variant and PAN bytes are never modified. Except for the explicit dual-plane candidate above, source requirements stay one Grid pvSystem/subarray/ordinary fixed plane; all modes exclude shading scene/module layout, load, storage, P50/P90 or saved horizon, complete grid counts and a northern-hemisphere site record. Module width and height come from a readable loose PAN in metres when available; matching Commercial/root aliases must agree and only XML pv:module uses millimetres. For a built-in database reference without a readable loose PAN, provide module_geometry explicitly; its provenance is caller-provided, awaiting PVsyst's import consistency check. A square module is allowed. geometry_depth_m is explicit geometric metadata, not an inferred vendor specification. All provided metadata must agree with a readable source PAN; no PAN, project or variant is generated or rewritten. Total table modules must equal the source module count (NModSerie x NStringCh), so the scene cannot be drawn smaller than the array. Tilt and azimuth are inherited from the source orientation record and only disclosed in the response, so the caller cannot pick engineering angles. The COLLADA azimuth uses north = 0 clockwise, converted as (180 + FieldAzim) % 360; that mapping is only verified for a northern-hemisphere site, so a non-positive latitude stops. House/table translation uses the same local frame; only vertex, face and transform data are generated. No physical, irradiance, shading or optimizer model is computed. AI-authored parts and legacy roofs use the same serializer. PVC2 support is still beta, so creating a file does not prove that PVsyst imports it as a shading scene or consumes it. dry_run=true writes nothing and creates no directory. Execution writes only UserData/<output_name>.pvc2 with no-overwrite semantics and re-checks both the source variant and PAN bytes. native_consumption_verified and imported stay false.