![]() |
|
How to review texmap images - Printable Version +- LDraw.org Discussion Forums (https://forums.ldraw.org) +-- Forum: General (https://forums.ldraw.org/forum-12.html) +--- Forum: Parts Tracker Discussion (https://forums.ldraw.org/forum-36.html) +--- Thread: How to review texmap images (/thread-29160.html) |
How to review texmap images - Peter Blomberg - 2025-11-09 How are texmap images reviewed? Is special software needed? RE: How to review texmap images - Chris Böhnke - 2025-11-10 Last time I reviewed, I mostly just did visual comparison. There are two problems here:
What I think is important to check:
RE: How to review texmap images - Orion Pobursky - 2025-11-10 (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. 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. RE: How to review texmap images - Peter Blomberg - 2025-11-20 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? RE: How to review texmap images - Chris Böhnke - 2025-11-20 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 RE: How to review texmap images - Travis Cobbs - 2025-11-20 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. RE: How to review texmap images - Orion Pobursky - 2025-11-21 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. RE: How to review texmap images - Peter Blomberg - 2025-11-21 (2025-11-20, 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. RE: How to review texmap images - Orion Pobursky - 2025-11-21 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 RE: How to review texmap images - Peter Blomberg - 2025-11-21 (2025-11-21, 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. RE: How to review texmap images - Peter Blomberg - 2025-11-21 Any regulations or pointers on the "fallback pattern"? RE: How to review texmap images - Orion Pobursky - 2025-11-21 (2025-11-21, 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). RE: How to review texmap images - Willy Tschager - 2025-11-21 (2025-11-21, 3:24)Orion Pobursky Wrote: This part is an example of part that would be pretty much impossible _without_ texmap: The above statement is not correct: w. RE: How to review texmap images - Peter Blomberg - 2025-11-21 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. RE: How to review texmap images - Roland Melkert - 2025-11-21 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 RE: How to review texmap images - N. W. Perry - 2025-11-22 (2025-11-21, 23:19)Roland Melkert Wrote: From a rendering pov i still think any curved area is better of using a texture. 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? RE: How to review texmap images - Hageta - 2025-11-22 (2025-11-22, 16:02)N. W. Perry Wrote: 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 am currently working on an OpenScad template that can put svgs on a rectangle. RE: How to review texmap images - Roland Melkert - 2025-11-22 (2025-11-22, 16:02)N. W. Perry Wrote: 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. RE: How to review texmap images - Chris Böhnke - 2025-11-22 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 RE: How to review texmap images - N. W. Perry - 2025-11-23 (2025-11-22, 22:56)Roland Melkert Wrote: 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. 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? |