New models format

[tomangelo]

As you know, current model format is very old and insufficient for our goals (easy modding, skeleton animations). Many things are hardcoded in game engine, so currently modding is almost impossible.

Of course we could use some of existing formats, but:

• we need to move as much as possible from code to model files (so it must be something better than just mesh file)
  
• it should be easy to update (when someone wants to change the wheel model in bots, then it would be better to modify one file instead of modifying every model that contain wheels)
  

There might be an idea - making one in-game file from parts files by assembling them with an converter. Parts files would be in anyone format that support animations and anything else. But how converter would like to know how it should be placed? It would use a text file, with describing all properties, like lights, health points, animations (simple ones, rotating, moving, like it looks like in our code), etc. It could allow us to move as much as possible from code to model files, leaving only loading code and some things that wouldn't be possible to implement in this way.

I'm working on how would this file look like, for now I've got something like this (still WIP, but I want to know if this idea makes any sense) :

Spoiler :

It all base on our current model specification, so it doesn't contain information about crashspheres, or textures.

Code:

// Lines started with these characters are comments

Header
//There are all properties of final model

frames [x] //amount of total frames for animations
is_destructible Y/N
models n //optional parameter, if implementing this format would require to know how many source models will be included in final model before converting.
lights n //like above

Lights
//There you can set where lights will be placed. Also you can change their color, power, direction etc. By default, they're set to light forward
Light [x] [y] [z] [ID] [color] [power] [type] [additional parameters] //color may be defined in hexadecimal number; types described below; ID is related to parent/child points, so it allow us to make light source that will move with model while animation.

//Available types:
//Point - small, shining point
//Sun [sx] [sy] [sz] - shining ball, you can set scale for ball
//Cylinder [rx] [ry] [rz] [s1x] [s1y] [s2x] [s2y] – Light pole, you can set rotation of cylinder and set scale for both ends. 2 lasts parameters can be optional, so we'll get cone-sized light, as one end will be size=0.

Models
//Importing models from files

//Main model
//Note: first model is always master model, it's placed in local coordinates 0,0,0
file filename.txt
child [ID] [x] [y] [z] [rx] [ry] [rz] [sx] [sy] [sz] //create new child point and set it initial position/rotation/scale. There will be locked child model to this parent model. ID should be unique
animation [sf] [ef] [mx] [my] [mz] [rx] [ry] [rz] [sx] [sy] [sz] [sound] //sf - start frame, ef - end frame, m - move, r - rotate, s – scale, sound – sound that will be played over animation.
//if we'll import model with embeded animations, then we can pass move/rotate/scale parameters as 0.

//Second model
file second.txt
parent [ID] //linking child model to parent model
//Non-master models can have child models too.


//Parent/child points should be able to move, if we're rotating arm, then points on arm should be moved too.

How would look like all this process?

In this example we'll build a WheeledGrabber bot.
At first we'll need to know what models we'll be using. We'll need body frame as main model, 4x wheels, 2x arms, also there are 3 tool models. Also we'll use some lights.

So our file would look like this:

Spoiler :

Code:

Header

frames x
is_destructible Y
models 10 //like I said, it's optional to implement
lights 4

Lights

Light 10 1 -2 #FFFFFF 1 cylinder 0 100 0 0 0 4 4 //left front bulb, cone-sized ray
Light 10 1 2 #FFFFFF 1 cylinder 0 100 0 0 0 4 4 //right front bulb, cone-sized ray
Light -10 1 -2 #FF0000 1 sun 0.2 0.2 0.2 //left rear bulb, it may be even replaced with point-type light
Light -10 1 2 #FF0000 1 sun 0.2 0.2 0.2 //right rear bulb

Models

//main body
file body.ext //whatever extension we'll use
child 1 8 0.2 -5 0 0 0 1 1 1 //left front wheel
child 2 8 0.2 5 0 0 0 1 1 1 //right front wheel
child 3 -8 0.2 -5 0 0 0 1 1 1 //left rear wheel
child 4 -8 0.2 5 0 0 0 1 1 1 //right rear wheel
child 5 0 3 0 0 -15 0 1 1 1 //arm #1
//second arm will be connected to first arm

//L F wheel

file wheel.ext
parent 1
animation 30 45 0 0 0 0 90 0 1 1 1 "drive.ogg" //driving forward; frames numbers are only for example
animation 45 60 0 0 0 0 -90 0 1 1 1 "drive.ogg" //driving backward
animation 60 75 0 0 0 0 0 40 1 1 1 null //turning right, null means that there is no sound in this animation

//L R wheel

file wheel.ext
parent 3
animation 30 45 0 0 0 0 90 0 1 1 1 "drive.ogg" //driving forward; frames numbers are only for example
animation 45 60 0 0 0 0 -90 0 1 1 1 "drive.ogg" //driving backward
animation 60 75 0 0 0 0 0 -40 1 1 1 null //turning right, but rear wheel need to turn left

//and so on

file arm.ext
parent [5]
child [6] 0 2 0 0 90 0 1 1 1 //keep in mind, that there are relative coordinates to this mesh,
//at first, "youngest" childs are placed/rotated/scaled by this child lines, next there are placed/rotated/scaled their parents along with childrens, and so on
animation 90 105 0 0 0 0 -45 0 1 1 1 //grabbing, in this case rotating arm, all child models need to be rotated along with this arm
//second arm and tools will be placed in similar way

This will be both with model files converted to in-game file.

This still need to be detailed, also there are still features that must be included. I just want to know if this makes any sense, if this is even possible to implement and if it's worth to work with that or I should just reject this idea and try to figure out something better.