Collada - up_axis not processed #25432

Closed
opened 2010-12-31 13:13:36 +01:00 by Christian Monfort · 11 comments

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

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

Changed status to: 'Open'

Changed status to: 'Open'
Member

%%%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 ;)%%%

%%%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 ;)%%%
Member

%%%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?%%%

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

%%%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.%%%
Member

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

%%%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 :)%%%
Member

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

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

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

%%%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.%%%
Member

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

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

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

%%%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.%%%
Member

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

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

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#25432
No description provided.