In MDL file ../ is not recognized as ..\\ is

Gaming and Visualization Technologies Visualization MDL SDK
1

Hi,

When accessing textures in a relative path (which is no subfolder relative to the MDL file itself)
this relative subfolder access …/…/ seems not correctly being recognized on Windows OS in a MDL file.

//ok:  (when file is directly in same folder where the MDL file is): 
uniform texture_2d Texture_2 = texture_2d("texture.bmp"),

// ok if using backslash "\\" and the file is in folder relative to the MDL file:
uniform texture_2d Texture_2 = texture_2d("..\\..\\..\\..\\TESTS\\texture.BMP"),

//fails:   
uniform texture_2d Texture_2 = texture_2d("../../../../TESTS/texture.BMP"),

   // gives error message:  strict relative file path contains too many directory names '..'
   //  and                  Unable to resolve file path '../../../../TESTS/texture.BMP'

…/ should do the same as “…\\” or should it not ?
Is this different behaviour expected ?

However, when running cmd.exe (console window) a command
cd ../../
also perfectly works on Windows, although normally backlashes separate folders.

Thank you.

My System:
MDL SDK 2020.0.1
(OptiX 6.5.0 CUDA 10.1) or (OptiX7.1.0 SDK CUDA 11.0.1)
GTX 1050 2GB
device driver: 451.48
Win10PRO 64bit (version 2004; build 19041.264)
VS2019 v16.7.0 (toolkit v140 of VS2015)

2

Hi,
can you describe your search path setup here? Is texture.bmp in the root of your search path or is ../../../../TESTS a root or even an higher folder?

According to the specification (Sec. 2.2) only / is a valid path separator in MDL. \ is reserved and must not be used. So you might discovered a problem here in the case where it worked using\\ on windows.

The reason it is not working with the forward slashes is related to my question above. You are not allowed to “leave” a search path root using ../. If you go further up than allowed, the file resolution can be ambiguous and therefore will fail. My guess is this happened here.

Thanks

1 Like
3

Hi,

thanks for your answer.

I did not add any search path at all.
Yes, texture.bmp was related to a “higher” parent folder.
I also overlooked the limitation related to the “\” char.
So what I encountered there as “working scenario”
was more or less “undefined behaviour”.

However, the file resolution would be not ambiguous there, as long as only one search path (the default one) is present. But since its not allowed by design I know why it is like it is.

So I now know how to use it. Thank you.

4

Yes, it’s “undefined behavior” and yes, in case of one search path it is not ambiguous but the rules should not depend on the number of search paths to keep them as simple and comprehensible as possible.

Still, thanks for reporting this. I will check if the backslashes are still resolved in the current release.