Ogre Forums

Hi,
Recently have tried the blender2ogre exporter and I could not even imagine that such a situation could even occur - I will not rewrite my discovery and feelings again, the topic is here: viewtopic.php?t=97189
Ogre is an excellent 3d engine (I am referring to the 1.x variant).
It has a very robust and flexible API and it is one of the last well made 3d egines written in C++ for C++ developers.
The flexibility it does offer is far away from the Unity crap but the last one has choosen a path that Ogre did not - to offer a very well made and easy to use 3d editor with the engine integration built in.
Unity has made the same mistake that Ogre did or maybe it was intentional - to go for a pseudo proprietary scene format - well, it is not accurate as almost all the assets are in the fbx format, but the grouping and arrangement is proprietary.
In any case Unity has revolutionized the game dev scene as it has offered the tool to let artists and content creators to make beautiful assets and scenes and sell them on the Unity store and then allowing indie developers to create good games with less effort and by using a reasonable amount of time.
Even the Godot new born engine is including a gltf scene importer so that the Unity to gltf and gltf to Godot process is allowing almost 50% of the scene to be imported.
Personally I do not mind the dx12 parallel gpu taks commitment/processing which has given the idea to create the version 2 of Ogre with a rewritten pipeline in order to be compliant to the new M$ API.
I am convinced that this was the Ogre team fault, it was your fault guys.
At that time when you were going to embrace that journey (to create the new engine) it was clear which were the two/three major flaws of Ogre 1.x
It was not the engine pipeline (serial instead of parallel) instead it was the lack of a non proprietary format support: ie GLTF, the lack of a scene editor, the lack of an advanced lightning system ie VCT.
While the second and third were not mandatory IMHO the first one was.
During these years you also did not make the blender2ogre plugin use multi threading - it is impossible to offer a tool which will take one, two days to complete a mid complex scene.
I do not know if the Ogre founders are still on the Ogre project, it would be nice to hear a voice from them.
Anyway if you will not refactor the blender2ogre plugin or create a commandline tool like the xml converter to convert a blender scene into the .scene format in a reasonable amount of time (not more then 5 mins for a very complex scene) then probably Ogre will end like many other engines did before, just to mention one of them: Irrlicht.
I would like to encourage you to offer such a tool by using multi threading with an efficient DOM like data model from which the final .scene can be built in a robust and fast way.
At the stage we are now we can not expect Ogre to be used for commercial products - almost all the assets are made and available on the Unity store.
You/we can avoid that Ogre will be forget, please create such petition where people will be funding such blessing tool for both the Ogre engines.
Thanks.

Well, I can tell that you haven't looked at the blender2ogre options:
https://github.com/OGRECave/blender2ogr ... Options.md

The idea of blender2ogre is to export the meshes, that is its main purpose. That is, to be able to convert an "asset" in Blender to a .mesh file that OGRE can use.

As a bonus it is also able to export a .scene XML file that you can import into OGRE.

When using blender2ogre you have to mentally separate the scene from the meshes in order to be able to work more efficiently.

That is why you can play with the EX_MESH (Export Meshes) option so that when you are only operating on the scene (that is moving things around or adding meshes here or there) you should only export the scene and not the meshes. You will see that exporting only the scene is extremely fast, only a few seconds.

I think your problem is that every time you export your scene you are exporting both the .scene and also all the meshes that get recreated and overwritten every time in a time consuming process.

You can also set the option: EX_MESH_OVERWRITE (Export Meshes (overwrite)) to false so that only meshes that don't have a corresponding .mesh file are exported.

If you find issues with these things then you can let us know in the blender2ogre repo as an issue, but what you said in your post is not completely justified.

OGRE is not trying to compete with Unity or Godot because that is impossible and was never the purpose.

Many people tried to make a game engine out of OGRE and many have succeded, but there is not a single or standard OGRE game engine. The thing that is the closest is Ogitor https://github.com/OGRECave/ogitor

Hi,
Sorry but I have never said any word in favor of Godot or Unity except their ability to handle assets in the best fashion.
There is no need to write down what a scene is made of - when a user is going to export a scene he expects that a scene will not get more then few minutes to be "translated" in the format he wants to work with.
If we do remove the terrain from a scene we will get for the most the meshes, which are the most heavy objects to parse and rearrange in the desired format.
I can not see any valid explanation in your words.
Just for the curiosity I ve made the export options to be the less heavy I could, no mesh overwrites, no image conversions, no lod adjustment (by using Ogre external tools).
The result is still horrible, it has passed one hour and I still do not see the END!
If Ogre was going to be a commercial product no one will be choosing it.
I am not going to use Unity nor any other 3d engine for your information.
I am going to use Ogre but I will spent the next weeks by doing my own gltf parser and as a second step an Ogre scene loader from the scene builder.
I invite you to accept some critics, I do not know how old are you, this also should not be part of a public conversation, the question however is serious - no one is moving critics towards Ogre for the lack of some eye kindy functionality - we are speaking about something more important - assets support and alternatives to handle the lack of such support - blender2ogre is not the choice to go with, DOT.

as sercero said, the main purpose of blender2ogre is to export a single object. While you can export a whole scene, most people do not use it that way.

In case you are willing to help out with the performance, the bottleneck with exporting is the conversion of the geometry to text (XML). This could be solved by using ogre-python to directly write the binary mesh and skipping the textual representation altogether.

Also note that Ogre can already directly load glTF via the Assimp Plugin:
https://github.com/OGRECave/ogre/tree/m ... Ins/Assimp

However, this is again designed around loading a single object and hence any hierarchy present in glTF will be "baked" into a single geometry on loading. So improving the Assimp plugin in this regard would be another option.

Well damn. Man the title I feared it was a topic by an Ogre developer, someone with >1000 posts etc.
I'd change it, IMO seriously confusing at best. Actually after closer look into 1st post, there's serious non-sense in it so whatever. Ogre-Next or the Ogre 2 split and development (mainly by 1 person) was the best thing that happened here, not any freaking GLTF format.

And yeah Ogitor editor wasn't clearly possible to last longer, back in times when there were even few developers (not a couple like now). I'm just a long time user here, so just my POV OFC.
I tried it back then and came to conclusion that I'd be spending 5x more time writing a road plugin for it, than making my own editor and yeah also own scene.xml, which I did. Surely took long time in total. But is much faster to use for doing Stunt Rally tracks (now over 200) than any other editor ever.

What I kind of like in modern engines like Godot is the shader graph editor, man that'd be great in Ogre-Next, but surely impossible right.

BTW. I had no issues with importing any recent common model format (e.g. from sketchfab, blendswap) into Blender and then exporting into .mesh for Ogre (or Ogre-Next) to use. Then doing materials by hand in text file.