Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Not at all, @mrpdean_7efbae9610 I hate it when I work hard on something that I think is the best thing since sliced bread, and then there's no evidence that anyone is even using it...
Version 2 or 3? Please say 3 :)
I would like to have the option to choose either node names or node labels. Everyone's workflow is different
I'm going to investigate if node name is suitable, and if so, I'll add radio buttons to allow the user to choose.
As I suspected, node names are not unique. That's a huge problem. That's one way in which the official Alembic Exporter is broken.
@mrpdean_7efbae9610 Does that mean that you never want to export multiple characters? The names of the two figures, tears, and eyelashes would clash.
Before I make any changes, could you do an experiment? What does the FBX export look like if you load two identical objects in a scene? Say, two G8.1Fs. The labels will be unique, but what are the node names? How does FBX distinguish them from one another?
I suppose I could just throw an exception if the names are not unique, but that feels kind of hacky and it'd be like turning v3 back into v2 in a sense... so I'm really curious to see how the FBX export manages this problem.
Version 3.1 is up.
It adds a choice to name nodes by label or by name.
It also handles loading/saving configurations better.
Hello,
Just to follow-up, here is a screenshot of the copied .dll file in my Daz plugins folder. I don't have another alembic exporter in there and it also shows that it is installed and running in the ''about installed plugins'' section. Does anyone know what could have gone wrong or how I could remedy this?
@tabithaswansondesign
There's now some documentation in the first post of this topic.
I also added links to the excellent tutorials by @Torkuda
Let me know if there's anything I can do.
Thanks so much for the update.
Can I ask, are you forcing lower case for the node names option?
They are coming through as all lower case:
It's not a huge deal and definetly better than using node labels for my workflow... was just curious if the all lower case was deliberate.
Also, in terms of how the FBX exporter handles duplicate node names:
The standard Daz Fbx exporter appends _dup_# to the names. E.g.
Genesis8_1Female
Genesis8_1Female_dup_2
Genesis8_1Female_dup_3
The DazToMaya (and preumably the other DazToXYZ plugins) don't allow you to select more than one character to export at a time.
Thanks again
Yes, I forgot about the force lowercase. That was deliberate.
Also, 3.1 seems to replace spaces and hyphens with underscores when using the node names option:
Yes, that too. I'll change it so that when the node's name is used, it doesn't transform it at all.
Is there any way to port with diffeo materials in 3.1 ?
2 suggestions:
Add a checkbox that allows for alembic overwrite, instead of always creating a new folder. This is important because sometimes you just want to update something to see the change in blender and its a lot of fiddling around if you want to manually update the alembic file.
The config does not save with the duf scene file. Every time i open sagan i have to either manually find and re-load the config file or make a new config. This doesnt make any sense, once you set the config it should be assumed that it is always open in that file until you close or change it.
Yes. When you import via Diffeo, there is now a global option under Materials called "Sort Materials Alphabetically". With that checked, you can now just select the Alembic object, shift-select the diffeo model, and on the mateials tab, select Copy Material to Selected.
I'll make a script to automate that in the future.
I'll add a checkbox for overwriting.
But I thought I already fixed the second issue, about it looking for the config file at start up and automatically using it if it finds one...
ive just checked it again and it definetly does not save. i save the config, i load it, i click done, i re open sagan and config is gone. didnt even restart daz
A few other things I've noticed while messing around with Sagan in various platforms.
V2 imported into 3D Max with the correct orientation whereas v3 and v3.1 import into max rotated in 90 degrees.
V2 imported in Maya fine whereas V3 and V3.1 seem to crash Maya (at least my version crashes).
V2 imports into Unreal Engine fine whereas V3 and V3.1 imports with what looks like flipped geometry normals.. basically the insides are visible while the outside polygons aren't.
From some initial tests, I can't get my previous ML Deformer workflow working with V3 or V3.1, but my new Houdini JCM workflow does work with V3 and V3.1.
Working onthe other issues, but I do not have access to 3D Max and my license for Maya expired last year and I did not renew, so it will be difficult to diagnose those problems. It seems strange because V2 and V3 use exactly the same exporting code. I can work on UE and Houdini, though.
OK, find v3.2.0.0
It doesn't transform the node name at all.
It has an option to not number versions.
@clandescent1 Please check again. It should look for the configuration file in the same directory as the scene file, and load it if it finds it.
@mrpdean_7efbae9610 I'm going to borrow some code from LotP. It abstracts the issues of vertex winding order that affects the normals, the coordinate system that might be causing the rotation (does it mirror as well?), etc.
I don't know why these things should be necessary, they should be taken care of by the receiving program's Alembic importer, but at least I'll have a framework to fix it.
Thank you very much @TheMysteryIsThePoint !!
Node name option is working very well now so far as I've tested it.
I can confirm that config saving/loading is also working for me.
Thanks for looking into it. I'm happy to run some more in-depth tests if it helps.
Would be amazing if we can get the ML Deformer workflow workingalongside the JCM generation workflow as I've had a few people ask me how I got the ML Deformer working in the first place.
Hi again,
So I did some more testing and, using Houdini, I was able to identify and correct the issue with V3+ alembics getting messed up in Unreal and crashing Maya.
I can only explain the issue in Houdini terms as I don't know anything about the internals of alembic files, but hopefully it will make sense to you.
When importing the alembics into Houdini it creates a path primitive attribute. My rough understanding is that this attribute is used to define/represent the hierarchy of the geometry contained within the alembic cache.
For Sagan V2 alembics, this path attribute is always two "layers" deep:
However, for Sagan V3+ alembics the path attribute is only one layer deep:
If I manually change this path attribute in Houdini on the V3+ alembic, to be two layers deep, the resulting alembic works perfectly in both Unreal and Maya.
Hopefully this all means something to you and helps to resolve the issue. At least I now know how to correct for it in my Houdini workflow.
Everything works well now and overwrite option is a lifesaver. Thanks!
Another thing I can suggest is an option to add a configurable hotkey for quick export, so you dont have to open sagan menu and click export with a mouse every time you want a quick update, but its not that important. Is there a function i could run from daz script to create a hotkey myself? Assuming this function will run without opening the sagan menu and it will use the active config file.
Are meshes/uv's from 1.16 sagan incompatible with 3.2+ ?
I think it is worth mentioning that copy materials to selected method does not work with figures that have geografts. Diffeomorphic imports geografts separately and imports the main figure as base figure, so if you copy paste those materials onto a sagan figure that has all of the geograft materials on one figure it will just break everything because neither the order nor the number of material slots match. This is not a big deal to fix manually as it is now, however if you automate the process in future using this method then every import with geografts will be broken. You could make another checkbox, however i dont understand what was wrong with original method of just replacing materials by their name with a generated python script? That seemed to work fine in 1.16
Awesome.
I'll accept your kind offer. The normals in UE is a strange one; as long as I account for DS's winding order being opposite of what Alembic wants, UE's Alembic importer should recalculate them fine. Sagan has not explicitly exported normals for quite some time, back to version 1.x so I'll definitely need some help from someone more versed in UE (which is the entire set of UE users).
That is another head scratcher. Sagan has always made all objects in the root context, and should have been 1 layer deep, always. I did recently update the version of the Alembic library Sagan uses, stolen from Blender, but I cannot see that affecting this. Clearly I've done something differently, but I can't immediately think of what it is. In any case, I think one layers deep is the correct behavior.