TEXMAP searchorder

[Roland Melkert]

I'm a bit unclear on the texmap search order, working with the 10054p01 helmet Philo made a long time ago I noticed it failed loading as it couldn't find the png's.

I fixed the issue by coping the png's and adding it to LDCad's buglist.

I'm now addressing the bug, but I'm wondering if it's a bug at all, it concerns this file structure:

Code:

Helmet\10054p01m.dat
Helmet\s\10054s05m.dat
Helmet\textures\10054s05a.png

10054p01m.dat references "s\10054s05m.dat" which references "10054s05a.png"

LDCad currently looks for the png in these places

Code:

Helmet\s\textures\10054s05a.png
Helmet\s\10054s05a.png
<ldraw>\parts\textures\10054s05a.png
<ldraw>\parts\10054s05a.png
<ldraw>\p\textures\10054s05a.png
<ldraw>\p\10054s05a.png

The spec doesn't mention it should also look in the parent's textures folder, LDView seems to do so though.

I think the png's, in this case, should be located in "Helmet\s\textures\" instead of "Helmet\textures\"

[Philippe Hurbain]

I think the idea is to have all texture files in the same folder. The problem is not very different to the problem of a subpart referencing another subpart, both are placed in the same folder, but both expect to find subpart in relative s\ folder, meaning that the second level should be placed in parts\s\s folder!

[Travis Cobbs]

The spec doesn't mention it should also look in the parent's textures folder, LDView seems to do so though.

I don't think LDView will successfully load the texture if the part is used in a model, unless all the files go into a parts directory (either the official one or the unofficial one). LDView prepends textures/ onto the texture filename, and then uses its standard dat-finding path algorithm. One of the entries in LDView's search path is the main model's directory, so if you load this part into LDView, it should find the textures based on that. But if you use the part in an LDraw file located in a different directory, it shouldn't find the textures. (In that case, the LDraw file would need a path to find the .dat, which wouldn't be normal.)

If the part itself is put into either <LDraw>/Parts or <LDraw>/Unofficial/Parts, part-finding paths searches should work (and it looks like that would already work in LDCad). So I don't think there is anything wrong with your current search path, nor is there anything inherently wrong with Philo's part, since it's a fair assumption that all of its files will be placed in either an official or unofficial parts directory (or perhaps the directory containing the model it is part of).

The reason LDView looks in the main model's directory for files is because in the past before MPD became common, many LDraw models would make use of sub-models, but these sub-models would be separate files in the same directory as the main model. Technically LDCad should support this, but I'm not real sure it's all that important, since I doubt anybody uses that functionality these days.

[Roland Melkert]

The spec doesn't mention it should also look in the parent's textures folder, LDView seems to do so though.

I don't think LDView will successfully load the texture if the part is used in a model, unless all the files go into a parts directory (either the official one or the unofficial one). LDView prepends textures/ onto the texture filename, and then uses its standard dat-finding path algorithm. One of the entries in LDView's search path is the main model's directory, so if you load this part into LDView, it should find the textures based on that. But if you use the part in an LDraw file located in a different directory, it shouldn't find the textures. (In that case, the LDraw file would need a path to find the .dat, which wouldn't be normal.)

If the part itself is put into either <LDraw>/Parts or <LDraw>/Unofficial/Parts, part-finding paths searches should work (and it looks like that would already work in LDCad). So I don't think there is anything wrong with your current search path, nor is there anything inherently wrong with Philo's part, since it's a fair assumption that all of its files will be placed in either an official or unofficial parts directory (or perhaps the directory containing the model it is part of).

The reason LDView looks in the main model's directory for files is because in the past before MPD became common, many LDraw models would make use of sub-models, but these sub-models would be separate files in the same directory as the main model. Technically LDCad should support this, but I'm not real sure it's all that important, since I doubt anybody uses that functionality these days.

Thanks for the background info Travis.

I indeed don't include the main models folder, I might add that but I'm not sure if that's a trivial change as the loading mechanics are multi threaded in LDCad.