Wednesday, March 12, 2008

COLLADA: quick update

Time's running fast. Two weeks has passed since my post about COLLADA, and I've found a killer bug in FCollada TBN generation code.

As 3dsmax native API does not provide support for returning TBN (I do not know about Maya, perhaps it does not too), Feeling Software implemented their own algorithm for TBN calculation, based on source found in Maya 7.0 documentation, "Appendix A: Tangent and binormal vectors". Of course, relying on NVMeshMender would be too easy.

And after three years of Feeling Software's Collada plugins, there is a bug in TBN generation code. You can read the full details here: http://sourceforge.net/forum/forum.php?thread_id=1966038&forum_id=460918 (the poster is me), but to keep it simple - returned tangent/binormal are opposite to the correct ones because of incorrect sign in equations (proof with asset files and comparison between Maya reference code and FCollada is also in the post). Well, perhaps it's just that I misunderstand something, but I definitely think it is a bug - there's just too many things to back it up.

And suddenly I can't post a bug report on Feeling Software forum, and through I get to know that Collada free support is discontinued. Given that other alternatives to DAE export from Max/Maya are just not worth the trouble, this means that suddenly COLLADA starts to feel much less attractive than before.

I'm even considering writing a small (geometry, node hierarchy, skin controller and sampled & baked animation - should not be that hard) plugin for 3dsmax/Maya...

P.S. Don't click the "Read more" link, it's here because Blogger maintainers can't implement the most useful feature about blogs - ability to hide parts of the message for brief version that's displayed on the main page.

28 comments:

  1. there would surely be open source freaks who'll continue developing free branch of collada plugins

    ReplyDelete
  2. That's quite sad about Collada state then.

    Writing an exporter when you know what exactly you need from the app is not that hard. It is some investment, but at least it's your code and you're responsible for any bugs. I did a simple exporter for 3dsmax ages ago, and it worked just fine (http://dingus.berlios.de/index.php?n=Main.3dsmaxMeshExporter)

    ReplyDelete
  3. I investigated the FCollada code and noticed that binormals are computed incorrectly for mirrored meshes. Binormal is being computed as simple cross product of normal and tangent and no check is being made if triangle is mirrored. As a result, binormal gets inverted where it should not.
    If i understood the math for that calculation, then I could probably fix it my self, but unfortunately I don't :)

    ReplyDelete
  4. Yeah, I can sympathise. I'm on the Maya side of the fence and am discovering a lot of bugs in Collada export.

    If you're a registered PS3 dev, then you might be interested that Sony are maintaining a fork of ColladaMax/ColladaMaya as part of their PhyreEngine project. I've moved to that one because I no longer have any confidence that Feeling Software can get the exporters into a usable state, paid or not.

    I'm getting the feeling that it's going to be a very long time before Collada standardisation finishes. How many years did it take HTML 4/CSS/JS to become reliably supported? Collada is probably even more complex than that.

    ReplyDelete
  5. chacha: Yes, I guess there are problems for mirrored meshes too, I don't remember any code that tries to duplicate vertices, and without that you won't get correct seam between mirrored and non-mirrored part.

    Anonymous: Hmm, sweet - I am a registered PS3 dev, but I supposed that Phyre/PSSG uses non-modified Collada tools. I'll give it a look, thanks!

    ReplyDelete
  6. I do appreciate ppl commenting my blog, but I do think that maybe it's wiser to actually read what I wrote first...

    Anyway, I have a lot of experience with the 3dsmax collada plugin and its tangent basis, and I can tell you that it's fucked up, Max itself has 2-3 different ways of computing TBN (for example the normalmap baker is different than the extremely bugged directX shader material), and it's not true that it does not have an API for computing them.

    TBN consistency between 3d packages and exported mesh is extremely hard to obtain.

    ReplyDelete
  7. You're definitely right about reading posts...

    I never said 3dsmax does not have an API for computing TBN - it does, in IGame. Though since there are several different ways to compute TBN in Max, and IGame does not compute it exactly the same way as normalmap baking facilities do, it's not of much use.

    ReplyDelete
  8. If I remember correctly there's also a native way to get TBN or there is a sample code that shows how max computes that internally, but still you're right, it's not useful and the collada plugin is not using the sample code nor IGame. Also if I remember correctly collada does generate binormals from tangents crossed with normals, while the directX shader plugin does the opposite. The latter one has also other bugs almost everywhere, it's really bad to use it.

    ReplyDelete
  9. And well, maybe my english is poor (it is) but I don't think I wrote that you were wrong about the Max native API (even if I'm not sure that you're right because I remember seeing a function to compute TBN outside IGame as I said)...

    Lastly, you didn't want to comment on "further" insults, were did you read those? Again, not in something I wrote, you're probably reading something else when I write. Dunno why, but anyway, good work.

    ReplyDelete
  10. I am using FCollada for reading .dae files and nothing more.

    Next steps, like vertex duplications and TBN calculations are done with my own code. The FCollada path was too buggy-.

    Are you sure FCollada dropped support for the free version?

    ReplyDelete
  11. DEADC0DE, ok, never mind - let's close the matter and be friends :)
    As for COLLADA - yep, it uses Maya-style generation for everything, and has some more or less lame code for handling stuff like non-orthonormal TBN and mirroring (which, well, does not work...).

    ent, yep, I thought so. Yes, unfortunately, I'm quite sure about that - read this link: http://www.feelingsoftware.com/content/view/107/34/lang,en/

    ReplyDelete
  12. Anyway I don't see much value in Collada those daya, you export from max to collada, but then you have to read collada and write your serialized file, reading collada directly on the platforms is slow, requires huge amounts of memory, that sometimes simply is not there (psp). So it adds an extra step that is not incredibly useful, yes it's a standard but a few programs really use it (fx composer 2? I have it anyway). So I guess it would be simpler to write a plugin that directly writes a binary version of what you need for your engine to load. It's also way faster because you can generate only what you need, while with collada you have to export almost everything and then discard and postprocess what you get.

    ReplyDelete
  13. Ye, of course I know that in theory it's supposed to be application agnostic and standard, but I've found in practice this to not be true, and my older collada based pipeline in the end worked only for that given exporter, under 3dsmax, after using my maxscripts etc, switching to another DCC program would have required a lot of work. And anyway all our other custom tools were written for max, so switching to maya for example required a major effort anyway. Don't know, to me collada is a nice-ish idea that do not quite work in practice. It's a huge burden and it doesn't quite seem to be written with games in mind

    ReplyDelete
  14. In our data pipeline we have two stages for importing data.

    In the first stage external data is imported into a generic format. The second stage writes an optimized binary version of the generic format.

    For us, Collada is ideal for the first part. Obviously we do not use collada as a runtime format.

    FCollada discontinuing its open source project is really bad news... :(

    ReplyDelete
  15. That's what I used to do too. But why should that be a good solution?

    ReplyDelete
  16. It is a good solution (or at least it seemed to me when I opted for it) because being a standard I do not have to code a plugin for each software.

    Plugins for Max, Maya, XSI, Blender, etc etc are already there to be used.

    I didn't want to code again a plugin for Max.

    :)

    ReplyDelete
  17. True but in practice each collada exporting plugin works differently (the tangent frame is a good example but it's not the only one), probably you'll need to extend the DCC application anyway (i.e. to support custom metadata, asset management etc), and writing an export plugin if you have a good pipeline is not hard, so Collada in my opinion tries to solve a simple problem in a bad way.

    ReplyDelete
  18. It's disappointing to see FCollada become less useful, but what about the COLLADA DOM api? Doesn't Sony itself maintain that? I understand it's more cumbersome to use, but wasn't it always a good alternative to FCollada for people who wanted finer control over the data that was being imported?

    I'm just getting started trying to use Collada myself, so a lot of this talk is rather troubling to me... :(

    ReplyDelete
  19. open source freaks

    Agreed... maybe the PhysX NXUstream format is what you're looking for. http://codesuppository.blogspot.com/2006/08/physx-nxustream-file-format.html
    Plus the other native formats and loaders... of course. XD Part of collada's problem is that it tries to be a jack of all trades.

    I think I'll just go with a standard plugin DLL and a converter to that DLL... once I learn enough to make a DLL (yes, total newb).
    Then I'll have changes stored AS changes not as the resulting file, and all resources will slowly baloon up to the size of china! XD

    Oh, I tried to send you an e-mail, if it fails just remind me of the blog and I should be able to find it.

    ReplyDelete
  20. Amusingly I found and fixed this very bug in the version of the Collada exporters that we release with our SDK.
    Oh, and I sent the fixed code back to Feeling, and they ignored me.

    If you're a registered PS3 developer you should be able to find our version under phyre on devnet. if you have any problems with it please do let me know.

    ReplyDelete
  21. Yeah, I know - we actually patched our version with diffs between your (PhyreEngine) one and Feeling's :) We did not have any problems for ten months or so since.

    ReplyDelete
  22. Haha, well thats good to know.

    We're still fixing and upgrading our version as we get developer requests or bug reports. For example, recently I've done a fair amount of work fixing the Maya ColladaFX shader plugin, fixing blendshape support on Maya, and a lot of work on getting the Max plugin up to scratch - the Feeling version of the Max plugin is pretty broken especially when it comes to ColladaFX support.
    It's still not perfect but it is hopefully getting better.

    ReplyDelete
  23. Could you publish the patches to the opensource project?

    http://sourceforge.net/projects/colladamaya/

    ReplyDelete
  24. Hmm, that's nice - we're starting to use blendshapes now, and though currently everything works as expected, it'll be nice to fix any glitches beforehand - when will your updates be released?

    ReplyDelete
  25. Blendshapes should already be working in the Phyre package - we've had developers using them.
    A new version with fixes is released with every new SDK release of Phyre, so it's worth checking it each time. :)

    ReplyDelete
  26. Using the OPENCollada Exporter for Maya, I can export a skeleton animation just fine, but it doesn't let me export any blendshapes. Is there still a bug for exporting blenshapes?
    I've tried exporting the animation (skeleton and blendshapes) after doing a geometry cache, but it seems stuck on one frame when the collada file is previewed. Can anyone tell me what's going on? Any help would be great!

    ReplyDelete
  27. Daniel, I've had no problems with blendshapes export - however I was using Feeling Software exporter rather than OpenCOLLADA. I did not try exporting blend shapes with OpenCOLLADA so can't comment on the bugs you're experiencing. OpenCOLLADA is an almost entirely different codebase rather than Feeling's exporter fork, so it's possible blend shape support is not implemented yet.

    ReplyDelete
  28. Thank you for responding! I'm losing hope here. Could you let me know your settings when you export an animated rig with blendshapes? I will try it with ColladaMaya (by Feeling Software).
    Another question... what version of ColladaMaya are you using? This is the only place I can find a free download of ColladaMaya: http://update.multiverse.net/wiki/index.php/Exporting_Models#Exporting_from_Maya

    ReplyDelete