TEXMAP addition to Official Library Spec

[Orion Pobursky]

I proposed the following addition to the Official Library Spec to go with the proposed rev the !TEXMAP meta:

Under META Commands add:

!TEXMAP Meta
The !TEXMAP NEXT command or geometry2 lines (as outlined in the Texture Mapping (!TEXMAP) Language Extension) will not be used.

Sufficient !TEXMAP FALLBACK geometry3 lines must be included such that the part renders correctly in non-!TEXMAP supporting programs. It is highly encouraged that the included fallback geometry reflect the pattern created by the !TEXMAP, even if it is reduced in resolution or colors, but this is not required.

[Travis Cobbs]

I proposed the following addition to the Official Library Spec to go with the proposed rev the !TEXMAP meta:

Under META Commands add:

!TEXMAP Meta
The !TEXMAP NEXT command or geometry2 lines (as outlined in the Texture Mapping (!TEXMAP) Language Extension) will not be used.

Sufficient !TEXMAP FALLBACK geometry3 lines must be included such that the part renders correctly in non-!TEXMAP supporting programs. It is highly encouraged that the included fallback geometry reflect the pattern created by the !TEXMAP, even if it is reduced in resolution or colors, but this is not required.

The two new paragraphs are basically contradictory. If "real" fallback geometry is only "highly encouraged", then it's not appropriate to forbid geometry2 lines (and the NEXT command). Since the second paragraph states that it is acceptable (although discouraged) to submit a part that shows blank geometry where the texture is, the best way to do that is to omit the geometry1 and geometry3 sections entirely. It would not be acceptable to only have a geometry1 section, though.

[Orion Pobursky]

The two new paragraphs are basically contradictory. If "real" fallback geometry is only "highly encouraged", then it's not appropriate to forbid geometry2 lines (and the NEXT command). Since the second paragraph states that it is acceptable (although discouraged) to submit a part that shows blank geometry where the texture is, the best way to do that is to omit the geometry1 and geometry3 sections entirely. It would not be acceptable to only have a geometry1 section, though.

I don't see it that way. There always needs to be a fallback to produce a part without holes in non-TEXMAP compliant renderers (and TEXMAP is not required by the file format spec so we have to honor that). With NEXT you don't get fallback at all. With geometry2 you might but even the spec itself discourages it's use. Therefore it's better and simpler to just say no NEXT, no geometry2, and all fallback geometry goes in geometry3.

[Travis Cobbs]

I don't see it that way. There always needs to be a fallback to produce a part without holes in non-TEXMAP compliant renderers (and TEXMAP is not required by the file format spec so we have to honor that). With NEXT you don't get fallback at all. With geometry2 you might but even the spec itself discourages it's use. Therefore it's better and simpler to just say no NEXT, no geometry2, and all fallback geometry goes in geometry3.

That is definitely not true. I believe that you are misunderstanding TEXMAP.

If the texture is drawn over a single quad, then the blank version of that exact same quad is perfectly legal. In this case, that quad would be a geometry2 quad, and would logically use !TEXMAP NEXT, since it's a single geometry line. If a texture is displayed over multiple triangles and/or quads, then START/END is required, but omitting the texture would still show blank geometry in the same place, as long as they use geometry2.

Obviously, anything in the geometry1 section would be ignored by non-TEXMAP compliant renderers. So, if there is a geometry1 section, then it is almost certain that there should also be a FALLBACK section. Requiring this in the official parts spec is reasonable. But the easiest way to make a textured part is to simply leave the textured geometry blank for non-TEXMAP compliant renderers. So disallowing NEXT and geometry2 in official parts is wrong.

[Orion Pobursky]

That is definitely not true. I believe that you are misunderstanding TEXMAP.

If the texture is drawn over a single quad, then the blank version of that exact same quad is perfectly legal. In this case, that quad would be a geometry2 quad, and would logically use !TEXMAP NEXT, since it's a single geometry line. If a texture is displayed over multiple triangles and/or quads, then START/END is required, but omitting the texture would still show blank geometry in the same place, as long as they use geometry2.

Obviously, anything in the geometry1 section would be ignored by non-TEXMAP compliant renderers. So, if there is a geometry1 section, then it is almost certain that there should also be a FALLBACK section. Requiring this in the official parts spec is reasonable. But the easiest way to make a textured part is to simply leave the textured geometry blank for non-TEXMAP compliant renderers. So disallowing NEXT and geometry2 in official parts is wrong.

That's not right either. From the spec:

The first set of geometry will be used when textures are active (and the second will be ignored), and vice-versa when TEXMAP is not supported.

Therefore, in order for a non-!TEXMAP renderer to render the part correctly, per spec, there has to be a FALLBACK section and geometry3 lines.

[Roland Melkert]

That is definitely not true. I believe that you are misunderstanding TEXMAP.

If the texture is drawn over a single quad, then the blank version of that exact same quad is perfectly legal. In this case, that quad would be a geometry2 quad, and would logically use !TEXMAP NEXT, since it's a single geometry line. If a texture is displayed over multiple triangles and/or quads, then START/END is required, but omitting the texture would still show blank geometry in the same place, as long as they use geometry2.

Obviously, anything in the geometry1 section would be ignored by non-TEXMAP compliant renderers. So, if there is a geometry1 section, then it is almost certain that there should also be a FALLBACK section. Requiring this in the official parts spec is reasonable. But the easiest way to make a textured part is to simply leave the textured geometry blank for non-TEXMAP compliant renderers. So disallowing NEXT and geometry2 in official parts is wrong.

I agree

geometry2 is basically shared code (between the textured and fallback version)

NEXT is only useful for simple shapes (e.g. sticker quad), and as Travis explained it is its own fallback (the plain quad)


bit off-topic:

Something that does bother me a bit though, is the fact we seem to assume the textured version is 'better'.

This is not always true. The textured version could be faster to render and even give nicer results (especially on curved surfaces) but in many cases a vector representation will result in higher details upon zooming.

So unless we allow vector formats alongside png the textured version is not always visually the best solution.

For this reason I find the whole 'fallback' term a bit misleading, I wouldn't mind some hint system in order to let the renderer choose fallback over textured in some cases.

[Orion Pobursky]

geometry2 is basically shared code (between the textured and fallback version)

I basically agree but the spec contradicts this. Once again, we're back to revising the spec for clarity. Sigh.

[Orion Pobursky]

That's not right either. From the spec:

Therefore, in order for a non-!TEXMAP renderer to render the part correctly, per spec, there has to be a FALLBACK section and geometry3 lines.

Actually, the more I think about this, there more it doesn't make sense. For programs that don't know the !TEXMAP meta, the non 0!: lines would be rendered regardles of where they were. For those programs that do recognize !TEXMAP, why go through the trouble of implementing support and not support texmaps? As I said in my reply to Roland, the spec needs another clarification.

[Orion Pobursky]

Based on the above discussion, I change my proposal to the following:

!TEXMAP Meta
Sufficient !TEXMAP <geometry2> and/or <geometry3> lines (as outlined in the Texture Mapping (!TEXMAP) Language Extension) must be included such that the part renders correctly in non-!TEXMAP supporting programs. It is highly encouraged that the included geometry reflect the pattern created by the !TEXMAP, even if it is reduced in resolution or colors, but this is not required.

In addition, the spec should be further clarified as discussed above.

[Travis Cobbs]

Actually, the more I think about this, there more it doesn't make sense. For programs that don't know the !TEXMAP meta, the non 0!: lines would be rendered regardles of where they were. For those programs that do recognize !TEXMAP, why go through the trouble of implementing support and not support texmaps? As I said in my reply to Roland, the spec needs another clarification.

The intent was that "the first set of geometry" referred to the geometry1 and geometry2 lines, and the second referred to the fallback lines (geometry3). I suspect that over the evolution of the spec creation, this was written before the first bits were explicitly called out as geometry1 and geometry2. To be clear, "geometry1" refers to TEXMAP lines with 0 !: prefix, while "geometry2" refers to TEXMAP lines without that prefix. Furthermore, it's perfectly valid for them to be mixed and matched, although the spec certainly implies otherwise.

[Travis Cobbs]

I basically agree but the spec contradicts this. Once again, we're back to revising the spec for clarity. Sigh.

I don't personally feel that the spec outright contradicts this, but I do agree that what is there is unclear.

[Travis Cobbs]

Based on the above discussion, I change my proposal to the following:


In addition, the spec should be further clarified as discussed above.

This sounds good (both points).

[Travis Cobbs]

Something that does bother me a bit though, is the fact we seem to assume the textured version is 'better'.

This is not always true. The textured version could be faster to render and even give nicer results (especially on curved surfaces) but in many cases a vector representation will result in higher details upon zooming.

So unless we allow vector formats alongside png the textured version is not always visually the best solution.

For this reason I find the whole 'fallback' term a bit misleading, I wouldn't mind some hint system in order to let the renderer choose fallback over textured in some cases.

I think that it is generally assumed that if the vector geometry is better, it will be there instead of the texture, as opposed to being the fallback for a texture. While it is true that the texture would almost always render more quickly, LDraw has traditionally mostly preferred accuracy to performance.

[Magnus Forsberg]

To me as a user, and a reviewer, this is still a mystery. I can't say that I understand, or need to understand, the technical side of this spec.
Is there somewhere a "Texmap for dummies"?

What is the right way to do a texmap part? What is wrong?
When do I Hold-vote?
What size should the image have? Is there a right size? When do I hold-vote?
Resolution?
When should I not use a texmap?
Am I allowed to leave the fallback surface without a pattern?

In recent time we've seen some very simple files using a texmap image instead of a geometry pattern. Is that OK?
And we have also seen some very large and complex parts, but without a fallback geometry.

I think it would be great to have good example files, maybe on the wiki, to download and study.

How should a reviewing tool handle these rules?
I know that DatHeader will chrash if I try to review a file without a correct geometry?

I agree with Roland. We should talk more about the quality/demands on the "fallback" geometry.

[Lasse Deleuran]

(...)

I agree with Roland. We should talk more about the quality/demands on the "fallback" geometry.

Is there an overview of which viewers and editors that cannot handle Texmap? Adding fallback geometries can be a great amount of work, so I'm considering if it will be easier to simply update all viewers.

We have open source code for Texmap -> UV translation, so porting this code to the various editors might be a good choice.

[Orion Pobursky]

Is there an overview of which viewers and editors that cannot handle Texmap? Adding fallback geometries can be a great amount of work, so I'm considering if it will be easier to simply update all viewers.

We have open source code for Texmap -> UV translation, so porting this code to the various editors might be a good choice.

I think MLCad is the only major outlier and it will probably never be updated. There are, however, quite few minority viewers/editors that will probably never be updated either. Most of those don't recognize the !COLOUR meta either so they can't rightly be said to follow the spec.

[Lasse Deleuran]

I think MLCad is the only major outlier and it will probably never be updated. There are, however, quite few minority viewers/editors that will probably never be updated either. Most of those don't recognize the !COLOUR meta either so they can't rightly be said to follow the spec.

What do you think is the likelihood of MLCad and those minority viewers/editors going Open Source (if they not already are), so that we can add it?

Having support of Texmap in part editors seems to be a priority task, given the subject at hand.

[Orion Pobursky]

I think MLCad is the only major outlier and it will probably never be updated. There are, however, quite few minority viewers/editors that will probably never be updated either. Most of those don't recognize the !COLOUR meta either so they can't rightly be said to follow the spec.

That said, there are several issue that Magnus brought up that can be objectively evaluated and maybe should be addressed in the spec (e.g. image dimensions). There are others that can only be evaluated subjectivity (e.g. image clarity) that should be hashed out in the review process.

[Magnus Forsberg]

How about LeoCAD and Bricksmith?  Lpub3D?  POV-Ray?

Import/export to and from Stud.io? Will it work?

And the guys over at Eurobricks and GitHub,
Import/export to and from LDD ?

Blender export?

[Orion Pobursky]

How about LeoCAD and Bricksmith?  Lpub3D?  POV-Ray?

Import/export to and from Stud.io? Will it work?

And the guys over at Eurobricks and GitHub,
Import/export to and from LDD ?

Blender export?

I'm pretty sure LeoCad supports and I know Bricksmith does. LPub3D uses LDView as the its rendering engine so yes. POV-Ray isn't an LDraw program. 

Part of the reason for this change proposal is to make sure the official part has, at the very least, correct geometry in non-TEXMAP supporting programs (i.e. no missing faces, holes, etc). I think that's the most important issue and why I made this proposal. 

The other issue, and something we can hash out in a different thread is how detailed the fallback needs to be or when TEXMAP is appropriate.

[Eugen]

I'm pretty sure LeoCad supports...

Part of the reason for this change proposal is to make sure the official part has, at the very least, correct geometry in non-TEXMAP supporting programs (i.e. no missing faces, holes, etc). I think that's the most important issue and why I made this proposal.

Yes, LeoCAD supports "!TEXMAP": https://www.leocad.org/docs/texmap.html

Is there a way to link texture image located in the same folder with the LDraw model? (instead of moving texture image file into LDraw library "texture/" subfolder), i.e.:

• ../Documents/model.ldr
  
• ../Documents/texture.png
  

I know its possible to embed image into LDraw file with Base64, but question is about linking texture file outside LDraw library folders.

[Travis Cobbs]

Yes, LeoCAD supports "!TEXMAP": https://www.leocad.org/docs/texmap.html

Is there a way to link texture image located in the same folder with the LDraw model? (instead of moving texture image file into LDraw library "texture/" subfolder), i.e.:

• ../Documents/model.ldr
  
• ../Documents/texture.png
  

I know its possible to embed image into LDraw file with Base64, but question is about linking texture file outside LDraw library folders.

I don't know how LeoCAD works, but the !TEXMAP spec states that texture files should be looked for in the "textures/" folder, and if not found there, then in the folder containing the model. So having texture.png in the same directory as model.ldr is supposed to work.

[Eugen]

I don't know how LeoCAD works, but the !TEXMAP spec states that texture files should be looked for in the "textures/" folder, and if not found there, then in the folder containing the model. So having texture.png in the same directory as model.ldr is supposed to work.

I just copied example code from LeoCAD docs: https://www.leocad.org/docs/texmap.html

Code:

0 !TEXMAP START PLANAR 100 10 100 100 10 -100 -100 10 100 bottom.png
4 16 100 1 -100 100 1 100 -100 1 100 -100 1 -100
0 !TEXMAP END

0 !TEXMAP START PLANAR -100 -200 10 100 -200 10 -100 0 10 side.png
4 16 100 -200 120 100 0 120 -100 0 120 -100 -200 120
0 !TEXMAP END

0 !TEXMAP START PLANAR 0 -200 100 0 -200 -100 0 0 100 side.png
4 16 120 -200 100 120 0 100 120 0 -100 120 -200 -100
0 !TEXMAP END

Saved it as texmap.ldr, and placed it in a separate folder together with bottom.png and side.png images.

But opening this file in LeoCAD shows only untextured faces:

   


UPDATE: LeoCAD does not supports images placed in the same folder with LDraw file, and images embeded into LDraw file with "!DATA" command.

But LeoCAD supports texture image if it placed in "<path-to-library>/parts/textures/" folder.

[Eugen]

I proposed the following addition to the Official Library Spec to go with the proposed rev the !TEXMAP meta:

Under META Commands add:

!TEXMAP Meta
The !TEXMAP NEXT command or geometry2 lines (as outlined in the Texture Mapping (!TEXMAP) Language Extension) will not be used.

"Texture Mapping (!TEXMAP) Language Extension" (https://www.ldraw.org/spec/texmap.html) link not exists or moved.

Actual correct link: https://www.ldraw.org/texmap-spec.html

And the same page has one more link: https://www.ldraw.org/documentation/ldra...pping.html