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
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  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.
(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  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.
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 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?
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)
Pages: 1 2 3 4 5 6 7 8