LDraw.org Discussion Forums

Full Version: Texture Mapping extension
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 9 10
This is in reference to the LSC post

Do to the potential to reuse patterns at differing scales, I'd like to see the mapped images be in a vector based format. Thoughts?
I can see how it would be useful, but as a software author, I would prefer we didn't go down that road. In order for it to be useful, we'd probably want to use a standard vector format, and most likely that means SVG. Unfortunately, supporting SVG textures requires tools to incorporate some 3rd-party SVG library. Realistically, this would be the case for any standard vector file format; they're just too complicated to expect an LDraw program to directly parse them. (Using the LDraw format itself as the format for the vector "textures" would seem to defeat the purpose, since that wouldn't make part creation any easier.) From my point of view, that's yet another library that I have to get working in LDView, and I already have enough that it's quite difficult to get LDView to build on a clean machine. Adding one more just complicates things further. Also, it takes a lot longer to load (and then render) an SVG than to load a PNG.

In order to get the performance gains that textures bring, the vector texture would then need to be converted to an image by the rendering program, and that image would then be used as a texture map. And while it's true that the program could generate the image at a resolution that is based on the size at which the image is projected, I don't think this buys us much over simply making the PNG texture big enough to be useful in the largest part using the pattern.

I do feel that it would be perfectly reasonable to include vector versions of the textures in the parts library, and make it optional for rendering programs to use them. However, I feel that any such vector "texture" should be required to also include a PNG version that is simply a rendering of the SVG at an appropriate resolution. This would make it so that if someone created a part using a texture, and someone came back later and needed the texture to be bigger, they could simply re-render the vector graphic into a higher-resolution PNG file, and both the old and the new file would then work fine.
- How can we seperate between colours from LDConfig.cfg (e.g. 80 [Metallic Silver]) and direct colours (0x2RRGGBB) if we have only a image (SVG/PNG/JPEG/BMP/GIF..) as colour reference for the pattern?

- How can we get the material information of a specific colour from the image? For example, metallic silver is some kind of reflective.
I'm guessing because the texture is still used by a '4' or '3' line it will use that lines colour for base properties (incl it's colour for alpha blending). And when you need a pastern with multiple properties you have to divide it into multiple quads etc using multiple textures.
I'll bow to your technical expertise on this.

The thing that concerns me and the reason I brought this up is that I really don't like the "fuzzy" lines of scanned patterns. If I want to make a model virtually, I expect the lines of the patterns to be nice and clean. While this doesn't necessarily need to be addressed in the spec, it definitely needs to be addressed in the policies for the Official Library.
You don't, and Joshua Delahunty (the one who initiated this process) has a proposed solution to the problem, but I didn't include his solution in my proposal. His solution is a separate gray-scale "glossmap" that determines the shininess of each pixel in the texture. Note also that while the textures will likely use RGB values from LDConfig.ldr, they will not be using LDraw color codes directly.

I removed references to gloss maps in the proposal for a few reasons. First of all, I haven't implemented support for it, and without a proof of concept implementation, I'm leery of proposing it for ratification. Secondly, Joshua's proposed syntax wouldn't have worked well with texture filenames that include spaces. It's legitimate to simply disallow spaces in texture filenames, but now that we allow spaces in model filenames (although not part filenames), I don't think that's the right approach. While it's true that the main motivation for the textures was parts, support for them could be added to modelers to allow arbitrary stickers.
I think it would be extremely important to capture each texture's source vector art in the part tracker and library. In addition to allowing the creation of higher-resolution textures in the future, it would also greatly facilitate editing existing patterns.

I agree that this would be very useful. Having said that, some textures won't have any vector artwork associated with them at all. For example, the jungle wall in the samples probably doesn't have any associated vector graphics. And while it could certainly use cleanup, it seems good enough as-is to be used in a "Needs Work" part. I don't think it would be a good idea to require that all textures have vector-based source artwork.
Isn't it a bit overkill to use texture's when there is vector data available?

Because unless it's a curved surface the vector data could translate into core LDraw format which in the long run produces higher quality because it won't go 'fuzzy' at closeups.
I agree on some level. However, the increasing complexity of patterns and printed parts necessitates this. It is far easier to redraw a high quality reproduction of a pattern in an image editor than to model it up with quads and triangles. I'd rather have a high quality drawn pattern that is used with texture mapping than nothing.
Pages: 1 2 3 4 5 6 7 8 9 10