[size=xx-small][font=Tahoma,Arial]* 

* 

(2020-07-25, 14:15)Jaco van der Molen Wrote: Can the globe print be done trough texture mapping?
The part exists.

I am trying to make the image for mapping, but I am unsure how to map the image on the part.

(2020-07-25, 16:10)Orion Pobursky Wrote: This is one of the outstanding patterns for the modulars. If you come up with a good image, it can prolly be TEXMAPed.

(2020-07-26, 1:48)Travis Cobbs Wrote: It should be straightforward using spherical mapping. The attached file will map earth.png (not included) onto a sphere. (That just needs to be any map of the Earth using Mercator Projection, I think.)

(2020-07-26, 16:09)Magnus Forsberg Wrote: I have no idea of what I'm doing but this works, sort of.
I used, and adapted the example from Travis below.



Something breaks around the northpole.

(2020-07-26, 16:09)Magnus Forsberg Wrote: I have no idea of what I'm doing but this works, sort of.
I used, and adapted the example from Travis below.



Something breaks around the northpole.

(2020-07-26, 21:52)Travis Cobbs Wrote: One problem with spherical mapping is that things go bad at the north and south poles. This isn't a problem on the bottom due to the fact that there's nothing at the south pole, but two polygons on top share the north pole as one of their vertices.

Another problem is that your image needs to be quite a bit taller than it currently is to work as a mercator projection. It seems like the image you have is roughly -80 to +80 latitude. If you change the the second 180 to 160 in the !TEXMAP line to reflect this, things get a bit better, but still not perfect (at least in LDView). I need to check to see if there is a bug in LDView. The top edge of the texture doesn't work well. Having said that, there is no way to apply two separate textures to the same geometry, so having a texture stop in the middle of a polygon leaves the rest of that polygon blank, and there's nothing you can do about that.

If the sphere geometry stopped at +80 degrees, and then a cone was used above that, a separate texture could be applied to the cone from above, and things would probably look pretty good. (Getting that texture to line up would take some work, but it would certainly be possible.) In that case, your existing texture would work great with a 160 degree vertical span.

I also tested by resizing your original image to be 1600 pixels tall, and just filling in the new space with the tan background (leaving the angle in the file set to 180). That actually improves things a lot, but the longitude lines then stop before the pole, and extending them up runs into the north pole discontinuity problem again.

As for the wiggly lines, I think that is caused by the fact that the spherical geometry is so low-resolution.

(2020-07-27, 20:39)Jaco van der Molen Wrote: OK, I will do some testing with the image and test the part Magnus made.
If all goes well I will have the physical part tomorrow so I can try match the worldmap as good as possible.

(2020-07-28, 6:49)Magnus Forsberg Wrote: Please note that I repositioned the subfiles to fit the image, instead of moving the image.
This part, 61287, have a bad orientation. The outside, printed surface, will end up on the backside, in default position.

I have some ideas on how to change the surface. Let me know if you need help with the shape of the part.

(2020-07-28, 10:26)Jaco van der Molen Wrote: I definitely need help with the part. I can do the image.
Here is another test.

Definitely some strange things happening on the north pole.
I got the part today, so now I am line drawing the outlines of the continents to match the part

(2020-07-28, 13:03)Jaco van der Molen Wrote: Some more WIP to download at:
https://drive.google.com/drive/folders/1sR6d4DNUuJeecRS7ZCBbUACZei5SNnXW?usp=sharing
I will update my work in this folder.

(2020-07-28, 14:14)Magnus Forsberg Wrote: I made two surfaces.
One based on a 4-8sphere primitive, and one replicating the globe/map, with longitudinal lines.
I think the logitudinal works best. May be that we should make a surface that completely match the black lines in the pattern?

(2020-07-28, 19:49)Jaco van der Molen Wrote: Indeed I agree that 61287p01_longitude.dat will work best. I will do some testing again tomorrow!

But don't you think we should match the image, instead of the geometry?

(2020-07-29, 11:56)Magnus Forsberg Wrote: 2 subfiles are now at the Part Tracker.
https://www.ldraw.org/cgi-bin/ptscan.cgi?q=61287&scope=description

Attatched here is a file with correct position on the part and texmap.  It might still need some finetuning.
I've extended the printed surface to include some of the bottom. It is actually also printed.
Shouldn't the tan part of the image be transparent?

(2020-07-29, 12:32)Jaco van der Molen Wrote: What do we think of the images so far?

(2020-07-29, 14:58)Magnus Forsberg Wrote: I like them alot.
But the pattern is offset. I think the equator line has to be in the center of the image, but I'm not sure.

(2020-07-29, 14:58)Magnus Forsberg Wrote: And the whole grid has to be perfectly adjusted to the center of the image. 
The "empty" half-square to the left and right has to be equally wide. And together they should have the same width as a whole square.

The bottom surface is at y=0. The northpole is at y=-46, but the equator is at y=-20
Should the image be cut to compensate for the missing south pole?

(2020-07-29, 12:49)Jaco van der Molen Wrote: I am not sure about the transparency of the image.
Compare with dark tan background left image (using the hex-color code for dark tan from ldconfig) and transparent right image.
Rendered with LDView in LPub3D


Above post features image rendered in LDCad with tan background.
This is transparent background in LDCad

(2020-07-29, 19:43)Travis Cobbs Wrote: If I modify the textures to be transparent, they look fine in LDView. I don't have the part, but I assume that the pattern is only present on the non-tan portions. Assuming that this is the case, then the textures should be transparent. I'm not sure why the LPub3D LDView rendering looks so bad.

Note that when I made the tan parts of your textures transparent, I was left with a faint tan halo around everything, although this wasn't really visible when it was applied to the part. If your source art is vector, you can regenerate the PNGs with transparent background instead of tan, and wouldn't have this problem. Or is that what generated the weird transparent screenshots you posted?

Can you upload the transparent version of the textures so I can investigate?

(2020-07-30, 11:16)Jaco van der Molen Wrote: OK, my source files are vector so I can easily make the background transparent.
That is what I used when I rendered in LPub3D using LDView that came with LPub3D. I'll have to test with your normal version of LDView, but I am unsure that works in LPub3D. I do not have access to my laptop with the graphics program (I use Adobe Fireworks btw) nor the LDraw stuff, so I will update later today.

(2020-07-30, 12:03)Jaco van der Molen Wrote: My daughter was so kind to give me some time on _my_ laptop, so I could upload transparent versions of the images in the Google folder: t-pb001.png and t-pb002.png =.
Where t stands for transparent, not tan. I have renamed the versions with background to dt-pb001.png and dt-pb001.png.

Next I tested and compare the two versions in LPub3D, LDView and LDcad.
Top globe is with transparent background, bottom is with dark tan background.

The strangest thing in LPub3D is that a certain area of the image is not rendered in every instance of the generated image.



LDCad does a very nice job rendering


LDView 4.3 did not render the textures and 4.2 crashed parsing the model.

(2020-07-30, 19:35)Travis Cobbs Wrote: The missing bits in LDView are probably due to a slider that needs to be adjusted. In the Textures section of the Primitives tab is an "Offset" slider. Setting it to a higher value will hopefully fix that problem. Having said that, the reason it isn't automatically set to a higher value is because doing so can introduce artifacts.

I made quite a few fixes to LDView's texture support relatively recently, and I don't know what code-base is being used by LPub3D. LDView 4.4 Alpha 6 (available here) renders the transparent version like this when the part color is set to Tan:

(2020-08-07, 14:40)Magnus Forsberg Wrote: Are you satisfied with the images now?
Do you want to upload the parts with texmap images?
Maybe you could make the dark brown version too?

(2020-08-07, 15:02)Jaco van der Molen Wrote: I am on vacation, I’ll take a last look in 2 weeks.

(2020-09-13, 11:24)Jaco van der Molen Wrote: Do we think these are ready to submit?

(2020-12-02, 20:37)Magnus Forsberg Wrote: These are now uploaded to the Part Tracker.

https://www.ldraw.org/cgi-bin/ptscan.cgi?q=bubble%20map&scope=header

(2021-02-06, 21:22)Magnus Forsberg Wrote: The one on the left is DkBrown, code 308
The one on the right is Reddish Brown, code 70

If the pattern is made using the same rgb code as Reddish Brown, why doesn't it look the same?

(2021-02-07, 4:12)Travis Cobbs Wrote: I'm not sure. Just to make sure I understand, you're saying that the texture uses the RGB for reddish brown, the oceans are transparent, and the underlying geometry is reddish brown?

(2021-02-07, 7:22)Magnus Forsberg Wrote: Correct. Screenshot from LDCad, not LDView. But I didn't make the texmap image.

https://forums.ldraw.org/thread-24419-post-40170.html#pid40170

(2021-02-07, 21:24)Travis Cobbs Wrote: In my LDConfig.ldr, color 70 (Reddish Brown) has a different RGB than the PNG texture. The RGB in the PNG for the brown part is #682b18. The RGB for Reddish Brown in LDConfig.ldr is #5F3109.

(2021-02-07, 21:28)Travis Cobbs Wrote: Also, if I edit the PNG for the texture to use #5F3109, the two colors look the same in LDView. (I don't have LDCad.)

(2021-02-07, 21:37)Jaco van der Molen Wrote: What color is it anyway on the real part? Is it reddish brown?

(2021-02-07, 22:38)Magnus Forsberg Wrote: That's the funny part of this issue. They both exist. Both DkBrown and Reddish Brown.

https://www.bricklink.com/v2/search.page?q=61287pb00*#T=A

(2021-02-08, 0:12)Travis Cobbs Wrote: The RGB in the PNG doesn't match any current color in LDConfig.ldr

(2021-02-08, 0:12)Travis Cobbs Wrote: The RGB in the PNG doesn't match any current color in LDConfig.ldr. Also, it's further from dark brown than it is from reddish brown. So, while a separate texture would be needed for each color, if it really does match those colors then the current texture could simply be updated to match reddish brown, and a new one (p02?) can be created for dark brown.

(2021-02-08, 1:45)Roland Melkert Wrote: Slightly off topic:

I've been thinking about supporting mapped pngs'  in LDCad, meaning using the combined RGBA color space as found in the decoded png as an LDraw number.

You could then map those numbers to the LDConfig RGBA defs before sending the raw image data to OpenGL.

Only real problem is how a renderer would know when to apply this.

Possible solution would to only allow <1024 colors, and apply this translation only if all RGBA pixel (uint) values are <1024

(2021-02-08, 7:01)Jaco van der Molen Wrote: OK, I can easily make 2 versions png (or rather 4, 2 for each half and variant)
I'll use LDraw's Reddish Brown and Dark Brown values.

(2021-02-09, 10:27)Jaco van der Molen Wrote: @Magnus: can I share the PNGs with you so you can submit to the PT?