Hacker News Reader

Comment by aphextron | Hacker News Reader

I think beyond even VR, just having this standard markup language for building 3D scenes is amazing. My biggest gripe over modern game engines is the lack of a programmatic means for building scenes. You always end up with massive proprietary binary “scene” files that are a pain to put in VCS.

View on HN

This is a necessary evil unfortunately. When loading 3D content from disk, every cycle counts. Therefore storing and parsing this content in plain text is just too inefficient. A number of 3D scenes are quite large in size as well, and benefit highly from compression.

This is admittedly a naive question— but wouldn't something between the two work well? (A-Frame is arguably akin to that already)

A 3d markup language that can be compiled? At least for prototyping, it might be useful, no?

Does that exist? Or is it a problem that's already been tossed around and buried?

This exists, it’s very common to have a human readable format for development and storage in version control that gets converted to a binary format for release. What doesn’t really exist is a common inter-engine format.

VRML ?

https://en.wikipedia.org/wiki/VRML

Lots of common formats exist for scene data just very few of them are actually used by game engines in a manner that would make them somewhat interoperable.

Probably most the most commonly shared is something like the Tiled TMX format for tilemaps.

I guess Blender Python scripts come kind of close to this, but that's not really a markup language. (And 3D Modeling not a game scene file)

How about glTF? It's a JSON based scene description which uses inline data or references to external binary files, with an option for a single binary "glb" data file.

https://github.com/KhronosGroup/glTF

https://github.com/KhronosGroup/glTF/tree/master/specificati...

glTF is already gaining some traction as a model format. But it’s scene support is more what you’d see for modelling software than what you’d have for a game engine where the scene description is more about the game entities and the data glTF provides is usually abstracted out.

glTF is a great idea for providing a sensible interchange format for models though. Even this data usually gets converted into a custom binary format for the runtime engine to consume depending on use. Although as you note glTF has its own binary format and I understand it’s going to be improved with support for compression like Basis so perhaps that will reduce the need for custom formats for all but the most optimised cases.

You're probably right, at least for the near future. There's another A-Frame article about how to make an immersive game with low-poly models. https://hacks.mozilla.org/2018/03/immersive-aframe-low-poly/ If you're really pressed for size though, you can combine binary coding on disk with A-Frame, as Platane did in Vernissage. https://hacks.mozilla.org/2018/01/lessons-learned-from-the-a...

Why not just compile the thing? Textual source code for authoring, optimised binary for execution.

We do this for executable code, is there any reason why we shouldn't do this for assets as well?

I’ve worked on 3D pipelines that did just that. The text format was even, gasp, XML! As long as the large arrays were large strings of numbers and not individual nodes per component, it was actually pretty efficient and very fast to convert.

This is essentially what three.js does with WebGL content. Using JSON;

https://github.com/mrdoob/three.js/wiki/JSON-Geometry-format...

Everything old is new again...

https://en.wikipedia.org/wiki/VRML

Hey, one of the A-Frame creators here. Looking past the markup, A-Frame is closer to a Unity-esque web framework (based on ECS) than a standard declarative file format. An ECS-based three.js framework that has some DOM flavor. Developing with it sort of feels similar to Vue.js.

Unity scenes are stored as yaml in the project, and are only baked to binary for built executables.

Reply on news.ycombinator.com