LDraw.org Discussion Forums

Full Version: Texture mapping
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8
(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.
(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?
(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.
(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.
(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.
(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);
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.

[attachment=2842]
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?
(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.
(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.
Pages: 1 2 3 4 5 6 7 8