Page 2 of 2

Re: Loading industry standard model formats

Posted: Tue Apr 30, 2013 8:46 am
by Kojack
One example of something that can't be converted: the number of bone weightings per vertex.
Like most real time engines, Ogre only supports 4 bones per vertex (this comes from fixed function gpu limits). But modelling programs like max and blender support unlimited bones per vertex. If you try to export an animation that has too many bones per vertex, some will be lost and the animation will look different. This isn't the fault of ogre or the exporter, it's the fault of the artist not making the model suitable for the target engine.

Re: Loading industry standard model formats

Posted: Sat May 04, 2013 6:42 pm
by bvanevery
When Ogre moves away from fixed function pipelines in the future, such as with the GL3PLUS or DX11 renderers, I'm thinking the 4 bones per vertex limitation should be done away with. I wonder how many other import limitations are artifacts of fixed function pipelines. I have tried to understand Ogre's roadmap; I am guessing an embrace of "future looking" (really, the present?) pipelines is a ways out yet.

I don't know all these 3d modeling animation programs, Maya MAX Blender blah blah blah. As you can see from this discussion, there are big problems with importing someone else's business model for content production. Maya adds a new feature, "1476 bones per vertex!!!" and now everyone in industry has to dance to that tune, or else be the backwards looking engine that breaks on mesh import. I suppose it all depends on who really has the power in industry and what the target market for the engine is. If people are getting real work done and making real money, then they don't have to be beholden to the APIs that the big players push. Maya and MAX try to create de facto standards, to lock everyone into their version of content production, so that you have to have teams of specialist animators to get anything done, and you have to pay thousands of dollars per seat to do it. Money money money roll with big piles of money... the AAA likes this kind of development just fine, dropping a few million $ just on artists, who will redo their art at least once and half of them will leave mid-project anyways. All really crazy.

I do not like the Maya MAX business model. I think it is of no value to a small indie game developer, unless you happened to have learned all that stuff anyways, and I didn't. Sure I could learn Maya MAX Blender blah blah, I'm an artist not just a programmer. But I do not want to waste hundreds of hours of my time enslaving myself to someone else's business model. Why should I work for them and dance on their treadmill?

As for Blender, my main objection is it's GPL code. Secondary objection is a lot of people think it sucks. If true to some degree, I could fix that... except that it's GPL code, so I'm not going to. Way too much effort to redesign UIs or content paradigms, fighting other people about it in a committee, if I can't own my results in the free and clear for any commercial purpose I want.

So, as a programmer, I want to accomplish most of my content by procedural means. So I will be looking at "Ogre mesh format" from that standpoint. My profit inspiration is Minecraft, if not for aesthetics. We don' need no steenkin' importer. Skipping it can turn into $80 million.

Re: Loading industry standard model formats

Posted: Fri May 10, 2013 5:50 am
by tbz
Zonder wrote: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.
I found what the issue is. The models contain animation tracks that transform scene nodes. Ogre's scene format is separate from the mesh format. The tools export the meshes as a single mesh with multiple sub-meshes, meaning the sub-meshes can't be transformed by scene nodes (And, every exporter I have tried seems to discard the animation tracks that transform the scene nodes anyway).

There are a few solutions. One is to (#1) export the meshes as separate mesh files, then to export a dotscene file that contains the animation tracks for the scene nodes. Another is to (#2) convert scene-nodes into bones, which is fairly straightforward. Yet another is to (#3) bake the mesh(s) into a morph-animation.

I am developing a tool (based off of Assimp) right now. It does #3 already, although since morph animations are sub-optimal I am adding support for #1. Both are necessary due to the nature of the models I am working with. I am probably going to ignore #2, although I am making sure it would be easy to add if someone feels the need.

Once it is stable I will be releasing it to the Ogre community. This nightmare has cost me a weeks worth of work and hours of innumerable headaches, hopefully this tool can save someone else from that hassle.

Btw - Would it be all that bad to add support in Ogre for storing scene structure inside of the *.mesh files?

Re: Loading industry standard model formats

Posted: Fri May 10, 2013 10:29 am
by Kojack
(And, every exporter I have tried seems to discard the animation tracks that transform the scene nodes anyway).
OgreMax can export node animation.

Re: Loading industry standard model formats

Posted: Fri May 10, 2013 2:22 pm
by Transporter
I don't know which file Format you like to use. I'm reading collada with ogreassimp and STEP/IGES with opencascade. Using opencascade is a bit tricky, because it's only working if you load your files before you start rendering.

Re: Loading industry standard model formats

Posted: Fri May 10, 2013 6:09 pm
by tbz
Kojack wrote:OgreMax can export node animation.
Yes, too bad it doesn't work :|. At-least, not for my models.

Re: Loading industry standard model formats

Posted: Mon May 13, 2013 4:22 pm
by Mind Calamity
OgreMax can export node animation, and I'm working on implementing the same feature in the blender2ogre exporter, although I won't be able to do much until after June 12th. (Exams and stuff like that)

What you're looking for is a scene format, not a model format, since node animation should always be separate from the mesh itself.

Re: Loading industry standard model formats

Posted: Tue May 14, 2013 10:47 am
by Thoran
jacmoe wrote: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.
I agree when it comes to the point how the geometry data is laied out in memory, but I don't think it is relevant in the file format as long as you don't care for the loading times.
For Assimp in fact the geometry data is already laied out in a way that reduces vertex cache locality.

Re: Loading industry standard model formats

Posted: Fri Sep 27, 2013 11:20 am
by cloud
I really do think assimp is the silver bullet as far as model conversion is concerned, and it aught to be treated as such.

ogreassimp has issues, I've seen models that clearly haven't worked, but its hard to attribute blame since its an exporter, assimp, then the ogre code, it could screw up at any point along the way. I kinda did the bone animation in ogreassimp and found different formats arrange the hierarchy differently so assimp had the data consist with the model format, it ultimately had me on the floor with my head in my hands. The other issues with ogreassimp is how you want it to handle the materials and how you want to construct the mesh/meshes because you've basically got to work with an animated dot scene.

I can understand ogre team not going down this path, that said I wish they would.

Re: Loading industry standard model formats

Posted: Thu Jul 27, 2017 10:19 am
by Aiden
Well, this thread ain't dead.
I am working on developing a plugin for ogre to load models with assimp without using external tools, however it has some minor issues.
You can try it if you want, so far it loads simple objects well, but for complex ones there is an issue that needs fixing.
After completing this task I'll move to loading textures and skins then finally to animations.
I'm new to both ogre and assimp. However if want to try it out, Check ... ef_id=2210
If you are willing to improve it, either edit the page or check the github link at the bottom of the page which will lead you to the ASSIMP Issue .
Know that if you help improve this code, you also improve the user experience with ogre as this will enable them to load atleast 40+ models without using other external tools.


Re: Loading industry standard model formats

Posted: Wed Mar 07, 2018 7:50 pm
by Ybalrid
If anybody's interested, I'm hacking around in my little corner to load glTF files into Ogre 2.1 (and using HLMS PBS for the PBR materials obviously). For now I'm just looking at getting the 1st mesh object of a particular glTF file.


It's not ready and usable yet, I have to finish implementing the skeletons and animation, have *some* code cleanup, and normal maps are broken with DirectX 11 currently.

I like glTF because it's actually tailor made for the kind of need a 3D real time application needs. I don't really see the point into trying to load something like collada into a real time engine. 3D data are simple binary buffers in the same format you'll want to upload them to the GPU, and there's no ambiguity about implementation.

End goal would be to make it as an addon/plugin that can get the glTF data from Ogre's resource group manager. so that you could seamlessly create an entity like you would do with a .mesh, but with a .glb (binary, self enclosed with it's textures and other data) or .glTF

glTF can fundamentally be used to represent a whole scene with multiple objects and everything, it's not my main interest (I want a standard workflow for getting 3D objects (mesh, material, textures, animation) out of something like Blender and getting it into Ogre), but I know some people would want to use something like Blender as a "scene editor" (like with the good old .scene format) so i'll put that on the TODO list once I get the rest sorted out.

I have other things to work one beside this (college stuff),

I'm setting up this thing to track work on this, I'm new to trello, but it seems pretty nice :

Re: Loading industry standard model formats

Posted: Thu Jul 12, 2018 10:17 pm
by Ybalrid
Hey guys, I made some progress this past week or so (finally got back to it), on my glTF 2.0 loader for Ogre 2.1: It is now able to load skeletons and animations (for single item files. I'm interested into an alternative solution to .mesh files, not a scene loader or anything like that)

Now, I'm basically need to do 2 things:

1) plug the loading through Ogre's Resource Manager, so that you can have your .gltf+resrouces/.glb files inside ResourceLocations as you do with everything else in Ogre (I hacked around it in my game engine to store game-play scripts and audio files and retrieve them that way, so I know more or less how that works). I also want to play around with Ogre's plugin interface to make it a bit easier to use (right now it's just an additional DLL that you need to link to, and call stuff manually).

2) Throw more glTF files to it, and see what breaks, because there's probably a lot of bugs and edge cases to squash ;-)

I'll keep you up to date with that on the forums. If anybody's interested into following this closely, all the links are in the previous message (and I tend to ramble on Twitter quite a lot :mrgreen: )