Blender26 Ogre Exporter

[cyrfer]

It looks like a .bullet export I make from my Blender scene and the (OGRE) .scene export have different initial transforms.

Does anyone know where in the script the position values are being modified? I think the script is trying to "help" me by transforming into "ogre's" coordinate system. I'd like to disable this so that a position in Blender = position exported.

[bstone]

You don't have to modify the script for that. There's an option for mapping XYZ to something else. Select XYZ and it will leave the coordinates as is.

[cyrfer]

Hi bstone,
That is great news! Can you tell me where I can find that option in Blender's interface? I have looked, but I've not been successful. Thanks.

[bstone]

It's right on the Export Ogre panel. See "swap axis". It's there on the second row.

[brunobg]

I'm still facing problems with exporting a mesh with a skeleton. Even after adding a RootBone at 0,0,0 and making it parent of the bone hierarchy, I get "ERROR: Mesh (polySurface6): is offset from Armature - zero transform is required". When I open it in OgreMeshy the mesh is offset from the skeleton (the skeleton is positioned at the origin as expected, but the mesh itself is translated).

meshy.jpg

I'm using blender 2.61 with exporter 0.5.6preview 8. Any tips?

[Waruck]

your mesh propably has some global transformation in blender (which is ignored by the exporter). just do the following:
- select your model in object-mode
- press ctrl+a (apply) -> l (location)
this applys any local translation to the local coordinates.

(maybe the skeleton is tranlated too, but since you said the skeleton is exported as expected the problem should be the mesh, but doing the same with the skeleton can't hurt)

You also don't need a root bone at (0.,0.,0.) anymore with the new version hartsantler posted some time ago.

[cyrfer]

It's right on the Export Ogre panel. See "swap axis". It's there on the second row.

Wow. I never noticed all those options after clicking File->Export->OGRE3D. Thanks for the help!

[Homer Johnston]

Hopefully this is something dumb on my part, but the exporter doesn't seem to be creating a .skeleton for me. Running Blender 2.62 and Blender2Ogre 0.5.5... here's a screenshot after running a test export: http://dl.dropbox.com/u/4621600/Ogre/Blender2Ogre.jpg

Are there any specific prerequisites I need before it will create a .skeleton file? Appreciate any help!

[duststorm]

Are there any specific prerequisites I need before it will create a .skeleton file? Appreciate any help!

I think you need to apply an armature modifier linked to the armature to your object.

[Homer Johnston]

That was it. Thanks for the help!

[sockpuppet418]

I have used the blender2ogre-0.5.5 script to get models into blender.

Now I am wondering if this script will help me port object animation from blender to Ogre.

Can I export a time series of camera location and object locations?

At the beginning of this post is a note that talks about "real-time streaming of object location and scale into RealXtend Tundra2" so I am hoping this is close.

Am I in the right place?

Thanks!

[Arkiruthis]

Just a heads-up to anyone upgrading Blender. It seems the new Blender 2.63 B-Mesh functionality breaks the exporter. Going back to 2.62 is fine.

The script complains that object has "no attribute called faces", which makes me think it's the new B-Mesh functionality that's changed things.

[Pidigi]

Just a heads-up to anyone upgrading Blender. It seems the new Blender 2.63 B-Mesh functionality breaks the exporter. Going back to 2.62 is fine.

The script complains that object has "no attribute called faces", which makes me think it's the new B-Mesh functionality that's changed things.

Same here:

File "C:\Users\Claudio\AppData\Roaming\Blender Foundation\Blender\2.63\scripts
\addons\io_export_ogreDotScene.py", line 4296, in dot_mesh
Report.faces += len( ob.data.faces )
AttributeError: 'Mesh' object has no attribute 'faces'

[Waruck]

The problem here seems to be, that with 2.63 Blender introduced support for n-gon faces in its BMeshes. Before only trinangles and squares were supported, now any number of vertices per face.

http://wiki.blender.org/index.php/Dev:R ... 2.63/BMesh

With this came some name-changes of the variables/functions to access the data inside the BMesh and that's why all scripts written for 2.62 and before will fail with the new version.
The Problem however is that Ogre only works with triangles, so the new faces with n-vertices have to be split in triangles. However this can be done in multiple ways and I'm not sure if there is a general best solution for this. Up to now squares were split in 0-1-2 and 0-2-3. For more than 4 vertices one has to consider to devide them into something like a triangle-fan or a triangle-list, but since these n-gons support concave geometry there is no easy way to find a real solution for the division. (I'm not sure yet that there even is a polynomial sollution for this problem).

I haven't tried 2.63 till now, but I have to say that the Bevel and (Limited) Dissolve tools look quite interesting to me. Unfortunatly it looks like the limited dissolve tool will quite certainly create faces with more than 4 vertices.

If I find the time I might try to update the exporter to 2.63 but I'm still not very good at python-programming and also the weather looks like I don't want to spent too much time indoors this weekend

[f00bar]

Read the Edit at the end, for exporters there is an even easier way to update.

Just in case somebody has time to do the update. I already updated other scripts for blender 2.63. The changes needed should be minimal if choosing the easiest route. However, with the easy route the problem is that accessing the UVs is much slower than with earlier blenders (10-20 times slower). There are 3 APIs to access the mesh info, so maybe the not so straight forward ones are more efficient.

What I did was:

Code: Select all

#check somewhere if you are in a BMesh blender:
    global isBMesh
    try:
        face = mesh1.polygons
        isBMesh = True
    except:
        isBMesh = False

#use this two functions to get faces or UVs:
def faces(mesh):
    if isBMesh:
        return mesh.polygons
    else:
        return mesh.faces

def uvs(mesh, f, F):
    if isBMesh:
        uv_loops = mesh.uv_loop_layers.active.data
        lstart = lend = F.loop_start
        lend += F.loop_total
        return [uv.uv for uv in uv_loops[lstart:lend]]
    else:
        return mesh.uv_textures.active.data[f].uv

The uvs function could be updated to only need parameters mesh and F instead of the ugly one I use (f is face index, F is MeshPolygon, but you should be able to get face index from F in the non BMesh case (then F is a Face)).

About triangulating the n-gons: as I proposed earlier it is maybe better to just call the triangulate operator of blender on a copy of the mesh before exporting. Would simplify the code of the exporter. And if I remember correctly, the exporter copies the mesh anyway before exporting in many cases. And I assume the blender operator is written in c++, so it is maybe even more efficient.

[Edit:]
If you look at the BMesh API, you can also get the data in format compatible to the old data (meaning n-gons are transformed to quads and triangles, aka bpy.types.MeshTessFace). This route is even easier. See here: http://www.blender.org/documentation/bl ... tion-faces Read this, it explains how to update exporters.
I could not use that in my case because my script needed the n-gons as n-gons.

[cadabra]

I have a few problems with the armature animation export. Here's my .blend: http://dl.dropbox.com/u/364980/AR.62k.blend

- I can play back each NLA track individually in blender. When I try to play a single track in Ogre, it plays all of them.

- If I export with the default swap axis setting (xz-y, IIRC?), my mesh and armature end up oriented differently and all animations are broken. Like this: http://i.imgur.com/AyHOQ.jpg. If I export with xyz, they're good, but I need to adjust the scene node programmatically. I've checked that all location/scaling/rotation settings are fully applied on both the mesh and armature.

- I'm trying to animate compressing front shocks on a bike by moving the wheel and pistons up and down. In Blender, I can do this by animating the scale of a bone (parent of the shocks) and setting its child bone (the shocks (which is a parent of the wheel)) to not inherit scale. Looks good in Blender, but once exported to Ogre, the child bone still scales. So my wheel scales when the shocks are compressed. :-/

- I tried to work around the above scaling by removing the parent bone and just animating the child bone's location instead. So now the shock bone and wheel aren't directly connected to the rest of the armature hierarchy. This made animations go away altogether. Ogre still sees the animation tracks, but nothing's animating. Is there any other way I can animate compressing shocks?

- Is there any way to invoke the exporter from my build system? Having to export through blender every time I make a change is really tedious. :/

[duststorm]

60K polygons, are you sure that's a good idea?
It looks a bit heavy to be used in a realtime application.

(sorry for off-topic )

[cadabra]

Ha, yeah. Just using it while I work out the details. I can render a bunch of those, until I start animating. Software skinning that thing hurts. I have the same issues with simpler setups. Here's the upside down armature:

[Waruck]

@f00bar: thx for your hint, I'll definetly have a look at it if I find the time for it.

@cadabra: what version of the exporter are you using? there had been a problem with the rotation-matrix for the root bone in xz-y-mode (since bones are relativ to their parents only the root-bone hat to be rotated, that's why the rest of the skeleton looks correctls). For a fix and a little bit more explanation read this post and the followings http://www.ogre3d.org/forums/viewtopic. ... 75#p451546

[cadabra]

@Waruck: I'm using blender 2.62 + the latest exporter from source: right here. I checked my installed script and it has your fix:

Code: Select all

            if CONFIG['SWAP_AXIS'] == '-xzy':      # Tundra1
                self.flipMat = mathutils.Matrix(((-1,0,0,0),(0,0,1,0),(0,1,0,0),(0,0,0,1)))
            elif CONFIG['SWAP_AXIS'] == 'xz-y':    # Tundra2
                #self.flipMat = mathutils.Matrix(((1,0,0,0),(0,0,1,0),(0,1,0,0),(0,0,0,1)))
                self.flipMat = mathutils.Matrix(((1,0,0,0),(0,0,-1,0),(0,1,0,0),(0,0,0,1)))	# thanks to Waruck

I'm still stumped about the animation issue. My Ogre app (and Ogre Meshy) plays back all tracks even if I just select one. I probably messed something up in blender, I'm pretty new to this.

[Waruck]

ok, I changed the .faces to .tessfaces and had the script calculate the tessfaces before trying to export a mesh (otherwise the tessfaces-list could be empty). This is done in line 3196.

Quick test with the new n-gons:


I don't guarantee the correct working of all the exporter's functions, this is just a quick fix for the new n-gons. I'll have a deeper lock at it during the next week.
Also notice that the license of the original script from Hartsantler found in the first post of this thread still apply

edit:
see this post: http://www.ogre3d.org/forums/viewtopic. ... 58#p457758

[Waruck]

@cadabra: the reason why your animations are played all simultaneosly is because you have them at the same frames in your nla-editor. All strips go from frame 0 to 60 and therfore influence each other. the script only takes the strip for the extends of the animation and then looks how your bones are moved in each frame in the whole armature.
To have independent animations just move the strips so they don't overlap anymore (animation1 from frame 0 to 60, animation2 from frame 61 to 121 and so on....)
If i recall correctly there also was a certain order needed (from top to bottom or vice versa). I'm not sure about that right now, but you can also put all strips in just one nla-track and put them after each other. (you may want to make sure to have 1 frame free between each strip!) That's how I arrange my strips

[cadabra]

Ahhh. Thanks! That works. I'm going with all strips in one track. It doesn't look like any in-between frames are needed.

I was under the impression that each NLA track becomes an Ogre track and that you can put any action strips you want in the NLA tracks. Since Blender offers the functionality of playing each track individually, I just assumed that would naturally map to Ogre's tracks. Mapping Blender strips to Ogre tracks works, but it seems like it's going against Blender's intentions, doesn't it? Maybe there's something I don't understand, I'm new to this.

[Waruck]

the in-between frames might not be needed right now because currently there is another issue with the exporter that was discussed previously:
currently the exporter exports one keyframe at the beginning of each frame of the strip, but this means from the beginning of the last frame to the end of the last frame (1/22 sec since blender works with 22 fps) there is no keyframe exported and it seems that ogre interpolates back to the first keyframe in this case. for looping animations this looks fine, but for animations that need to end in a different pose than they had started this is a problem.
The fix for this problem is to tell the exporter to export one more keyframe at the end of the strip, but it might cause some trouble if the end of the strip is also the beginning of the next strip.

I'll try to have a look at the exporter next week to see if it is possible to export the single nla-strips directly even if they overlap. Although it makes sense to keep the possibility of combining animations in Blender this feature is currently hamstringed by the fact that the length of the exported animation is given as the length of a single stip so you can only combine animations in this way if one is completly played in the length of the other.

[Waruck]

update:

if run into the same problem as cadabra, that my skeleton was upside-down in xz-y mode in the new blender version. To fix this one has to simply change the flip-matrix:
from this:

Code: Select all

self.flipMat = mathutils.Matrix(((1,0,0,0),(0,0,-1,0),(0,1,0,0),(0,0,0,1)))

to this:

Code: Select all

self.flipMat = mathutils.Matrix(((1,0,0,0),(0,0,1,0),(0,-1,0,0),(0,0,0,1)))

I don't know why it has to be the other way with the new blender version. I'm never sure when defining a Matrix as a vector of vectors and usually try-and-error ... ^^

edit:
I've added a new version of the exporter which should completly work with blender 2.6.3. I hope hartsantler forgives me, that I've started a new version number, but I think a new version of blender needs a new version of the exporter. I've tested it with my models and ogre-applications and everything worked fine for me.

Version 0.5.7. prev.1

Changes:
- Updated support to Blender 2.6.3.
- fixed the skeleton rotation in xz-y-mode (again)
- added an extra keyframe at the end of each animation to correctly support non-looping animations.
- added an option to export only deformable bones (will cause errors if deformable bones have non-deformable parrents)
- added an option to export animations independently from each other. (doesn't work for shape-animations yet)