How are texmap images reviewed? Is special software needed?
How to review texmap images
Last time I reviewed, I mostly just did visual comparison.
There are two problems here:
What I think is important to check:
There are two problems here:
- 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.
- 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:
- 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?
- 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.
- 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.
- Excessive File size? Not sure if server checks automatically.
- Possible licencing problems? Certain things may not be allowed (like https://www.bricklink.com/v2/catalog/cat...only%22:0}).
(2025-11-10, 21:35)Chris Böhnke Wrote: [*]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
(2025-11-10, 21:35)Chris Böhnke Wrote: [*]Excessive File size? Not sure if server checks automatically.
Texture image are run through an image optimizer upon submission.
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?
What is the preferred way of handling this type of situation? Vote or comment?
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
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
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.
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.
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.
(Yesterday, 23:33)Travis Cobbs Wrote: 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.
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
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
(Today, 3:24)Orion Pobursky Wrote: This part is an example of part that would be pretty much impossible with texmap:Thanks for the examples. The two first are impossible _without_ 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
(Today, 6:30)Peter Blomberg Wrote: Any regulations or pointers on the "fallback pattern"?
Per the spec:
Quote: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).
(Today, 3:24)Orion Pobursky Wrote: 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.
LEGO ergo sum
« Next Oldest | Next Newest »
Users browsing this thread: 2 Guest(s)

