BabylonJS Logger: Adding Per‑Category Filtering to Reduce Console Noise

Short answer: yes, a wrapper around BABYLON.Logger is the practical way to get per-category filtering today. BabylonJS's Logger (as of the 6.x/7.x line) exposes only a global LogLevels setting plus Log, Warn, and Error methods — there is no built-in category or tag support, and I'm not aware of any maintained official extension that adds it. Modifying the engine source is possible but is the worst option for upgrade compatibility. The wrapper approach preserves the public API, requires no fork, and keeps errors and warnings visible while you mute noisy subsystems.

How the wrapper works

The idea is to make your wrapper the single entry point for your own logging calls. Each call carries a category (a string tag or a message prefix), and the wrapper consults a per-category level map before forwarding to the real Logger. Anything below the category's threshold is dropped; everything else passes through to BABYLON.Logger, which still applies its own global level.

const CategoryLevels = {
  Physics: BABYLON.Logger.WarningLogLevel,
  Assets:  BABYLON.Logger.ErrorLogLevel,
  UI:      BABYLON.Logger.LogLogLevel,
};

const CategoryLogger = {
  log(category, msg) {
    if (BABYLON.Logger.LogLogLevel >= (CategoryLevels[category] ?? BABYLON.Logger.LogLogLevel)) {
      BABYLON.Logger.Log(`[${category}] ${msg}`);
    }
  },
  warn(category, msg) {
    if (BABYLON.Logger.WarningLogLevel >= (CategoryLevels[category] ?? BABYLON.Logger.WarningLogLevel)) {
      BABYLON.Logger.Warn(`[${category}] ${msg}`);
    }
  },
  error(category, msg) {
    BABYLON.Logger.Error(`[${category}] ${msg}`); // never filtered
  },
};

With this setup, CategoryLogger.log("Physics", "contact resolved") is suppressed, while CategoryLogger.warn("Physics", "solver drift") still prints. Errors are never filtered, which matches your requirement that critical alerts always remain visible.

What this does and doesn't cover

One honest limitation: the wrapper only filters your log calls. BabylonJS's own internal logging (engine warnings about materials, textures, etc.) goes straight to the global Logger and can't be categorized without patching engine code. In practice that's usually acceptable — engine-internal messages are already mostly warnings and errors, and the verbose debug spam tends to come from your own subsystems. If engine-internal noise is your actual problem, the only lever the public API gives you is the global level, and I'd want to know which messages specifically are flooding you before recommending a source patch.

Why not fork the Logger

Patching the Logger internals to add real category support means maintaining a fork or reapplying a patch after every BabylonJS upgrade. The Logger API is small and stable, so a patch would probably survive minor releases, but you'd own the merge risk forever, and any future official category support would conflict with it. Given that a ~30-line wrapper achieves the goal with zero upgrade friction, the fork is hard to justify.

Verifying it

1. Emit one debug, one warning, and one error per category in a test scene.
2. Set CategoryLevels.Physics to WarningLogLevel and confirm physics debug lines disappear while warnings and errors remain.
3. Toggle the wrapper off (call BABYLON.Logger directly) and diff console output to confirm the wrapper isn't duplicating or swallowing messages.

One caveat to flag for review: exact LogLevels member names have shifted slightly across major versions, so confirm the enum names against your installed version before shipping.