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
Hi, @Ambrozewicz
Different programs that already support Alembic should already be largely supported. The wrinkles will be: Scaling, vertex order, and materials. Scaling is easy, you can probably just tell be what the default units are, and I'll add it. Vertex order is aso easy because there are only two possibilities. You can export something and import it into 3DS Max, and either it works (perhaps at the wrong scale, though) or the normals are flipped and needs an option to reverse the order (and I just realized that I haven't tested that with Maya nor Motionbuilder, so thank you). Neither of those is a big deal.
But materials are a different story. While 3DS Max could not in good faith say they support Alembic if it didn't preserve Daz Studio's surfaces, Alembic does not support materials at all, beyond that. This exporter leverages and automatically re-applies the materials converted by the excellent Diffeomorphic Daz Importer, but that, of course, is for Blender. I cannot take on an effort of such complexity and size as that; I'm not one of those more courageous (and more techically proficient with just understanding how materials work) guys here who have done exactly that :) With 3DS Max, there are no freshly converted materials lying around to just pick up and apply.
But then again, that is only to have them automatically applied. If you've got your own native materials, and I am correctly assuming a minimum of 3DS Max Alembic support, the surfaces should have survived, and you can just apply them. If there should appear a way to convert materials to 3DS Max, we can then talk about how the exporter might leverage them.
So, let me know about the units and the vertex order, and I'll make what changes are necessary to prepare for such a time.
@JClave
OK, so this implementation is getting out of hand.
While it looks like just searching for a mesh with a material slot name that fits a regular expression will work, it's made more complicated because of all the ways that names of armatures, meshes, and material slot names can collide and be renamed in ways that the Alembic Exporter cannot know when it runs. While that is not an insurmountable problem, it is rather a PITA and I haven't finished it yet.
But I think it should still be done as an option because:
I haven't yet investigated why, but parsing the DSON on my laptop, which is not Threadripper but still no mean slouch, what took 3 seconds on Linux takes 3 minutes to uncompress and parse a (compressed) 50MB duf file that has dForce data in it. This would only have to be done once, and then a script to remember applied materials and another to re-apply them in the future would be used. I'll see about making it faster, but in the mean time, it works like a miracle.
I'll keep you posted.
you really only need a way for it to easily copy the materials off an object exported first I reckon as thats how I use the DAZ one in Octane for example but maybe using the obj and mtl file or something so it can load in any program supporting abc
To clarify, is this issue regarding the default option? (parsing .duf file to name exact material id's)
Or is it regarding the 'Express option' and trying to get it to work with Diffeomorphic?
Also regarding the material renaming issue, I don't think the exporter should cater to the scenario.
Wouldn't it make everyone's life easier, if either through user manual or with automated scripting, that scenario is explicitly prevented?
i.e. state in the user manual that you are supposed to use alembic exporter straight after diffeomorphic plugin import.
or adding automated script that combines Diffeomorphic material generation and Alembic import together so that, Alembic import and Diffeomorphic material generation always happen together and therefore use the same id
@WendyLuvsCatz Yes, that's the idea and by having the material slot names match, the "copying" is done automatically. It's made difficult by facts that Diffeo and the Alembic exporter name objects and material slots differently, and mostly because Blender automatically numbers the name of an added object if that name is already in use, which neither the exporter nor a material script will know. It's still possible, but it is not as straightforward as both @JClave and I thought it was.
Reading the DSON is slower, but everything works fine. This is just with the express option that needs to be fast.
How could it not? What is the alternative?
That's my workflow exactly. That doesn't solve the renaming problem. The Diffeo plugin by itself already has naming collisions between armatures and meshes, so the name of the mesh already may not be the name that the Alembic Exporter thinks it is. And collisions are the consequence of both exporters exporting the same things; how could they not use similar names?
I don't see how this could be done without creating dependencies on the internals.
I still think it is possible, it's just not as simple as the Alembic Exporter knowing an explicit mesh with an explicit material slot name. It'll have to search for things given a POSIX regular expression, and I can help by ensuring that mesh object names are unique, much like the material slot names. The script can change everything back at the very end.
After sleeping on it, I think that since Diffeo has to parse the duf file anyway, I'll investigate hacking it to output a JSON file that just maps the objects' labels to its surfaces, and its surfaces to their material IDs, and then try to convince Thomas to accept the pull request.
Sorry again if I fail to understand exactly what this is referring to.
Is this about changing the Diffeo's script that gets run during export from Daz?
@Padone
I'm seeing some behavior that confuses me. With the latest build, I imported a model with Cycles as the render engine. It looks fine in both material preview and render mode, but some materials preview as all black, as in the attached image. I've noticed that these materials have one thing in common: they import with a Normal Map node.
Further, if I import the Alembic, which gets the same material IDs, the materials also preview as all black, look fine in material preview mode, but in render preview mode, the material renders as all black. And looking at the node setup, the same Normal Map's UV Map now has a red background, and the only option in the dropdown is different, "uv" in lowercase, while the current value is "UV" in uppercase.
Selecting "uv" in the drop down just switches the problem; The material renders all black on the diffeo model, but fine on the alembic. Deleting it altogether causes it to render correctly on both models, but presumably without the benefit of the map.
Have you any idea at all what is going on here?
During import into Blender. Or rather, whenever it parses the duf file, which I don't think the export_to_blender script does.
@TheMysteryIsThePoint
As for the material preview it seems that blender has issues when multiple uvs are used, aka when we use the uv map node in the material setup. This is limited to the material preview though, the rendering and viewport preview work fine so there's nothing to worry about. I guess this may have something to do with the active uv in the uv map list but I didn't take time to investigate since this seems rather a limit in the material preview panel.
https://bitbucket.org/Diffeomorphic/import_daz/issues/70/weird-geograft-issue
As for the material ids I'm not sure to follow. Why do you have to get the same object names as diffeo ? Is it not enough to get the material ids ? I do not know the blender api so if you can only access materials by object properties then I understand. But if there's a "material library" in the scene description then there's no need for object names.
Also as for parsing the duf files, can't you just skip the simulation data ? Again I do not know the daz api so it's a pure question.
Okay, so this new JSON contains material id information used by Diffeomorphic.
And does the user need to configure the Alembic exporter to read this JSON file during export in Daz?
Or is it automatically read somehow during import in Blender
@Padone
I'm seeing it render black as well. Choosing the map present in the drop-down renders, but with those visible creases along the edges of the faces. The only way to remove the creases seems to be to delete the uv map altogether, and it seems not to degrade the visual detail at all. Is the uv map absolutely required, or is it just an optimization?
I meant that the object names do not necessarily need to match, but they need to be in such a way that the Alembic Exporter can, at the time that it runs, figure out which of its objects correspond to which Diffeo objects. The basis of being able to apply materials without parsing the DSON is that per object, there should be only one material slot whose name is a function of the Daz Studio material group name. If the Alembic Exporter cannot know which Diffeo object corresponds to the one it is considering, the material IDs are ambiguous because more than one could fit the regular expression, i.e. default-1 from object1, default-2 from object2, etc... But Diffeo and Blender itself both create renumbered object names, making this correspondence difficult to establish.
The DSON material_library only describes the material itself, not where it should be applied.
How a material is associated with a surface of a node is easy enough to figure out from the DSON, but the problem is that Diffeo's naming convention will cause Blender to number the names in order to make them unique in a way that the Alembic Exporter cannot know. That the Alembic Exporter will also want to use the same name means that it cannot even count on objects to retain the same name that it itself exported. An object that theAlembic Exporter reckons as "Object" can actually ultimately be "Object", or Object.00n"; it can't even, in a straightforward manner, find objects that it itself exported! This makes it difficult for it to generate a script to know which Diffeo imported material to apply to which Alembic Imported object and material slot; there's a bit of tortured logic to "find" the right Alembic imported object, and the right Diffeo imported object that correspond to each other.
For example, a Daz object whose label is "Object" will show up after Diffeo import as either "Object" or "Object.00n" I think it can be distinguished because only one will be a MESH object, and none of its materials should follow the Alembic Exporter's object#surface naming convention. If none do, then this "Object" is the Diffeo imported object, and its material_slots are the one we want to apply to the Alembic exported object.
The Alembic exported object should be an object named "Object" or "Object.00n", all of whose material slots DO follow the object#surface naming convention. And ach of its material slots of the form "material" should receive the Diffeo object's material slot named "material" or "material-n". There should only be one, if my reasoning about the DSON node_instance, geometry, and material_instance is correct.
As far as I know, there's no DSON parser library that has this functionality. I don't think a DSON file has any indices into the data, and the only way to reliably skip a section would be... to parse it. I could be wrong, and honestly hope that I am. Failing that, I think I've figured out where Diffeo parses the nodes and material sections of the duf, all that is needed to establish the object/surface to material_id correspondence. It's just that I am not yet an experienced Python programmer and am not versed in all the idioms that Thomas uses. As a result, anything that I suggest to export this data for external applications sticks out like a sore thumb amid his quite elegant code. I'll have to keep thinking about it for a while.
I believe it can be made to default to the same directory where Diffeo read the duf file, which the Alembic exporter knows as well.
Diffeo uses the extra uv map nodes when daz uses multiple uv maps. Usually for shells. So you can't remove them. I don't seem to get "creases" related to uv maps. Then if you have a specific example you need to explore better I can look at it.
I didn't get you were talking about avoding to parse the duf file. In my opinion using the unique material ids in the duf file is the easy way and that's what Thomas does. Everything else risks to be a "guess" because of the blender object renaming that you are trying to manage.
Then I understand z-cycles by @JClave has its needs too. But if it could stick to the duf ids as well it would be easier to transfer materials.
@Padone
OK, you've caused a lightbulb to turn on. The materials that render black are ones that have multiple uv maps, and when a map other than the first one is selected. Because I didn't know what else to do, the Alembic exporter always grabs the first uv map. This could account for why the same material on two different objects behaves differently: the Alembic model has the wrong uv map.
I'll invenstigate further, but if this does not resolve the problem, I would appreciate your briefly looking at a .blend file that I upload.
But before that, thanks for your insight... that is probably the problem.
Please note that as for shells they get their own geometry in daz studio, while they are imported with an additional material layer in diffeo without the extra geometry added up. This helps to optimize the figure for animation.
I haven't tested much in the area of geoshells and geografts. Thanks for the note.
New version.
Alembic Exporter 1.11.0.0
Under the materials tab, there are now two methods. The Diffeo option parses the .duf file, and so if you import with Diffeo first, and then import Alembic, all the materials ( less, a bug when a surface has multiple UVs, more on that later) will match and be applied automatically. The object#surface option does not parse the .duf, but names the surfaces with a regular pattern that can be inferred from the geometry. This is useful because the exporter also generates a script to rename the materials once they are in Blender, using the same regular pattern, and so the material IDs will once again match, without having to parse the .duf every time, which is faster.
@Padone I've defaulted the base directory to the export directory, please verify that this is what you had in mind.
@JClave Look at the Quick Export tab and let me know if that works for your needs. It's not implemented yet, but it's next :) The exporter does not consider changing the active tab as a significant change in order to prompt you to save the configuration, but if you explicitly save the configuration, it'll remember what tab you were on. This is to speed up your rapid-fire testing of materials.
@marble Go ahead and try... it should automatically apply the Diffeo converted materials, except for some, which because of a Blender bug, will render black (in Cycles). All you have to do is go into the Shading tab at the top, and for every material that shaeds black, find its Normal map, click on the UV Map (it should be red), and select the one offered from the drop down. This is a pain, but you only have to do it once because after you fix them, you can run the rename script and save the renamed materials, and then export Alembic using the object#surface option.
Next up is:
Thank you for the update!
I am happy with how the material naming works with the Object#Surface option.
I did a quick test with duplicate figures (but different names) and they seem to work well.
And sorry I meant to ask about the Quick Export feature beforehand.
I am trying to understand what the use case for this feature is.
If I understand correctly, this is so that a script can remember material naming the first time so that it can be re-applied on subsequent exports.
(Or is it remembering the whole material section in .duf?)
I assume this feature is specifically targetted for Diffeo-users so that .duf parsing doesnt have to be done within Alembic.
Because all Z-Cycles needs is the Object#Surface option so that material naming can be inferred and duplicate namings are prevented.
@TheMysteryIsThePoint Thank you for the update that's awesome. Going to check it ..
@JClave Ha ha maybe it's me that needs to better understand your requirements. You made it sound like you foresaw an iteritive process of perfecting the materials. This led me to assume that a one-click export method that wasn't concerned with the other details that would always output to the same files would be most convenient.
If I'm totally wrong, and you just need the material slot naming convention, I can just remove the tab.
@Padone I also investigated putting the exporter on the FIle menu, but believe it or not, that's more envolved. For some reason, the SDK has a DzEditAction class, and some others, but no DzExportAction class. This means that I'll have to figure out the details of the menu item stuff myself, and of course none of it is documented.
There seems to be a lot of talk about Blender, but does this plugin play well with Cinema 4D for animation?
@Auroratrek
Probably; Alembic is relatively agnostic. The plugin has a lot of functionality for Blender, but there's nothing, as far as I can tell, that would make the Alembic file not work in other apps that support Alembic. Without my trying, it has also worked in Houdini, Marvelous Designer, Maya, and Motionbuilder.
I don't have Cinema 4D, so I can't be sure. Could you try it, and together we'll work out whatever wrinkles there are? Off the top of my head, I would need to know the unit of measure C4D uses, and the vertex order. For the vertex order, you could simply import something and tell me whether the normals were flipped or not. So far, Daz wants them one way, and the rest of the world appears to want them the other way.
You, of course, won't benefit from Diffeo's material conversion, but I'd say it will probably just work or be easily made to work.
First attempt - the figure came across but not the textures. I have a plain grey figure in Blender right now.
[EDIT] Ahh I see. I have Diffeomorphic selected but I think, from your text above, I need to import the figure using that plugin first? I'll try the other method.
Nope - I've tried various combinations of export options and still get a plain grey figure in my Blender viewport (this time I tried with Object#Surface).
So my question is - how do I combine the Diffeo import and the Alembic import if both are required for textures?
@marble
You are correct... you need to import with Diffeo first, which will create the materials.
Then, import the Alembic model, having used the Diffeo material slot naming method to export. Those material slot names in the screenshot you provided are the object#surface method, and so don't match anything that Diffeo would have created.
Let me know how it goes.
Edit: Also, avoid multiple imports in the same scene without having cleared out the materials from any previous imports. This will invoke Blender's numbering scheme, and then the material slot names will no longer match. You can clear the materials by deleting the object that use them, and then purging orphan data.
Right. So I still don't get what the Object#Surface option is for. If I understand you correctly, your Alembic exporter needs the Diffeo add-on to be able to transfer materials. If so, when you use it for Marvelous Designer, for example, do it export without materials?