Mangalore
3D GUI
Entities & Persistence
Entity ID's
Mangalore level DB
 
Diverse Jme Mangalore Nebula Project1 Project2 Tabletop

Mangalore Level-Db

This document is based on the experience I made while working with the managlore database files (.db3) needed for a level configuration. It was written as a short summary without being complete or eventually not being completely correct.

For a level in mangalore you will need to export something to display, Entities will be exported one by one (already known from nebula 2 as .n2 files). They are only referenced in the mangalore db file for further use and enriched by several other files for certain purpose for which I will give a short overview first.

Files and directories used

The following paths are relative to your development directory. For XML files please keep in mind that the files are parsed line by line, so saving an XML file as a character stream as some tools (open office has an option somewhere) do will break them for mangalore. The files you need for a level besided the world.db3 are (as far as I have used them or know something about):

data\tables\blueprints.xml

The definitions of your entities are stored here (which property is used on which entity type) thus influencing which attributes/columns will be used on your entity and stored in the _entities table in the world.db3 file. The file is readable with a notepad as it is normal xml.

data\tables\anims.xml

Not used so far by me. The file contains animation information, you should enter the level amations (perhaps for elevators uand such?) here. The file is an ms office xls sheet in xml format, readable with open office (if you remove the cell checks entries)

data\tables\sounds.xml

This file contains a listing of sounds used in your game. The file is an ms office xls sheet in xml format, readable with open office (if you remove the cell checks entries)

In my opinion all the files above are bulllshit and should be moved inside the .db3 as database tables. This would need some refactoring for the access classes but it would be more consistent to have all configuration in your database and not have one configuration no matter how many .db3 files you have :-(

export

In mangalore it is important that all path entries referenced from the db file are made up of a directory and a file entry (e.g. examples/myn2file), the loader uses the directory entry to group the files into catgories. The file entries in the orld database are normally omitting the file ending. So when you export your game assets you should always place them in a subdirectory, examples are following:

export\anims

The animation sequences of your models are stored in this directory as .nanim2 files for example: examples\eagle.namin2 or myobject\my.nanim2

export\gfxlib

The standard .n2 load files are situated in this directory, they are used in the db file for model loading. The files must be in a subdirectory e.g examples\eagle.n2 or myobject1\my.n2

export\meshes

The nebula mesh definitions (.n3d2 or .nvx2) are inside this directory. The files need not to be placed in subdirectories (but it helps) as long as your .n2 file points to the correct mesh. The files herin are not referenced directly from the db.

export\physics

In this directory the physics definitoins for your level entities are stored. Again the files must be in a subdirectory for example myobject1\myobject1_physics_representation.mxl. Physics definitions are xml files which are not really suited for manual editing if you have complex physics objects.

export\textures

The nebula textures are found inside this directory. The files need not to be placed in subdirectories (but it helps) as long as your .n2 file points to the correct mesh. The files herin are not referenced directly from the db.

export\db

Normally only one world.db3 file exists (but your custom coded games could use several). The file contains three tables per default:
_categories, _navigation, _entities

The .db3 world file

All entries regarding positionining are expressed in world coordinates. Thus all models should be exported around world center 0/0/0 or otherwise you will have to live with the offset beween local and world coords.

Table _categories

This table describes again the entities from blueprints.xml, I am not sure if this information is used or really needed anywhere in mangalore as the blueprints are parsed from the xml file on start.

Table _navigation

I have not used this table so far, but guessing from the fields it is a simple listing of navmesh file and its position in the world (transform see _entities)

Table _entities

This is the table I use most. The important columns are _type, gui, _id, _level, _category, _transform, graphics, but that only could be my special case. Following is a description of the fields you find in the standard .db3 file. If you create your own properties new columns will be created when you are saving your entities and these propertiy attributes are configured as storable. Only writable attributes/columns get updated, these are only very few (like transform, etc.).

Column _Type

Stores if the entity is an INSTANCEor a TEMPLATE object. This is only neccessary if you are creating objects by code (createbytemplate). INSTANCE objekts are loaded as default for you level.

Column guid

This column is a (hopefully) global unique id string, you could enter any bullshit as long as it remains unique as it seems sqlite does not support unique constraints.

Column _id

A name string identifying your entity.

Column _level

This entry defines to which level instance this entity row belongs as you could have several levels defined in your .db3 file

Column _category

This entry is quite important as it determins which entity loader and entity template is to be used. Aktually the following categories exist: Actor, Simple, Light, Camera, .Level, _Environment

Actor is used for controllable entities, Simple for simple physical (optional) entities, Light for (guess) lights in your level, Camera for cameras as you can toggel between several cams in your level, .Level (please obey the dot) for level roots (one entry only per level) and finally _Environmentfor the static content (physics optional) in your level.

Column transform

Importent column used for placement of entities in world coords in your level. Format is a4x4 matrix which means 8 floats comma separated analog to the normal nebula matrix used in code.

Column lighttype

The string Point, Direct, Omni (or Ambient?)

Column lightcolor

rgba, 4 floats comma separated

Column lightrange

range of light :-) one float

Column lightambient

rgba (4 floats, comma separated) if row defines an Omni light empty otherwise.

Column lightcastshadows

true or false dependant upon the lightsource being used for creation of shadows or not

Column animpath

File containing an animation of the model, seems to be level animations, have nothing in common with the normal .n2 files (kyla for example has no entry but has animatin sequences) used for elevators, trains or similar.

Column graphics

String entry directory/filename_withoutn2ending from the export\gfxlib directory representing the graphics of the entity (mesh, tex, etc.)

Column center and extents

As far as I know this entry is only used for a .Level entry; center is the middle of the level, extents is the distance the level extends into x,y,z in world coordinates. Each one as 3 floats separated by spaces

Column id

Not really important, most of my levels run without this entry

Column placeholder

Don't know what this is for

Column LE, AE, AT, PA

This already introduced the stats of the RPG game the dark eye (Das Schwarze Auge), not used by this code, columns can be deleted.

Column name

Another descriptive entry, ev. for ingame, but not really needed

Column animset

Entry from anims.xml which model animations to use

Column inputfocus, camerafocus

true or false depending on the fact if the entity can have inputfocus or camerafocus makes only sense on actor or camera entites

Column maxvelocity

Velocity of the entity, float

Column fieldofview

FOV value (camera viewport angle), float

Column time

Not really important for level creation, will be updated on save

That's it, hope it has shed some light on the what and where of the nebula/mangalore level file world.db3



Something missing? Mail to cc


2009-06-01
WoW Importer for Max
The World of Warcraft tool for 3D Studio has been updated. It now converts model files from WoW Client version 2.x (upto 2.7) and displays correct animations for multi mesh models. The script can be found here....
2007-03-07
nGUI explained
If you ever wanted some more details on the nebula2 nGUI System you can find it in the nGUI System article.
2006-10-17
Mangalore entity ID's
If you need information about the mangalore entity ID usage have a look here..
2006-08-06
Mangalore Articles
Added a new section about the mangalore game framework from radonlabs. The section contains some articles about my experience with mangalore. Read more here:
2006-03-10
Free models
Finally some free models for the Radonlabs SDK. You can download them here.