We should define a format to export/import data from/to binary resources.
The format should be platform agnostic (even if we only support PC resources for now)
The format should be modular (pgBase blocks can either be root of a resource or embedded into another resource)
The format should use an easy syntax to be easily parsed by third party tools (like a Blender I/O plugin)
Format
Software
Language
Specs Available
Modular
Verbosity
Binary Buffers
openFormats
OpenIV
proprietary
No
Yes
Low
No
CodeWalker XML
CodeWalker
xml
No (but open source)
Somehow
High
No
openFormats
openFormats seem a valuable format although it has no public specs and everything is strictly coupled to openIV software, it only supports a few rage resource types and furthermore it has some few little inconsistencies:
how many attributes can a node have?
why sometimes an array has a count attribute but sometimes it doesn't?
CodeWalker XML
CodeWalker XML on its side supports almost all the rage resource types, but it's very verbose and very inconsistent.
Another format to consider could be glTF (either json or binary) which is easily extended using "extensions" so any software which already handles glTF will only need a plugin to handle extensions for the rage engine specific data, in addition it also supports external binary buffers.
Although has still some limitations which would require too many work on extensions and currently it only supports a Y+ up coordinates system by design which would require to transform bases of all the transformations data in rage formats on export/import.
We should define a format to export/import data from/to binary resources.
openFormats
openFormats seem a valuable format although it has no public specs and everything is strictly coupled to openIV software, it only supports a few rage resource types and furthermore it has some few little inconsistencies:
countattribute but sometimes it doesn't?CodeWalker XML
CodeWalker XML on its side supports almost all the rage resource types, but it's very verbose and very inconsistent.
Another format to consider could be glTF (either json or binary) which is easily extended using "extensions" so any software which already handles glTF will only need a plugin to handle extensions for the rage engine specific data, in addition it also supports external binary buffers. Although has still some limitations which would require too many work on extensions and currently it only supports a Y+ up coordinates system by design which would require to transform bases of all the transformations data in rage formats on export/import.