Scene and EC Model

Jonne Vaisanen edited this page Sep 14, 2016 · 13 revisions


Scenes are identified by their name (ID possible in the future, if wanted/needed). Currently only the first created scene is replicated and the rest of the possible scenes are local. Scene consists of 0 to N Entities.


Entity itself has no data whatsoever and is identified by a unique ID number. Entity can be local (non-replicated) or replicated. Entity can also be temporary (not saved to disk by default when the scene is saved). Entity consists of 0 to N Components.


Components can be added to any Entity in the scene. The components define the functionality/behavior of the Entity. Component (Entity-Component, EC) consists of 0 to N Attributes. Component can be local or replicated.


A Component consists of Attributes. Each attribute has an ID (string) and a type. Once this structure is defined it can automatically be synchronized over the network, whatever the structure may be, without doing any networking code / message definitions to the components implementation. For more on the network synchronization refer to the realXtend Tundra protocol.

The components listed on this page are not a full list of available components in Tundra, but a list that will be relevant in brainstorming the XML3D integration. For a full list of components, refer to the Tundra class reference.

Creating new components

The Tundra component system is extendable, so anyone can define a component and add it to the system. Usually outside of the Tundra core SDK this happens by loading C++ plugins during runtime that declare/register the component structure to both the server and client.

Entity Action

Entity Action represents an executable command on an Entity. Components can register to listen specific actions by using Entity::ConnectAction(). Actions can be triggered by Entity::Exec(), where the following parameters are passed:

ExecType: defines where action is executed

  • local: Self
  • server: Hosting server
  • peers: All clients exept me

i.e. we can use local+server (self and server), local+peers(all clients but not server), server+peers (everyone except me), and local+server+peers (everyone).

Id: String id that entity uses to identify what action needs triggering

Parameters: are passed as string array

List of Components



  • Adds a non-unique name for an entity. This can be used to query scene for Entities. Description and group can be used by application logic to create groups and define metadata (lighter alternative to using DynamicComponent)
  • Main attributes: name (String), description (String) and group (String).


  • Special component of which structure is not statically defined, but can be defined during runtime. This is useful on script logic to store custom data for the application and have it persist in the scene state.
  • Main attributes: defined during runtime, all 17 attribute types are available.



  • Adds this Entity to the rendering scene graph by creating a scene node to it.
  • Main attributes: transform (Transform: pos, rot and scale vectors) and visibility (Bool).


  • Defines the visual 3D mesh resources and surface materials to be loaded.
  • Attaches itself to the parent Entity's Placeable component's scene node.
  • In addition to the mesh resource defines list of materials that tell the rendering about mesh surface properties (ambient, diffuse, emissive, specular colors + textures + potential shaders).
  • Main attributes: meshRef (AssetReference), meshMaterial (AssetReferenceList).


  • Adds a camera/viewport to the 3D rendering. Usually this component is created locally on the client by (script) application logic.
  • Attaches itself to the parent Entity's Placeable components scene node.
  • Main attributes: FOV, near- and farclip (Real).


  • Adds a light source to the 3D scene.
  • Attaches itself to the parent Entity's Placeable components scene node.
  • Main attributes: Diffuse and specular color (Color), type (Number/Enum: Spot, Point and Directional), range (Number), brightness (Number), attenuation(s) (Number).


  • Adds a particle system/effect to the 3D scene. The particle system will be loaded from the specified asset reference.
  • Attaches itself to the parent Entity's Placeable components scene node.
  • Main attributes: particleRef (AssetReference: points to a supported particle asset) and visibility (Bool).


  • Adds a "2D" sprite type billboard to the 3D scene. Surface material defined similarly as the Mesh component does, references to a material file.
  • Is part of the 3D scene but always faces the active camera.
  • Attaches itself to the parent Entity's Placeable components scene node.
  • Main attributes: materialRef (AssetReference), position (Float3: relative offset from Placeable), size and visibility (Bool).



  • Adds a skybox to the scene. There are multiple sky component from skybox to more comple dome with volumetric cloud rendering etc.
  • Main attributes: materialRef (AssetReference) or a list of textures for the cube map and sky box size.


  • Adds water to the scene. There are multiple water components from water plane to complex real-time water rendering.
  • Main attributes: water position/height and size.

Extra Visuals


  • Creates a web browser (with 3D input etc.) render to the mesh surface (replacing the original material in that submesh).
  • Main attributes: url (String), resolution (Float2), accept3DInput (Bool) etc.



  • Defines a script resource that should be loaded and executed.
  • Main attributes: scriptRef (AssetReference), runMode (Int/Enum: Server, Client or Both), runOnLoad (Bool: if should be execute after load completes. If false application logic can execute the script.)



  • Adds a rigid body object to the physics simulation world for collision & dynamics response. On the native Tundra client/server, the physics simulation world will always be created along with the scene if the PhysicsModule plugin is loaded. Web client does not currently simulate physics.
  • If the rigid body is dynamic (mass > 0), the position & rotation in the entity's Placeable component will be updated after each simulation step
  • The collision shape of the rigid body can either be a primitive like box, sphere, capsule, cylinder, or derived from rendering mesh data (trianglemesh or convex hull). The size attribute and the scale from the Placeable's transform are combined to find the final size for the collision shape.
  • Main attributes: mass (Real), friction (Real), restitution (Real), linearVelocity (Float3), angularVelocity (Float3), shapeType (enum Int), size (Float3), collisionMeshRef (AssetReference)

For a more comprehensive list, see


List of Attribute types

This is the mapping of attribute type id to the type name of the available attribute types in Tundra.

  • 1 : String
  • 2 : Int
  • 3 : Real
  • 4 : Color
  • 5 : Float2
  • 6 : Float3
  • 7 : Float4
  • 8 : Bool
  • 9 : UInt
  • 10 : Quat
  • 11 : AssetReference (1)
  • 12 : AssetReferenceList
  • 13 : EntityReference (1)
  • 14 : (Q)Variant (2)
  • 15 : (Q)VariantList
  • 16 : Transform (pos, rot and scale vectors)
  • 17 : (Q)Point (pair of signed integers; pretty much unused/deprecated, use Float2)

(1) Essentially a string but has different semantics and additional type information and possible functionality.

(2) QVariant is a Qt class the encapsulates arbitrary types (a single value of a single type at a time). Over the wire these are always just converted to a string. Typically f.ex. a QVariantList Attribute is used for list of integers or strings. This is not a relevant type to support from a generic design standpoint.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.