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

Handle merges where GLTF resources are in different directories #7

Merged
merged 9 commits into from
Feb 6, 2018

Conversation

erikdahlstrom
Copy link
Contributor

No description provided.

@msftclas
Copy link

msftclas commented Jan 11, 2018

CLA assistant check
All committers have signed the CLA.

std::wstring FileSystem::GetRelativePathWithTrailingSeparator(std::wstring from, std::wstring to)
{
wchar_t outPath[MAX_PATH] = L"";
if (PathRelativePathTo(outPath, from.c_str(), FILE_ATTRIBUTE_DIRECTORY, to.c_str(), FILE_ATTRIBUTE_DIRECTORY))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This API will only work on desktop. Can you please use std::filesystem instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, np. I'll take that as a go-ahead to replace the other two shlwapi calls (PathFindFileName, PathRemoveExtension) that were already in the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A closer inspection reveals that msvc doesn't support std::filesystem::relative (c++17), which would be the natural replacement for PathRelativePathTo. I was really hoping to avoid re-implementing that.

@@ -148,8 +148,7 @@
<GenerateDebugInformation>true</GenerateDebugInformation>
</Link>
<Lib>
<AdditionalDependencies>
</AdditionalDependencies>
<AdditionalDependencies>shlwapi.lib</AdditionalDependencies>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove - this doesn't work with UWP

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@@ -30,7 +30,7 @@ namespace Microsoft::glTF::Toolkit
/// </summary>
/// <returns>The primary GLTF Document with the inserted LOD node.</returns>
/// <param name="docs">A vector of glTF documents to merge as LODs. The first element of the vector is assumed to be the primary LOD.</param>
static GLTFDocument MergeDocumentsAsLODs(const std::vector<GLTFDocument>& docs);
static GLTFDocument MergeDocumentsAsLODs(const std::vector<GLTFDocument>& docs, const std::vector<std::wstring>& relativePaths);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have an option without this parameter that assumes everything is in the same directory

@@ -40,7 +40,7 @@ namespace Microsoft::glTF::Toolkit
/// <param name="docs">A vector of glTF documents to merge as LODs. The first element of the vector is assumed to be the primary LOD.</param>
/// <param name="screenCoveragePercentages">A vector with the screen coverage percentages corresponding to each LOD. If the size of this
/// vector is larger than the size of <see name="docs" />, lower coverage values will cause the asset to be invisible.</param>
static GLTFDocument MergeDocumentsAsLODs(const std::vector<GLTFDocument>& docs, const std::vector<double>& screenCoveragePercentages);
static GLTFDocument MergeDocumentsAsLODs(const std::vector<GLTFDocument>& docs, const std::vector<std::wstring>& relativePaths, const std::vector<double>& screenCoveragePercentages);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have an option without this parameter that assumes everything is in the same directory

@@ -375,7 +386,7 @@ GLTFDocument GLTFLODUtils::MergeDocumentsAsLODs(const std::vector<GLTFDocument>&

for (size_t i = 1; i < docs.size(); i++)
{
gltfPrimary = AddGLTFNodeLOD(gltfPrimary, lods, docs[i]);
gltfPrimary = AddGLTFNodeLOD(gltfPrimary, lods, docs[i], relativePaths[i]);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the first element of relativePaths is always ignored. Maybe the input should be only the non-lod0 relative paths?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

true, I'll make it so

Copy link
Contributor

@robertos robertos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for your work on this! :)

@@ -16,6 +16,8 @@
#include <algorithm>
#include <iostream>
#include <set>
#include <codecvt>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I've been using the naïve conversion from wstring to string elsewhere. I don't have a great solution for this - it's unfortunate that the GLTF SDK works with std::string everywhere, while files can have non-ansi chars.
If this conversion is the best, we should put it in a helper function and use it everywhere (probably with a unit test to ensure it does what we want)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given that the GLTF spec states that "JSON must use UTF-8 encoding without BOM." my patch assumes that the std::string entries are UTF-8 encoded. I think that using codecvt way is better than the naïve approach, and agree that unit-testing this would be good.

Not sure about the timeframe for getting a c++ standard replacement for codecvt, another option would be to include a third-party lib e.g libiconv.

@@ -24,6 +24,7 @@
#include <windows.h>
#include <wincodec.h>
#include <pathcch.h>
#include <shlwapi.h>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider it gone.

@@ -15,6 +15,7 @@

#include "CommandLine.h"
#include "FileSystem.h"
#include <filesystem>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already included in FileSystem.h? Otherwise this should be there?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, will move it there.

@robertos robertos merged commit 9cc0960 into microsoft:master Feb 6, 2018
@erikdahlstrom erikdahlstrom deleted the relative_path_hack branch February 22, 2018 13:56
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

Successfully merging this pull request may close these issues.

None yet

3 participants