hayba-pcg-build

Hayba PCG build

When to use

Use for a new or existing PCG/PCGEx graph when the result must be repeatable and verified in a real editor. The production method is still a choice to make from the scene requirements.

Decide before authoring

1. State the desired scene outcome and its constraints: target platform, frame-time and memory budgets, streaming boundaries, instance and draw-call expectations, texel density, deterministic regeneration, edit frequency, and designer override needs. Record unknown budgets as unknown; do not invent a pass/fail threshold.
2. Compare viable methods before choosing a graph. Include manual/Actor Palette placement or reusable composed assets, native PCG, PCGEx, and a hybrid where relevant. Manual composition gives precise art direction but costs placement and maintenance time. Native PCG supports repeatable broad distribution with fewer dependencies but may need bespoke graph logic. PCGEx offers specialized graph, cluster, path, and staging operations but adds a plugin/version dependency and more graph complexity. A hybrid can reserve hero assets and exceptions for manual control while generating the repeatable field, at the cost of a clear ownership boundary. For each candidate, note streaming and regeneration costs, correction workflow, and why it fits or fails this scene.
3. Look for a relevant standard production pattern when evidence is available, then propose at least one structural alternative, such as changing route, visibility, or asset grouping rather than only tuning density. Label analogies as design hypotheses until tested in this project.

Tool routing

Ground the graph

1. If PCGEx is a candidate, call hayba_query_pcgex_docs for the task concepts and candidate classes, then hayba_get_pcgex_knowledge_detail for exact IDs. Record the bundle generation date, documented plugin version, source hash/stale flag, and any warnings or conditions. Treat placeableInPcgGraph as a documentation classification, not proof that the node is installed. The bundle is optional; an unavailable result is an evidence gap, not permission to guess pins or settings.
2. Use hayba_get_pattern_template only as an annotated starting point. Its preflight is catalog-only and can report absent or unknown pins. In the target scratch editor, use pcg_list_node_classes and pcg_get_node_details to confirm loaded settings classes, default pins/types, and properties. Compare the installed PCGEx .uplugin version with the documented version. Resolve a mismatch from live reflection or defer the uncertain connection; never silently convert a documentation pin into a wire.
3. Sketch the graph as JSON with explicit asset/component ownership. Use pcg_validate_graph and resolve its errors before pcg_create_graph. Before wiring a created node, use pcg_list_pins on that graph to check its exact current labels and types, including dynamic pins. A validator pass is only a structural check; it does not establish that the graph produces the intended scene or meets performance budgets.