Hi, please find here a much lighter file. I'm not able to reproduce the issue with a scene built from scratch so I've simplified as much as possible the current scene. I hope it will be ok.
Here's what I've got so far...it builds successfully and exports valid Alembic files, but abcls doesn't find the mayaColorSet=1 flag so I'm still doing something wrong.
Alembic::AbcCoreAbstract::MetaData md; md.set("mayaColorSet", "true"); OC4fGeomParam param(prop, name, true, kFacevaryingScope, 1, 0, md);
Implemented import & export of camera focal length in FBX now, so will re-assign to @Sybren A. Stüvel (sybren) for the Alembic part of it…
I suspect this file uses advanced FBX features we do not support… but hard (impossible) to tell with such a big fat FBX, please try to reproduce same issue with dead simple file (like, only a few cubes, without any addition like materials, textures, animation, etc.).
I have started a rework of the animation exporter. The fix in D3070 already solves the issue, but it needs some refinement and further testing.
OK, progress--I can build Blender from source with Alembic enabled. Next step, @Dario Seyb (daseyb) says for Unity he used the following to add the Maya color set flag:
AbcGeom::MetaData md; m.set("mayaColorSet", "true"); m_colorSet = AbcGeom::OC4fGeomParam(m_scheme.getArbGeomParams(), “Cd”, true, AbcGeom::GeometryScope::kFacevaryingScope, 1, m_tsi, md);
Could you help me adapt this for Blender?
Sun, Feb 18
Sat, Feb 17
If I wanted to recompile Blender's Alembic export module with the mayaColorSet=1 flag added, where in the source should I look?
Fri, Feb 16
This issue is fixed in master. You may want to double check that the problem is fully solved.
Wed, Feb 14
Thu, Feb 1
note to self:
It looks like the export can be done in a straight forward way, see rna_Mesh_calc_tangents().
The FBX exporter does it similar to this:
Thanks for reporting. At the end i found the problem was in the way how the importer handles errors. Your files should now import with warnings about missing images.
Wed, Jan 31
Sure thing. Actually it's the same issue in Maya in case you're able to test it. Haven't tested with 3dsmax but i'd assume it may be the same.
Here is attached a screenshot.
Dont have access to Unity/Unreal atm.
@lucas veber (lucky3) : could you upload a screenshot of both Unity and Unreal as a reference?
Fri, Jan 26
Closing this, since it's an upstream Alembic limitation that I can't solve.
This patch makes too many unrelated changes. I was hoping this could be done by keeping existing code as is, with an optional block to write extra vertices.
Thu, Jan 25
This file contains chunks that place objects which we currently don't support, which could be the cause of the problem - see a dump:
Yeah, final word here is that FBX6.1 has only been kept for a few specific use cases where it was better/easier to use than binary 7.x. But it is not maintained anymore, and doomed to disappear soon. Supporting one version of that mess is already a nightmare, we cannot afford to support older versions too. :)
Wed, Jan 24
OK, I think that one file is enough to reproduce
This is one screenshot is of, but other files seem to have same issue.
@Campbell Barton (campbellbarton) , mind having a look?
@Alex P (eneen): thx, but I cant find a 1_2.3DS in that zip.
No problem, here is link:
@Alex P (eneen) : Sorry for the longstanding inactivity here. However, to have another look at this we would need the particular 3ds file to reproduce the issue.
That link in the task description is dead unfortunately...
Note that I'd propose to remove this exporter: T53877 since binary FBX is much better supported now.
Tue, Jan 23
Since last asking for information it has been 7 or more days, due to the policy of our bug tracker we will have to archive the report until the requested information is given.
Mon, Jan 22
I think it might have something to do with Softimage's bones having "roots" and "effectors" by default. If I export the FBX without the roots and effectors, I get a different result - still broken, but different.
For some reason, this FBX generates two different armatures when imported in Blender, which make a mess in binding (if you set both armatures to Rest pose, the mesh is not weirdly deformed anymore).
Then it means that FBX SDK does not even respect its own documentation (what a surprise…)
I dont have maya or 3ds max. this fbx is ok with windows 3d painter and daz studio. I tried to open in daz and save again to work around but it introduced some daz studio things not needed. I suspect that the reason it cannot be opened in blender is that I put chinese character in file name when I saved it in marvelous designer. Marvelous Designer uses fbx sdk, it should be ok with maya and 3ds max in my opinion.
Regarding OBJ file, I guess we have no issues here because we do not have the MTL file associated with it (its path is the only textual info in an OBJ file I think…).
Jan 20 2018
OBJ importer works for me though (it is using above method - using a replacement character - already btw...)
@Henrik Berglund (cyaoeu) : thanx for investigating
how about D3012: fix T53841: FBX import: use replacement character when utf-8 decoding fails?