That’s why BF worked closely with Epic in order to make sure FBX from Blender imports well into UE4. And it does indeed. So does FBX from UE4 imports into Blender quite well.
Not quite. FBX is from Autodesk. So Autodesk made it to be a black box and for obvious reasons it wouldn’t disclose specs to BF. Epic themselves have to fix a lot of breakage associated with Autodesk changing FBX specs (but since Autodesk is interested in UE4 supporting FBX well, I am sure they share specifics with Epic).
Alembic is open source format. Specs should be openly available and if Epic and BF follows the specs, all it should take is getting in touch with Epic and collaborating on why Alembic files exported from Blender aren’t loading properly in UE4. Epic devs are quite open and communicate with users often, especially on forums and Discord (Unreal Slackers). Blender is used in-house at Epic.
So “not knowing what should be done and therefore wasting time fucking about” is a poor excuse in case of Alembic IO implementation and making sure it’s works with UE4.
There are 26 letters in English alphabet, so it’s not too late for a patch release with working Alembic (unless Epic finds that it’s a bug on their side, which requires collaboration with BF)
I myself am not declaring bugs any ware. I am just trying to raise some issues in two forums related to software that are implementing Alembic for the first time.
I am searching a workflow for animating in Blender and rendering in (near)real-time in UE. For long time I suspect Alembic would be the Holy Grail, so your initiative can only be treasured by me. If I seem to be arrogant and you feel pressured, please, forgive me. I just want to help with feedbacks from my experiences.
As you can see in the image, UV is not an issue to me right now. There are rotation, scaling and mirroring problems, but they are UE related.
**Great news is that UE imports per face materials from Blender’s Alembic, but Maya and 3dsMax don’t.
As far as I can judge from exporting and reimporting Alembic in Blender itself, these are issues that may be related to your code:
Setting size other than 1 SOMTIMES doesn’t work, SOMETIMES IT DOES (testing).
Exporting normals makes files 10x bigger (maybe not an error).
Exporting group’s instances or linked groups does not work. This is a real issue when dealing with character animation.
Face sets (per face material id?) seem to work checked or not.
Hi Adriano, I think we are on the same page and really aim for the same workflow, I am very excited about the ability to render out animations in realtime so ya, I really appreciate Alembic to work.
Well, you seem to not understand the fact that I am not paid to work on this ; I am only doing this on my spare time. I repeat: I am only doing this on my spare time. And no one else is paid by the Blender Foundation, or the Blender Institute, to work on Alembic support. If you want that to change, contact the Blender Foundation, perhaps even make a sizeable donation. So it is not a poor excuse per se, since I really don’t have time to waste fucking about.
You were not really targeted by this little rant. I do go to the UE forum thread to see what’s up and know which ones are quick to draw conclusions about something they don’t know.
Setting size other than 1 SOMTIMES doesn’t work, SOMETIMES IT DOES (testing).
This would require example files for the case where it doesn’t work. It could a hierachy issue since the scale factor is only applied to root objects (child objects inherits their parents transform, so no need to modify theirs, otherwise it would apply the scale a second time, and the you go down the hierarchy, the bigger the objects will get).
Exporting group’s instances or linked groups does not work. This is a real issue when dealing with character animation.
I would need to check on that, but it doesn’t feel like a bug, more like a missing feature.
Face sets (per face material id?) seem to work checked or not.
This one should be fixed now, thanks for the quick report!
EDIT: also, on the 2.78 release, and the possible letters releases following it (‘a’, ‘b’, …): only crucial fixes will be backported and no new features. For example, the release won’t have support for triangulating meshes during export, though the buildbot does have it. And some fixes will require new features and refactors first so they won’t be part of the release. Nothing prevents you to use the nightly builds if some to be developed features are important to you or for testing purposes.
Well, still kinda sucks as I’d expect BF/BI to pay through until Alembic is 100% usable (which isn’t usable with UE4, but BF/BI is known not giving a damn about game developers). It seems that a lot of features in Blender are made for a check mark
With 3D interchange, nothing ever works 100%, especially on the game engine side. Not even the simplest formats like OBJ are fully supported. Alembic isn’t even commonly used in game engines and UE4 support is experimental. What exactly do you expect? If the export works to other packages, but not UE4, chances are they aren’t supporting something properly.
Open source and standardized does not mean equally implemented everywhere. 3D applications, the data they handle and store, and the functions they have access to are far too varied to ever have 100% interop, even between two products under the purview of the same ownership such as Max and Maya.
It doesn’t make any sense. If there is a way how Alembic format stores UV maps for example, then Blender would convert its UV data into the format of Alembic and write it. UE4 would have to read Alembic UV and convert it into its internal format.
I don’t see how there can be a mismatch unless either Blender doesn’t write it into appropriate format, or UE4 doesn’t read it correctly (or doesn’t transform it correctly).
I am oversimplifying things, but the gist of it still stands.
Here is an example (although file format is not standardized in any way) - Doom 3 md5model/anim files. Blender’s exporter would adjust data to the format “standard” (for example UV map had to be flipped on one axis), save it and the game would read it. Works like a clock. It required some back and forth tweaking and testing, but it was done. Based on that I see that lack of communications played the role here.
Alembic is one of these open-source code dumps. There is no “standard” (not that this would make things better), there’s an open-source library and the documentation is basic API docs.
Has it been tested in Maya / MAX? And if so, were there zero issues ? If that’s the case, then indeed Epic screwed up.
According to KWD’s reply in this thread…
“I do not pretend my code is bug free as I fixed a bug this morning, but according to previous posts in this thread, UVs export fine to Maya, 3DS Max and Houdini”
… and even if there are 100 other issues with that export, Epic may still have screwed up or left stuff for TODO or unsupported. They’re not wizards over there.
So you actually do see how it could go wrong? I’m not familiar with Alembic, but there is more than one way to store vertex attributes and game engines tend to only support what they need, while the format may support more. Specifically, game engines usually don’t support more than one normal/UV per vertex, because GPUs cannot draw such meshes. The vertices need to be split. Again, even with as simple a format as OBJ you run into that issue.
Sorry, but there is a big difference between a native format, and an intermediate formats like alembic, collada and fbx. As for the first you do have a strict way on how you can export it: If it does run in doom 3, the exporter design is correct. If it does not, somethings wrong with the exporter. Period.
While format like alembic do have to cover a wide range of 3d applications, all with their own design decission how they the import the data and how to process things, based on their own features their application do support. So for someone writing an importer
you practically have to deal with both: The importing and exporting side. If the target application X does not support a certain feature, because its not designed to do this, you can write the best exporter in the world, but you will always be on the loosing ground with X.
(Not to mention what those people designing an importer / exporter for Program X will do to tweak the format to support their application in the best way possible…wich makes the mess much bigger)
Thats why I do like about the USD aproach: If it runs in Hydra, the exporter is correct.
(And yes I was a big fan of intermediate formats, but in the long run imho its better to push companies to open source their native file format in the least restrictive license possible (yes I’m also looking at you, blender) so you can code native support for their applications.)
@Kevin:
great work you’ve done so far, hope these negative comments will not discourrage you.
Repeating a lie does not make it a truth. I’m personally happy about FBX, custom normals, Alembic, asset management and the other game-related endeavours the BI/BF paid and pays developers for. Next thing I’m looking forward to is viewport and PBR improvements in 2.8
Hmm, did you talk to Aligorith about those features? Create some mockups or examples of what you need (you could use rightclickselect.com for that and then point him there).
(unless Epic finds that it’s a bug on their side, which requires collaboration with BF)
