API functionalities from other ecosystems

[philpax]

There's precedent for the kind of scripting ecosystem we're trying to foster (Garry's Mod, FiveM, JC2-MP, MTA, etc). This is a rough list of functionality from these ecosystems that I think would be nice to have in Ambient at some point. When/if we're ready to work on them, they can be converted to issues or such:

• rendering
  • post-processing support (Add a component mixer camera component for rudimentary color grading #555 etc)
  • custom render targets
  • particle systems
  • immediate-mode rendering (Immediate-mode clientside 2D/3D rendering functions #431)
  • light creation/manipulation
• entity:
  • per-entity callbacks (not sure how this would work with our ECS paradigm, or what this would mean - generalisation of the messages?)
  • hierarchy traversal/search ("find child by name", generalised operations)
  • bounding box/radius retrieval
  • knowing what spawned the entity (world load, multiplayer sync, WASM)
  • bone/skeletal manipulation (likely possible with just hierarchy traversal + entity manipulation, but helpers might be useful?)
• physics
  • constraints (Expose physics::weld(ent1, ent2) #161, Expose remaining PhysX joints #162)
  • procedural physics mesh (Procedural physics meshes #540)
  • parameters (drag, damping, inertia, gravity, buoyancy, etc)
• player
  • kick/ban
  • current connection status of the player (connecting, connected)
• assets
  • check if a given asset is loaded
• input
  • gamepad/analogue input support
  • "global" input lock system?
• persistence
  • file I/O (A way to read/write files local to your project #531)
  • database access

[FredrikNoren]

• "fine bone by name" exists here: https://github.com/AmbientRun/Ambient/blob/main/guest/rust/api_core/src/animation.rs#L269
• bounding box should just be looking at the component right? there's the local_ and world_bounding_X components, not sure if they are exposed in the api right now though

[philpax]

• Good catch! I've edited it to cover the more generic operation I wanted to cover - getting/manipulating something in the hierarchy by an arbitrary query.

  We could genericise get_bone_by_bind_id to take either an arbitrary EntityId -> bool condition or a (component, value) to search for, move it to entity, and then reimplement get_bone_by_bind_id with reference to that. Not sure if we could do with other hierarchy manipulation, though.

• Ah yeah, those exist but aren't exposed because they're AABB = Cuboid type. Could either split them into individual components, offer functions for retrieving them, or wait for structured type components (but that could be a long way away).

  Don't think we have any immediate demand for this (outside of maybe debug viz), so we can figure it out later.

[FredrikNoren]

For additional context; bind_ids are related to hierarchy but not equivalent, they are for animations specifically. They're more of "abstract targets", like "left foot", which is then resolved to something in the hierarchy.