Relative paths not working on Windows about vulkan-gltf-pbr HOT 2 CLOSED

Had the same problem using Visual Studio from /build folder. I had to replace ./../data with ../../data in four places because the working folder cmake creates in visual studio projects is relative to the vcxproj, which is under build/src. So to get to data you need to drop down two levels of folders, not one.

In general, relative paths should work both within Visual Studio debugger and if you click on the .bin directly. So the working folder should be the solution folder, which should be assumed to be under the root in /build probably. The current build dir dumps the .exe three levels deep at /build/bin/debug (or release), but the vcproj is at build/src, two levels deep, so there is no common path that works with or without visual studio debugger attached OOTB.

Lots of other samples do this relative path searching dynamically at runtime, which is a bit clunky and hacky TBH.

I'm not sure what command line change is to make solution dir the default working dir in cmake, but it would be worth adding it to the README..

The one improvement I do think should be made to this repo, is to remove the duplicated / hardcoded "./../data" prefix and make it a define so you only need to change it in one place, and any time you try to read an asset it concatenates the string. Could be done at runtime (or at compile time with some macros).

Anyway, the main problem in this codebase for me is that I had to modify several files and places to fix what should've been a single character missing (.. instead of .). It's best not to hardcode paths anyway, or if you do hardcode something, hardcode it once and only once, period. Never have magic numbers sprinkled around in several places either, that's what defines or constexpressions are for.

from vulkan-gltf-pbr.

Same for building on macOS or Linux using CMake where the build directory is a child of the main project directory.

from vulkan-gltf-pbr.