Texture mapping


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
#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
#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
#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
#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
#69
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
Reply
RE: Texture mapping
#70
(2018-01-31, 4:31)amanda feuk Wrote: 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
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#71
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!
Reply
RE: Texture mapping
#72
(2019-03-12, 19:05)Alexander Etges Wrote: 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.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#73
(2019-03-12, 22:07)Jaco van der Molen Wrote: 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!
Reply
RE: Texture mapping
#74
(2019-03-14, 20:56)Alexander Etges Wrote: 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.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#75
(2019-03-24, 20:40)Jaco van der Molen Wrote: OK, these seem OK. I'll give it a try.

Check the tracker, as I'm curently working on those particular ones.
Reply
RE: Texture mapping
#76
(2019-03-25, 19:22)Damien Roux Wrote: 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.
Jaco van der Molen
lpub.binarybricks.nl
Reply
RE: Texture mapping
#77
(2019-03-26, 10:09)Jaco van der Molen Wrote: 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.
Reply
« Next Oldest | Next Newest »



Forum Jump:


Users browsing this thread: 40 Guest(s)