Loading...
> >

Sagan: A DAZ Studio to Blender Alembic Exporter

24567…20

Comments

  • PadonePadone Posts: 3,700
    edited August 2020

    @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.

     

       

     

    daz-uv.jpg
    375 x 525 - 44K
    blender-uv.jpg
    411 x 256 - 27K
    Post edited by Padone on
  • GordigGordig Posts: 10,060
    TheMysteryIsThePoint said:
    Gordig said:

    Exporting now, which is decidedly less swift than it was previously. An acceptable change if it keeps the materials, though, and it's still going to be much faster than using the bridge. I'm not crazy about how it forces you to save the scene before exporting, but again, acceptable. The interface is much cleaner and easier to digest. I'd prefer if it still showed up in the DS menu as Alembic Exporter, even if you prepend "Sagan".

    And yes, everyone wants the menu option under File, I just haven't gotten around how doing it. Daz, for some reason, did not see to include a DzExportAction class in the way that they included a DzEditAction class, and so I'll need to know all the details of the File Menu which I didn't have to know for the Edit menu. It will eventually get there, but there are other options that I'd likt to have working first. But I'll change the name as you suggest right now.

    Actually, I'd just as soon have it under Scripts with the other bridges.

    TheMysteryIsThePoint said:
    Gordig said:

    I'm still not getting any textures in C4D. Which parameters should I have checked? I tried twice, once without separate checked, and one with, and I get nothing either way.

    @Gordig

    I still don't know if you are referring to the textures not being applied, or if the material zones (or whatver they are called in C4D) are simply not being preserved.

    No textures are applied because Sagan doesn't do material conversion at all. For Blender, it can re-use the textures that the Diffeomorphic plugin converts. This obviously won't work in C4D. Unfortunately, there's nothing I can do there... the task of material conversion for C4D is a whole separate endeavor. But there's got to be a way to reapply the textures with a script to reduce the pain of having to do so. If you could, by hook or crook, obtain such a script that re-applies a single texture, I could use it as a model to output a script that will re-apply all of them. We could figure this out together if it is important to you.

    If it's just the material zones that are lost, then C4D is not respecting the material zones in the Alembic file in the same way Blender does. There is not much I can do there, either, not owning C4D at all.

    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.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    Gordig said:
    TheMysteryIsThePoint said:
    Gordig said:

    Exporting now, which is decidedly less swift than it was previously. An acceptable change if it keeps the materials, though, and it's still going to be much faster than using the bridge. I'm not crazy about how it forces you to save the scene before exporting, but again, acceptable. The interface is much cleaner and easier to digest. I'd prefer if it still showed up in the DS menu as Alembic Exporter, even if you prepend "Sagan".

    And yes, everyone wants the menu option under File, I just haven't gotten around how doing it. Daz, for some reason, did not see to include a DzExportAction class in the way that they included a DzEditAction class, and so I'll need to know all the details of the File Menu which I didn't have to know for the Edit menu. It will eventually get there, but there are other options that I'd likt to have working first. But I'll change the name as you suggest right now.

    Actually, I'd just as soon have it under Scripts with the other bridges.

    But it isn't a script... if anything, I would say File/export.

    Gordig said:
    TheMysteryIsThePoint said:
    Gordig said:

    I'm still not getting any textures in C4D. Which parameters should I have checked? I tried twice, once without separate checked, and one with, and I get nothing either way.

    @Gordig

    I still don't know if you are referring to the textures not being applied, or if the material zones (or whatver they are called in C4D) are simply not being preserved.

    No textures are applied because Sagan doesn't do material conversion at all. For Blender, it can re-use the textures that the Diffeomorphic plugin converts. This obviously won't work in C4D. Unfortunately, there's nothing I can do there... the task of material conversion for C4D is a whole separate endeavor. But there's got to be a way to reapply the textures with a script to reduce the pain of having to do so. If you could, by hook or crook, obtain such a script that re-applies a single texture, I could use it as a model to output a script that will re-apply all of them. We could figure this out together if it is important to you.

    If it's just the material zones that are lost, then C4D is not respecting the material zones in the Alembic file in the same way Blender does. There is not much I can do there, either, not owning C4D at all.

    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.

    @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 :)

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    edited August 2020
    Padone said:

    @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.

     

       

     

    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.

     

    Post edited by TheMysteryIsThePoint on
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    TheMysteryIsThePoint said:
    Padone said:

    @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.

     

       

     

    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.

     

  • PadonePadone Posts: 3,700
    TheMysteryIsThePoint said:

    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.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    Padone said:
    TheMysteryIsThePoint said:

    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.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948

    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

    Alembic::AbcGeom::OPolyMeshSchema::setUVSourceName( const std::string &name );

    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?

  • PadonePadone Posts: 3,700
    edited August 2020

    @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.

    Post edited by Padone on
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    Padone said:

    @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:  "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:  "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":

    Alembic::AbcGeom::OPolyMeshSchema::setUVSourceName( "Base Male" );
    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

    Alembic::AbcGeom::OPolyMeshSchema::setUVSourceName( "Project EYEray UVs - G8M" );
    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?

     

  • JClaveJClave Posts: 64
    edited August 2020

    Please delete this post

    Post edited by JClave on
  • PadonePadone Posts: 3,700
    edited August 2020

    @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 ?

    Post edited by Padone on
  • brainmuffinbrainmuffin Posts: 1,205
    TheMysteryIsThePoint said:

    We've reached the point where it is necessary to distinguish between Alembic Exporters.

    Previous discussion can be found here.

    Get the Sagan Alembic Exporter

    I see the zip contains a DLL. Is this windows only?

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    brainmuffin said:
    TheMysteryIsThePoint said:

    We've reached the point where it is necessary to distinguish between Alembic Exporters.

    Previous discussion can be found here.

    Get the Sagan Alembic Exporter

    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.

  • brainmuffinbrainmuffin Posts: 1,205
    TheMysteryIsThePoint said:
    brainmuffin said:
    TheMysteryIsThePoint said:

    We've reached the point where it is necessary to distinguish between Alembic Exporters.

    Previous discussion can be found here.

    Get the Sagan Alembic Exporter

    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.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948

    @Padone

    Padone said:
    Why don't you like the merge uvs idea ?

    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.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    edited August 2020
    TheMysteryIsThePoint said:
    brainmuffin said:
    TheMysteryIsThePoint said:

    We've reached the point where it is necessary to distinguish between Alembic Exporters.

    Previous discussion can be found here.

    Get the Sagan Alembic Exporter

    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.

    @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?

    Post edited by TheMysteryIsThePoint on
  • PadonePadone Posts: 3,700
    edited August 2020
    TheMysteryIsThePoint said:

    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?

    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.

    Post edited by Padone on
  • brainmuffinbrainmuffin Posts: 1,205
    TheMysteryIsThePoint said:
    TheMysteryIsThePoint said:
    brainmuffin said:
    TheMysteryIsThePoint said:

    We've reached the point where it is necessary to distinguish between Alembic Exporters.

    Previous discussion can be found here.

    Get the Sagan Alembic Exporter

    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.

    @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?

    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.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    Padone said:
    TheMysteryIsThePoint said:

    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?

    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.

    OK, I'll code that up and we'll see what happens.

  • lilweeplilweep Posts: 2,488

    Really liking this.  Really helpful for MD workflow when working with geografts on.

    CapTest8.jpg
    3660 x 2440 - 854K
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948

    That's awesome.

  • lilweeplilweep Posts: 2,488

    youre awesome

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948

    *blushes*

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    Padone said:
    TheMysteryIsThePoint said:

    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?

    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.

    @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?

     

  • PadonePadone Posts: 3,700
    edited September 2020

    @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.

    Post edited by Padone on
  • PadonePadone Posts: 3,700
    edited September 2020

    @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

    Post edited by Padone on
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    Padone said:

    @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.

  • SoulMystSoulMyst Posts: 10

    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!!!!!!

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,948
    SoulMyst said:

    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.

Sign In or Register to comment.