
## Why Audio Blocks Matter

The Audio families let graph logic coordinate with Babylon.js Audio V2 playback.

These blocks are useful when interaction logic should start, stop, pause, or inspect sounds as part of a larger scene behavior.

## Audio Actions

### `PlaySound`

Use `PlaySound` to start an Audio V2 sound with playback options such as volume, offset, and looping.

### `StopSound`

Use `StopSound` when a sound should be halted immediately.

### `PauseSound`

Use `PauseSound` when the graph should pause a playing sound or resume one that is already paused.

### `SetSoundVolume`

Use `SetSoundVolume` when interaction logic should change a sound's volume dynamically.

## Audio Events

### `SoundEndedEvent`

Use `SoundEndedEvent` when graph logic should react to playback completion.

## Audio Data

### `GetSoundVolume`

Reads the sound's current volume.

### `IsSoundPlaying`

Reports whether the sound is currently playing or starting.

## Practical Notes

- These blocks target Audio V2 objects.
- They are most useful when the loaded scene already contains or creates the relevant sound references.
- Audio control often pairs well with pointer, pick, and custom event workflows.



## Why Control Flow Matters

The Control Flow family shapes when and how execution continues through the graph. These blocks are often the difference between a graph that merely reacts and a graph that behaves predictably over time.

## Core Branching And Routing

### `Branch`

Use `Branch` when execution should follow one path for `true` and another for `false`.

Typical uses:

- Only run an action when a true/false variable allows it
- Choose between success and failure paths
- Route logic based on a runtime check

### `Switch`

Use `Switch` when you need more than two execution outcomes. The block routes execution to a case-specific output based on an input value.

This is useful for state-driven graphs or mode-based logic.

### `MultiGate`

Use `MultiGate` to distribute repeated incoming triggers across multiple outputs instead of choosing between them from data.

This is useful for cycling behaviors or controlled sequencing patterns.

### `Sequence`

Use `Sequence` when one incoming signal should deliberately trigger several outputs in order.

This is useful when a single event should kick off multiple independent actions.

### `FlipFlop`

Use `FlipFlop` when repeated activations should alternate between two outputs.

This is a good fit for toggle-style interactions.

## Loops And Repetition

### `ForLoop`

Use `ForLoop` when you need a numeric iteration over a range. It is helpful when repeating an action a known number of times.

### `WhileLoop`

Use `WhileLoop` when repetition depends on a condition that stays true.

This is powerful, but it should be used carefully because poorly bounded conditions can make graphs harder to reason about.

### `DoN`

Use `DoN` when an action should be allowed only a limited number of times.

This is useful for actions that should run only once, or only a set number of times.

### `CallCounter`

Use `CallCounter` when you need execution history, such as triggering an action only after a block has been reached several times.

## Time-Based Flow Control

### `SetDelay`

Use `SetDelay` to schedule a continuation after a time interval.

This is useful for deferred actions, cooldown-style waits, and staged interactions.

### `CancelDelay`

Use `CancelDelay` when a pending delayed action should no longer happen.

Together, `SetDelay` and `CancelDelay` let you model timers that can be invalidated by later events.

### `Debounce`

Use `Debounce` when repeated fast triggers should collapse into one effective action after input settles.

This is useful for noisy event sources or rapidly repeated interactions.

### `Throttle`

Use `Throttle` when repeated triggers should still be allowed, but only at a limited rate.

This is useful when the graph should remain responsive without running an expensive action every frame or every input event.

## Coordination Blocks

### `WaitAll`

Use `WaitAll` when multiple required signals must arrive before execution continues.

This is useful for synchronization points in larger graphs.

## Choosing The Right Block

- Use `Branch` for two-way boolean routing.
- Use `Switch` for value-based multi-way routing.
- Use `Sequence` when every output should run in order.
- Use `MultiGate` or `FlipFlop` for repeated trigger distribution.
- Use `ForLoop`, `WhileLoop`, `DoN`, or `CallCounter` for repetition.
- Use `SetDelay`, `CancelDelay`, `Debounce`, or `Throttle` for time-sensitive execution.
- Use `WaitAll` when multiple prerequisites must complete first.



## Why Physics Blocks Matter

The Physics families let graphs respond to simulation events and directly change body state.

These blocks are most useful when the preview scene has Physics V2 enabled and physics bodies are already attached to relevant meshes.

## Physics Events

### `PhysicsCollisionEvent`

Use `PhysicsCollisionEvent` when graph logic should react to collisions.

This block can expose collision-related data such as the other body, contact information, impulse, and penetration details.

## Physics Actions

### `ApplyForce`

Use `ApplyForce` for sustained force-like effects, especially when driven repeatedly over time.

### `ApplyImpulse`

Use `ApplyImpulse` for instant velocity changes.

### `SetLinearVelocity`

Use `SetLinearVelocity` when you want direct control over movement speed and direction.

### `SetAngularVelocity`

Use `SetAngularVelocity` when you want direct rotational motion control.

### `SetPhysicsMotionType`

Use `SetPhysicsMotionType` when the body's motion mode itself should change.

## Physics Data

### `GetLinearVelocity`

Reads the current linear velocity.

### `GetAngularVelocity`

Reads the current angular velocity.

### `GetPhysicsMassProperties`

Reads mass, center of mass, and inertia information.

## Practical Notes

- Physics blocks depend on a physics-enabled scene.
- They are best tested against a preview scene that already contains physics bodies.
- When debugging these graphs, combine runtime stepping with visible scene motion so you can distinguish graph issues from simulation issues.


Audio Blocks

Why Audio Blocks Matter

Audio Actions

`PlaySound`

`StopSound`

`PauseSound`

`SetSoundVolume`

Audio Events

`SoundEndedEvent`

Audio Data

`GetSoundVolume`

`IsSoundPlaying`

Practical Notes

Further reading

Block Reference

First-pass reference for the current blocks available in the Babylon.js Flow Graph Editor.

Supported Block Families

Overview of the current block families available in the Babylon.js Flow Graph Editor.

Authoring, Validation, and Debugging

Learn how to run, inspect, validate, and organize graphs in the Babylon.js Flow Graph Editor.