Page MenuHome

Collada - up_axis not processed
Closed, ResolvedPublic

Description

It seems that collada importer in new Blender 2.56 is not processing the "up_axis" field from .dae files.

When using something different from "Z_UP" (which is what Blender uses for up axis), then the imported model is not rotaded so that up axis matches what is in .dae file.


OS: Windows 7 64
Blender build: 2.56.0 r33949 win32 & win64 (official)

Attached files:
pyramid_Z_up.dae : Pyramid made from cube (top face shrinked so that pyramid summit is in Z direction in Blender), then exported to .dae from Blender.
pyramid_Y_up.dae : Pyramid made from cube (right face shrinked so that pyramid summit is in Y direction in Blender), then exported to .dae from Blender, and edited to replace "<up_axis>Z_UP</up_axis>" with "<up_axis>Y_UP</up_axis>".

When importing back the modified pyramid_Y_up.dae file, the model is not changed/rotated at all, and the summit is in Y direction, not in Z direction as it should be (fromm what I understand from up_axis in Collada.

Note: I used "Collada loader" (http://www.gamedev.net/community/forums/topic.asp?topic_id=450761) to check the files, and it loaded both files with pyramid top upward.

Details

Type
Bug

Event Timeline

Assigned to Nathan.
Do note that a missing feature in importers doesn't necessary make it a bug, only when it was intended to work. Collada has a multitude more features than a person can code in a life time... well, so it seems ;)

the collada definition of up_axis is "This element specifies which axis is considered upward, which is considered to the right, and which is considered inward." Collada also says in fora that it every tool is free to support selected up-axis's.

When importing there are several ways to overcome this problem:
a. export/import using the axis both should support. (in case of blender this is z-up)
b. export in a different axis, convert using a pipeline tool like Collada Refinery
c. create an xlst document for intermediate transformation (for experienced pipeline integrators)

if you can't do A, do B if B fails do C. I wouldn't recommend to support this option during importing of a file as Collada in Blender as it has many not well documented usages.

Do you agree Ton, Nathan?

Ok guys, i can see your point. If it's optional feature you're perfectly right to support it or not.

But I think not supporting it reduces the interest of collada importer in Blender, because that means you cannot import directly data exported from other 3D tools that use something different from Z for up axis without additional manipulation that - I think - are not that easy for average user...

Please do not consider this as a criticism, as a programer myself I know that this can be complex to implement. IMHO, that was a "must have" feature, and I was surprised not to find it.

When I'll succeed I compiling Blender (I always had a problem with collada libs - building on win7, using mingw or VS, I'm using VS2010 btw, maybe that's the cause) I think I'll have a look a it.

A complete axis conversion for a character rig setup is a very tough job, especially with animation data, constraints and drivers. I would advice the collada team to not get into this can of worms, and get at least our import/export working decently.

If you consider it a "must have", then check if maya/max/xsi or others allow axis conversions? That way you can put the burden in these programs :)

@Christian Monfort

if you want to work on this subject there are IMO 2 ways to implement it.
1. Introduction of the axis_up in the DNA Object struct. This is really hard work as it impacts at least the renderer (pre-processing), game engine (transformer), editor, viewer and kernel. But it should result into the most stable and future proof solution. IMO it is more work that should be done by a studio. There is also issues as bullet does not support it either.

2. Use transformation methods to convert the object to Z-axis when importing. this is less hard work to implement but it should be tested with many and many cases to be sure it is implemented correctly. especially as collada states that every object can have a different up-axis and rigs and meshes can have different one but they do not state how you have to handle them.

Max and Maya don't have these issues as they have already implemented something like point 1.

If you need some help with the work, you can always consult me.

BTW blender is not alone in this, there are some easy ways to convert the files before importing (via an asset management tooling) so I don't think it is a must have to have this in Blender ATM. It is the current way collada has to be used as we cannot implement all collada features.

Ehm, an 'axis up' setting should be at least on scene level, if not global. Can Maya work with objects having each individual axis dominance? Interesting concept, but I only foresee really messy code then. This is not really Keep It Simple Stupid :)

I also realize that Blender should fit in well for studio pipelines, but the conversions can also be done outside of Blender's internal workings;
- Blender -> maya: no issue if maya supports it
- Maya -> blender: importer can also convert axis dominance to blender

This keeps the issue where the issue is. An axis-dominance feature is best coded by-design, and not added later in a system that really wasn't meant to use it.

cleaning up tracker, this is a todo item we first have to discuss too. :)

It slipped through my attention that this feature first needed to be discussed.
However it has first been fixed in Blender 2.66 and i reworked it for Blender 2.68.
It should work now fluently for static models and for animated models as well.
Sorry, the exact revision numbers of the implementations are unknown.

Your reported issue has been fixed in SVN. Thanks for taking the
time to report!.

Gaia Clary (gaiaclary) closed this task as Resolved.Aug 2 2013, 6:18 PM