Blender 2.5 Exporter [Official]

[jacmoe]

What is it you want from the meshes exporter?

Given that there is no scene format for Ogre, you'd need to tailor it to your own needs - there are as many dialects of the so-called 'dotscene' (.scene) format as there are importers and exporters.
All the scene exporter needs to do is iterate over the selected objects and get their position/orientation and any userData they have attached.
The old scene exporter did that - and you could change it to suit your needs.
Or use your own.

A sample scene exporter would be nice, though.
Without being embedded in the meshes exporter.
The difference is that the Ogre .mesh format is a official format.

[antont]

Err, and it is the official .mesh format that blender2ogre for 2.5 writes.

I just want good exports, of meshes and materials etc. And scenes, but that can sure be separate.

[jacmoe]

@Antont:

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

That's what Lf3thn4d wrote about the other efforts and what's the focus here.
I agree on all points.

That doesn't mean that some of us can't cook up a starter kit for scene export. (separate, of course).

[antont]

Yep, and that's why I asked if it'd be a good idea to separate the mesh and scene exporters there. So we'd get a already working mesh export for 2.5 that everyone could use, and it wouldn't have to be rewritten. We can help with that if it seems like a good idea.

I think it's all about the quality of the code, the approach used to do handle the Blender data, what lib is used to write xml and how etc. Haven't looked in such a detail myself.

[Sadr]

I don't mean to take away from Lf3thn4d's efforts, but try see this from the outsiders' perspective: Blender2Ogre works, the code is openly out there and actively progressing. The official exporter on the other hand is still in the ever equivocal planning stage. Many developers need the WIP to go stable yesterday, so I can see how a merger, effectively slapping the "official" sticker on the currently working exporter, would ease the mind.

But as far as a merger is concerned, the cons seem to far outweigh the pros. I will still argue however, that some greater effort could be made to accommodate prospective co-developers like tp and quismo here. Making code (-repo?) available for starters.

Also Lf3thn4d seemed to have a nice step-by-step plan in mind for key features (mesh export -> skeletal export etc.). Can we expect test-releases for these milestones? I could surely find some testers in the jMonkeyEngine community as soon as such a release is made available.

[jacmoe]

I don't mean to take away from Lf3thn4d's efforts, but try see this from the outsiders' perspective: Blender2Ogre works, the code is openly out there and actively progressing.

That is not the philosophy behind Ogre - that if it 'works' it goes into the code base.
If it's poorly put together, then it's not worth pursuing.
I mean no disrespect in saying that - it's just that the official stamp requires just a bit more.
Keep in mind that this is not really the 'real' official Ogre Blender exporter just yet.
The one in the sticky is the official - this is the preview.

But, of course, more developers are welcome.

[GenesisRage]

also i would like to point out, the blender2ogre is being actively developed, but many ui elements and features break between releases.
i dont know if lf3thn4d has a "magical" way of exporting, but for many ppl speed is an issue, i have a mesh and with his exporter (2.49) takes 0.3 seconds to export, where blender2ogre takes 6 minutes to export the same mesh.
with that being said, it would be nice to have a .scene exporter with "official" but as many use a custom format (because there isnt a standard), having a 3rd party non-official plugin that extends lf3thn4d's exporter would be perfectly fine for me. if the exporter could be setup this way, i see it being more beneficial, as 3rd party could write their own (proprietary even) format for .scene

[Thoran]

Without taking position for any of the exporters discussed here, I find it rather strange, that a official exporter is tried to actively being enforced, already in advance oc completition of any one exporter. Why not let things evolve and once everything has reached a state it can be considered to be made official then label it so. To be honest and similar to jacmoe I say that without disrespect, I can't see anything in a "official" state anyhwere so far. And finally in most cases it is always the community that decideds in an implicit manner what is used.

Please forgive me if that was too much offtopic now.
My 2 cents.

Thoran

[spacegaier]

Okay, before this gets out of hand, let's please agree on and understand the following points:

• 1. In the past, the exporter of lf3thn4d was the most complete and used one and resided in the official Ogre repositories wihch made the team give it the label "official" back then. The fact that now there are multiple exporters emerging in parallel is in my eyes a good thing and I really think we should not focus on the naming/labeling right now, but rather enhance all the exporters to get them to a really usable state. Everybody can then decide on their own which one to use based on personal preferences, functionality or whatever.
  []
• 2. At a future point in time, someone might then again start this labeling dicussion, if he or she still feels the need for it, but right now we are discussing about tools that are still in development and this argument is not helping anyone, but slowing things down if anything.
  []
• 3. So for the time being, please let's just stick with the names in order to make it easy for everyone to follow which tool is talked about in which thread and focus on the exporters itself. Everything else would just be plain silly...

[Thoran]

[*]2. At a future point in time, someone might then again start this labeling dicussion, if he or she still feels the need for it, but right now we are discussing about tools that are still in development and this argument is not helping anyone, but slowing things down if anything.

Actually that was my point, even though I might have expressed it in a complicated way.

Thoran

[Sadr]

Agreed. Was not my intention to derail the development or in any way add coal to the fire.

Keep up the good work!

[jacmoe]

'Official' means that Lf3thn4d has been given the rights to push to the Ogre repository.

[merlinblack]

I really like the idea of being able to easily drive the exporter either from the GUI or from another script. For instance I use Lua scripts as my scene/level/whatever files which I generate from a blender python script, and it would be great to ask the mesh exporter to export the mesh for each object automatically.

It's a popular design pattern to divide things into a front-end and a back-end at any rate.

[zeromath]

Hey guys any update?

[antont]

Brett said yesterday (on irc) that he had improved the mesh exporting in the blender2ogre exporter, cleaner code and reportedly about 100x faster now :p

He was preparing it for new release and said that will post info then.

[zeromath]

Will this exporter be using ogre 1.7?

[merlinblack]

Will this exporter be using ogre 1.7?

My guess is that as the exporter will be writing XML and using whatever version of OgreXMLConverter you have installed. Therefore it will be compatible with any, or at least most, versions.

[zeromath]

ok, the latest version I was able to find was 1.63...is there a 1/7 version or is this really the latest version?

[LiMuBei]

As merlinblack said, the xml converter is the only thing version specific here. So the exporter will work for almost everything. Get the 1.7.3 command line tools with the newest OgreXMLConverter and you're good to go.

[zeromath]

Hey guys any update? I know the developer is busy, but is there any news or anything?

[Mind Calamity]

While the "official" exporter is at halt, the unofficial and working exporter with a whole lot of features is progressing every day.

Why don't you guys just join powers and work on one exporter for the greater good ?

[Sadr]

While the "official" exporter is at halt, the unofficial and working exporter with a whole lot of features is progressing every day.

Why don't you guys just join powers and work on one exporter for the greater good ?

I asked that same question a while back and received a complete answer:
http://www.ogre3d.org/forums/viewtopic. ... 19#p424339

If the other exporter fulfills your needs, use that

[Mind Calamity]

While the "official" exporter is at halt, the unofficial and working exporter with a whole lot of features is progressing every day.

Why don't you guys just join powers and work on one exporter for the greater good ?

I asked that same question a while back and received a complete answer:
http://www.ogre3d.org/forums/viewtopic. ... 19#p424339

If the other exporter fulfills your needs, use that

Yeah, thanks, that got my question answered.

I know that the interface of the Blender2OGRE exporter is kinda bloated at first sight, but once you get used to it, it all makes sense

But lf3thn4d wants minimalism and usability, for which he is right but Blender2OGRE's development is a lot faster and now they don't have the C:\ drive dependency and a lot of the features have been improved and a lot of the bugs fixed.

But then again, it all comes down to preference.

[lf3thn4d]

Hey guys, Just to update, I've been getting my hands on every free time I have for the new 2.5 exporter. I must say it's a little frustrating for me as I thought the new python api would allow us to write more robust scripts. Unfortunately they still do not have a good event handler system (I.E. Selection event to detect when selection changed) and also no way to keep a reference Object(ID) in their RNA property other than just the object names as strings. Looking for possibilities of these have wasted quite a large amount of my time.

Hence, the new exporter would be quite similar to the old exporter. We will still need to click on the refresh button to have a proper listing of the meshes we will be exporting. I've decided to give up on the search to have a more automatic method. I'm pretty sure it doesn't exist yet. Hopefully in the future the blender team will add some API for such use case.

Here's the update of what the exporter screen looks like now:

[xieu90]

nice update ^^