Why .mesh?

Design / architecture / roadmap discussions related to future of Ogre3D (version 2.0 and above)
Post Reply
Jay721
Halfling
Posts: 41
Joined: Mon Jan 29, 2018 8:19 am

Why .mesh?

Post by Jay721 » Wed Apr 18, 2018 8:16 pm

Why does Ogre only load .mesh? Why isn't there a built in importer for files like .obj and .fbx? I'm struggling to convert my .fbx files as the exporters I've tried with Blender & Maya don't work :/
0 x

User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 4

Re: Why .mesh?

Post by Mako_energy » Wed Apr 18, 2018 8:44 pm

This is an ongoing gripe I have with Ogre as well. I started a thread a while back to try and get glTF 2.0 support into OgreMain, but it seems it only became an addon/plugin. While that is way better than nothing, it's the type of thing I think will fall into disrepair as time goes on.

Assimp is another option, but still suffers the same problems. Ogre is a moving target and hard to keep up with the core Ogre team as an outsider with imperfect communication to make sure all the features are supported and used correctly. I've seen countless threads where people complain about bugs and gaps in functionality. All of these create serious barriers to people starting out using Ogre. Materials going to JSON in 2.0+ is pretty awesome though.

Edit:
Ybalrid is working on something that can help in this area a great deal, adding glTF 2.0 support to Ogre. I still feel this should be a part of OgreMain, though.
https://trello.com/b/TFl8tJMX/ogregltf
https://github.com/Ybalrid/Ogre_glTF
0 x

Jay721
Halfling
Posts: 41
Joined: Mon Jan 29, 2018 8:19 am

Re: Why .mesh?

Post by Jay721 » Thu Apr 19, 2018 4:48 pm

Thanks for the reply :) So what should I do if I want a mesh with a skeleton :/

It seems like the thing you posted isn't quite there with animations?
0 x

User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 4

Re: Why .mesh?

Post by Mako_energy » Fri Apr 20, 2018 4:18 am

It's not ready, no.

You need to find an exporter that supports the tool you are using. There are some stickies in this forum that refer to exporters that can potentially be used depending on the tool you use.

Other than that, Assimp or Ogre-Assimp is likely your best bet. It supports a large range of formats, however I haven't kept up to date on how well maintained any given format is. Worse, doing a quick glance at Ogre-Assimp I'm not sure if it supports any Ogre 2.0+ formats as I only see references to Ogre 1.10. In general you don't have very many options here.
0 x

User avatar
Ybalrid
Halfling
Posts: 70
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 20
Contact:

Re: Why .mesh?

Post by Ybalrid » Thu Apr 26, 2018 6:17 pm

It's not ready yet, far from it. I am still working on the animation support in the glTF thing. I had a few rough months with my studies so I haven't had the time to get back to it since January~February.

Once it's done, there will be a bit more work for making this integrate more "seamlessly" with Ogre. 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

Main goal is to be able to load "meshes" but in glTF binary format (.glb files). This file format feels, at leas for me, like the better way to exchange 3D assets from a modelling software to a game engine. I am less interested into using glTF as a "scene" representation (it can do it, it even has support for lights and cameras)

In any case, I'm happy to see that people are interested in my little importer. I plan to switch an ogre powered game-engine completely from using .mesh files to use glTF with a standard PBR workflow, with the official glTF exporter for Blender... :wink:
1 x
Ogre_glTF Ogre v2-1 GLTF2 loader : topic link github repo
BtOgre21 Fork of btOgre, for Ogre v2-1 : topic link github repo
OIS Current maintainer : Official repository
Annwvyn VR focused game engine using Ogre : https://github.com/Ybalrid/Annwvyn https://annwvyn.org/

User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 4

Re: Why .mesh?

Post by Mako_energy » Thu Apr 26, 2018 9:57 pm

Glad to hear you haven't abandoned it. I'm pretty much of the exact same mindset for most of what you mentioned. I think the scene aspect is needless and safe to ignore. 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. Personally, I'd ignore any scene related features if you were to implement them.

I don't think glTF everything is the best way to go, although I could be wrong. Keeping things in the native format may have performance benefits when loading. 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. We simply lack a robust and well supported way to do that first step in Ogre.
2 x

User avatar
Ybalrid
Halfling
Posts: 70
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 20
Contact:

Re: Why .mesh?

Post by Ybalrid » Thu Apr 26, 2018 10:32 pm

Mako_energy wrote:
Thu Apr 26, 2018 9:57 pm
I'm pretty much of the exact same mindset for most of what you mentioned. I think the scene aspect is needless and safe to ignore. 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. Personally, I'd ignore any scene related features if you were to implement them.
You are on the same wavelength with me for the scene representation stuff. But I also see some people that would want to use something like blender as a makeshift "level editor". That was the purpose of the old ".scene" format (a big XML file referencing .mesh files with their local position/rotation/scale in a tree that represent the scene manager and it's nodes.)

This is fairly low priority for me. 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. For now, the importer is designed in a way where it will look at the first mesh it can load, and only load that.

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.
Mako_energy wrote:
Thu Apr 26, 2018 9:57 pm
I don't think glTF everything is the best way to go, although I could be wrong. Keeping things in the native format may have performance benefits when loading. 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. We simply lack a robust and well supported way to do that first step in Ogre.
I'm not saying glTF "everything", I'm saying glTF as the transfer format (it's desinged for that). There are a lot of information that other format made for authoring (like collada, fbx or blender's .blend) that will not be present in a glTF file.

It's safe to say that .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. But, texture format aside, and metadata, glTF is literally in the same format you'll upload and describe data to the GPU in OpenGL. Textures are any image format you may like, and metadata are JSON objects.

glTF is at the sweet spot between an easy to use format. 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).

This is why I think glTF 2.0, especially in it's serialized, concatenated binary form (.glb files) is probably the best solution for the final export from the art asset creation toolchain, and a game engine (be it in a smartphone app, a webpage, or something bigger that runs with Ogre for example... But I would like everyone to support glTF and end the hell that surround exporting stuff from 3D software. It's designed to be "the JPEG of 3D", and I really hope it will become it. You can already open theses files with Pain3D on Windows ( :!: ) and you can post them like you do pictures on Facebook ( :!: ) so it's coming along...
0 x
Ogre_glTF Ogre v2-1 GLTF2 loader : topic link github repo
BtOgre21 Fork of btOgre, for Ogre v2-1 : topic link github repo
OIS Current maintainer : Official repository
Annwvyn VR focused game engine using Ogre : https://github.com/Ybalrid/Annwvyn https://annwvyn.org/

Jay721
Halfling
Posts: 41
Joined: Mon Jan 29, 2018 8:19 am

Re: Why .mesh?

Post by Jay721 » Fri Apr 27, 2018 8:28 pm

So what are people using to create .mesh files? This seems like a really big draw back with Ogre :/
0 x

zxz
Greenskin
Posts: 139
Joined: Sat Apr 16, 2016 9:25 pm
x 5

Re: Why .mesh?

Post by zxz » Fri Apr 27, 2018 9:46 pm

For .mesh-files we are using the now seemingly defunct OgreMax exporter for Maya. I seems to be gone from the web :(

In place of .mesh-files, we have mostly migrated to using .fbx-files imported into Ogre using the Assimp library. The mesh data and animations are pulled out of the .fbx using Assimp and put into Ogre vertex buffers. This alternative is working well for us, and is way more future proof than continuing to use .mesh with a diminishing amount of maintained exporters. As mentioned, Assimp also supports many other formats, which can all be imported through the same library interface, which gives even more format flexibility.
0 x

hedphelym
Gremlin
Posts: 154
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: Why .mesh?

Post by hedphelym » Sat Apr 28, 2018 8:53 am

At work we use 3dsmax.
First we used ofusion - that one is dead.
Then we used ogremax - dead as well.
Then I wrote our own exporter by using the 3dsmax c++ SDK and Ogre, and we've been using it ever since.
Also ported that exporter to ogre 2.1.
It exports directly to binary mesh files, then also exports the whole scene to .scene file with animations and everything.

At home for personal projects - I have not decided yet, but I like the GLTF importer mentioned above, and
that's what I want to use, I want to help out getting some of those missing features in, but I have not had much time recently to help on it.
(full time job and two kids does not make it easy to find time).

I'm assuming .mesh format is not going to be replaced, so I think Ogre still needs a proper .mesh exporter for Blender,
not one that exports to .xml and then needs conversion, but one that exports to binary directly, and also the .scene file that contains the scene information, but again - someone has to sit down and do it, and it is a lot of work to write a full exporter.
I am currently working on a exporter for a render engine for blender (not realtime engine), and it's always in the back of my mind to make one for Ogre.
A lot of the features I'm making now would be the same for a Ogre exporter.
0 x

paroj
OGRE Team Member
OGRE Team Member
Posts: 615
Joined: Sun Mar 30, 2014 2:51 pm
x 85
Contact:

Re: Why .mesh?

Post by paroj » Sat Apr 28, 2018 9:18 pm

hedphelym wrote:
Sat Apr 28, 2018 8:53 am
I'm assuming .mesh format is not going to be replaced, so I think Ogre still needs a proper .mesh exporter for Blender,
not one that exports to .xml and then needs conversion, but one that exports to binary directly, and also the .scene file that contains the scene information,
blender2ogre already exports .scene just fine and can even add physics properties for bullet.

Why do you think the intermediate step with .xml is bad? The xml format is more stable and thus can be (theoretically) consumed by different Ogre versions.
Additionally using the Python component it should be straightforward to directly use Ogre for writing the .mesh file.
1 x

hedphelym
Gremlin
Posts: 154
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: Why .mesh?

Post by hedphelym » Sat Apr 28, 2018 10:03 pm

Correct, but still it needs some work to get it to work with ogre 2.1, and also you need to set up the xml converter.
So for a new user it's more things to worry about getting set up (I know it's not that hard, but still it can be for a new user).
I personally like binary export directly because of speed, we work with scenes with hundreds of of meshes, and if we export to .xml first, then have to call the xml converter for each file it takes a lot of time to export. Exporting to binary directly is very fast compared to that.

One thing though, is the new ogre 2.1 serializer, if I understand it correctly it would be similar to .scene format,
maybe that one is better to implement for a ogre 2.1 exporter for blender.
1 x

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3772
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 132
Contact:

Re: Why .mesh?

Post by dark_sylinc » Mon Apr 30, 2018 5:24 am

As paroj said, binary versions come and go, but the XML scheme hasn't changed in ages. It's much more stable thus easier to target.

Like you also noted, exporting to text and then to binary has a performance cost. Fortunately faster machines can help with that, and adding more cores help too.
hedphelym wrote:
Sat Apr 28, 2018 10:03 pm
One thing though, is the new ogre 2.1 serializer, if I understand it correctly it would be similar to .scene format,
maybe that one is better to implement for a ogre 2.1 exporter for blender.
Yes.
By the way, if you dare to compile and use DERGO (it has a few quirks to activate it, follow the video's steps), Dergo supports exporting the scene directly to binary (meshes and materials). Note however, skeletons are not supported. And if Dergo server crashes at the moment it's just better to restart Blender and reload the scene (basically: it's not fully stable; but it may workout for you)
1 x

hedphelym
Gremlin
Posts: 154
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: Why .mesh?

Post by hedphelym » Mon Apr 30, 2018 6:02 am

Thanks for the reminder, I remember seeing that some time ago but I forgot about it, I'll definitely check it out and get that tested.
0 x

Jay721
Halfling
Posts: 41
Joined: Mon Jan 29, 2018 8:19 am

Re: Why .mesh?

Post by Jay721 » Mon Apr 30, 2018 7:35 pm

Oh, so there's a blender exporter that works? The one I'm trying to use spits out a few errors whenever I try and export anything.
0 x

Hrenli
Halfling
Posts: 51
Joined: Tue Jun 14, 2016 12:26 pm
x 8

Re: Why .mesh?

Post by Hrenli » Tue May 01, 2018 1:36 pm

Jay721 wrote:
Mon Apr 30, 2018 7:35 pm
Oh, so there's a blender exporter that works?
io_export_ogreDotScene.py works fine for me (with Blender v2.79). Not 100% sure I recall where I downloaded it from, was quite some time ago.
0 x

Jay721
Halfling
Posts: 41
Joined: Mon Jan 29, 2018 8:19 am

Re: Why .mesh?

Post by Jay721 » Wed May 02, 2018 7:04 pm

Hrenli wrote:
Tue May 01, 2018 1:36 pm
Jay721 wrote:
Mon Apr 30, 2018 7:35 pm
Oh, so there's a blender exporter that works?
io_export_ogreDotScene.py works fine for me (with Blender v2.79). Not 100% sure I recall where I downloaded it from, was quite some time ago.
All I need is to export meshes, not scenes... Will that do it?
0 x

Hrenli
Halfling
Posts: 51
Joined: Tue Jun 14, 2016 12:26 pm
x 8

Re: Why .mesh?

Post by Hrenli » Wed May 02, 2018 7:12 pm

Jay721 wrote:
Wed May 02, 2018 7:04 pm
All I need is to export meshes, not scenes... Will that do it?
Yes, that's exactly what I use it for - to export separate meshes (and skeletons). It produces .xml files which I then pipe to OgreMeshTool to build binaries.
0 x

Jay721
Halfling
Posts: 41
Joined: Mon Jan 29, 2018 8:19 am

Re: Why .mesh?

Post by Jay721 » Mon May 28, 2018 8:30 pm

I was going to try and compromise and export my meshes to .mesh, but this is really not practical for me now. I really need the ability to load meshes like .obj and .fbx whilst the program is running, not like that command line converter.

It seems very weird that there is no built in support for different file formats on Ogre, I've used irrlicht a while back which seems a lot more lightweight and they had obj support.

Has anyone made assimp work on the go with Ogre 2.1? (or any alternative way of loading meshes a runtime)
0 x

User avatar
Zonder
Ogre Magi
Posts: 1102
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 12

Re: Why .mesh?

Post by Zonder » Mon Jun 04, 2018 9:50 am

As I recollect Xrgo shared some code to load blend files directly for 2.1 but I think it wasn't 100% complete (he just copied it out of his engine) just had a look for the post but can't find it :S
0 x
There are 10 types of people in the world: Those who understand binary, and those who don't...
My Blog - http://www.This post is suspected as SPAM! If you feel otherwise contact a moderator.

User avatar
Ybalrid
Halfling
Posts: 70
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 20
Contact:

Re: Why .mesh?

Post by Ybalrid » Wed Jun 13, 2018 12:56 am

Hey guys, I took some time today to continue on my glTF loader. (Haven't actually sat down in front of the code since February. Projects and exams and stuff got in the way)

I'm loading skeletons, and looping through the vertex -> bone assignments in the vertex array object now. I'm building a (v1) skeleton out of that, then adding it to the mesh via _notifySkeleton(). Then, here I'm accessing it via the Item, as a SkeletonInstance.

Maybe there's something weird about the nodes and the transforms the bone apply, I don't know, it needs more testing on my part. This model has two bones. Here I'm just setting the 2nd one as "manually controlled" and moving it's position along it's Y axis (relative to the parent). The parent bone seems to be moving too when doing so. I don't know if it's normal, and I don't actually know at what point the position/rotation of the bones are applied (base? middle? tip?)

And there's a thing called the "inverseBindMatrix" in the glTF file that I don't know what it's supposed to be or to do with. But, in any case, moving one bone definitively deform the mesh, so it's progress! (see below)

Image

NB: this is not the animation track inside that sample file, I am not importing the animations (yet).

I'm centimetringinching towards being able to just import one model from a glTF file entirely (if we exclude morph targets, they aren't planned, as far as I know, Ogre 2.x doesn't have them yet). I'm pretty happy about that!

I hope to be able to continue chipping at it this week. I really want to have this importer working for other project... ^^"
1 x
Ogre_glTF Ogre v2-1 GLTF2 loader : topic link github repo
BtOgre21 Fork of btOgre, for Ogre v2-1 : topic link github repo
OIS Current maintainer : Official repository
Annwvyn VR focused game engine using Ogre : https://github.com/Ybalrid/Annwvyn https://annwvyn.org/

hedphelym
Gremlin
Posts: 154
Joined: Tue Nov 25, 2008 10:58 am
Location: Kristiansand, Norway
x 7
Contact:

Re: Why .mesh?

Post by hedphelym » Thu Jun 21, 2018 6:51 pm

ybalrid, its much easier to test it with a more basic shape, for example a cube,
then add 2 bones, assign them to 4 verts each, then print out the vertex influence from the gltf data and then ogre data to compare with.
I used ogremeshy a lot for debugging exports of 1.x meshes, but that one does not support 2.x yet.

In the gif it seems as if there is vertices in the middle of the cylinder, and that bone that you move is influencing more verts then it should (or moving those vertices in the middle) - giving a illusion that bone 1 is moving as well, but I'm guessing here.
0 x

Jay721
Halfling
Posts: 41
Joined: Mon Jan 29, 2018 8:19 am

Re: Why .mesh?

Post by Jay721 » Thu Jul 12, 2018 6:14 pm

How am I supposed to set up the blender to Ogre exporters if they require 'OGRETOOLS_XML_CONVERTER' which doesn't seem to be included in 2.1?
0 x

User avatar
Ybalrid
Halfling
Posts: 70
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 20
Contact:

Re: Why .mesh?

Post by Ybalrid » Thu Jul 12, 2018 6:39 pm

Jay721 wrote:
Thu Jul 12, 2018 6:14 pm
How am I supposed to set up the blender to Ogre exporters if they require 'OGRETOOLS_XML_CONVERTER' which doesn't seem to be included in 2.1?
Mh, check that you are building Ogre with the TinyXML dependency (if you are using this package you are all set on Windows https://bitbucket.org/cabalistic/ogredeps/, on linux you can probably install a package to get it). And the option to build, and to install "TOOLS" is activated in CMake, then you should have the XML converter.

The, you need to give it's path to the blender plugin, I don't really remember how.

There use to have separatse "XML converter" and "Mesh upgrader" exes, but now they have been merged into one "Ogre Mesh tool"

Other solution would be to just let the exporter output the XML files, and convert them by hand with the tool.

By default when you build Ogre, the tools executable are located in some "bin" folder, the exact path depend on the configuration (debug/release, thing like that).
1 x
Ogre_glTF Ogre v2-1 GLTF2 loader : topic link github repo
BtOgre21 Fork of btOgre, for Ogre v2-1 : topic link github repo
OIS Current maintainer : Official repository
Annwvyn VR focused game engine using Ogre : https://github.com/Ybalrid/Annwvyn https://annwvyn.org/

Post Reply