Uh. You want to store assets in JSON? Why? You generally want asset packs to be seekable so that you can extract just one asset, and why would you want to add the overhead of parsing potentially gigabytes of JSON and then, per asset, decoding potentially tens of megabytes of base64?

▲

embedding-shape 4 hours ago | parent | next [-]

> You want to store assets in JSON? Why?

Why not have both options? .gltf and .glb being possible for assets been more than helpful to me more than once, having the option gives you the best of both worlds :)

	▲	mort96 2 hours ago \| parent \| next [-]
		What's Apple's incentive for having two different asset pack formats? It seems like more work to support parsing and generating both, and Apple expects you to use their tools to generate asset packs. Working with binary files really isn't that hard. If Apple documented the .car format, writing your own parser wouldn't be difficult. It's not like it's a complicated format. Still, Apple clearly doesn't intend for people to make their own .car generators; to them, ease of reverse engineering is a bug, not a feature.
	▲	3 hours ago \| parent \| prev [-]
		[deleted]

▲

silvestrov 4 hours ago | parent | prev | next [-]

Keep all the meta info in JSON and then the big binary files in a zip file. Much easier to parse.

	▲	mort96 2 hours ago \| parent [-]
		Easier for the developer or easier for the computer? Computers need to do it a bunch for every program launch for every single user of macOS for decades. The developer just needed to write a generator and a parser for the format once. Would it have been a bit easier to write a parser for a format that's based around a zip file with a manifest.json? I don't know, maybe. You'd end up with some pretty huge dependencies (a zip file reader, a JSON parser), but maybe it'd be slightly easier. Is it worth it?

▲

ape4 4 hours ago | parent | prev [-]

Someday JSON will be out of fashion - like XML is now.