[2.1][Addon] glTF loader plugin for Ogre v2-1

[Ybalrid]

Hi guys!

So, I've been talking about this in a few topics here and there, but I'm working on a plugin that allows user to load glTF 2.0 files into Ogre, complete with their PBR material (relying on HlmsPbs obviously!) and animations. Since it's is almost at a usable stage, I think I can create my own here, like, to do a proper little announcement!

The current goal is to allow users to use (binary) glTF files files in lieu of the good old .mesh format. I know a few people are interested into that idea, and it could make the workflow from taking objects made by artists on 3D software, or getting assets found online, into Ogre. And doing so using an industry standard file format.

This is free and open source software, available under the MIT license, like Ogre itself.

This plugin, is NOT a scene loader. It load meshes from glTF files, not a hierarchy of objects

So, today, I'm releasing a first alpha, and I need people to break test it!

Release history:

• 0.2.1 : Add support of Draco compressed meshes
• 0.2 : Fixes, alpha in materials, multi material objects, and local transform loading are now supported
• 0.1.1: Added methods to glTF interface to get the v2 Mesh object and datablock instead of just an item (idea from a remark by @dark_sylinc)
• 0.1: first release

Here are the relevant links:

• Project management in my Phabricator : https://phabricator.polutropon.games/project/view/4/
• Github (because free bandwidth... ^^") : https://github.com/Ybalrid/Ogre_glTF
• Github releases : https://github.com/Ybalrid/Ogre_glTF/releases/
• Website : https://ybalrid.github.io/Ogre_glTF/

Once the source code is built, you'll get a dynamic library called `Ogre_glTF`. This library can be loaded as a Plugin DLL into Ogre. There's a Zip with everything built on Visual Studio 2017, in the release page, but it's pretty straightforward to get everything working from source.

You need to add the headers in the /include directory to your project. Either point your compiler to that directory, or copy them directly.

Then, once the plugin as been loaded and installed by Ogre, you can do the following to get a pointer to a glTF loader object:

Code: Select all

	glTFLoaderInterface* glTFLoader = gltfPluginAccessor::findPlugin()->getLoader(); 

This will actually search inside the installed plugin and grab the correct one, and give your a pointer to an interface defined in the headers you added (glTFLoaderInterface). Store that pointer somewhere to not have to "find" the loader again.

Put simply, if you put a .glb file into your resource group, you can do this :

Edit November the 2nd, 2018: Sample code in this post updated to reflect version 0.2's new API

Code: Select all

	//Get access to the gltf loader, and load a GLB file in the resources to an item
	//This actually search through the list of installed plugin, keep that pointer somewhere convenient
	auto glTFLoader = gltfPluginAccessor::findPlugin()->getLoader(); 

	//You can create an Item for a scene by giving the name of the GLB file to look for in the resources
	Ogre_glTF::ModelInformation model = gltfLoader->getModelData("myGltfFile.glb", glTFLoaderInterface::LoadFrom::ResourceManager);
	Ogre::Item* myItem = model.makeItem(mySceneManager);

You may need to get the local transform of the object, the "transform" member of the ModelInformation structure you got from the loader contains the position, orientation, and scale to apply to a node.

Code: Select all

	itemNode->attachObject(myItem);
	model.transform.apply(itemNode); //apply the local transform

That's it! You could also hard-link to the library, and manually manage it. the "test" program does that on the repository, but the goal is to use the Ogre plugin interface, and have the simplest API possible!

I'm open to any questions, suggestions, bug reports and pull request on the GitHub repository, or in this very topic!

[al2950]

Awesome

[Zonder]

Awesome

+1

[Ybalrid]

Hey, I'm happy you like it

And now I started using my plugin in my own Ogre powered projects, one of the sample files is a 3D model of an avocado:



I didn't have much time to play with it (There's a few things I need to try - I have BtOgre21 and Bullet running here, I need to check if it can properly generate a rigodbody from the geometry of a 3D object here. Shouldn't be an issue, but we are never too prudent ) but everything seems to work "just fine".

I am no 3D artist, and I haven't touched blender in a while, but there's a official exporter that I need to play with. There's also a lot of other tools to manipulate glTF files (collada -> glTF converter, things along those lines).

Also, currently, I'm not really supporting having multiple meshes inside one .glb file, I need to get around this down the line. but as a "alternative" to using .mesh files, it is certainly usable, and it does pack-in all of the textures and the .material and .skeleton files you would have to carry around!

[xrgo]

This is one of the greatest things that happened to ogre in the last time.
Very good work!

[Ybalrid]

Awesome

+1

This is one of the greatest things that happened to ogre in the last time.
Very good work!

You are too kind guys ^^"

[Zonder]

Would be good to do some performance comparisons against .mesh at some point on loading.

[Ybalrid]

Would be good to do some performance comparisons against .mesh at some point on loading.

glTF will probably be slower: .mesh is *the* format for Ogre, it's an Ogre::mesh serialized to disk. Probably not that much slower tho. But I hope the convenience factor will make the difference in speed "not that significant". And beside, when you're loading, your loading. It doesn't really affect engine performance, just loading times.

There's a bit of memory twiddling going on to put the "vertex buffer elements" in the right format for loading vertexbuffers within an Ogre VAO (they are generally interleaved in one big array in glTF, and Ogre except an array of arrays if you want, with a list of tags describing their "vertex element semantics").

Also, the code of the glTF loader is probably not well optimized. I was concentrated on getting it to work. And it is also pretty verbose with Ogre::LogManager, this is probably not helping :




Edit : Also, there are a few issues with the texture loading code. But I'm not going to stress that a lot because it is using interfaces that will be gone with the V2-2 "Texture Refactor" branch. But one thing that could be beneficial is tho be able to load a Metal+Roughness texture map in one go. Here' I'm separating the channels by hand into 2 greyscale textures.

Changing this would require modifying HLMS/PBS, both in the C++ side and the shader side. And I don't think I'm going to delve into this myself, as I have no idea what I'm doing

[Zonder]

Oh was just a passing thought, I wouldn't have expected you to have optiomized yet, was just a metric for people

[dark_sylinc]

Mmm... I will have to try it myself then! (If I forget, someone please remind me in a few months...!)

Just a note: Performance is irrelevant. Well of course if glTF could match native .mesh loading then great. But it's not critical because you can (or rather should) accept glTF and then export to a native format, and on the next run load the native one unless the glTF timestamp changed.

For example Unity accepts a billion of texture formats, but when shipping the game, it creates a version that is natively optimized for the target platform.

[Ybalrid]

Just a note: Performance is irrelevant. Well of course if glTF could match native .mesh loading then great. But it's not critical because you can (or rather should) accept glTF and then export to a native format, and on the next run load the native one unless the glTF timestamp changed.

For example Unity accepts a billion of texture formats, but when shipping the game, it creates a version that is natively optimized for the target platform.

This is probably the way to go. I was focusing on "just loading the damn file", and this plugin will not do more than that. Right now the plugin interface is pretty poor (I have a really simple abstract class, and I'm basically just giving you Ogre::Item* on demand). I'll put that on the todolist!

I should give you easier access to the v2 MeshPtr directly from the glTF import inside Ogre's MeshManager. Creating and distributing Items was just for convenience. That way, building a caching system similar to what you are describing shouldn't be too hard by just serializing theses meshes to disk.

For now I'm just consuming glTF files (and even, if you want to read them via Ogre's Resources, I'm really just consuming glb files. But that's probably for the better when you think about it)

Edit: did a really quick refactor to allow what was mentioned above, and tagged it v0.1.1 https://github.com/Ybalrid/Ogre_glTF/releases/tag/0.1.1

[Slicky]

Thanks for the plugin. I am starting to play with it. I've hit a little issue. I'm wondering if scale isn't implemented. A cube that is scaled to a flatter surface still comes in as a cube. I'm stepping through the code to try and see what the deal is.

Part of the .gltf file:

Code: Select all

"nodes": [
        {
            "mesh": 0,
            "translation": [
                0.0,
                0.0876861959695816,
                0.0
            ],
            "scale": [
                30.293285369873048,
                1.158614158630371,
                30.293285369873048
            ],
            "name": "pCube1"
        }
    ],

[Ybalrid]

Thanks for the plugin. I am starting to play with it. I've hit a little issue. I'm wondering if scale isn't implemented. A cube that is scaled to a flatter surface still comes in as a cube. I'm stepping through the code to try and see what the deal is.

Part of the .gltf file:

Code: Select all

"nodes": [
        {
            "mesh": 0,
            "translation": [
                0.0,
                0.0876861959695816,
                0.0
            ],
            "scale": [
                30.293285369873048,
                1.158614158630371,
                30.293285369873048
            ],
            "name": "pCube1"
        }
    ],

That's expected...

Scene local transform aren't applied. It's strictly a "mesh" loader as of now, not a "scene" loader. So any rotation/scale/translation to nodes are ignored, and it will only try to load the first mesh it can find.

It shouldn't be too hard to implement loading of nodes via the plugin, but I wasn't interning to use gltf asset "that way" personally (I really, really needed a cleaner import of mesh with PBR materials, and why the heck not use a standard file format for that). But if it's requested by users, I think I can work on it relatively soon...

[Slicky]

OK good to get confirmation I couldn't see any evidence of it being there. This is just one example model from Maya which seems to use scale instead of making the item that size. When I use a web viewer the export looks correct. So I'm not doing a scene. Initially I thought I needed to freeze history like you could do in Softimage but apparently not.

I can try and add something too if I can work out what to do.

[Slicky]

I got it to look correctly I think by freezing the scaling on the model. That makes me wonder about transforms and rotations. They might be a problem too.

That would mean freezing history on each export but it would work.

[Ybalrid]

I don't know a thing about Maya. In Blender what you would want to do is to "apply" the transform made in "Object Mode" to the mesh itself (Ctrl + A). This will actually move the vertices in the mesh to the actual transfrom they appear inside the editor viewport.

[Slicky]

I created a pull request today to implement node transforms. I tried to use similar coding style. On one brief test from an exported model from Maya it is working for me. I have to play with it more to be sure.

Take a look and see what you think.

[Ybalrid]

I created a pull request today to implement node transforms. I tried to use similar coding style. On one brief test from an exported model from Maya it is working for me. I have to play with it more to be sure.

Take a look and see what you think.

Seen. It's pretty clean, so I merged it right away

And many thanks for correcting a few typos along the way. I wrote this thing rather quickly, especially the comments, and sometimes I just type weird things...

[JuBe]

Hi,

I made small changes that adds support for models that uses multiple materials.

Here's a patch of the changes, if you want to include them to main repo.
https://tinyurl.com/yabs47cj

[Ybalrid]

Hi,

I made small changes that adds support for models that uses multiple materials.

Here's a patch of the changes, if you want to include them to main repo.
https://tinyurl.com/yabs47cj

If you happen to have a GitHub account, I would appreciate a pull request.

[JuBe]

Hi,

I made small changes that adds support for models that uses multiple materials.

Here's a patch of the changes, if you want to include them to main repo.
https://tinyurl.com/yabs47cj

If you happen to have a GitHub account, I would appreciate a pull request.

Done, that was the first time I made pull request so hopefully I did it right.

[Slicky]

I just did a small pull request to fix default scale on nodes.

[Ybalrid]

This is great guys! I'm really happy you find interest in this work, and are willing to contribute.

I'm going to review these pull request as soon as I can. Don't hesitate to post feedback about using the plugin/library here, I'm really interested about this. I want this tool to become as useful as possible.

[Ybalrid]

@Slicky Just so you know since current version of the plugin, I'm doing a tiny change to the API right now:

Code: Select all

		virtual ItemAndTransform getItemAndTransformsFromResource(const std::string& name, Ogre::SceneManager* smgr) = 0;

is now

Code: Select all

		
		virtual ItemAndTransform getItemAndTransformFromResource(const std::string& name, Ogre::SceneManager* smgr) = 0;

with singular Transform.

The interface of that class, between constructing an Item for you, getting the Item and transform, and getting a mesh and a datablock starts becoming a bit silly. I need to do a refactor of this soon.

I'm going to decide how it will be best to interact with the glTF loader. Once this is done, I'll look at a few other parts of the code I'm not happy with, and since it's going to be the first real breakage of API, and new features have been added, I'm going to bump it to version 0.2.

An issue to track this : https://github.com/Ybalrid/Ogre_glTF/issues/16
And a milestone for releasing 0.2 (more stuff can be added to this, I don't have a date planned) : https://github.com/Ybalrid/Ogre_glTF/milestone/1

[Slicky]

Ok cool I will keep following.