Ask Epic: Verse - March 28 @ 10:00 AM ET

Scene graph questions, if possible please reply in-line. :slight_smile:

  • :white_check_mark: Is scene graph meant to replace the traditional actors in UEFN and UE long term?

  • :white_check_mark: Is scene graph meant to be a runtime only or will it have procedural editor time creation capabilities such as for PCG editor time generation?

    • Can we build an editor time prefab that replicates instanced meshes along a spline component (this is extremely common in UE)?
  • :white_check_mark: Can we still use actors along side the new entities?

  • :white_check_mark: What type of mesh components will be supported?

    • Static Mesh Component (already known)
    • Spline Mesh Component ? (CRITICAL)
    • (Hierarchical ) Instanced Mesh Component ? (CRITICAL)
  • :white_check_mark: Will there be an easy way to convert actors into entities? (CRITICAL WORKFLOW)

    • It is common that a PCG spawned actor has multiple groups of HISM components with hundreds of meh instances. Converting those manually into scene graph entities and components is not feasible. A conversion from existing actors (not blueprints) to scene graph entities with components is almost a requirement, because copy pasting thousands of transform points and instances manually would become a nightmare otherwise.
    • Migrating existing pre-created and actor only geometry is extremely imported.
  • :white_check_mark: What about animations on scene graph entities and components?

    • Could we possibly animate individual instances of a HISM component?
  • :white_check_mark: How would entities behave in terms of world partition streaming?

    • Current FN devices are mostly fixed and not spatially loaded, therefore they consume an enormous amount of runtime memory. Will that change with scene graph entities and components?
  • :white_check_mark: Will the verse part of screen graph entities and components be eventually unit testable?

  • :white_check_mark: (CRITICAL) Will the scene graph allow for fine-grained runtime control such as:

    • spawning a mesh with or without collision and only make that mesh visible to player A but not B
    • showing a certain texture and or material on a mesh to player A but not player B
    • updating these effects to apply those to all players
    • auto applying effects from current runtime world states to players that joined the experience in-progress
    • general control on what the server replicates to which client would be great, because FN experiences are always online and we cannot have a client side persistent world state or client side non-replicating simulation (if player A sees player B going through a destroyable wall, it is simulated on player A’s client, but from the perspective of player B the wall might already have been destroyed)
  • :white_check_mark: Will scene graph entities support data layers?

  • :white_check_mark: Will entities and individual sub-components have states such as “visible / hidden in-game”?

  • Are there plans to calculate the cost of individual entities and performance impact analysis directly in the editor?

    • runtime memory cost
    • cooked size
    • draw calls?
  • Will the scene graph receive first class debug support?

  • :white_check_mark: Are there plans for editor time scene graph simulation (without a concrete running client)?

  • Why is the existing static mesh component limited to 0 to 1 material slots instead of 0 to N?

    static_mesh_component<native><epic_internal> := class(mesh_component):
      @replicated("RepNotify")
      # The path to the material asset of a static mesh
      var Material<native><public>:?material = external {}
    

    Meshes can have multiple material slots. This is either WIP, an oversight or a downgrade. :thinking:

3 Likes