Blender 2.5 Exporter [Official]

[lf3thn4d]

[s]Hey guys, since Blender 2.5 has gone into RC phase, I'm starting to plan out on the new official blender 2.5 exporter for Ogre. I know this is a long time coming, but I'm a very busy man and have real life and work issues to attend to. Hence I will not be able to commit to this full time. However, I've planned to set aside at least a few hours once a week to have some progress! As this will be a from scratch implementation, I intend to make it as manageable and extensible as possible.

I do understand that there's an unofficial exporter that integrates with the dotScene export. The official exporter will not be a dotScene exporter however and will solely focus on providing excellent mesh exporting. One of the feature I would like to bring back from the 2.49 exporter is the custom material template feature. Now that the new blender has better UI system, we would be able to extend this feature to be a much more mature and user friendly state.

Before I get started, my first move is to draft out the UI placement and also a rough back end script ERD. I will be posting my designs up on the wiki which I will link-in here later. Hopefully by doing so, we can have a much better feedback and probably also some helping hand on the development of the export script.

That being said, stay tuned for the next official blender exporter![/s]

After much wait, the exporter is now partially usable. Hence I've started a development release build.

What the exporter does:
- Similar workflow as the old blender 2.49b exporter.
- Per-mesh export settings or use global settings.
- Default export to use shared vertex buffer for all submeshes. (the most optimal choice)
- Sub-mesh naming and shared-vertex-buffer settings. (Submeshes are defined base on Material Slots - To create multiple submesh of the same material, just create multiple Material Slots that points to the same Material)
- Per-object export logging.
- Parallel XMLConverter execution to utilize multi-core cpus. (limits to the number of cores on the machine)

What the exporter doesn't do YET:
- Skeletal animation export
- Pose/Morph animation export
- LOD export

What the exporter will NEVER do:
- Dot scene exporting.

Wiki link: http://www.ogre3d.org/tikiwiki/Blender+2.5+Exporter

DOWNLOAD:
- 2.0.3 - ogre_mesh_exporter_v2.0.3.zip (21/10/2012) - tested with Blender 2.64a

Install instruction:
Manual way:
1. Unzip content to [blenderInstallPath]/[blenderversion]/scripts/addons
2. File -> User Preferences... (Ctrl+Alt+U)
3. Find Ogre Mesh Exporter (under Import-Export category) or use the find text box.
4. Click on the checkbox in the top right corner of the addon item to enable the addon.
Blender way:
1. File -> User Preferences... (Ctrl+Alt+U)
2. Goto Addons tab
3. Click on [Install Addon...] button at bottom of window
4. Find downloaded zip file and click [Install Addon...] button
5. Click on the checkbox in the top right corner of the addon item to enable the addon.

[zeromath]

w00t I never used b25 because it counldnt export .mesh like b49

[Shockeye]

Great news.
Blender 2.5 has some great features which I can't use yet.

[xieu90]

[Sadr]

To my knowledge, there were at least two different Blender 2.5 exporters being worked on at one point. I suppose you're referring to this one:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=61485 by "hartsantler" and "SRombauts" (++?)

But there was also this other one:
http://www.ogre3d.org/forums/viewtopic. ... 0&p=403392 by Tony Richards
though it seems to have lost traction pretty early on.

I just hope some joined efforts can come out of this.

Could anyone please explain; do the different approaches (dotScene or not) truly merit different exporters, or could these two efforts theoretically be merged into one?

[lf3thn4d]

Thanks for the feedback guys. It's great to hear interest in this. I'll be posting an initial UI plan on the wiki to give an idea of how the interface will work. Would love to hear feedback on it so I'll know if I'm going the right direction.

@Sadr: Yes, I just found out that there were actually two. As far as I could tell, the one that lost traction earlier on was an intention to bring up an initial exporter for 2.5. Personally I would like to have some sort of joint effort to come out of this, however, it all depends on how the exporters are developed. Do note that the attempt on this new exporter is to provide an actual official blender 2.5 mesh exporter for Ogre. Base on what I've inspected on the dotScene + mesh exporter script, it's more geared towards a specialized exporter that is focused at unified dotScene + mesh export experience. This is a good concept however dotScene is not an official ogre format so it would not make sense to make it as part of the official exporter. The second reason for bringing up this attempt is also focus. I believe a smaller focus such as just handling mesh/material exporting is crucial for the future development of other ogre based export/import scripts. With all due respect, I believe not everybody is using the dotScene format but all ogre users would need a mesh exporter. That said, it is all the more important to have specific exporter that does what one wants instead of an exporter that clutters the blender UI with many other unused components. From what I can tell, imho, the dotScene + mesh exporter though a rather good and impressive effort, is badly structured with all code in one single big file bloat. This is far from ideal if any joint effort is to happen. However, I'm open to ideas and suggestions if it makes sense and shows good directions. I hope this answers your question.

[jacmoe]

The best part: it's official.

[Sadr]

That explains it perfectly lf3thn4d, thanks a bunch. I'll be sure to send a lot of testers from the jMonkeyEngine community your way. I'd also like to have some discussions about the OgreXML format in general, so expect to hear from me in that regard as well.

~ erlend_sh

[lf3thn4d]

lol. yes jacmoe, that's the best part. hehe.

That'll be great Sadr, I'm looking forward to having more feedback . Do note though that the xml format isn't my role. We might have to bring in the core ogre engine guys to hear any suggestions being feasible or not. In either case, it'll affect all exporters that uses the xml format so that will be something outside of the scope of the blender exporter. But shoot them anyways, the more feedback on the tool-chain the better.

[Shockeye]

From what I can tell, imho, the dotScene + mesh exporter though a rather good and impressive effort, is badly structured with all code in one single big file bloat.

And don't get me started on the fixed locations for the the dependencies on C: drive!

[shadowfeign]

wow official? really? arrogant much? how bout you drop the official bit until it actually is, which based on your ego, I doubt you'll ever have a free enough license to make it official, assuming you even make an exporter, which so far I haven't seen anything from you, I think I'll stick with the ones that work.

[lf3thn4d]

@Shockeye: Really? wow I never knew that. lol
@shadowfeign: You probably don't know but I'm actually the official maintainer for the Blender 2.49 exporter. It would do everybody good to stop judging and do your research properly before you start flaming on the forums. We don't want trolls here but people with constructive criticism. And yes, I'm dead serious about an official implementation in the spirit of the old blender 2.49 exporter. Really sorry if I hurt you and seemed to have made myself look like an ego douchebag to you. Personally though, I don't see the point in trying to flesh my ego on an opensource community. I'm here to provide contributions, not show off.

P.S. I've posted an initial mind dump sketch of UI placement in the wiki. I'll work on some scripted mockup after this. Once we get the UI part decided, I'll focus on the actual basic mesh exporting (without material & animations) first.

[shadowfeign]

haha, well paint me an ass, sorry.

[lf3thn4d]

Apology accepted. I would love to also hear from any of your suggestions or comments when we have something to show. I'm hoping that we will have at-least the basic mesh exporting done by end of this month base on my current time available.

[shadowfeign]

well I don't know what your opinion is of correcting rig problems, some I think could be taken care of potentially? but perhaps it might be better to just train people to rig things properly with games involved? some things would probably be simple like applying transforms, but other issues like the rig being in a weird hierarchy because of control objects when creating things like reverse foot rigs or whatever, or other features that aren't usable in .mesh . my first thought was to try creating something that grabbed the bone data from skin(thinking in max terms, sorry primarily a max person. I do all my testing stuff in max, then try to duplicate in blender) and create a bone chain with those, if there are reversed order bones, try to flip them around by checking if they stay fixed to that point somehow. same kinda thing if the bones aren't actually in the same chain, try to figure out if they are and link them.

perhaps this would be better done as a prep tool before the exporter though.

[lf3thn4d]

Yeah, rigging is one of the big issues especially when it comes to exporting for games. One of the biggest problem is blender do not have a way to limit max bone weighting limit. As for extra control objects and what not, I think it's part pre export tool and part tool feature. There are cases where we do not want to export a particular bone because it's actually a control bone. In that case, the exporter need some way to identify which bone not to export. I think this is important since for any proficient animator, they would want as many armature control features to build fluid animations so stripping off such possibility due to exporter limitation would be a bad idea.

So yeah, some features should be a pre export blender tool and some part should be the export feature.

[jacmoe]

haha, well paint me an ass, sorry.

It means that it goes directly into the Ogre source tree.

[tp]

I started work on a Blender Ogre exporter last fall, but ran out of time then. It was based on the work at https://code.google.com/p/blendogre/

I added skeleton and animation export and did some initial material stuff as well. I think the design is pretty nice and modular, and I would be happy to share what I have if there is interest.

As for the design, I think it should take advantage of all that is available in Blender, and integrate with the regular work flow as much as possible. Re-exporting whatever you have in a .blend file should be as simple as possible, basically just running a blender script operator. All configuration should happen as a side effect, based on settings that you have in place for the export and individual objects.

Currently, my script exports animations based on a skeleton, and determines skeletons that meshes use by parent relationships (i.e. a mesh links to a skeleton file that it gets from the armature object, and multiple meshes can use the same skeleton). The actions that are exported by a skeleton are defined in the object data panel of the armature. You can also override the name of the .skeleton file there, and all exported skeletons and meshes respect that (an empty value defaults to the name of the armature, due to some limitations in the Blender API).

ArmatureOptions.png

The same applies to materials, but my implementation is currently quite limited:

MaterialOptions.png

For materials this can become tremendously powerful, as you can then set up multiple materials that map to a common file, generate materials/programs from a shader tree and so on.

There's an operator for the export, that you can reach from the space bar menu:

MenuInvocation.png

This allows you to just hit [space], [enter], [enter] to re-export with current settings. Of course, the re-export could be made even easier by giving it a dedicated action that you could just hot key or put into the tools panel.

Any customizations you need to do for the entire export are in the export operator's panel. This appears when the operator is invoked, before it is executed (for details, see the blender operator return states).

[tp]

And a screenshot of the master export operation option panel:

InvocationParameters.png

[lf3thn4d]

Awesomeness tp, I think you and I are on the same page on how the exporter should work. Each settings on it's individual object's property page except for the global export settings such as the xml converter path and export path. I'm not too sure about the bone weight influence stuff though, I think that should be a tool outside of the exporter. It'll be better for the artist to be able to see the exact applied blend weight in blender when animating their models.

Once I get some general setup done, you're more than welcome to port some of your work over. That way it will help all of us and your hard work won't go to waste as well. If not, I could probably take my time to port your work when I'm ready for it. But as we all know, all of us are busy man. If everybody can contribute a little of their time, this exporter would be up and ready much faster.

[GenesisRage]

im torn on the idea of having setting on the object properties themselves.
i think having them on the object is good, but thinking maybe global setting as well... that could be used as a fallback or default setting.
(e.g. you have several objects that require the same settings, you could set them globally, and objects that have individual settings would just ignore the global ones)

[lf3thn4d]

Hmmm.. yes that's a good point. We should have a default fallback setting for the object's property. I'll see if that's possible with the UI.

[tp]

There should be no reason why you can't just select multiple objects and set properties on all of them at the same time, just like Blender works with every other setting it supports. The way blender ID properties (which is what export settings would be) work is that you create a property and it applies to all objects of the given type. I.e. if you give the material type a "target file" property, all materials will have it. The property can be given a default, but I don't think it can be changed afterwards.

In general, it takes a minute to set export properties on an object and hours to create the object, it's much more useful to make re-exporting as easy as possible than worry about shared defaults. It is very confusing also from a UI design standpoint to have a property defined in multiple locations, which may or may not override each other.

[lf3thn4d]

Hmm.. you can modify multiple object's properties all at once? From what I've tested, Blender seem to have a target active object within a selected group of object. The properties tab only shows property of the active object. Not the whole. But I do agree with you that it may be sometimes confusing to share defaults. We have to think this through carefully. Sometimes it may be desirable to have some sort of default or shared export property E.G. Tangent generation.

[jonim8or]

Hmm.. you can modify multiple object's properties all at once? From what I've tested, Blender seem to have a target active object within a selected group of object.

Depends on what property you want to set. The properties in the properties panel are only of the active object. So applying a material to multiple objects can't be done by selecting multiple obejcts and then applying a material in the materials panel.
But other things, like moving or rotating can be done for the whole group.