ADR 256: static entities #281
Conversation
Deploying adr with
|
| Latest commit: |
3273939
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://13b23549.adr-cvq.pages.dev |
| Branch Preview URL: | https://static-entities.adr-cvq.pages.dev |
| Note: As an alternative approach, we also discussed handling this via a separate new `Static` component instead of a new field on the `Transform` component. There are pros and cons to each approach. | ||
|
|
||
| - On one hand, an extra field on the Transform adds a slight overhead to each update message regarding any transform. (Although if the value of its corresponding protobuff digit is 1, then there should be no Transform updates beyond the initial creation) | ||
| - On the other hand, it's easier to creators to find where to add this property if it exists on the Transform. Any object that makes sense to make static will always have a Transform anyway. |
There was a problem hiding this comment.
I'd choose Static component rather than an extra bool in Transform.
- Static feature affect many other components beside Transform, it makes more sense to implement it as a new component in my opinion
- 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
|
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 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 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. |
No description provided.