Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions creator/sdk7/3d-essentials/lights.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 2 additions & 0 deletions creator/sdk7/design-experience/design-games.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down
6 changes: 5 additions & 1 deletion creator/sdk7/interactivity/player-avatar.md
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand All @@ -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.

Expand Down
11 changes: 11 additions & 0 deletions creator/sdk7/interactivity/player-physics.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
4 changes: 4 additions & 0 deletions creator/sdk7/optimizing/performance-optimization.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down
18 changes: 18 additions & 0 deletions creator/sdk7/projects/scene-metadata.md
Original file line number Diff line number Diff line change
Expand Up @@ -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](../publishing/publishing-options.md#decentraland-worlds), you can configure several World-specific settings in your `scene.json` file using the `worldConfiguration` object.
Expand Down