Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected png renders #3

Open
melMass opened this issue Mar 29, 2021 · 8 comments
Open

Unexpected png renders #3

melMass opened this issue Mar 29, 2021 · 8 comments

Comments

@melMass
Copy link

melMass commented Mar 29, 2021

Hi @edolstra,

Thanks for this great utility, I'm trying to debug it now but everything seems to work except the render to png (Applied morphs obj look like they should):

image

Do you have a clue?

I'm on macOS with:

  • OpenSubdiv 3.4.4
  • libPNG 1.4.12
  • ZLib 1.2.11
  • Boost 1.75.0
  • GLEW 2.2.0
@melMass
Copy link
Author

melMass commented Mar 29, 2021

And this is the working version (same inputs) with morphs-to-obj

image

@Xin-888
Copy link

Xin-888 commented Apr 1, 2021

That's very likely a failure to zero-initialize glm vectors (see #2). You can either hard code the zero-initialization, or set the flag GLM_FORCE_CTOR_INIT.

As a side note, I have been expanding this program here (for windows but compiled with MinGW so it only requires tiny changes for other platforms): https://bitbucket.org/Diffeomorphic/import_daz/issues/357/it-is-possible-to-read-dhdm-files-directly . It's still not well organized since I was trying different things, but feel free to take stuff from there too, like EXR support, support for base meshes with triangles (like genesis 2 ones), auto-scaling option, interfacing with Blender directly, etc.

@melMass
Copy link
Author

melMass commented Apr 2, 2021

That's very likely a failure to zero-initialize glm vectors (see #2). You can either hard code the zero-initialization, or set the flag GLM_FORCE_CTOR_INIT.

As a side note, I have been expanding this program here (for windows but compiled with MinGW so it only requires tiny changes for other platforms): https://bitbucket.org/Diffeomorphic/import_daz/issues/357/it-is-possible-to-read-dhdm-files-directly . It's still not well organized since I was trying different things, but feel free to take stuff from there too, like EXR support, support for base meshes with triangles (like genesis 2 ones), auto-scaling option, interfacing with Blender directly, etc.

Thanks a lot, I'm trying those right now!
I'll definitely check your fork! I see you are adapting it to blender, I'm trying to adapt it to Unity (EXR is on my todo list so that's interesting), I'm reworking the official DAZ addon, and until recently tried to keep it PRable (https://github.com/melMass/DazToUnity), I'm now completely diverging from it as the codebase is full of dead functions, half done stuff etc etc... The idea would be to integrate dhdm in the process, automating most of it!

@melMass
Copy link
Author

melMass commented Apr 2, 2021

set the flag GLM_FORCE_CTOR_INIT.

Thanks !! that was it.
In CMake:

set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DGLM_FORCE_CTOR_INIT")

image

@melMass
Copy link
Author

melMass commented Apr 2, 2021

@Xin-888 I'm trying to implement your modifications, can you explain the code required to generate the meshdiff in your version?

Here is what I've tried but it returns black exrs:

        ...
        auto baseMesh = Mesh::fromDSF(baseMeshPath, uvMapPath);
        std::string baseObj = "displacement_base.obj";
        baseMesh.writeObj(baseObj); // I'm using a second function with the same name to save to file
        auto finalMesh = baseMesh;
        auto level = finalMesh.applyMorphs(morphPaths);

        baseMesh.subdivide(level, {}, -1);

        fmt::print(fg(fmt::color::green_yellow), "Triangulating...");
    
        baseMesh.triangulate();
        finalMesh.triangulate();
        
        const char* baseName = "myBaseName";
        MeshDiff::renderContextInit('X', 4096); // use 'P' for png
        MeshDiff diff('T', baseMesh, finalMesh ,baseName,true ,1.0,0.5,1.0);

        const std::set<unsigned short> selectedTiles {1001,1002,1003,1004,1005,1006};
        std::vector<std::future<void>> asyncs;

        diff.writeToImage("out",selectedTiles,asyncs);
        MeshDiff::renderContextFinish();
        std::cout << "Async Waiting...\n";
        for (auto & async : asyncs)
            async.get();

Small note:
const std::string outFilePrefix( fmt::format("{}\\{}", outputDirpath, texture_prefix));
Should be (to be cross platform):
const std::string outFilePrefix( fmt::format("{}/{}", outputDirpath, texture_prefix) );

@melMass
Copy link
Author

melMass commented Apr 2, 2021

Yay !! Dumb me, they are 32bits.
but aren't they a bit too crunched?
image

I have to double check, but it's skipping tiles:
image

@Xin-888
Copy link

Xin-888 commented Apr 2, 2021

Tiles are still being filtered out if the maximum displacement in that tile is small (just like the version here does). The tile set filtering added later is done after that to exclude tiles which have non-negligible displacement but which you don't care about.

Also, thanks for that slashes thing, I will change that.

@melMass
Copy link
Author

melMass commented Apr 2, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants