Support THREE.Timer while retaining compatibility with older Three.js versions

[Huciko]

Description

Spark currently uses THREE.Clock internally in sparkRuntime.ts. In applications using Three.js r183 or later, this results in Spark relying on a deprecated Three.js API, even when the application itself has migrated to THREE.Timer.

THREE.Clock: This module has been deprecated. Please use THREE.Timer instead.

Could Spark introduce a version-compatible timing abstraction that uses THREE.Timer when available and falls back to THREE.Clock for older supported Three.js versions?

This would align Spark with current Three.js timing APIs, avoid deprecated API usage, and preserve compatibility with older Three.js releases.

[mrxz]

There's a PR to address this issue: #378. Since Spark targets r180 and later, it can safely rely on THREE.Timer as it has been moved into core in r179, so no need for version detection or fallbacks.

[Huciko]

Thanks @mrxz ,
sorry to miss that :)