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
@TheMysteryIsThePoint
As for the texture issue I suspect you may be using the daz uv map id to export the uv map. While diffeo uses the uv map label to help comparison with the daz materials especially when shells and geografts are used where there are multiple uv maps involved. This may be why the uv maps don't match. Then this only affects the blender material when the uv map name is used explicitly, as for example for the normal maps. This is why the bardot outfit doesn't work while G8F and the toulouse hair work.
If this is the case then the fix should be to export the daz studio uv map labels instead for the diffeo materials option.
Actually, I'd just as soon have it under Scripts with the other bridges.
Ok, I may have misunderstood what you meant about textures before, since I didn't follow your previous thread very closely. I haven't tried retexturing the models yet, but they load with a number of polygon selections that appear to correspond to material zones in DS, so that seems at a glance to be working.
I should also state that I know that you're developing this for Blender, not C4D, and am tempering my expectations accordingly. I'm not expecting you to cater to me or other C4D users, just letting you know what does and doesn't work for your own edification.
But it isn't a script... if anything, I would say File/export.
@Gordig
It's not that I'm developing it "for" Blender. I concentrate on Blender because that's what I use. Not being able to get content out of Blender because the !@#$ Alembic exporter doesn't work was extremely frustrating and so I'm willing to accomodate anyone that I can. But there are practical considerations: I don't own C4D, and even if I did, I am not a materials expert. @Padone is. @JClave is. But it is rare that I can even follow the conversation between the two of them :) That's why I tried to leave it open by saying find me a subject matter expert, and we'll see what we can do. I cannot think of a set of circumstances under which someone would ask for functionality that would be useful to them, and I would say "No" if it were within my ability. That goes against the Open Source spirit as taught and practiced by Saint Ignucius, which I have benefited much from, and wish to play forward. But, yeah, C4D materials is a bit beyond me considering I don't even have the program :)
Thanks, @Padone. But nothing I do seems to influence the UV map name when the material is applied to the Alembic model. There was an extremely promising looking function:
Alembic::AbcGeom::OPolyMeshSchema::setUVSourceName( const std::string &name );
and I tried setting the name to "Default UVs" before I wrote the code to figure out what it should really be, based on the material, but it had no effect whatsoever. I am going to look at the Blender's Alembic importer, as I am begining to suspect that it always sets the map name to "uv". I can't see where else "uv" is coming from.
PEBKAC. I forgot to remove the orphan materials before re-importing. Calling setUVSourceName() actually does the trick. If I call it with a string literal, say "Default UVs" all materials with that uv map work perfectly.
But as nothing can ever be easy with Daz Studio, it appears that, like the material ID, the UV set name cannot be gotten via the API, at least through any obvious function. I tried getName() and getLablel() on the object's DzUVSet, and most of the time the function returns a zero-length string. I suspect that Diffeo is again getting the name from the DSON, and I will do the same.
But if true, this does improve the case to suggesting to Thomas that a "data exporter" has a place in Diffeo, because there's turning out to be quite a bit of information in the DSON that doesn't appear to be accessible from the SDK.
*sigh* If I didn't love Daz Studio so much, I would hate it. I would hate it.
LOL .. You're doing a great job here, especially considering the daz "documentation". As I understand it Thomas doesn't use or even know the c++ api. It would be great for example to have a c++ version of the hd exporter since it's so slow in diffeo. It also may be that having to parse the dson is considered an "integration" to the api. So this may just be how it is supposed to work. Then Thomas is often online and usually available at diffeo so for any integration he should be easy to contact.
Waiting for the update. Thank you for this great tool.
@Padone, and everyone else, thank you for the kind words. They do keep me motivated when dealing with the worser aspects of the SDK.
Things are looking good.
The UV set is actually in the same DSON object where material ID comes from, only that it is often a URL that refers to an external file, so now I have need of the same paths strategy that Diffeo uses to locate content. And sometimes the duf file is compressed, but uses the same extension so I have to read the first two bytes just to see if I need to decompress it. And since the same file is referenced several times, I need to imlement some sort of caching but not so much that I consume too much memory, by some metric. All of this is easy stuff, but it'll take a little time. I am confident that the Diffeo materials will eventually "just work", probably over this three-day weekend, and I can get back to the other functionality I promised.
Anyone have any bright ideas on what to do when different materials within the same object use different uv maps? As far as I know, Alembic only supports one uv map per object, i.e. there is
at the mesh (object) level, but no such call at the face set level.
Analyze the uv maps and warn when all the uv maps for all an object's surfaces are not the same? Use the most popular uv map among the object's surfaces? Consider it an error that must be rectified?
@TheMysteryIsThePoint
That's a odd limitation I wasn't expecting from an advanced file format such as alembic. May be you can merge all the uv maps into a single uv map then, same as merge uv for the obj format. Then for diffeo you will also need a script to run in blender to set all the scene materials with the alembic uv map name. This will scramble the diffeo materials because the vertex order doesn't match with alembic, but that apart should work fine.
edit. This will work because the uber shader has a limit of one uv per vertex, that's why shells get a geometry. Using multiple uvs per vertex is a diffeo optimization for shells.
@Padone This is why talking to you is so helpful to me. It would be an odd limitation indeed, and you saying so caused me to stop, step back, and re-evaluate my understanding. I think there is nothing wrong with Alembic, it's just that Alembic Meshes do not perfectly correspond to Daz/Blender objects. It's just how Blender interprets them. Alembic meshes are more general than Blender objects.
I think all of the uv and material problems would go away if I were to segregate the Daz objects by its material zones that use different uv maps, and create a different Alembic mesh for each one. That way, I can assign the correct uv map, and it'll again automatically correspond to the correct material imported by Diffeo. For most objects, there will be no difference because all of its materials refer to the same uv map. But a Daz object that uses more than one uv map will get broken up into multiple meshes and therefore multiple Blender objects. I can live with that, and any new objects can have an obvious name that indicates where it came from.
For example this is how a certain G8M I have breaks down, materialID versus uv map name:
DEBUG: material ID from DSON: "Lips-1" "Base Male"
DEBUG: material ID from DSON: "Teeth-1" "Base Male"
DEBUG: material ID from DSON: "Torso-1" "Base Male"
DEBUG: material ID from DSON: "Ears-1" "Base Male"
DEBUG: material ID from DSON: "Legs-1" "Base Male"
DEBUG: material ID from DSON: "EyeSocket-1" "Base Male"
DEBUG: material ID from DSON: "Mouth-1" "Base Male"
DEBUG: material ID from DSON: "Arms-1" "Base Male"
DEBUG: material ID from DSON: "Pupils-1" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "Fingernails-1" "Base Male"
DEBUG: material ID from DSON: "Cornea-1" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "Irises-1" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "Sclera-1" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "Toenails-1" "Base Male"
DEBUG: material ID from DSON: "EyeMoisture-3" "Basic Male"
Currently, this gets imported into Blender as a single object, and the Pupils, Cornea, Iris, and Sclera are all black because they are using the "Base Male" uv map, when the material calls for "Project EYEray UVs - G8M". The proposal is to split the G8M into two objects, "Genesis Male#Base Male" and "Genesis Male#Project EYEray UVs - G8M":
DEBUG: material ID from DSON: "Face-1" "Base Male"
DEBUG: material ID from DSON: "Lips-1" "Base Male"
DEBUG: material ID from DSON: "Teeth-1" "Base Male"
DEBUG: material ID from DSON: "Torso-1" "Base Male"
DEBUG: material ID from DSON: "Ears-1" "Base Male"
DEBUG: material ID from DSON: "Legs-1" "Base Male"
DEBUG: material ID from DSON: "EyeSocket-1" "Base Male"
DEBUG: material ID from DSON: "Mouth-1" "Base Male"
DEBUG: material ID from DSON: "Arms-1" "Base Male"
DEBUG: material ID from DSON: "Fingernails-1" "Base Male"
DEBUG: material ID from DSON: "Toenails-1" "Base Male"
and
DEBUG: material ID from DSON: "Pupils-1" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "EyeMoisture-2" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "Cornea-1" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "Irises-1" "Project EYEray UVs - G8M"
DEBUG: material ID from DSON: "Sclera-1" "Project EYEray UVs - G8M"
This is actually functionality I had planned to implement later, so that different modifiers could be applied to different material zones of an object. Do you, or @JClave, or anyone else, see anything obviously wrong with this proposal?
Please delete this post
@TheMysteryIsThePoint
If you split the meshes then you may have normal issues at the borders. Unless you can split the normals where the vertex is doubled. Then the normals are recomputed during animation so I suspect this will only work for the first frame. Also there are some materials that may rely on manifold meshes to be computed right, especially for volumetrics, refraction and some sss.
Why don't you like the merge uvs idea ?
I see the zip contains a DLL. Is this windows only?
@brainmuffin Yes, I do not own a mac nor am I competent to develop in that environment.
Ok, thanks for confirming. This is a very interesting discussion thread, none-the-less.
@Padone
It's not that I didn't like it, I just thought I could solve the problem with code that I was already going to write, anyway. But I am disposed to take your word for it about the problems that might be encountered by splitting the mesh.
Let me see if I understand what you are suggesting: You mean to "bake" the multiple uv maps into a single uv map by figuring out which uv map each face uses, based on the material group it belongs to, and exporting that new, single, baked map? And then updating all the meterials in Blender to refer to that map as well?
Thanks for your ideas, your are being a tremendous help.
@brainmuffin I should have mentioned that I'll be publishing the code as soon as it settles down. I'd be more than happy to work with anyone who knows how to develop for OSX (you?) to get it working on that platform. Not going to leave a fellow UNIX user out in the cold :) In my understanding, OSX is closer to UNIX than Windows, so it shouldn't be that hard... but is there SDK for OSX?
Yes exactly that. Beware that this can only work because the uber shader gets a single uv per vertex. As for shells I hope this will work as well since hopefully shells will preserve the vertex order being them an instance of the main mesh.
By my background, it would seem I could help convert this, though I'm on an iMac that is two version behind on macOS and cannot be upgraded. I've also never written anything for the Mac, though I've had XCode for years. I will help as I can though.
OK, I'll code that up and we'll see what happens.
Really liking this. Really helpful for MD workflow when working with geografts on.
That's awesome.
youre awesome
*blushes*
@Padone
I think I see different faces refer to the same vertex multiple times, but always also with a different uv index for each, which I think this accounts for why there are often more uv coordinate pairs than there are vertices. The Uber Shader aside, would this also protect us from the problem you foresee?
@TheMysteryIsThePoint
This is normal. Since a uv map is usually divided in uv islands, you have multiple uv points for the same vertex where there are seams. This doesn't mean there are multiple uv maps.
@TheMysteryIsThePoint
I got that the diffeo HD exporter already exports a merged uv map, so hopefully you could use the HD materials and it should work. I just fired a bug report on this so it's waiting for Thomas to review.
https://bitbucket.org/Diffeomorphic/import_daz/issues/184/bad-normals-in-the-hd-export
@Padone Thanks for the heads up.
Just wanna say I finally got around to install sagan and test it yesterday and could kick my own butt for not installing it sooner; vertex perfect indeed with geographs and hd detail and tested quite a few animations. Only thing I could not quite figure out at the start was how to re-texture the mesh in blender.... not create nodes and manually set texture (which would have killed my will to live) but I mean with the diffeomorphic checkmark until I realized importing the alembic file, then save the same mesh with diffeo and quickly importing that also into blender and all I needed to do was just quickly re-map the diffeo model textures to the alembic and walla!! hell of lot of work saved and I have animation and textures quickly....
.....super awesome work!!!!!!
@SoulMyst
Glad it's being useful for you. If you import the same scene with Diffeomorphic before importing the Alembic, it will reapply all the textures for you. But since the Diffeomorphic materials mode takes so much longer to export because it has to hunt down all the materials information in the duf files (a lot of work has been done to ensure compatibility with Diffeomorphic's excellent material conversion), there will soon be a script to save the materials as they are, and another to re-apply them without having gone through the full export.
There are still a few gotchas being worked out still, having to do with objects with multiple uv sets, but it otherwise seems to be stable. There's more functionality coming after things have stabilized and assuming no bombshell bugs are found.