Loading...
> >

Alembic Exporter

123578

Comments

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    Padone said:

    @TheMysteryIsThePoint

    If you can't find a better option I'd go with reading the duf file. That for materials only should be fast enough anyway. I see Thomas exports the material labels in the export hd script so I don't know if this may be useful. But he doesn't export the material ids that are available only in the duf file.

    @Padone Does the import script not use the material id as the material's name, and hence the material slot's name?

  • WendyLuvsCatzWendyLuvsCatz Posts: 38,204

    yes 

    I have too many issues just rendering anything in Blender right now so haven't been but when I sort that out looking forward to this

    (its not wanting to use my graphics card)

  • marblemarble Posts: 7,500
    TheMysteryIsThePoint said:

    OK, it turns out that I was misunderstanding the relationship between material groups and materials. The level of indirection that I though existed, doesn't really, and it is similar to Blender: The material group's name is also the material's name. So all I need to do is find the material of the same name, and name the group after the material's asset id, and we're done, right?

    Wrong, of course.

    material->getAssetId() returns not the same id from the DSON, but the material's shader. I have no idea why. After a brief period of elation thinking I may not have to parse the DSON after all, I may have to.

    But it did later dawn on me that once I have the material's id, and it should now match the Daz Importer, we will have acheived perfect compatibility: If one imports a model with Daz importer first, and then imports with Alembic, the Alembic model will assume all the textures automatically. That's worth the trouble to parse some DSON :) Then I think it may be useful to rename the materials to something more orthogonal, and move them to a material encyclopedia from where they can be linked later.

    This is going to take a little longer, but I think I can see the light at the end of the tunnel, and then we can move on to other cool functionality.

    I can wait. I'm sure we all appreciate the efforts you techie wizards are making towards interoperability. If you had one of those buy-me-a-coffee links I'd buy you one.

  • TheKDTheKD Posts: 2,691

    Yeah, much appreciation to people out there coding this stuff.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    @marble Ha ha, thanks. I think to see you up and rendering in Blender is the true reason I'm doing any of this :)
  • marblemarble Posts: 7,500
    TheMysteryIsThePoint said:
    @marble Ha ha, thanks. I think to see you up and rendering in Blender is the true reason I'm doing any of this :)

    Yeah, I know. I'm not quite the Blender evangelist yet but you guys are making it possible for me to become one. I still have so much to learn but then I'm still learning new things about DAZ Studio and I've been playing with it for 15 years. I'm between projects right now - that sounds grand and professional but I am just a hobbyist and the "projects" are my personal follies but they keep my creative juices flowing - so I spending more time watching Blender tutorials. 

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    @WendyLuvsCatz Cycles or EEVEE, Wendy? If Cycles, is your device listed and selected under system Cuda and/or Optix? Rendering with GPU compute? If EEVEE, does your device show up under OpenCL? You probably checked all of that already, just a third party sanity check...
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    marble said:
    TheMysteryIsThePoint said:
    @marble Ha ha, thanks. I think to see you up and rendering in Blender is the true reason I'm doing any of this :)

    Yeah, I know. I'm not quite the Blender evangelist yet but you guys are making it possible for me to become one. I still have so much to learn but then I'm still learning new things about DAZ Studio and I've been playing with it for 15 years. I'm between projects right now - that sounds grand and professional but I am just a hobbyist and the "projects" are my personal follies but they keep my creative juices flowing - so I spending more time watching Blender tutorials. 

    Oh, you will be *dramatic pause* You will be.
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    TheKD said:

    Yeah, much appreciation to people out there coding this stuff.

    I think when @JClave's build is available, these three tools are going to be awesome, together. For me, the last missing piece is a retargeter and mocap cleaner upper. I'm going to try again to research the stuff I didn't understand about bone orientation/rotation and complete that.
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    BTW, when the industry standard advances to Python 3.8, it will support shared memory and it would be feasible to do away with all of these file formats and have a proper bridge directly from Daz Studio to Blender. When one thinks about it, most of these incompatibilities are because of general file formats that don't understand specific applications, like FBX and BVH.
  • JClaveJClave Posts: 64
    edited July 2020
    TheMysteryIsThePoint said:

    OK, it turns out that I was misunderstanding the relationship between material groups and materials. The level of indirection that I though existed, doesn't really, and it is similar to Blender: The material group's name is also the material's name. So all I need to do is find the material of the same name, and name the group after the material's asset id, and we're done, right?

    Wrong, of course.

    material->getAssetId() returns not the same id from the DSON, but the material's shader. I have no idea why. After a brief period of elation thinking I may not have to parse the DSON after all, I may have to.

    But it did later dawn on me that once I have the material's id, and it should now match the Daz Importer, we will have acheived perfect compatibility: If one imports a model with Daz importer first, and then imports with Alembic, the Alembic model will assume all the textures automatically. That's worth the trouble to parse some DSON :) Then I think it may be useful to rename the materials to something more orthogonal, and move them to a material encyclopedia from where they can be linked later.

    This is going to take a little longer, but I think I can see the light at the end of the tunnel, and then we can move on to other cool functionality.

    First, I would like to understand your planned workflow on how Diffeomorphic's material script is applied to Alembic imported objects.

    Are you making changes to Diffeomorphic scripts so that the material creation scripts can be applied?

    Or are you importing a .duf file via Diffemorphic and using your own custom script to copy over materials?

    Or something else?

     

    I'm having trouble seeing why not simply infer the material id from material script within blender.

     

    The .duf files may look small but they are gzipped. So if you extract it, they can be 10x the size.

    i.e. a single Victoria 8 with full Samurai outfit is ~9MB in raw DSON file  vs 595KB as gzipped .duf file

    And for large scenes, I can only imagine how big the raw DSON file will be. (100MB? possible)

    I can see DSON parsing within Alembic exporter definitely slowing down the export speed noticeably

    Post edited by JClave on
  • JClaveJClave Posts: 64
    edited July 2020

    duplicate post deleted

    Post edited by JClave on
  • WendyLuvsCatzWendyLuvsCatz Posts: 38,204
    edited July 2020
    TheMysteryIsThePoint said:
    @WendyLuvsCatz Cycles or EEVEE, Wendy? If Cycles, is your device listed and selected under system Cuda and/or Optix? Rendering with GPU compute? If EEVEE, does your device show up under OpenCL? You probably checked all of that already, just a third party sanity check...

    yeah both my 980ti and onboard Vega graphics show, it did work at some stage but a Nvidia driver update or so ago it stopped working 

    Post edited by WendyLuvsCatz on
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    JClave said:
    First, I would like to understand your planned workflow on how Diffeomorphic's material script is applied to Alembic imported objects.

    If I can duplicate Diffeo's reckoning of materials, no script will be necessary. Since the material slot names will all be the same for both both import methods, simply importing the Diffeo model and then importing the Alembic model will have them all applied correctly to the Alembic model.

    JClave said:

    Are you making changes to Diffeomorphic scripts so that the material creation scripts can be applied?

    This won't be necessary. The only missing piece is how to name the Alembic surfaces after the id of the material on that surface. This information is in the DSON.

    JClave said:

    Or are you importing a .duf file via Diffemorphic and using your own custom script to copy over materials?

    Or something else?

    I'm parsing the duf file as well, because Diffeo has access to the unique material IDs it uses to name the materials, but the C++ SDK does not seem to. So I think it'll be easiest to just get them from the DSON as well.

    JClave said:

    I'm having trouble seeing why not simply infer the material id from material script within blender.

    I don't see how the material ID can be inferred. Can you explain what you mean in more detail? I don't rule out my over-looking something.

    JClave said:

    The .duf files may look small but they are gzipped. So if you extract it, they can be 10x the size.

    i.e. a single Victoria 8 with full Samurai outfit is ~9MB in raw DSON file  vs 595KB as gzipped .duf file

    And for large scenes, I can only imagine how big the raw DSON file will be. (100MB? possible)

    I can see DSON parsing within Alembic exporter definitely slowing down the export speed noticeably

    I think you are basing your estimate on python or javascript? JsonCpp parses my 28MB unzipped test file in 1.056 seconds.

    Let me know.

  • JClaveJClave Posts: 64
    edited July 2020
    TheMysteryIsThePoint said:
    I think you are basing your estimate on python or javascript? JsonCpp parses my 28MB unzipped test file in 1.056 seconds.

    Let me know.

    Okay, I've done a quick bench on another duf file. (3 figures and a scene) which translates to 39MB unzipped

    This was done using Rust's serde_json, which is apparently faster than the fastest cpp json parser https://users.rust-lang.org/t/serde-and-serde-json-1-0-0-released/10466/5

    Takes up to 0.3 second to unzip and parse the JSON to structs.

    But this is using Threadripper 3960x.

     

    I still would prefer to avoid parsing DSON within Alembic, because this is doubling the DSON parsing time from end user's perspective (first from Alembic, second from Diffeomorphic/Z-Cycle's material parser)

    So that 0.3 second doubles to 0.6 in the best case. And could increase to 1+ second for even larger scenes.

    For some ppl, that may not be a big deal.

    But for the following use case - click two buttons, one from daz, other from blender, in order to sync Daz scene to Blender and start render manually by user as soon as possible

    That may turn out to be just long enough to add to the annoyance of export&import processing time.

     

    Other alternatives on importing Alembic file and applying Diffeomorphic mats:

    1. In Blender,
      1. import Alembic file
      2. import .duf via Diffeomorphic.
        • Add new code at the end of Diffeomorphic import process which will:
          • Read pre-existing materials in Blender that match Alembic's custom material id naming convention i.e. {object id}#{material name}
          • For each material found, copy(or replace with) the corresponding material created by Diffeomorphic. i.e. If Alembic's material is "Victoria8#Face", replace it with "Face-1" from Diffeomorphic
    2. In Blender,
      1. import .duf via Diffeomorphic.
      2. import Alembic file via following method:
        1. Custom import button that will:
          1. Import alembic file via file browser
          2. Look for materials created by Diffeomorphic.
            1. i.e. If Alembic's material is "Victoria8#Face", find a material under "Victoria8" mesh that contains the regex expression "Face-{number}"
          3. Replace Alembic imported materials with the identified Diffeo materials

    It's up to you at the end, but the above are my recommendations

     

     

    Post edited by JClave on
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    JClave said:
    TheMysteryIsThePoint said:
    I think you are basing your estimate on python or javascript? JsonCpp parses my 28MB unzipped test file in 1.056 seconds.

    Let me know.

    Okay, I've done a quick bench on another duf file. (3 figures and a scene) which translates to 39MB unzipped

    This was done using Rust's serde_json, which is apparently faster than the fastest cpp json parser https://users.rust-lang.org/t/serde-and-serde-json-1-0-0-released/10466/5

    Takes up to 0.3 second to unzip and parse the JSON to structs.

    But this is using Threadripper 3960x.

     

    I still would prefer to avoid parsing DSON within Alembic, because this is doubling the DSON parsing time from end user's perspective (first from Alembic, second from Diffeomorphic/Z-Cycle's material parser)

    So that 0.3 second doubles to 0.6 in the best case. And could increase to 1+ second for even larger scenes.

    For some ppl, that may not be a big deal.

    But for the following use case - click two buttons, one from daz, other from blender, in order to sync Daz scene to Blender and start render manually by user as soon as possible

    That may turn out to be just long enough to add to the annoyance of export&import processing time.

     

    Other alternatives on importing Alembic file and applying Diffeomorphic mats:

    1. In Blender,
      1. import Alembic file
      2. import .duf via Diffeomorphic.
        • Add new code at the end of Diffeomorphic import process which will:
          • Read pre-existing materials in Blender that match Alembic's custom material id naming convention i.e. {object id}#{material name}
          • For each material found, copy(or replace with) the corresponding material created by Diffeomorphic. i.e. If Alembic's material is "Victoria8#Face", replace it with "Face-1" from Diffeomorphic
    2. In Blender,
      1. import .duf via Diffeomorphic.
      2. import Alembic file via following method:
        1. Custom import button that will:
          1. Import alembic file via file browser
          2. Look for materials created by Diffeomorphic.
            1. i.e. If Alembic's material is "Victoria8#Face", find a material under "Victoria8" mesh that contains the regex expression "Face-{number}"
          3. Replace Alembic imported materials with the identified Diffeo materials

    It's up to you at the end, but the above are my recommendations

    And I'm grateful for them. I'm just barely beginning to understand Daz materials.

    It's essentially the script that I have now, that harvests the Diffeo materials and creates normalized names of the form collection.object.material, removing any numbering. This way, a second script that obeys the same normalization rule knows what material to put where, even if Alembic material slots are missing because they were ignored, or in a different order. I just wasn't clear on how/why material IDs get renumbered in order to stay unique and could not convince myself that normalizing the material slots names in that way would never lose information. Is the material ID that Diffeo uses always of the form daz_surface-n? Give me some time to see that this is the case.

    But an advantage of doing the parsing is that if the material slot names on both imports are preceisely equal, there are no additional texturing steps after importing. The parsing is easy enough to at least make it an option.

    Thanks for your collaboration.

     

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    JClave said:

    First, I would like to understand your planned workflow on how Diffeomorphic's material script is applied to Alembic imported objects.

    1. So, if certain assumptions remain valid, the workflow can be:
    2. Export Alembic, which will create a script that will create a normalizer script to rename material slots to object/surface
    3. Import Diffeo into Blender.
    4. Run the normalizer script.
    5. Import the Alembic, which will have already named the material slots to object/surface.
    6. Profit.
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946

    @JClave

    So, parsing the DSON is simple, clear and straightforward. It provides a rock solid mapping of a node's surfaces to the material ID's used by Diffeo. This would enable the Alembic exporter to do all the work, without any scripts 0.861 seconds on a 1950X.

    While I do feel good about that, it also shows that you are also correct; there are no cases where the surface name is not simply the material ID with the numbering removed. I'll try it on a more complex duf and see if I can invalidate the assumption, but it looks good from here.

    If you are concerned about the time, both implementations are easy, so I'll do both.

    We are kicking some serious butt... I don't want to go to work tomorrow :)

    ripper:~ $ time ./json
    ==============================================
    MATERIAL INSTANCES
    ==============================================
            geometry_id: #KaftanLongA surface: Kaftan material_id: Kaftan-1
            geometry_id: #Lashes surface: EyeMoisture material_id: EyeMoisture-3
            geometry_id: #Lashes surface: Eyelashes material_id: Eyelashes-1
            geometry_id: #aprilyshKarissaHairG8F surface: hair1 material_id: hair1-1
            geometry_id: #aprilyshKarissaHairG8F surface: hair2 material_id: hair2-1
            geometry_id: #aprilyshKarissaHairG8F surface: scalp material_id: scalp-1
            geometry_id: #geometry-10 surface: 02___Default material_id: 02___Default-1
            geometry_id: #geometry-10 surface: 08___Default material_id: 08___Default-1
            geometry_id: #geometry-10 surface: 09___Default material_id: 09___Default-1
            geometry_id: #geometry-10 surface: wire_134006006 material_id: wire_134006006-1
            geometry_id: #geometry-10 surface: wire_143224087 material_id: wire_143224087-1
            geometry_id: #geometry-5 surface: Default material_id: Default-1
            geometry_id: #geometry-6 surface: Arms material_id: Arms
            geometry_id: #geometry-6 surface: Cornea material_id: Cornea-1
            geometry_id: #geometry-6 surface: Ears material_id: Ears
            geometry_id: #geometry-6 surface: EyeMoisture material_id: EyeMoisture-2
            geometry_id: #geometry-6 surface: EyeSocket material_id: EyeSocket
            geometry_id: #geometry-6 surface: Face material_id: Face
            geometry_id: #geometry-6 surface: Fingernails material_id: Fingernails
            geometry_id: #geometry-6 surface: Irises material_id: Irises
            geometry_id: #geometry-6 surface: Legs material_id: Legs
            geometry_id: #geometry-6 surface: Lips material_id: Lips
            geometry_id: #geometry-6 surface: Mouth material_id: Mouth
            geometry_id: #geometry-6 surface: Pupils material_id: Pupils
            geometry_id: #geometry-6 surface: Sclera material_id: Sclera
            geometry_id: #geometry-6 surface: Teeth material_id: Teeth
            geometry_id: #geometry-6 surface: Toenails material_id: Toenails
            geometry_id: #geometry-6 surface: Torso material_id: Torso
            geometry_id: #geometry-7 surface: 01___Default material_id: 01___Default-2
            geometry_id: #geometry-7 surface: 07___Default material_id: 07___Default-2
            geometry_id: #geometry-8 surface: 01___Default material_id: 01___Default-3
            geometry_id: #geometry-8 surface: 07___Default material_id: 07___Default-3
            geometry_id: #geometry-9 surface: material1 material_id: material1-1
            geometry_id: #geometry-9 surface: material2 material_id: material2-1
            geometry_id: #geometry-9 surface: material3 material_id: material3-1
            geometry_id: #geometry-9 surface: material4 material_id: material4-1
            geometry_id: #geometry-9 surface: material5 material_id: material5-1
            geometry_id: #geometry-9 surface: material6 material_id: material6-1
    ==============================================
    SCENE NODES
    ==============================================
    node: African Headwear
            geometry id: geometry-9
            geometry URL: #geometry-3
    node: Amira
            geometry id: geometry-6
            geometry URL: /data/DAZ%203D/Genesis%208/Female/Genesis8Female.dsf#geometry
    node: Earring Left
            geometry id: geometry-7
            geometry URL: #geometry-1
    node: Earring Right
            geometry id: geometry-8
            geometry URL: #geometry-2
    node: Genesis 8 Female Eyelashes
            geometry id: Lashes
            geometry URL: /data/DAZ%203D/Genesis%208/Female%20Eyelashes/Genesis8FemaleEyelashes.dsf#Lashes
    node: Head Jewelry
            geometry id: geometry-10
            geometry URL: #geometry-4
    node: KaftanLong
            geometry id: KaftanLongA
            geometry URL: /data/Nikisatez/G8FKaftans/dForce%20Kaftan%20Long/KaftanLongA_20958.dsf#KaftanLongA-1
    node: Karissa Hair Genesis 8 Female
            geometry id: aprilyshKarissaHairG8F
            geometry URL: /data/AprilYSH/KarissaGenesis/KarissaHairG8F/aprilyshKarissaHairG8F_174239.dsf#aprilyshKarissaHairG8F
    node: Plane
            geometry id: geometry-5
            geometry URL: #geometry

    real    0m0.861s
    user    0m0.723s
    sys     0m0.136s

  • PadonePadone Posts: 3,688
    edited July 2020
    TheMysteryIsThePoint said:

    @Padone Does the import script not use the material id as the material's name, and hence the material slot's name?

    I'm not sure since this is specific to the hd exporter. I mean the standard exporter doesn't export material names. I guess this is useful to Thomas to link the hd materials.

    As for the material names for the alembic file, I have a different opinion and I don't like the "normalizer" script idea. I mean if you get the ids from the duf file then it's already done as you reported yourself, and the procedure would be simply:

    1. export alembic

    2. import diffeo

    3. import alembic and the materials are automatically applied since they share the ids

    I don't see how gaining a couple of seconds to avoid parsing the duf file can benefit the user in any way since then we'd have to launch an extra script so I fail to understand the point by @JClave. But that of course is very minor everything will do as far as it works.

     

    edit. Added a reference to this discussion at diffeomorphic just in case anyone could be interested.

    https://bitbucket.org/Diffeomorphic/import_daz/issues/53/

    Post edited by Padone on
  • JClaveJClave Posts: 64
    edited July 2020
    TheMysteryIsThePoint said:

    @JClave

    So, parsing the DSON is simple, clear and straightforward. It provides a rock solid mapping of a node's surfaces to the material ID's used by Diffeo. This would enable the Alembic exporter to do all the work, without any scripts 0.861 seconds on a 1950X.

    While I do feel good about that, it also shows that you are also correct; there are no cases where the surface name is not simply the material ID with the numbering removed. I'll try it on a more complex duf and see if I can invalidate the assumption, but it looks good from here.

    If you are concerned about the time, both implementations are easy, so I'll do both.

    We are kicking some serious butt... I don't want to go to work tomorrow :)

    If you do implement both approaches we discussed, that would be fantastic. :)

    You do raise a good point about whether material id naming is always formatted like {material name}-{number}

    So far, the namings inspected in sample files seem to behave this way. But more research may be needed to eliminate all unknowns with this material inferring approach. (I can think of a possible approach but it's getting to be a bit too much effort to explain. Since I'm probably the only one interested with this approach, I will save explaination for later hah)

     

    @Padone

    I think a split second load time increase may be negligible for Blender users who want to do everything in Blender (posing, material tweaking, etc..)

    Because they only have to import the same scene once.

    But there is also a use case for users who want to do posing and material tweaking in Daz instead. And use Blender as simply an render engine.

    (I'm working on Iray Uber Node in Blender as we speak, and I can already tell that people will much prefer to modify parameters for this node in Daz instead of Blender)

    For those users, they may want to tweak something in Daz, then import to Blender multiple times to iteratively work on their scene.

    I believe the Alembic exporter will enable this use case with import speed that is much more tolerable than Diffeomorphic.

    Post edited by JClave on
  • marblemarble Posts: 7,500
    JClave said:
    TheMysteryIsThePoint said:

     

    For those users, they may want to tweak something in Daz, then import to Blender multiple times to iteratively work on their scene.

    I believe the Alembic exporter will enable this use case with import speed that is much more tolerable than Diffeomorphic.

    If I understand the conversation correctly, I believe that I may be one of those users you speak of.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    JClave said:
    TheMysteryIsThePoint said:

    @JClave

    So, parsing the DSON is simple, clear and straightforward. It provides a rock solid mapping of a node's surfaces to the material ID's used by Diffeo. This would enable the Alembic exporter to do all the work, without any scripts 0.861 seconds on a 1950X.

    While I do feel good about that, it also shows that you are also correct; there are no cases where the surface name is not simply the material ID with the numbering removed. I'll try it on a more complex duf and see if I can invalidate the assumption, but it looks good from here.

    If you are concerned about the time, both implementations are easy, so I'll do both.

    We are kicking some serious butt... I don't want to go to work tomorrow :)

    If you do implement both approaches we discussed, that would be fantastic. :)

    You do raise a good point about whether material id naming is always formatted like {material name}-{number}

    So far, the namings inspected in sample files seem to behave this way. But more research may be needed to eliminate all unknowns with this material inferring approach. (I can think of a possible approach but it's getting to be a bit too much effort to explain. Since I'm probably the only one interested with this approach, I will save explaination for later hah)

     

    @Padone

    I think a split second load time increase may be negligible for Blender users who want to do everything in Blender (posing, material tweaking, etc..)

    Because they only have to import the same scene once.

    But there is also a use case for users who want to do posing and material tweaking in Daz instead. And use Blender as simply an render engine.

    (I'm working on Iray Uber Node in Blender as we speak, and I can already tell that people will much prefer to modify parameters for this node in Daz instead of Blender)

    For those users, they may want to tweak something in Daz, then import to Blender multiple times to iteratively work on their scene.

    I believe the Alembic exporter will enable this use case with import speed that is much more tolerable than Diffeomorphic.

    No, not at all, I have a vested interest in amximizing utility for everyone.

    But note that the parsing would only have to be done once, and while testing I also began to appreciate the need for a quicker method, and that is what I envisioned for the not-yet-implemented "Snapshot" button.

    And what I really want to do is do away with file formats altogether and talk directly to Blender over a socket or, better yet, shared memory. Push a button and your model appears in Blender. Serializing everything for sockets is oh so 2000s, and Blender's version of Python doesn't support shared memory yet, but since you're rolling a custom build anyway, maybe when we reach a stable point, we can talk about that.

     

  • TheKDTheKD Posts: 2,691

    All this blender progress is getting intense lol.

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946

    I can happily report that the first of three techniques for re-applying textures in Blender seems to work, and man, it felt good to see the model appear perfectly without having to do anything at all.

    There is now an option two use one of three possible methods for naming the material slots: Diffeo mode, DTB mode, and Guess mode.

    • Diffeo mode works, and sure enough if you import a character with Diffeo first, and then import the Alembic, all the materials are applied because the material slot names now match the material IDs that Diffeo uses, and since it reads them right out of the DSON, it will always work.
    • DTB mode is the original behavior, using the surface name as the material slot name, to match what DTB appears to do.
    • Guess mode is what @J Cade wanted, in order to not bog down the process of tweaking materials, and this will be the default for the "Express" button. I do agree that it would have slowed things down; I run Daz Studio on a laptop and it took much longer to parse. You should never benchmark code on a TR.

    I'm going to test a little more and file down some rough edges with the GUI, then I'll publish this version an continue working on the other modes.

  • WendyLuvsCatzWendyLuvsCatz Posts: 38,204

    good to know, I will find your exporter more useful for my animated renders than those other two options 

    the DTB option uses even more resources and freezes too but the materials applying to yours is definitely a help

    I do need to do shorther animations though, my greed was the biggest issue as the abc files obviously end up massive 

    my use for Blender is largely as a render option anyway, posing there was never important so alembic is the best

  • JClaveJClave Posts: 64
    edited July 2020

    Thanks again for your hard work.

    I'm looking forward to your latest exporter so I can finish my material parser's id handling logic.

    Also appreciate your willingness to cater for minimal latency with 'Express button'

    Good point about benchmarking as well.

    Post edited by JClave on
  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    JClave said:

    Thanks again for your hard work.

    I'm looking forward to your latest exporter so I can finish my material parser's id handling logic.

    Also appreciate your willingness to cater for minimal latency with 'Express button'

    Good point about benchmarking as well.

    No problem. It's just better when tools work together.

  • marblemarble Posts: 7,500

    Maybe this should be moved to the Blender forum now?

  • TheMysteryIsThePointTheMysteryIsThePoint Posts: 2,946
    marble said:

    Maybe this should be moved to the Blender forum now?

    It was, but someone moved it out.

  • AmbrozewiczAmbrozewicz Posts: 7

    Hi guys, I just found this thread and it's amazing how much work is being put into the plugin.

    I know this is a long shot but are there any plans for porting this to 3ds Max? Because the same problems exist there as well (with the DAZ store plugin version).

Sign In or Register to comment.