Subpart texture file path

[Orion Pobursky]

There are no subpart textures on the PT right now (or in the official library) but I'd like to figure this out before it becomes an issue. I think the way the PT is handling subpart textures is wrong.

The UI on the PT submit page lists "\parts\s\textures" as the subpart texture file path

However the !TEXMAP spec states "a search for the specified texture file will first be attempted after adding a "textures\" prefix to the filename". By my reading this means subpart textures files should be in "parts\textures\s".

[Chris Dee]

There are no subpart textures on the PT right now (or in the official library) but I'd like to figure this out before it becomes an issue. I think the way the PT is handling subpart textures is wrong.

The UI on the PT submit page lists "\parts\s\textures" as the subpart texture file path

However the !TEXMAP spec states "a search for the specified texture file will first be attempted after adding a "textures\" prefix to the filename". By my reading this means subpart textures files should be in "parts\textures\s".

Really? I am sure I based the Parts Tracker implementation on an example, but to my mind adding a prefix to the filename (not the filepath), gives:

• A texmap for parts/1234.dat in parts/textures/1234.png.
  
• A texmap for parts/s/1234s01.dat in parts/s/textures/1234s01.png.
  
• A texmap for p/logo.dat in p/textures/logo.png.
  

I think it is more logical that the texture .png file is in a subfolder of its parent .dat file. But if what you describe is how tools have interpreted the spec then I'll change the Parts Tracker.

[Lasse Deleuran]

This is interesting as I initially understood the structure to be:


- parts
 - parts/s
- p
 - p/48
 - p/8
- textures



And all textures would be lumped into the one separate folder. 

It would be nice with an example file structure in the spec so that we all have the same understanding.

[Travis Cobbs]

There are no subpart textures on the PT right now (or in the official library) but I'd like to figure this out before it becomes an issue. I think the way the PT is handling subpart textures is wrong.

The UI on the PT submit page lists "\parts\s\textures" as the subpart texture file path

However the !TEXMAP spec states "a search for the specified texture file will first be attempted after adding a "textures\" prefix to the filename". By my reading this means subpart textures files should be in "parts\textures\s".

To be honest, I'm not entirely sure what the original intent was. Looking at my actual code in LDView, I put "textures/" before the "filename" referenced in the part. In this case, the "filename" would be something like "s\whatever.png", so LDView would indeed look in "parts\textures\s\whatever.png".

I'm open for debate on what the proper behavior should be. Also, whatever the decision, we should clarify the !TEXMAP spec.

[Roland Melkert]

There are no subpart textures on the PT right now (or in the official library) but I'd like to figure this out before it becomes an issue. I think the way the PT is handling subpart textures is wrong.

The UI on the PT submit page lists "\parts\s\textures" as the subpart texture file path

However the !TEXMAP spec states "a search for the specified texture file will first be attempted after adding a "textures\" prefix to the filename". By my reading this means subpart textures files should be in "parts\textures\s".

I always considered the type 1 string a reference not a filename.

So "1 ....... s\123.dat" translates into

Reference s\123.dat
fileName: 123.dat
path: d:\ldraw\parts\s\123.dat

then it will search for s\123.dat in

1 the mpd if any
2 same folder as the containing file
3 library parts
4 library p

Once 123.dat has been found a texture used in that file will be searched for in

1 the mpd if any
2 same folder (as the .dat) \textures
3 library parts\textures
4 library p\textures
5 same folder
6 library parts
7 library p

This means if a texture meta references s\123.png it will look for

<mpd>s\123.png
<folder>\textures\s\123.png
d:\ldraw\parts\textures\s\123.png
d:\ldraw\p\textures\s\123.png
<folder>\s\123.png
d:\ldraw\parts\s\123.png
d:\ldraw\p\s\123.png

So in short, it should be a prefix to the reference used in the texture meta.

It might be good practice to just always use 123.png without 's' in the meta's.

side note:  this makes me wonder if <mpd>\textures\s\123.png should be checked too.

[Orion Pobursky]

There are no subpart textures on the PT right now (or in the official library) but I'd like to figure this out before it becomes an issue. I think the way the PT is handling subpart textures is wrong.

The UI on the PT submit page lists "\parts\s\textures" as the subpart texture file path

However the !TEXMAP spec states "a search for the specified texture file will first be attempted after adding a "textures\" prefix to the filename". By my reading this means subpart textures files should be in "parts\textures\s".

I'm writing the proposed change to the spec. Is the consensus that texture should be appended to the name as specified in the Name: META (e.g. s/123.dat would search parts/textures/s/123.png)?

[Philippe Hurbain]

I'm writing the proposed change to the spec. Is the consensus that texture should be appended to the name as specified in the Name: META (e.g. s/123.dat would search parts/textures/s/123.dat)?

I always thought it was supposed to work that way...

[Magnus Forsberg]

I'm writing the proposed change to the spec. Is the consensus that texture should be appended to the name as specified in the Name: META (e.g. s/123.dat would search parts/textures/s/123.dat)?

Hm...
Don't you mean " s/123.dat would search parts/textures/s/123.png "?

[Orion Pobursky]

Hm...
Don't you mean " s/123.dat would search parts/textures/s/123.png "?

Yes. Copy and paste. Grr.

[Travis Cobbs]

I'm writing the proposed change to the spec. Is the consensus that texture should be appended to the name as specified in the Name: META (e.g. s/123.dat would search parts/textures/s/123.png)?

Just to be clear here, when s/123.dat references a texture, it needs to do so using s/123.png as the texture name (just like s/123.dat would use s/123a.dat to reference a separate subpart). Given that, then parts/textures/s/123.png would be where the texture file would go.

[Orion Pobursky]

Just to be clear here, when s/123.dat references a texture, it needs to do so using s/123.png as the texture name (just like s/123.dat would use s/123a.dat to reference a separate subpart). Given that, then parts/textures/s/123.png would be where the texture file would go.

Yes except that the png filename will be the one referenced in the !TEXMAP START|NEXT statement.

[Chris Dee]

Hm...
Don't you mean " s/123.dat would search parts/textures/s/123.png "?

The Parts Tracker has been changed to use parts/textures/s/ instead of parts/s/textures.

[Orion Pobursky]

There are no subpart textures on the PT right now (or in the official library) but I'd like to figure this out before it becomes an issue. I think the way the PT is handling subpart textures is wrong.

The UI on the PT submit page lists "\parts\s\textures" as the subpart texture file path

However the !TEXMAP spec states "a search for the specified texture file will first be attempted after adding a "textures\" prefix to the filename". By my reading this means subpart textures files should be in "parts\textures\s".

Revision done. Proposed changes in red.
https://www.ldraw.org/draft-texmap.html

[Travis Cobbs]

Revision done. Proposed changes in red.
https://www.ldraw.org/draft-texmap.html

I find the wording of the FALLBACK update to be confusing. Specifically, "... required if ... not used". In my opinion, the following wording conveys the same meaning in a less confusing manner:

The FALLBACK section is required unless the NEXT command is used or the geomtery2 section is missing.

However, the above actually changes the requirements of the spec, which I don't feel is warranted here. Simply put, the FALLBACK section is never required based on the original spec, and I don't feel we should be changing that. However, I can definitely see how it should be required in official parts if there is no geometry2 section.

So, my suggestion for the TEXMAP spec would be something more like this:

Note: the FALLBACK section is always optional, although it is highly recommended any time there is no geometry2 section.

Then, in the Official parts document, we can add a restriction that upgrades that "highly recommended" to "required".

Note that this means that NEXT can then only be used in official parts if the next line is a type 1 line and not a 0 !: line, while your suggested change would allow NEXT to be used in official parts even if that were not the case.

[Orion Pobursky]

I find the wording of the FALLBACK update to be confusing. Specifically, "... required if ... not used". In my opinion, the following wording conveys the same meaning in a less confusing manner:


However, the above actually changes the requirements of the spec, which I don't feel is warranted here. Simply put, the FALLBACK section is never required based on the original spec, and I don't feel we should be changing that. However, I can definitely see how it should be required in official parts if there is no geometry2 section.

So, my suggestion for the TEXMAP spec would be something more like this:


Then, in the Official parts document, we can add a restriction that upgrades that "highly recommended" to "required".

Note that this means that NEXT can then only be used in official parts if the next line is a type 1 line and not a 0 !: line, while your suggested change would allow NEXT to be used in official parts even if that were not the case.

I agree. I'll make the change.