Alembic Exporter
gyltefors
Posts: 1
What is the status of the alembic exporter? Is anyone able to use this for production work?
Trying to export a scene gives an "unknown error". Searching the forums shows that there are various issues reported. There is even a mention that DAZ has removed posts about the alembic exporter bugs because "stating that DAZ is selling a broken plug-in is clearly an accusation of wrong-doing and as such is against the forum TOS."
If we buy assets for DAZ that we export though alembic, and the exporter suddenly stops working, there is no way we can use these assets in our pipeline anymore, so any bug in the exporter should be taken very seriously by DAZ.
I would say that any "unknown error" can clearly be classified as a bug. If the exporter fails for a valid reason, the reason should be clearly stated.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
try staying under 200 frames
that helps a lot
I use the MDD exporter from aniMate 2 full version.
(Too many negative reports from other DS about the alembic exporter)
I have 61 completed minutes of a feature length animated film
created with Daz assets with animated characters rendered in Maxon Cinema4D
Vai MDD driven meshes .
No frame limits no problems with scene item naming conventions etc.
Sample:
I even use MDD for exporing animated cloth simulation from Daz studio
There are two bugs I have run into with the Alembic Exporter. One is that it reverses the normals which has been fixed in the DAZ Studio 4.11 beta. The other one, that causes "unknown error" is when there are two of the same object in the scene that is being exported. IE two Genesis 3 Females. This is super annoying for trying to export whole scenes as usually there is something duplicated (ie two of the same lamp or wall or chairs etc.). This one has not been fixed as far as I can tell.
I thought I would add that I have not managed to get the Alembic exporter to work with Unreal. So if that is your target workflow you might want to think twice. Here is a more extensive post: https://answers.unrealengine.com/questions/924479/view.html. The bottom line is that the FBX from DAZ to Unreal works fine but the Alembic import has an issue with the texture which you can see most obviously in the eyebrows. I've raised this with both DAZ and Unreal but I don't know where the fault lies... It could be the exporter, it could be the Unreal import, it could be I have not hit upon the correct settings that will make it work. I did find a post that showed the same problem with Octane and it looks like it was fixed so I tend to think that Unreal might be the ones to fix this.
You need to reapply transpaency settings to the eye surface, and the transparency map to the lashes if I understand the issue you are seeing
Its not the eye surface ... I just didn't bother fully mapping the textures. Take a look at the eyebrows. The one on the right shows them correctly. The one on the left shows them 'blocky'. If you look at the rest of the head surface you can see the blocky results too. Its as if the texture on each polygon does not line up.
I had the same problem with Octane. There is one option in the DS4 alembic export that cause the trouble : Preservation of subdivision surface must be unticked if I remember well.
Octane people said to me it was a problem with the exporter (4 years ago !) . I opened a ticket and it was the answer.
I didn't try with Octane V4 as I only use alembic on very specific cases.
It's the vertex order affecting the UV map. Daz seems to reckon vertices in a different order than both Alembic and Wavefront. I thought the 4.12 Alembic Exporter fixed that?
In my experience, the Preserving SubD option is useless for getting Daz shapes into Blender because Blender doesn't use OSD. But OSD is expected in the future months, and I think it's been in a dev branch for a while, if I was following the conversation correctly.
Update on DAZ -> Alembic -> Unreal.
I exported a simple beach ball via Alembic. Near as I can tell the beachball has no subD, doesn't have multiple overlapping UV channels and is about as simple an object as I could export. It didn't work - same problem with blocky textures (see attached showing FBX (right) alongside ABC (left)). Epic logged an issue, the URL for which is: https://issues.unrealengine.com/issue/UE-85482
I've been working for quite a while on an Alembic Exporter plugin that corrects all the problems I am aware of with the official one.
It supports Ogawa. It doesn't mess up the vertex order, UVs, or normals. No "unexpected error" error. No frame limit.
The actual exporting was rather easy, but I had to add quite a few features having to do with the way Blender implemented Alembic support.
The greatest issue preventing it from being a really useful tool is the general heaviness of hair models. So I wrote some code that analyzes the hair on the Daz side, and a colaborator wrote some code that converts it into a particle system on the Blender side. I am happy to report that it is really starting to work, and the model went from around 8 gigabytes in Cycles down to a peak of 1183 megabytes.
There are some issues still with the hair materials giving a straw-like appearance, simulating (the whole reason for doing all this in the first place) doesn't work (but it does go at about 3 seconds per frame, which is not bad), I haven't figured out a way to smooth the strands yet, and it only supports the "Classic Long Curly Hair with dForce" product so far, but the proof of concept is there.
I might add that once the hair is converted, one can use the Particle Edit Mode's Comb Tool to style the hair, much like people were hoping that they would be able to do with dForce Strand Based Hair in Daz Studio. I was just too lazy to fix the poke through in the image since I expect the simulation to ultimately fix that for me (hair collisions are working again in Blender 2.83!!!).
When it's presentable, I'll put it up on GitHub for all who are interested in using it, and I hope that some others will add additional hair types.
And I feel I should say something else.
Creating plugins that users want and need is made TEN TIMES HARDER/SLOWER by the lack of good documentation. It is really aggravating and time consuming to have to guess what the API really means, especially when one has to restart Daz Studio and reload the test scene after every wrong guess. I've only got an hour or so per day to devote to this project, and half of that is waiting.
Whenever the subject of future functionality comes up, please do not forget to stress the importance of documenting the current functionality: and not as an afterthought left to an intern who doesn't know the code anyway, but by the guys that wrote it. I would even support a paid technical support option, sort of like PAs.
Better SDK Documentation = More Cool Plugins
I came close to giving up several times simply because I could not figure out very simple things and there appears to be no one to help. A bunch of header files with one line descriptions that could have been deduced from the name of the function itself does not an SDK make.
the DAZ one fails for me in Blender, Animate2 mdd cache on an obj works but my Blender lighting skills are lacking once I get it in there
You're a genius. Im glad you perservered in spite of daz's obscurity.
Do you know if your alembic exporter works with geografts?
The official one doesnt export with geograft or geoshell animations (the latter not a big deal of course, but geografts kind of important).
I noticed there was an update for the official Alembic Exporter recently, but i dont know if they improved anything or was just to be compatible with updates.
odd I never noticed that in Octane Standalone (the only thing I can use it in)
It's not genius, but OCD really :) And I saw the updates, but haven't tried them either because of the bad taste it left in my mouth.
You know, I have no idea if it will work with geografts... currently the code looks at all the nodes, and anything that has a mesh potentially gets converted. It would depend on precisely how a geoshell is modeled in the data. I've never actually used a geoshell. I'll put that on my list of things to investigate after the hair works, or maybe even before if it's easy.
Ha ha you and me both :)
Question for you, Wendy. MDD is actually much, much simpler than Alembic and one of the problems I've grappled with is that Blender implemented Both MDD and Alembic support as read-only caches, i.e. you can't modify either one in edit mode once you import it. But MDD is so simple that one could probably figure out a way to update the MDD file with any edits made in edit mode... for example, it is trivial to calculate the exact location in the MDD file where a certain vertex is, in order to update it. That'd be really nice for fine tuning things you didn't catch until after you exported it, like minor poke throughs, etc...
But I also noticed that MDD is just a vertex cache; it gets the UVs from the object it is attached to, and doesn't support normals at all. How do you get around that? Do you always have to use a normal map, then? I was thinking of throwing in support for MDD and OBJ sequences just because 1) it'd be easy, and 2) Maybe later we could have an in-place MDD editor in Blender but wasn't sure how useful MDD would be for character animation, not supporting normals. But you can work around that? MDD might be worth it?
@lilweep I'd like to try this, if it is useful to other people. Can you give me some cheap products to buy, and some simple steps to follow, in order to test it, and/or get it to work?
I just export twice, an obj and an mdd
then import the textured obj into Blender not split up and load the mdd cache on it under file import
is just an obj with vertex movements along the timeline so imagine editable like any obj, not tried
But only the object in the first frame has normal information. When the object is deformed by the mdd cache, it doesn't know how to update the normals and probably just updates them from the faces. This looks OK?
You might like to look at the work Thomas Larsson and @Padone have been doing with geografts using the Diffeomorphic DAZ Importer. I know it isn't the same concept but the geografts presented a problem for them and they found a workaround so I thought it might be helpful to you.
https://bitbucket.org/Diffeomorphic/import-daz/issues/38/better-geografts
[EDIT] ... I now see you were involved in that discussion, sorry.
I really doubt that I was meaningfully involved in a discussion about geografts :) I literally have no idea what they really are. Thanks for the link... maybe it'll shed some light.
I cannot understand since it is just vertex mesh how geografts or geoshells for that matter would affect anything unless the DAZ exporter is doing what Carrara does with the duf imports and destroying the UV mapping but thats on rigged mesh.
I am only a user and don't understand the technical side of stuff, I just know mdd on an obj works in Blender but no idea how,
That's pretty much the conclusion I can to as well... if it's just a mesh, I think it'll get exported like any other. Of course, we won't have the rigging challenges that it did. But the UV stuff kind of concernes me because that is one of the areas I couldn't figure out. There are multiple UVs per shape, and I just grab the first one, I think, because it wasn't clear what else to do. And I use the term "shape" as if it were well defined in the docs and I understand the concept, which it wasn't, and I don't :(
You do realise that the documentation is the work of Rob Whisenant, the lead developer, and that he does it on his own time? Posts like this don't exactly encourage him to keep going. I agree that an official documentation budget would be welcome, but don't lose sight of the fact that it would require input from the developers (a tech writer can't just intuit the workings) so it would have a significant impact on the main development process.
common geografts are extra limb appendages or extensions for creatures (like Rawart creatures) and anatomical elements are also geografts. if you type in geograft in Daz store, most products will have them listed.
Basically, if you set up an animation with a geograft fitted to your character, the geograft will follow the character it is fitted to. When exporting the animation, the official Daz Alembic Exporter will export
1) The complete animation with your figure + geograft doing the animation (which is good)
But then it also has:
2) An accessory 'phantom' geograft that isnt animated. I think it is usually stuck at scene origin (not sure).
Maybe for many applications this isnt a big deal, because you should be able to remove the extra mesh elsewhere. But it is annoying.
I will say I appreciate the work the DAZ 3D devs have done and giving us a tool which many thousands of creators enjoy - thank you.
Regarding documention, this has been an issue for close to a decade and the technical debt continues to climb. This is not a failing of the devs - they shouldn't be burdened with technical writing work at all. DAZ management should really search long and deep that if they want to open DAZ Studio to a wider audience. New and upcoming users (even existing ones learning new features) should not rely on the trials and tribulations of its frustrated user base due to lack of documentation. Richard, you have been a very helpful member of the community and we all appreciate that too - but I am sure you also see that frustration.
To rely on dev's free time is a failing of management - especially on something as crucial as documentation. Maybe James Thorton and his management team can start thinking of ideas to make the dev's lives easier. Even if its a GoFundMe page - I'd gladly donate some bucks to the cause.
DAZ Studio being (for the most part) a free product, I guess the underlying message is that we just need to suck it up. That's OK too, some folks would rather take the long way home.
So, the lead doing the docs on his own time is normal, and the problem is actually me. Got it.
OK, I was way off. I thought it was for tattoos and such. I'll grab one of Rawart's products and just see what happens. I hope it's just a node with a mesh, and will Just Work(tm). The problems the Daz Importer had were due to rigging, which Alembic doesn't export, so we'll see.
As a dev, this is perhaps what I should have said instead. But I doubt James Thorton's ear is to the forums.
Similarly, how could we go about even floating this idea to those in a position to perform? If the quality even approached something like, say, Qt, I would consider it an investment in myself and budget for it to reflect that.