TEXMAP addition to Official Library Spec


TEXMAP addition to Official Library Spec
#1
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.
Reply
RE: TEXMAP addition to Official Library Spec
#2
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#3
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#4
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#5
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#8
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#10
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#6
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#7
(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.
Reply
RE: TEXMAP addition to Official Library Spec
#11
(2020-07-21, 23:39)Orion Pobursky Wrote: 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.
Reply
RE: TEXMAP addition to Official Library Spec
#13
(2020-07-21, 23:30)Roland Melkert Wrote: 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.
Reply
RE: TEXMAP addition to Official Library Spec
#14
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.
Reply
RE: TEXMAP addition to Official Library Spec
#15
(2020-07-24, 11:40)Magnus Forsberg Wrote: (...)

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.
Reply
RE: TEXMAP addition to Official Library Spec
#16
(2020-07-24, 13:22)Lasse Deleuran Wrote: 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.
Reply
RE: TEXMAP addition to Official Library Spec
#17
(2020-07-24, 13:31)Orion Pobursky Wrote: 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.
Reply
RE: TEXMAP addition to Official Library Spec
#18
(2020-07-24, 13:31)Orion Pobursky Wrote: 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.
Reply
RE: TEXMAP addition to Official Library Spec
#19
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?
Reply
RE: TEXMAP addition to Official Library Spec
#20
(2020-07-24, 16:05)Magnus Forsberg Wrote: 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.
Reply
RE: TEXMAP addition to Official Library Spec
#9
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.
Reply
RE: TEXMAP addition to Official Library Spec
#12
(2020-07-21, 23:49)Orion Pobursky Wrote: 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).
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)