Loading industry standard model formats

What it says on the tin: a place to discuss proposed new features.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Loading industry standard model formats

Post 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.
User avatar
bvanevery
Goblin
Posts: 218
Joined: Wed Feb 28, 2007 4:54 am
Location: Asheville, NC
x 7

Re: Loading industry standard model formats

Post 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.
tbz
Halfling
Posts: 60
Joined: Mon Jul 30, 2012 4:49 am

Re: Loading industry standard model formats

Post 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?
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Loading industry standard model formats

Post 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.
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Loading industry standard model formats

Post 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.
tbz
Halfling
Posts: 60
Joined: Mon Jul 30, 2012 4:49 am

Re: Loading industry standard model formats

Post by tbz »

Kojack wrote:OgreMax can export node animation.
Yes, too bad it doesn't work :|. At-least, not for my models.
User avatar
Mind Calamity
Ogre Magi
Posts: 1255
Joined: Sat Dec 25, 2010 2:55 pm
Location: Macedonia
x 81

Re: Loading industry standard model formats

Post 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.
BitBucket username changed to iboshkov (from MindCalamity)
Do you need help? What have you tried?
- xavier
---------------------
HkOgre - a Havok Integration for OGRE | Simple SSAO | My Blog | My YouTube | My DeviantArt
User avatar
Thoran
Halfling
Posts: 94
Joined: Mon Dec 01, 2008 2:04 pm
Location: Germany
x 1
Contact:

Re: Loading industry standard model formats

Post 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.
cloud
Gremlin
Posts: 196
Joined: Tue Aug 08, 2006 6:45 pm
x 14

Re: Loading industry standard model formats

Post 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.
User avatar
Aiden
Halfling
Posts: 54
Joined: Fri Jul 14, 2017 3:16 pm
x 5

Re: Loading industry standard model formats

Post 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 http://www.ogre3d.org/tikiwiki/tiki-ind ... 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.

WE SHOULD MAKE THIS INTO A PLUGIN COMPLETE WITH A REPO
User avatar
Ybalrid
Halfling
Posts: 89
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 31
Contact:

Re: Loading industry standard model formats

Post 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.

https://github.com/Ybalrid/Ogre_glTF

Image

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 : https://trello.com/b/TFl8tJMX/ogregltf
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
Ybalrid
Halfling
Posts: 89
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 31
Contact:

Re: Loading industry standard model formats

Post 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: )
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