An Entity is a single static object in the world. It is based on an Object.

An Object is somewhat the Type definition for an Entity. When an object is changed, all entities that refer to this object also change. An object can contain a number of render elements, a number of collision meshes, and other things like maybe contact points, lights, …

A Mesh represents a renderable Model. A mesh can be used in different objects. A mesh can consist of parts using different materials. Can be imported from 3dsmax or created procedurally. The point of a mesh is to represent a collection of parts that together form some kind of visual object. If changes are made to the mesh, all objects using this mesh are affected. A mesh also binds materials to the parts.

A MeshPart represents a single piece of geometry (which can be rendered with one DrawPrimitive call). It does not contain any material info.
TODO: rename to Geometry or smth? EDIT: <color red>Now that this is also shared, this should be renamed.</color>

<graphviz center> digraph {

node [shape = box];

IMesh → MeshCoreData → IMeshPart; IMesh → MeshCollisionData; IMeshPart → MeshPartGeometryData; } </graphviz>

These interfaces represent the DataObject pointers. Their implementation is totally free, but the implementing object must be capable of representing the entire DataObject.

Currently contains all data for an Object, including a list of models (currently ModelFullData)

Factory for serializing the ObjectFullData to the WorldDatabase

This holds the very core data for this mesh. This currently only contains the references to the MeshPart DataItems. NOTE: this is a design quirk, and maybe if this happens more often (a dataItem containing other DataItems), support for this should be added natively in the WorldDatabase.

This contains extra info about the mesh: importer, imported date, modeler, etc.

This contains the core info about an object: which subparts it contains (ObjectSubpiecesData?)

Core Entity information

Contains stream sources. Every element of each source is part of one vertex. Every three vertices form a triangle.

Extra data

Helper class to create tangents from a mesh with position, normal and texcoord. TODO: this is not yet tested or used in any way

(ALLREADY deprecated!) Represents the core geometry of the model. Note: could be made uniform GeometryData

IMPORTANT! This design is similar to the design of the other Client Modules like ‘Terrain.Client’ and ‘Player.Client’

TODO: Implement the creation of the actor by using a Factory passed by the constructor. This moves the creation/caching/syncronizing logic to the outside. For a sketch of this implementation, see the Data System above.

This class uses an EntityFullData as input to produce a PhysX actor object that represents collision for the given entity. Currently this is done by creating a trianglemeshshape using the entity’s rendering triangles. This should be extended later on to allow simplified versions of the model or a collision model composed of boxes, spheres, convexmesh. These simplified versions should be build in the editor

Currently there is one PhysX actor per entity, and one PhysX shape per model.

There is some serious unwinding done concerning the scaling of entities or models. The scaling of model and entity is done directly on the model’s vertices for the TriangleMesh. So is the models local matrix. Remainder of the entity transform is stored in the global pose of the actor.

This class implements the IClientPhysics interface, thus representing a client physics entity. These objects are static by default. Support for dynamic entities should be implemented at a later time.

This is the main class for the application logic. It holds gui stuff and loads everything else. It also holds the data system.

There are no more FullData-classes. Data should be split in coherent pieces. The EditorObject performs the function of the FullData, by holding all the pieces (for editor use)

This class is still used in the old system. It should however become the Object DataObject for the Editor Data System

TODO: Editor meshes currently have no spatial information stored with them in the EditorObject

Represents a single renderable model, containing parts for different materials.

<color red>WARNING: You must call setChanged() if you make changes to the mesh, because otherwise the changes wont be stored to the db.</color>

Represents a single material part of a Mesh

Is responsible for converting a collada file, to a The Wizards Mesh, using Editor functionality.

Note: this class could be adjusted that it simply loads a colladaMesh as a mesh in the WorldDatabase, not referencing any editor logic. This might be unnecessary

<color red>TODO: A layer should be added to this class. There should be a class that reads the collada format and saves it into its own structure (which is equivalent with the current Data System structure). Then some other instance should copy it from the collada importer structure to the data system (Data System decoupling) Same goes for the OBJ importer.</color>

This class is responsible for loading, building resources and rendering an EditorMeshPart.

Note that this is a shared resource, it can be used in different meshes at the same time

This class is responsible for loading, building resources and rendering an EditorMeshPart.

Note that this is a shared resource, it can be used in different meshes at the same time

This class also requires material creation, so it should have access to some methods of the render system.

• FullData objects are no more! Split in coherent pieces of data. FullData objects are only used in the editor, by using the Editor Data System
• All Mesh – stuff, doesn’t really belong here.
• Maybe Material should be added?