Assimp flipping y/z axis on different formats

Help
2012-10-27
2014-11-10
  • Matthias Guntrum

    Hello,

    I am using the ASSIMP command line tool to export from various file formats (.dae, .3ds, .ase, .obj) to .obj. After importing into my object viewer the shading seems to be inverted on the y/z axis. I can recreate this issue with all the described file formats except for .obj. If i export from max to obj (no matter which setting) import to assimp and export to obj again, the issue is gone. I had no look with .dae, .3ds, .ase file formats. After exporting those from assimp to o.obj i have the described problem.

    I tried converting the .obj to utf8 and displayed them in webgl (using threejs) with the same effect.
    http://threever.org/demos/problem/flippedaxis/utf8flippedaxis.html
    (left is the obj -> obj that works, right a dae -> obj)

    Here are the links to the source files:
    http://threever.org/demos/problem/flippedaxis/flippedaxis.zip

    Image describing the issue:

     
  • Thomas Ziegenhagen

    First: how do you tell that the axises are inverted? To me it simply looks like some step in your process screwed up the normals. Recheck with a file that actually exposes axes clearly, for example a collection of coloured arrows.

    Second: What are your import settings? What are your export settings? The .dae loader, for example, uses the "up axis" information given in the file to rotate the whole scene to fit the Assimp standard coordinate system. Which is X to the right, Y up and Z towards the viewer. Most file formats don't provide this information and/or the format specification does not state anywhere which coordinate system the authors assumed, so the files do NOT fit to any expectation you might have, and nothing could be done about it. Furthermore, Assimp does conversion between lefthanded and righthanded coordinate systems for you. Direct3D .x files, for example, are lefthanded by definition, and are silently converted to the righthanded default coordinate system of Assimp. If you request so in the post processing steps, you'll get the whole scene converted to left handed coordinates, and of course this changes all the data in the scene, therefore also changing the output of the export process.

    Third: every format conversion is data loss. You won't get around this, neither using Assimp nor using any other conversion tool. Avoid conversions if possible. And the first conversion is already the export plugin you have used to write these files from Blender. These exporter tools apply their own set of changes to the files, including coordinate system changes. If you're relying on 3d scenes appearing in your application directly and correctly in every case, you are screwed no matter what. Always add code to allow basic adjustments on a per-file base after loading.

     
  • Matthias Guntrum

    Hello,

    yes. It looks like the normals are screwed. They are screwed in a way where y should be z.

    if I patch the model loader to do the following I get the desired results:

    before "patch":
    normalArray = x;
    normalArray = y;
    normalArray = z;

    after "patch":
    normalArray = x;
    normalArray = z;
    normalArray = y;

    I use 3ds Max to export the models in the various file formats and I am wondering why the above results are the same with every export setting i choose except obj. Why does 3dsMax -> obj -> assimp -> obj not screw up anything while every other format i choose ends up with those flipped normals. If it is flipped in every case that would be ok. I would simply apply my patch and that's it. But in this case some models have flipped normals and some don't . I was thinking of letting the user decide whether normals are flipped or not but I want to know where the problem comes from first.

    I don't need complete scenes just simply the model.

    I am sorry that my problem definition with the "inverted axis" was misunderstood, as well as the double post I made. Please, don't be angry about it. Render me a novice programmer in this stuff.

     
  • Thomas Ziegenhagen

    Ok, that makes me wonder. Because to my knowledge there is nothing in the code that could case the axis invertion. It could be a combination of 1) rotation (to adjust the up axis) and 2) conversion to lefthanded coordinate system (which mirrors the Z axis). What flags did you use to import and export the files?

     
  • Matthias Guntrum

    Export options when exporting from 3dsMax:

    3dsMax > DAE
    When exporting from 3dsMax to .dae i can choose from a number of options. Under the axis panel i can choose to set Y or Z as the up axis i tried both. But to my knowledge this didn't change anything either.

    3dsMax > OBJ
    Exporting from 3dsMax to .obj i have similar options. I tried with "flip y/z" checked and unchecked. As said in the previous posts exporting from 3dsMax to obj results in a working model no matter what setting i choose. So with/ or without flipping the y/z axis in the options panel: In the end (after assimp converts from .obj to .obj) i get a model with all normals displayed correct.
    http://threever.org/demos/problem/flippedaxis/objExportPanel.jpg

    Commandline options when importing and exporting with the commandine tool:

    ASSIMP export options

    assimp export infile.dae outfile.obj -cfull

    assimp export infile.dae outfile.obj -lh

    assimp export infile.dae outfile.obj -fwo
    ^^ resulted in a 'export format not recognized' error. http://threever.org/assimp/help

    assimp export infile.dae outfile.obj -face-winding-order

    assimp export infile.dae outfile.obj -cts -gsn -jiv -icl -lbw -rrm -slm -tri -guv -sbpt -fd -fiv
    ^^ fiv was not recognized although these are the parameters used for the "default" preset

    Every export looked the same regardless of the attached parameters. This left me thinking that maybe parameters were not recognized properly. But after editing the source to print out whether parameters were recognized or not it looked like they were understood.

    Some short code commands however were not recognized like -fwo or -fiv (not in the parameter list but used in presets)

    However if I imported an .obj file and exported it to .obj again it works.

     
  • Prime_8

    Prime_8 - 2013-05-05

    i am getting the same issue . i made a mesh the had  distinctive shape for x,y,z directions .
    i found the axis orientation on import to variate with the import file format . mesh was created in UU3D , one tested and exported to many formats .
    then same mesh imported and re-exported from WIngs3D into  many formats had same results .
    a mesh made form scratch in Max9 , and exported many ways .  sames results .

    using latest zip dl from assimp-3.0.1270-source-only.zip.

    the data is read into a d3d .   testing with and without the left handed options

     
  • Frank Perbet

    Frank Perbet - 2014-11-10

    First of all, thanks a lot for this great library guys, you are making the world a better place :-)

    I have the same issue here using the C++ interface. I tested it by creating a 3D RGB-coloured axis in sketchup pro and then exporting it using different file formats. For some file formats, when re-loading with assimp, the axis are flipped. Re-loading with Meshlab or Maya doesn't show this problem, so that's de

    My workaround is to detect what format is loaded and apply a fix after the file has been imported. I couldn't find a way to get assimp to tell me what format was actually loaded so I reverted to file extension check.

    Here is a bunch of suggestions to improve assimp:
    - in the Importer class, add a way to get the format of the last file loaded
    - give a list of the file formats which are flipped (to my knowledge: .3ds and .dae, but probably more)
    - the best would be to add a flag to disable any rotation on load but since this is not done already I reckon there must be some internal issues making this change harder than it seems.

    I am using assimp 3.1.1

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks