Collision Masks FAQ: Category and Collide Fields in Simulation

Do matching Collision Masks prove that two objects touched in a simulation? The question confuses a declared filtering relationship with an observed simulation event. SDFormat contains separate category and collide bitmask descriptions, and a learner should preserve both roles before interpreting a scene package. This FAQ reads the SDFormat 1.12 source definitions. It uses a fictional robot-scene note, without loading a model, evaluating a bitwise example or running a physics engine.

Where does the filter belong in the scene description?

The official collision-element definition places collision properties within a link's collision element and includes geometry and surface descriptions. It explicitly distinguishes collision properties from visual properties. This locates the filtering question within a described collision object, rather than an arbitrary visible object name in a screenshot.

A proposed package review should identify the full collision-element context before copying a mask. A link can have a named collision element, and a visible mesh is not a sufficient identifier for every underlying property. Ask the contributor which declaration the summary describes. This is a question about the supplied file's structure; it does not establish how a simulator interpreted that structure during a particular run.

How do category and collide masks have different roles?

The official surface definition describes collide_bitmask as a collision-filtering mask and category_bitmask as the category mask for collision filtering. It gives a rule combining each category mask with the other object's collision mask, joining the two directional terms with a bitwise OR. A review should not replace that stated rule with an informal requirement that both directional terms must be nonzero.

The source also states what the category mask should mean when it is unspecified: it is interpreted as the collide mask. That omission rule matters when comparing a concise file with an expanded summary. An omitted category entry is not automatically an empty category. The summary should explain whether it copied an explicit declaration or applied the source's stated omission interpretation.

What other nearby setting can change the question?

The same surface source describes collide_without_contact as disabling contact-force generation while allowing collision checks and contact visualization. It separately describes the relationship of collide_bitmask to that setting. These are reasons to keep adjacent contact configuration visible in a review. A statement that a filter permits a pair does not describe every aspect of contact-force behavior.

No particular numeric mask or contact coefficient is recommended here. A document reviewer can ask which settings the contributor intended to summarize and which specification version explains them. That request is useful before running an experiment. It prevents a learner from treating the presence of a filter declaration as a complete physical model or as evidence that a simulated event already occurred.

How would a fictional scene note overclaim?

Imagine an explicitly fictional scene called Model Rowan. Its handover note says that the robot contacted a barrier because the package contains mask declarations. There is no run account or observation attached. The reviewer can identify the unsupported jump from configuration to event. This example contains no actual robot geometry, mask evaluation or simulated contact result.

A narrower revision would identify the two collision declarations, explain their category and filtering roles, and leave the event question open. If an observation is supplied later, retain the scene revision and simulator context it concerns. A configuration note and an observation account should be connected explicitly rather than blended into a single sentence that hides their different origins.

Suppose the revised note adds a screenshot of overlapping visual meshes. The screenshot still needs an explanation of what it depicts and which collision configuration applies. Visual overlap, a filter declaration and a reported contact-force observation are distinct materials. The reviewer can ask for their relationship without inferring that any one of them independently establishes the others.

For a scene revision, ask whether a changed mask belongs to the same collision element or a replacement element with another name. A prose change log may summarize both as “collision fixed,” but that phrase leaves the actual declaration unexplained. The reviewer can request a description of the changed relationship and preserve the earlier file as historical context. This does not claim that the revision repaired a physical interaction. It makes the configuration change understandable before anyone attributes an observed difference to it.

What makes the reading reproducible for another learner?

Keep the SDFormat version, the relevant element identities and the exact source description of the filtering rule. Record whether a category entry was explicit or interpreted under the omission rule. Identify any unresolved simulator or observation context separately. These details allow another learner to follow the same documentation question without pretending that a source inspection is a completed physics test.

The site's simulation-reference category and related-information category offer further navigation. A useful final note can explain how the package declares the collision filter and what evidence is still needed for an event claim. That bounded conclusion preserves the distinction between a scene's intended configuration and a result actually observed in a defined simulation.