I've had huge issues converting models to/from the Ogre format. Its been an enormous inconvenience, and looking around the forums it seems as if others have had issues as well. I would, then, humbly request that support be added to Ogre to load the most common industry standard model formats. Using (for example) Assimp (http://assimp.sourceforge.net/) is pretty straightforward and easy, and it would allow Ogre to load a huge variety of model formats.
It doesn't make much sense to spend CPU cycles dynamically converting the models from foreign formats when you can do that once and then load them directly without any conversion overhead. Don't punish your users, they will thank you
Perhaps not too you, but too others the functionality could be quite useful. Furthermore, model formats are pretty straightforward, with minor variations of storing the same data. A proper implementation shouldn't add hardly any more overhead than importing the native Ogre format. Additionally, the Ogre mesh format has several issues that aren't had in other formats, and other formats are more feature-rich than the limited Ogre format. I've spent a lot more time caught up on these inconveniences than I'd care too, and browsing the forums it would appear that I am not the only one.
Wouldn't it make sense to increase the productivity and usability of the Ogre engine and support industry standard formats? You could still have a custom Ogre mesh format for those that want to hassle with it.
If only it worked, no offense . Assimp has no issues loading/displaying/etc some models I have, but converting them (using every tool on the internet, including OgreAssimp) results in a broken mesh once they reach Ogre. Blender, max, etc have no issues with the models. Clearly it is Ogre and/or its mesh format that is the issue.
jacmoe wrote:The Ogre mesh format is an industry format.
bstone wrote:And Blender, max, etc. all are real-time rendering engines, right?
No. They are the modelling tools that produce content for the real-time engines, and it should be easy to get content from them into real-time engines. For other engines it is easy, but not for Ogre (at least, in my expereince). Getting content into Ogre is an enormous pain.
Yep, and the modeling tools have much more flexibility in that regard. Furthermore, since you already entered those waters, I'm sure you can tell that the issues you had with converting models to Ogre format was not because the format is deficient - it's basically what GPU wants to render geometry - but because the problematic formats were either universal or specifically tailored to the respective modeling tools and as such were quite far from what GPU wants.
bstone wrote:Yep, and the modeling tools have much more flexibility in that regard. Furthermore, since you already entered those waters, I'm sure you can tell that the issues you had with converting models to Ogre format was not because the format is deficient - it's basically what GPU wants to render geometry - but because the problematic formats were either universal or specifically tailored to the respective modeling tools and as such were quite far from what GPU wants.
Bstone, I would kindly request that you quite patronizing me. I am no idiot, and your dogmatic, condescending assertions are really irritating me. Please quite treating me like some idiot monkey with a mouse. I have legitimate reasons to request that Ogre be able to load industry standard formats just like other rendering engines can. Just because you can't see the use or you don't agree with it doesn't mean others can't use it or that it won't be useful.
I like the way Ogre dictates that all meshes must be loaded using Ogre mesh format, or if you want to load other mesh formats then you can do it on your own, OR you can have something like assimp to convert it for you. Otherwise, Ogre is dictated by the file format which it has no control whatsoever. Ogre - having its own format can also ensure that loading time can be optimized, among other advantages.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
I believe it would be useful and you should write it tbz.
I don't think anybody would refuse such a feature if it came as a patch. Especially if it doesn't break current .mesh format loading.
Just don't expect Ogre Team to do it for you. Afaik no one works on Ogre as a full-time job.
Nimet - Advanced Ogre3D Mesh/dotScene Viewer asPEEK - Remote Angelscript debugger with html interface ogreHTML - HTML5 user interfaces in Ogre
syedhs wrote:Ogre - having its own format can also ensure that loading time can be optimized, among other advantages.
That's great for a release, but what about development? Models change. They have to be converted to and from the Ogre format, sometimes taking multiple steps to get there, etc. Sometimes spending an extra 250MS parsing a model is an acceptable trade when it saves you 5 minutes of conversion commands (that's assuming the conversion commands work, at all).
Sometimes a model will be being edited. Save it, save as dae, convert to Ogre using OgreAssimp, copy new files over, test. Oops, model doesn't look right, need to repeat again and again and again until the model is right. Wouldn't it be so much easier if I could just tell the exporter where to plop the dae file and ogre automatically loads it? That would be amazing.
Yes I don't deny it would be better if Ogre can support more than one format, but it is a question of balance.. having Ogre to support would require man hours to author the code etc etc, and the time spent IMO should be spent for other things. Yes as saejox said, if you think it is important, you can help by writing (and sharing) the code.. DAE is nightmare to support and now being abandoned by quite many players. And there was a Google Summer Project for dae loader, and I think it can be considered fail because it is not used.
Edit: And you can use exporter like Ogremax (which works in 3dsmax and maya) which allows you to preview the object real time in Ogre viewport before you export it.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
All right, when you have time, make a component just for that. It will sure find its users but you might not find time for anything else other than catching up with all the formats and fixing all related issues. I'm sure Ogre's team has much more urgent tasks to invest their time in. What do you think?
bstone wrote:All right, when you have time, make a component just for that. It will sure find its users but you might not find time for anything else other than catching up with all the formats and fixing all related issues. I'm sure Ogre's team has much more urgent tasks to invest their time in. What do you think?
You have to keep up with changing formats/etc anyway with the tools such as OgreAssimp.
syedhs wrote:Edit: And you can use exporter like Ogremax (which works in 3dsmax and maya) which allows you to preview the object real time in Ogre viewport before you export it.
Too bad OgreMax doesn't export my models correctly. It, and others, butcher the animations. Assimp, or other tools, have no issues with the animations. Clearly its Ogre and/or its mesh format.
tbz wrote:Bstone, I would kindly request that you quite patronizing me. I am no idiot, and your dogmatic, condescending assertions are really irritating me. Please quite treating me like some idiot monkey with a mouse. I have legitimate reasons to request that Ogre be able to load industry standard formats just like other rendering engines can. Just because you can't see the use or you don't agree with it doesn't mean others can't use it or that it won't be useful.
Oh, I missed that one. No offense intended at all. You can request all you want. I just wanted to save your time and tried to explain why. If I sounded dogmatic then it's most likely because English is not my first language.
OgreAssimp can load a file directly into memory. I guess that's what you want?
You can load a obj, dae or md2 directly into Ogre (because you're using the created mesh/skeleton pointer provided by OgreAssimp).
The remaining task is to detect a change and reload the asset.
However, I think that's a dangerous path to walk, because of much the same reasons why you don't want to develop your C++ application in debug mode only.
Release mode will surely kill you.
It makes a lot of sense for Ogre to have it's own optimized format, just like every other rendering / game library under the sun does.
/* Less noise. More signal. */ Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion. OgreAddons - the Ogre code suppository.
I don't think anybody would refuse such a feature if it came as a patch. Especially if it doesn't break current .mesh format loading.
Actually it most likely won't be accepted.
Many people have requested support for other formats over the years, and all have been turned down. Using a custom mesh format has always been an explicit part of ogre's design. Supporting other formats that aren't designed for ogre means needing to deal with features that ogre doesn't support. It's much better to have a single format that matches the abilities of ogre. Less compatibility issues, greater performance, simplified code, and the ogre developers don't have to worry about supporting formats they have no control over.
Making an addon that can load other formats would be fine, but adding them directly to ogre itself isn't going to happen.
If there are models that ogreassimp can't convert correctly, could you provide some examples for us to test?
If you are having problems exporting your models it's not the .mesh format that is the problem it's the exporter and it needs debugging, it could be your using a feature in the modeling program which can't be converted or it's not been implemented yet.
The best way to make it a better experience is get the exporter code if possible and debug it and submit a patch to the maintainer. These exporters are usually only worked on by one person and are not commercial you could even offer to pay the maintainer to fix a bug that will give them motivation (I know that's not always possible).
There are 10 types of people in the world: Those who understand binary, and those who don't...
