Texture mapping

[Travis Cobbs]

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.

[Merlijn Wissink]

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?

[Travis Cobbs]

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.

[Roland Melkert]

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.

[Travis Cobbs]

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.

[Roland Melkert]

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

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

[Jaco van der Molen]

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.

   

[Damien Roux]

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?

[Roland Melkert]

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.

[Travis Cobbs]

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.

[Philippe Hurbain]

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

[Jaco van der Molen]

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]

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

[Philippe Hurbain]

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!

[Philippe Hurbain]

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?

[Jaco van der Molen]

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.

[Travis Cobbs]

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.

[Jaco van der Molen]

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.

[amanda feuk]

Hello is there a tutorial out there I have been looking to do exactly this but have yet to find a tutorial on how to do so

Thanks

[Jaco van der Molen]

Hello is there a tutorial out there I have been looking to do exactly this but have yet to find a tutorial on how to do so

Thanks

Hi Amanda,

I don't think there is a tutorial, yet.
I was writing one but had to put it on hold for now. I am planning to pick it up again, but this will take time.

Perhaps you are able to create a part with texture mapping if you read this thread and study all answers.
If not, let it know here. There are always people here that can help.

Edit: found a thread with some posts here too:
https://forums.ldraw.org/thread-22181-post-25512.html

Texturemap format:
http://ldraw.org/documentation/ldraw-org...pping.html

[Alexander Etges]

Hello @All of you!


as I am a huge fan of the Brickheadz, I'm always searching for a way to get the unique bricks for the SDCC exclusives and like Mr. Wissink said a while ago, I don't want to spend this huge amount of money to get them and so I found this nice Forum.

If this still an active Thread I like to ask Mr. van der Molen if you're still designing the bricks!?

I could provide some pictures of the unique bricks in hopes that you can design them...

Keep up the great work and thx in advance!

[Jaco van der Molen]

Hello @All of you!


as I am a huge fan of the Brickheadz, I'm always searching for a way to get the unique bricks for the SDCC exclusives and like Mr. Wissink said a while ago, I don't want to spend this huge amount of money to get them and so I found this nice Forum.

If this still an active Thread I like to ask Mr. van der Molen if you're still designing the bricks!?

I could provide some pictures of the unique bricks in hopes that you can design them...

Keep up the great work and thx in advance!

Hi Alexander,

If you can provide me with good flat images for the patterns, I can make them using texture mapping. That should be no problem.

[Alexander Etges]

Hi Alexander,

If you can provide me with good flat images for the patterns, I can make them using texture mapping. That should be no problem.

Sounds good!

https://drive.google.com/drive/folders/1...sp=sharing

I hope the pics are okay!

[Jaco van der Molen]

Sounds good!

https://drive.google.com/drive/folders/1...sp=sharing

I hope the pics are okay!

OK, these seem OK. I'll give it a try.

[Damien Roux]

OK, these seem OK. I'll give it a try.

Check the tracker, as I'm curently working on those particular ones.

[Jaco van der Molen]

Check the tracker, as I'm curently working on those particular ones.

OK, Damien. Do you need my (vector) drawings? I've done only a few now.

[Damien Roux]

OK, Damien. Do you need my (vector) drawings? I've done only a few now.

As the patterns are not complex, I should be OK.

All the patterned parts of Brickheadz SDCC2016 are on the tracker BTW.