Texture mapping experiment

[Philippe Hurbain]

You'll find here my first experiment with Texture mapping extension...
A few issues...
- Resolution (here 300dpi) looks fairly low, despite a rather large image size.
- The image was obtained by scanning the sticker sheet. But there are color matching issues! image file 10602r0.png is raw from scanner. In the image used for mapping (10602r.png) I tried to substitute yellow and red values obtained from LDconfig.ldr, but when you look at part with sticker (64683stick-r.dat) using LDView, you see that match is still far from perfect. And what happens if LDConfig color definition is tuned? The sticker will no longer match...
- Smooth shading doesn't seem effective in LDView with texmap (see parts with "condlines" in filename)
- This forum doesn't let me post texture images directly! (or a zipped folder...).

Comments? Suggestions?

Edit: Just noticed that subfile 64683s03.dat wrongly contained top surface. Now corrected in archive linked above.

[Roland Melkert]

Maybe playing around with a fixed palette (using some of the LDraw colors) helps. You could then (in theory) use a descent image converter to map all pixels to the nearest LDraw colors.

[Philippe Hurbain]

Interesting suggestion.
BTW1, is it possible to use paletized PNGs? LDView doesn't seem to support them
BTW2, do you plan to add texmap to LDCad? (I know you are busy with flex parts

[Roland Melkert]

#1: I think so, the libpng source seem to support it. But you could also use a different (loss less) format for the palette conversion (gif, bmp), and then convert it back to rgb(a) afterwards. irfanview could possible do most of the work (with some plugins).

#2: Yes I will add support for textures in LDCad, biggest issue for me with that is how to keep the 'normal' rendering at the current speed.


Thinking about libpng, you could probably make a relatively easy c++ program using libpng to convert a png to one using the nearest LDraw colors without having to use all kinds of tools.

[Philippe Hurbain]

Maybe that's not so simple. I made some tests using Photoshop, using a 4 colors palette with only LDraw colors. Problem is that RGB -> 4 colors palette conversion finds a red fringe around black areas...

[Roland Melkert]

could be Photoshop applying anti aliasing. Or if the source it self has a gradient (usually also aa) of red on that location.

Maybe you could use a second 'lesser' red control color, you can change to black afterwards.

[Philippe Hurbain]

No, I think it's just proximity of jellow and black that produce an intermediate tone actually closer to red. Anyway for relatively straighforward pattern like this one, it would be better/simpler to vectorize the image. But then we are not far away from old style patterns

[Roland Melkert]

This unwanted dithering might be caused by Photoshop mapping pixels to the nearest palette color in an area where it's pretty much 50/50 between 'rounding' to yellow or black so it goes yellow for one pixel and black for one besides it although it might only be like 1rgb value higher or lower. Not sure how to fix that, I'm not that familiar with Photoshop.

I actually think most patterns will be indeed better of using the old way, but textures are very handy for extremely complex stuff or placeholders until someone finds the time to make a vector version.

[Philippe Hurbain]

Indeed, this one is pretty simple. I started this experimentation with a really complex one in mind...

[Travis Cobbs]

I'll investigate what might be needed to support paletted PNGs in LDView. Could you send me a sample file (both texture and part)? That would make my life easier.

[Travis Cobbs]

- Resolution (here 300dpi) looks fairly low, despite a rather large image size.

When you view the part all by itself and have it fill the window, the resolution is iffy. However, if you included the part inside a model and view the model, I think the resolution is plenty high enough.

Also, are you positive your images are 300DPI when displayed at actual size? When I view the image on my screen (at around 100DPI), the graphics are about 4.25" from the leftmost black part to the rightmost black part. Is that distance really less than 1.5" in real life? (I don't have this sticker.)

[Philippe Hurbain]

However, if you included the part inside a model and view the model, I think the resolution is plenty high enough.

You are probably right...

Also, are you positive your images are 300DPI

Definitely, yes. Physical part length is 2 inches, and image size is 600 pixels.

[Michael Heidemann]

Code:

I tried to substitute yellow and red values obtained from LDconfig.ldr,

Can you please explain why you do that.
In my opinion a picture (and a scan is a picture) should stay the way it is created. I would never try to substitude a color on a scanned sticker with a color from LDConfig.ldr. I think in most cases the result is not the same. On the other hand we have the direct colors introduced just fot pattern because the colors do match to LDconfig.ldr very seldom. So I am irritating by your attempt, but I guess you have a good reason for that ?

[Alex Taylor]

First, scanners are not accurate. The colours you get back will not be the same as the colours of the original image.

Second, the LDConfig.ldr colours are not accurate. They are best-approximations to the actual LEGO colours, adjusted to look 'right' on a typical computer monitor. Not that monitors are particularly accurate either... :-)

Third, in this particular case, the sticker is supposed to be the same colour as the part it's being applied to, so it is entirely reasonable to use the LDConfig colours for it.

[Philippe Hurbain]

In the general case, I agree with you... even though color calibration is a VERY complex matter, involving scanner, screen, rendering software, etc. You also have to live with real life devices, eg. here, colors are not even uniform from one end to the other end of the sticker, despite my scanner is reasonnably good (it's an Epson V30).

But for this model, stickers are stuck on same color parts, and in real life they blend very well with the substrate. Raw scans clearly didn't... Actually, several of the stickers are half red/half yellow, and are stuck on red and yellow panels to form a seamless diagonal line (see http://shop.lego.com/en-US/Helicopter-9396). Clearly color match should be perfect!

Edit - just saw Alex post... we pretty much agree

[Michael Heidemann]

I agree fully with you regarding the colors. But I would solve that in a different way. If one color in computer does not match the real color I would tune the computer color of the whole picture. Not only one specific color.
Because if one color does not match I belive that also all other colors on the sticker are not correct .

[Alex Taylor]

I agree fully with you regarding the colors. But I would solve that in a different way. If one color in computer does not match the real color I would tune the computer color of the whole picture. Not only one specific color.
Because if one color does not match I belive that also all other colors on the sticker are not correct .

...which is what he did ;-)

[Travis Cobbs]

Just as a note, you can set the yellow part of the texture to be clear, and then set the underlying part geometry to be yellow, and the problem should go away. Antialiasing around the printed bits can get complicated, though.

Note that this is NOT the same thing as trying to set the yellow part of the sticker to be transparent. You'd be setting the yellow part of the texture to be yellow, but since the texture would then be applied over yellow geometry, the sticker itself would still be yellow for that section.

[Tim Gould]

Hey Travis, could you illustrate with a pic? I'm not sure I understand you. Not that I'll be doing anything like this anytime soon, but it would be nice to have it demonstrated

[Philippe Hurbain]

I should have thought of that! Excellent idea.
It can even kill two birds with the same stone... eg. for diagonal line stickers 1 and 2 in this sheet, you set sticker top red/silver/yellow, and add only fine grid details as texmap. And the colored sticker top can act as a fall back for non-texmap able viewers. This is another example where imho 0 !FALLBACK should be made optionnal, fall back geometry and projection geometry are the same.

[Michael Heidemann]

Yes, the geometrie is the same, but the "fine grid details" that you apply with the TEXMAP section should also be modeled in the FALLBACK section for viewers that do not understand TEXMAP.
So the texture that we bring into the parts is always only an addon. The traditional procedure for pattern has always to be done. That is what I read from the spec.

[Philippe Hurbain]

No! I don't agree! or we loose any benefit of texmap. A fallback is just that - a poor man's version!

[Michael Heidemann]

I somewhat agree with you, but at present it is nevertheless not allowed in official files

[Travis Cobbs]

Replace 10602r.png in Philo's example with the image below (make sure to click on it and save the original image and not the one shown in the forum):



If you do that, Philo's sample sticker parts will appear with a gray background, which is wrong, but 64683stick-r.dat, which has the sticker applied to the part using color 14 as the main color for the sticker, will appear correct. Simply update all the color 16 instances in the front-side sticker geometry to be color 14, and the stickers will then be correct also.

[Michael Heidemann]

Yes, that is a good example how to solve the color problem