LDraw.org Discussion Forums

Full Version: TEXMAP addition to Official Library Spec
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
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.
(2020-07-21, 21:38)Orion Pobursky Wrote: [ -> ]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.
(2020-07-21, 22:53)Travis Cobbs Wrote: [ -> ]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.
(2020-07-21, 23:02)Orion Pobursky Wrote: [ -> ]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.
(2020-07-21, 23:13)Travis Cobbs Wrote: [ -> ]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:
Quote: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.
(2020-07-21, 23:13)Travis Cobbs Wrote: [ -> ]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.
(2020-07-21, 23:30)Roland Melkert Wrote: [ -> ]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.
(2020-07-21, 23:27)Orion Pobursky Wrote: [ -> ]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.
Based on the above discussion, I change my proposal to the following:

Quote:!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.
(2020-07-21, 23:44)Orion Pobursky Wrote: [ -> ]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.
Pages: 1 2