Croydon
commented
6 years ago 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
aschaeffer
This issue introduces several breaking changes, for the sake of:
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:
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:
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 (https://github.com/lsalzman/iqm/issues/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