Texture mapping


Texture mapping
#1
Hi all,

I've been very busy with texture mapping in the past days and did some bricks and tiles with nice "prints" for some projects I've been working on.

Now, I have need for a round 1x1 tile with a pattern.
So I made a square PNG image with transparent background (which works perfectly with the bricks and tiles) and mapped that on the surface.
Alas, this texture mapped surface remained planar and square so no such luck there.
Then I thought I'd made the plane on which is mapped transparent, but that had a bad result.

Would it be possible either way to apply texture mapping on other surfaces than rectangular, like for example the 4-4disc primitive?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#2
I see no reason why this shouldn't work... Got some screenshots/sample code? See also this round dish with texmap: http://www.ldraw.org/cgi-bin/ptdetail.cg...960p0b.dat
Reply
RE: Texture mapping
#3
(2017-06-28, 11:10)Philippe Hurbain Wrote: I see no reason why this shouldn't work... Got some screenshots/sample code? See also this round dish with texmap: http://www.ldraw.org/cgi-bin/ptdetail.cg...960p0b.dat

I was trying to create the Round Tile 1 x 1 with Brickheadz eye pattern. See attached.
This is the result:


.png   brickheadzJackSparrow.png (Size: 223.81 KB / Downloads: 327)

Note that the patterns on the bricks and tiles are low-res as I am testing things.


Attached Files
.png   bh-eye.png (Size: 42.61 KB / Downloads: 305)
.dat   98138bh-eye.dat (Size: 471 bytes / Downloads: 3)
.dat   bh-eye.dat (Size: 341 bytes / Downloads: 2)
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#4
(2017-06-28, 12:04)Jaco van der Molen Wrote:
(2017-06-28, 11:10)Philippe Hurbain Wrote: I see no reason why this shouldn't work... Got some screenshots/sample code? See also this round dish with texmap: http://www.ldraw.org/cgi-bin/ptdetail.cg...960p0b.dat

I was trying to create the Round Tile 1 x 1 with Brickheadz eye pattern. See attached.
This is the result:

Note that the patterns on the bricks and tiles are low-res as I am testing things.

OK, I studied the file you provided and see I am doing things way too difficult and my code and method is not correct.
I'll try to correct.

Edit: done.


Code:
0 Tile  1 x  1 Round with Brickheadz eye Pattern
0 Name: 98138bh-eye.dat
0 Author: Jaco van der Molen
0 !LDRAW_ORG Unofficial_Part
0 BFC CERTIFY CCW
0 !KEYWORDS Brickheadz, eye
0 // Tile 1x1 round without top face
1 16 0 0 0 1 0 0 0 1 0 0 0 1 s\98138s01.dat
0 !TEXMAP START PLANAR   -9 0 9   9 0 9   -9 0 -9   bh-eye.png
0 !: 1 16 0 0 0 9 0 0 0 9 0 0 0 9 4-4disc.dat
0 !TEXMAP FALLBACK
1 16   0 0 0   9 0 0   0 0 0   0 0 9   4-4disc.dat
0 !TEXMAP END
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#5

.png   Jack.png (Size: 113.51 KB / Downloads: 316)
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#12
FYI, LDView has a bug that prevents texture maps from working on transparent geometry.  Unfortunately, this will probably never be fixed, since doing so would require a complete redesign of my texture mapping and transparent geometry handling. More specific, any geometry that textures are applied to becomes opaque. The texture map itself can contain arbitrary transparency, and the underlying geometry's opaque color will show through the transparent parts, but the geometry the texture is applied on is always drawn opaque.

As Philo already pointed out, the solution to your problem was to map the texture onto a disc. If this were a sticker, then the sticker itself would of course be round, which in LDraw would be a very short cylinder, I suppose.
Reply
RE: Texture mapping
#6
OK...
- the underlying "sticker box" needs to be removed
- The texture must be applied to a disc, and not to a quad!
With this considerations, you get the attached subpart.

Then...
Since the structure is very simple, you don't even need the subpart (see part attached with texmap code directly embedded). For modularity reasons you may prefer the subpart way nonetheless!

...and finally... you don't need this at all since brickheads eye is on PT for a while http://www.ldraw.org/cgi-bin/ptdetail.cg...138p0l.dat ;D


Attached Files
.dat   bh-eye.dat (Size: 295 bytes / Downloads: 0)
.dat   98138bh-eye.dat (Size: 629 bytes / Downloads: 1)
Reply
RE: Texture mapping
#7
OK, cross posts... I see you got it, except for part on PT...
Reply
RE: Texture mapping
#8
(2017-06-28, 12:32)Philippe Hurbain Wrote: OK...
- the underlying "sticker box" needs to be removed
- The texture must be applied to a disc, and not to a quad!
With this considerations, you get the attached subpart.

Then...
Since the structure is very simple, you don't even need the subpart (see part attached with texmap code directly embedded). For modularity reasons you may prefer the subpart way nonetheless!

...and finally... you don't need this at all since brickheads eye is on PT for a while http://www.ldraw.org/cgi-bin/ptdetail.cg...138p0l.dat ;D

I see. I was working way too difficult, still in "sticker" mode, since that is where I started a few days ago.

I was kind of dumb not looking for the part on the PT, but I was so busy creating and playing around with texture mapping I just went on.

Update on the patterns for this Jack Sparrow Brickhead (I do hope the patterns are not on the PT)
I made a hi res (still vector PNG) image of the belt pattern on the 1x3 brick.

   
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#9
Haha, I made that Brickheadz eye pattern a while ago, I needed it and it's a super simple pattern  Wink

If you need/want scans/photos of other printed Brickheadz parts, I happen to have all of them (well, aside from the stupidly huge amount of exclusive SDCC models Dodgy ) so just let me know.
Reply
RE: Texture mapping
#10
(2017-06-28, 20:16)Merlijn Wissink Wrote: Haha, I made that Brickheadz eye pattern a while ago, I needed it and it's a super simple pattern  Wink

If you need/want scans/photos of other printed Brickheadz parts, I happen to have all of them (well, aside from the stupidly huge amount of exclusive SDCC models Dodgy ) so just let me know.

LOL

Can you please scan all Brickheadz parts? As sharp and hi-res if you can make them.
I will "remake" them in Vector PNG files (in Fireworks/Illustrator).
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#11
Why using textures here? The patterns are rather simple and easy to author in the usual way...

I'm just asking because Brickheadz are the next patterns I was planning to work on as soon as I'm done with the new architecture sets.
Reply
RE: Texture mapping
#13
(2017-06-28, 22:28)Damien Roux Wrote: Why using textures here? The patterns are rather simple and easy to author in the usual way...

I'm just asking because Brickheadz are the next patterns I was planning to work on as soon as I'm done with the new architecture sets.

These are actually good candidates for parts with full fallback geometry. Textures will cause them to render much faster, but the fallback geometry would still look fine.
Reply
RE: Texture mapping
#14
(2017-06-29, 3:35)Travis Cobbs Wrote:
(2017-06-28, 22:28)Damien Roux Wrote: Why using textures here? The patterns are rather simple and easy to author in the usual way...

I'm just asking because Brickheadz are the next patterns I was planning to work on as soon as I'm done with the new architecture sets.

These are actually good candidates for parts with full fallback geometry. Textures will cause them to render much faster, but the fallback geometry would still look fine.

Damien:
I was testing Texture mapping. I sometimes do models (including instructions) with custom prints/stickers and I wanted to use Texture mapping for that.
I never gave it any attention but a week or so ago it did got my attention and I've been playing around with it since.
The Brickheadz are very nice and if you want to recreate them digitally you have to do a lot of patterned parts.
Since the making of patterned parts is very time consuming I thought it'd be nice to use texture mapping too.

But, if you are willing to make them with LDraw geometry: be our guest!

Concerning Travis his thoughts, I think we should look more in to texture mapping for future patterned parts, since they become more complex and detailed with each new set that comes out.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#15
Let's start with the first one then; Batman. Normally I just take a picture, but I decided to try a scanner this time around. Here's a link.
It does cast a bit of shadows at the bottom, but I think the images are usable right?

I also accidentally saved them as tif, don't know if that matters.

If you (or anyone else) rather want photos, let me know Smile
Reply
RE: Texture mapping
#16
(2017-06-29, 7:11)Merlijn Wissink Wrote: Let's start with the first one then; Batman. Normally I just take a picture, but I decided to try a scanner this time around. Here's a link.
It does cast a bit of shadows at the bottom, but I think the images are usable right?

I also accidentally saved them as tif, don't know if that matters.

If you (or anyone else) rather want photos, let me know Smile

These are fine, Merlijn. Thanks. I'll get right to it.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#17
(2017-06-29, 7:26)Jaco van der Molen Wrote:
(2017-06-29, 7:11)Merlijn Wissink Wrote: Let's start with the first one then; Batman. Normally I just take a picture, but I decided to try a scanner this time around. Here's a link.
It does cast a bit of shadows at the bottom, but I think the images are usable right?

I also accidentally saved them as tif, don't know if that matters.

If you (or anyone else) rather want photos, let me know Smile

These are fine, Merlijn. Thanks. I'll get right to it.

Done.
The logo on the brick is 4000x1200 pixels.
The belt is 4000x1000.
These should represent the dimensions of the planes on which they must be mapped.
Brick 1x4 is 80x24 LDU, Tile 1x4 80x20 LDU.

The yellow color is #F2CD37 which I got from the color chart reference here:
http://www.ldraw.org/article/547.html

The PNG files are vector so they can be scaled up even further (or down).

   

   
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#19
Btw, were you also planning to create vector images for the (many) SDCC exclusive Brickheadz? Because, then I could use those to (try) to create my own stickers. That way I can try to make my collection complete, the cheap way  Rolleyes No way I'm gonna spent thousand(s) of dollars to buy the real versions.
Reply
RE: Texture mapping
#20
(2017-06-29, 8:24)Merlijn Wissink Wrote: Btw, were you also planning to create vector images for the (many) SDCC exclusive Brickheadz? Because, then I could use those to (try) to create my own stickers. That way I can try to make my collection complete, the cheap way  Rolleyes No way I'm gonna spent thousand(s) of dollars to buy the real versions.

If I get good images, pictures or scans from those parts, I can do that. No problem.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#22
(2017-06-29, 8:26)Jaco van der Molen Wrote:
(2017-06-29, 8:24)Merlijn Wissink Wrote: Btw, were you also planning to create vector images for the (many) SDCC exclusive Brickheadz? Because, then I could use those to (try) to create my own stickers. That way I can try to make my collection complete, the cheap way  Rolleyes No way I'm gonna spent thousand(s) of dollars to buy the real versions.

If I get good images, pictures or scans from those parts, I can do that. No problem.

Yeah... That's a bit of a thing... I don't know anybody who has those sets, let alone someone who actually openend the sets (I mean, probably 90% of the buyers just buy it for the resell value  Dodgy ). Well, I'll see if I can find anyone.
Reply
RE: Texture mapping
#30
(2017-06-29, 8:42)Merlijn Wissink Wrote:
(2017-06-29, 8:26)Jaco van der Molen Wrote: If I get good images, pictures or scans from those parts, I can do that. No problem.

Yeah... That's a bit of a thing... I don't know anybody who has those sets, let alone someone who actually openend the sets (I mean, probably 90% of the buyers just buy it for the resell value  Dodgy ). Well, I'll see if I can find anyone.

LOL  Big Grin
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#25
(2017-06-29, 7:59)Jaco van der Molen Wrote: The logo on the brick is 4000x1200 pixels.
The belt is 4000x1000.
These should represent the dimensions of the planes on which they must be mapped.
Brick 1x4 is 80x24 LDU, Tile 1x4 80x20 LDU.

For use with your own custom stickers, this is fine. However, for use in an actual part, it is not a good way to do things. The texture mapping parameters can be adjusted to make the texture map smaller than the geometry it is mapped over. So texture images in official files should always be cropped to not contain any empty space around the edges.
Reply
RE: Texture mapping
#26
(2017-06-29, 17:41)Travis Cobbs Wrote:
(2017-06-29, 7:59)Jaco van der Molen Wrote: The logo on the brick is 4000x1200 pixels.
The belt is 4000x1000.
These should represent the dimensions of the planes on which they must be mapped.
Brick 1x4 is 80x24 LDU, Tile 1x4 80x20 LDU.

For use with your own custom stickers, this is fine. However, for use in an actual part, it is not a good way to do things. The texture mapping parameters can be adjusted to make the texture map smaller than the geometry it is mapped over. So texture images in official files should always be cropped to not contain any empty space around the edges.

On other thing. The belt texture should be black and transparent. When making a texture, you generally only want to include the part of the printed pattern that is actually printed. In this case, that is just the black lines, since the yellow comes from the underlying part. This guarantees that no matter what exact colors are used for the part, there won't be a mismatch. (It also allows the part to be used in completely different colors from the original, as long as whatever color is chosen contrasts sufficiently with the black to allow the pattern to be visible.)

On the batman logo texture, you would want the bat to be black instead of transparent, even though that section presumably isn't printed on the actual part. That's because that part really is supposed to be black, and not "whatever's underneath".
Reply
RE: Texture mapping
#28
(2017-06-29, 17:47)Travis Cobbs Wrote:
(2017-06-29, 17:41)Travis Cobbs Wrote: For use with your own custom stickers, this is fine. However, for use in an actual part, it is not a good way to do things. The texture mapping parameters can be adjusted to make the texture map smaller than the geometry it is mapped over. So texture images in official files should always be cropped to not contain any empty space around the edges.

On other thing. The belt texture should be black and transparent. When making a texture, you generally only want to include the part of the printed pattern that is actually printed. In this case, that is just the black lines, since the yellow comes from the underlying part. This guarantees that no matter what exact colors are used for the part, there won't be a mismatch. (It also allows the part to be used in completely different colors from the original, as long as whatever color is chosen contrasts sufficiently with the black to allow the pattern to be visible.)

On the batman logo texture, you would want the bat to be black instead of transparent, even though that section presumably isn't printed on the actual part. That's because that part really is supposed to be black, and not "whatever's underneath".

OK, I made the belt with black lines and transparent background. The yellow background was just to show.
Concerning the bat, I think it should indeed be black on yellow and background transparent. You can map it on a 1x4 brick to then use in any color.

I made a few other PNG patterns for other parts from Brickheadz. I'll upload those to my website and make the parts on which they are used.

[EDIT] The PNG files I created so far are already in the shared Google folder Merlijn provided:
https://drive.google.com/drive/u/1/folde...S1MZnVEWDg
These do not have the correct dimensions like Travis pointed out.

I think we should consider taking more effort in making patterned parts using texture mapping.
As long as the textures are correct and represent the part we can create patterned parts more rapidly and easily.
Making patterns using LDraw geometry is very time consuming and labour intensive.
And since the prints on patterned parts are getting more complex there comes a time when a pattern cannot be made with LDraw geometry.
Since most modern new generation LDraw programs support texture mapping, I think this is the way we need to go?

At least for purpose I use it: to create models and building instructions using LDCad and LPub3D using LDView as renderer.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#27
(2017-06-29, 17:41)Travis Cobbs Wrote:
(2017-06-29, 7:59)Jaco van der Molen Wrote: The logo on the brick is 4000x1200 pixels.
The belt is 4000x1000.
These should represent the dimensions of the planes on which they must be mapped.
Brick 1x4 is 80x24 LDU, Tile 1x4 80x20 LDU.

For use with your own custom stickers, this is fine. However, for use in an actual part, it is not a good way to do things. The texture mapping parameters can be adjusted to make the texture map smaller than the geometry it is mapped over. So texture images in official files should always be cropped to not contain any empty space around the edges.

I don't understand this. If I scale 4000x1200 pixels tot 80x24 LDU it is a perfect fit. Not?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#29
(2017-06-29, 20:40)Jaco van der Molen Wrote:
(2017-06-29, 17:41)Travis Cobbs Wrote: For use with your own custom stickers, this is fine. However, for use in an actual part, it is not a good way to do things. The texture mapping parameters can be adjusted to make the texture map smaller than the geometry it is mapped over. So texture images in official files should always be cropped to not contain any empty space around the edges.

I don't understand this. If I scale 4000x1200 pixels tot 80x24 LDU it is a perfect fit. Not?

You're forcing the app to load a 4000x1200 texture, which then must be loaded into the graphics hardware, even though only a small fraction of that is actually used. So in a typical scenario, this image would require over 24MB of graphics memory in a situation where most of it is wasted space.

Textures often get loaded using a technique called MIP-mapping, which loads multiple progressively smaller versions of the same image. All the MIP-map levels add up to roughly 133% as much memory as the main texture alone would require. 4000 x 1200 x (4 bytes per pixel) x 1.33 = 25,536,000 bytes. Cropped, the image is 1768x879. The same calculation from above yields 8,267,663 bytes, which is just under 1/3 as many. So, since it uses less than 1/3 the memory, but produces identical end results, it's worth it to go that route when creating an official part.
Reply
RE: Texture mapping
#31
Attached are two files that use the two different methods. batman.ldr uses your original PNG, while batman-crop.ldr uses batman-crop.png (also attached), which is simply a crop of your original PNG. Both should produce identical results when rendered. When I double click on your file from Windows Explorer to load it fresh in LDView, LDView itself uses 70.3MB. When I double click on batman-crop.ldr, LDView uses 52.8MB. With computers and graphics cards having more and more memory as time goes by, that might not seem like much, but it's a 17.5MB difference on one single part. As more parts become textured, it starts to add up. (Note: using the same part multiple times wouldn't multiply the memory, since the texture is only loaded once.)


Attached Files Thumbnail(s)
   

.ldr   batman.ldr (Size: 182 bytes / Downloads: 4)
.ldr   batman-crop.ldr (Size: 205 bytes / Downloads: 3)
Reply
RE: Texture mapping
#33
(2017-06-29, 21:14)Travis Cobbs Wrote: Attached are two files that use the two different methods. batman.ldr uses your original PNG, while batman-crop.ldr uses batman-crop.png (also attached), which is simply a crop of your original PNG. Both should produce identical results when rendered. When I double click on your file from Windows Explorer to load it fresh in LDView, LDView itself uses 70.3MB. When I double click on batman-crop.ldr, LDView uses 52.8MB. With computers and graphics cards having more and more memory as time goes by, that might not seem like much, but it's a 17.5MB difference on one single part. As more parts become textured, it starts to add up. (Note: using the same part multiple times wouldn't multiply the memory, since the texture is only loaded once.)

OK, I'll study this :-)
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#35
batman-crop.ldr uses more memory than batman.ldr in my LDview (~100MB vs ~85MB). How's that possible then? Or did you mean the vram?
Reply
RE: Texture mapping
#51
(2017-06-30, 6:40)Merlijn Wissink Wrote: batman-crop.ldr uses more memory than batman.ldr in my LDview (~100MB vs ~85MB). How's that possible then? Or did you mean the vram?

I meant system memory. It's very odd for the cropped one to use more memory. Just to verify, each LDView run was separate, right? In other words, the only file you opened in LDView was the file in question (batman.ldr or batman-crop.ldr), and exited LDView between files? I would hope that LDView isn't be leaking that much memory, but memory does become fragmented, which causes it to use more and more as time goes by.

I can't think of any reason why the cropped version would use more memory than the non-cropped version. The GLU (OpenGL Utility Library) code I use to convert the image data into OpenGL MIP-Mapping format will resize images so their dimensions are powers of 2. (It resizes to the closest power of 2.) So while the cropped one might be scaled up by 50% in a given dimension, it still shouldn't use more memory than the uncropped one.
Reply
RE: Texture mapping
#52
(2017-07-01, 2:45)Travis Cobbs Wrote:
(2017-06-30, 6:40)Merlijn Wissink Wrote: batman-crop.ldr uses more memory than batman.ldr in my LDview (~100MB vs ~85MB). How's that possible then? Or did you mean the vram?

I meant system memory. It's very odd for the cropped one to use more memory. Just to verify, each LDView run was separate, right? In other words, the only file you opened in LDView was the file in question (batman.ldr or batman-crop.ldr), and exited LDView between files? I would hope that LDView isn't be leaking that much memory, but memory does become fragmented, which causes it to use more and more as time goes by.

I can't think of any reason why the cropped version would use more memory than the non-cropped version. The GLU (OpenGL Utility Library) code I use to convert the image data into OpenGL MIP-Mapping format will resize images so their dimensions are powers of 2. (It resizes to the closest power of 2.) So while the cropped one might be scaled up by 50% in a given dimension, it still shouldn't use more memory than the uncropped one.

Yes, I had just 1 LDview open at a time. No 2 LDviews at the same time. The memory usage. Every single time it's ~85MB vs ~100MB (non-cropped vs cropped). I just tried it again on my freshly started machine. Same thing.

my batmanlogo.png is 2000x600 130kB
my batmanlogo-crop.png is 1768x879 54.2 kB

Maybe there's a difference. It looks like Jaco changed the size of batmanlogo.png between your message and me trying it out?
Reply
RE: Texture mapping
#53
(2017-07-01, 6:56)Merlijn Wissink Wrote: Yes, I had just 1 LDview open at a time. No 2 LDviews at the same time. The memory usage. Every single time it's ~85MB vs ~100MB (non-cropped vs cropped). I just tried it again on my freshly started machine. Same thing.

my batmanlogo.png is 2000x600 130kB
my batmanlogo-crop.png is 1768x879 54.2 kB

Maybe there's a difference. It looks like Jaco changed the size of batmanlogo.png between your message and me trying it out?

Yep, that's the difference. I suggested he keep dimensions below 2048, so he scaled his down by half. The logo I got was 4000x1200, which GLU would scale to 4096x1024 at run-time. Yours will scale to 2048x512. My cropped one will scale to 2048x1024. If you scale my cropped one in half, it would be a more fair test, since the actual bat in my cropped one is twice as big as the bat in his updated one. However, my cropped one is still under 2048 in each dimension, so leaving it alone provides a higher quality end result.
Reply
RE: Texture mapping
#54
(2017-07-01, 18:04)Travis Cobbs Wrote: Yep, that's the difference. I suggested he keep dimensions below 2048, so he scaled his down by half. The logo I got was 4000x1200, which GLU would scale to 4096x1024 at run-time. Yours will scale to 2048x512. My cropped one will scale to 2048x1024. If you scale my cropped one in half, it would be a more fair test, since the actual bat in my cropped one is twice as big as the bat in his updated one. However, my cropped one is still under 2048 in each dimension, so leaving it alone provides a higher quality end result.

Why are you/glu scaling images? Modern drivers don't care about power of two anymore (maybe the internals do but that's their problem).

In LDCad I'll check if the driver needs power of 2 if so I generate a padded image and use uv of <1.0 to compensate. I only apply scaling (down) if the image is above the max supported texture size.
Reply
RE: Texture mapping
#55
(2017-07-01, 18:32)Roland Melkert Wrote:
(2017-07-01, 18:04)Travis Cobbs Wrote: Yep, that's the difference. I suggested he keep dimensions below 2048, so he scaled his down by half. The logo I got was 4000x1200, which GLU would scale to 4096x1024 at run-time. Yours will scale to 2048x512. My cropped one will scale to 2048x1024. If you scale my cropped one in half, it would be a more fair test, since the actual bat in my cropped one is twice as big as the bat in his updated one. However, my cropped one is still under 2048 in each dimension, so leaving it alone provides a higher quality end result.

Why are you/glu scaling images? Modern drivers don't care about power of two anymore (maybe the internals do but that's their problem).

In LDCad I'll check if the driver needs power of 2 if so I generate a padded image and use uv of <1.0 to compensate. I only apply scaling (down) if the image is above the max supported texture size.

I'm using GLU to generate the MIP-maps. Do you use MIP-maps? Because I'm pretty sure they're required to be power-of-two.
Reply
RE: Texture mapping
#56
(2017-07-01, 22:31)Travis Cobbs Wrote: I'm using GLU to generate the MIP-maps. Do you use MIP-maps? Because I'm pretty sure they're required to be power-of-two.

Currently not as I kinda forgot about it now I think about it Smile

I'll add it to 1.6a as it fairly easy to let the driver generate them by using glGenerateMipmap (gl >=3.0) or glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAP, GL_TRUE);
Reply
RE: Texture mapping
#57
Hello,

The patterns for the Brickheadz are almost done, as are the parts.
I've come up with a scheme to name them.

The black tile 2x4 that indicates the series number is part 87079pz00.
For all other parts I started numbering with 1 with the parts in set 41585 Batman.
That set has a 1x4 brick and 1x4 tile so those are 3010pz01 and 2431pz01
And so forth to Beast which featured the 3rd 1x2x2 brick and named that 3245bpz03.

I hope to post them all tomorrow.

I yet have to do Salazars forehead (tile 2x4 with cracks) and the parts for Belle's dress.

For the images I multiplied the dimension with 25 for 1 LDU.
So the PNG file for a 2x4 tile is 2000x1000 pixels.
Tile 1x4 is 2000x500, Tile 1x2 is 1000x500, etc.

Also I am looking up some color information and finding what part of the pattern should be transparent.

   
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#58
Great work!

I was wondering: did you kept the vector based files (Illustrator or whatever you are using). As I said, I'm planning to author those patterns and It could help me a lot to make the parts in ldraw format.

By the way, I also have another question : lets say you put the parts on the tracker, would I be able to "overwrite" them with ldraw geometry only? Is vector based patterns "better" than texture mapped ones?
Reply
RE: Texture mapping
#59
(2017-07-03, 20:09)Damien Roux Wrote: By the way, I also have another question : lets say you put the parts on the tracker, would I be able to "overwrite" them with ldraw geometry only? Is vector based patterns "better" than texture mapped ones?

Just my 2cts:

For flat surfaces LDraw geo should be 'better' unless it generates a billion polygons.
For curved surfaces (minifig heads etc) textures are 99% of the time better as it prevents the 'crumbled paper' effect when doing smoothing.
Reply
RE: Texture mapping
#60
(2017-07-03, 20:21)Roland Melkert Wrote:
(2017-07-03, 20:09)Damien Roux Wrote: By the way, I also have another question : lets say you put the parts on the tracker, would I be able to "overwrite" them with ldraw geometry only? Is vector based patterns "better" than texture mapped ones?

Just my 2cts:

For flat surfaces LDraw geo should be 'better' unless it generates a billion polygons.
For curved surfaces (minifig heads etc) textures are 99% of the time better as it prevents the 'crumbled paper' effect when doing smoothing.

I would qualify that on flat surfaces and say that textures are better if there is a gradient, since LDraw geometry can't do a good job with gradients.
Reply
RE: Texture mapping
#61
(2017-07-04, 6:23)Travis Cobbs Wrote:
(2017-07-03, 20:21)Roland Melkert Wrote: Just my 2cts:

For flat surfaces LDraw geo should be 'better' unless it generates a billion polygons.
For curved surfaces (minifig heads etc) textures are 99% of the time better as it prevents the 'crumbled paper' effect when doing smoothing.

I would qualify that on flat surfaces and say that textures are better if there is a gradient, since LDraw geometry can't do a good job with gradients.
Completely agree with both. Ldraw geometry can also look good (better?) on low curvature parts like bow top plates.
If only the Part tracker (or any other suitable repository?) was updated to receive texture files...!!!
Reply
RE: Texture mapping
#62
(2017-07-03, 20:09)Damien Roux Wrote: Great work!

I was wondering: did you kept the vector based files (Illustrator or whatever you are using). As I said, I'm planning to author those patterns and It could help me a lot to make the parts in ldraw format.

By the way, I also have another question : lets say you put the parts on the tracker, would I be able to "overwrite" them with ldraw geometry only? Is vector based patterns "better" than texture mapped ones?

Sure I kept al files and resources. You can have them if you like. What format? I can make Illustrator or EPS.

About the parts maybe becoming official: I did them because I was testing and playing around with Texture Mapping for some projects I do with custom prints and stickers.
I guess, reading comments by Travis and Roland and others, we'd prefer patterns on flat surfaces done with LDraw geometry.
So be my/our guest to make them. Though texture mapping is much easier and faster, this would be better in the end.

We can do two things: I will make them downloadable, but postpone putting them on the tracker for now.
Or we could put them on the tracker for now and gradually replace them by LDraw geometry versions.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#63
Parts and PNG files to be found here:

Parts: https://drive.google.com/drive/folders/0...sp=sharing
PNG: https://drive.google.com/drive/folders/0...sp=sharing
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#65
(2017-07-04, 6:54)Jaco van der Molen Wrote: We can do two things: I will make them downloadable, but postpone putting them on the tracker for now.
Or we could put them on the tracker for now and gradually replace them by LDraw geometry versions.
There is already a possibility to toggle between texmap and LDraw geometry at global program level. Could it be possible to make it user selectable on a per-part basis?
Reply
RE: Texture mapping
#67
(2017-07-04, 6:54)Jaco van der Molen Wrote: About the parts maybe becoming official: I did them because I was testing and playing around with Texture Mapping for some projects I do with custom prints and stickers.
I guess, reading comments by Travis and Roland and others, we'd prefer patterns on flat surfaces done with LDraw geometry.
So be my/our guest to make them. Though texture mapping is much easier and faster, this would be better in the end.

Just to be clear. One of the reasons for adding the !TEXMAP extension was due to how much easier it made part creation. So while LDraw geometry might be "preferred" for flat patterns, a working textured pattern is infinitely better than no pattern at all.
Reply
RE: Texture mapping
#68
(2017-07-05, 5:37)Travis Cobbs Wrote:
(2017-07-04, 6:54)Jaco van der Molen Wrote: About the parts maybe becoming official: I did them because I was testing and playing around with Texture Mapping for some projects I do with custom prints and stickers.
I guess, reading comments by Travis and Roland and others, we'd prefer patterns on flat surfaces done with LDraw geometry.
So be my/our guest to make them. Though texture mapping is much easier and faster, this would be better in the end.

Just to be clear. One of the reasons for adding the !TEXMAP extension was due to how much easier it made part creation. So while LDraw geometry might be "preferred" for flat patterns, a working textured pattern is infinitely better than no pattern at all.

Agreed! So, if any part Patterned parts request come and there is a good image or scan I can make it, while we wait for someone to create the LDraw geometry version.
Or, like stated before: patterns with gradients or complex patterns. I can easily make that with Fireworks.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#64
(2017-07-03, 18:10)Jaco van der Molen Wrote: For the images I multiplied the dimension with 25 for 1 LDU.
I think that this resolution is needlessly high for most usages. A rule of thumb for good quality printing is to use 300 dots per inch, which matches eye resolution at normal reading distance. This translates into about 5 pixels per LDU (and consider that even if LEGO printing on parts has improved a lot, it hardly qualifies as "good quality printing"). OK, let's crank it up a bit to be on the safe side on higly sloped surfaces, but 10 pixels per LDU should be more than enough!
Reply
RE: Texture mapping
#66
(2017-07-04, 8:49)Philippe Hurbain Wrote:
(2017-07-03, 18:10)Jaco van der Molen Wrote: For the images I multiplied the dimension with 25 for 1 LDU.
I think that this resolution is needlessly high for most usages. A rule of thumb for good quality printing is to use 300 dots per inch, which matches eye resolution at normal reading distance. This translates into   about 5 pixels per LDU (and consider that even if LEGO printing on parts has improved a lot, it hardly qualifies as "good quality printing"). OK, let's crank it up a bit to be on the safe side on higly sloped surfaces, but 10 pixels per LDU should be more than enough!

OK, I´ll scale down a bit then.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#32
(2017-06-29, 20:56)Travis Cobbs Wrote:
(2017-06-29, 20:40)Jaco van der Molen Wrote: I don't understand this. If I scale 4000x1200 pixels tot 80x24 LDU it is a perfect fit. Not?

You're forcing the app to load a 4000x1200 texture, which then must be loaded into the graphics hardware, even though only a small fraction of that is actually used. So in a typical scenario, this image would require over 24MB of graphics memory in a situation where most of it is wasted space.

Textures often get loaded using a technique called MIP-mapping, which loads multiple progressively smaller versions of the same image. All the MIP-map levels add up to roughly 133% as much memory as the main texture alone would require. 4000 x 1200 x (4 bytes per pixel) x 1.33 = 25,536,000 bytes. Cropped, the image is 1768x879. The same calculation from above yields 8,267,663 bytes, which is just under 1/3 as many. So, since it uses less than 1/3 the memory, but produces identical end results, it's worth it to go that route when creating an official part.

Ok this is too technical for me  Blush Huh

What would be the ideal dimensions for the PNG?
Would 1768x879 be it for a 1x4 brick to have a good enough resolution, a good fit and good result?

I am aiming to create some standard parts that are typically patterned like the 1x1, 1x2, 1x3, 1x4 ,1x6 bricks etc.
And tiles 1x1 (square or round), 1x2, 2x2, 1x3, 1x4, 2x4 etc.
And thus create some template PNG files of the correct dimension so we can easily create new patterns.
The minifig torso is a good candidate too to create some standard as are panels.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#34
(2017-06-29, 21:15)Jaco van der Molen Wrote: Ok this is too technical for me  Blush Huh

What would be the ideal dimensions for the PNG?
Would 1768x879 be it for a 1x4 brick to have a good enough resolution, a good fit and good result?

I am aiming to create some standard parts that are typically patterned like the 1x1, 1x2, 1x3, 1x4 ,1x6 bricks etc.
And tiles 1x1 (square or round), 1x2, 2x2, 1x3, 1x4, 2x4 etc.
And thus create some template PNG files of the correct dimension so we can easily create new patterns.
The minifig torso is a good candidate too to create some standard as are panels.

Unfortunately, there's no one right answer, since parts can be used in arbitrary ways and rendered at arbitrary sizes. Having said that, old graphics hardware might fail to load any textures that are bigger than 2048 in either dimension. So it might be good to keep the textures smaller than that*. 2000x600 would probably be plenty to represent the entire area of a 1x4 brick. The trick is that for an official part, the texture should be auto-cropped, and the auto-cropped texture should then be mapped to fill the appropriate region of whatever it's being applied to.

* Technically, renderers (like LDView) should detect the hardware's maximum texture size and automatically down-scale textures that are bigger than that. I can't remember if LDView does this or not, but I think not. It's something I'll consider adding if it's not already done.
Reply
RE: Texture mapping
#36
(2017-06-29, 7:59)Jaco van der Molen Wrote: The PNG files are vector so they can be scaled up even further (or down).
Just to make sure... PNG is not a vector format, is it? (in one of its variants?)
Reply
RE: Texture mapping
#37
(2017-06-30, 8:09)Philippe Hurbain Wrote:
(2017-06-29, 7:59)Jaco van der Molen Wrote: The PNG files are vector so they can be scaled up even further (or down).
Just to make sure... PNG is not a vector format, is it? (in one of its variants?)

PNG is a lossless format, but not a vector based one as far as I know.
Reply
RE: Texture mapping
#38
(2017-06-30, 8:54)Damien Roux Wrote:
(2017-06-30, 8:09)Philippe Hurbain Wrote: Just to make sure... PNG is not a vector format, is it? (in one of its variants?)

PNG is a lossless format, but not a vector based one as far as I know.

I use a program called Fireworks from Adobe which saves in PNG, but one draws and works in vector style like Illustrator.
These PNG's are scalable while maintaining all vector information and thus resolution.

You can use paths, text, shapes, etc.
You can cut, punch, unify with paths and shapes and apply effects like gradient colors and many other great stuff.
It also works with layers.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#41
png can be lossless, but it is a raster-based format in the end. It's not a format to store vector images as far as I know. The most widely used for that nowadays is svg (I think, don't have any sources).
Reply
RE: Texture mapping
#45
(2017-06-30, 12:50)Merlijn Wissink Wrote: png can be lossless, but it is a raster-based format in the end. It's not a format to store vector images as far as I know. The most widely used for that nowadays is svg (I think, don't have any sources).

Still Fireworks makes a great PNG and stores the vector info somehow.
I'll have to check if I can make svg.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#18
Cool. You can find the other ones here, once I've scanned them Smile
Reply
RE: Texture mapping
#21
(2017-06-29, 7:59)Merlijn Wissink Wrote: Cool. You can find the other ones here, once I've scanned them Smile

Thanks! I'll keep it going.
Can you give me permission on that Google folder to drop the PNG files in?
That way, we can share them there and if we decide to actually make the parts, we can easily upload them to the PT?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#23
(2017-06-29, 8:27)Jaco van der Molen Wrote:
(2017-06-29, 7:59)Merlijn Wissink Wrote: Cool. You can find the other ones here, once I've scanned them Smile

Thanks! I'll keep it going.
Can you give me permission on that Google folder to drop the PNG files in?
That way, we can share them there and if we decide to actually make the parts, we can easily upload them to the PT?

Sure, if you can PM me your Google email I can add you to the folder. I'd rather not make it editable for everyone, that's just opening a can of worms on the internet.
Reply
RE: Texture mapping
#24
(2017-06-29, 8:43)Merlijn Wissink Wrote:
(2017-06-29, 8:27)Jaco van der Molen Wrote: Thanks! I'll keep it going.
Can you give me permission on that Google folder to drop the PNG files in?
That way, we can share them there and if we decide to actually make the parts, we can easily upload them to the PT?

Sure, if you can PM me your Google email I can add you to the folder. I'd rather not make it editable for everyone, that's just opening a can of worms on the internet.

I've sent you an e-mail, but will PM you too.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#39
(2017-06-29, 8:27)Jaco van der Molen Wrote:
(2017-06-29, 7:59)Merlijn Wissink Wrote: Cool. You can find the other ones here, once I've scanned them Smile

Thanks! I'll keep it going.

Done some more and put them in the Google folder.

Question: I am going for Iron Man next. How about the pattern on this part:
[Image: 6188122.jpg]
Since this is curved, what would the dimension of the image be?
And how do I map it?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#40
Projection from top. So you need to set the dimension of image to match the base of the brick (40x80ldu), and create the pattern using a photo from top as guide (though since the curvature is rather low here, it won't make much difference)
Reply
RE: Texture mapping
#42
(2017-06-30, 12:12)Philippe Hurbain Wrote: Projection from top. So you need to set the dimension of image to match the base of the brick (40x80ldu), and create the pattern using a photo from top as guide (though since the curvature is rather low here, it won't make much difference)

OK, something like this:

   

Can you give me a hint how to project it in LDraw format?
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#43
Same as usual...


Attached Files
.dat   88930im1.dat (Size: 842 bytes / Downloads: 2)
Reply
RE: Texture mapping
#44
(2017-06-30, 13:49)Philippe Hurbain Wrote: Same as usual...

Ah, OK. I am still not too comfortable with the format and metas for texturemapping.
Would attached files be suitable for the 1x4 brick and 1x4 tile?
Is my header format correct?

What about name giving? I thought about ie. 2431bh01 where bh stand for BrickHeads.


Attached Files
.dat   2431bh01.dat (Size: 563 bytes / Downloads: 2)
.dat   3010bh01.dat (Size: 581 bytes / Downloads: 2)
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#47
(2017-06-30, 14:07)Jaco van der Molen Wrote: Ah, OK. I am still not too comfortable with the format and metas for texturemapping.
Would attached files be suitable for the 1x4 brick and 1x4 tile?
Mmhhh... Travis recommendation about image cropping is still (very) valid!

Quote:Is my header format correct?
No. I strongly suggest that you process files you submit to PT with Datheader http://ldraw.heidemann.org/index.php?page=datheader (it's soooo easy to forget something!)
Quick review of issues:
- brick size must contain front space character in case size is one digit only, in order to ensure correct sorting
- You must inclue a license notice:
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
- !Category must be ommited when the first word of description IS category
- History is not supposed to be there for a simple PT submit. Note that if you need history line (eg. for modifications, or for LDD shape notice), your name must be enclosed in [], not {}
- Keywords must not repeat words present in description

Quote:What about name giving? I thought about ie. 2431bh01 where bh stand for BrickHeads.
This one is a can of worm... Here is naming policy: http://www.ldraw.org/library/tracker/ref/patterns/
So I would use 'B' code (superheroes), 2431pb0 and 3010pb0 (see also already used codes for each part: http://www.ldraw.org/cgi-bin/ptpatterns.cgi?p=2431 and http://www.ldraw.org/cgi-bin/ptpatterns.cgi?p=3010)
Don't forget the 'p' indicating pattern in filename.
Reply
RE: Texture mapping
#48
(2017-06-30, 14:48)Philippe Hurbain Wrote:
(2017-06-30, 14:07)Jaco van der Molen Wrote: Ah, OK. I am still not too comfortable with the format and metas for texturemapping.
Would attached files be suitable for the 1x4 brick and 1x4 tile?
Mmhhh... Travis recommendation about image cropping is still (very) valid!

Quote:Is my header format correct?
No. I strongly suggest that you process files you submit to PT with Datheader http://ldraw.heidemann.org/index.php?page=datheader (it's soooo easy to forget something!)
Quick review of issues:
- brick size must contain front space character in case size is one digit only, in order to ensure correct sorting
- You must inclue a license notice:
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
- !Category must be ommited when the first word of description IS category
- History is not supposed to be there for a simple PT submit. Note that if you need history line (eg. for modifications, or for LDD shape notice), your name must be enclosed in [], not {}
- Keywords must not repeat words present in description

Quote:What about name giving? I thought about ie. 2431bh01 where bh stand for BrickHeads.
This one is a can of worm... Here is naming policy: http://www.ldraw.org/library/tracker/ref/patterns/
So I would use 'B' code (superheroes), 2431pb0 and 3010pb0 (see also already used codes for each part: http://www.ldraw.org/cgi-bin/ptpatterns.cgi?p=2431 and  http://www.ldraw.org/cgi-bin/ptpatterns.cgi?p=3010)
Don't forget the 'p' indicating pattern in filename.

OK, great. It has been a while since I made a real part and got a little rusty on things  Confused
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#49
It would good to have a suffix for all Brickheadz patterns as there are and there will be a certain amount of part.

As "b" is for Superheroes and as not all Brickheadz are superheroes, there should be some kind of thinking before taking that letter I guess.
Reply
RE: Texture mapping
#50
(2017-06-30, 17:47)Damien Roux Wrote: It would good to have a suffix for all Brickheadz patterns as there are and there will be a certain amount of part.

As "b" is for Superheroes and as not all Brickheadz are superheroes, there should be some kind of thinking before taking that letter I guess.

Let's use Z for Brickheadz. So NNNNpz0, et. seq.

I've updated the documentation.
Chris (LDraw Parts Library Admin)
Reply
RE: Texture mapping
#46
(2017-06-30, 13:49)Philippe Hurbain Wrote: Same as usual...

Big Grin

.png   88930im1-1.png (Size: 33.34 KB / Downloads: 164)
Jaco van der Molen
lpub.binarybricks.nl
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 1 Guest(s)
Forum Jump:


Users browsing this thread: 1 Guest(s)