Occlusion policy and dependency rules
Two features that live in the planner rather than in the engine. Both are useful; neither does what its name suggests if you assume it is a runtime behaviour. This is the page that keeps that from being an expensive surprise.
Occlusion policy#
An occlusion policy expresses intent about how much of a target should be visible: a planning and QA contract, used when producing and evaluating a plan.
What it is not: a force that makes objects occlude each other. Actual occlusion is produced by geometry and placement. If you want objects partly hidden, put something in front of them — arrange the scene so it happens, using clusters and inter-class distances.
The measured result appears afterwards as occlusion_ratio per observation,
which is the number to check. The policy states what you wanted; the ratio states what the
frame contained.
Dependency rules#
Dependency rules express ordering and conditional relationships between spawn rules at planning time.
The native capture path does not consume dependency rules. It does not ignore them either. A job carrying the field is rejected before capture, with a specific error:
[UNSUPPORTED_CAPTURE_JOB_FIELD] 'dependency_rules' is not consumed by
this native semantic path; disable that ScenarioConfig feature until the
runtime advertises support.The same rejection applies to the sensor block, for the same reason: sensor
and lens degradation is an offline image-processing path, so a
capture job carrying it would be claiming the engine will do something it will not.
Why failing is the right behaviour#
The alternative is worse in a way that is hard to detect. A run that silently ignored an unsupported field would produce a complete-looking dataset in which your dependency rule had no effect, and nothing about the output would say so. You would find it by noticing the relationships you asked for are not there, which could be weeks later.
Failing at job load costs you one error message and thirty seconds.
How to tell which side a field is on#
The execution model page carries the matrix, and the generated field reference exposes the execution owner per field. When in doubt, a dry run followed by a smoke test will surface a rejection before a full run does.