Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Thank you, that is genuinely useful to know for my current workflow.
Thanks for your input, however i think it is not very practical as manually counting vertecies can bring things to a halt especially if you consider multiple high-res objects.
Ok but can we still get subd and base mesh vert count option to append either in a path or as attribute? This has to do with just meshes, not materials..
Yes, I'm going to employ the general, user-defined naming scheme everywhere it is applicable.
@mrpdean_7efbae9610 You are right, I just assumed that blender doesnt store vertex count of its objects in blend data because its slow to count them also considering painfully slow mesh editor in blender so that was my logic. However it isnt slow to count vertecies, subd level 4 of genesis 8 which is 4192586 vertecies took less then a millisecond. But I'd still prefer a stored count due to potential issues you mentioned.
@TheMysteryIsThePoint If you load a .sagan config that was created in a different scene file, it will keep getting reset like before even if you click to save it. Like if i load a config that is made in a different scene and click done and then re open sagan its gone again. Also I suggest "Save As" button for config, because if you have loaded config you cant unload it and there is only save option which overwrites.
Glad to hear that. I'm particularly interested in your UE5 stuff (after watching the State of Unreal, that tech is hard to ignore), so please never hesitate to tell me how I can support you.
I'm almost done with the general naming scheme, and I'll look at the config loading/saving that clandescent1 talked about.
Hi everyone,
Version 3.4 is up in the usual place.
It includes:
As usual, test, and let me know...
Working well for me so far, although I've only been using one of the naming schemes. Haven't looked at the others yet.
Thanks for the update!
Great add-on. Very nice work and really appreciate your efforts on this.
I've spent the last two days working on exporting DAZ to Unreal using the DAZtoUnreal pluigin. The intention is to use the new ML Deformer in Unreal so we don't have to use shapekey jcm's anymore. I ran into one small issue when exporting and was wondering if anyone had any suggestions. The DAZtoUnreal plugin exports an fbx, animation, and alembic. When adding a geograft to the figure, the alembic file somehow generates some loose vertices which causes a vertex count mismatch between the fbx and the alembic exports. For example, when adding the base genesis 8.1 genital geograft, we get an extra 100 loose verts in the alembic file. I get the same results (extra verts) when using DAZ2UE or Sagan. When I export with the obj sequence the geometry is perfect.
I know geografts are constantly a pain, but I can't figure this one out other than to export the obj series and convert to an alembic cache (which I will probably try). Any help would be much appreciated. Tks.
Geografts. I just couldn't reverse engineer it with the given documentation. Nothing I've read online worked. I guess I can take another stab, with a fresh look.
But when you say that obj sequence works, are you referring to Sagan obj sequence export? That would be strange because the underlying calls to get the geometry is independent of how the geometry is actually exported, i.e. either both or neither should cause a vertex count mismatch...
And I assume you are using Sagan v3?
Sagan 3.4
Yes, the obj sequence export from Sagan. I have not fully tested this yet. I had some issues converting the obj sequence to abc but I'll get it. Just takes time.
If you've already looked at it, please don't feel obligated to try again if you don't think it can be fixed. It's a wierd issue for sure. I just checked again and the fbx, obj, and abc file all have the same vertex count and vertex order when I delete the extra vertices in Blender. Basically I select the character model in edit mode, select by trait, and select loose geometry. I tried it with 2 different geografts and they both had extra verts. Some of the verts are along the seam of the geograft while a few others seem to be floating in space. I tried deleting any loose geometry in DAZ but it didn't find anything. The obj exports match up fine (as far as I can tell, I'll have to verify to be 100% sure).
I did manage to export a character with Epic Eyes and got the ML Deformer working, which was the whole point. I'll post up some examples when I can get them looking a little more presentable. So thank you to you and all the other smart people out there making the tools for us to use.
That's wierd, but at least something I can investigate without your context... the Wavefront export and Alembic export should be virtually the same.
The geografts issue is nagging me... I just don't understand very well some of the concepts involved, like Shapes. What the heck is a Shape? I really thought that the Hidden Face Bit was the solution, but it wasn't set for any faces, even ones that the geograft hid. I gave up at that point in 3.3, I think. Maybe a fresh look again is just what I need. It doesn't seem like this should be hard to figure out, but I'm just missing it. I think I'll ask Thomas or David... one of them has simply got to know :)
I'm glad you got what you needed to work, though. And when you're ready, I'm (and probably a lot of other people) very interested in seeing what you did with the ML Deformer, which keeps inching me closer and closer to UE...
The ML Deformer looks really good. I willl be curious to see the results of your experiment and workflow.
I don't know if this helps but a "Shape" as far as Daz Studio is concerned appears to just be any type of geometry node. Figures, props, etc
In this example, there are 3 "shapes" in the scene. Michael 8.1 (figure), the male genitalia (geograft) and the special round glasses (prop):
When exported as an FBX and inspected inside Houdini, I get a name attribute for all 3 "shapes":
Like I say, I've no idea if that's helpful or not but figured it couldn't hurt to mention it :)
It looks like every polygon in the FBX belongs to one, and one one, "shape".
With geografts, you get the duplicate geometry problem. So with the male genitalia for example, as well as being exported as it's own separate "shape", a copy of it's polygons are also merged into it's parent figure (in this case the Michael 8.1 figure).
With the Alembic exporter, I don't know if it's possible to tell if a "shape" is a geograft or not, but if it is possible, you might just be able to ignore it altogether as presumably it's polygons will also be part of the parent figures geometry.
@mrpdean_7efbae9610
Thanks for that analysis... it's always helpful to see Houdini's more detailed view.
I actually said "Shape" when I should have said "Assembly"... Shapes are exactly what you investigated and figured out, but an Assembly escapes me. I can't find an explanation of the concept, the problem they solve, nor how. They seem to lie to you about subdivision levels, and the hidden face calls don't work as I expect them to. It's one of the few things left that I just don't get, and for that reason, the geografted node looks to Sagan just like any other node and all it can do is to export it just like any other. It bugs the heck out of me but I have not been able to understand it.
What you said about the geograft being part of another node is what I thought an "Assembly" might be (it's called an assembly, afterall), but it doesn't appear to be.
Out of curiousity, if you could tell that the node was a geograft, I wonder what would happen if you just excluded the entire node from export? Would the parent figure still contained the merged polygons?
I'm sure you've seen this already, but just in case: https://www.daz3d.com/forums/discussion/109271/is-a-child-a-geograft
Possibly these aren't available in the SDK, I've no idea.
Those functions are all in the DzFigure class and described in dzfigure.h, but this is not enough to know how the functions are supposed to be used.
If I recall correctly, the geograft shows up as just another node. If I export it, there is duplicate geometry. If I don't, there is geometry missing.
So i have some alembic setup that was created with sagan version 3 or above, not sure which one it was. however the latest version, 3.4 has double object paths like someone mentioned before so the new alembics are incompatible. I am using blender. I know someone mentioned it before so i read through the posts but i did not find any solution. This has started with 3.4 i believe. EDIT: Actually ive no idea where this started since ive not touched sagan for a couple of months. It could also be blender version itself, who knows.
So ive done some debugging and the problem was introduced in version 3.3 of sagan alembic. versions before that dont have double paths, its not affected by blender version only by sagan version. Its not a big problem however since this is not intended behavior it would be very inconvenient if at some later version this issue is fixed and then again alembic files become incompatible. If this is an issue with alembic libraries and it is clear that this is not intended behavior, i can suggest a hacky fix(if the issue can be affected from daz at all) a checkbox to trim the double path to avoid potential problem in the future if alembic library gets fixed
The discussion about the path starts on page 15 and runs through to page 16 of this thread.
Sagan V1 and V2 both exported with double object paths (the first being the transform and the second being the object I believe).
Sagan V3 originally exported with a single object path and as a result, the Alembic didn't work in Maya, Max or Unreal Engine. Only Houdini and Blender seemed to cope with having a single object path.
This was fixed (double object path was reinstated) in a later version of V3 although I forget which version exactly. I think v3.0.0.1 would have single object path if you need it.
I'm fairly certain the double object path is the correct way because if you export an alembic from Maya, Max, Blender, Houdini or Daz Studio (using the "official Alembic exporter") they all export with a double object path.
Oh, you re right blender does export it as double. I guess there is no problem then. Thanks!
Suggestion to add an option to export .abc file directly with ability to overwrite the file, instead of creating/overwriting a folder. And some options to custom name .abc file like you did with the objects but I think it doesnt have to have many options just something like a possibility for scene name + some text.
Or at least the ability to custom name the exported folder, I think that would work as well. There are situations where you want to keep the alembic path consistent even though you are using different named scene .duf's, but since exported folder is always named after the scene file it breaks the alembic path in blender. I guess you can put the .duf inside a unique folder and keep the .duf the same name, but that can also get inconvenient I think it would be best if the export folder could be properly named and saved in config.
@TheMysteryIsThePoint
I'm looking into the grograft issue now as well. I found I can get a list of faces on a figure that are hidden by geografts. I'm attempting to skip those faces when exporting to Alembic. Things haven't matched up correctly yet though. Here's the code so far:
Getting the list of hidden faces:
// Get Geograft hidden faces
DzFigure* Figure = qobject_cast<DzFigure*>(FigureNode);
int GeograftHiddenFaceCount = Figure->getNumFollowTargetHiddenFaces();
std::vector<int> hiddenFaces;
for (int hiddenFace = 0; hiddenFace < GeograftHiddenFaceCount; hiddenFace++)
{
hiddenFaces.push_back(Figure->getFollowTargetHiddenFacesPtr()[hiddenFace]);
}
When writing out faces later, I skip these like this:
for (int FacetIndex = 0; FacetIndex < FacetMesh->getNumFacets(); FacetIndex++)
{
if (std::find(hiddenFaces.begin(), hiddenFaces.end(), FacetIndex) != hiddenFaces.end()) continue;
I should mention, if you look here where I mention Follower Auto Hidden Faces, that's what made me think to look at these functions.
Daz To Unreal – Hiding Figure Geometry – David Vodhanel
Ok, I managed to remove the geometry that a geograft hides from my alembic export. What I was missing is those indexes aren't the faces for the DzFigure you're getting the list from. You want to get the list from the DzFigure for the geograft and apply it to the primary figure that's getting the geometry hidden. It looks like this:
DzFigure* Figure = qobject_cast<DzFigure*>(FigureNode);
std::vector<int> hiddenFaces;
for (int GraftFigureIndex = 0; GraftFigureIndex < Figure->getNumGraftFigures(); GraftFigureIndex++)
{
DzFigure* GraftFigure = Figure->getGraftFigure(GraftFigureIndex);
int GeograftHiddenFaceCount = GraftFigure->getNumFollowTargetHiddenFaces();
for (int hiddenFace = 0; hiddenFace < GeograftHiddenFaceCount; hiddenFace++)
{
hiddenFaces.push_back(GraftFigure->getFollowTargetHiddenFacesPtr()[hiddenFace]);
}
}