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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Okay, after a TON of work, I figured out why strand based hair may not be working very well for many of you. Mesh based hair still stubbronly refuses to not look like a helmet when rendered and I believe Sagan has said before he's still working on that- as is the creator of diffeomorphic as that problem exists with or without the alembic.
When you import your figure through diffeomorphic, on the hair, under material method, make sure to use single principaled. I don't know WHY this makes a difference, it just does.
As for diffeomorphic the best option for material conversion is bsdf. Not all the top coat options are supported yet since iray gets a ton of them, so this may be the issue with some hairs. Also some hairs use not supported custom shaders, in this case you can try to convert to uber before exporting. Same if you import a 3delight material the plugin warns you that must be converted to uber before exporting, though there's some basic support for 3delight too.
So in general the best conversion you can do is convert to uber then export then import as bsdf.
note. If you have a specific hair that doesn't work, apart the limits explained above, please let me know I'll look at it.
Hi @Torkuda
One rationale behind simplifying Sagan 3 was to make it simpler to add functionality that is orthogonal to actually exporting Alembic: Figuring out SBH. With so much unrelated functionality, it was really getting difficult to keep things straight. David asked for the code, and I'm sure he probably threw up a little when he looked at it :)
But now, it should be pretty simple: Set tesselation to 2, and calculate all the vertices of each strand as being the average between the sides at any given point along the strand. Another user pointed out that I can determine which end is the root by looking at the UV coordinates.
But as you probably know, the old particle system in Blender is quite old and it's pretty janky what you have to do in order to do something as simple as create a hair particle system from a bunch of know vertices that model the strands. The new hair curve object has a great (read simple) Python API to access the hair, all its strands, and all the vertices of each strand. That's perfect. But what hasn't been implemented yet is the Python API to add a strand with its vertices. It's going to be glorious when it's implemented, but my question when it might be worked on went unanswered. From that I infer that know one knows yet. So I'm going to wait for the better way, and then we'll have functionality to export SBH as a new Blender Curve object at a given frame, animated over a frame range, and also in a binary format suitable for the Houdini hair sim tool I paid Alex to write. As an incidental aside, Alex is Ukrainian, and I sent him a message asking if he was OK, and got no response. I don't know what that means.
Hello, I am trying to use Sagan 3 but in the About Installed Plugins Daz menu it says that the "Plugin failed to load".
The previous version 1.16.0.0 works fine.
I'm using Daz Studio 4.21 Pro.
Any idea what the issue is?
Thanks!
Yep, I'm also getting this error. Also using 4.21 Pro.
Yes, it works on my dev box, but failed on the test box. I'm looking in to it. Stay tuned.
I rebuilt it, and now it loads on my other box. Not sure what the problem was, but give it a try now. I've updated the 3.0.0.0 download zip.
I'm still getting the same error :(
Plugin failed to load!
Reason : Library could not be loaded. File is not a valid DAZ Studio plug-in, or was made for a different version of DAZ Studio.
Now that's odd. I'm on 4.21 as well. I'll have to look further into this. Sorry for the inconvenience.
No worries. Thanks for your work!
I think I found the issue. Have I mentioned this week how much I hate Win32? And I'm not just saying that because I suck at it :)
I'll have the fix up this weekend.
Thank you. Looking forward to tring it out.
OK, 3.0.0.1 is up. I think I figured out the problem, that debug and release libraries cannot be intermixed, but I was unable to test in a pristine environment because I no longer have a Windows box without a development environment on it.
When I tried to reinstall Windows 10, I get a new error about some missing driver (strange, this before any OS is even loaded) that I never got during the dozens of times I've re-installed. I'm sure it's some tactic to get me to upgrade to W11.
Anyway, sorry to make you guys into guinea pigs, but please try this version.. I'm reasonably convinced that the relase/debug thing was the problem. I wonder if I were to live-boot Linux on it, where I know how to use the admin tools, and completely wiped the drive, whether it would install W10 again or not...
Can confirm it's working now :)
It's quite a bit faster and it does solve the issue of vertex order not matching that of the Fbx export as well.
Thank you very much for your work!
You're welcome! We're a community.
And Oh thank god... I was at my wit's end. Have I said today how much I hate Win32?
BTW, I was able to remove all the Diffeomorphic materials stuff because of a patch to Thomas's plugin that he very graciously did, with coordination by Padone. There is now a global option in Diffeomorphic under "Materials" called "Sort Materials Alphabetically". With that checked, DS, Sagan, and Diffeo all order the slots in the same way, alphabetically. So now to transfer materials to a Sagan object, one only need select the Sagan object, shift-select the corresponding Diffeo object, go to the materials tab, and "Copy to Selected".
I just did a quick test and it seems to work now! Thanks, looking forward to using it :)
Hello, I just started up DAZ today and noticed the exporter is no longer in the menu. It says it's installed in the Installed Plugins window but for some reason has randomly disappeared from the Edit menu.
Any idea?
EDIT: It was because I switched layouts and it broke the link to it. I fixed it by going to Window > Workspace > Customize and on the left side under Miscellaneous it is located, dragged it to the right side Menus > Main Menu Bar > Edit.
Hello guys,
I have 2 questions regarding the Sagan Alembic Exporter script.
My goal was to export a scalp (or hair cap) object so that when I export my alembic animation I can grow hairs on it.
Thanks for your time! :)
Hi @jerjer
1. The purpose of the tab is to create a Blender Hair Particle System from the DAZ hair object. But Blender hair is sort of in a transitionary period where the old method of making a hair particle system doesn't work anymore, and the new way is not implemented by the Blender devs yet. The idea, as you said, was to create a scalp object to grow the hairs on. Since I haven't been able to use it in so long, the scalp object code may be broken.
2. And SBH doesn't export via the normal methods because of the way SBH it works in DAZ Studio; The hair isn't geometry until it is tesselated, and turned into strands. Again, Blender doesn't yet have a Python API to create hair curves, and the old way crashes the latest Blender builds.
But when its implemented in Blender, I'll figure out how to export SBH and various other transmapped hairs as Alembic curves, which I think will work in C4D as well. I think they'll get around to it soon. Agree that there are a lot of nice SBH assets out there, so this is a high priority feature for me as well.
Edit: If you want to keep an eye on it, check out the Blender Issues. When "Add/remove curves and points" or "Alembic import (D11592)" is checked, then I can work on it. I know you said you're using C4D, but it working in Blender marks when I can implement/test it with my setup.
Hi,
I've been using this plugin a lot and I have a question around visibility and whether or not the Alembic export is supposed to export invisible surfaces or not.
For example if I hide a surface in Daz and export the figure, the hidden surfaces are always exported and visible in the resulting alembic cache.
In v2 there was the option to exclude specific surfaces from export.
I understand you wanted to simplify things with v3 however, imho the plugin should export things exactly as there appear in the Daz viewport. That is, if parts of the figure are hidden in the viewport, ideally, they should be excluded from export.
Is there any way to exclude hidden parts from export with v3?
Thanks!
@mrpdean_7efbae9610
Yes, we're in agreement. I did it this way for two reasons:
1) I've observed that the only slow process in the exporting is the advancement to the next frame; other processes on an Alembic file are lightning fast. So my intention was to just get the basic export to be as fast as I could make it (by simplifying it), and then write other, simple apps independent of one another to process the Alembic file in the ways that used to be part of the plugin. This leads to:
2) I don't really trust DAZ to not break everything and not fully document the new things, so the less code that depends on DAZ Studio, the better. These simpler operations have nothing to do with DAZ Studio, and would be immune from whatever changes are made to DAS Studio. So, to hide certain surfaces, like in the previous versions, you'd export with v3, and then in Powershell, do something like:
sagan remove-surface <the surface(s) you don't want> --input <your alembic file> --output <the new alembic file>
If this seems complicated, trust me, it is not. A little alien at first, maybe, but not hard to get the hang of. And I was really surprised at how fast reading and re-writing Alembic is.
Another benefit is that you can stack operations on top of each other. Doing it like this is borrowed from the UNIX philosophy of writing small, simple tools that work together. That way, a user like you could make Sagan do lots of things in precisely the way that you wanted, in ways that I myself did not even forsee, and didn't need to code for. It's much more powerful and it enables a lot of ideas that I have for Sagan to make it more useful, like hair conversion. And it'll be much easier to make Mac versions.
I see. It's an interesting idea and I get what you're saying about breaking things down into smaller function apps that do specific tasks.
I do however feel like the starting point for any exporter should be to export as close to a one-to-one match as possible, with what's represented in the viewport. I think that's what most users would expect as the default behavior for an exporter.
I also think most people who have need for an Alembic file will almost certainly have plans to take it into another DCC which would likely already have the capability to do things like deleting surfaces etc. I know Maya, Max and Houdini have these capabilities already.
My own workflow (and a few others that people have mentioned they're working on) relies heavily on vertex count and vertex orders of the FBX export and the Alembic export matching. V2 had the vertex counts matching and V3 has the vertex orders matching, but the vertex counts only match if there is no hidden geometry on the Daz figure.
I am also a huge fan on automating workflows as much as possible. I can easily automate getting the vertex orders to match but I doubt I'll be able to automate getting the vertex counts to match as it will likely require user intervention, either by running your future powershell app as in your example or in the case of my own tool, manually selecting the surfaces to delete.
Personally, I would consider flipping the logic of the Sagan exporter. By that I mean exporting only the visible geometry by default, with an option to export all hidden geometry if that's what the user really wants. Kinda like what the FBX export does.
At least I can still use V2 which means I can keep my automated processes working.
I am very grateful for the work you've put into this plugin.
Edit: Just had another thought.. all of the Alembic importers I've experimented with have a "Use visibility" option to determine if they should load invisible geometry or not. I don't know the inner structure of Alembic files but this implies it has support for setting some kind of flag/property to denote if geometry is invisible or not. So even if Sagan exports all geometry, perhaps it could set the approriate visibility flag on hidden geometry?? That way we could have the best of both world.
Hi @mrpdean_7efbae9610 Thanks for your feedback. I'm not aware of the visibility flag in Alembic, so I'll have to research that. I'm surprised that counts would not match in v3 because, unlike v3, it always exports all surfaces. The visibility is only considered at the object level, and I wouldn't think anything would have to match above the object level. But that should be a non-intrusive change; I'll research how to do it.
And as part of my effort to protecgt Sagan from DAZ by removing as much of it from the DLL as I can, The Lord of the Plugins will eventually replace Sagan, and then even the basic export will be a Powershell app. That should make automation even easier. I have read other posts saying that the headless sample code in the SDK now works, so perhaps I'll be able to get it working without even having to run the full-blown DAZ Studio, i.e. everything truly automated. Something I've wanted for over 4 years.
Thanks again for your input; I'll let you know what I find.
I think that is the core of the issue I'm facing with V3. That is, V3 always exports all geometry whether you want it or not whereas the FBX exporter can be set to only export visible geometry with it's "Visible only" option, which I think is on bny default, which makes sense to me. This can lead to a mismatch in vertex counts between the exported FBX and the exported Alembic file.
P.S I found the thread on your The Lord of the Plugins project. Very cool!
But even v3 has an option to not export invisible objects "Ignore Invisible Objects" . It doesn't go down to the object surface level like v2 does, but whole objects can be excluded. Would that work for the time being?
Or are you saying that the FBX, like you suspect Alembic does, has something in its format that says not to instantiate certain geometry even though it is encoded in the file?
Thank you for this detailed answer! I may have a workaround for the moment wich would be to just apply a simple hair cap on my daz character, which geometry would be exporting well in Alembic keeping the animation, and I could grow hairs on this specific hair geo in C4D (while reducing its opacity to 0 to hide it). The problem is that I don't know where to find a simple hair cap product on the marketplace. I can do same with a full hair set but it is a bit heavy to have all the polygons for nothing (because they will end up being hidden). Do you know how I could find such simple hair cap geo somewhere?
Looking forward to see the further development of your plugin!
J.
Hi,
I don't know of any product, but I can't believe that this doesn't exist... maybe ask a general DS question in one of the other forums?
But if you've got modeling skills, you could just export the character at base res, select the faces you want for the cap, and import that back into DS with the Transfer Utility.
Or in C4D you can you somehow parent the hair cap geo to the Head bone, and use something like Blender's Shrink Wrap modifier?
In any case, "extract hair cap" seems like a perfect example of a simpler, more specific applet I should write. I'll put that on the list.
To be honest, I don't know what I'm saying anymore :) I think I've managed to confuse myself somewhere along the way.
I decided to run a few quick, controlled experiments to see what was happening. Here's what I found.
As you say, the Visibility options of both the FBX and Sagan exports only act at the object level, not the surface (or polygon) level.
Where things start to differ is that it seems like the FBX exporter never exports hidden polygons, regardless of if the "visible only" option is selected or not. This makes sense to me, going back to the "only export what's visible in the viewport as a starting point" philosophy.
On the other hand, the Sagan exporter will export all polygons of any visible object, regarless of if those polygons are visible in the viewport or not. So, the default settings for both Sagan v2 and v3 generally produce the same results and those results both differ from the FBX export IF there are any hidden polygons on the character.
I'm not sure why I thought v2 didn't export hidden polygons. It's probably because I'm only now at the stage where I'm experimenting and testing with more complex character setups. For example, clothign which auto-hides part of the characters body.
This is basically where I'm running into problems with my workflow.
Now in theory, with V2, I could at least assign those hidden polygons to a surface and set that surface to be ignored in the V2 exporter and that would get the vertex counts to match again, whereas with V3, there really nothing I can do on the Daz side of things to get both the FBX and Alembic vertex counts to match.
I don't think there is anything in the FBX or Alembic specs that can set visibility at the polygon level. I think you're correct in that it's only set at the object level. I think it's probably more a case where the FBX exporter is just ignoring hidden polygons and therefore doesn't write them to the final FBX output... I'm only guessing. I don't actually know how it's working under the hood.
On a somewhat unrelated note, I said above that V2 and V3 generally produce the same results. I did come across one instance (with the Centaur character) where they do produce slightly different results.
V2 comes in clean whereas V3 is coming in with the points from the deleted parts of the character still visible. This one is really weird and it's very much an edge-case so I wouldn't worry about it. Just though I'd mention it in case it has anything to do with the dicsussion above.
Oh, now I get it... a geograft. Yes, that's one of the things that I never was able to reverse-engineer: how to tell when a face is hidden.
I think the first applet I'll write will most likely be to provide this functionality.
I think you're right. I think it's the FBX exporter which is more aware of "hidden polygons" that I am, unfortunately.
OK, I understand that one, too. v2 has an optimization to re-count the vertices, and only encode vertices that are actually part of a face. I removed it in v3 because people really wanted the vertices to match in count and order. I'm not immediately sure how I can not encode certain arbitrary faces, have the vertex count and order match, and have no non-manifold geometry left over...
Maybe something will jump out at me if I can actually figure out how DS represents a hidden polygon.
Thanks for the insights on how things are actually being used.
Hi there... it's me again.. sorry :)
Do you think it would be possible to update the Sagan exporter to use the node names rather than the node labels when writing the Alembic file?
The FBX exporter uses node names whereas the Sagan export seems to be using node labels.
Changing Sagan to use node names would greatly help with my workflow as it would allow me to auto-match shapes between the FBX exports and the Alembic exports, and I can't think why it would break anyone elses uses for it.
Thanks