From ac9c31ba4bb29645ff9c477e68b0d000827b84c5 Mon Sep 17 00:00:00 2001 From: nearnshaw Date: Tue, 14 Jul 2026 17:33:21 -0300 Subject: [PATCH 1/3] disable terrain --- creator/sdk7/design-experience/design-games.md | 2 ++ .../optimizing/performance-optimization.md | 4 ++++ creator/sdk7/projects/scene-metadata.md | 18 ++++++++++++++++++ creator/worlds/about.md | 1 + 4 files changed, 25 insertions(+) diff --git a/creator/sdk7/design-experience/design-games.md b/creator/sdk7/design-experience/design-games.md index 141e4785..400257d9 100644 --- a/creator/sdk7/design-experience/design-games.md +++ b/creator/sdk7/design-experience/design-games.md @@ -20,6 +20,8 @@ Players that step outside your scene keep rendering it as long as it’s at a vi You could also build a game that spreads out throughout several disconnected plots of land that are unknown to players, and where the exploration of the rest of the world becomes part of the gameplay. A game like that would be made up of multiple separate _scenes_, that could share data with each other via a server. +If your game is published to a [Decentraland World](../../worlds/about.md), you have more control over what players see beyond your scene's boundaries. Worlds are normally surrounded by an auto-generated landscape of grassland, trees, and sea, but you can [disable this landscape](../projects/scene-metadata.md#landscape-terrain) if it clashes with your game's setting, for example a game that takes place in open water or in space. + ### User inventory **There currently isn’t an inventory where players can store game items as they walk between scenes.** The following alternatives are available today: diff --git a/creator/sdk7/optimizing/performance-optimization.md b/creator/sdk7/optimizing/performance-optimization.md index 1a93ddfb..cd063040 100644 --- a/creator/sdk7/optimizing/performance-optimization.md +++ b/creator/sdk7/optimizing/performance-optimization.md @@ -162,6 +162,10 @@ Avoid making adjustments to the UI on every frame, those are especially costly a Avoid having many hidden UI elements, these also have an effect on performance even if not being rendered. When possible, try to create UI components on demand. +## Landscape terrain in Worlds + +Scenes published to a [Decentraland World](../../worlds/about.md) are surrounded by an auto-generated landscape of grassland, trees, and sea. Rendering this landscape consumes part of the player's rendering budget. If your scene doesn't need it, you can [disable the landscape terrain](../projects/scene-metadata.md#landscape-terrain) in your `scene.json` to free up those resources for your scene's own content. + ## Monitor Performance The best metric to know how well a scene is performing is the FPS (Frames Per Second). In preview, you can see the current scene FPS in the debug panel. You should aim to always have 30 FPS or more. diff --git a/creator/sdk7/projects/scene-metadata.md b/creator/sdk7/projects/scene-metadata.md index 678a98f3..aab19045 100644 --- a/creator/sdk7/projects/scene-metadata.md +++ b/creator/sdk7/projects/scene-metadata.md @@ -486,6 +486,24 @@ Here are some more examples of valid values: * 64800 seconds => _18:00_ * 86400 seconds => _24:00_ +## Landscape terrain + +Scenes published to a [Decentraland World](../../worlds/about.md) are surrounded by an auto-generated landscape of grassland, trees, and sea. If this landscape doesn't match the aesthetics of your scene, for example a scene that floats in open water or in space, you can disable it. To do this, add the following field to your `scene.json` at root level: + +```json +{ + "landscapeTerrain": false +} +``` + +With `landscapeTerrain` set to `false`, nothing is rendered beyond your scene's parcels, and players only see the skybox around the scene. Removing the surrounding terrain also frees up rendering resources, which can help your scene run smoother. + +If the field is not set, it defaults to `true` and the landscape is displayed as usual. + +{% hint style="warning" %} +**πŸ“” Note**: This field only applies to Worlds that contain a single scene. It's ignored in Genesis City, where the surroundings are always determined by the neighboring parcels. You can also use it while running a local preview of your scene, to check how the scene looks without the landscape. +{% endhint %} + ## World configuration When publishing to a [Decentraland World](../../worlds/about.md), you can configure several World-specific settings in your `scene.json` file using the `worldConfiguration` object. diff --git a/creator/worlds/about.md b/creator/worlds/about.md index 0fc66728..77553e22 100644 --- a/creator/worlds/about.md +++ b/creator/worlds/about.md @@ -27,5 +27,6 @@ To get your own Decentraland World, you need a [Decentraland NAME](https://build * [Publishing options](../sdk7/publishing/publishing-options.md#decentraland-worlds) - How to obtain a NAME or ENS domain * [Publishing to Worlds](../sdk7/publishing/publishing.md#publishing-to-worlds) - Step-by-step publishing instructions * [World configuration](../sdk7/projects/scene-metadata.md#world-configuration) - Configure skybox, communication settings, and more +* [Landscape terrain](../sdk7/projects/scene-metadata.md#landscape-terrain) - Disable the auto-generated landscape around your World's scene * [Managing Worlds](../scene-editor/get-started/manage-scenes.md#managing-worlds) - Visualize storage space and manage deployments * [World FAQs](../scene-editor/faq/README.md#worlds) - Common questions about Worlds From 3cccf0e3e23a5917cb1494cff16138a9d680be6a Mon Sep 17 00:00:00 2001 From: nearnshaw Date: Tue, 14 Jul 2026 17:38:46 -0300 Subject: [PATCH 2/3] glider physics force --- creator/sdk7/interactivity/player-avatar.md | 6 +++++- creator/sdk7/interactivity/player-physics.md | 11 +++++++++++ 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/creator/sdk7/interactivity/player-avatar.md b/creator/sdk7/interactivity/player-avatar.md index 11ebd989..ac2c2521 100644 --- a/creator/sdk7/interactivity/player-avatar.md +++ b/creator/sdk7/interactivity/player-avatar.md @@ -342,7 +342,7 @@ The following properties are available: - `runJumpHeight`: The height at which the player jumps after running, in meters. - `doubleJumpHeight`: The height of the second jump when double-jumping, in meters. - `glidingSpeed`: The horizontal speed at which the player moves while gliding, in meters per second. -- `glidingFallingSpeed`: The falling speed of the player while gliding, in meters per second. +- `glidingFallingSpeed`: The maximum falling speed of the player while gliding, in meters per second. This only caps the player's descent: upward motion, like a lift from a scene's continuous force, isn't limited. - `hardLandingCooldown`: The cooldown after a hard landing, in seconds. This is the time that the player has to wait before they can move again after landing from a high fall. For reference, here are the default values for those properties: @@ -357,6 +357,10 @@ For reference, here are the default values for those properties: - `doubleJumpHeight`: 2 m - `hardLandingCooldown`: 0.75 s +{% hint style="info" %} +**πŸ’‘ Tip**: While gliding, continuous forces applied by the scene are 1.5 times stronger, and upward forces can lift the player. See [Forces while gliding](player-physics.md#forces-while-gliding). +{% endhint %} + {% hint style="info" %} **πŸ’‘ Tip**: None of these properties can be lower than 0. If you set one of them to a negative value, it will be clamped to 0. Setting these values to zero will have the same effect as using the `InputModifier` to block the use of certain keys. diff --git a/creator/sdk7/interactivity/player-physics.md b/creator/sdk7/interactivity/player-physics.md index 6ab1db50..44c925cc 100644 --- a/creator/sdk7/interactivity/player-physics.md +++ b/creator/sdk7/interactivity/player-physics.md @@ -235,6 +235,17 @@ timers.setTimeout(() => { ``` +## Forces while gliding + +While the player is gliding, continuous forces behave differently: + +* Continuous forces β€” from `applyForceToPlayer()`, `applyForceToPlayerForDuration()`, or `applyRepulsionForceToPlayer()` β€” are **1.5 times stronger**, since the open glider catches the airflow. Wind zones and currents feel more responsive to a gliding player. +* The upward component of a continuous force can **lift** a gliding player. The glider's falling speed limit only caps how fast the player descends, it doesn't cancel upward motion, so an angled or vertical wind current pushes the player along the full direction of the force. + +One-shot impulses β€” from `applyImpulseToPlayer()` or `applyKnockbackToPlayer()` β€” are not affected by gliding. They behave the same whether the glider is open or closed. + +You can combine these behaviors to build mechanics like thermal updrafts that carry gliding players upward, or wind corridors that are easier to traverse with the glider open. To adjust the glider's falling speed or forward speed, use the `AvatarLocomotionSettings` component, see [Locomotion Settings](player-avatar.md#locomotion-settings). + ## Convert a local direction to world space Use `Transform.localToWorldDirection()` to transform a direction vector from an entity's local coordinate space to world space, accounting for the full parent hierarchy. This is useful when applying forces relative to a rotated entity β€” for example, pushing the player away from a specific face of a rotating obstacle. From 0fd3ddf80fed09d5415fe3226b5dfd1d802dcb85 Mon Sep 17 00:00:00 2001 From: nearnshaw Date: Tue, 14 Jul 2026 17:52:40 -0300 Subject: [PATCH 3/3] light culling distance --- creator/sdk7/3d-essentials/lights.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/creator/sdk7/3d-essentials/lights.md b/creator/sdk7/3d-essentials/lights.md index 004ab32c..480625fa 100644 --- a/creator/sdk7/3d-essentials/lights.md +++ b/creator/sdk7/3d-essentials/lights.md @@ -183,12 +183,13 @@ If there are more lights than allowed, the engine will automatically disable lig In all cases, the engine will only render shadows for up to 3 light sources. If there are more lights with shadows than 3, the engine will automatically disable shadows for the remaining lights that are further away. -Besides the maximum number of allowed lights, shadows also depend on distance from the player. +Besides the maximum number of allowed lights, shadows also depend on distance from the player. The exact distances vary with the light type and the player's quality settings, but as a general rule: -* Less than 10 meter away: Shadows are rendered as soft shadows (high quality) +* Less than 10 meters away: Shadows are rendered as soft shadows (high quality) * Between 10 and 20 meters away: Shadows are rendered as hard shadows (low quality) -* Between 20 and 40 meters away: Shadows aren't rendered -* More than 40 meters away: Light sources are not rendered at all +* More than 20 meters away: Shadows aren't rendered + +The light sources themselves keep illuminating the scene at much larger distances: they are only disabled when the player is more than 160 meters away (10 parcels). This makes lights suitable for large-scale setups like stage lighting at live events, where most of the audience is far from the light sources. It's also important to note that lights are only rendered if the player is standing inside the scene. If the player is outside the scene, the lights will not be rendered.