1. Thomas Larsson Avatar Thomas Larsson
  2. Diffeomorphic
  3. import_daz
  4. Issues

Xin HD Addon integration

Issue #1369 duplicate
Maneki created an issue

Since Xin doesn’t seem to be around anymore and the addon doesn’t seem to work with Blender 3.4+ I’d like to request a integration of it into the daz importer to keep it up and running for newer versions. I assume the code is open source which means it should be technically possible?
I work a lot with HD morphs and this addon is the only option to get a bunch of HD morphs at once on a character easily currently. This could maybe change when they allow subdivision stages for multires shapekeys which would be similar to how subD and morphs are in Daz Studio but that seems to be far far into the future.

I guess this request goes directly to Thomas @Thomas Larsson ?

It’d be really appreciated!

Comments (23)

  1. Alessandro Padovani

    As I understand it Thomas can’t code c++, plus the dll may not be easy to compile. One way is to use the Xin addon in blender 3.3.2 then load the scene in blender 3.4.1. Since HD requires a lot of work anyway this additional step is minor.

    But of course we wait for the reply by Thomas, or Xin.

  2. Thomas Larsson repo owner

    I did have a look at Xin’s addon, but I don’t think I can help. The error should not be in the C++ code itself, since the compiled dll still works with previous versions of Blender. Unfortunately, the python code that interfaces to the dll contains lots of stuff that I have never worked with and don’t understand.

    Perhaps somebody else can help. Somebody who knows how to write dll wrappers in python.

  3. Mike Fischer

    Here are my initial observations since @Alessandro Padovani asked me to look into the xin addon, after building the blender versions to use the volumetric shader without skin map bleeding (Issue #1168).

    Observations / Possible fix

    When trying to compile the dll with the recent blender 3.4.1 header files, an error gets thrown when trying to access a specific member from a constructor within the header files.
    More precisely the constructor "MPoly" within the blender header "DNA_meshdata_types.h" has no member named "mat_nr" anymore.
    It was renamed to "mat_nr_legacy" as it’s an deprecated material index now. However it may still be usable (see comment above member declaration):

    typedef struct MPoly {
  /** Offset into loop array and number of loops in the face. */
  int loopstart;
  /** Keep signed since we need to subtract when getting the previous loop. */
  int totloop;
  /** Deprecated material index. Now stored in the "material_index" attribute, but kept for IO. */
  short mat_nr_legacy;
  char flag, _pad;
} MPoly;

    To resolve this issue, the called member “mat_nr“ in the DLL source file "blender_mesh.cc" from Xin must be renamed to "mat_nr_legacy":
    Line 55:

    face.matId = load_materials ? mpoly->mat_nr_legacy : 0;

    Line 196:

    mpoly->mat_nr_legacy = uses_materials ? face.matId : 0;

    This might be the solution to make this plugin compatible with the latest Blender releases.

    Difficulties

    Till now I wasn’t able to actually build the dll due to my confusion over the libraries that I have to implement into this project.
    I'm coming from C# and Visual Studio where you can just reference pre-built dlls or load packages from Nuget.

    Within the Code::Blocks IDE, the errors I get are all formatted like this: [undefined reference to '__...']

    All the necessarry header files that are included in the code are also included in my project. I can even open the included files from the code, so it should be because of the included libraries.

    In C++, the actual order in which these libraries are linked is very important so that may be the part that I got wrong.
    I use vcpkg to get and build the libraries and headers.

    Maybe someone, who has experience with building dlls can help me out?

  5. bouich jules

    Actually thomas why not just include ALL xin HD plugin into diffeo?

    like create a new category in advanced setup for “ HD MESH” then copy/paste all functions of xin plugin.. like this we will have a long term support and it’s for sure a superuseful features,

    ‌

  6. Mike Fischer

    @bouich Unfortunately, that won’t work. The DLL is wrapped and used by the Python code, but it must first be compiled. Since Python is an interpreter, it cannot directly use the DLL code written in C++. Instead, the DLL logic relies on the Blender source code, which is compiled when Blender is built. Python has no way to directly access Blender's source code. Also, many other C++ libraries that python can’t use are needed to make the DLL and its functions work.

    @Thomas Larsson please correct me if I am wrong on any point.

  7. Thomas Larsson repo owner

    I haven’t used C++ for almost a decade and never in combination with Blender or dlls, so I don’t have anything to say. In my comment above I assumed that something had changed in the wrapper code but that the binary dll from Blender 3.2 should still work, but that seems to be wrong. The dll must probably be compiled with new header files that match the python version.

  9. Thomas Larsson repo owner

    One could make a standalone program that is invoked from python with os.system. I used that technique to resize textures, before I realized that the Blender API already contains such a function. The problem is how to get the result into Blender. The standalone program could write the result to an ascii file that the plugin loads, but that will probably consume a lot of space and time. Or one could do everything in python, but that leads to performance issues too.

  10. Mike Fischer

    I would have suggested building a version of Blender where the commit to the material indexes is reverted.
    But that would introduce the risk that addons and future features of blender that access the material index would no longer work as expected.

    Also, unlike Brecht's volume "fix", this commit actually seems to makes sense.
    See more in commit: https://github.com/blender/blender/commit/f1c0249f34c4171ec311b5b9882e36fed5889259

    Regarding the standalone versions, they are a good idea, but for that you need to know exactly what the program is supposed to do and how it is supposed to do it.
    Also, as Thomas mentioned, there are some disadvantages to calling a program from Python and then using its results when handling big data.

  11. Alessandro Padovani

    @Mike Fischer , did you look at the link I provided above ? As you noted the error should arise from the order of the linked libraries and there’s some advice from others who solved it. The readme.txt by Xin included in the distribution also states the order for the libraries, if this is the information you miss. Let us know if this helps.

    Modified and expanded from: https://github.com/edolstra/dhdm

    Compiled with MinGW on Code::Blocks 20.03 in windows x64, with C++17 support.

    The following compiled libraries are needed, in order:

    glew32
    http://glew.sourceforge.net

    glfw3
    https://www.glfw.org

    fmt
    https://github.com/fmtlib/fmt

    libpng
    http://www.libpng.org/pub/png/libpng.html

    osdCPU
    https://graphics.pixar.com/opensubdiv/docs/cmake_build.html

    The iostreams part of boost:
    https://www.boost.org/doc/libs/1_75_0/more/getting_started/index.html

    The following libraries included with Code::Blocks MinGW compiler:
    glu32
    opengl32
    gdi32
    user32
    kernel32

    And the following headers only libraries:

    https://github.com/g-truc/glm
    https://github.com/nlohmann/json
    https://github.com/syoyo/tinyexr
    Some Blender 3.2 headers (see "./blender_mesh.cc")

    ‌

  12. Rincewind

    @Thomas Larson
    I thought on that the standalone produces the displacement maps and writes them on the disk and just returns the pathes of created maps to Blender. I don’t think that is very “heavy”.

    But the Blender addon has to export into a temporary the mesh to bake for the standalone app. I think this could be pretty heavy (sub3 or 4 meshes” are pretty happy).

    But anyways, I think is would be the best solution, to keep the addon stable.

    @{6345d753cba49e290971515a}
    At least I will not install a custom Blender build just for baking VDM ;)
    A custom Blender build would mean:

    • I have to wait for with every Blender release for a new custom build
    • Custom build specific bugs may occur
    • Custom build specific incompbilites to other add-ons might appear

    For similar reason I also refuse e-cylces or k-cycles ;)

    ‌

    ‌

  13. Alessandro Padovani

    Rince, the purpose is not to use the custom build to bake the VDM, you could use 3.3 for that just the same. Of course the build by Mike needs to be updated with blender, but it’s the only way to get the new blender features AND a working volume to fix #1168.

  14. Mike Fischer

    @Alessandro Padovani Thank you for the links. Unfortunately, I already read through them until my eyes bled before you posted them.
    In code::blocks you can organize the libraries in the linker settings, but that doesn't seem to have any effect:

    ‌

    Having given up on Code::Blocks, I switched to the more familiar Visual Studio and used vkpkg, a package builder that can load, build, and register all libraries and includes for C++ projects to use them with #include without further ado. Linking would then be handled automatically!
    I tested this and it seemed to work as expected. But unfortunately there seem to be actual syntax errors within the source code if we trust the debugger:

    ‌

    If I'm honest, I don't want to fiddle with the source code too much, so I need to find another solution.
    So far though, I have only used vkpkg to load and build the libraries. Maybe there is some corrupted or older library version I use that causes these errors in VS and CB.
    So an option would be to create them manually but I’m slowly running out of options…

  15. Alessandro Padovani

    Ok thank you for the news, unfortunately I’m running out of ideas too. I’ll let you know if I find something.

    p.s. Did you check if the dll is 32 or 64 bits ? I mean may be you have to link the 32 bit versions ?

  16. Mike Fischer

    yes, I already checked the DLL with dependencywalker and it is 64 bit:

    Nevertheless, just to be sure, I linked the 32-bit libraries and includes in code::blocks while also using the 32 bit compiler, but unfortunately that didn't do the trick.

    I have not yet tried to manually build and configure the libraries and header files, as this is a rather tedious and complex task.
    First, I will try to configure and use Visual Studio Code with the MinGW compiler, hoping that I can link the libraries correctly and also use the MinGW compiler that Xin used…

  17. Alessandro Padovani

    You’re doing a tremendous effort here, so much for c++ being a portable language, go figure if it wasn’t. Please let us now of your progress. If only Xin would be reachable but even the link doesn’t seem to work.

    @Thomas Larsson I may recall wrong but it seems to me that Xin may have contacted you by email for questions about “politically correct“ names ? If so you may have a go to contact him ?

  18. Maneki reporter

    Yes, it’s really appreciated. I wish I could help here but I barely have a week of coding expierence and only java. 😅

  19. Alessandro Padovani

    I was a professional programmer for some years but a very long time ago. I wouldn’t really dare to dive in now.

  20. Thomas Larsson repo owner

    Alessandro, I haven’t seen any email from Xin, but I don’t monitor the hotmail address that connected to my Bitbucket account. That mailbox is filled up, primarily with all the posts from this tracker. Though I searched for Xin in the mailbox and didn’t find anything since his last post here last July.

  24. Log in to comment
Assignee
–
Type
proposal
Priority
major
Status
duplicate
Votes
0
Watchers
6
Jira: the preferred issue tracker for Bitbucket. Join the team!