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
Thank you for your reply. I look forward to seeing the completed version of your project. My situation is similar to yours; I also don’t have much time in my daily life to work on this project. It might take several years to meet the expectations. Currently, using Sagan alone is also very convenient.
@francescogenovesi78
I am am feeling cautious optimism that I have finally solved the geograft UV problem. I'll update probably within a week or so.
we have a geograft UV issue in Carrara, I wonder if how you solve it could be applied there too
Hi Wendy,
I sincerely hope not; in retrospect I think the bug can be placed firmly in the "stupid mistake" area...
With both Alembic and USD, you encode faces by defining the vertices of its corners by an index into a long tables of all the vertices in the mesh. That's efficient because unless a vertex is a UV seam, it only needs to be in the table once, even if more than one face refers to it.
UVs are different. They're not indexed because there should not be any dupes and the same optimization for vertices would not save you anything. So, you just encode the actual U and V values in the same order as you're encoding the faces that make up the mesh.
Now, when there is a geograft or geoshell which can remove faces, that creates unused vertices that have to be removed or else you end up with loose vertices in Edit Mode in Blender. So you encode only the faces that are still used in the mesh, and create new indices that refer to a shorter list of vertices that are actually referenced by a face. It is not necessary to do this for UVs because, as I said above, UVs are not indexed.
The bug was that I was redoing the UVs as well, in a way analogous to what I had to do for the vertices, which creates a UV array of a shorter length than it should be because it is removing the "duplicates" that it falsely believed existed when the corresponding face's vertex was a duplicate. Blender's Alembic importer doesn't report the error, it just silently discards the bad UV map. I found it when I used the same code for Hitchens, which uses USD, and the Blender USD importer gave a meaningful error message saying the length of the UV map was off. At that point it was just a matter of staring at that section of the code long enough until the error jumped out at me.
So the problem was Alembic and USD specific (they both encode geometry is pretty much exactly the same way), and I must assume that the Carara guys are better at this than me, or at least they should be :)
yeah, I understand it's a vertex order change and this is reflected in what happens fitting a geografted part in Carrara, it destroys the UV mapping, it doesn't if the figure is imported in any way (FBX or obj) but it happens loading a duf file.
So something using the way Carrara reads duf files which DAZ added to the program and apparently not in the SDK.
There are 2-3 different solutions we use, my favourite is fitting a second geograft to the first one and hiding the first one, another option is fitting it to something else conformed to the base figure or editing it in DAZ studio to make it into a conforming item instead of a geograft
I obviously cannot do coding solutions but can work with geometry solutions and was hoping you were doing the latter since Blender imports it.
That illustrates something strange that I'm seeing, and don't really know how to interpret because it is of course not documented anywhere how this works: A geograft appears as a whole separate node that is just the graft itself, but it also gets grafted onto the figure. I think that's kind of what you're saying about fitting a second geograft. Because the geograft that gets grafted onto the figure changes the vertex order, the UVs are probably messed up. But the other standalone geograft probably still has its UV map intact. Hmmm... maybe there needs to be an option to keep the standalone geograft.
Hey.
I copied the sagan-3.7.0.0 dll to my daz plugins folder. It shows up in the installed plugins and is active, but it isnt available in the edit menu. Daz 4.24
@seegvisualizations
Hi. Read the first post.
@TheMysteryIsThePoint
Hey there. First of all, let me express my appreciation for the work you've put into this tremendous plugin. I was just wondering if the source code for the most recent sagan 3.7.0 was available anywhere. I want to change the exporting process such that parts of a figure that are hidden aren't exported, something it looks like you and mrpdean discussed previously, but, as far as I can tell, was ultimately not implemented.
Hi @Ataraksea
The code isn't available anywhere at the moment because I'm in the middle of a massive rewrite to clean up the nearly 7 years of iteratively figuring things out and incurring more and more technical debt. 3.8 will be a pretty big update, and one of the several big features is that I finally figured out the hidden geometry in geoshells... it turns out that it's not even exposed by the SDK so I never would have found it :) So if that was what you were referring to, I may have you covered already...
But after I get 3.8 out the door (in a week, two tops?), please, by all means message me back and I'll give you the code, provided that you agree to also publish your changes to the community (such as it is), as is required by the GPLv2. I'm excited at the prospect of collaboration, but it should really be from the cleaned up 3.8 base which is much cleaner, has an actual object model and coherent approach, not 3.7 which is all over the place... we'd just have to re-write it anyway so there's no point.
Donald
Gotcha. Well, I'm in no big hurry anyway, so no rush. Once you've finally gotten everything in a state you're comfortable sharing, might I suggest simply uploading the codebase to Github(or your preferred repository hosting service). Not the end of the world if you would rather not for whatever reason, it just makes collaboration much simpler, obviously.
I think the project space is already on Github, I just haven't uploaded anything.
And I just fixed one of the major bugs that was stopping me, so it'll be sooner rather than later. The rest is Hitchens related, which is kind of separate, anyway.
But your project is open sourced, right? GPLv2?
Hmm, I had to stop and think about that one, but after some consideration, I don't think it would be applicable. My "project" isn't any sort of software that I'm releasing. I'm simply creating a character model at the moment, and using Sagan as part of DazToHue's workflow to bring that character model to UE5. I have some plans to incorporate an LLM to drive the character model's behaviour, which will necessitate some amount of code, but I have no plans to distribute it. This is mostly just me exploring a new hobby at the moment.
I think the distribution aspect is the letter of the GPL, not the spirit. If you use Sagan code and benefit from it, the idea is to pay it forward so that others might benefit from your code in the same way that you benefitted from mine. If you keep it to yourself, no one can say "Hey, that code does almost exactly what I need!". Anyway, just think about it :)
In any case, I found the bug that was holding me up last night after this pretty big re-design; there are just a few more relatively small things left (assuming I don't find any more bugs... I've really got to get better at Win32 and set up unit tests, but Win32 makes me die inside a little bit every day), and I'll release the source soon while I continue fixing the remaining Hitchens bugs.
Hey uh, since you are working on it, SBH hair object gets imported to blender in the original scale and orientation from daz studio, which is different from blender. Its not a big problem since you can just rotate and scale down the object on object level, however applying the orientation or editing the python function to rotate the points themselves breaks the strands, makes them look like thick cylinders. So you have to keep the modified rotation and scale values. But its not a big deal just though i should mention it if you dont already know.
@starslinger
Thanks for reporting. Yes, that's been fixed already. I thought I had hidden that functionality; it wasn't quite ready for Prime Time.
Getting close, lots of bug fixes and just a few more features to add.
Hair conversion is working pretty well with the 4 or 5 random assets I've thrown at it so far. Cards, tubes, SBH... it figures out what it is and converts it to Blender Hair Curves.
Here is a demo with dForce Wet Style Curly Hair for Genesis 8 and 9.
Looks great! Thank you for doing this amazing work!
Thanks, @starslinger
There isn't a whole lot of progress with Blender's Hair Dynamics project, so dForce hair is still relevant and needed to be supported.
What is "Blender's Hair Dynamics project" ?
The old hair system that was based on the Particle system had some simulation capability, but it was quite unstable. It wasn't well integrated into the rest of Blender. For example, if you updated the positions of the guide points via the Python API, it was very easy to crash Blender and there were some non-obvious gymnastics that you had to go through to get the hair to animate. There was never a solution that was rock solid and instilled confidence.
But the new system makes Hair a first class citizen with a new object type called Hair Curves, not to be confused with the existing object type Curve (splines, NURBS, etc...). It is much better, can be manipulated with Geometry Nodes, but it doesn't simulate in the way that, say, Houdini can simulate hair.
The new Hair Dynamics Pproject is the Blender effort to rectify that. But as you can see from this, it hasn't gotten much attention, yet. But from that you can also see that it's goin g to be pretty awesome when it is done.
Okay, I see. With that said, I thought that there are some grooming plugins for blender's new Hair Curves that currently allow for simulating hair.
Hair Brush, for example, and some other one I forgot the name of had it before Hair Brush did.
Hi @lilweep,
All of the methods I'm aware of, maybe you know some other ones in which case I hope you'll share them, are clever "cheats" to achieve a level of realism without actually simulating. Houdini (and at some point in the future Blender) simulates the actual strand guides by brute force.
@TheMysteryIsThePoint
Hi!
First of all, I want to express my huge gratitude for creating and developing this exporter. It’s inspiring to see enthusiasts who are striving to make digital artists lives easier.
I have a question about the Sagan, specifically whether version 3.7.0.0 supports SBH dForce hair. I apologize in advance if this is a silly question — before asking I went through all the forum pages, but I wasn’t able to find clear information. Someone said something like “Oh, SBH works great, thanks,” and that made me think I might be doing something wrong. I’m using the “dForce Lively Ponytail Hair for Genesis 9,” but when importing .abc into Blender I can see everything except the hair. It doesn’t even appear in the Outliner. Before exporting, I increased tessellation by 2 in DAZ3D so the hairstyle would be visible.
Could you please clarify if I’m missing something, or if SBH support is still in development? Thank you very much, with best regards!
Hi.
As you suspected, no it doesn't. SBH doesn't present itself as geometry in the same way as other nodes and a few things are necessary to get the geometry. But I think I figure it all out, and more, for 3.8 which is coming soon.
@fading.club1
That asset works fine.
Notice that the G9 fiber eyebrows work. That was a fun one (not).
@TheMysteryIsThePoint
Looks just wonderful! btw I’m curious: previously, for still renders, I exported SBH hair as .obj with line tessellation = 2. And the hair was great. Does their appearance differ visually from the one they have when imported through Sagan with blenders hair curves?
btw on that screenshot they don’t look any worse imo
The main difference is that if you export with line tesselation = 2, that just causes DS to create some geometry, i.e. faces that the OBJ exporter to export. What you get in Blender is a Mesh object. But the arguably better thing to do, which Sagan does, is to convert that mesh geometry into a Curves object so it is now susceptible to all the current and future work the Blender devs are doing with Geometry Nodes and... drum roll please... the revamping of hair dynamics that is underway right now. Also, the node setup as well as the material that I used for the screenshot are not particularly good and can probably be substantially improved upon; that's literally what I came up with in 3 minutes at 2 in the morning :) Also, exporting hair models as meshes makes the files quite large and rendering is slower, if that's relevant to you.
@TheMysteryIsThePoint
"Great, now I understand. Thank u for the explanation!
But wasn’t it possible to export the SBH hair (dForce) simulation through the classic Alembic export with tessellation = 2? After all, in that case Daz generates geometry that, in theory, the Alembic format should support. Unfortunately, though, SBH hair can only be transferred to Blender in a static form and only as .OBJ. Apparently, Daz3D does not 'bake' the simulation into geometry under any circumstances
@fading.club1
Hi, I'm not sure what you mean by "classic Alembic export", but as far as I know, Sagan could always export animated hair with a tessellation modifier. All the tessellation modifier does is it turns each segment along a strand into a face. sides=2 means each segment along the strand will be a quad. That's the minimum DS needs in order to recognize it as the same kind of geometry as any other mesh. Without the tesselation modifier, DS says that the SBH has a bunch of vertices, but no faces that connect them and so what gets exported is a cloud of disconnected vertices.
With the tessellation modifier, what you get in Blender is a Mesh object like another, where each strand is like a long, two-sided strip of tape. This may be sufficient because it is real geometry, and has UVs and materials. But it isn't a Blender Curves object which is the way forward for Blender's coming more advanced geometry nodes. For that, you need to convert the tessellated geometry into actual 1 dimenstional strands and export it as Alembic Curves, which Blender interprets as Hair Curves objects.
The math is not for the faint of heart, but I figured out how to do this in a general sense. As far as I can tell, there are four kinds of hair in DS: tubes, cards, strand based, and fiber based. Sagan can look at a node, think about it, and determine what type a hair asset is, and convert it appropriately to Alembic Curves.
Does that make it clear?