Why are decals/printed images done the way they are???

[End Unsure]

Having done a fair amount of cg modeling and animating I've extracted a few lego pieces for use in programs I'm more familiar with. These things have some of the most insane meshes I've ever seen and the details on them (faces, words, printed designs etc...) are actual models, floating off the main model instead of being a simple texture.

Why??? wouldn't it be easier to have them be a texture with a black and white transparency map that tells the computer which parts to not re-color when you select a new color?

Obviously it all works, Ldraw is an amazing program and its part authors are damn hard workers but I want to understand why this route was taken.

[Travis Cobbs]

Having done a fair amount of cg modeling and animating I've extracted a few lego pieces for use in programs I'm more familiar with. These things have some of the most insane meshes I've ever seen and the details on them (faces, words, printed designs etc...) are actual models, floating off the main model instead of being a simple texture.

Why??? wouldn't it be easier to have them be a texture with a black and white transparency map that tells the computer which parts to not re-color when you select a new color?

Obviously it all works, Ldraw is an amazing program and its part authors are damn hard workers but I want to understand why this route was taken.

The LDraw file format was created before texture mapping was reasonable on consumer hardware, and so did not include support for texture mapping. Support was eventually added to the file format, but as of yet it's still not supported by the parts tracker, nor is it (or probably will ever be) supported by MLCad, which was historically the most popular LDraw editor. Parts Tracker support is required to get the textures into official files, and people need to stop using MLCad for it to be likely for them to catch on. Fortunately LDCad, which is becoming more and more popular (and may even surpass MLCad at this point) supports textures.

The lack of support on the parts tracker is (I think) due simply to lack of time by the people running it. There are texture mapped files on the tracker with simple fallback geometry, along with a note with a URL to the texture file. Hopefully textures will become the norm once they are supported by the parts tracker.

[Roland Melkert]

Having done a fair amount of cg modeling and animating I've extracted a few lego pieces for use in programs I'm more familiar with. These things have some of the most insane meshes I've ever seen and the details on them (faces, words, printed designs etc...) are actual models, floating off the main model instead of being a simple texture.

Why??? wouldn't it be easier to have them be a texture with a black and white transparency map that tells the computer which parts to not re-color when you select a new color?

Obviously it all works, Ldraw is an amazing program and its part authors are damn hard workers but I want to understand why this route was taken.

The main reason is legacy as LDraw was invented by James with vector 'decals' in mind (maybe even no patterns at all?). Also during that age hardware accelerated VGA was far from common (maybe the occasional extension card). So doing texturing in software only was way more work and might be too slow.

Now a days we do have a way to texture parts using png images, but many of the part modelers still prefer the vector based style as that often results in higher quality during zooming.

And also textured parts are not yet integrated in the official library part tracker.

[End Unsure]

Having done a fair amount of cg modeling and animating I've extracted a few lego pieces for use in programs I'm more familiar with. These things have some of the most insane meshes I've ever seen and the details on them (faces, words, printed designs etc...) are actual models, floating off the main model instead of being a simple texture.

Why??? wouldn't it be easier to have them be a texture with a black and white transparency map that tells the computer which parts to not re-color when you select a new color?

Obviously it all works, Ldraw is an amazing program and its part authors are damn hard workers but I want to understand why this route was taken.

The main reason is legacy as LDraw was invented by James with vector 'decals' in mind (maybe even no patterns at all?). Also during that age hardware accelerated VGA was far from common (maybe the occasional extension card). So doing texturing in software only was way more work and might be too slow.

Now a days we do have a way to texture parts using png images, but many of the part modelers still prefer the vector based style as that often results in higher quality during zooming.

And also textured parts are not yet integrated in the official library part tracker.

So funny, I didn't even think about the zooming issue. Its so obvious and I deal with it all the time, I mean I use 8000x8000 textures to avoid that and I still get issues in fine detail areas.

Travis, your detailed answer was greatly appreciated and I enjoyed the history in it.

For the record, I read LDcad was preferable so I started with it and it works great so I never looked back.

My end conclusion however is that textures should continue to be done as they are due to resolution issues but if ever a day came that it was possible to easily make vector textures in a separate file format, it should probably be upgraded to that but yeah for now, this is the only way to go.

[Michael Horvath]

The main reason is legacy as LDraw was invented by James with vector 'decals' in mind (maybe even no patterns at all?). Also during that age hardware accelerated VGA was far from common (maybe the occasional extension card). So doing texturing in software only was way more work and might be too slow.

Now a days we do have a way to texture parts using png images, but many of the part modelers still prefer the vector based style as that often results in higher quality during zooming.

And also textured parts are not yet integrated in the official library part tracker.

So funny, I didn't even think about the zooming issue. Its so obvious and I deal with it all the time, I mean I use 8000x8000 textures to avoid that and I still get issues in fine detail areas.

Travis, your detailed answer was greatly appreciated and I enjoyed the history in it.

For the record, I read LDcad was preferable so I started with it and it works great so I never looked back.

My end conclusion however is that textures should continue to be done as they are due to resolution issues but if ever a day came that it was possible to easily make vector textures in a separate file format, it should probably be upgraded to that but yeah for now, this is the only way to go.

Maybe one day LDraw will support SVG decals. Though I don't think there would be any benefit over current methods.

[Nils Schmidt]

Maybe one day LDraw will support SVG decals. Though I don't think there would be any benefit over current methods.

The drawback of the SVG standard is the constant change and evolution of the file format. It is an unfavourable idea to introduce another complex dependency to the LDraw File Format standard.
The !TEXMAP extension is quite powerful in combination with PNG texture files.
PNG is a WC3 standard, it is free, backwards and forward compatible and is easy to parse.