Texture Mapping extension

[Orion Pobursky]

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?

[Travis Cobbs]

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.

[Nils Schmidt]

- 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.

[Roland Melkert]

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.

[Orion Pobursky]

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.

[Travis Cobbs]

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.

[Allen Smith]

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.

Allen

[Travis Cobbs]

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.

[Roland Melkert]

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.

[Orion Pobursky]

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.

[Travis Cobbs]

There was a big thread on patterns where I started on a program to convert SVG files into LDraw DAT files. However, SVG is a very complex file format, and I never got the program to the point where it could read arbitrary SVG files (and probably never will). I looked for an SVG library, but while they can be found to rasterize an SVG (convert from vector graphics to pixel graphics), I was unable to find one that would produce a set of non-overlapping triangles, as is needed for LDraw files.

The point, though, is that people were going to town creating SVG files that represented the patterns, but had no good way to get that information into the official library. Allowing their source SVG files to be in the library, while having pre-rendered PNG versions of the same files for use in programs like LDView, would, in my opinion, be very helpful.

[Joshua Delahunty]

This is in reference to the LSC post

I would also like to discuss that post, though on a bit of a different tangent (Travis Cobbs suggested this was the right place to have some input on the subject).

BACKGROUND
Back in 2009, I worked with a friend who has a history of professional CAD/CAM development. He created a parser for the LDRAW format, using only the precise LDRAW specs as published on the site. He threw a quick-and-dirty GUI front end on it, and we named it "Foundry," the first step in what was to be (and still may be) a world-class part editor that would work with LDRAW compatible parts (there was some serious discussion of creating a higher-level curve-based or geometric-solids based language, and using the .DAT format as the tesselated output of "compiling" that language).

We then worked with Travis Cobbs to create the !OBI extension to LDRAW (which has yet to be submitted to the LSC). That extension allows for the "shading" of stud sides and tube hollows so that parts look as they did in Old Building Instructions (or Original Building Instructions, take your pick). Directives could be placed into code so that a compliant viewer can turn on or off the casting of defined surfaces to black to create this effect. We created a fairly feature-rich directive language, including START..END blocks, and single-line definition NEXT blocks. The effect would "dive into" sub-files as needed, and we had a method for setting and clearing macro values, so that the effect could be conditional inside a sub-file as defined "outside" that sub-file before the sub-file is "called" as if it were a sub-routine.

Foundry received the first OBI treatment, and then I patched in to LDView sources a fairly rich attempt to replicate that success. I had some issues identifying and conditionally disabling the feature with transparent parts* with his sources, so in the end Travis re-wrote the support from scratch and made it comform fully to that spec.

DESIGN BY ARCHITECTURE
Later, I wrote my first two design parts, the Exxon and trucker torsos. I found the "design by architecture" approach to be extrememely slow-going and error prone, and the fact that any design created could not be increased in resolution without a full re-design convinced me that it was time to make something happen with LDRAW texture mapping.

Our first attempt was to write an application that took a bitmap and tesselated it into triangles matching the image. Despite best efforts, and some interesting success, the numbers of triangles seemed prohibitive (source files would grow larger than bitmaps holding texture map textures would be, and they would ALWAYS load into the graphics pipeline, no shutting them off), plus we were still stuck without the ability to do gradients, which more and more decorated parts were featuring. We eventually abandoned this approach.


!TEXMAP DEVELOPMENT
So we developed the !TEXMAP syntax. I wrote the syntax, and my friend coded it into Foundry. We took an approach that would fit the existing LDRAW syntax, be more understandable to the typical layman than UV coordinate definitions, and felt we were off and running. Our first approach was to simply scan the image, slap it on a part, and call it a day. It was nearly INSTANTANEOUS designs on parts.

I asked Travis about running this work in front of the LSC, and also asked if he would add this feature to LDView as yet another unreleased standard. As I recall, it was proof that gradients did exactly what you'd expect that got him working to put the feature into LDView. On the former issue, though, he was reticent. He felt that non-support by MLCAD would be a huge blocker. In fact, nearly every one to a person asked me, upon seeing the results, "when can we get that in MLCAD?!"

The next step we took was to make sure that the FALLBACK syntax was designed and integrated, so that all existing work would continue to live on, and MLCAD compatible files could continue to be developed by those who did not want to upgrade.

I wrote texmap.txt, and furnished that to my friend. He turned it into texmap.doc, added the diagram of how planar mapping works, and added the end section on the Foundry Implementation (so Travis could base his approach on that of Foundry's).

So I had the overwhelming opinion of "that's tremendously cool, but it will never pass with most of the LDRAW population using MLCAD". Additionally I had another LDRAW author strongly advise me NOT to seek LSC approval, because it always resulted in delays. Much better to create something powerful and have people just use it. It was at this point that I dropped the idea of making !TEXMAP into an LSC standard, and set about changing people's minds one at a time...


A LIVING, DEVELOPED STANDARD
I've spent the next two years explaining how it works:
http://www.facebook.com/media/set/?set=a...4199f78c01

and expanding further and further the proof that it's worth the switch from MLCAD
http://www.facebook.com/media/set/?set=a...e2f35c7d88
(this was just the latest, I have a lot more)

Basically, this has been a de facto standard, living and in use, for the past two years. It has lived through many many "what if" and "how do we" scenarios to arrive at the syntax and workflow that were developed in that time.

so when Roland opines "you mean we can't change anything it's all or nothing?"

I have to say that
a) *I* did not submit this standard for consideration by the LSC, and
b) the standard has been developed and is operational, with two years of effort behind it

To take a standard that someone else developed, and then insist that the LSC should ratify that standard, but with certain features removed or modified because they don't "sound right" is, in the nicest terms possible, unfair and improper (and I don't mean this personally, Roland, I have great respect for your work, AND your view on software patents).


SUMMARY
On this topic, my position now is the same as it has been since the standard was written: it's out there to use. It's not official LDRAW syntax, and I have no desire to make it so. Support it if you like, or don't, but be aware that there are incompatibilities with official syntax (file names require quotes if you use spaces in them, for instance).

There are two viewers that support the syntax as designed now. Both fall just short of full compliance with the standard:

- LDView doesn't support quotation marks around the pngfile parameter and based on what he told me, GLOSSMAP would be supported as a texture file name if someone tried

- Neither actually supports GLOSSMAP operations (Travis didn't implement this at all, we were working on implementing lights in Foundry when we got bogged down with the weight of Yet Another Extension), and I'm pretty sure LDView doesn't treat it as a reserved word (see above)

- Neither supports CYLINDRICAL or SPHERICAL mapping (my friend told me it was a trivial addition, when the requirement would arise, for Foundry). LDView only treats CYLINDRICAL as a reserved word, not SPHERICAL (as I understand it)

I'd be most pleased to see expanded support of the standard. Yesterday, I ran into a need for CYLINDRICAL (else I'd probably have to match up two separate PLANAR mappings onto a curved surface -- NOT FUN), and my artist friend who has been working on textures for me has repeatedly asked for GLOSSMAP for all the shiny paints that appear on the minifigure series torsos now (see second link above for image of Kimono Girl, which SHOULD have shiny gold paint). He and I have also discussed the still-theoretical BUMPMAP support so we can do rubber in a pitted way like TLG does in their animations. CYLINDRICAL and GLOSSMAP are probably not very far off in the Foundry implementation, to be sure.

-- joshua


* a feature later found to be un-official, TLG *will* shade such parts. Oh, well.

EDIT: added footnote

[Roland Melkert]

hi Joshua Welcome to the board.

Judging from your reference to my stand on software patents (I'm against them) I think you understand my main concern.

Travis post made me think the whole texture standard is to be handled has Proprietary although I wouldn't mind that as separate entity (unofficial meta), but I do think anything part of the official LDraw standard shouldn't be hampert in such a way. Because the LSC won't be allowed to adjust it in any way like it does the core stuff as part of the LDraw evolution.

Judging from you post above I think we best add this meta as an unofficial extension (only information on ldraw.org)

[Orion Pobursky]

Travis post made me think the whole texture standard is to be handled has Proprietary although I wouldn't mind that as separate entity (unofficial meta), but I do think anything part of the official LDraw standard shouldn't be hampert in such a way. Because the LSC won't be allowed to adjust it in any way like it does the core stuff as part of LDraw

A spec beyond the control of the LSC is exactly the reason why we decided to disallow POV-Ray code in the Official Library

[Allen Smith]

The whole point of having a texture meta is so official LDraw parts can be created using it.

LDraw is a terrible language for making illustrations. Rather than spending huge amounts of time perfecting printed parts using LDraw geometry, people could make high-quality textures in minutes/hours. People who are good at part authoring could focus on real challenges instead. People who stink at part authoring (like me) could meaningfully contribute.

That's not going to happen if there's no agreed-upon standard to do so. That would be sad.

Allen

[Travis Cobbs]

Unless I'm misunderstanding again, Joshua hasn't said that LDraw.org cannot add to this texture mapping standard in the future. He's saying that he does not want any sub-set of the standard he documented to be approved, and he doesn't want any changes to be made in the portion already documented. Furthermore, he expects to add new features in the future (that may be approved or not by the LSC).

I'm not saying that even these restrictions are necessarily acceptable to the LSC, just that things aren't quite as bad as it seems to be portrayed.

[Orion Pobursky]

I'm fine with us adopting the spec but once we do so it should be considered an LSC controlled fork of the original spec. Joshua can do whatever he wants to with the original but our version won't necessarily reflect his changes.

[Joshua Delahunty]

The whole point of having a texture meta is so official LDraw parts can be created using it.

LDraw is a terrible language for making illustrations. Rather than spending huge amounts of time perfecting printed parts using LDraw geometry, people could make high-quality textures in minutes/hours. People who are good at part authoring could focus on real challenges instead. People who stink at part authoring (like me) could meaningfully contribute.

That's not going to happen if there's no agreed-upon standard to do so. That would be sad.

Allen

All the very solid reasons I've spent two years using and proving the technology.

It was one of the principles who first helped create the LDRAW committees who convinced me not to seek ratification, however. Innovation rarely occurs in a bureaucracy.

When I worked with James (and then Terry, and Steve), the goal was to invent means to get our work done, not have rules and roadblocks and limitations on our work. This is why I decided (and told Travis over a year ago) that I didn't want the LSC's involvement.

I've been discussing the situation with my co-author. We didn't intend for the work to be placed into public view in this manner, but that's just something we're having to deal with...

[Travis Cobbs]

When I worked with James (and then Terry, and Steve), the goal was to invent means to get our work done, not have rules and roadblocks and limitations on our work. This is why I decided (and told Travis over a year ago) that I didn't want the LSC's involvement.

I'd like to point out here that I totally misinterpreted the email he sent me over a year ago where he meant that he didn't want the LSC's involvement. Re-reading it after he re-forwarded it to me, I can see in retrospect what he meant, but I didn't understand it at the time. (I know that seems strange, but the context was a response to an email I sent him which was totally unrelated to textures.)

Having said that, I've always felt as Allen does, which is that the point of the meta is so that textures can be used in official parts, and that can't happen without LSC ratification.

[Roland Melkert]

I agree, adapting the current into a LSC controlled fork seems a reasonable compromise.

Although I can't help feeling a bit railroaded, although I fully understand it's not on purpose.

[Joshua Delahunty]

I'm fine with us adopting the spec but once we do so it should be considered an LSC controlled fork of the original spec. Joshua can do whatever he wants to with the original but our version won't necessarily reflect his changes.

Awfully kind of you, allowing me to do what I want with my own spec. :-)

[Please note the double smiley: this comment was made to make light of the situation, I thought the phrasing here was humorous]

EDIT: added extra note about intent of the message.

[Orion Pobursky]

In light of recent gnashing of teeth regarding the ownership of the proposed spec, I think we should create our own spec from scratch. This will prevent the inevitable fight that would ensue if we were to co-opt someone else's work without their express permission.

[Joshua Delahunty]

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).

That is exactly how this works, and the proof of use of gradients and proper alpha blending were what was necessary to bring Travis onboard two years ago.

See the AT-AT dish (in green instead of grey so it really shows) and the "TEST/TEST/Philo was here!" dish at https://plus.google.com/photos/116975088...paign=link

And when you need a pastern with multiple properties you have to divide it into multiple quads etc using multiple textures.

While no one has yet had a need or use for multitexturing yet, this was the intended approach. As Travis mentioned elsewhere, each line as spec'd is to take an optional GLOSSMAP parameter, so each texture is defined to allow for it's own per-texel specularity value for making "shiny" colors actually reflect light appropriately.

[Joshua Delahunty]

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.

The jungle wall just doesn't have artwork YET. ;-) Someone just has to sit down and trace it out, to give the best possible source material. But we did find that a quick scan and some background removal gave EXCELLENT "needs work" results in a very short time frame, and the quality was at or exceeding that of design-by-archiecture approaches in most cases. I recall having great fun finding a Space Police set on the shelves a couple months (November, prior to official January launch) prior to official release, and that night I had the entire figure: head, torso, legs decorated and in LDRAW ready to render. It was of course not up to the highest quality standards, but it was instant gratification and certainly up to released parts standards.

The jungle wall was an example of how a scan looks as opposed to a prepared vector-to-bitmap texture map from the initial examples pool, but the plan was ALWAYS to try to get it vectorized, to get everything vectorized. I redid upper part #5 (the original blue suit-and-tie) with vector art because even those simple shapes look much more true-to-life when vectorized-then-output-as-bitmap than the DbA version.

EDIT: fixed timeline

[Joshua Delahunty]

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?

Once the vector art is set-up (I've used Adobe Illustrator), it's been really simple to output higher-resolution versions of the same image when better fidelity has been needed (Save for Web and Devices...). I went FAR overboard on some of the early tests, using 1024x1024 texture maps for parts that were only a couple inches across.

I haven't tried a single 1Kx1K (or even 2Kx2K for the super fancy graphic carded enthusiast) for, say, the top view of a ramp-and-pit-plate, so that may not be enough. I imagine dividing such a part into quadrants (or more) for texture mapping.

what to do with a 32x48 baseplate of that style? Might need even more.

It will be an interesting experiment, once I get around to it.

[Tim Gould]

I don't think it should be part of the official spec at all. I'm happy to see a texture mapped part library out there, and I'd be happy to see it linked to from the official parts library, and I'd probably download it. But I think that the parts library would be diminished by adapting a limited subset of the format, and I think that the library would be at risk adopting an external format.

The problem with adapting or adopting it officially is that, for editors and viewers that don't support the metas, the parts would reduce to their blank version. Which is far from ideal. Better, IMO, to keep the official library to those parts that work on any LDraw compatible editor/viewer, but allow people to go outside for the texture mapped parts.

Tim

[Willy Tschager]

In light of recent gnashing of teeth regarding the ownership of the proposed spec, I think we should create our own spec from scratch. This will prevent the inevitable fight that would ensue if we were to co-opt someone else's work without their express permission.

Agree with you. Adopting the propsed specs will leave both parties unsatisfied. The developers 'cos inevitable there will be made changes sooner or later, we 'cos we don't have the freedom to go in every direction and will always feel barred. The waste of time and efforts done by the developers is be a pity, but it's better to make a painful break than draw out the agony.

w.

[Travis Cobbs]

That's not true. The spec very specifically has support for fallback geometry so that non-texture-supporting applications would display that instead. Any existing part that was updated to have a texture would continue to display exactly the same in applications not supporting textures. New parts modeled with textures would have whatever level of fallback geometry was considered appropriate. In the short run, this fallback geometry would likely be fairly detailed. In the long run (years down the road, once almost all LDraw apps support textures), this fallback geometry might be very rudimentary.

[Tim Gould]

I was being a little extreme, but you would have to design the tile twice to fall back OK. Which may not be super difficult depending on how crude the fallback was.

Having the part external of the main library would allow the designer not to worry about making a crude fallback part (or to make a really, really crude one). Having them internal would require some balance of quality of fallback.

EDIT: Having given it a little more thought you could use very low-res versions of the texture to automatically make a fallback part so I take back that issue.

Tim

[Joshua Delahunty]

I don't think it should be part of the official spec at all. I'm happy to see a texture mapped part library out there, and I'd be happy to see it linked to from the official parts library, and I'd probably download it. But I think that the parts library would be diminished by adapting a limited subset of the format, and I think that the library would be at risk adopting an external format.

The problem with adapting or adopting it officially is that, for editors and viewers that don't support the metas, the parts would reduce to their blank version. Which is far from ideal. Better, IMO, to keep the official library to those parts that work on any LDraw compatible editor/viewer, but allow people to go outside for the texture mapped parts.

Tim

This problem could be fixed if MLCAD had a software texture mapping renderer added. It IS possible.

[Joshua Delahunty]

This is in reference to the LSC post

I've added images of the texture-mapped minifigure series 4 lawn gnome (#1) to a google+ album (images for #2 kimono girl -- sans decor on her hair, we'll need CYLINDRICAL support for that -- and #3 Musketeer were already up)

https://plus.google.com/photos/116975088...6826227105

-- joshua

[Roland Melkert]

This looks nice, but I must admit I'm at a lost on how to proceed with the whole texture meta thing.

[Joshua Delahunty]

This looks nice, but I must admit I'm at a lost on how to proceed with the whole texture meta thing.

Travis removed three parts of the standard because they aren't implemented in code yet, and he felt that keeping things simpler would be less confusing.

However, the parts shown here need GLOSSMAP so the shiny paints will "look right", and CYLINDRICAL so that the Kimono Girl's head will properly wrap the texture that needs to be built for it. The Foundry author is looking into creating sample code for CYLINDRICAL (as he did for the original PLANAR support). We will need to add lightsources and multi-texturing with a shader to Foundry to provide sample code for GLOSSMAP (after CYLINDRICAL is implemented).

So I had an issue with cutting features out of the standard when they're really not optional, long term.

As should be obvious from the way the meta was so carefully built, it was designed to work in the LDRAW system, including backwards compatibility, and that was our goal when we started.

In the past two years since, several interested parties, including LDRAW committee members, advised me that the meta might "do better" if it remained external. Unfortunately, that change of plans was not communicated to Travis in the clearest manner, and he proceeded with his presentation of the specification -- also unfortunately not well communicated *back* to me a priori, so Travis and I could get on the same page.

I don't have an issue with ratification, despite the advice that ratification by the LSC has often killed innovation in the past, but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

The best approach, in my humble opinion, would be to ratify the entire spec as it stands (if ratification happens), since we are planning to implement the "excised" portions in the coming weeks or months, and there would be a pretty quick follow-up vote otherwise.

-- joshua

[Orion Pobursky]

I don't have an issue with ratification, despite the advice that ratification by the LSC has often killed innovation in the past, but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

Can I have an example of this? In fact, I can't think of any currently ratified spec that wasn't internally developed by the LSC or one of it's members.

[Joshua Delahunty]

I don't have an issue with ratification, despite the advice that ratification by the LSC has often killed innovation in the past, but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

Can I have an example of this? In fact, I can't think of any currently ratified spec that wasn't internally developed by the LSC or one of it's members.

The advice I received was that, once ratified, most tech never really continued to be innovated forward in a major fashion.

I wasn't provided examples, however.

It's quite possible that, once a technology is ratified, it's reached near enough to its potential that it no longer has much room for additional features, and there is a measure of coincidence involved.

[Travis Cobbs]

I think both BFC and MPD pre-date the LSC, but were ratified after the LSC came into existence.

[Allen Smith]

…but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

I have been meaning to look at implementing this syntax for several years, but when Travis brought it up again, I was finally stimulated to get started. While writing a parser for this texture syntax, several questions have arisen. I would appreciate it if you could answer them:

1. You have mentioned your intention to extend this syntax. Where are such extensions going to happen? How are they going to be backwards-compatible with a parser which does not implement them?

2. Suppose I have an image file named

Code:

"Evil" grin.png

What does the TEXMAP START line look like to reference that file?

3. What is the result of the following code snippets?
(Please ignore any actual numbers; they are for demonstration purposes only.)
(Please treat each snippet as if it were contained in a separate file)

Code:

0 // Snippet 1
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
3 4 0 0 0 80 0 0 40 -40 0

Code:

0 // Snippet 2
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 // comment
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0

Code:

0 // Snippet 3
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

Code:

0 // Snippet 4
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0

Code:

0 // Snippet 5
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !: 4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !TEXMAP END
0 !: 3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

Code:

0 // Snippet 6
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !: 4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !: 0 !: 4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !: 0 !TEXMAP END
0 !: 0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

Code:

0 // Snippet 7
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 STEP
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END

Code:

0 // Snippet 8
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
3 4 0 0 0 80 0 0 40 -40 0
0 STEP
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END

[Joshua Delahunty]

…but rest assurred that we plan to continue our work and to expand the specification as necessary, whether it's fully "external" or not.

I have been meaning to look at implementing this syntax for several years, but when Travis brought it up again, I was finally stimulated to get started. While writing a parser for this texture syntax, several questions have arisen. I would appreciate it if you could answer them:

1. You have mentioned your intention to extend this syntax. Where are such extensions going to happen? How are they going to be backwards-compatible with a parser which does not implement them?

We intend to implement CYLINDRICAL and GLOSSMAP fairly soon, SPHERICAL may or may not follow (mostly for completeness, but CYLINDRICAL was in some folk's eyes not needed until very recently).

There was talk for some time of a BUMPMAP extension, so that rubber textures could be done.

For the former, they are in the spec now, a program that didn't want to support them should implement the keywords in the parser, and issue an error (which I believe LDView does currently, though I may be wrong) unless and until it does support them.

For the latter, BUMPMAP may be at the same level as TEXMAP, so it would technically be a comment to any parser that didn't understand the keyword.

2. Suppose I have an image file named

Code:

"Evil" grin.png

What does the TEXMAP START line look like to reference that file?

0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 "\"Evil\" grin.png"

3. What is the result of the following code snippets?
(Please ignore any actual numbers; they are for demonstration purposes only.)
(Please treat each snippet as if it were contained in a separate file)

Code:

0 // Snippet 1
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
3 4 0 0 0 80 0 0 40 -40 0

First let me say that the "texture stack" was partially left over from our OBI work, where it was important to keep track of whether OBI was on or off repeatedly. In some ways, it "wasn't my area." But I'll proceed based on my understanding of the intended operation. I'd say that nesting these guys would just lead to confusion in most cases, and -- as you mentioned -- it's mostly about how these might work if you left something "open" as you went into a sub-file.

In this case, the quad would have image2.png applied, and the tri would have image.png applied (following the spec).

Code:

0 // Snippet 2
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 // comment
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0

The comment is ignored, the quad gets image.png applied.

Code:

0 // Snippet 3
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

quad -> image2.png
tri -> image.png

Code:

0 // Snippet 4
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP NEXT PLANAR 1 2 3 4 5 6 7 8 9 image2.png
0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0

quad -> image.png
tri -> image2.png

I'm going to guess that this MAY not work in the current impl of LDView.

Code:

0 // Snippet 5
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !TEXMAP END
0 !: 3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

According to the spec, this should result in a syntax error on the '4 !: ...' line.

Only 0 !: is an acceptable meta.

Code:

0 // Snippet 6
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 0 !: 0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image2.png
4 !: 0 !: 0 4 4 0 -100 0 80 -100 0 80 -180 0 0 -180 0
0 !: 0 !: 0 !TEXMAP END
0 !: 0 !TEXMAP END
3 4 0 0 0 80 0 0 40 -40 0
0 !TEXMAP END

You'd have a syntax error here as well. Further, the nesting of :! is not supported in the spec. The point of :! is to allow legal geometry to be parsed by a TEXMAP-compliant parser while that same geometry is ignored by older parsers.

something like

Code:

0 !TEXMAP START PLANAR  1 1 1  2 2 2  3 3 3  image.png
0 !TEXMAP_GEOMETRY 4 16 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP_GEOMETRY 3 16 0 0 0 80 0 0  80 -80 0
0 !TEXMAP FALLBACK
4 16  0 0 0  80 0 0  80 -80 0  0 -80 0 0 80 0
3 16  0 0 0  80 0 0  80 -80 0  0 -80 0
0 !TEXMAP END

was determined to be too unwieldy, so we reduced those lines to a constant (and thin) vertical border to make them more readable:

Code:

0 !TEXMAP START PLANAR  1 1 1  2 2 2  3 3 3  image.png
0 !: 4 16 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !: 3 16 0 0 0 80 0 0  80 -80 0
0 !TEXMAP FALLBACK
4 16  0 0 0  80 0 0  80 -80 0  0 -80 0 0 80 0
3 16  0 0 0  80 0 0  80 -80 0  0 -80 0
0 !TEXMAP END

To a non-TEXMAP application, the above would still apply the existing design (made of quads and tris and so on).

Code:

0 // Snippet 7
0 !TEXMAP START PLANAR 1 2 3 4 5 6 7 8 9 image.png
0 STEP
4 4 0 0 0 80 0 0 80 -80 0 0 -80 0
0 !TEXMAP END

Good question. My guess, by spec, would be to act as if the 0 STEP was before the 0 !TEXMAP, and the quad would have image.png applied. The intent of the current spec is that START..END and NEXT always apply to non-comment lines. I'm not sure what the corner cases are for other valid comment-commands or metas. Travis might be able to answer that one better than I.

-- joshua

[Allen Smith]

My apologies; Snippets 5 and 6 contained typographical errors with the leading "4". I have edited my post to correct them. Could you please also edit your responses?

Also note the addition of Snippet 8. I forgot this one the first time around.

Thanks,
Allen

[Daniel Goerner]

Magnus wrote this as comment to one of my submitted parts:
"Am I missing something, or why are we creating "texture mapping", when patterns like this is created?"

Well, I think I have finally made a part that's pro texture mapping:



This is still WIP but as of right now, it has gone beyond 600 KB. I think I could do that with a Hi-Res image for about a third or a quater of that size. Although I don't know which format the textures will finally be, I made a test jpeg about 2000x2000 px in size which had 300 KB. But I think a texture for a torso doesn't have to be this big and could still be considered as Hi-Res.

[Roland Melkert]

Just on a side note, I don't think using JPEG for textures is a good idea. Compression artifacts would ruin quality at close range.

[Daniel Goerner]

It was just an example...

I finished the part a few minutes ago. It's 700 KB now.

[Roland Melkert]

Personally I couldn't care about 700K disk space, and would still prefer it over textures because of it being a vector source.

imho textures (for flat surfaces) should only be used for place holders until a real pattern is modelled.

[Joshua Delahunty]

Just on a side note, I don't think using JPEG for textures is a good idea. Compression artifacts would ruin quality at close range.

IIRC, the standard says to allow either JPEG or PNG, but I've always consistently used PNG files for all the texture mapping I've been doing. For what that's worth. I guess I agree with you, Roland.

The beauty of using Illustrator to create vector art and then output an intermediate PNG as texture is that if there is artifacting, it can usually be greatly reduced by simply outputting the texture at a higher resolution (the higher the better, subject to whatever size limitations you may want to keep on yourself versus the quality). This way, simpler textures can take up less room, and highly detailed textures more room, for required better quality.

Changing the colors in the texture also becomes pretty straightforward.

-- joshua

[Orion Pobursky]

On a side note, is there a free equivilant of Illustrator? I'd like to keep the barriers to parts authoring fairly low and having to buy into Adobe isn't cheap.

[Travis Cobbs]

I believe that Inkscape is designed to be a free alternative to Illustrator. I have no idea if it's any good, though.

[Joshua Delahunty]

On a side note, is there a free equivilant of Illustrator? I'd like to keep the barriers to parts authoring fairly low and having to buy into Adobe isn't cheap.

Anything that allows output of a bitmap is going to work for texture mapping; but I do recommend a tool chain that supports vector graphics for greatest flexibility and value to the work that's done (it's so much easier to make adjustments later on). I'm sure there are all levels of tools that allow for vector graphics to be created, and a bitmap to be output based on it. The tools that were used to generate the SVG for that work are a good place to look..?

Though, to me, the value of the project lies in the fact that I can turn to my professional artist friends and talk to them in the language they understand, and they can do workflow like they understand, and there's no slowdown to the work, fewer barriers to overcome. This fits in with what Allen said here, basically that texture mapping allows those who aren't part modelers to work in a much different way, but still meaningfully contribute. I guess what I'm saying here is that this wouldn't be a barrier to "parts authoring," but rather texture generation, and that it could just as easily be looked upon as an advantage, rather than a barrier -- that professional and useful tools can be used to make low complication contributions to the cause. Adobe tools aren't cheap (nor is Corel Draw, for that matter), but I own both and do they EVER make this job so much easier and quicker to accomplish than any other existing method for LDRAW patterns!

I suggest thinking more in the mindset of how many artistic types (who are already going to know, understand, and likely own, Adobe tools) you can encourage to the cause because you've brought the mountain to them, than how many parts authors you're going to convince to work on textures using yet another open source application to learn (another mountain to climb).

[Philippe Hurbain]

Adobe tools aren't cheap (nor is Corel Draw, for that matter)

There's a Corel Draw student/hobbyist version that's not SO expensive. I've tried Inkscape too, as any new tool it requires some time getting used to it, but it's definitely a capable piece of software.

[Orion Pobursky]

That's good. My reasoning being that if I think that Adobe products are over priced then the 15 year old graphic prodigy with a passion for Lego who works at McDonalds probably cant even dream of buying Illustrator. I want to make sure the there's a free or reasonably price piece of vector software out there.

[Tim Gould]

Sadly it is not particularly good.

Tim