It's explicit on how an object is represented (there's no room for interpretation, unlike collada for example), and it's free, standard, and open (unlike FBX that is autodesk's stuff). GlTF is at the sweet spot between an easy to use format. Textures are any image format you may like, and metadata are JSON objects. But, texture format aside, and metadata, glTF is literally in the same format you'll upload and describe data to the GPU in OpenGL. mesh will load faster than anything else because, as far as I know, it's a direct serialization of how Ogre loads the file in memory.
blend) that will not be present in a glTF file. There are a lot of information that other format made for authoring (like collada, fbx or blender's. I'm not saying glTF "everything", I'm saying glTF as the transfer format (it's desinged for that). We simply lack a robust and well supported way to do that first step in Ogre.
OGRE ENGINE PARENTING OFFLINE
Even then, having offline editing be done through more versatile formats and then saving to native for the live version seems to be the best of all worlds. Keeping things in the native format may have performance benefits when loading. I don't think glTF everything is the best way to go, although I could be wrong. Goal is that you can stash your glb or gltf files in your resource locations, and just call a "loadGltfMesh" somewhere that will give you a (v2 only) mesh with it's materials, textures and animations to then use and create an Item in a scene manager. For now, the importer is designed in a way where it will look at the first mesh it can load, and only load that.
Finishing the mesh loading, the animations, and the integration with Ogre's ResourceGroupManager is way more important for me than loading a "scene" from glTF. mesh files with their local position/rotation/scale in a tree that represent the scene manager and it's nodes.) That was the purpose of the old ".scene" format (a big XML file referencing. But I also see some people that would want to use something like blender as a makeshift "level editor". You are on the same wavelength with me for the scene representation stuff.
Personally, I'd ignore any scene related features if you were to implement them. Especially with Ogre it's more likely that people will construct their own scene formats for the engine they use Ogre in, rather than rely on something external that is oblivious to the capabilities of said engine. I think the scene aspect is needless and safe to ignore. I'm pretty much of the exact same mindset for most of what you mentioned. mesh files to use glTF with a standard PBR workflow, with the official glTF exporter for Blender. I plan to switch an ogre powered game-engine completely from using. In any case, I'm happy to see that people are interested in my little importer.
I am less interested into using glTF as a "scene" representation (it can do it, it even has support for lights and cameras)
OGRE ENGINE PARENTING SOFTWARE
This file format feels, at leas for me, like the better way to exchange 3D assets from a modelling software to a game engine. Main goal is to be able to load "meshes" but in glTF binary format (.glb files). Maybe make it a plugin, or just a library where you call a function once to initialize it, and then pull the glTF files from Once it's done, there will be a bit more work for making this integrate more "seamlessly" with Ogre. I had a few rough months with my studies so I haven't had the time to get back to it since January~February. I am still working on the animation support in the glTF thing.
0 kommentar(er)
