Initial import of rendering / modelling formats

[hakanai]

Imported from my organisation's repository.

Since this is a new directory - is "rendering" a good name for this stuff? In IANA, these formats are classified as just "model", but the word has too many different meanings in software.

About these formats:

FBX - "Filmbox" format originally by Kaydara, now owned by Autodesk, standard interchange format between modelling software and game engines and the like.

GLB - Khronos group's standard binary format for model exchange. But unfortunately a terrible format for Kaitai. I implemented it as far in as was possible anyway.

The above two file types can be created using Blender. (Actually, Blender's own format is one that I want to take a look at as well.)

PMD, PMX - Model formats used by animation software MikuMikuDance (PMX newer, PMD older), many samples can be found on bowlrowl and similar sites.

VMD - Animation data format used by MikuMikuDance.

[KOLANICH]

Maybe kaydara_fbx?

[hakanai]

Should I be changing the filename to match? I notice the generated code ends up using this ID as the classname instead of the filename of the ksy. (Sucks that we have essentially the same info in two places...)

[KOLANICH]

Looks unfinished.

[hakanai]

In what sense? A GLB file is made up of data chunks. The chunk can be either a JSON chunk or a binary chunk. This is a binary chunk. There's no way to know what sort of data you're looking at in here though, because, for that, you'd have to first parse the JSON to get the offsets out of there.

[KOLANICH]

Please look at https://github.com/kaitai-io/kaitai_struct_formats/pull/183/files#diff-ce5a8a6f65e08325535c534e8222ecbd9f53a9749ba538b04cf857b5b07a0795R89 and https://github.com/kaitai-io/kaitai_struct_formats/pull/213/files#diff-35cf895592a530eee852a5354aaa16e650100fdfddb1e81752f7e6d0ef036786R115

for the ideas how one can try to solve the issue of having data in some another format.

[hakanai]

Neither of those appear to actually solve the issue, but rather push it out to a single-language solution, which doesn't really fit with the spirit of Kaitai anyway.

What would be nice is a native JSON type in Kaitai, so that we can then just traverse into the tree of JSON objects.

So I guess one valid solution is, define a new format for JSON and import that format, so we can declare the type of this piece as json. And then say that implementing the JSON format is up to the reader. LOL

[KOLANICH]

Neither of those appear to actually solve the issue, but rather push it out to a single-language solution which doesn't really fit with the spirit of Kaitai anyway.

I completely agree.

What would be nice is a native JSON type in Kaitai, so that we can then just traverse into the tree of JSON objects.

It would be nice to have KS extensible, because blessing JSON over other serialization formats, including custom ones, is incorrect. And the impl still will be language-dependent. The same way as runtimes are and KS itself is. All of this is just an abstraction layer around languages.

So I guess one valid solution is, define a new format for JSON and import that format, so we can declare the type of this piece as json. And then say that implementing the JSON format is up to the reader. LOL

So a valid solution is finishing and landing interfaces proposal first, and then standardizing some interfaces and creating a standard library for each interface. See the discussion in kaitai-io/kaitai_struct#457 .

[hakanai]

I wasn't saying that json would be the only format to implement, nor was I saying that json would be implemented by kaitai itself. I was just saying that we could implement a placeholder 'type' for any given unknown type, and then how that's implemented is up to the future. If the future happens to be some interface where the type is converted to something else using external code, that's fine. If someone figures out how to complete a kts file for json, that's fine too.

[hakanai]

Closing as I'm splitting into multiple PRs as previously discussed.