How to review texmap images

[Peter Blomberg]

How are texmap images reviewed? Is special software needed?

[Chris Böhnke]

Last time I reviewed, I mostly just did visual comparison.

There are two problems here:

1. There are no direct regulations regarding the actual content of a Texmap image file (at least not that I am aware of). It probably is also a bit tricky defining any "hard" rules here.
   
2. I doubt there are many people who really check for colour consistency, especially since Texmaps are primarily used for colour gradients and similar.
   

What I  think is important to check:

1. Is the image "correct": All details, colours etc present and at the right place? Like on a regular vector pattern.
   
2. Are the proportions correct when applied to the part file?
   
3. Do the colours "match"? As stated above, most likely have little signs of editing fromtheir original source, so the hexes probably don't match exactly. If they look too off, I see that as an error, but not as strictly as on a regular pattern. Be wary of those that should match the border of it's base part.
   
4. Is the Texture REALLY needed? IMO Texmaps should only be used as a last ressort, when everything else is not possible to achieve a realistic result. Complex images (especially without gradients/dither) should be done traditionally.
   
5. Excessive File size? Not sure if server checks automatically.
   
6. Possible licencing problems? Certain things may not be allowed (like https://www.bricklink.com/v2/catalog/cat...only%22:0}).
   

[Orion Pobursky]

[*]Is the image "correct": All details, colours etc present and at the right place? Like on a regular vector pattern.
[*]Are the proportions correct when applied to the part file?
[*]Is the Texture REALLY needed? IMO Texmaps should only be used as a last ressort, when everything else is not possible to achieve a realistic result. Complex images (especially without gradients/dither) should be done traditionally.

These are the most important

[*]Excessive File size? Not sure if server checks automatically.

Texture image are run through an image optimizer upon submission.

[Peter Blomberg]

Would a pattern such as https://library.ldraw.org/parts/30501 fall under "TEXMAP not really needed" since the colors are uniform and the colored area borders are sharp?

What is the preferred way of handling this type of situation? Vote or comment?

[Chris Böhnke]

Technically, yes.

However this is one of the Super Mario barcodes, which is a problem that already runs a bit deeper than that  
The barcodes could easily take advantage of some sub-file usage, also those are one of the few examples of pre-applied stickers, which makes numbering more complicated and there are quite a LOT of them, which look almost identical. Just to name a few issues with them.

If you need a few more examples of "unneeded", look here https://library.ldraw.org/parts/sticker-sheets/929

[Travis Cobbs]

I think it's worth pointing out that one of the reasons for adding support for texmap was the hope that more parts would be modeled, since using a texture can be significantly easier than modeling the geometry. With this in mind, I personally feel that stating that anything that can be modeled should be modeled is wrong-headed.

[Orion Pobursky]

To tack onto Travis's comment, which I agree with:

I definitely implied above that I felt that a part with a texmap that could be modeled with geometry was a holdable problem. This isn't the case. As long as the Texmap meets all the other quality criteria, it should be certified and released. If someone else wants to redo the part with vector geometry, that's fine too.

[Peter Blomberg]

I think it's worth pointing out that one of the reasons for adding support for texmap was the hope that more parts would be modeled, since using a texture can be significantly easier than modeling the geometry. With this in mind, I personally feel that stating that anything that can be modeled should be modeled is wrong-headed.

Yes, I've wondered about that. Why should one use this cumbersome way of splitting a surface in million pieces when simply applying an image on a surface can do the same job? From what I can observe, the image tends to be smaller in byte size than the huge number of lines any complex pattern would need.

[Orion Pobursky]

This part is an example of part that would be pretty much impossible with texmap:
https://library.ldraw.org/parts/25449

Here's another:
https://library.ldraw.org/parts/23919

This one is high quality but definitely could be geometry:
https://library.ldraw.org/parts/32004

This one is borderline IMO (and there appear to be an image generation bug with this one as well):
https://library.ldraw.org/parts/24737

[Peter Blomberg]

This part is an example of part that would be pretty much impossible with texmap:
https://library.ldraw.org/parts/25449

Here's another:
https://library.ldraw.org/parts/23919

This one is high quality but definitely could be geometry:
https://library.ldraw.org/parts/32004

This one is borderline IMO (and there appear to be an image generation bug with this one as well):
https://library.ldraw.org/parts/24737

Thanks for the examples. The two first are impossible _without_ texmap.

[Peter Blomberg]

Any regulations or pointers on the "fallback pattern"?

[Orion Pobursky]

Any regulations or pointers on the "fallback pattern"?

Per the spec:

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.

Translation:
The part must render correctly on fallback and the pattern is not required but strongly encouraged (but not necessarily pixel perfect).

[Willy Tschager]

This part is an example of part that would be pretty much impossible _without_ texmap:
https://library.ldraw.org/parts/25449

The above statement is not correct:

   

w.

[Peter Blomberg]

Thanks Willy!

Perhaps it is better to claim that it is more convenient with texmap in particular because of the large number of triangles otherwise needed.

[Roland Melkert]

From a rendering pov i still think any curved area is better of using a texture. 

Otherwise you often get the 'crumbled paper' effect, most noticeable on minifig heads.

With flat surfaces it depends on the number of (tiny) triangles needed whether to use a texture or not.

my 2cts

[N. W. Perry]

From a rendering pov i still think any curved area is better of using a texture. 

Otherwise you often get the 'crumbled paper' effect, most noticeable on minifig heads.

With flat surfaces it depends on the number of (tiny) triangles needed whether to use a texture or not.

my 2cts

This was my thought as well. While the MF head shown above (https://library.ldraw.org/parts/24737) isn't as hi-res a a geometric pattern, it avoids the problem Roland describes.

I'd love to see a solution someday that provides the scalability of vector graphics without breaking primitive substitution. Theoretically, would it be possible to map an SVG graphic onto a part rather than a PNG?

[Hageta]

This was my thought as well. While the MF head shown above (https://library.ldraw.org/parts/24737) isn't as hi-res a a geometric pattern, it avoids the problem Roland describes.

I'd love to see a solution someday that provides the scalability of vector graphics without breaking primitive substitution. Theoretically, would it be possible to map an SVG graphic onto a part rather than a PNG?

I am currently working on an OpenScad template that can put svgs on a rectangle.

[Roland Melkert]

I'd love to see a solution someday that provides the scalability of vector graphics without breaking primitive substitution. Theoretically, would it be possible to map an SVG graphic onto a part rather than a PNG?

I was wondering about the usefulness of using normal type 1..4 lines to describe the pattern which a renderer can use to generate a texture. 

This would work much like embeded textures but instead of !DATA it uses normal ldraw code which must be 2d and flat.

[Chris Böhnke]

Strongly agree on the curved surfaces issue. Texmap avoids many problems here.

However, I would argue that consistency should have a certain prioity here. At least when dealing with parts that have a very large number of available patterns like the minifig head.

If we have a mix of both styles for the same part it looks weird when both are used together.
Also consistency helps a bit in reviewing parts IMO.


Regarding fallback, you can also split a pattern into the "doable" and "impossible" part and only have the later use texmap. That way, fallback often becomes a monochrome area.
Example:
https://library.ldraw.org/parts/45891

[N. W. Perry]

I was wondering about the usefulness of using normal type 1..4 lines to describe the pattern which a renderer can use to generate a texture. 

This would work much like embeded textures but instead of !DATA it uses normal ldraw code which must be 2d and flat.

Even better, really, as it saves having to translate from SVG format (which is not too different from LDraw code anyway, just different language format). Couldn't a renderer then project this flat geometry onto, e.g., a cylinder to make a minifig head without the "crumpled paper" effect?