Manage models in inexor-flex

[a-teammate]

This issue introduces several breaking changes, for the sake of:

• getting rid of cubescript
• moving management logic to node.js (aka "make things more flexible")

---

InexorFlex

Makes all the management logic: read the model configuration file, organize the models in your instance (playermodels, mapmodels, ...)
Basically you just use a list in the InexorTree afterwards to tell the InexorCore part which things it needs for loading the data to the GPU and rendering it afterwards.

Managment Logic Currently:

there are different configuration options for each format, some interchangeable, some not.
The plus point they share is (although a bit outdated) the cubescript API is relatively good documented in this area: http://sauerbraten.org/docs/models.html (formats: md2, md3, md5, smd, iqm, obj)

There is a .cfg for each model you want to load, named like the format of the model.
e.g. md2.cfg

This should change towards:

TODO (tomls, managers.. ideas)

InexorCore

On C++ side the model loading is one of the parts of the code one wouldnt want to touch.
Probably because the C++ code is not so readable (since the CubeScript bindings are not used directly, polymorphism is used without comments or clean structure, headers are not interfaces but really text
replacements and used as such.. all the usual sauer problems)

Well, we want to do that differently.
On C++ side you only need:
The models array. If you add new models to it, they need to get loaded.
Hence we want one single shared class (models).

We don't want to deal with different loaders when the managers should be giving us all we need to work in highspeed.

So we do it differently:

• we throw out everything except for a fast binary format which is fast to load and has a lot of features.
• We expect InexorFlex to provide us with that format.

The model format of choice seems to be IQM, as it got converters from all other skeletal model formats we have (md5, smd, obj) plus FBX (which is huge in the industry, but proprietary). Missing ones are md2 and md3 (both vertex animation formats, but as we never really used animation of those in the engine anyways.. the static mesh could be easily convertable)

The downside to this approach is, that people should make not only the IQM file available but also the blendfile/fbx-file/whatEverTheirModelingToolNativelySpitsOut.. which was used to convert to IQM.
But imo this is anyways necessary.

The upsides are:

• straight forward pipeline
  • you load in InexorCore IQM files, you convert to IQM in inexorflex
• config files in toml
• better managers possible in node.js

The downside is apparently that we need to provide a converter which doesnt feel like a pain in the ass for the users.

Libraries like AssImp are not really made for loading stuff fast, but for converters.
@Blarget2 and I hence brainstormed a bit about the needed features and arrived at IQM.
The problem is its lack of support and its non-ANSI codebase. If there would have been
a libiqm (lsalzman/iqm#14) it would probably be used outside of the open source world as well (currently warsow use it as standard https://www.warsow.net/forum/thread/t/215214).
Edit: blender IQM import plugin https://github.com/ccxvii/asstools

[Croydon]

The downside to this approach is, that people should make not only the IQM file available but also the blendfile/fbx-file/whatEverTheirModelingToolNativelySpitsOut.. which was used to convert to IQM.

They should do this already anyway: https://github.com/inexorgame/media-sources

The downside is apparently that we need to provide a converter

Agreed.

[a-teammate]

http://freegamer.blogspot.de/2012/07/dev-corner-inter-quake-model-format-and.html

[aschaeffer]

👍 for IQM

We could use Flex as a GUI frontend for the IQM tools btw