You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 11, 2020. It is now read-only.
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
The text was updated successfully, but these errors were encountered:
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.
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 (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
The text was updated successfully, but these errors were encountered: