ADR 256: static entities

[nearnshaw]

No description provided.

[cloudflare-workers-and-pages]

Deploying adr with    Cloudflare Pages

Latest commit:	3273939
Status:	✅  Deploy successful!
Preview URL:	https://13b23549.adr-cvq.pages.dev
Branch Preview URL:	https://static-entities.adr-cvq.pages.dev

View logs

[NickKhalow]

I'd choose Static component rather than an extra bool in Transform.

1. Static feature affect many other components beside Transform, it makes more sense to implement it as a new component in my opinion
2. I'd say that it would affect L-caching performance on engine's side because each extra field makes an array of structures bigger and it turns to handle less components at the time. But this aspect could be easily optimised

[kuruk-mm]

Adding a field to the Transform breaks the compatibility of the protocol. The Transform is not a protobuf; it's a fixed set of bytes. Adding a new field changes its length, which makes it problematic. Additionally, it's the most used component. Adding one byte that isn't going to be used is not a good option.

Optionally, we can use a new StaticComponent as @NickKhalow said. To make things easier for Creators, we could create a wrapper in the SDK that behaves like a new field in the Transform but adds the StaticComponent behind the scenes.

Almost every time we make a protocol change to "make things easier for users," the solution doesn’t lie in the protocol itself—it lies in the SDK implementation. The protocol should remain as simple as possible, serving as an efficient communication channel between the runtime and the explorers.

Anyway, we have another proposal for this approach that we think is better for the Creator and also easier for the Protocol: adding this function to the engine API.

Example code:

import { markEntitiesAsStatic } from '~system/EngineApi'

export function main() {
  const door = engine.addEntity()

  GltfContainer.create(door)
  markEntitiesAsStatic([door])

  GltfContainer.update(door) // it should fail at the SDK level... at the engine level, it does nothing
}

WDYT?

Also. It would be interesting to know which kind of optimization the Foundation is thinking.

[AlejandroAlvarezMelucciDCL]

Adding a field to the Transform breaks the compatibility of the protocol. The Transform is not a protobuf; it's a fixed set of bytes. Adding a new field changes its length, which makes it problematic. Additionally, it's the most used component. Adding one byte that isn't going to be used is not a good option.

Optionally, we can use a new StaticComponent as @NickKhalow said. To make things easier for Creators, we could create a wrapper in the SDK that behaves like a new field in the Transform but adds the StaticComponent behind the scenes.

Almost every time we make a protocol change to "make things easier for users," the solution doesn’t lie in the protocol itself—it lies in the SDK implementation. The protocol should remain as simple as possible, serving as an efficient communication channel between the runtime and the explorers.

Anyway, we have another proposal for this approach that we think is better for the Creator and also easier for the Protocol: adding this function to the engine API.

Example code:

import { markEntitiesAsStatic } from '~system/EngineApi'

export function main() {
  const door = engine.addEntity()

  GltfContainer.create(door)
  markEntitiesAsStatic([door])

  GltfContainer.update(door) // it should fail at the SDK level... at the engine level, it does nothing
}

WDYT?

Also. It would be interesting to know which kind of optimization the Foundation is thinking.

I didn't know the Transform wasn't a protobuf, I understand the issue now.
I think we might be limited to the options we have and what you proposed seems to be the easiest. I'm not sure about the naming or having a function like that, but the idea feels solid, I might think of a better implementation later on.

I am very curious about what you mention of another proposal of adding this function to the engine, can you elaborate?
Or is it just to add: engine.markStatic([door]) ?