LDraw.org Discussion Forums

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?

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

(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:

[attachment=2817]

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

(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.

[attachment=2819]

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

OK, cross posts... I see you got it, except for part on PT...

(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.

[attachment=2821]

Haha, I made that Brickheadz eye pattern a while ago, I needed it and it's a super simple pattern 

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 ) so just let me know.

(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 

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 ) 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).

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.

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.

(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.

(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.

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

(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

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

(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

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).

[attachment=2825]

[attachment=2824]

Cool. You can find the other ones here, once I've scanned them

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   No way I'm gonna spent thousand(s) of dollars to buy the real versions.

(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   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.

(2017-06-29, 7:59)Merlijn Wissink Wrote: [ -> ]Cool. You can find the other ones here, once I've scanned them

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?

(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   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   ). Well, I'll see if I can find anyone.

(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

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.

(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.

(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.

(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".

(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?

(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.

(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.

(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   ). Well, I'll see if I can find anyone.

LOL 

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.)

(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 

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.

(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 :-)

(2017-06-29, 21:15)Jaco van der Molen Wrote: [ -> ]Ok this is too technical for me 

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.

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?

(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?)

(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.

(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.

(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

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:

Since this is curved, what would the dimension of the image be?
And how do I map it?

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)

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).

(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:

[attachment=2830]

Can you give me a hint how to project it in LDraw format?

Same as usual...

(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.

(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.

(2017-06-30, 13:49)Philippe Hurbain Wrote: [ -> ]Same as usual...

[attachment=2834]

(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.

(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 

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.

(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.