LSC: Texture Mapping extension

[Travis Cobbs]

As has been mentioned in the past, a fair bit of work has been put in behind the scenes to create a texture mapping extension for LDraw. The original work was done by Joshua Delahunty, and then a bunch of back and forth work was done between him and me after he contacted me and I worked on supporting the extension in LDView.

I've been meaning to bring it up here with the LSC for discussion for a long time now, and just never got around to it. Well, I finally got around to converting the specification Word Document that Joshua sent me to HTML, and I feel that LDView is at a point where it can be used as a proof-of-concept renderer for LDraw parts with textures. So, now I'd like us to discuss the extension as it exists now, and work towards getting it ratified.

The current specification (written mostly by Joshua, I think, but edited by me to remove certain features) is here. (I was going to put it into the LSC scratch pad, but ldraw.org was going so painfully slow that I decided not to.)

My development LDView (hopefully) conforms to the above specification. Additionally, a number of files have already been created that conform to this specification by Joshua. A sample of some of them are available here. Because of this, I'd like to request that syntax changes only be made if a relatively major problem is found with the current syntax. I realize this isn't normally how the LSC works, but it seemed that there was little hope of getting this ratified without a working sample implementation, and doing that involved a lot of work.

Obviously, you cannot view the above sample files with any current official LDraw viewer. However, I am currently in the process of releasing LDView 4.2 Beta 1, and have uploaded the installers to SourceForge.net. You can find them below.

Windows 32 bit

Windows 64 bit

Mac Intel 32/64 bit

Linux 32 bit .deb

Linux 64 bit .deb

Some notes. The Linux versions were built using Ubuntu 11.10. They may or may not work on any other Linux versions. The Mac version probably requires Snow Leopard or later. Please let me know if you try it on Leopard or earlier.

The original specification Word Document I got from Joshua Delahunty is here. In addition to some formatting changes, I removed the description of the CYLINDRICAL projection method, and removed its optional GLOSSMAP. Based on the recent discussion of filenames in type 1 lines, I don't think that the syntax for gloss maps was appropriate. If gloss maps are added as a future feature, I would expect them to be in a subsequent !TEXMAP line with a new command. Finally, I removed the OpenGL sample code. That sample code should probably go somewhere, but I don't think the official spec is the right place for it.

Note: I added LSC: to the thread title to differentiate it in the recent messages list from the thread in the public group. I did this to all messages in the thread, which is why I'm listed as the last editor on them. I did NOT change the text of any of the other messages.

[Travis Cobbs]

Sorry to immediately reply to my own post, but I don't feel the information here belongs in the original post. I have some comments to make about the proposed specification for texture maps.

First of all, the extension was specifically designed so that files with texture maps could be loaded in old renderers and still present something to the user that wasn't complete garbage. That's why most texture mapped geometry will be prefixed with 0 !: (to hide it from old renderers), and the reason behind the 0 !TEXMAP FALLBACK command.

Having said that, it is expected that files will be created with textures for the main detail, and placeholders for the fallback geometry. It is also expected that texture mapped versions of existing patterned parts will be created, and for those, the existing full pattern geometry would be used as the fallback. As it happens, the sample files contain both types of files. The following files have both texture maps and full fallback geometry:

970c00px50.dat
973pa9.dat
3068p101.dat

The following file has blank fallback geometry:

3068px01.dat

The following file has red fallback geometry:

3626bpx395.dat

LDView 4.2 Beta 1 contains a "Use texture maps" check box in the Primitives tab of its preferences. The Windows and Mac versions allow you to put this in the toolbar. (The Linux toolbar still can't be customized.) Toggle that setting with the above files loaded to see what happens. This version does not support POV exporting of textured parts. And in fact, if the textures feature is enabled, you'll get bad results, as it outputs both sets of geometry (but without the texture map). I will fix it to either support textures or at least go into correct fallback mode sometime between the Beta release and the official 4.2 release.

If we ratify this texture maps extension, we'll need to update the official parts restrictions document to specify things like maximum texture resolution and requirements for fallback geometry. I don't think we should require the fallback geometry to be anywhere near as good as it is now for patterned parts (although Needs Work might be required if it isn't). One of the reasons for this extension was to make it easier to create patterned parts. And if we require them to have just as much geometric detail as they have right now, but allow them to also have a texture map, that just makes it harder to create them, not easier.

Some of the sample files contain BFC errors. Please disable BFC when looking at them. Real files would obviously not be allowed to have BFC errors.

Support for textures would have to be added to the Parts Tracker. Also, while it's not in the spec yet, it is expected that textures will be placed into a subdirectory. LDView automatically prepends "textures/" to the PNG image's filename. It then uses its standard search path searching to find the file. If that fails, it repeats the process without prepended "textures/". The expectation is that texture files would go into a new <LDraw>/parts/textures directory.

[Chris Dee]

In principle I support this and will do what needs to be done to the Parts Tracker to implement it. However, I'll be on vacation (with no internet) for the next week, so please don't interpret silence as lack of interest. Please give me the opportunity to comment from the Parts Tracker perspective before finalising anything.

[Roland Melkert]

This is very exciting and seems already very good thought out indeed, congrats Travis and Joshua.

Although I find the mapping somewhat (over) complicated i see it's advantage over, for example, the OpenGL approach as an ease of use for the part authors.

One thing I can think of right now (have to look more closely at the examples and experimental LDView later) is adding a mechanism for mip mapping using a default folder structure. Or should we leave that to the renderer (auto generating it themselves)?

Only 'bad' thing about the proposal imho is the short '0 !:' meta, I would prefer something more descriptive. Unless we introduce some general meta command indicating 'is part of above used extension'.

[Travis Cobbs]

Actually, this spec was created with OpenGL's texture matrix capabilities firmly in mind. The data all gets loaded into the texture matrix, and then the texture is activated while drawing all the textured triangles. If you look at the sample source code in the posted Word Document, you'll see how that works. And yes, it was done this way to make it easier to author parts, vs. the more traditional method of mapping specific texture coordinates to the three corners of each triangle.

LDView auto-generates MIP maps at load time. Renderers will really want to do this, because otherwise the textures don't look very good. All of the sample textures also have power of two dimensions, although this isn't mentioned in the spec anywhere.

The !: was chosen after a lot of thought, and some back and forth discussion. We acknowledge that it is obfuscated, but once you understand how it works, it actually makes reading the files (by eye, not computer) really easy, and it has the advantage of being concise. Since there could potentially be a lot of texture-specific geometry, being concise was a consideration.

[Allen Smith]

I have been meaning to start an implementation of this for such a long time, but I've kept putting it off to do other things. No longer, I hope. I think this is a vital addition to LDraw.

Here are a few comments about the proposal:

1. Does a texture stack have a real-world application, or is that just included to handle the case of nested TEXMAP directives?
   
2. I strongly prefer removing geometry2. (All directives between TEXMAP START and TEXMAP FALLBACK would be a !: meta.) This would make writing the file back out considerably easier.
   
3. If geometry2 remains in the spec, does that mean it is legal to introduce another TEXMAP START before the next TEXMAP END without it being in a !: meta? This is somewhat more parsing work, as it means counting up STARTs instead of just advancing to END/FALLBACK.
   
4. I think the NEXT command should be removed. I think it adds complexity with little to no value; I would rather keep the syntax minimalistic.
   
5. Extensibility of projection method: is every method expected to have 9 parameters? If not, there needs to be some kind of demarcator, since the last token cannot be identified if the pngfile is allowed to have spaces in it.
   
6. pngfile must support spaces, because this would make a good end-user feature. Lots of people make custom decals for their creations.
   

Allen

[Travis Cobbs]

Here are my answers to your questions:

1. I'm not sure. That came from Joshua, who is the only one who has really created the files.
   
2. I'm not sure why removing this would make writing significantly easier. If a file were loaded, there would have to be an flag on that file line to let the app know it was shared geometry.
   
3. Yes. However, this is related to item 1, which I didn't have a good answer for. I can't remember how LDView would behave in this instance. Note that LDView strips out the 0 !: from the beginning of all lines they occur on when it is in a !TEXMAP region before parsing those lines (although it also keeps an original copy of the line text).
   
4. This command would actually be quite useful to allow an editor to add a sticker to a user's model. One !TEXMAP PLANAR NEXT, and one quad. It could also be used in an official part with a blank fallback, but only if we allow blank fallbacks (which is probably a bad idea now, but may not be in three years).
   
5. Every method would have a different number of parameters, but any renderer supporting such a method would know in advance how many parameters to expect. Any renderer that doesn't support such a method should either simply ignore the !TEXMAP command, or present a warning to the user. Right now LDView semi-parses the CYLINDRICAL command, but that is an accident; I forgot to remove that code, but will do so prior to the official LDView 4.2 release, which will result in an "unknown texmap method" warning from such lines.
   
6. I agree.
   

[Travis Cobbs]

Joshua Delahunty contacted me via email to inform me that he was the sole author of the Word Document I posted a link to in the original email. I apologize for not verifying that before posting above.

Additionally, as the author of the spec, and as the author of another software program that uses it, he has expressed an unwillingness to allow for us to adopt the spec in modified form. When he asked me a number of years ago to bring it up with the LSC, I misunderstood the request. Since he wrote it, he owns it, and that is his prerogative. I am currently communicating with him via email regarding my own proposed changes (removal of GLOSSMAP, CYLINDRICAL, and SPHERICAL).

I'll post here again when I have more information, but until then, we should put this discussion on hold.

[Roland Melkert]

I must say I find this somewhat alarming, you mean we can't change anything it's all or nothing?

If so that goes against the LDraw nature imho.

[Willy Tschager]

I must say I find this somewhat alarming...

I don't ... it's Joshua.

w.

[Willy Tschager]

In the light of these two posts:

http://forums.ldraw.org/showthread.php?t...11#pid4311

http://forums.ldraw.org/showthread.php?t...30#pid4330

I'm gonna shortly call for a vote. If the vote passes we are going to adopt Joshua's proposal as official LDraw standard, if it's voted down (were 2 NO votes prevent passage) we'll have to work out our own.

w.

[Roland Melkert]

I think we need to wait until Chris is back from his vacation.

[Willy Tschager]

No need. According to our LSC procedures:

Votes last for three weeks

... which give Chris plenty of time to cast his vote.

w.

[Roland Melkert]

Ok, but I would prefer some more discussion about how taking the whole proposal 'as is' will affect future (needed) changes, cause like I stated here:

http://forums.ldraw.org/showthread.php?t...54#pid4354

I don't see the advantage of making something official when LDraw.org it self has no say in it's (future) format.

[Travis Cobbs]

First of all, I do have more to say on the issue, which I will do shortly (hopefully later tonight).

Secondly, Chris specifically asked us to hold off until he got back so that he could be involved in the discussion. If you want to ignore that and call for votes anyway, go ahead, but I personally feel it would be an incredibly cheap shot on your part.